init development

Under development: PCMCIA, wireless, etc.
Message
Author
vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#31 Post by vg1 »

yes, you are right. I had missed it in your previous post.
I made several tests and could not get it to find a pup_save on another partition, vfat or linux. I tried various combinations and none worked.

Crash - is it possible at all to have your code find a pup_save on another partition?

vg

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#32 Post by ICPUG »

vg1,

Have you tried removing the PDEV1 parameter? I know without psubdir and PDEV1 the pupsave file could be found on another partition. Not sure what happens if you have only psubdir and not PDEV1. I think it would filter for the associated subdir on any partition before Crash implemented his mods.

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#33 Post by Crash »

Vg1,
Crash - is it possible at all to have your code find a pup_save on another partition?
Yes, if you specify the complete set of parameters, you can locate the save file in any partition, for example (from the original post):

psave=hda3,ext2,/pup220/pup_save.2fs

I can choose the save file to be as diverse as being on a hard drive or on a USB thumb drive.

As you said, the code was only implemented beginning with (I think) 4.2 Beta and later. You have to hack the earlier versions, which may be more trouble than it is worth.

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#34 Post by vg1 »

Crash,

it still doesn't work for me, specifying all params as above. Yes, I had dropped PDEV1 as ICPUG suggests already in my earleir tests. If I drop psubdir then puppy is not found in subdir, only on root. But psave on another partition still doesn't work, with or without psubdir.

Here's my setup:
pup_410, initrd & vmlinuz on sda3/puppy4/410k2 [vfat]
pup_save41k27-3wm.2fs on sda7/p420 [ext2]

here's the grub entry:

title P410 k2.6.27 - pup_save on sda7
rootnoverify (hd0,2)/puppy4/410k27
kernel /vmlinuz20 psubdir=puppy4/410k27 PMEDIA=satahd psubok=TRUE psave=sda7,ext2,/p420/pup_save-41k27-3wm.2fs
initrd /initrd20-2s-ps.gz

Puppy is found correctly, but then boots to ram as on first boot, & pup_save is not found.
Have also tried with pup_save on sda10[vfat], and with p420 on hda3 & its pup_saves in both sda7 & sda10. None of these work.

Can you spot anything wrong in the above setup or entry?

regards
vg

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#35 Post by Crash »

vg1,

I've been using LINLD to boot, and I'm not sure what you need to do using GRUB. I'll mess around with GRUB and give you a report on what I find. It's a good excuse for me to become re-acquainted with GRUB, anyway.

Looking back, the psubok=TRUE parameter tells INIT to ONLY look at the directory you chose when you set the parameter psubdir=puppy4/410k27. It says "all the files are in this subdirectory". You may be able to store a save file on another partition with the same subdirectory name and it should work. This is probably getting clear as mud now. One thing you can do is look at the contents of /initrd/tmp/PUPPYFILES after bootup. It contains the results of INIT's search for all Puppy files. The save file has to show up there in order for it to be recognized.

... I just did some tests after writing the above comments. It turns out that if I don't use the psubok parameter, the boot process will see the save file in different partitions. But when I used the psubok parameter, the first try was a bust. The loader expected the pup_xxx.sfs to be in the first partition that it searched. So I put a copy of the .sfs file there too. Then it booted OK, but didn't bother searching any more partitions for the save file. Actually I can't explain this behavior yet - I need to do more testing.

So what I know so far is that without the psubok parameter, the psave parameter works across partitions. Of course this limits you to putting the Puppy files only one subdirectory deep.

Like I said, this is probably clear as mud. I need to do some more testing. For instance, the two partitions I used were FAT and NTFS. I'm not sure if there are any issues there. Also, I'm using my butchered INIT file and Puppy 4.12 to do the testing. I suppose I should really use version 4.2 to make sure I am using an official released version.

Like usual, it may take me a while to see what is going on. To tell you the truth, you have a configuration that I haven't been using. I normally have one version of Puppy on the hard drive, and another on a USB thumb drive. There are only two other partitions on the hard drive and I don't like to mess with them: one is the NTFS Vista partition ("don't mess with me"), and the other one is the restore partition ("really, really don't mess with me"). What I may do is shrink the NTFS partition again and make room for another partition on the hard drive. That will make testing more straightforward.

