How Good is Commercial BIOS Code? 60
Bitten-by-BIOSbugs asks: "My job involves porting PC BIOS code supplied by one of the Big Names to my employer's products. In my experience, this code seems to be so full of holes you could strain pasta with it. However, the vendor seems not to care when I report bugs, and rarely have fixes been made available. What is the experience of other Slashdot readers regarding the quality of commercial BIOS products?"
Re:It is better than... (Score:1)
Re:It is better than... (Score:1)
It's a dying concern (Score:3, Insightful)
Re:It's a dying concern (Score:2)
Since so few BIOS functions are actually used once the operating system gets into place, it's becoming less and less of a concern to get things perfect.
This is mostly true, but one part which every OS needs is correct ACPI information, which many BIOSs do not have.
Another great question. (Score:5, Funny)
:-)
Too many are broken (Score:2, Insightful)
Alan Cox's view of (at least one) BIOS programmer (Score:3, Funny)
I Think. (Score:1)
That being said, what *really* needs to be provided by the BIOS these days. I'm suprised they even bother talking with you in the first place. Why fix bugs that aren't used from the OS these days anyway.
I'm not really sure what features in the BIOS aren't provided by today's popular OS drivers either? Anyone?
Re:I Think. (Score:1, Insightful)
Re:I Think. (Score:2, Insightful)
Now so far out there (Score:2)
Haven't seen code, but... (Score:1, Informative)
Pasta (Score:4, Funny)
At least it's not writen in perl. Then how could you tell it from the pasta your straining?
Re:Pasta (Score:1)
mmm... spaghetti [code] *drools
Who needs commercial code? (Score:3, Informative)
Re:Who needs commercial code? (Score:1, Insightful)
It also has about two lines of actual documentation on how to set it up, giving anyone who wants to use it a funny look on their face and a need to go look on the poorly archived mailing list for an answer that isn't there. Then the mailing list is sparsely updated with material like, "Hey! Now Linux Bios works on yet another board over a year old that you can't even find on Ebay!", or "Ooh, another company expressed interest in using it, but this has no actual relevance to whether or not you can use it on your computer. Because you still can't."
If you think this is trolling, you obviously have never tried to use Linux Bios. It is a great idea, and I wish it worked, but it doesn't except in
Re:Who needs commercial code? (Score:2)
While I agree that it only supports a small percentage of all MBs out there, I think you're overstating the situation a bit.
I use it all the time on a SiS630 based board that's actually quite good for general purpose use.
A lot more motherboards would be supported except that it seems many hardware vendors would rather die a horrible screaming death than document their chipset outside of an NDA.
It takes time to figure out an undocumented motherboard with a somewhat (or not) documented chipset. More developers can solve that problem.
All things considered, LinuxBIOS has come a long way in a short time.
I only wish I could devote a greater portion of my time to advancing the LinuxBIOS cause.
Re:Who needs commercial code? (Score:1)
Are there still BIOSs in new PCs? (Score:4, Interesting)
Is it time for the BIOS to go the way of the BASIC interpreter provided in the original PC ROMS?
Re:Are there still BIOSs in new PCs? (Score:1)
Its a small part, but integral to many systems, mostly as an interface between the OS and hardware.
When I installed Linux on a wintel box (solid linux, not dual-boot), the BIOS still ran before lilo, which shows that even linux (which I view as the best of production OSes) still makes use of the BIOS.
Re:Are there still BIOSs in new PCs? (Score:1)
Re:Are there still BIOSs in new PCs? (Score:3, Insightful)
There has been long debates on the linux-kernel list of whether ACPI should be used by Linux. Using it the way it was intended means calling into BIOS code quite often. Since it seems no vendor has managed to produce an ACPI-implementation that is both reasonably bug-free and reasonably complete, there are worries stability and security. Imagine a backdoor in an ACPI BIOS... The shipping Linux kernel uses ACPI as little as possible, but it is not clear that it can be avoided forever.
The only thing about the BIOS that might go away is the name. It isn't really basic or about I/O anymore.
Re:Are there still BIOSs in new PCs? (Score:1)
All though not 100% relevant, and not viewed friendly, You can install Windows 2000 (Dunno bout NT, or XP for that matter, never really tried though) without ACPI support, and to my experiance, it seems to run alot better. I Belive you hit F5 when during setup it asks you to hit F6 for the RAID drivers (I think maybe could be SCSI). And then out of the list, pick Standard PC. It seemed to raise the uptime on the boxes I was in charge of (Which was bad because it made my supervisor even less willing to switch to bsd). There are better descriptions online.
BIOS developers are generally bad programmers (Score:5, Informative)
The reason why is that they've been working with assembly language for most of their careers, while everyone else was learning advanced techniques like object-oriented design and development, and working on multiple languages (C++, Java, C#, etc). There were a dozen BIOS developers in my department, and I was the only one who lnew object-oriented programming. The only one!
Now, you might be saying, what does OO have to do with BIOS? True, you're not supposed to write OO assembly code, but you are at least supposed to understand the concept, so that you can apply them in some way. The Linux kernel is written like this - the kernel developers know OO concepts, but they use them only where necessary, and the code is still written in C.
I firmly believe that the only reason why these people worked there was because no one could write this code. Writing BIOS is hard, and it's almost impossible to find someone who knows BIOS and modern programming techniques. I remember this one guy who consumed caffeine all day long and was completely wired. He wrote code really fast, but it was all very poorly designed, and none of it was documented. Every time a new feature was added, the guy had to hack it in somehow, because the original code was always written to just what it was supposed to do, no more.
Another reason why they were so bad is that BIOS developers are highly resistant to change. Most of them spend all their time updating the code to support new motherboards, but they would never rewrite anything to improve its design. The majority of code was written back in the 80's, and no one wants to touch it. So this code just sits there, from one version to the next.
What made it more pathetic was that these people were actually better than most BIOS programmers. We would have conference calls with some of these other developers (the company doesn't write the BIOS for all motherboards they sell), and we would ask them technical questions, and they couldn't answer half of them!
The real solution is to rewrite the entire BIOS from scratch, using proper OO techniques, and writing as much code as possible in C. But today's BIOS programmers aren't qualified for that job.
Re:BIOS developers are generally bad programmers (Score:3, Informative)
Mobo makers might be wise to make their specs public. Even just the simple improvement of a 32-bit BIOS would be a good idea (as in start as 16 and switch to 32 first thing on a particular setting).
/Brian
Re:BIOS developers are generally bad programmers (Score:1)
For most embedded programming, that's the intent and is looked upon as a good thing.
Re:BIOS developers are generally bad programmers (Score:1)
Re:BIOS developers are generally bad programmers (Score:2)
Working with assembly all your life does not a bad programmer make. In fact, quite the opposite. Given the choice between a developer with assembly experience, and one without, I'll take the former, all other things being equal. Of course, an assembly background doesn't automatically make you a good programmer, either, but I think it certainly helps. From observation, I'd be more inclined to say that exposure to C++ and Java makes you a bad programmer, but I doubt that's really true either. I suspect it's just that they're the new sexy languages, and so they're the ones to which newbie and unskilled programmers are drawn, in the hopes of making money...
Re:BIOS developers are generally bad programmers (Score:1)
But that's my point - all other things were not equal with this bunch. All they knew was how to program hardware in assembly language.
And I think it's inconsistent of you to say that expose to Assembly makes you a better programmer, but exposure to OO languages makes you a worse programmer. A good programmer learns from all the languages he's exposed to. If you're exposed to a language, and it makes you a worse programmer, then you were never a good programer to begin with.
Re:BIOS developers are generally bad programmers (Score:1)
OO programming is a state of mind, not a language. OO code is a function of the programmer, not the language. I've seen some of the worst [non-OO code] written in in C++ and Java; I've seen some of the most beautiful [OO-oriented code] written in assembly language.
Get a clue.
Re:BIOS developers are generally bad programmers (Score:1)
OO languages suck for BIOS (Score:1)
Sometimes even the assemblers don't do what you really want them to do and you need to do wierd stuff in hex. The last time I did BIOS level code for x86 (actually a WinCE bootloader - not a BIOS) some of the code was written in hex because the freakin assembler would not generate the code that I needed. The resulting code was approx. 1% hex, 10% assembler 89% C. The code was also a mix of 16 and 32 bit (which is what really stumped the assembler).
C++ Is not a good thing for BIOS work because it hides what's going on. In BIOS-land we don't want beautiful layers of abstraction (we're poking values into registers and we know it), so all that OO design has limited benefit. IMHO, C++ is not even a good idea for operating system code for the same reasons. Linus is more articulate on this point than I am http://www.linuxgazette.com/issue32/rubini.html
On your generalisation re BIOS programmers.... point taken. I see people like this in many other areas too. People who like to draw a veil of mystery over what they do and seem to get off on clever trickery etc rather than good coding.
Re:OO languages suck for BIOS (Score:1)
And FYI, a typical BIOS is 90% Assembly language and 10% C.
OOP is not the same as OOL (Score:2)
Can you hack the BIOS your self? (Score:1)
I have a system that hangs at boot up because the BIOS boot order
code is defective and the manufacturer's tech support is totally clueless.
Re:Can you hack the BIOS your self? (Score:1)
I've lost the links, but I looked into something similar for a BIOS that I thought might have a Y2K problem. Downloaded the update, decided to "wait and see", and after Y2K, it was fine, so I never bothered to load it.
Re:Can you hack the BIOS your self? (Score:2)
Haven't seen source, BUT... (Score:3, Funny)
I'd fire any programmer who did that, but it's de rigeur for BIOSes.
Re:Haven't seen source, BUT... (Score:2, Funny)
Re:Haven't seen source, BUT... (Score:2, Funny)
They typically can't spell interociter either. Talentless hacks.
Re:Haven't seen source, BUT... (Score:1)
From my experience, fairly good... (Score:2)
That said, as a meer admin and user I take it as a rule of thumb that if a new system is acting flaky for no obvious reason, firmware upgrades are on the short list of things to check into along with RAM and video drivers.
bad... and getting worse (Score:1)
LinuxBIOS (Score:1)
As I recall, poweron to Linux in single user mode was less than 5 seconds. That speed was largely a factor of how fast the code could be read from the EEPROMs.
Please ask Dell, HPQ, IBM, Gateway, and your favorite mother board manufacturers to dump the crappy old BIOSes and migrate to something modern.
Answer Re: How Good is Commercial BIOS Code (Score:1)
"BIOS. Huh! What is it good for." (Score:1)