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"

Comments

It's not the last barrier

[ClosedSource]

to Open Source systems since the microprocessor and other PC hardware is not open.

Re:It's not the last barrier

[Anonymous Coward]

Agreed, especially the graphics hardware! But oh, google probably doesn't install graphics cards in their servers.

Re:It's not the last barrier

[McNihil]

So the sparc processor doesn't count?

http://www.sun.com/processors/opensparc/

Enlightened yet?

Re:It's not the last barrier

[ClosedSource]

I can't evaluate the level of openness of opensparc in a few minutes, but in any case, I don't think the fact that one of the minor microprocessor players (in terms of volume) has opened up their design allows one to conclude that an open BIOS is the last barrier to an open system. In fact, Sun wouldn't be opening it up if it thought that the sparc was still a viable player in the marketplace.

Re:It's not the last barrier

[squiggleslash]

They opened up SPARC decades ago, and while they didn't start with a GPL'd reference implementation, they have released a number since.

This is just the way Sun works. It has nothing to do with them deciding whether the architecture is a viable player or not.

Re:It's not the last barrier

[T-Ranger]

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.

Re:It's not the last barrier

[smittyoneeach]

What would be the point of a GPL hardware implementation to the individual user?
Who would have the skill (to say nothing of the fab) to make a change to the hardware, and then distribute it?

Re:It's not the last barrier

[kfg]

Getting a custom chip is more then just sitting around and thinking.

We don't need a custom chip. We need a true commodity chip.

KFG

Re:It's not the last barrier

[McNihil]

That could equally be read as "Linux wouldn't be open if it was a viable player in the market place"

Having it open source is to ensure that it will be available even if the main company dies. How much great closed technology have been lost because of being jousted out of the market place by ignorant consumerism when decades later it resurfaces as if it was the hot-shit du jour?

It is costing us humans a great deal to reinvent things all the time... imagine if we needed to start from scratch now and then where General Relativity/Space exploration is concerned or something like that.

We have only limited resources and we better damn use them efficiently.

Re:It's not the last barrier

[T-Ranger]

What do you mean by "commodity"?

Cheap and ubiquitous? x86(_64) from Intel and AMD (and VIA, and...)
Single design, multiple vendors? SPARC and MIPS

Re:It's not the last barrier

[kfg]

What do you mean by "commodity"?

Anyone who wants to take the trouble can grow a tomato; and just about everybody knows what to do with it once its grown.

Cheap and ubiquitous?

Z80; three bucks retail.

KFG

Re:It's not the last barrier

[Skuld-Chan]

Pegasos is an open system - including the schematics. This is similar architecture the Apple Macintosh used to be based on.

Besides with Linux it doesn't really matter what the architecture is. Linux runs just as well on Sparc, PPC, and X86.

Re:It's not the last barrier

[DragonWriter]

"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".

Re:It's not the last barrier

[TheRaven64]

Getting a chip made with last year or the year before's process is actually surprisingly cheap. You're looking at around the $2000 per chip mark for runs as small as a few tens. Once you get the volume up, the price drops a lot. It won't drop as low as an off-the-shelf chip, but sometimes you pay a price for freedom.

Re:It's not the last barrier

[T-Ranger]

Well, cheap can mean both "very low total numerical price", "good value for your money", and possibly "low screwage from the manufacturer, distributor, retailer".

Intel and AMD processors may not be "very low total numerical price", with the good competition between the two of them, on the low end at least, there is "low screwage". I recall from one of the initial Cyrix marketing blurbs that the cost of manufacturer of the 6x86 processors was around $80/each. This was a decade ago, and they were made in low volume (almost by hand), so lets say that a modern processor built by AMD or Intel costs $45 to make. I think you could get a low end CPU for $90 (or less), 100% edge from cost-of-manufacture to in-the-consumers-hand isn't bad.

If you want "low total numerical price", get a Via "embedded" processor, around $50 for a 1GHZ C3; from 50 - 400x as fast as a the z80 @ 2.4-20MHZ, (ignoring that the z80 is 8bit and the Via 32). In price/MHZ, the Via comes out at ~1/3 of the cost. And a low end AMD or Intel chip still wins out over the Zilog, in price/performance, so "good value for your money" also qualifies.

Re:It's not the last barrier

[ClosedSource]

Actually processors are often implemented using microcode, so some hardware can and does have source code.

In any case, if you exclude the hardware, there is no such thing as an "open source system", only "open source software".

Re:It's not the last barrier

[ClosedSource]

"That could equally be read as "Linux wouldn't be open if it was a viable player in the market place"

Not exactly, but if AT&T had decided way back when that they could make a lot of money selling UNIX, there probably wouldn't be a Linux.

Re:It's not the last barrier

[kfg]

If you want "low total numerical price". . .

I'm not sure you have grasped the point of wanting a chip that anyone can make simply because they desire to do so.

KFG

Re:It's not the last barrier

[DragonWriter]

Actually processors are often implemented using microcode, so some hardware can and does have source code.

Microcode certainly has source code, which is the source code for software included in or with the hardware, but not source code for the hardware itself.

Microcode could be open sourced, but that wouldn't make the hardware itself open source.

In any case, if you exclude the hardware, there is no such thing as an "open source system", only "open source software".

This seems to presuppose that the word "system" cannot refer to things consisting entirely of "software", which is wrong.

A system consisting entirely of software can be open source, and is the only really literal meaning that the phrase "open source system" can have. If hardware designs had open-source-like IP licenses attached, it would be fair to call a system using such hardware an "open system" or, perhaps to be more clear, an "open-licensed system", but the rights to the hardware would not be to free access and modification of source code, so "open source" wouldn't be the right word.

Re:It's not the last barrier

[T-Ranger]

Ah, I see your strategy now. Change your arguments mid-stream. Anyway:

- Anyone with a computer has all that is needed to hack on a BIOS.
- You need tens or hundreds of thousands of dollars to do a production run of a modern processor. If you have that kind of coin kicking around, then you could afford to buy into SPARC International, or the reference MIPS designs. If you want to dick around with toys like a Z80, get yourself a FPGA.

Re:It's not the last barrier

[kfg]

Ah, I see your strategy now. Change your arguments mid-stream.

"Heritage" tomatoes. First, last and always.

You need tens or hundreds of thousands of dollars to do a production run of a modern processor. If you have that kind of coin kicking around, then you could afford to buy into SPARC International, or the reference MIPS designs.

Confirmation that you don't see the point, i.e., not having to buy Monasanto's genetically modified, sterile seed for every planting. Nor am I quite sure how having a million dollars implies that I have two million dollars.

If you want to dick around with toys like a Z80 . . .

I'd get myself a Z80. Three bucks. Retail. But I never said I wanted to dick around with a Z80. Although they're not toys. They're still available, in bulk, because they do perfectly real work, even today. People buy them. Lots of them.

KFG

Re:It's not the last barrier

[ClosedSource]

"Microcode certainly has source code, which is the source code for software included in or with the hardware, but not source code for the hardware itself."

Are you confusing microcode with machine code? Microcode implements the instruction set in a processor, machine code is a program that uses the instruction set. From the outside, microcode is part of the hardware because the processor will not function without it.

I think in the context where hardware is part of the discussion (which it must be for a BIOS to be relevent), it's understood that the word "system" includes software and hardware unless it is explicitly designated as software only.

Re:It's not the last barrier

[cheater512]

This is the last actual code in a computer which doesnt have a open alternative.

Re:It's not the last barrier

[DragonWriter]

Are you confusing microcode with machine code?

No.

Microcode implements the instruction set in a processor,

Typically, microcode (as I understand it) implements a part of the instruction set in a processor, built on a smaller "kernel" of instructions implemented more directly.

From the outside, microcode is part of the hardware because the processor will not function without it.

Sure, when looking at the machine it is part of; from a development perspective, its like a conventional set of utilities written to run on the simpler machine represented by the core instructions of the processor that are implemented directly rather than through microcode. Now, clearly, since the microcode is within the processor and not rewritable, open-source microcode doesn't provide a means to let you "upgrade" a processor, it would be more useful in cutting down development time of a compatible or related processor, or perhaps in emulating the processor.

think in the context where hardware is part of the discussion (which it must be for a BIOS to be relevent), it's understood that the word "system" includes software and hardware unless it is explicitly designated as software only.

I disagree, since BIOS is software, that in the context it was being discussed hardware has to be "included in the discussion", and, at any rate, I think that in the phrase "open source system", the "open source", since it only has any meaning in regard to software, does explicitly designate the "system" as being software only.

Re:It's not the last barrier

[ClosedSource]

I agree, but I don't think it's appropriate to use the word system to describe it. The broader point is that if one wants to be "pure" with respect to openness, you can't stop at the software. If it's "evil" to use closed source software it's also "evil" to use closed microprocessors, graphics cards etc. Otherwise, the "moral" argument falls apart.