So I don't know if this information will help your particular situation, but it may shed some more light on the overall process.

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#36 Post by vg1 »

Crash,

thanks for your extensive comments. I don't really need help with my 'particular situation'. I keep all pup_saves on the same partition with pup_xxx.sfs. I hacked all my p3 & p4 puplets' inits, and all work from two levels deep & multiple pup_saves.
Pup_saves in different partitions were created only to enable me to test & reply to pupshock's questions. I had never tried it with psaves on different partitions and wanted to see it it really works.

Back to your comments. Now finally we are getting somewhere. ICPUG was also on to it. Initially when I dropped pdev1 & psubdir puppy could not be found because it had remained in a subfolder. After several attempts it now works with:
- pup_420.sfs, initrd & vmlinuz on sda3/420 [fat]
- pup_save-420.sfs on sda2/420 [fat], or sda7/420 [ext2]
I had to drop psubdir, pdev1 & psubok.

These are the grub entries that work:

title pup420 - psave on sda7
rootnoverify (hd0,2)/420
kernel /vmlinuz PMEDIA=satahd psave=sda7,ext2,/420/pup_save-420.2fs
initrd /initrd.gz

title pup420 - psave on sda2
rootnoverify (hd0,2)/420
kernel /vmlinuz PMEDIA=satahd psave=sda2,vfat,/420/pup_save-420.2fs
initrd /initrd.gz

/initrd/tmp/PUPPYFILES shows that puppy finds all the save-files scattered around the hard disk, and boots the one specified in grub, provided no params are used. Puppy scans the partitions for pup_xxx.sfs but finds it fairly quickly. Unlike in your case, puppy scanned all partitions, found all save-files and the pup_xxx.sfs on sda3 [so, not only on 1st partition].

In summary, it is as you said: save files will be found across partitions, but with puppy only one level deep. I therefore suggest you modify your statement above 'any combination can be used'.
You seem to be very resourceful and if you can devote more time to this hopefully you will crack it and give us an even more versatile script, with both psubok & psave working in all combinations.

thanks for all your work
vg

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#37 Post by Crash »

It's my pleasure to work on this part of the Puppy project. Believe me, I derive far more benefit learning about Linux through this exercise than I can possible give back to the community.

Yes, the statement should probably read "many different combinations can be used"!

I'm in the process of doing some more tests, and have made another partition on my Vista computer to play with. That in itself took a while, not to make the partition, but to back up all my data and to defrag the hard drive. But that's something I need to do periodically anyway. More to come.

Actually, there is probably no limit to the amount of flexibility that could be built into the search process, but this version of INIT is barely making it into the distro. I need to let it cool down a little before offering any more suggestions. But testing is always appropriate, and I'll let you know what I find out.

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#38 Post by Crash »

I found a simple fix. At line 389 add a single line of code:

Code: Select all

...
 umntfunc /mnt/data
done

[ "$PSUBOK" == "TRUE" ] && PSUBDIR="" #Added code to allow multiple partitions

#in case PSUBDIR boot param (path of puppy files), filter...
if [ "$PSUBDIR" ];then
...
This code prevents the original PSUBDIR filter from being executing. The original filter didn't allow more than one partition to be used. If you don't use the PSUBOK flag, the original code executes unchanged, so the overall code package is backward compatible.

If you use PSUBOK=TRUE and PSUBDIR= wherever your files are, you can put Puppy in multiple partitions in as many directory levels deep as you want. The only caveat is that the directory path has to be the same in each partition, for instance /linux/puppy/p42 in both sda2 and sda4.

Let's see, two weeks to produce one line of code. No wonder software is so expensive!
Attachments
init.tar.gz
Modified init based on init from Puppy v4.2 initrd.gz
(17.34 KiB) Downloaded 516 times

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#39 Post by vg1 »

Crash,

it took me some time to get this right. I used my own init, made up from my previous hacks & manually added your latest code above. When it would't work initially I thought I had made a mistake. But I finally got it to work, so my hack was ok.
It's very fussy though about how you set it up, so here are some more details:

