Slashdot Mirror


The 1-Second Linux Boot

An anonymous reader writes "Less than one second Linux boot! This video shows an OMAP3530 capturing video data from a camera and rendering it to an LCD display — the video appears on the LCD display in less than a second from reset."

24 of 156 comments (clear)

  1. 1-Second First Post! by Fieryphoenix · · Score: 5, Funny

    Guess Linux is faster than Slashdot.

  2. Re:Link is dead already by Beelzebud · · Score: 5, Funny

    Don't worry, it will be back in a second.

  3. Pretty long video though by suso · · Score: 5, Funny

    For a 1 second boot, it takes a 2.5 minute video to demonstrate it.

    1. Re:Pretty long video though by buchner.johannes · · Score: 3, Funny

      Because it's in slow motion, doh

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  4. The Register also has the story. by Anonymous Coward · · Score: 5, Informative
    1. Re:The Register also has the story. by somenickname · · Score: 4, Informative

      I find it disturbing that you have to sit through a 2:30 minute powerpoint presentation accompanied by 1980s porn music in order to see the 1 second boot time. For those looking for just the boot time, it occurs between 1:05 and 1:06 seconds in the video.

    2. Re:The Register also has the story. by martin-boundary · · Score: 4, Funny

      it occurs between 1:05 and 1:06 seconds in the video.

      Which half of 1:05? I don't want to waste my time!

  5. One Second Boot? by WrongSizeGlass · · Score: 4, Funny

    It must have been his first time.

  6. Misleading summary by cualexander · · Score: 5, Insightful

    This is a linux computer in a car that has very specific hardware and limited functionality. Wake me up when you can get a true desktop machine to boot in 1 second and then we can talk. This is like saying, "My toaster runs linux and it can boot instantly!" Big freaking deal.

    1. Re:Misleading summary by caseih · · Score: 5, Insightful

      Actually it is a pretty big deal. In most embedded systems that need to be instant on, a manufacturer would likely use highly customized code with highly customized hardware. The big deal here is that a (relatively) full linux kernel and system boots in the same time as all that custom code giving a manufacturer a solid, generic, and cheap base to work from. In other words, rather than having to rely on highly customized, specific firmware for the device, a more generic linux-based system platform can be used. This makes everything cheaper and thus must more profitable. This is proof that Linux is flexible and agile enough to be used from the smallest devices all the way up the line. Same kernel-level APIs everywhere. Same tools. A tremendous advantage for embedded device makers rushing to get to market.

  7. But by DuChamp+Fitz · · Score: 4, Funny

    does it run crysis?

  8. Ok... I'll take it by Foredecker · · Score: 5, Informative

    Ok, so that is interesting, but only just... This isnt desktop Linux so Im not sure why you are saying "eat that".

    The OS is DMAed directly into system memory. Ok, thats kind of spiffy. That means its been "pre-loaded" which is already located.

    Let me put this in perspective. Back in the mid 90s I worked at AMD. On the ÉlanSC520 system on a chip (133mhz 486 class):

    • Booting of Windows CE, QNX, Psos, VXworks and other real time operating systems to a running state (like these guys) was measured in 100s of milliseconds.
    • Even better, the SC520 supported Execute in Place (XIP) - FLASH was directly conntected and had a controlerl off the CPUs cache - it was fast. This let the OS and applicatoins run right out of flash from reset - no "booting" at all. Systems could easily initialize in 10s of MS and be fully running - with graphics in a few 100ms. This included a running network stack. Pretty spiffy for the old school.
    • There was a company that was doing this with an early version of Linux back then too. Their company name started with an R - but I cannot remember the rest. I think someone bought them. This was fast too.

    So, this really isnt that spectacular - cool yes, ground breaking no.

    -Foredecker

    --
    Jibe!
    1. Re:Ok... I'll take it by Anonymous Coward · · Score: 3, Funny

      Isn't this what Commodore Business Machines were doing back in the 70's? Will everyone ever catch up with their remarkable technology? Not only instant OS but alternative instant OS's by plugging in a new cartridge. Awesome even at 1MHZ.

  9. Re:Sense? by fuzzyfuzzyfungus · · Score: 4, Interesting

    Embedded systems, I suspect.

    For servers and a fair few desktops, uptime is a virtue. They are rarely or never voluntarily shut down. For that reason, boot time isn't a huge issue(particuarly for servers, you are probably going to spend more time twiddling your thumbs while some RAID card spins up the drives and meditates upon infinity than you are actually booting your OS).

    For laptops, suspend(ie. with RAM still live) is almost always the right thing to do(if the ACPI gods are with you and everything is likely to come out of suspend cleanly) because laptops almost always have at least a bit of power available. Only when the system is unplugged and the battery virtually dead do you need to bother hibernating to disk or shutting down. Again, boot time not a huge deal, though likely to be faster than either of the first two cases, because the hardware is more predictable and there are fewer disks to worry about.

    Embedded stuff, though, particularly embedded stuff in certain consumer electronics, or in hostile, low-power environments, really needs to be able to wake up fast. When joe user turns on his digicam, he wants it to come up now, and he doesn't want it flattening its batteries keeping an image alive in RAM. When some minimalist sensor node with only a solar cell and a trickle-charged capacitor for company needs to wake up and transmit some data back to the mothership, it needs to spend as little energy as possible on booting, and as much as possible on sensing and transmitting.

    Since Montavista is mostly known for embedded stuff, I assume that this is why they care.

  10. Perverting the context much, Timothy? by macraig · · Score: 5, Insightful

    Where's the very relevant word embedded in the Slashdot title? Even TFA's author was honest enough to include it in the original title.

  11. Boot times by fm6 · · Score: 3, Informative

    I just bought a cheap digital TV that takes almost 5 seconds to boot. Sad.

  12. Re:I use Linux by biryokumaru · · Score: 3, Funny

    That's not the same kind of POST.

    --
    When you're afraid to download music illegally in your own home, then the terrorists have won!
  13. Why not do this for desktop OSs? by bertok · · Score: 4, Interesting

    What I've never quite understood is why most operating systems boot every time like it's the first time. If you look at most operating systems, they run a bunch of scripts, initialize a bunch of things, thrash the hard drive with random read and/or write patterns, and end up.. at exactly the same state every time. Why not just capture that state, and restore it?

    If you think about it, the only differences between typical boots are:

    - The date & time
    - The type of boot (hibernation or cold boot)
    - Some USB type devices that may have been plugged in or unplugged
    - Minor logging events ('successful boot', 'need an fsck/chkdsk', etc...)

    Really, all of that work can be done in milliseconds, not minutes. Operating systems should just read the ~100MB "ready for use" image from a nice contiguous section of the disk, write it straight into memory, and then do a quick sanity check for changed hardware.

    A typical desktop SATA drive can read at 50MB/sec sequentially, so this should take, what, 2 seconds at most? On a good SSD, it should be 500ms!

    I have a high-end laptop with a good SSD, and it still takes 46 seconds to go form "pressed the power button" to "logged on and usable" with Windows 7, and I suspect it wouldn't be much better with Linux.

    The CPU utilization of typical machine booting in a VM with a very fast disk or SSD behind it is interesting to watch. It takes several seconds of 100% CPU time to boot either Windows or Linux. If you think about it, there's no useful computation that the OS can possibly be doing before it's booted. That's 100% wasted time.

    1. Re:Why not do this for desktop OSs? by pmontra · · Score: 3, Interesting

      Don't know on other OSes but hibernate on Linux stores all the RAM on disk. I've got 4 GB of RAM and restoring them takes about the same time as booting (some 35-40s to login), getting through Gnome/Nautilus startup (so slow) and restarting the apps I need. The real boot time to a useful desktop is about three minutes. Hibernate is not faster than that and a shutdown is much faster than writing those 4 GB to disk. Furthermore hibernate doesn't work well on my laptop. I think it's the video driver not restoring the video card state correctly (the radeon open source driver).

    2. Re:Why not do this for desktop OSs? by evilviper · · Score: 3, Informative

      What I've never quite understood is why most operating systems boot every time like it's the first time.

      Because you told it to do so. If you didn't want it to reboot, you should have suspended or hibernated the system instead.

      Really, all of that work can be done in milliseconds, not minutes. Operating systems should just read the ~100MB "ready for use" image from a nice contiguous section of the disk, write it straight into memory, and then do a quick sanity check for changed hardware.

      You've reinvented Hibernate mode, with it's existing limitations, and more mistakes you've added... Anyone who's used hibernate know it mostly works, but some devices need to be more fully initialized (like your video card) and starting to use it when it's in a different state than it last was, is a sure recipe for disaster. Despite claims to the contrary, I'd say S3 Suspend is easier to get working CORRECTLY, than Hibernate, and with power requirements less indistinguishable from the "off" load, and boot times of <2 seconds, S3 is far better all around.

      I continue to use this old PC (Socket-A MSI Mobo) as my desktop because S3 Suspend mode works (almost) perfectly with FreeBSD-6.x. The ability sit down at my PC, hit the power button, and have all my apps open where I left them (not just the minimal OS up and running) is incredibly valuable. It's a real shame so few people have had the opportunity to experience it. In addition, it's great to be able to just get up and walk away from my computer at any time, for any reason without giving it a second thought... because in 10 minutes it'll be using no power, and when I come back, it'll be right where I left it. Never mind the implications for a UPS-powered system, like a system left right where it was when you last used it, which can be powered from the smallest battery for hundreds of hours, easily.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  14. Re:Link is dead already by Yvan256 · · Score: 5, Funny

    Way to spoil the ending of the new Zelda game.

  15. Re:Specialized platform... by marcansoft · · Score: 4, Interesting

    Yup, 1-second embedded boot is fairly is fairly nice but the summary is misleading and this is not even remotely comparable to desktop boot times. They're using an initramfs, no real filesystem, and no real distribution.

    To put things into perspective, I have an OMAP3530 platform in front of me (same as TFA, funny coincidence) and a totally vanilla kernel that I compiled a few days ago boots in 2.5 seconds, not counting the long time wasted by the totally suboptimal bootloader (3-second deliberate boot delay, networking support, loading the kernel from an SD card, all that crap). That time includes mounting an ext3 filesystem from an SD card and starting to run init from it, and the kernel has built-in drivers for all onboard hardware including USB host+OTG, Ethernet, networking (ipv4 and ipv6), HDMI display output, audio, etc. Of course, booting the rest of the (real, full-blown) distro up takes a while as usual, but TFA is basically showing an embedded application that could be as simple as a single binary running from initramfs (I've actually poked a MontaVista Linux system once, and their startup was basically a single shell script - not quite SysV Init!). Remove the sd/ext3 stuff, remove useless drivers, replace the bootloader with a minimal build, use a busybox shell script + a single executable binary for the actual application, and you're probably getting close to 2-second total boot times without even beginning to optimize stuff with DMA and the like.

  16. Already done faster... by Anonymous Coward · · Score: 3, Informative

    This is nothing really new. In fact, they boot slower on a faster processor than earlier acheivments. This is mostly an ad for MontaVista.

    See http://elinux.org/Main_Page for a lot more information om bootup.

    I think the record is about 200ms by Sony.

  17. Re:Take that! by hairyfeet · · Score: 4, Funny

    Now where did I hear something like that? Oh yeah here. Funny how every thread here on /. has at least one section where this would fit.

    --
    ACs don't waste your time replying, your posts are never seen by me.