Re:It's not the last barrier

[ClosedSource]

"Typically, microcode (as I understand it) implements a part of the instruction set in a processor, built on a smaller "kernel" of instructions implemented more directly."

I'm sure there are all kinds of variations, but I think a counter would be the minimum required to bootstrap the microcode.

"Sure, when looking at the machine it is part of; from a development perspective, its like a conventional set of utilities written to run on the simpler machine represented by the core instructions of the processor that are implemented directly rather than through microcode. Now, clearly, since the microcode is within the processor and not rewritable, open-source microcode doesn't provide a means to let you "upgrade" a processor, it would be more useful in cutting down development time of a compatible or related processor, or perhaps in emulating the processor."

I don't think there needs to be "core instructions", but as I said, there are a lot of different ways to implement it. Some processors do allow microcode to be rewritable although that's not the most common practice.

"I disagree, since BIOS is software, that in the context it was being discussed hardware has to be "included in the discussion", and, at any rate, I think that in the phrase "open source system", the "open source", since it only has any meaning in regard to software, does explicitly designate the "system" as being software only."

The point is that BIOS is specifically designed as an interface to hardware, so it serves no purpose if the system is defined to exclude hardware. As I've aleady shown, there is code within microprocessors, so the term open source can apply to some hardware components as well.

Re:It's not the last barrier

[zuiraM]

Actually, there are approximately six useful approaches to open source processors, which all mostly have to do with security:

* Make a tiny processor, or a fragmented small one, that can be implemented in FPGAs. This gives you a mostly open approach, although you still have to trust the FPGA. The gate count and clock rate would be fairly limited, but it's viable. Many people build their own RISC systems for this; an open source EPIC-like architecture might be nice here, too.
* Make a small processor, or a fragmented medium one, and develop a semiconductor technology that home users can implement. This was discussed on the Cypherpunk lists at one point, and would probably either require the development of semiconductor ink that can be used in a printer, which could yield useful (yet still huge) feature sizes; or, printing projector transparencies and doing a home-version of the regular processes, presumably with Zink, Gallium and Germanium, which would presumably yield gargantuan feature sizes. On the positive side, anyone with a microscope can verify that they have got the right design.
* Make a medium to large processor, and require the users to go for group buys, for example via MOSIS. This implies trusting MOSIS, but is quite doable, albeit at higher costs than a commercial processor. It also has been done, IIRC, with cores from the OpenCores project. This is the closest thing to something that is viable on grounds of utility and geek appeal, I guess.
* Make a tiny to large processor that is implemented on PCBs with discrete transistors. You can buy reels and reels of N/P dual MOSFETs, and either hand-solder them (tiny processor, probably nothing fancier than a 286 at best) or have them machine mounted (up to large sizes, by stacking and otherwise interlinking several PCBs to get enough transistors). This would offer limited clock rates unless some ingenious engineering was done, and would probably consume a lot of power, but could be viable in terms of computing power. Inspection is also simple. It would be very expensive, though.
* Make a tiny to large processor that is implemented on PCBs with logic gates (74-family). This is like the previous option, except it sacrifices some amount of inspection to gain a more compact footprint, higher clock rates and lower power consumption. This has been done with the Magic-1 Homebrew CPU, and is equivalent to what one once had to do in order to get a home "PC" ;)

The last approach, which would require a *ton* of funding, and sacrifices *hardware* inspection, but actually seems at least potentially viable, is to have lots and lots of geeks to pool their money to have the FSF/GNU/whatnot buy a prototyping fab or somesuch and have them crank these things out. The cheapest is a direct-write system, but I'm sure some second-hand fabs are available at a "reasonable" cost, although you'd not be getting entirely modern feature sizes for a reasonable price with anything but direct-write.

Commercially, these approaches all have limited value, I think. From a hacker's perspective, however, I find all of the above to have appeal. Is it reinventing the wheel? Sure. But doing it "just because I can", and to learn, experiment and play with it is IMHO worthwhile, if you have the resources to do so.

A class of CPU-engineers-in-training can complete a binary-compatible 486 DX in less than one year, according to someone I spoke to whose class had done just that (in a few months). MOSIS can fabricate it. This is, IIRC, how the RISC-1 was done, introducing the RISC concept to the world.

With sufficiently large-scale coordination and cash pooling, you could even conceivably buy a production run of a CPU with a modern feature size from one of the companies in that business.

Re:It's not the last barrier

[smittyoneeach]

have lots and lots of geeks to pool their money to have the FSF/GNU/whatnot buy a prototyping fab or somesuch and have them crank these things out.

The requirement here is leadership. If RMS is Moses, there needs to be an Aaron to manage the details.

why would a major manufacturer of motheboards

[BrentRJones]

Why would a major manufacturer of motheboards want to stay away from Linux for BIOS?
What do Award and Phoenix have better than Linux?

Re:why would a major manufacturer of motheboards

[runderwo]

LinuxBIOS is not compatible with legacy DOS-based PC operating systems and the GPL does not allow for proprietary extensions.

Re:why would a major manufacturer of motheboards

[Lumpy]

Why would a major manufacturer of motheboards want to stay away from Linux for BIOS?

What do Award and Phoenix have better than Linux?

two simple reasons.

1 - they do what they are told by the OS and content industries. "Trusted computing" is a buzzword they spent lots of money on.
2 - A linux Bios will not have the ability to lock the user on DRM or Os choices. something they desperately want at Microsoft. D oyuo think a company will make a motherboard that microsoft will refuse to support their os on? how about one that will never run windows VistaXP2 with "Protect you from you" technology? because the Bios does not refuse to boot an OS without a Microsoft certificate?

Try and buy yourself an ATX Alpha processor motherboard or Power PC motherboard. They exist but are insane priced because nobody buys them but uber geeks and research/science people....

Do you want your next Linux computer to cost you 3 times as much because your Motherboard costs $1800.00?

Re:why would a major manufacturer of motheboards

[Laur]

LinuxBIOS is not compatible with legacy DOS-based PC operating systems

According to the ADLO page there is no reason that LinuxBIOS couldn't boot up DOS-based OSes with a bit of tweaking, it just seems that no one has bothered yet.

Re:why would a major manufacturer of motheboards

[Gerzel]

I have to agree.

In order for Linux to go much further there has to be a concerted effort to advertise and educate people about linux. Also while that is done the software quality has to be kept up. No small task considering that there is no linux boardroom where people can be told what to do from the comfort of big leather chairs.

Re:why would a major manufacturer of motheboards

[Anonymous Coward]

There are two problems with major LinuxBIOS adoption.

First: Silicon support. CPU and chipset companies are loathe to give out documentation. Anyone who has tried to work with nVidia or Intel or dozens of like-minded companies can attest to that. Without documentation, you just CAN NOT get chipset support. Unless you want to accept a black-box binary module from nVidia... I know I dont.

Second: Vendor support. Ignoring the first problem, why would a mobo manufacturer do this? They barely spend enough time on each new board as it is, now you expect them to bring it up twice? Until LB supports *everything* that modern BIOSes support, and can boot DOS and Windows out of the box, and supports all the latest hardware, its a non-starter for the guys in Taiwan.

Sad but true.

Re:why would a major manufacturer of motheboards

[kfg]

Try and buy yourself an ATX Alpha processor motherboard or Power PC motherboard. They exist but are insane priced because nobody buys them but uber geeks and research/science people....

Similarly 12/24/48VDC ATX power supplies are also available off the shelf; at about three hudred bucks a pop. But if you're the sort of uber geek research/science person who really needs one, well, that's what you pay.

However, if, eventually, enough people get sick enough of the MS locked down systems there just might be a market for an outside player to hit one out of the park with an open system. That's why MS and its familiars are trying hard to get laws passed to forbid it.

KFG

Re:why would a major manufacturer of motheboards

[suggsjc]

However, if, eventually, enough people get sick enough of the MS locked down systems...

Sorry to burst your bubble, but that has been the line for everything that the /. crowd has for anything that comes out of Redmond. "Just wait, people are going to get fed up with ___"

Its been said that people are going to boycot iTunes because they are going to get "fed up with DRM" but I'll believe that when I see it.

Its been said that people are going to boycot Vista because of "not supporting legacy hardware", "not supporting legacy software", "not providing adequate reason to upgrade", "increasing the DRM", "unfair pricing", and just about any other gripe conceivable. But when those people come back to reality they will sit and watch as Vista will eventually be on %60-70 of all desktops.