This was my setup for the test:

pup_420.sfs, initrd, vmlinuz & pup_save420.2fs in /sda3/puppy4/420 [vfat]
pup_save420sda2.2fs & pup_save420sda2b.2fs in /sda2/puppy4/420 [vfat]
pup_save420sda7.2fs in /sda7/puppy4/420 [ext2]

Notes:
- psubdir must point to the main location which contains the pup_xxx.sfs file, with no mention of partion or fs, so in my case: psubdir=puppy4/420
- psave must contain the full path [obviously], as in /etc/rc.d/PUPSTATE: psave=sda2,vfat,/puppy4/420/pup_save420sda2.2fs
- PDEV1 must not be used, DEV1FS & PUPMODE have no effect.

Here are my grub entries that worked:

title Puppy420 [default]
rootnoverify (hd0,2)/puppy4/420
kernel /vmlinuz PMEDIA=satahd psubdir=puppy4/420 PDEV1=sda3 psubok=TRUE
initrd /initrd.gz

title Puppy420 - test on sda2
kernel (hd0,2)/puppy4/420/vmlinuz PMEDIA=satahd psubdir=puppy4/420 psubok=TRUE psave=sda2,vfat,/puppy4/420/pup_save420sda2.2fs
initrd (hd0,2)/puppy4/420/initrd3.gz

title Puppy420 - test on sda7
rootnoverify (hd0,2)/puppy4/420
kernel /vmlinuz PMEDIA=satahd psubdir=puppy4/420 psubok=TRUE psave=sda7,ext2,/puppy4/420/pup_save420sda7.2fs
initrd /initrd3.gz

More notes:
- initrd3 is the hacked init containing all the additional code
- the entry works equally with or without the 'rootnoverify' line [hence two different tries above]
- both the partition with the pup_save and the one with the pup_xxx.sfs are mounted at boot. The former as /initrd/mnt/dev_save [also linked to /mnt/home], and the latter as /initrd/mnt/dev_ro2 [as distinguished from /initrd/pup_ro2].
- if more than one pup_save is used on the other partition, one can select the correct file, but using the full pup_save name:
pup_save420sda2.2fs & pup_save420sda2b.2fs work, and the 'short' versions [2.2 & 2b.2] do not work.
Again, you may wish to modify your 'caveat' statement above [ 'one caveat' instead of 'the only caveat' ]?

In conclusion, agan Crash it works as you say [not that I doubted it], provided one takes care to create a correct setup & grub entry. I don't need such a setup but I imagine it will come handy to someone, some time. Now it only has to be included in the main puppy. I hope the developers are reading this.

Thanks for your work again.

regards
vg

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#40 Post by Crash »

vg1,

Thanks for the testing results. My results are similar, although I haven't needed to spell out the entire save file descriptor. I have the following files:

pup_save.2fs and pup_save2.2fs in sda2/linux/puppy/p42
pup_save.2fs and pup_save4.2fs in sda4/linux/puppy/p42
vmlinuz and initrd.gz in sda2/linux/puppy (arbitrary placement)
pup_420.sfs in either sda2/linux/puppy/p42 or in sda4/linux/puppy/p42 - it doesn't make a difference

sda2 and sda4 are both fat32 partitions.

My menu.lst is as follows (yes, I am now using Grub - at least Grub 4 DOS, and hey Grub is Grub, right??):

Code: Select all

title 1. asks for all save files - doesn't set psave
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 2. loads choice of file pup_save.2fs on sda2 or sda4 - sets psave=save.2fs
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=save.2fs psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 3. loads pup_save2.2fs on sda2 - sets psave=save2.2fs
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=save2.2fs psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 4. choice of pup_save.2fs or pup_save2.2fs on sda2 - sets psave=sda2
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=sda2 psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 5. loads pup_save4.2fs on sda4 - sets psave=save4
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=save4 psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 6. choice of pup_save.2fs or pup_save4.2fs on sda4 - sets psave=sda4
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=sda4 psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

