innovating Tinycore proposal - preliminary poll

[tinypoodle]

"Of course it is not without importance at which speed the data is read (difference of boot media)."

Yes, I actually got the biggest drop in boot time when I went from running TC on a box with USB 1.1 to one with USB 2.0.

FWIW, boot time is not a top priority issue with me. At most I boot/shutdown twice a day (often without saving anything on shutdown if I haven't updated any preferences etc.), or even only once a week if I'm being less anal about not wasting energy.

Booting a PC uses a lot of resources and energy, so suspend to disk instead of shutdown and (a later) boot could actually save energy.

With suspend to RAM there would be a certain threshold of time at which either shutdown would use more or less energy in comparison. My estimated guess would be that 2 boots a day may use more energy than suspending to RAM.

[tinypoodle]

what I noticed as taking the most of the time was silly stuff the kernel was searching for that I didn't have  (there's floppy support, even though my computer doesn't have a floppy drive). 

Such is unavoidable with a stock kernel having to work with a wide range of hardware.

You could tune behavior of kernel to a certain degree at boot time with optional parameters:
http://www.kernel.org/doc/Documentation/kernel-parameters.txt

YMMV   

[P5music]

It is very simple - and applies for all operating systems - the bigger the size of data which has to be read at boot time is, the longer the boot time. 
Of course it is not without importance at which speed the data is read (difference of boot media).

I think that with recent hardware it accounts for a very little extent respect to uncompressing data in RAM, creating filesystem, creating dev directory, module loading and timeouts.

loading extensions "onboot" could make up for the vast part of differences of boot times.

indeed fast boot would encompass remastering; at least  "tclocal" trick should be used (I fear both do not work for every combination of extensions).

I could not see how housekeeping of the backup which is in the direct personal responsibility of the user would be related to init scripts.

I think, as well as the member I answered, that we can say tinycore handles backup/restore in a fashion similar to a boot/init script. The meaning was that.

 

When it resets, the PC is set to some fixed starting address. 
000 Registers may or may not be cleared at this point, so the first thing that should happen is that all registers should be cleared.
001 The bare minimum needed to interface to some storage device and the full range of RAM needs to be initiated.
010 Data is copied (at max speed possible) from hd0 to RAM.  The smaller this file, the faster it'll boot.
500 Registers are set to what is indicated by file from disk.
510 PC set to origin of in RAM.
511

this was addressed by Hiroki Kaminaga (I know just his work, I don't know others) in "Improving Linux Start Time Using Software Rescue". It gains just 50% time.

This might be a vast simplication of the process, but the point is that what is typically done by the BIOS, needs to be done by the bootloader.  The more the bios can get out of the way the better.  Or rather, ideally the bootloader would be in the BIOS, and not in the MBR (why do we need that thing again?  It seems unnecessary.)

You are talking about "coreboot" project. But I do not think it is a useful way: kernel patching is the most easy and effective way to gain boot speed, then also init scripts have to be customized.

Grub is typically used, but which bootloader is the FASTEST?

It seems that some time can be gained also patching the boot loader. It has to be investigated.

With suspend to RAM there would be a certain threshold of time at which either shutdown would use more or less energy in comparison. My estimated guess would be that 2 boots a day may use more energy than suspending to RAM.

the king of all tricks would be storing a RAM image of a booted system and loading it at boot then jump to a suitable kernel routine. But it is not clear if devices would be initialited. This could be solved with a quick "wake-up" routine.
In fact the entire boot process could be re-thought but it would remain a linux system I think.

[tinypoodle]

It is very simple - and applies for all operating systems - the bigger the size of data which has to be read at boot time is, the longer the boot time. 
Of course it is not without importance at which speed the data is read (difference of boot media).

I think that with recent hardware it accounts for a very little extent respect to uncompressing data in RAM

If that is what you really believe, then you can just use the cpio archive without compression, avoiding the step of uncompression at boot, at a cost of having to read a bigger size of data.

[P5music]

very instructive to watch this in detail:

http://www.slideshare.net/andrewmurraympc/elce-the

[newbody]

I'm a nobody when it comes to these things but I do remember I've read how they do it in ROM when they do linux almost instant on for Asus and others that have a dualboot option.

They already know the hardware so they don't have to do all the searching a general os need to do to determine what hardware there is.

So one way to achieve it would be to first get to know the computer it is supposed to boot from and then the internal script change the boot so it act like those premade fast boot up in Asus?

Am I too naive maybe. But would it not work to have a slow first time during frugal install and then next time a super fast boot?

Xpud are one of the fast one as I remember.

[P5music]

I found this interesting too:

www.microsoft.com/windowsembedded/en-us/products/westandard/default.mspx
http://www.youtube.com/watch?feature=player_detailpage&v=Xay8nE6GusA
http://www.youtube.com/watch?feature=player_detailpage&v=87LHizlgDQk

[tinypoodle]

Not sure how an advertisement text for "Windows Embedded Standard 7" could be related to TC...

And the titles of both of those videos are misleading refering to "boot" when they obviously show resuming instead.

[tinypoodle]

I found this interesting too:

www.microsoft.com/windowsembedded/en-us/products/westandard/default.mspx
http://www.youtube.com/watch?feature=player_detailpage&v=Xay8nE6GusA
http://www.youtube.com/watch?feature=player_detailpage&v=87LHizlgDQk

Out of curiosity, when finding a chance I hibernated a win XP install on a 9 year old laptop, and resuming took... 6 seconds - same as in that "record breaking" video   
(And that's with a 5400rpm hdd)

[P5music]

obviously

, so this is a misunderstanding caused by the guys' mistake... Uhm, I don't think so.
However probably they could have used also the "Hibernate Once Resume Many (HORM)" feature of WES7.
But no need to guess that, other videos are available about genuine boot.

(this is in a virtual machine; note: WES=XP embedded)
http://www.youtube.com/watch?v=aZ2iEj12Wos&feature=player_detailpage

(this is on a probably slow device)
http://www.youtube.com/watch?feature=player_detailpage&v=c8Q4h1u-bgA

[curaga]

Hibernate once, resume many? I don't see much point in that on a general purpose computer. Then again, that's been done for years already on Canon cameras (they run linux .

[tinypoodle]

Hibernate once, resume many? I don't see much point in that on a general purpose computer. Then again, that's been done for years already on Canon cameras (they run linux .

Couldn't the same be said for firmware images of type OpenWRT et al, or even some others shipped by manufacturers of various embedded devices?

[danielibarnes]

Then again, that's been done for years already on Canon cameras (they run linux .

Originally, The ASIC in Canon cameras was x86-compatible and ran Datalight ROM-DOS. The next version of the ASIC migrated to 32-bit ARM and VxWorks. Since 2007, the cameras run DryOS, an operating system with a 16KB kernel developed internally at Canon.

[curaga]

Originally, The ASIC in Canon cameras was x86-compatible and ran Datalight ROM-DOS. The next version of the ASIC migrated to 32-bit ARM and VxWorks. Since 2007, the cameras run DryOS, an operating system with a 16KB kernel developed internally at Canon.

Hm, maybe my memory is faulty. I do think it was Canon, but maybe it was another camera manufacturer.

[tinypoodle]

obviously

, so this is a misunderstanding caused by the guys' mistake... Uhm, I don't think so.
However probably they could have used also the "Hibernate Once Resume Many (HORM)" feature of WES7.
But no need to guess that, other videos are available about genuine boot.

(this is in a virtual machine; note: WES=XP embedded)
http://www.youtube.com/watch?v=aZ2iEj12Wos&feature=player_detailpage

Another video which does not really reveal anything regarding to boot time...
That guy attempts to shutdown windows before it has finished booting and then wonders why it takes longer to shutdown than to boot... easily reproducible