In a rush, so not even going to give my "I really do like FOSS" disclaimer (even though I don't need the karma). All I'm going to say is I hope the LinixBIOS project does take off and really become supported by all major manufacturers.

Re:why would a major manufacturer of motheboards

[kfg]

". . .people are going to get fed up with ___"

I have no bubble to burst. I distinctly said "if," not "are."

In the past I have also distinctly said that I don't give a flying about whether Linux becomes "mainstream" or not; although I would appreciate a bit more hardware support.

KFG

Re:why would a major manufacturer of motheboards

[cp.tar]

What do Award and Phoenix have better than Linux?

Well, they support my mobo, for one...

Now, when LinuxBIOS becomes available for A8N-E or whichever mobo I'll be running on at that time, I'll gladly try it out. Until then, though...

Re:why would a major manufacturer of motheboards

[heinousjay]

In a rush, so not even going to give my "I really do like FOSS" disclaimer

In the same spirit: it goes without saying that you did, indeed give the disclaimer.

Re:why would a major manufacturer of motheboards

[k8to]

It's not clear that motherboard manufacturers have a strong interest in proprietary extensions to the BIOS. BIOS vendors do, but board vendors? They probably could have done something in this space if they wanted to, but haven't. I'd say that suggests a lack of motivation.

when I read "guts-like-to-be-free-too"

[jimstapleton]

I immediately pictured a guy walking around with a gaping hole in his torso, with all of his internal organs dangling about, dragging along, behind him, etc.

An I the only one?

Re:when I read "guts-like-to-be-free-too"

[byolinux]

Dude, you're thinking of goatse.

Re:when I read "guts-like-to-be-free-too"

[_Sprocket_]

I was kind of thinking of a spleen singing "Born Free."

Re:when I read "guts-like-to-be-free-too"

[jimstapleton]

That works well too. Or maybe freebird? And in regards to [some of] the modders: hehehe, sorry to anyone who thought I was trolling, it's just my disgusting, repulsive sense of humor, and the comment was on that one little blurb, not the content of the article itself. Lighten the hell up.

Extensible Firmware Interface

[smitty97]

uh.. EFI & TianoCore ?

Re:Extensible Firmware Interface

[the_humeister]

Don't forget Open Firmware, which I think just requires you to just purchase the documentation and maybe not even that.

Re:Extensible Firmware Interface

[Laur]

Don't forget a link to the OpenBios project, which aims to create a FLOSS implementation of the Open Firmware standard.

Re:Extensible Firmware Interface

[BigBuckHunter]

uh.. EFI & TianoCore ?
Since you included a "?", I believe the answer you are looking for is "Turd" , although Linus may have put it best when he called it "the other piece of Intel brain damage".

BBH

Re:Extensible Firmware Interface

[mrchaotica]

You do realize that the only purpose of creating EFI (as opposed to simply using OpenFirmware, which already exists) is to enable DRM, right?

Re:Extensible Firmware Interface

[MacColossus]

Where does one find info about EFI's sole purpose being DRM based? I'm not doubting you, but as a Mac user, I would like to learn more. Also, I would like to find Linus's comments. However, I do take anything Torvalds says with a grain of salt though. If it's not Linux, he bashes it in a "you suck, and I'm not going to waste my time explaining why" manner. The lone exception to this would be his arguments against the Mach kernel.

Re:Extensible Firmware Interface

[real gumby]

Unfortunately implementing EFI requires you to license Microsoft's FAT filesystem patent which was upheld at the beginning of this year by the PTO.

I added a dispassionate (NPV) comment about this to the EFI page in the Wikipedia but had it deleted. A pity.

Re:Extensible Firmware Interface

[DeathPenguin]

uhhh: https://www.tianocore.org/nonav/servlets/LegalNoti ces?type=TermsOfService

"You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software."

This is a compulsory licensing agreement which developers must agree to before even hopping on board with Tianocore.

Re:Extensible Firmware Interface

[Anonymous Coward]

Nobody expects the fanbois to understand. Don't you have a press conference or hardware refresh to be vigorously wacking off to?

Re:Extensible Firmware Interface

[Anonymous Coward]

All apple has to do is prepend "Open" onto something and you tards all think it magically garners some merit. I love it.

Any place to buy the MOBO with lb pre-installed?

[WindBourne]

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.

LinuxBIOS has a problem

[Aladrin]

From the site:

LinuxBIOS has a problem

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

Knew that'd get your attention ;) I really wanted a list of motherboards that support this... I think it would be really neat to have a customizeable BIOS.

Re:LinuxBIOS has a problem

[mengu]

Google's cache of the page:

http://72.14.209.104/search?q=cache:VJTK5OuL8OIJ:l inuxbios.org/index.php/Supported_Motherboards+Moth erboards+supported+in+LinuxBIOS&hl=en&gl=us&ct=cln k&cd=1

Re:LinuxBIOS has a problem

[BoneKracker]

It's a limited list of devices, but hopefully more will added with renewed interest. This has been mostly of interest to folks doing clustering (since the this bios doesn't do much, they dont' have to manually deal with thousands of bios nodes to reconfigure hardware initialization of boot attributes). PXE and other forms of centralizing boot, virtualization, etc. have provided alternatives.

Notably, Linux bios can reduce the time to load kernel significantly. I would see this as also useful to builders of embedded systems and users of mobile computers based on pc architecture. Also useful to builders is that it's free.

Re:LinuxBIOS has a problem

[darkfire5252]

In LinuxBIOS there is problem,
and that problem is slashdot.
Server very not so stable,
cause traffic spike is big.

Throw the dot down the well,
so my server can be free!
You must grab him by his linkings,
Then we have a big party!

Try waiting a few minutes and reloading.

[someone1234]

Yeah. That will solve the slashdotting problem.

Eternal game of catch-up?

[Kadin2048]

Aren't the BIOS/firmware revisions specific to various motherboard models?

I always assumed that they were made by Award and Phoenix in conjunction with the mobo/chipset manufacturers, because the BIOS was specific to a particular configuration of parts, and wouldn't be interchangeable.

So if you did write an "open source BIOS," how would you keep it up to date with the multitude of different chipsets and motherboards? Wouldn't each one require its own modified version? Seems like, unless the major motherboard manufacturers commit to using LinuxBIOS, that they'll forever be playing catch-up, trying to modify and QA their revisions against new pieces of hardware. Which I guess isn't a bad thing, but it seems like it'll never be mainstream that way.

Re:Eternal game of catch-up?

[sgtrock]

If a motherboard vendor chooses to use the FOSS BIOS, then I would assume that the vendor would recognize that it was in their interest to make sure that any changes to the hardware elements on their motherboard lines would necessarily require that they demand that their parts vendors work with the FOSS BIOS project to make sure that the low level drivers are working correctly.

I suppose it's possible that such a motherboard vendor might want to donate engineering time and samples to the project as well. They would have to weigh the cost of that effort against a host of other costs; licensing costs to use Award or Phoenix, the size of the expected market for the combined product, etc. Show them that the FOSS BIOS will work for MS Vista and they'll have a real incentive to push for it. Tell them that the market will be limited to just Linux and *BSD and they'll probably lose interest really fast.

Re:Eternal game of catch-up?

[drinkypoo]

This isn't just a random open source BIOS though. It's based on the linux kernel, and all the hardware support that entails. Or well, as much as you can cram into your kernel image. This kernel then bootstraps to another kernel (or through ADLO, apparently can run WinXP or Win2k's NTLDR.) The only bootloaders it in fact supports are NTLDR and LILO, apparently.

Re:Eternal game of catch-up?

[kfg]

So if you did write an "open source BIOS," how would you keep it up to date with the multitude of different chipsets and motherboards?

Does not Open Source imply freely modifiable?

KFG

Re:Eternal game of catch-up?

[Kadin2048]

Only a very small minority of people, even among open-source-software users, are capable of interpreting source code and modifying it.

Also, even a person that did know code, would need to be very comfortable (I would think) to write or change something that could potentially brick their mobo.

So whether the code is modifiable or not, really isn't relevant to all but a few users, at least in the direct sense. There are indirect benefits of having code available (see my other post in this thread concerning the indirect benefits of OSS to non-coders), but most people are going to look at the piece of software as a unit, and ask whether it works, and if it doesn't, they're going to move on to something else. The benefits of OSS are rarely so great as to make hiring a skilled programmer to modify it for you worthwhile.

It sounds from TFA that they have a nice automated QA system set up, where new revisions get tested against actual hardware automatically, but they're going to have to sustain an awfully high level of effort, in order to keep creating and testing new software revisions to cope with all the new boards that get released to the market every month.

I'm not panning the project; I really hope they succeed. It just seems like yet another project that probably won't have direct support from the hardware manufacturers, and as a result will always be one step behind mainstream usability. Perhaps that's okay -- maybe "mainstream usability" is overrated. But it's something worth considering.

Re:Eternal game of catch-up?

[kfg]

So whether the code is modifiable or not, really isn't relevant to all but a few users, at least in the direct sense.

Who said anything about users?

It just seems like yet another project that probably won't have direct support from the hardware manufacturers

Yes. That is what; and only what, is required.

. . .maybe "mainstream usability" is overrated.

It is. It can be a positive hinderence if you're not mainstream.

KFG

Re:Eternal game of catch-up?

[davidsyes]

But, then microsoft would just starve the BIOS and MOBO makers of marketing dollars. Sure, make it compatible/supportive of Vista, but them mshaft will just make the OS kernel check the BIOS maker ID-- IDs assigned by mshaft. As much as I'd love to see the hardware more Linux-friendly, I have no doubt it'll still be some time off.

Heck, I have TWO EZ-Cam webcams I bought back in 2001 or 2002. The designers sometimes allow their contract manufacturers to change up components for almost-the-same depending upon the prices in the commodities or components market.

It happened when I worked for a maker of multiplexers/demultiplexers. During burn-in, whole racks of equipment would just go to shit because the contract manufacturer sometimes sourced crappy (but supposedly- or almost-identical) components to put on the MOBOs. My director was a smart guy and traced the problems to that. Dell does the same thing. I had one Dell tech on the phone and seduced/challenged him into admitting that Dell from time to time changes board components even in the same make/model of machine without telling the consumers/purchasers of the equipment. Even when I was in the company IT department before moving to Customer Support & Manufacturing, my IT manager saw I was having problems with one or 2 boxes. He told me those were a pair Dell had quietly made changes to and were to be replacing them at Dell's cost. So, TWICE in the same company, in under 2 years, I got burned by secret changes.

What does it mean? Anyone buying boatloads of hardware for some large lab or emulation or scientific project might have some wayward machines having spurious, untraceable problems. All because a component on the MOBO was switched. I HAD to get the Dell guy on the speaker phone during a tech support call, and it was timely. I worked for a friend who told me I didn't know what the hell I was talking about. Having been insulted and demeaned in front of others by him (some non-Dell MOBO machines were just reFUSING to be Ghosted (Norton) and he blamed it on me and incompetence even tho I told him of my experiences with Dell and other products, and that the problem HAD to be in the MOBO he had just bought, a comment to which he took great exception), I was on the phone with Dell and got my over-the speaker answer. Swapping the MOBO on the NON-DELL box solved the problem. I never got an apology from that day.

As for my EZ-Cam cameras, one has a shitty Conexant chip. No distro of Mandrake since 2001, no Mandriva, no Ubuntu, or Suse, or any other distro I tried could get that damn camera to shoot or show images. They DID SEE the camera, but could not activate it. Meanwhile, another camera of the same markings, DID work. Years ago I opened both and took pictures and found what I suspected: different components, yet same model/type, etc.

So, it won't be that hard for mshaft to software discriminate against Linux-friendly BIOS code unless... well, unless, I suppose, that code is cross-licensed with Novell/Suse and mshaft, too.

Hopefully, Linux devs will become so nimble that the BIOS makers might be bypassed altogether. But, the hardware makers will still likely solder or epoxy on some firmware-laden chip that will refuse to work with Linux BIOS footprints.

Re:Eternal game of catch-up?

[sgtrock]

Interesting story, but how is it relevant to what I posted? If the mobo vendor doesn't know what components he's buying/substituting, no one does. If one of his subcontractors is substituting parts without notifying him, how on earth will an Award or Phoenix BIOS resolve the problem better than a FOSS BIOS?

Re:Eternal game of catch-up?

[Rutulian]

But, then microsoft would just starve the BIOS and MOBO makers of marketing dollars. Sure, make it compatible/supportive of Vista, but them mshaft will just make the OS kernel check the BIOS maker ID-- IDs assigned by mshaft. As much as I'd love to see the hardware more Linux-friendly, I have no doubt it'll still be some time off.

Wait, I missed the part where you explained why exactly MS would want to do this? Microsoft isn't in the bios business. Why would they care who writes the bios?

Re:Eternal game of catch-up?

[Anonymous Coward]

but they're going to have to sustain an awfully high level of effort, in order to keep creating and testing new software revisions to cope with all the new boards that get released to the market every month.

Let me just remind you that they have to have a common code base to release those motherboards so quickly like that. It should be pretty obvious that mobo vendors are not rewriting a completely new BIOS every time they make a new mobo.

Also, the general purpose OS is a much harder problem than the open BIOS. And we seem to have plenty of open source OSs to go around. There just has been little incentive up to this point for having an open BIOS. To the average user there is almost no benefit. In fact the primary appeal of LinuxBIOS is the extreme reliability and manageability needed for very large super computer clusters. Not something you're going to need for your average home. Deploying a fix by hand and rebooting two computers at home is annoying but manageable. But when you've got a cluster of 1,000 you might be looking for alternatives like Linux BIOS after you walked up and down the racks with a monitor, keyboard, and CD rebooting them one by one.

There should be no reason why we can't have a open source code base that can be adapted for a new motherboard with equivalently little adjustment. And when the LinuxBIOS becomes sufficiently robust most Taiwanese vendors will just use it instead of paying a license fee to use functionally equivalent PhoenixBIOS.

That said, Linux BIOS is extremely attractive to me and if I could get a standard single socket Intel or AMD motherboard I would do it. As it stands the best current support is for Tyan Opteron boards with multiple processors in the range of $300+ apiece. And the installation process is a little onerous, especially if you actually want to make it a usable desktop computer. So here's what Linux BIOS needs to speed adoption:

1) Prebuilt binaries for common motherboards
2) Better support for desktop features instead of the bare minimum for a headless processing node
3) Support for some *modern* single processor AMD / Intel boards.

