Google Sponsors the LinuxBIOS project
Rockgod noted that "The LinuxBIOS project aims to take down the last barrier in Open Source systems by providing a free firmware (BIOS) implementation. LinuxBIOS celebrates its Sixth anniversary this year, and has an installed base of over 1 million LinuxBIOS systems. With the One Laptop Per Child (OLPC) project, that number is expected to exceed 10 million users in 2007. LinuxBIOS supports 65 mainboards from 31 vendors in v1 and another 56 mainboards from 27 vendors in v2"
Why would a major manufacturer of motheboards want to stay away from Linux for BIOS?
What do Award and Phoenix have better than Linux?
Help end the use of Sigs. Tomorrow
uh.. EFI & TianoCore ?
mod me funny
If a company is selling mobos with these on it, now is the time to speak up. It strikes as this will be free advertisement. If not, this might be the time to start selling.
I prefer the "u" in honour as it seems to be missing these days.
1) Given that yesterday's news was that OLPC managed to produce a whole 10 computers, and that we're now halfway through November 2006 -- yeah, I can't see how they could possibly fail to hit 10 million in 2007!
2) Has Googlefawning now hit the point where it's no longer necessary for Google or the Slashdot story to explain exactly what it is that "Google sponsors" means? (Apparently they paid for a build system. Take that, Gates Foundation!)
What I'm listening to now on Pandora...
I have seen this mentioned every so often here, and I am interested in trying it out. But, the stuff I read blurs the line between what I think of as BIOS functions and the actual OS. So, I am not sure if it's worth trying out or not.
Does anyone have pointers to good information, or experience themselves? The kind of questions I have are:
- Do I still have the configuration capabilities that you expect in a Phoenix/Award BIOS? En/Dis-able integrated devices, Fan Control, ACPI en/dis-able, etc.
- The articles all say that LinuxBIOS boots a linux kernel very quickly. Is this into a limited BIOS setup environment, or is this the actual kernel for the Operating System that you're running? If it's the latter, don't kernel upgrades become more difficult/dangerous? (Are there any docs which go through the system bootstrap process step by step?)
- Is AMD64 (in 64 bit mode) supported?
- Beyond the Linux hobbyist incentive to try out new things, are there any other major advantages to using LinuxBIOS on my home Linux server (which is a supported board)? Do I lose anything my current Award BIOS offers?
Actually, I think of it in almost the opposite way... Why isn't the base OS kernel sitting on an eeprom on the MoBo talking directly to hardware and thereby completely obviating BIOS? I remember back on my Atari ST, they had a 512k ROM that had GEM/GEMDOS in it. If I didn't pop a floppy into the drive, the system still booted to a desktop using the ROM image. If I did pop a floppy into the drive, then the OS loaded off the floppy. The main point being that all interfacing to basic hardware on the ST was handled by the OS itself. There was no BIOS. I remember being very confused by this when I moved to the PC. I turned it on expecting to get a Windows 3.1 desktop that I could then use to format the HD and install the OS with, or as a second best option, a DOS prompt that would allow me to format/partition/install the OS. I remember when I turned it on and all I got was a "NO ROM BASIC" error, I called the store and complained that they'd sold me a damaged system and the OS seemed to be missing from the motherboard. I was incredulous when they told me that I actually needed to boot an OS from a floppy. That seemed so backwards based on where I was coming from.
Fast forward 12 years and here I am a big *nix head and everything... I can chuckle about my misconceptions to an extent. But I STILL to this day believe that the OS kernel should talk to and provide low level support for the MOBO components. Yeah, it would make the OS more complex, but I think it would also allow great flexibility and longer life to a system since many of it's functions would be in software with fewer limitations imposed by BIOS.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
A customizable BIOS with the Kernel in flash would be the proper place to setup user authentication, software harddisk encryption, firewall rules and VPNs. If supported by the kernel (AFAIK OpenBSD has such a feature; don't know about Linux), you could switch the OS into a secure mode after boot up and initialization where it is no longer possible to change certain settings before you even access the harddrive.
....." banner on startup and some epoxy over the bios flash rom ...
It's basically as close as you can get to "tamper-proof" by a software-only approach and for notebooks, it would provide some reasonable theft protection, esp. if combined with a "this notebook is the property of
The SPARC processor has (nearly) always been "open" for the 1990+/-5 definition of "open". Its design is managed by SPARC International, which besides Sun includes TI, Cypress Semiconductor, and Fujitsu.
But anyway...
The processor of a system is. Being "open" to change doesn't really get you anything. If you have enough money to do a production run of a modern CPU, then the costs of buying into SPARC International, or the reference design of MIPS, or an IBM POWER, etc, etc, is nothing. Getting a custom chip is more then just sitting around and thinking. BIOS is software. Writing a better BIOS is a matter of sitting around and thinking. (Well you see what I'm getting at here..) Getting a custom chip produced is not feasible for anyone but the most rich geeks, beyond the time sitting down with Verilog. Getting a custom BIOS, beyond sitting down in an IDE, is trivial.
Operating systems tend to ignore things which the BIOS tells them because they are not reliable. It's a lot easier and more robust to have the OS detect disks and memory than the BIOS.
So it takes the BIOS quite a lot of time to do something which isn't used anyways.
I'll give you an answer, from my point of view.
:p
:)
Have you ever used Solaris? On Sun Hardware? It's great to able to send the OS a 'break', and get an OK> prompt, where you can configure low-level stuff. It's one of the things that makes me love Sun+Solaris way more than I love linux.
Even better would be if we could have a standard co-processor-thingie listening on the serial port, like on SUN, where "lights-out-management" could be done. I really like that feature of Sun hardware too
HP's ILO and Dell's DRAC really doesn't cut the muster compared to Sun's LOM/ALOM/whatever-they-call-it-today
Of course the last two paragraphs can't be addressed by linuxbios, but the first one can. It's one of those things I really, really miss in Linux.
"Rune Kristian Viken" - http://www.nwo.no - arca
"Hardware" doesn't have "source code", so long as the software is open source, that would be removing all the barriers to "open source" systems.
It wouldn't be the last barrier to "open" systems, which would require some analogus open regime for hardware, but it wouldn't be "open source".