title 7. loads pup_save.2fs on sda2 - sets psave=sda2,vfat,/linux/puppy/p42/pup_save.2fs
kernel (hd1,1)/linux/puppy/vmlinuz PMEDIA=satahd psave=sda2,vfat,/linux/puppy/p42/pup_save.2fs psubdir=linux/puppy/p42 psubok=TRUE
initrd (hd1,1)/linux/puppy/initrd.gz

Note: Each of these entries is only three lines long. The line beginning "kernel" in each entry actually wraps around in this post to the next line (or two lines for the seventh case!).

Ths first case doesn't set psave to anything, and I am given the choice of no save file or any of the four save files.

The second case gives the choice of pup_save.2fs from either sda2 or sda4.

The third case loads pup_save2.2fs from sda2.

The fourth case gives the choice of pup_save.2fs or pup_save2.2fs from sda2.

The fifth case loads pup_save4.2fs from sda4.

The sixth case gives the choice of pup_save.2fs or pup_save4.2fs from sda4.

The seventh case loads pup_save.2fs from sda2. This is the only case where I use the entire save file descriptor since the file has the same name on two partitions.

This is the way I wanted it to work. Like I said I'm not sure why you need to spell out the whole big long save file phrase for all cases. Just typing something that makes the file unique should have done the job. But then, this is software. It does what we tell it to do, not what we want it to do.

User avatar
Hugh
Posts: 138
Joined: Sat 24 Jun 2006, 21:53
Location: Imperial Warmongering Dystopia of Amerika

init development and grub menu.lst for options

#41 Post by Hugh »

Crash and vg1:

Your work on this 'project' answers a lot of questions and sheds some very important 'light' on how to do something that has been befuddling me for the past couple of months. Very well done to both of you!!

The ability to direct Puppy to a specific bootup among several options is to me invaluable; and there is no doubt in my mind that numerous others will find your work a god-send.

This forum and its very capable developers/debuggers/innovators is truly amazing!

Thanks again guys!

ICPUG
Posts: 1308
Joined: Mon 25 Jul 2005, 00:09
Location: UK

#42 Post by ICPUG »

Crash,

Can I ask for clarification just to see if I have got it right.

Just one line of code has to be added to the init of the standard 4.2 Puppy.

That code is as per your post of Sat Apr 25, 2009 5:58 am.

The attachment is in effect the initrd.gz of standard Puppy 4.2 (released by WhoDo) modified by the one line of code.

If that is all correct I just need to understand that line of code now! I thought it set PSUBDIR to "" if PSUBOK is TRUE but not sure how that works when you quite clearly have a PSUBDIR and PSUBOK=TRUE in your menu.lst. Time to look at my Bash manual I think.

Thanks.

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#43 Post by Crash »

ICPUG,

Yes, that is exactly right, and the posted INIT is taken directly from the Puppy 4.2 distro with just the one line added.

The code that makes use of PSUBDIR and PSUBOK has already been executed before the added line. The added line is placed just in front of the original PSUBDIR code, and causes the original PSUBDIR code to be bypassed. That was the code that didn't allow more than one partition to be used. In general, when modifying someone else's code, I like to make minimal changes to the original code - I figure that the person who wrote the original code did it for a reason. So if you don't use the PSUBOK parameter, the code I added is bypassed and the original code functions as written. When PSUBOK is set to TRUE, the code I wrote is executed, then the original code is bypassed.

Hugh,

Thanks for the good words. Working on this stuff is a lot of fun, and the support and help from the rest of the community is what makes the Puppy project so enjoyable.

vg1
Posts: 142
Joined: Sun 02 Dec 2007, 18:56

#44 Post by vg1 »

Crash,

it all works as you laid out. I made a setup similar to yours with:

sda3: pup_save420.2fs
sda2: pup_save420.2fs & pup_save420b.2fs
sda7: pup_save420sda7.2fs

All your variations worked:

psave=b - boots pup_save420b.2fs on on sda2
psave=420.2 - choice of sda2 & sda3 pup_save420.2fs files
psave=sda2 - choice of sda2 psave files
psave=7.2 - boots pup_save420sda7.2fs on sda7

I tried one more:
psave=420 - choice of all pup_save420 files on all partitions, in puppy4/420
ie the choice was presented for all pup_saves with 420 in their name, if located in puppy4/420 on any partition. In my case I got the four of them.