Re:Eternal game of catch-up?

[davidsyes]

Well, mshaft didn't start out in a LOT of places:

Console games (went after original players in this space)
Real Estate (INT WTF)
Keyboards (branding and encroachment on smaller incumbents)
Mice (branding and encroachment on smaller incumbents)
Joysticks (branding and encroachment on smaller incumbents)
On-line Reservation Systems (branding and encroachment on smaller incumbents)
On-Line email servers (bought Hotmail) .....

So, if mshaft feels any BIOS manufacturer is not "with the program by making life easier for Linux users, developers and systems integrators", then most likely mshaft WILL enter that space, too. There, was that so hard to grasp? It's really up to mshaft to ignore or screw the smaller guy, and big-business and corrupt government make it all to perpetually easy.

Hitting two sacred cows at once...

[Otter]

With the One Laptop Per Child (OLPC) project [CC], that number is expected to exceed 10 million users in 2007.

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!)

Re:Hitting two sacred cows at once...

[Anonymous Coward]

Please note that it says "10 million users *IN* 2007", and not "by 2007" - so certainly they could, they have more than a year left!

Re:Hitting two sacred cows at once...

[Ant P.]

10 computers? That's odd, I could've sworn they made a few more than that.

Re:Hitting two sacred cows at once...

[Otter]

I couldn't resist the urge to use Irritating Nerd Sarcasm, either, so I'm not in a position to chide you for it...

So they made 10 machines, sent out a press release, and then made another 190?!? I don't quite understand the logic. Oh, and these aren't the final design, so at the moment the total number of actual OLPCs produced is ten less than I had thought.

In any case, it's not obvious how this scales to 10 million in 13 months.

Re:Hitting two sacred cows at once...

[rbanffy]

Idiot.

they hand assembled a couple units from the parts that will be used in the production lines to make sure everything works and that the production process does what is expected from it.

After they say "yes, this is right" they will start the assembly lines that will mass-produce the computers.

Re:Hitting two sacred cows at once...

[DragonWriter]

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!

It wasn't like the 10 computers were all they could produce, its all they had planned to produce for this phase of testing.

Still, 10 million units in the hands of end users by the end of 2007 is probably optimistic.

Re:Hitting two sacred cows at once...

[Ant P.]

These aren't exactly PS3s, they're just small laptops built using already-existing parts and bright green plastic. Making millions of them isn't going to be hard.

One word.

[AltGrendel]

Control.

They can control most, if not all, of what hardware is used by the motherboard. DRM? Sure, we can force that.

Why bother?

[Viol8]

I'm not trolling but I really don't understand the point of an open source BIOS.
I like linux because (in theory) I can look at the source code and see whats
running and modify it and hence modify my enviroment. Why would I care about the
BIOS? For all intents and purpose it just the first stage bootstrap system for
the hardware. As long as it does this quickly and simply who cares who or how
its written? Ok , if ever BIOSes had some sort of DRM style restrictions installed
them yes , maybe it'll have a use. But right now? I don't think so.

Re:Why bother?

[Anonymous Coward]

That's the whole point. Conventional BIOSes are not simple, quick or efficient. LinuxBIOS is.
Be booting into your OS in a couple of seconds, instead of the lengthy legacy crap normal BIOSes go through.
Want a network console from the moment of power-on? Customizability, man...

Re:Why bother?

[Anonymous Coward]

Well, if you are in the manufacturing business, and hope to deliver 10 million laptops, then the main appeal is the huge cost reduction by not having to pay for 10 million BIOS licenses.

