At the Linux Collaboration Summit in San Francisco, Intel Open Source Technology Center director Imhad Sousou discussed the company’s plans for the next major version of its Linux-based open source Moblin platform. The aim of Moblin, Sousou says, is to improve the quality of the Linux user experience on Atom-based devices. For Intel, this is a broad mandate that reaches deep into the platform and will require improvements at many different layers of the stack. One especially important aspect of Intel’s platform improvement agenda is to reduce overall startup time.
As of current there are maybe a hand full of minimalistic WM’s though could even do this (flux box or JWM ceom to mind), but no full blown DE. Also there would need to be some seriously insane kernel optimizations and even then it seems unlikely. QNX and WinCE can barely pull this off under ideal circumstance, and linux (even the kernel alone) has wayyyyy more overhead.
I am all for being ambitious, but I really think this isn’t going to work. Then again, Intel bought OpenHand some time ago, and the matchbox WM was one that I could see pulling this off. OpenHand had some pretty good tech.
Check this out http://www.embeddedarm.com/products/board-detail.php?product=TS-780… has a boot time of 0.69 sec with Linux kernel 2.6.21
About freaking time.
No, seriously. If some Linux distro had a 5s boot time three years ago, then maybe Windows XP wouldn’t be the number one pick now. It’s not good enough to be as good as Windows, Linux has to be _better_ (in the eyes of the consumer) and I can’t believe it’s taken until now to actually address this. Way, *way* too late now. The upcoming ARM netbooks are distro’s second chance to get things right this time.
Considering all the attempts made over the years to reduce boot time (Ubuntu Upstart, Gentoo InitNG, Fedora’s rhgb project, parallel Init) I hardly think it’s surprising that someone is “finally” tackling the problem. What WILL be surprising is if Intel’s attempt a.) works in most/all cases and b.) becomes widely used.
Red Hat’s RHGB really didn’t have a goal of reducing boot time and it has been replaced by a Plymouth, developed by Red Hat as a freedesktop.org project at
http://freedesktop.org/wiki/Software/Plymouth
Moblin is based on Fedora to a large extend, however the boot time of Moblin is not necessarily something that can be just generalized. It is easy to reduce boot times on a single system but specializing to that particular hardware. That has been done many times before. Having a generic improvement that results in such boot times is quite a bit harder.
Actually this was possible in the past (and _has_ been done, there are even videos of it on youtube) but i guess none of you ever heard of coreboot.
What makes this a bit hard with computers of today is the standard bios, get rid of that (and intel easily can) and all you need is a bit of tunning to get a paralellizing initrd (work has been done on that too already, plenty to choose from there) and loading from today’s flash drives (or better yet the super fast eprom where the bios used to sit) becomes insanely fast and this objective totally possible (maybe even surpassable with some intelligent hibernation).
To those clueless about a given topic: Please refrain from talking about what you don’t know, trolling everyone else and making fools of yourselves in the process. Help make the world a better place!
I’ve been holding out hope for wider development and adoption of coreboot back when it was Linuxbios but it’s still just not a big enough player.
Which is a shame – I bought a GA-M57SLI-S4 because I heard it was fully supported but after really digging down into what coreboot can do with this board, I’d be giving up too much over the vendor BIOS.
http://www.hyperspace.com/
http://www.splashtop.com/
http://www.coreboot.org/Welcome_to_coreboot
Corel has one too but I always have a hard time finding the link. These instant on type OS’s still have been around for some time, but they are still no where near 2 seconds from hitting the power button. It takes longer to pass POST on non EFI based systems.
-poundsmack
knows what he is talking about
the problem with the standard BIOS is that:
a) it’s what makes the machine work with the OS of your choice istead of being tied to just one (although i *hate* the fact that a pc mainboard is the only electronic device i know, that depends on an external – usually mechanical – storage device, and software to separately install on the latter, to not be totally helpless)
b) it’s what the other pieces of hardware and software in the system expect to work (pci cards for option rom’s -own BIOSes- detect and init, OS’s for booting and installation…)
imho, parallelizing helps, but is not the only way –
*deferring* could also do a lot
yes, many believe that presenting the user with a login or a dektop while services are still starting, is a “cheat”, and then shall be avoided
i disagree, because deferring the initialization of services a desktop does not strictly *require* to react to user input (say the networking / wireless stack, or plug and play, or the antivirus or …) could be of great help
of course the desktop would need to be normally responsive even though disk io is going on in the background… so, development in the “deferred start” direction may involve, say, better kernel IO prioritization, thus an overall improvement of the kernel itself
another thing that it could be interesting to take into consideration, would be to stage initialization of individual kernel components, and complete it only when the subsystem is to be actually used (eg initialize the sound card on the fly the first time it’s used or, before entering the desktop, only mount partition required for boot instead of all – or in general mount partitions the first time they’re referenced, and do the same wtr to lower layers)
again, an aspect of the above “defer as much as possible”
looks i’m not the only one who’d like to see the OS embedded on the mainboard (pretty much like in early Amiga kickstart / Mac OS times 🙂 )
unfortunately, the flash rom where the bios usually resides, usually is a *small* (with size of 4-8-16 Mega *bits* at best) and *serial* flash device, targeted for the LPC interface (typically used in 5 of the – iirc – 8 pins it supports) or the Intel Firmware Hub one
this somewhat makes mainboard bios flash chips, a market of their own – and makes somewhat difficult to embed a completely functional OS on the board..
it’d be different if mainboard makers were to put the firmware in the same flash chips used for SSDs and usb “pen-drives”, which in turn would require chipset maker s to migrate to faster parallel flash interfaces – but it’s likely that they’d do that only in the case of a strong market demand for board integrated OS’s
demand that’s missing atm…
though the above, this is a quite on spot idea
since what makes for most of the boot wait is steps for detection and initialization of connected devices ( pci cards, keyboard, usb peripherals, sata drives – which have to spin up – btw, it has been proved that a combination of custom bios and hybrid HDDs can save several seconds from the vista boot process, since the Hybrid drive’s flash memory is instantly ready, unlike the rotating media)
moreover, although nobody appears to thinks about that, a desktop (and even more a *-book) is more likely to retain its HW configuration across boots, than not – it is somewhat silly to detect the cpu, ram , hdd and gpu configuration anew, when it’s safe to assume they haven’t changed ( eg if the case has not been opened) so, making the state of the kernel’s HAL layer persistent across boots, and resetting it if the chassis cover (“intrusion”) check returns it has been opened, could be very useful…
I agree that there are techniques, hibernation is a good one. Pre-running or pre-initialisation also.
One problem is that this is for portable devices that are usually memory limited. There is a programming technique that causes huge delays. Sadly it is recommended to avoid out of memory problems.
This technique is to instatiate all objects needed by the program at start up. Sometimes, and further adding to the startup problem, these structures are then released. It applies also to file, drives and ports; open them or create them to make sure they are available.
As it is not just the kernel that starts but many plug-ins, coding guidelines need to be changed.
There are other techniques, and whole teams of people are engaged in developing them. Let’s hope Intel realise that education and training is essential in promulgating these changes as they must get to all programmers.
Hibernation actually takes longer than a full boot on some machines, especially if you have lots of ram.