As long as psave contains something unique identifying a specific pup_save it works. With short psave names, as above, puppy pauses a bit to figure it out. With a full pup_save name specified it boots a bit faster. The difference is a few seconds on my pc, could be more on a slower one.

regards
vg

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

#45 Post by WhoDo »

Crash wrote:Yes, that is exactly right, and the posted INIT is taken directly from the Puppy 4.2 distro with just the one line added.
Top stuff, Crash. Downloaded for inclusion in Puppy-4.2.1 due for release shortly. Thanks for your efforts, mate. They are much appreciated.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#46 Post by Crash »

vg1,

I feel more comfortable knowing your results are consistent with mine. I figure it takes at least two people to get repeatable results before something can be declared a success.

WhoDo,

I'm pretty happy with this latest small change. I'm still testing and haven't broke it yet.

This was a good exercise for me, because it gave me some incentive to re-acquaint myself with GRUB. I'm beginning to see why so many people prefer GRUB over alternative boot loaders. The DOS version is good for a beginner. It contains a very helpful menu.lst template that was easy to modify for these tests. Besides, when all else fails, it can drop back to DOS. Then I can go back to my old standby programs to figure out what is going on (I still have my floppy distros of Xtree and Norton Utilities in the garage).

This testing session also gave me incentive to take Puppy Version 4.2 out for a test drive. I had been using V4.12 up until now. The newer versions always bring something new and refreshing. Version 4.2 didn't disappoint.

I'm also getting more familiar with using Linux at the command prompt level, so when the GUI doesn't load I don't panic so much now. I'm not sure if it will ever replace DOS. But then again, I eventually weaned myself off of CP/M, so maybe there is some hope.

User avatar
ecomoney
Posts: 2178
Joined: Fri 25 Nov 2005, 07:00
Location: Lincolnshire, England
Contact:

#47 Post by ecomoney »

Crash, your work with the init script is very impressive...it is a very complicated piece of engineering work. It is now possible to launch different users from the Grub menu on a computer...with an attractive graphical frontend!

If you would relish a further challenge, there is a need for a further enhancement/boot parameter of the init script, to help Puppy meet its objectives.

Code: Select all

puppy pfix=recycle
BarryK wrote: Puppy Linux Mission Statement:

* Puppy will easily install to USB, Zip or hard drive media
* Booting from CD, Puppy will load totally into RAM so that the CD drive is then free for other purposes
* Puppy will be extremely friendly for Linux newbies
* Puppy will boot up and run extraordinarily fast
* Puppy will have all the applications needed for daily use
* Puppy will just work, no hassles
* Puppy will breathe new life into old PCs
The last point is particularly relevant

Currently our new users find it very difficult/complicated to install GRUB and get their computers booting without the CD. There is also a "lockout" barrier to installing puppy on really old pc's...correct me if any of my details are not quite accurate, from my research

To boot puppy in liveCD mode you need at least 48mb of ram, to be able start the (very complicated) installer. Puppy has been reported to work on just 24mb or RAM. 32mb is a very common figure.

Many people when they try puppy, they just want to install puppy to the hard disk, and pass their cd onto someone else to use....currently many continue to use the CD because the installation (GRUB Install/Puppy Universal Installer) is so difficult to use. This stops many more people from trying puppy.

Recycling operations for charity or to avoid landfill (which many people on here use puppy for) need a way to recycle their old computer donations with a minimum of training. For them TIME is their most valuable resource. Most computers just have a single hard drive, and on older ones the data already on them is expendable....in fact its often very welcome to be able to wipe this off easily before giving the computer to a new owner. Gparted/grub config/Puppy universal installer is "overkill" for this.

An install routine in "init", triggered by "pfix=recycle", which runs before the pup_4xx is loaded into RAM would make recycling a computer very fast (and worthwhile), and bypass the minimum ram requirement on very old hardware. It would run from the console.

The script might have these steps...