That is the reason.

Re:Why bother?

[molarmass192]

That's not exactly true, the BIOS also provides all your I/O services. So you may want to have more granular control of that I/O for example. You may also want to provide features that don't exist in OEM firmware such as remote BIOS management for headless servers. There are several potential benefits on the server, but you're right in that 99% of desktop users wouldn't have much interest in this beyond potential performance gains.

Re:Why bother?

[Lissajous]

Why bother? A few reasons, off the top of my head. 1. Because it reduces the cost of ownership of a PC. Every mobo sold without LinuxBIOS on it pays a licensing fee to Award / Phoenix / whoever. With a free (as in beer) BIOS, the OLPC project can reduce their overheads. This is a "good thing" (tm). 2. Because you'll be able to tailor the BIOS to do things the way you want it to. OK - maybe *you* won't (no offence), I could (but don't really feel the need to), and others can and will. If hacking around with electronics is your thing then a FOSS BIOS is a "good thing" (tm). 3. Because if you're a coder then playing with low-level stuff is good for the soul. It reminds us of where we came from, and provides those who didn't grow up with this stuff with an appreciation of how computer architecture works from the ground up. This is also a "good thing" (tm). All I have to say is more power to them, and well done Google for shelling out some of their hard-earned advertising revenue in that direction.

Re:Why bother?

[eno2001]

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.

Re:Why bother?

[tomstdenis]

That "annoying slow crap" is it detecting your processor and devices. Believe it or not, processors [for instance] are not perfect and require patching or tweaking to work with given chipset combos (e.g. adjusting timing, turning on/off features, etc).

I'd rather have a "slower" bios that detects my processors properly than a free bios that skips all that "junk".

though I think there are some other merits. Like features. My gigabyte P965 board has no way to update the bios other than through a floppy disk.... I don't even own a floppy drive, I had to borrow one!!!

Tom

Re:Why bother?

[Viol8]

>That's not exactly true, the BIOS also provides all your I/O services

AFAIA the BIOS hasn't provided I/O services since 16 bit DOS days. I can't
see why linux or any other 32 bit OS would switch into 16 bit mode to access
some crusty HD or floppy driver when they've got their own anyway.

Re:Why bother?

[randallman]

I'm not trolling but I really don't understand the point of an open source Operating System. I like OpenOffice because (in theory) I can look at the source code and see whats running and modify it and hence modify my enviroment. Why would I care about the Operating System? For all intents and purpose it just the first stage bootstrap system for the hardware. As long as it does this quickly and simply who cares who or how its written? Ok , if ever Operating Systems had some sort of DRM style restrictions installed them yes , maybe it'll have a use. But right now? I don't think so.

Re:Why bother?

[Chanc_Gorkon]

Oh RMS might care. I, personally could not give a crap.

Re:Why bother?

[Anonymous Coward]

Hey - 1999 called. It said that you can go ahead and keep that troll. It wasn't any good anyway.

Re:Why bother?

[elgaard]

> Why would I care about the BIOS?

For the same reason you care about other programs being open. E.g.

- Fixing bug. Eg hibernate problems.

- Checking for bugs and backdoord.

- Improving it to your needs. E.g., I would like to be able to boot from USB-disks or a CFlash card in a PCI-adaptor.
Or I could remove unnecessary stuff and put in a shell. Or an SSH server i the BIOS.

- Performance. My BIOS is slow. It does a lot of unnecessary things.

- Consistency. Next time I get a new computer, it would be nice to have the same bios. A company might prefer to use the same BIOS on all computers.

Re:Why bother?

[Anonymous Coward]

Who do you trust? BIOS' now are powerful enough to use network devices and may do things you don't want. Eventually there will be the potential for backdoors in the network cards, but for the time being the OS and the BIOS are the practical places to put in phone home code.

Re:Why bother?

[Slashcrap]

Believe it or not, processors [for instance] are not perfect and require patching or tweaking to work with given chipset combos (e.g. adjusting timing, turning on/off features, etc).

When you say patching you mean uploading microcode updates. This is always done by the OS, not the BIOS.

And when you say adjusting timing I can only assume that you mean DRAM timing. LinuxBIOS takes account of that. That's why a different version is required for each motherboard it supports.

I'd rather have a "slower" bios that detects my processors properly than a free bios that skips all that "junk".

LinuxBIOS is generally used in massive clusters. The project was started at Los Alamos. I suppose they must have much lower standards than you do.

But apart from your facts and opinions being a load of bollocks, I thought your post had a lot of merit.

Re:Why bother?

[prefect42]

That's great for before your OS is loaded. Have you never had a remote serial connection to a server pre-boot before? In fact, have you never booted a machine from a remote CDROM before?

Re:Why bother?

[Anonymous Coward]

Don't feel too bad, I remember trying to enter BASIC commands at the DOS prompt back in the day. ;)

Re:Why bother?

[99BottlesOfBeerInMyF]

Why would I care about the BIOS? For all intents and purpose it just the first stage bootstrap system for the hardware.

First, I think open firmware is important for developers and interoperability. It may not be important to your everyday use for those reasons, but most people don't ever make a change to Linux, but they do benefit from the results of its code being open. Second, and this seems to be the most overlooked part of this, is this is a way to let legacy hardware without Linux drivers, run Linux. That may make a difference to you if you happen to acquire the hardware on their list.

Re:Why bother?

[Hast]

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.

Re:Why bother?

[99BottlesOfBeerInMyF]

LinuxBIOS is generally used in massive clusters. The project was started at Los Alamos. I suppose they must have much lower standards than you do. But apart from your facts and opinions being a load of bollocks, I thought your post had a lot of merit.

Try not to be too hard on people. The summary misrepresented this project to some degree (I think) and the Web site is slashdotted. The fact that this is likely to be used mostly with legacy hardware or clusters was completely absent. The summary should have made it clear that this is not currently in the running to replace EFI as the basis for most new workstations and servers, but rather that it is mostly about getting specific old machines running Linux.

There certainly are features of modern chipsets that LinuxBIOS will probably ignore but which can be useful to some people. LinuxBIOS is not a full featured firmware. It is a quick and slim one.

Re:Why bother?

[arcade]

I'll give you an answer, from my point of view.

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 :p

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.

Re:Why bother?

[rubycodez]

such features are often supplied by yet another microprocessor with yet another BIOS, that's going beyond just having the main machine's BIOS opened sourced. You'd need to at least know how and what it interfaces with in the main system

Re:Why bother?

[sxpert]

take for instance the Via EPIA M 10000, with the latest bios drop from nvidia... I use PXE to boot the thing remotely. problem, I need to power cycle the motherboard for the PXE part to actually correctly function. a standard reboot will just have the PXE stuff hanging there with no chance of booting. talk about useless crap

Re:Why bother?

[richlv]

a practical example :
fujitsu-siemens lifebook c series 1020 laptop has broken usb controller suspending part (and probably also video chipset stuff somewhat).
i was unable to get the problem solved from them despite several attempts. i'd guess i could have more chances with weird guys all over the globe just doing this for fun.

then there was an asrock mobo with broken acpi tables data (two bytes swapped). i was lucky that it was brand new mobo, so i even got a bios update from them - but i got it personally and it was not put up for public download.

then all those cases of "old" (a couple of years) mobos, which were working fine, but some upgrade requires a bios update... which is nowhere to find at that point. and this is the optimistic scenario, in many cases a problem could be solved in bios code, but most if not all companies refuse to provide any support for older motherboards, probably because both of no resources allocated for that and forcing users to get hw upgrade instead of doing a simple bios update.

so yeah, i can definitely see where this could be massively useful.

Re:Why bother?

[Viol8]

"Have you never had a remote serial connection to a server pre-boot before? In fact, have you never booted a machine from a remote CDROM before?"

Funnily enough - no. And whats your point anyway? It still won't use the BIOS I/O once the OS is up and running.

Re:Why bother?

[Anonymous Coward]

Gotta laugh when a kiddie who has done nothing in his worthless life calls RMS a loser. :-)

Re:Why bother?

[richlv]

i'm not completely sure, but what about cases when bios update was required to support more/different ram ?
then there are simply bugs in bios that vendor refuses to fix.
and when you get to suspending/resuming and broken bios implementations... given the hype that "laptops sell better than desktops !", this is becoming more and more important.

Re:Why bother?

[Anonymous Coward]

I raped your mother.

Re:Why bother?

[RAMMS EIN]

``But I STILL to this day believe that the OS kernel should talk to and provide low level support for the MOBO components.''

