Hi bladehunter, Barry.
Just back from vacation
Just read the news about 1.0.5alpha + usrdevx.sfs.
I will not have a change to try it before next week
I really strongly believe, that we are on the right track with that.
We need to have such a usr*.sfs development environment file system, that
just by mounting AND hopefully executing some autostart script sort of thing,
allows to compile Puppy apps and the kernel etc...
If bladehunter and Barry can team up here - what a dream team!
BTW: I do need this to be automounted if the usr*.sfs file is fount on the live-cd
puppy is booted from.. NOT /mnt/home
But of course, I can always manually mount it..
So please continue both of you to reach this goal, because we are almost there!
BTW: When I left for vacation app. 2 weeks ago, we had close to 400 forum
users.. Now we are close to 500!!!
PS
Puppy 1.0.5a1
Yeah, please take the invitation!
Have fun :)
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
The latest usr_devx.sfs has the kernel 2.4.29 headers in it. As you say, that's all that many apps need to compile.rarsa wrote: To compile the VPN client I required the kernel source. I just downloaded it from the official site, extracted it in /usr/src and that was it. I did not have to compile it, though, but there are many apps that just require the headers.
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Yeah, please take the invitation!
usr_devx.sfs automounts on /usr at bootup, nothing to configure, it's all ready to use. You just have to download it to /mnt/home/, meaning the same partition that has pup001 -- so Puppy can easily find it.PeterSieg wrote: BTW: I do need this to be automounted if the usr*.sfs file is fount on the live-cd
puppy is booted from.. NOT /mnt/home
But of course, I can always manually mount it..
Well, the rc.sysinit script could be modified to look on the CD also... let's see, when it looks for usr_cram.fs, it could also look for usr_devx.sfs and if found copy that to the hard drive.
...next boot, usr_devx.sfs will already be on hd, thus speeding bootup.
...does this seem like what you would want?
Note: anyone with a NTFS-only hard drive must not download usr_devx.sfs to /mnt/home while running Puppy!!!
Barry wrote:
If you have your pup001 in C:\ then you have to do the following:
1. Using Windows download usr_devx.sfs
2. Copy usr_devx.sfs to C:\
3. Reboot with puppy.
Let me reword it to make it VERY clear.Note: anyone with a NTFS-only hard drive must not download usr_devx.sfs to /mnt/home while running Puppy!!!
If you have your pup001 in C:\ then you have to do the following:
1. Using Windows download usr_devx.sfs
2. Copy usr_devx.sfs to C:\
3. Reboot with puppy.
search for usrdevx.sfs etc
Well noWell, the rc.sysinit script could be modified to look on the CD also... let's see, when it looks for usr_cram.fs, it could also look for usr_devx.sfs and if found copy that to the hard drive.
...next boot, usr_devx.sfs will already be on hd, thus speeding bootup.
...does this seem like what you would want?
I do work with at the moment with no hdd at all. Just a cd drive with live-cd Puppy and
a usb stick for pup001 (or was it pup100?)...
Also the qemu environment is somewhat similiar...
So looking on the live-cd is great!
But copying to where pup001 is, doesn't work for me here because of limitted space.
Idealy, only copying to /mnt/home, if enough space..otherwise just mount from cd..
(Oh, so many options -- as usuall )
PS
Have fun :)
-
- Ultra Super-stud
- Posts: 168
- Joined: Fri 06 May 2005, 02:36
- Bancobusto
- Posts: 168
- Joined: Mon 13 Jun 2005, 20:52
- Location: Vancouver Island
Don't know if this helps, maybe there are more than on usr_devx.sfs out there, but here's the one I have, seems to work just swelll....
http://www.nstsoftware.com/puppy/
http://www.nstsoftware.com/puppy/
Barry,
If you are planning to move to the proposed (doopdoop) iceWM improved look and feel, plus having the ability to compile from within Puppy, plus all the other goodies, I really think that the next version of puppy should reflect it.
Those two items alone (ability to compile + new look and feel) separate the next release from the previous versions.
One of the standard ways packages and apps versions are numbered is
<major>.<minor>.<fix>.<build>
<major> Major version usually not fully backwards compatible
<minor> Substantial new features but still backwards compatible.
<fix> Small number of new features, usually resolving anoyances and bugs.
<build> Just meaningfull during development to differentiate test versions.
What rules are you following to number puppy's versions?
I'm actually thorn between suggesting 2.0.0 or 1.1.0
I really think that 1.0.5 does not make justice to the actual relevance of the release. I know that you that look at puppy every day may not realize how much it has grown.
If you are planning to move to the proposed (doopdoop) iceWM improved look and feel, plus having the ability to compile from within Puppy, plus all the other goodies, I really think that the next version of puppy should reflect it.
Those two items alone (ability to compile + new look and feel) separate the next release from the previous versions.
One of the standard ways packages and apps versions are numbered is
<major>.<minor>.<fix>.<build>
<major> Major version usually not fully backwards compatible
<minor> Substantial new features but still backwards compatible.
<fix> Small number of new features, usually resolving anoyances and bugs.
<build> Just meaningfull during development to differentiate test versions.
What rules are you following to number puppy's versions?
I'm actually thorn between suggesting 2.0.0 or 1.1.0
I really think that 1.0.5 does not make justice to the actual relevance of the release. I know that you that look at puppy every day may not realize how much it has grown.