1. Explain to the user/recycler what was about to happen (all data wiped), and confirm
2. Format 2 partitions - a 250mb swap, and the reminder to ext2
3. set the partition "bootable", or write to the MBR
4. Install GRUB to the hard disk
5. Copy the initrd.gz, vmlinuz, files to the hard disk from the CD
6. Ask the user to choose between a (well explained) choice of FULL or FRUGAL install, and perhaps even check the available RAM to give a recommendation.
7. If FRUGAL, copy the pup_4xx.sfs from the CD to the ext2 partition, if FULL, extract it to it.
8. Create a grub menu.lst files *with the file locations in the right place*
9. Eject the CD (this would be "nice") and ask the user to reboot

Much of the code for this already exists in the existing rc.shutdown scripts/universal installer.

I would be happy to work with you to design the screen, and the "newb english" (newblish?) needed to make it usable. I could also provide testing for it, by asking for it to be included it in the HanSamBen I am working with at the moment, plus the puppy 2.14ce "Phoenix" I will be working on.

This would make puppy available to many more people than it currently is, with a lot less "hassle". How big a pile of old computers can you image? You would save that 8)

Many thanks for your work so far.
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]

Sorry, my server is down atm!

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#48 Post by Crash »

Ecomoney,

What you suggest is potentially very useful, and kind of dovetails into two other action items I've been looking at:

"Missing pup_save.2fs file error dialog - what to do next", and "Investigate problem with PUI and Grub not installing properly".

I think a good way for me to start this is to just make another separate script file that I can test using an existing Puppy install from the GUI. Once that is working, it should be able to be incorporated into INIT. The test platform that I have that most closely resembles what you are interested in is a K6-2 Baby AT computer. I have run it with as little as 128 MB, but I can probably find even smaller memory chips to do further testing. It has a hard drive, floppy, CR-RW, and USB. Very cute computer in a small, low profile case, and fairly "green".

As always, don't hold your breath for the final product. But this would be a pretty modular project, and I can probably give periodic reports when I reach certain milestones.

Thanks everyone for your support and suggestions. As I have said before, Puppy Linux is a wonderful teaching resource, and I continue to have a fresh learning experience every time I use it. We have both Barry to thank for his origination of the project and all the Forum members to thank for their continued support.

User avatar
ecomoney
Posts: 2178
Joined: Fri 25 Nov 2005, 07:00
Location: Lincolnshire, England
Contact:

#49 Post by ecomoney »

This has made me :D

I have about 47 Pc's at my disposal at the moment, all of various ages/specs 8)

This includes two P233/96mb/4.3mb machines with EDO ram I use for demonstration purposes.

Qemu/other virtual machine may help you with the "first draft". Let me know where I can help.

In your own time Crash, this feature has been waited for a long time. Perhaps another thread would be appropriate. Would you like me to write up the "requirements/spec" (similar to above) to start things off?
Puppy Linux's [url=http://www.murga-linux.com/puppy/viewtopic.php?p=296352#296352]Mission[/url]

Sorry, my server is down atm!

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#50 Post by Crash »

Ecomoney,

This does indeed deserve a separate thread. The primary task for this thread, "specify pup_save file from boot loader", I believe has been accomplished. Further, I like your description of what needs to be done. We also have a great Vision Statement: "Puppy will easily install", "Puppy will be extremely friendly for Linux newbies", and "Puppy will breathe new life into old PCs".

Note that for the first iteration, I am not committing to "install to USB, Zip or hard drive media", just to a hard drive. The USB and possibly Zip can be added later, but the hard drive install is essential.

So if you can start another thread essentially repeating what you said back a couple of posts, that is a great starting point. Although when taken as a whole this looks like a big project, each one of the parts is easily bounded and well understood. Once an initial product is developed, we could go into some test and evaluation to see if anything else would be worthwhile to add. I'm a believer in sticking to the original specs and creating a product to those specs rather than iterating the specs during development. Then after evaluation, maybe other features could be added. This falls probably under the definition of "Spiral Development".

Actually, I'm surprised someone else hasn't done this previously. But it's never too late to start.

Also, I welcome others to suggest additional features that could be integrated into what you have already laid out. I'll actually be working on what you have already suggested, as I think no matter what, all the tasks you present are worthwhile.

Post Reply