Don't Linux and the BSD kernels do that, anyway? I've only had a cursory look at it, but it appear to me that one of the first things the kernel does is switch to protected mode (where BIOS doesn't exist, right?), then starts detecting and initializing hardware...kind of like a BIOS does.

Re:Why bother?

[J.R. Random]

If you actually read the LinuxBIOS web site, you will see that a prime motivation was to allow remote updating of the BIOS on Linux clusters. It beats attaching a keyboard to each of 256 motherboards and updating them one by one.

Manufacturers of embedded systems are likely to be interested in a BIOS that is free and fast.

It is not so clear what the benefits are for Joe and Mary desktop user. I'm sure most Linux users will continue to use the BIOS that comes with their board.

Re:Why bother?

[kenb215]

I really don't understand the point of an open source BIOS. I like linux because (in theory) I can look at the source code and see whats running and modify it and hence modify my enviroment. Why would I care about the BIOS? For all intents and purpose it just the first stage bootstrap system for the hardware. As long as it does this quickly and simply who cares who or how its written? Ok , if ever BIOSes had some sort of DRM style restrictions installed them yes , maybe it'll have a use. But right now? I don't think so.

I really don't understand the point of an open source software. I like Windows because (in theory) I can just click a few buttons and hence modify my enviroment. Why would I care about the software source? For all intents and purpose it just the backend stuff for the computer. As long as it works quickly and simply who cares who or how its written? Ok , if ever software had some sort crippling of DRM style restrictions installed them yes , maybe it'll have a use. But right now? I don't think so.

Basically, it might not be interesting or helpful to you, but it is to some people. As few computer users know much about how their software works, the few software engineers know much about how their hardware works.

Re:Why bother?

[Viol8]

Copying a post and changing a few words is really old and isn't an argument. Using your logic perhaps someone should open a free chip foundry since , hey , why should we use the closed design Intel or AMD chips? Or why stop there , perhaps open our own metalworks , why pay for Rio Tinto to process stuff for us , just get the FSF out with their spades and we're off! Right?

Bascially , smelting metals for circuit boards might not be interesting or helpful to you, but it is to some people. As few computer users know much about how their hardware works ... etc etc blah blah.

Re:Why bother?

[kenb215]

Like open source programs, BIOS costs almost nothing to distribute after its initial creation. Physical circuitry has a noticeable per unit cost, making it hard to support under a free market. However, if someone could find a way to create a free chip foundry, and enough people chose to volunteer so that it could work, then sure, they should go ahead and do so.

Link and Confusion

[99BottlesOfBeerInMyF]

First, the Website seems to be slashdotted, but anyone interested can get the basics about LinuxBIOS from the wikipedia page.

After reading said page it looks like this is an attempt to make a fast, barebones BIOS replacement without all the cruft of traditional BIOSes. Like others, however, I'm not sure I see the use for this on servers and workstations when compared to EFI or Open Firmware, both of which are already deployed. My current laptop boots via EFI. What disadvantage is there to me that this project is supposed to be solving?

No ceremony

[MattNukem]

It's kind of a shame really... linux boot loaders have become so good and what they do (and often look very good doing it) that just unceremoniously booting into linux would make me feel like something is missing.

A few primary reasons:

[Ayanami Rei]

1) It's fast.
2) No unnecessary hardware initialization or checks
3) Stupid bootstrapping tricks (if your onboard bios can't boot from it, linuxbios probably can)

BIOS + DRM = lockin ..

[rs232]

http://news.zdnet.co.uk/software/0,1000000121,3911 6902,00.htm
http://slashdot.org/hardware/03/09/04/1427237.shtm l?tid=137&tid=185

Re:BIOS + DRM = lockin ..

[Viol8]

Ah , well in that case maybe there is a point to it :) I didn't realise this genie was almost out of the bottle already.

Re:BIOS + DRM = lockin ..

[rs232]

"An apparatus that includes a BIOS routine, and a method executed during a BIOS routine, that includes a stored BIOS program causing a computer to receive information, including error information"

"Methods, apparatus .. for ensuring compatibility between an operating system and a BIOS redirection component"

A method of initializing a computer system equipped with a debugging system"

"a set of BIOS resume tasks specific to that operating system type are dispatched for execution in response to a sleep mode wake event"

"A method and apparatus for implementing a BIOS-level floppy boot-sector virus prevention system"

Now this is funny, the 'protection' consists of the BIOS prompting the user.

Re:BIOS + DRM = lockin ..

[Anonymous Coward]

Ah , well in that case maybe there is a point to it :) I didn't realise this genie was almost out of the bottle already.

It's my understanding that LinuxBIOS doesn't currently work well with MS DOS based OSs... So who's genie and which bottle are you talking about?

Don't try to act like this entire concept of "lock down" only works one way.

LinuxBIOS targets pre-EFI machines.

[Ayanami Rei]

And OpenFirmware is difficult for add-on card makers to support. LinuxBIOS sort of sidesteps the issue by supporting the necessary hardware directly (drawing from the existing pool of device driver support).

Re:LinuxBIOS targets pre-EFI machines.

[99BottlesOfBeerInMyF]

LinuxBIOS targets pre-EFI machines.

Okay that limits the scope of this project to primarily legacy hardware?

And OpenFirmware is difficult for add-on card makers to support.

Okay, so ignore the old PPC macs laying around as Linux already has drivers.

LinuxBIOS sort of sidesteps the issue by supporting the necessary hardware directly...

So this is a replacement for BIOS on legacy machines allowing Linux to run on them even if the Linux drivers for the boards were never written. That makes sense as a way to breath new life into old hardware using Linux. i wish the summary had made this clear. Half the comments here seem to be trying to figure this out.

Re:LinuxBIOS targets pre-EFI machines.

[DeathPenguin]

>>Okay that limits the scope of this project to primarily legacy hardware?

Nope. It works great with current hardware as well. AMD's been particularly helpful and has developers contributing quite often. Rev. F Opterons are already supported, for example.

>>Okay, so ignore the old PPC macs laying around as Linux already has drivers.

LinuxBIOS supports some PPCs, I'm not exactly sure which ones. Pease check wiki.linuxbios.org at a later time (When it's not slashdotted) for more info.

>>So this is a replacement for BIOS on legacy machines allowing Linux to run on them even if the Linux drivers for the boards were never written.

It's a replacement for legacy BIOSes that places responsibility of a lot of hardware initialization in the OS (Which most OS kernels do anyway). I think "Linux" in LinuxBIOS is more of a historical reference now. Some of the older work was called "LOBOS" (Linux OS Boots the OS). Other OSes such as FreeBSD, Windows 2000, and Plan 9 can boot from LinuxBIOS as well.

Re:LinuxBIOS targets pre-EFI machines.

[LinuxOnEveryDesktop]

LinuxBIOS targets pre-EFI machines.

That's completely incorrect. Would you call a dual-socket F AMD64 board *legacy*? I didn't think so.

EFI is a kludge. It's the same all 60's and 70's software design crap all over again. And it's proprietary. Intel has released some fairly insignificant parts of the specs, but the core is still locked up in heavily proprietary code.

Also, it's designed to force DRM on every user - read up on the 'sandbox model' in the EFI specs.

You don't want EFI. You want LinuxBIOS. Believe me.

Re:LinuxBIOS targets pre-EFI machines.

[Identifiable Coward]

EFI is a kludge. It's the same all 60's and 70's software design crap all over again. And it's proprietary. Intel has released some fairly insignificant parts of the specs, but the core is still locked up in heavily proprietary code. Also, it's designed to force DRM on every user - read up on the 'sandbox model' in the EFI specs.

Mod this man up. This is the most informative post in this thread.

Info on Linux BIOS in actual usage?

[tji]

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?

Re:Info on Linux BIOS in actual usage?

[LWATCDR]

I heard one of the big benefits was a much faster boot time.
The way Google builds system I wouldn't be shocked if they bought a motherboard company. They could build motherboards that fit their exact requirements.

Re:Info on Linux BIOS in actual usage?

[Shewmaker]

You can edit a plain text file in user space and write it to CMOS with at utility like lxbios or cmos_util. The options I've seen are: boot sequence related, ECC memory related, power on after failure, debug level, cpu throttling, and NMI related. I didn't see anything about the enabling and disabling of devices or fan control, but I'm sure it depends on how much effort the developers have put into a particular chipset/motherboard.

LinuxBIOS supports several different types of payloads: Linux, Open Firmware, Etherboot, etc. If you are using a Linux kernel payload, then you probably don't want to be upgrading it often. In that case, you can set up the first kernel to kexec a second kernel (before kexec, there was a patch called the two kernel monte).

AMD64's 64-bit mode is definitely supported.

It's not trivial (yet) to boot a version of MS Windows with LinuxBIOS, but using Linux as a BIOS can give all sorts of benefits. One very interesting capability for people running beowulf clusters is that you can boot over any network device that Linux supports (e.g. Myrinet or Infiniband). That may not mean anything to a regular home user, but the point is that you have a whole lot more flexibility in what you can do. Even if you don't want to make it boot your home system over your wireless LAN, it does increase your freedom and it prevents people from nibbling away at the freedom you already have.

