Slashdot Mirror
LinuxBIOS Gains Steam
solferino writes: "LinuxJournal has a good overview article about linuxBIOS and where it's currently at (hint : moving like a sleek penguin under arctic ice). Why linuxBIOS? To quote from the article "Currently two different interest groups are working on LinuxBIOS: one working on embedded systems and one building large-scale computer clusters. For these applications the legacy x86 firmware is suboptimal." Yes, this was a slashdot story in March this year but this article is relevant for updating the project status and for providing indepth information."
I quite like OpenFirmware, but have yet to see a x86 PC motherboard which uses it - PPC ones do, of course. The specification standard includes support for x86 computers, but the mobo manufacturers have deals with the BIOS producers (if they're not already the same company), and the BIOS producers have deals with MS, which means they've had financial incentives for years for keeping the BIOS in the dark ages of DOS.
Most current BIOSes are extremely biased toward DOS and DOS-derivatives like windows 95 - they're pretty ill suited to even Windows 2000, I'm sure microsoft now would prefer them to be replaced too (but with something that still ties you to MS, of course - no doubt MS will be prodding at x86 BIOS manufacturers to get this).
At the same time, perhaps what's needed is a open standard for the provision of a wodge of on-mobo flash-ram - the main reason people want to replace the BIOS with linux, so that the OS loads in a blink of an eye, perhaps without even requiring a HD. It's just silly that the BIOS spends a good while screwing around in Real Mode when Linux (or newer versions of Windows!) just go back and do all the setup again...
I thik it's be REALLY nice to have an OpenFirmware-type BIOS on x86, but with a few megs of flash on the motherboard that one could load the OS kernel and perhaps an initrd from, instead of having to mess about with the harddrive.
Choice of masters is not freedom.
The BIOS should be a generic facility that can load any desired operating system.
That is a desirable goal. Linux was chosen first because that was what the developer needed (meeting personal or professional need is the start of most Free software projects). Secondly, Windows is much more difficult since it is quite dependant on the legacy BIOS calls at startup while Linux is not.
The upshot is that if you can load the linux image into ram and jump to it, it will boot. With windows, you'd have to re-implement a good bit of the original BIOS.
Currently, LinuxBIOS just needs an ELF formatted binary image to load and execute. If you'd care to write a second stage that implements all of the necessary BIOS calls and boots Windows, feel free. There are a few people on the developer's list that would love to see that.
As a side note, it doesn't look like it would be all that hard to get *BSD or The HURD booting from LinuxBIOS.
Anyway, why an embedded device would want to use x86 hardware is beyond me...
because it's incredibly cheap maybe, with a mind boggling array of useful peripheral hardwares?
The aim of LinuxBIOS doesn't even remotely touch on some competitive manuevering as you ignorantly suggest.
Installing a LinuxBIOS ROM in place of normal DOS compatible microcode is something you do to modify I>commodity off the shelf hardware hardware to -for example- make your appliance system boot Linux to multiuser + network runlevel from a cold start in 3 seconds or less. It is a very specialized aftermarket improvement for hardware integrators - not motherboard OEMs or PC sellers- and has nothing whatever to do with the kinds of exclusionary practices Microsoft is famous for. It is not practical for general use PC system design, since kernel upgrades mean plugging in a new ROM or reprogramming the old one in a special ROM burner. It is for dedicated appliances only.
In short, Anonymous Coward, if you can't comment intelligently, and without smallminded paranoia, you may want to forgo commenting at all.
Johnny Quest has two Daddies.