I built the latest Puppy and installed to USB Flash. Booted, then tested PPLOG, but got a "500 internal server error". I found that PPLOG needs the 'CGI' Perl module -- the reason PPLOG worked before is because I had the 'devx' file loaded, which has the complete Perl, whereas the 'pup_xxx.sfs' has a cutdown Perl PET package (perl-5.8.8tiny). I added the CGI module and PPLOG worked -- that adds about 400KB uncompressed to the cutdown Perl package, but I reckon it is worth it (it jumps from 2600KB to 3000KB according to 'du').
Hmmm, now that we have a web server in the 'standard' Puppy build, I wonder what other little Perl CGI program gems are out there...
One thing that has been most impressive with UniPup is the fast boot. This has brought home to me that as Puppy has progressed, boot times have got gradually longer. 4.1alpha3 is the worst. It is time for a clean sweep, and to make some tough decisions.
I have applied the fast boot code developed for UniPup to the mainstream "normal" Puppy. Some notes on this:
rc.local0 is eliminated (it has a lot of historical, very tangled code), there is now just rc.sysinit, which calls rc.update, rc.network, rc.country and rc.services.
There is no probing of serial devices, nor any autodetection of modems (except of course udevd will autoload any appropriate module it finds a match for). Instead, the intention now is to do the probing after bootup, when the user runs PupDial. The user will also have to manually choose a serial mouse.
By default, pup_xxx.sfs is not copied into RAM, regardless how much RAM there is, unless 'pfix=copy' is specified.
Refined code from the rc.sysinit used in UniPup, to wait for slow hardware without gross 'sleep' lines inserted.
The "normal" Puppy cannot boot quite as fast as UniPup, due to the initrd step of the former -- the init script waits for USB storage to become available, then after the switch_root the modules for some other slow hardware may get loaded (for example PCMCIA) and there may have to be a wait again -- whereas in UniPup the usb-storage driver would be loaded concurrently with the drivers for other slow hardware. However, a full hd intall will get the same fast boot as UniPup.
Anyway, I think any potential slower boot of the "normal" Puppy will only be a few seconds.
A comment on point-2. In many cases a module for a modem will be detected and loaded, and its firmware package loaded, and any install script executed. So, it may be that the modem is still fully autodetected and ready to go. However, true hardware serial modems will not be autodetected, but the "probe" button in PupDial will find it, and set /dev/modem to point to the required device. Some details may need to be worked out though!
A comment on point-3. When boot from a live-CD, the normal thing is to create a save-file at first shutdown, then the 'pup_xxx.sfs' also gets copied to the hard-drive. On subsequent boots, although the pup_xxx.sfs' is not copied to RAM, I found performance to still be good, due to intelligent buffering of memory-reads in RAM by the kernel -- after the first read, the kernel keeps as much in RAM buffer as it can.
I suppose I could make one small concession -- on first boot, PUPMODE=5, if there is lots of RAM then do copy pup_xxx.sfs off the CD, but only for PUPMODE=5. I think that some people like to boot in PUPMODE 5 often, and would like the optical drive to be freed up.
Comments:Posted on 13 Jul 2008, 23:18 by linuxcbon
I was going to report "long booting time" for 4.1alpha3. Thanks for adding those improvements.
Posted on 13 Jul 2008, 23:39 by prehistoric1
The Unipup experiment is getting more and more attractive for me. Every time I see those sleep lines in the init code I get the feeling I used to get from analog delay lines in video designs; somewhere down the line those fixed delays are going to bite us. That "tangled code" has frightened me into passive acceptance on faith. I would need to know more about your relationship to some deity to alter it.
It may be possible to use features of normal Puppy at a later stage of the Unipup experiment. The problem at present is that we have not known the cost vs. a simple direct implementation, so we did not know when various tricks actually paid off.
I'm afraid the comment about the cgi module in PERL only reinforces my prejudices. (Far too easy to do.) As a first approximation, I assume PERL has no semantics of its own; everything is in various bindings and added packages. This makes reading PERL harder than writing. It also makes the size deceptive. That said, cgi could allow us to run a lot of code. Do we want it?
Posted on 14 Jul 2008, 3:40 by lobster
Glad to hear of the speed up - I noticed the speed increase of Unipup. Further increases possible?
1. Scan for 'esc' to bypass 5 second pause to put in puppy parameters at start up
2. Use this esc time to set a variable for the locale - otherwise default to 'En'
3. Use esc sequence to load a saved sfs-save file or default to last save file
4. Use a lowish res vesa as a default, straight in boot up - then dialog with first boot for set up - internet connection, higher res. etc.
Posted on 14 Jul 2008, 7:12 by GreatnessGuru
Linux kernel 220.127.116.11
> ... I built the latest Puppy ...
Linux kernel 18.104.22.168 is out, one patch:
"... x86: fix ldt limit for 64 bit
... Fix size of LDT entries.
On x86-64, ldt_desc is a double-sized descriptor.
Posted on 14 Jul 2008, 10:37 by kirk
Re: Faster Boot
That all sounds good. I've been booting pfix=noram for a while, haven't noticed any slow down. And some programs need lots of RAM.
Been playing with unipup a bit, once I add the kernel modules and other missing stuff, boot time slows down I think these changes will make it pretty close.
If you really want to speed things up, use ext3 in the pup_save file. After I use a pup_save file for a while and it gets lots of files stored in it, about 1/4 of my boot time is spent with fsck.
Posted on 14 Jul 2008, 12:07 by growler
Not tried uni-pup .. the slow boot problem is particularly sad with a frugal install and the requirement for a check of pup_save file.. on every boot. Frugal installs make for super easy upgrades and multiple installs etc.. but the boot time is a shocker.
On Hiwatha/PPLOG I compiled it on 4.0 when I couldn't find the PET and the binary was 400k + 400k for the Perl CGI we are looking at adding a fair bit. Maybe there are some compile options I didn't choose correctly. However, I expect this does open up a lot of other code though.
Posted on 14 Jul 2008, 14:53 by growler
Thanks Barry for the PET ... yes 107k looks more like it. I understand that Fast CGI may actually be a faster option than apache SAPI module for running PHP and this Hiawatha server looks much easier to administer. A PHP fast cgi binary into 400k seems extremely unlikely - although might be able to make a sensible PET option for those like myself that need it.
Posted on 15 Jul 2008, 18:39 by shankargopal
Not copying pup_save
On the decision to not copy the pup_save into memory - I agree it will no doubt save a great deal of time on bootup, but won't it slow down the system when running? For instance one of the systems I run my flash-based puppy on is an ancient 256 meg machine with an old AMD chip. Pretty much the only progs that start fast are those that are loaded into memory as part of the pup_xxx.sfs file. Would it make sense to speed up the bootup at the cost of more delays when the system is actually running?