I would say freedom from future DRM really is the biggest incentive for trying out LinuxBIOS at home. You can avoid Intel's EFI standard (they're pushing for it to be on all desktops and servers), which will enable companies to inflict DRM on you. Linus has made some very good points about why EFI is not good. One way to look at EFI is that it is basically an OS, and not a very good one.

There are several white papers and tutorials that do a good job of explaining how LinuxBIOS works. Look at the LinuxBIOS documentation section.

Re:Info on Linux BIOS in actual usage?

[vil3nr0b]

To me the usefullness is about two things: Speed and Downtime. The Open Bios boards on the Linux nodes I repair boot incredibly fast and since they have no use for anything but what I want them to use it is a great relationship. Also when there is a problem they go into a fallback mode. This lets me know the node has tried to boot normally three times but it was unable to do so. I am able to watch the node boot on a console and depending on where it freezes I know what hardware has failed. It saves me a lot of time in hardware repair.

Re:Any place to buy the MOBO with lb pre-installed

[Laur]

Try starting with the Products page at LinuxBIOS.

Harddisk encryption

[Ignatius]

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.

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 ....." banner on startup and some epoxy over the bios flash rom ...

Coral cache

[Anonymous Coward]

http://linuxbios.org.nyud.net:8080/

Opening the Gates

[Doc Ruby]

Actually, the BIOS keeps company with lots of proprietary drivers and codecs that are distributed only in binary, protected by either copyrights or even patents. The BIOS can be seen as a driver for the entire OS on the PC HW. The codecs can be seen as drivers for the transmission HW.

So there is a whole layer of Linux that remains outside the Open Source domain. There are plenty of open drivers and codecs, proving that it's entirely possible to open them, probably to open them all.

Opening the BIOS is a big chip away at the critical dependency path to run Linux at all, and Google deserves lots of credit for helping to get the basic platform in the clear. There's a lot of other closed components that need opening. Most of them can be opened by their owners. And others can be replaced by alternatives. I hope Google's move pushes more momentum into that movement, until it's all open.

Re:Why bother? Because Dell et al IGNORE BIOS bugs

[Hobart]

Why would I care about the BIOS? For all intents and purpose it just the first stage bootstrap system for the hardware. As long as it does this quickly and simply who cares who or how its written?

Because, like me, you might be stuck using a Dell Latitude D610 laptop.

One which locks up hard when you have a Microsoft Natural Ergonomic Keyboard 4000 plugged into it during boot time.

And you might be rather disappointed in the fact that when you open up a support ticket with Dell, they ignore it completely, after giving you the runaround with six or seven incompetent first level tech support engineers, who refuse to escalate the ticket.

You might even have posted in the Dell forums about this - and seen other people confirm the same problem. (Or you might have seen the same problem manifest on the other laptops in your office when using another of the same model of keyboard).

Unless a thousand people are complaining, Dell really doesn't care. They've moved on to the new overseas laptop manufacturer of the week, and don't even have anyone on staff who really knows how the BIOS works -- apart from a corporate agreement to stuff the right logo in place, the technical side of things is all between Phoenix and the overseas laptop maker.

Hypothetically, of course. No, I'm not bitter. (Hey, look, the support forums seem to indicate the Inspiron BIOS hang on boot too. Bet they care even less.)
--
Slashcode bug # 497457 - unfixed since December 2001 - Go look it up!

Why bother? indeed.

[anss123]

The BIOS limitations have largely been worked around, and the few features that we users demand of a BIOS have already been implemented. True, a better BIOS would make life easier for OS software vendors, but that is not a feature we end users care about in the least. Think about it, what use does the general population have of the BIOS? If you want to repair a system your better of with a CD distribution, today's OS install software can format hard drives as needed, etc, etc...

A final paint: People rarely look at the BIOS when purchasing a system, and those that do are usually embedded or cluster shoppers. IOW, a vendor that stamps 'Advanced BIOS' on the feature checklist will not see much increase in sales - and that at the cost of implementing a non-trivial feature.

Re:Why bother? indeed.

[db32]

It has worked in the past. "HYPERTHREADING!!!" sold a ton of chips to people that have no concept of what it means. That is the sole function of a marketing department. It doesn't matter what it is your selling, just make it sound flashy, more impressive, and create a desire to have it. You are right 'Advanced BIOS' (not to mention Advanced Basic I/O System doesn't sound right..advanced and basic at the same time?) probably wouldn't sell much but something like '*NEW* HyperDrive IO Chip' would probably go a much longer ways to creating hype and demand, add on a snazzy sticker and the masses of Best Buy computer shoppers will all add it to their must have list.

I believe it was George Carlin who explained it best talking about the difference between "pre-owned car" and "used car" and how its the same damned thing, and its stupid to be fooled by the marketing gimmiks. "Would you want a 'pre-fucked wife'?"

Cluster usage

[evandrofisico]

The main point of using linuxBIOS is the possibility to automate and flexibilize the boot process. It's not something you would need while dealing with your home server or notebook, but when you have to administer thousands of machines , just like google or linux networkx (which is an old times sponsor of LinuxBIOS) a flexible, automated envoirment where you have lower level access and the possibility to identify hardware errors *before* a node boots is very important. Anyone who ever administered a linux cluster knows how valuable the possibility to controls the machines from the begining of boot process is important and how much time can be saved.

Don't call it breathing new life into old hardware

[Ayanami Rei]

Most new Intel Core 2 systems and all workstation and server AMD systems come with "legacy" BIOS. Very few vendors ship with EFI at all even if it is supported, especially on platforms that are to be compatible with 32-bit operating systems (stock Windows XP).

So LinuxBIOS is still very relevant. In fact, it is still useful even if EFI was prevelant, as it is popular in the construction of clustered systems with homogeneous hardware. It makes dealing with distributed consoles and disk arrays simpler, and you can bounce machines with new boot images rapidly.

Reasoning is obvious

[ThinkingInBinary]

A lot of people have asked why you would want to use Linux for your BIOS. Generally it comes down to speed and flexibility. First, a Linux BIOS can be faster, because instead of having to check all the system RAM, test out all the integrated hardware, do SMART drive checks, and all the stuff a modern BIOS does to be "user friendly", it can just look for the disk it needs and boot, after initializing things like the memory controller. Second, a Linux BIOS is more flexible, because it can be programmed to boot off of any local media, or even, theoretically, do something crazy like netbooting over wireless.

Re:Reasoning is obvious

[pho3nixtar]

Are you talking about cold booting a system via wireless or would it have to be in some sort of standby mode? I don't see how you could cold boot the system unless there was at least a component in the system that was in some sort of sleep mode. Anyway, maybe you could program the wireless capabilities directly into the BIOS (or is that what you meant?). Of course, that would open up a huge security risk to the system, but maybe you could program security checks and balances into the boot-up process. I'm not smart enough (yet) to know what those checks and balances would be, but I'm sure someone could come up with something, if they haven't already.

OSS has benefits to non-coders.

[Kadin2048]

End users aren't going to modify their processors and have them fabricated, but then again, "end users" for the most part, aren't going to open up the source code to their applications and make any sort of nontrivial adjustments to them, and recompile them.

Writing code and recompiling a piece of software is almost as much a black art to most people, as designing a microprocessor and fabricating a chip is.

Source code is meaningless gibberish to most users, regardless of whether that source code describes hardware or software. Code written in VHDL is just a slightly more arcane strain of gibberish than C, but still meaningless.

Most people (who have even the foggiest idea of open source) benefit from it indirectly: by having higher-quality products to begin with, and having them available from more vendors, and having a guarantee that if a vendor tanks, that their product stands a better chance of being supported by somebody else (because another company or organization can take it over). This would also be true with hardware. An open and well-documented chip design would be available, were it popular, from a variety of vendors, and even if one vendor went out of business, the design would survive. These benefits exist even to people who cannot understand code, and exist for both hardware and software.

Re:OSS has benefits to non-coders.

[Anonymous Coward]

You mean like SPARC?

Re:OSS has benefits to non-coders.

[kyouteki]

You should make it more apparent when you speak about someone's signature.

Re:Don't call it breathing new life into old hardw

[99BottlesOfBeerInMyF]

Most new Intel Core 2 systems and all workstation and server AMD systems come with "legacy" BIOS.

True, but for Intel and AMD systems this is pretty unlikely to last very long once Vista ships. They both already have it in production and neither wants to be left behind.

So LinuxBIOS is still very relevant.

I didn't say it wasn't relevant, I spoke to the scope of the relevance which was misrepresented in the summary.

In fact, it is still useful even if EFI was prevelant, as it is popular in the construction of clustered systems with homogeneous hardware.

