I think, but I'm not sure, it means that you can boot up your computer *really* fast. As in, *BOOP* .... you're in! Also, they managed to fit an entire operating system on the motherboard without needing a hard drive. So that means if your hard drive gets borked (a la click of death), you can still use your computer without special bootup disks.
@insomniac the flash you're talking about is something like an order of magnitude slower than modern hard drives. there have been recent attempts to make realistic solid state hard drives, working at the same or better speed as a hard disk, but they work in something like the raid 0 fashion, spanning the data across several blocks of flash, making the perceived speed to be (flash speed)/(number of blocks). if the drive has 100 blocks, it would be 100 times faster than the flash speed (as long as the best scenario criteria are met).@smellinator booting doesn't take much time at all. if your system was booting dos instead of windows or osx, you would be at a command prompt 10 or 15 seconds after you hit the power button, as long as you don't have some kind of mass storage device that scans the bus for 3 minutes or something. what makes things like windows and linux slow to be ready is the loading of all the drivers, and pulling all the crap off the hard drive that has to be loaded into memory. using windows as an example, the best boot time will be if you use the hibernation method. that dumps memory to a file on your hard drive when you shut down, and reads the file back to memory when you start up.the limiting factor there is the amount of ram you have, and how much of it needed to be dumped. reading it back could taker anywhere from a few seconds to a minute, depending on your hard drive and fragmentation.i always thought that hibernation systems should have a partition dedicated to memory dumps. then you would never have fragmentation issues, and the possibility of you not having enough space left on the drive is nulled.
"I like the idea of a non operating specific open bios implementation such as www.openbios.info."Well then you'll _love_ LinuxBIOS, as it is probably the most far along open BIOS implementation; it's only called LinuxBIOS for "marketing purposes" and relation to the uClinux project, it can boot Windows and *BSDs just fine."Linux bios just seems like a gimmick who wants their most critical part of there computer crashing?"Your BIOS isn't more likely to "crash" than any other BIOS; LinuxBIOS code may be unstable now, but for certain platforms it's already rock steady. Secondly, after it's flashed on the chip, it's doubtful you'll even know its there. Unless you're a hardware hacker or a computer manufacturer, you're likely not going to be one of the ones to load this on your board, and thusly you shouldn't worry about it. The good news is, it's completely transparent; you /can/ go grab the code, compile it, burn it. But you're not required to. "and no I don't think linux is bad in anyway its just that 100% of bios code is audited the linux kernel umm well barely is."And if you have ever worked at, or know anyone who works at a BIOS company, you will laugh at that assumption. Why do you think these manufacturer's release updates to their BIOSes? That's right: bugs. They're everywhere, even in tiny Flash ROMs. And for some reason, they're so much nastier in little Flash ROMs, so it's likely they're caught much earlier in the development cycle. This is true no matter who's developing it (unless they're a 16 year old or something), especially the LinuxBIOS team, where you've got hundreds of eyes pouring over the code instead of a small team.
this plus a wget client to pull stuff for a web server into a ram drive, and ram /var, would allow it to become a very nice web server. A nice DB server that doubles as the content serving drive for all web servers, and you could have a nice simple HA site.
Can anyone remember the Commodore 64? It did not require a lot of time to turn on. I once had a Tandy IBM compatible computer that would boot from rom also. It also did not take long to boot but one could not upgrade the operating system on rom so one eventually had to boot from the hard drive. I am really not that interested in how long it takes to boot but I am interested in being able to boot after the hard drive fails. It would be nice to be able to boot with cd support so that one could run programs to repair the hard drive. It would also be nice to have a backup program where if the hard drive fails it would boot and restore from the dvd to a new hard drive and be back to the point where one was before the hard drive failed.
boot faster, remove reliance on closed companies, help standardize the BIOS world, support the open source culture, learn something, and add more features (you never know what you get in a world not geared towards Windows)You ask whether you'll need anything special to get RAID work, but you forget that Linux does raid all by itself. Bios (a.k.a. fake) RAID was invented to bring cheap RAID systems to the Microsoft masses!But to answer your question on RAID, most probably not. As the BIOS technically contains a full linux kernel, it is capable of doing almost anything (including RAID).Not having a jab at you, just think outside the box....
@RicktheBrick:You're actually describing the last version Ghost for DOS (6.2 or something like that). Once you create the first bootable CD/DVD you can then boot off it and tell it you want to create a new image from whole HDD or partition and save it to CD/DVD. It then makes your new blank disc bootable and burns the image for you. You could keep doing that in perpetuity. Which I've been doing since that version was released several years ago. Don't bother with the new ghost for Windows; it's not the same (No option to burn to CD while booted from a CD). Also it supports all popular file systems (including Ext2). I have used this several times to ghost a failing HDD (as reported by SMART) and restore the image to a new HDD. Works perfectly.
@raid517Nice.. doucebag of the day award. @geminitojanusSure theres bugs but there is auditing I mean come on the linux kernel has had *many* race conditions fixed in the past... hmm race conditon on a BIOS. Yes I do know LinuxBIOS can boot windows, etc I still dont think a non mission critical operating system should be on a critical piece of hardware
"If the design objective of the system was to "minimize the time between pressing the on button and being able to do productive work" then there'd be a better design and the boot time would be similar to my toaster's boot time. Instead, the design objective seems to be "be cautious and explore any possible configuration change"."No, the boot time would still be fairly slow. When humans boot, they already have in memory everything that was there before. When computers boot, they've got to reinitialize _everything_, restoring states to where they were before they were shutdown (and hoping those states are defined). The design isn't "be cautious", it's "do this or don't boot". You can't just turn on a piece of hardware and say "whelp, time to go to work, here's some instructions", you absolutely _MUST_ set up at least the registers so the hardware has a state to receive said instructions and start processing. This takes time, especially as hardware complexity increases and you have more and more registers and states to check and restore.The boot system also largely ignores configuration changes. For example: when booting Linux, the "hotplug" manager included in most more recent distributions will enumerate the system bus and see what hardware is there. For hardware that's known to be working and previously configured, it loads the generic profile built for that hardware (modprobe hardware-name usually does it). If it's not already enumerated, it journals this and sleeps on it. When it's got some (cpu) time later, it explores how to configure this hardware, and installs the corresponding modules accordingly. Can you skip this? Sure, if you want none of your hardware to work. You could also write scripts to automatically load the hardware you want manually, which is marginally faster, but is not flexible to adding/removing hardware [anyone using Debian pre-2000 knows this pain, manually writing out which modules to load on boot is a pain in the ass]. You can take this a step further and build a custom kernel that already has these drivers built in, instead of being modular. This gives you another marginal speedup (though bigger than editing your module config), but with the significant trade-off of now having to manage your own kernel (patches, upgrades, changes in hardware, etc).So, you've managed to cut down your boot time from 1:30 to about 1:10 (maybe). Now you start cutting out user space daemons, as they're the biggest waster of time on boot. Things like DHCP config, gone. That means manually setting your own IP configurations. Avahi/mDNS autodiscovery are also out, which means configuring your own printers and other shared intranet services. SSHD is out so no remoting in to your computer. The list goes on and on. You're down to 40 seconds. You've still gotta load X (unless you want to do that by yourself too), which still requires setting up a very complex beast, which takes a long time. You really _can't_ bypass this, no matter how much you want to. What's taking so long? You're hardware bound; your hard drive simply can't move any faster to get the data into RAM any faster. Even your ultrafast 15000 RPM (30-8 useconds seek time) hard disks can't keep up with even the most lowly, cheap Flash module (~30 nanoseconds random access, 3-4 orders of magnitude faster). Oh, and lastly, you _can_ boot to minimal configuration, if you want. Just don't expect _any_ distribution to take you seriously; rebooting in Linux is a sufficiently rare enough event that more people prioritize fixing the start up times of programs once you're booted, as that's really the productivity killer (I can't tell you how many _hours_ I've wasted waiting for SMB volumes to come available, or for Nautilus to draw a window containing a few thousand documents (whitesheets), or waiting for web pages to finish rendering, especially those damned sites covered in Flash which can slow even the most modern browsers to a crawl).
@geminitojanus:Like a lot of engineer-types, you are missing the forest for the trees. No disrespect intended. You just gave a thousand reasons why it can't be done, and then in your last paragraph, said it could sort-of be done. You need to think outside the box.I have absolutely no doubt that if a "system" (hardware+firmware+software) were designed FROM THE GROUND UP with the objective of "fast boot" being the norm, it would be done. Hibernate SHOWS that it can be done. You make a point that they have to re-initialize *everything*. Two questions: Why (really, why.... and don't give a technical answer as to why it is done this way now), and why can that not be instantaneous? Try not to fall into the trap of saying "because that's how it is now." ... I KNOW that's how it is now. You have said that in each of your posts. I KNOW that. I'm saying that it absolutely positively does NOT HAVE to be that way.If every component (from hardware to firmware to system software to application software) were designed so that "power on" state WAS a working / productive state, then when the system received power, you'd be able to work. Period. It's that "simple". But since Processor vendors and Board vendors, and Disk Vendors, and PC vendors and OS designers are all in their own little silos, this won't happen anytime soon.A minute boot-up time is ridiculous. I *have* systems that boot in a fraction of a second. There are models to learn from in the market already (whether you look at a calculator or an old microcomputer - heathkit 3400 or something). Just because you add complexity doesn't mean you need to add boot time - and engineers who think so just aren't very creative in their solutions! Cell phones and DVR's are other examples which have extremes - some are rapid boots, others are seconds or even a minute long. Just take the DVR - there's no reason in the world a DVR can't be nearly instant boot. After all, VCR's could do it, years before. If you built a single-function DVR (meaning it wasn't really just dvr software on top of linux, like a lot of them are), you could have something like a VCR which boots instantly. But noooooooo - many DVR builders are building on top of other platforms (for other reasons, like time-to-market). And it's silly. If power goes out, I need to wait for 2 minutes for my DVR to reboot?? That's braindead! So once the market settles down, and time-to-market isn't so important, DVR builders will address this, so that they can differentiate themselves from the competition. But for now, we have to live with the 2-minute boot process right in the middle of your favorite show, when the power goes out.
Closed AccountMar 8, 2007
I think, but I'm not sure, it means that you can boot up your computer *really* fast. As in, *BOOP* .... you're in! Also, they managed to fit an entire operating system on the motherboard without needing a hard drive. So that means if your hard drive gets borked (a la click of death), you can still use your computer without special bootup disks.
crash128Mar 8, 2007
This reminds me of that $100 one laptop per student project (small, affordable, mobile devices that use linux). Boo-yah, long live unix/linux.
dioxideMar 8, 2007
@insomniac the flash you're talking about is something like an order of magnitude slower than modern hard drives. there have been recent attempts to make realistic solid state hard drives, working at the same or better speed as a hard disk, but they work in something like the raid 0 fashion, spanning the data across several blocks of flash, making the perceived speed to be (flash speed)/(number of blocks). if the drive has 100 blocks, it would be 100 times faster than the flash speed (as long as the best scenario criteria are met).@smellinator booting doesn't take much time at all. if your system was booting dos instead of windows or osx, you would be at a command prompt 10 or 15 seconds after you hit the power button, as long as you don't have some kind of mass storage device that scans the bus for 3 minutes or something. what makes things like windows and linux slow to be ready is the loading of all the drivers, and pulling all the crap off the hard drive that has to be loaded into memory. using windows as an example, the best boot time will be if you use the hibernation method. that dumps memory to a file on your hard drive when you shut down, and reads the file back to memory when you start up.the limiting factor there is the amount of ram you have, and how much of it needed to be dumped. reading it back could taker anywhere from a few seconds to a minute, depending on your hard drive and fragmentation.i always thought that hibernation systems should have a partition dedicated to memory dumps. then you would never have fragmentation issues, and the possibility of you not having enough space left on the drive is nulled.
geminitojanusMar 8, 2007
"I like the idea of a non operating specific open bios implementation such as www.openbios.info."Well then you'll _love_ LinuxBIOS, as it is probably the most far along open BIOS implementation; it's only called LinuxBIOS for "marketing purposes" and relation to the uClinux project, it can boot Windows and *BSDs just fine."Linux bios just seems like a gimmick who wants their most critical part of there computer crashing?"Your BIOS isn't more likely to "crash" than any other BIOS; LinuxBIOS code may be unstable now, but for certain platforms it's already rock steady. Secondly, after it's flashed on the chip, it's doubtful you'll even know its there. Unless you're a hardware hacker or a computer manufacturer, you're likely not going to be one of the ones to load this on your board, and thusly you shouldn't worry about it. The good news is, it's completely transparent; you /can/ go grab the code, compile it, burn it. But you're not required to. "and no I don't think linux is bad in anyway its just that 100% of bios code is audited the linux kernel umm well barely is."And if you have ever worked at, or know anyone who works at a BIOS company, you will laugh at that assumption. Why do you think these manufacturer's release updates to their BIOSes? That's right: bugs. They're everywhere, even in tiny Flash ROMs. And for some reason, they're so much nastier in little Flash ROMs, so it's likely they're caught much earlier in the development cycle. This is true no matter who's developing it (unless they're a 16 year old or something), especially the LinuxBIOS team, where you've got hundreds of eyes pouring over the code instead of a small team.
cvncpuMar 8, 2007
this plus a wget client to pull stuff for a web server into a ram drive, and ram /var, would allow it to become a very nice web server. A nice DB server that doubles as the content serving drive for all web servers, and you could have a nice simple HA site.
rickthebrickMar 8, 2007
Can anyone remember the Commodore 64? It did not require a lot of time to turn on. I once had a Tandy IBM compatible computer that would boot from rom also. It also did not take long to boot but one could not upgrade the operating system on rom so one eventually had to boot from the hard drive. I am really not that interested in how long it takes to boot but I am interested in being able to boot after the hard drive fails. It would be nice to be able to boot with cd support so that one could run programs to repair the hard drive. It would also be nice to have a backup program where if the hard drive fails it would boot and restore from the dvd to a new hard drive and be back to the point where one was before the hard drive failed.
xanium4332Mar 8, 2007
boot faster, remove reliance on closed companies, help standardize the BIOS world, support the open source culture, learn something, and add more features (you never know what you get in a world not geared towards Windows)You ask whether you'll need anything special to get RAID work, but you forget that Linux does raid all by itself. Bios (a.k.a. fake) RAID was invented to bring cheap RAID systems to the Microsoft masses!But to answer your question on RAID, most probably not. As the BIOS technically contains a full linux kernel, it is capable of doing almost anything (including RAID).Not having a jab at you, just think outside the box....
subassyMar 8, 2007
@RicktheBrick:You're actually describing the last version Ghost for DOS (6.2 or something like that). Once you create the first bootable CD/DVD you can then boot off it and tell it you want to create a new image from whole HDD or partition and save it to CD/DVD. It then makes your new blank disc bootable and burns the image for you. You could keep doing that in perpetuity. Which I've been doing since that version was released several years ago. Don't bother with the new ghost for Windows; it's not the same (No option to burn to CD while booted from a CD). Also it supports all popular file systems (including Ext2). I have used this several times to ghost a failing HDD (as reported by SMART) and restore the image to a new HDD. Works perfectly.
nmcsweenMar 8, 2007
@raid517Nice.. doucebag of the day award. @geminitojanusSure theres bugs but there is auditing I mean come on the linux kernel has had *many* race conditions fixed in the past... hmm race conditon on a BIOS. Yes I do know LinuxBIOS can boot windows, etc I still dont think a non mission critical operating system should be on a critical piece of hardware
geminitojanusMar 10, 2007
"If the design objective of the system was to "minimize the time between pressing the on button and being able to do productive work" then there'd be a better design and the boot time would be similar to my toaster's boot time. Instead, the design objective seems to be "be cautious and explore any possible configuration change"."No, the boot time would still be fairly slow. When humans boot, they already have in memory everything that was there before. When computers boot, they've got to reinitialize _everything_, restoring states to where they were before they were shutdown (and hoping those states are defined). The design isn't "be cautious", it's "do this or don't boot". You can't just turn on a piece of hardware and say "whelp, time to go to work, here's some instructions", you absolutely _MUST_ set up at least the registers so the hardware has a state to receive said instructions and start processing. This takes time, especially as hardware complexity increases and you have more and more registers and states to check and restore.The boot system also largely ignores configuration changes. For example: when booting Linux, the "hotplug" manager included in most more recent distributions will enumerate the system bus and see what hardware is there. For hardware that's known to be working and previously configured, it loads the generic profile built for that hardware (modprobe hardware-name usually does it). If it's not already enumerated, it journals this and sleeps on it. When it's got some (cpu) time later, it explores how to configure this hardware, and installs the corresponding modules accordingly. Can you skip this? Sure, if you want none of your hardware to work. You could also write scripts to automatically load the hardware you want manually, which is marginally faster, but is not flexible to adding/removing hardware [anyone using Debian pre-2000 knows this pain, manually writing out which modules to load on boot is a pain in the ass]. You can take this a step further and build a custom kernel that already has these drivers built in, instead of being modular. This gives you another marginal speedup (though bigger than editing your module config), but with the significant trade-off of now having to manage your own kernel (patches, upgrades, changes in hardware, etc).So, you've managed to cut down your boot time from 1:30 to about 1:10 (maybe). Now you start cutting out user space daemons, as they're the biggest waster of time on boot. Things like DHCP config, gone. That means manually setting your own IP configurations. Avahi/mDNS autodiscovery are also out, which means configuring your own printers and other shared intranet services. SSHD is out so no remoting in to your computer. The list goes on and on. You're down to 40 seconds. You've still gotta load X (unless you want to do that by yourself too), which still requires setting up a very complex beast, which takes a long time. You really _can't_ bypass this, no matter how much you want to. What's taking so long? You're hardware bound; your hard drive simply can't move any faster to get the data into RAM any faster. Even your ultrafast 15000 RPM (30-8 useconds seek time) hard disks can't keep up with even the most lowly, cheap Flash module (~30 nanoseconds random access, 3-4 orders of magnitude faster). Oh, and lastly, you _can_ boot to minimal configuration, if you want. Just don't expect _any_ distribution to take you seriously; rebooting in Linux is a sufficiently rare enough event that more people prioritize fixing the start up times of programs once you're booted, as that's really the productivity killer (I can't tell you how many _hours_ I've wasted waiting for SMB volumes to come available, or for Nautilus to draw a window containing a few thousand documents (whitesheets), or waiting for web pages to finish rendering, especially those damned sites covered in Flash which can slow even the most modern browsers to a crawl).
smellinatorMar 11, 2007
@geminitojanus:Like a lot of engineer-types, you are missing the forest for the trees. No disrespect intended. You just gave a thousand reasons why it can't be done, and then in your last paragraph, said it could sort-of be done. You need to think outside the box.I have absolutely no doubt that if a "system" (hardware+firmware+software) were designed FROM THE GROUND UP with the objective of "fast boot" being the norm, it would be done. Hibernate SHOWS that it can be done. You make a point that they have to re-initialize *everything*. Two questions: Why (really, why.... and don't give a technical answer as to why it is done this way now), and why can that not be instantaneous? Try not to fall into the trap of saying "because that's how it is now." ... I KNOW that's how it is now. You have said that in each of your posts. I KNOW that. I'm saying that it absolutely positively does NOT HAVE to be that way.If every component (from hardware to firmware to system software to application software) were designed so that "power on" state WAS a working / productive state, then when the system received power, you'd be able to work. Period. It's that "simple". But since Processor vendors and Board vendors, and Disk Vendors, and PC vendors and OS designers are all in their own little silos, this won't happen anytime soon.A minute boot-up time is ridiculous. I *have* systems that boot in a fraction of a second. There are models to learn from in the market already (whether you look at a calculator or an old microcomputer - heathkit 3400 or something). Just because you add complexity doesn't mean you need to add boot time - and engineers who think so just aren't very creative in their solutions! Cell phones and DVR's are other examples which have extremes - some are rapid boots, others are seconds or even a minute long. Just take the DVR - there's no reason in the world a DVR can't be nearly instant boot. After all, VCR's could do it, years before. If you built a single-function DVR (meaning it wasn't really just dvr software on top of linux, like a lot of them are), you could have something like a VCR which boots instantly. But noooooooo - many DVR builders are building on top of other platforms (for other reasons, like time-to-market). And it's silly. If power goes out, I need to wait for 2 minutes for my DVR to reboot?? That's braindead! So once the market settles down, and time-to-market isn't so important, DVR builders will address this, so that they can differentiate themselves from the competition. But for now, we have to live with the 2-minute boot process right in the middle of your favorite show, when the power goes out.