World record in Linux boot time! 1 Second :)

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
DMcCunney
Posts: 889
Joined: Tue 03 Feb 2009, 00:45

#16 Post by DMcCunney »

sunburnt wrote:yep... If you have one set of hardware you don`t need lots of boot code to figure it out.
In fact most of Puppy`s boot code does exactly that, and finding itself of course...
Driver modules can be compiled into the kernel ( no loading...), etc., etc...
And one of the standard things Linux users used to do was get the source and recompile the kernel. Generic kernels are...generic, built to work with the widest range of hardware. If you know what hardware you have, you can recompile the kernel to include only the bits you need for a smaller, faster, and more efficient system, and do thing like build in the drivers rather than load them at boot.

It's not done that much now, I suspect because hardware has gotten fast and cheap enough that the performance gain isn't worth the effort involved.
______
Dennis

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#17 Post by technosaurus »

Top 3 things that slow Puppy down

a lot of the boot time delays in puppy regarding searching for files is either for backwards compatibility or lack of coordination between the installer script and the init script - not sure which. phome/psubdir should be included by default in every install so that those scans during init are unnecessary. I'm only about 80% familiar with the init process and ~90% with the frugal install script, so I've been hesitant to make the changes myself.

Also copying of the sfs into ram could begin as a thread early on in the init sequence and run concurrent with the rest of the init sequence ... leaving a breadcrumb for the pivotroot sequence to check before running

Adding the modules.dep is already supported but you have to enable it in the woof build (trades 1-2 seconds of boot speed for <1Mb size)

Just my 2¢

The command line setup interface also increases the perceived boot speed. I have addressed this before for keyboard, language and mouse for sidder's hsb puplet, but have yet to come up with a good way to do it for video (too complex for the time I had) or timezone (was not supported). I would suggest en_US, detected mouse, UTC timezone and xorg video at the top resolution and bit depth, with a gui that pops up at first boot to allow any necessary changes.[/code]
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#18 Post by smokey01 »

What would be nice to see is a very fat Puppy that has all the drivers to work on the majority of computers. Once the live CD/DVD is booted it determines what drivers are actually required for the individual hardware and all unused drivers are stripped out and a new OS is created just for this one machine. This would reduce the current distro size significantly and I expect also the boot time. I think Puppy does this to some degree within the pupsave file.

I think Jemimah has used this method for pupeee.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#19 Post by technosaurus »

I worked on a script about a month ago to do exactly that - zdrv cutter
... still needs testing to work out the corner cases though
goingnuts has adapted it for pup'n-go (resulted in 3MB zdrv sfs including the modules.dep - down from over 20MB)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#20 Post by smokey01 »

technosaurus wrote:I worked on a script about a month ago to do exactly that - zdrv cutter
... still needs testing to work out the corner cases though
goingnuts has adapted it for pup'n-go (resulted in 3MB zdrv sfs including the modules.dep - down from over 20MB)
Excellent technosaurus.

I've been thinking about this for a long time now but I just can't seem to find the time and I probably don't have the tech skills anyway.

Another enhancement that I think would be good is to have a separate config file to the pupsave file. The config file would save all of your settings. I couldn't count the amount of times when I've had to create a new pupsave as it got trashed because of some sofware I had installed. I know it creates another file but I can see some advantages especially if the config file was plain text and easy to manually edit.

I actually like the idea of having additional software included by the SFS method as it keeps the pupsave file size down.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#21 Post by technosaurus »

The single config file is not a bad idea & fairly easy to implement on a case by case basis - it may actually reduce the number of files by combining them into one location. /etc/DISTROSPECS ??? (or something like that) contains a lot already.

as for sfs vs pup_save - maybe you would prefer some sort of compressed save file?

here is a little trick for making "meta-packages"

mkdir mypets
dir2pet mypets

When it asks you for dependencies, just enter the comma separated list of the .pets that you normally install.
+firefox,+bmp,+icewm,...

Now you have a metapackage that you can use to install all of your favorites in each Puppy/puplet you install
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#22 Post by goingnuts »

deleted - wrong post :oops:

Post Reply