I can certainly see benefits for this type of environment, which is probably why Google is interested in it, but most people are concerned about their desktops and servers, not clusters. Take a look at this thread. How many people do you see discussing this for getting Linux running on specific hardware that does not have drivers, or for clusters? Most people assumed this project was aimed at the average desktop (something implied by the summary) and were rightly concerned/dismissive as it is not a good fit there.

Complete Speculation, but..

[billyj4]

What would stop google from using a TCP/IP layer in the bios, to allow these machines to boot up their own OS over the network?

Re:Complete Speculation, but..

[Curien]

Dude... ever heard of PXE? Nearly every BIOS already supports this.

4004

[deevnil]

What about a 3 ghz multicore intel 4004?

eSupport.com

[misleb]

Why would a major manufacturer of motheboards want to stay away from Linux for BIOS? What do Award and Phoenix have better than Linux?

Well, at least one company makes money selling proprietary BIOS "upgrades." This company, and any motherboard manufacturer that makes you go through them, pisses me off to no end. It is such a scam. They claim that they are selling custom upgrades (what the heck is that, anyway?), but really they are just selling updates. Some manufacturers don't supply BIOS updates directly. They redirect you to esupport. Want the latest BIOS revision for your motherboard to fix a hardware compatibility problem? Pay like $50. I had to deal with these people once. I just went and bought a new motherboard instead.

-matthew

how about The microcode

[Anonymous Coward]

an open source microcode would allow you to override instructions of the processor during runtime

Good :)

[Anonymous Coward]

Google rocks. I wish they also sponsor http://gaia.serezhkin.com/ project :) Or better open Google Earth source code...

LinuxBIOS on the desktop

[niko9]

I'd like to know if anyone is using this on a mainstream desktop motherbaord. Most of the supported boards listed are of the industrial server variety; I can understand why. Instant on Linux, on the desktop is something that I have been craving for quite some time.

Re:Don't call it breathing new life into old hardw

[Ayanami Rei]

The summary (to me) implied nothing about the purpose of the LinuxBIOS firmware. Was it confusing that the one example usage as the OLPC project? To me, it was obvious that it is used in the OLPC project is a by-product of wanting to reduce the per-machine royalty costs, since the hardware is well-known and standardized (compare to a cluster).
End-user have no need to worry about such an issue, they buy mainboards with BIOS bundled, and absorb the per-unit cost which is not worth mentioning. What would make them think that LinuxBIOS is somehow necessary, other than wanting a "really free" complete software stack?

Re:Any place to buy the MOBO with lb pre-installed

[gt_mattex]

It's a little disconcerting that directly next to the product page of

Artec Design Group run LinuxBIOS on their DBE61 system.

You find Microsoft Windows Embedded Partner

Re:Don't call it breathing new life into old hardw

[Cid Highwind]

True, but for Intel and AMD systems this is pretty unlikely to last very long once Vista ships. They both already have it in production and neither wants to be left behind.

I think it'll last at least another full Windows release cycle. 32-bit Vista won't support EFI. 64-bit Vista will, but is too locked down for some users. Gamers (and anyone else who wants to use unsigned drivers in Windows) will need BIOS for a long time to come.

What will actually be Google's part?

[itz2000]

What will actually be Google's part? it already runs on 1 million systems, but lets be honest : In this case Google is trying to earn the credit by "helping" the project with some money, after it's already a success. Probably the sponsorship will go to wider support of LinuxBIOS, which is good, but Google will earn 2 much credit for it :] Therefore Google made an extreamly wise choice (some chain for credit == good deal) go Google! continue sponsoring OpenSource projects no matter what state they are (even when it's only on an Idea state, nothing more) Mono-Project looks like it needs more cash, go and help them :] Good luck!

MOD PARENT UP

[TheRaven64]

OpenBIOS is a far more interesting project, since it implements an open standard for boot firmware. LinuxBIOS always felt like a 'because we can' project.

opencores.org

[RAMMS EIN]

http://www.opencores.org/

3 GHZ Multicore 4004

[obsidianpoet]

"What about a 3 ghz multicore intel 4004?"

I hate to take away from your post but the Intel 4004 is not the 4 core processor.... it was one of Intel's first microchips ever...... as seen here on todays Slashdot :) http://hardware.slashdot.org/article.pl?sid=06/11/ 14/2356255

Re:3 GHZ Multicore 4004

[Unski]

Thankyou for sharing. I think people use irony too often.

Open Firmware clarification

[DeathPenguin]

Just a reminder to everyone--Open Firmware is a specification, not an implementation. An open implementation currently available is OpenBIOS which can be used in conjunction with LinuxBIOS.

Re:Why bother? That's interesting because if

[davidsyes]

the BIOS could be wholly bypassed by Linux BIOS, then I could get my laptop (Sony Vaio PCG-FX215 from 2001) booting via a USB-connected hard drive. See, my l/t suffered ad "hardware controller failure" and it cost me time and data last year. The machine otherwise works: BIOS, PCMCIA, USB, sound, CD/DVD devices in the bay, battery charging (tho the battery life is dismal). Well, the ON-BOARD NIC doesn't work, so I had to buy a card bus NIC, which works fine.

Funny thing is, the BIOS allows booting via ATAPI device, but if I had adaptors, I could probably put the hard disk in the CD ROM bay tray and then use the CDROM externally. I suppose this wouldn't work for installing or using a Live Disk of Linux.

But, what IS a silver lining about this is that I can surf on a diskless, Mandriva One-live DVD machine and not worry about attacks as much as I might be concerned with my fixed-disk machines. I can just shut down and reboot, as clean as the DVD from the magazine. Only problem is that I haven't bothered to save my Konqueror preferences (hmmm, funny, the Slash spell checker recognizes Konqueror, but not Mandriva as a correctly spelt word, or is that my local M1 DVD?) to floppy or to the USB HDD. Even so, I need to learn how to adjust the "guest" account to use them so I don't have to reset/customize a few settings.

OLPC isn't using LinuxBIOS anymore

[burns210]

As of a few weeks ago, the OLPC project isn't using LinuxBIOS anymore, they have moved to OpenFirmware from Sun, which was recently open sourced. Sorry to burst the bubble.

Re:OLPC isn't using LinuxBIOS anymore

[chgros]

If you read your link, they are still using LinuxBIOS, but not as a bootloader anymore (only as a BIOS)

Re:OLPC isn't using LinuxBIOS anymore

[LinuxOnEveryDesktop]

As of a few weeks ago, the OLPC project isn't using LinuxBIOS anymore, they have moved to OpenFirmware from Sun, which was recently open sourced. Sorry to burst the bubble.

That's incorrect. The OLPC project is still using LinuxBIOS to boot the machine, but they are using OpenFirmware as a payload. I have seen both OpenFirmware and a linux kernel payload demonstrated on the OLPC revA developer boards. They chose OpenFirmware because it can fit in a smaller ROM chip.

If you don't understand what that means, just read up on things at http://linuxbios.org/

Re:OLPC isn't using LinuxBIOS anymore

[jg]

Incorrect.

OLPC continues to use LinuxBIOS: we use OFW as the *bootloader* rather than using Linux as Bootloader.

LinuxBIOS sets up the base machine, and then brances to a bootloader; so we are very much continuing to use LinuxBIOS.

Link problems...

[evilviper]

This is the second time, in as many days, that a link in the story has gone to some random nonsense at the bottom of the page.

It isn't all that hard to strip off, is it editors? Editors...

10...200...millions

[Jecel Assumpcao Jr]

Starting up mass production of a consumer product is a complicated task with many steps. Earlier this year they built a few boards (pre-A), made some modifications (A-test) and then built a lot more (around 200). These boards were distributed to developers who hooked them up to SVGA monitors and USB keyboards and mice. Later several changes were made to the design (B-test) and a very small number of boards which were used by a few key developers to adapt the low level software.

Last week they carefully assembled 10 full machines by hand to test that all the parts fit together as they should. This was certainly worth a press release as complete, working OLPC machines now existed for the very first time. This week there was a trial run through a pilot assembly line resulting in 200 more working machines. If I understood correctly, by the end of the week there should be 900 or so laptops.

But notice that none will be made next week, nor in December. Instead these first machines will be put through various tests (about 500 will be given to children for destructive testing) and also used for further software development. As a result of all this the design will certainly suffer some tweaks. Some time early next year there will be another pilot run. If all goes well this will be followed by a full production run and after any glitches are sorted out Quanta will bring more and more lines into production mode. At that point building 10 million machines will be easily done in just a couple of months.

How old are you? 15?

[jotaeleemeese]

Sun opened the SPARC specification from the start.

That is at least 15 years ago.

I saw and worked with other manufacturers of SPARC machines happily running Sun's SunOS and later Solaris.

The Sun haters in /. would never admit it, but Sun's philosophy for doing bussiness has been consistent and head and shoulders above how others have gone about doing business.

Two words for you

[jotaeleemeese]

Trusted Computing.

Sorry, let me write that correctly

"Trusted" Computing.