BIOS Will Be Dead In Three Years

Stoobalou writes with news that MSI is planning a big shift towards UEFI (universal extensible firmware interface) at the end of 2010, possibly spelling the beginning of the end of the BIOS as we know it. "It's the one major part of the computer that's still reminiscent of the PC's primordial, text-based beginnings, but the familiarly clunky BIOS could soon be on its deathbed, according to MSI. The motherboard maker says it's now making a big shift towards point-and-click UEFI systems, and it's all going to kick off at the end of this year. Speaking to Thinq, a spokesperson for the company in Taiwan who wished to remain anonymous said, 'MSI will start to phase in UEFI starting from the end of this year, and we expect it will be widely adopted after three years.'"

Comments

A GUI for the motherboard?

[logjon]

Absolutely brilliant! Why didn't I think of it?

Re:A GUI for the motherboard?

[MrEricSir]

I've seen quite a few machines like this when I did computer repair. Most were major brands at the time -- Compaq, Packard Bell, etc -- and the GUI tended to be a knockoff of Windows 3.1.

Presumably this was to make users less afraid of changing their BIOS settings, although considering some of the users I dealt with, that might not have been such a good idea.

Re:A GUI for the motherboard?

[nigelo]

Oblig:

http://en.wikipedia.org/wiki/UEFI

It's more a strategy to remove 16-bit and other legacy restrictions from the firmware interface:

"The Extensible Firmware Interface (EFI) is a specification that defines a software interface between an operating system and platform firmware. EFI is a much larger, more complex,[1][2]:4 replacement for the older BIOS firmware interface present in all IBM PC-compatible personal computers."

Re:A GUI for the motherboard?

[erroneus]

It's more than that. This will cause a DOS compatibility issue. This means that the floppy boot process and other handy-dandy things we've been doing that uses DOS of some kind (Microsoft, IBM, FreeDOS, whatever) to boot up and get devices working through the config.sys and all that used BIOS hooks to get much of the I/O accomplished.

I don't know whether or not UEFI's services provide compatible techniques or if whole new things need to be created, but it would seem to me that many low-level recovery and imaging tools may be lost to us. Perhaps Symantec needs to update its Ghost to run on Linux, for example, as Ghost currently runs on DOS which uses BIOS hooks for I/O.

Re:A GUI for the motherboard?

[h4rr4r]

You should switch to FOG, it is free and uses PXE. It is better than Ghost in every way.

None of what you speak of should be done with dos floppies in 2010, linux boot usb sticks are the way to do this stuff.

Re:A GUI for the motherboard?

[jtdennis]

Ghost also runs in the WinPE boot environment without any problems. WinPE should boot off EFI based systems without a problem as it's used in the Vista and 7 boot DVDs. Just run Ghost32.exe from within WinPE and use Ghost like you always have.

Re:A GUI for the motherboard?

[man_of_mr_e]

EFI can have BIOS compatibility modules installed. So it *MIGHT* cause compatibility issues, or it might not.. depends on the motherboard manufacturer, and if they include BIOS compatibility. You may also be able to add BIOS modules later.

Re:A GUI for the motherboard?

[Anonymous Coward]

The point isn't the GUI. The point is that EFI is a REPL, much like Sun + Apple's OpenFirmware. The BIOS just does a few things: scan ram, handle input and output. Your "BIOS screen" really didn't have anything to do with the BIOS, except that the BIOS hosted it. (Presumably you could load up new firmwares through it, which would change how the BIOS is programmed to operate)

Now, picture a world where device drivers are written at the EFI level, using a nice language. Where any operating system that speaks EFI can use any hardware with EFI drivers.

Re:A GUI for the motherboard?

[NJRoadfan]

Compaq used a special service partition on the HD to run that GUI based BIOS and diagnostics.

There was one true GUI BIOS out there, the AMI WinBIOS. Nobody really adopted it and stuck to the old "pink screen" AMI BIOS. (remember those?)

Re:A GUI for the motherboard?

[alexborges]

The BIOS in intel has been an ugly piece of shit for YEARS, even DECADES now. It was about fucking time.

Re:A GUI for the motherboard?

[couchslug]

"Perhaps Symantec needs to update its Ghost to run on Linux, for example"

Linux runs fine, who needs Ghost?

Re:A GUI for the motherboard?

[Culture20]

Perhaps Symantec needs to update its Ghost to run on Linux, for example, as Ghost currently runs on DOS which uses BIOS hooks for I/O.

Did you write this in 2004? Ghost has been running fine on Linux for a while now. In fact, Symantec's Linux boot disks have better driver support and more functionality than both the DOS and WinPE boot disks.
I'm stepping on your lawn.

Re:A GUI for the motherboard?

[larkost]

FOG is nice, but it does not have all of the features of Ghost Solution Suite (the enterprise product under the Symantec brand, not the consumer one under the Norton name). I really wanted to use it, but it was missing two major features that I could not live without:

1) It will only run under PXE boot, so it requires that you have control over DHCP wherever you are. With GSS I can use a "virtual partition" to boot from, so it will download the boot system from the server, then boot without ever requiring me to get special information from a DHCP server. Since my clients need to be able to roam to many network segments (that I have no control over, and may have their own network boot servers), including home networks, I can't use FOG.

I should note that this is one thing I hope will change under UEFI. Apple's implementation (while being a bit off the standard) is a great example of the flexibility that having a more intelligent boot system can do.

2) The system tray item does not allow my clients to initiate a re-image when they want. For my purposes they have to be able to trigger a re-image of a computer in front of them in a easy-GUI way. We get a lot of people flowing through and while I may have my pain-points on the GSS version of the system tray icon, it is drop-dead simple to implement and only requires a "see, here is the tool you use" level of training.

So no, FOG is not better in all ways than Ghost (at least not GSS).

Re:A GUI for the motherboard?

[negRo_slim]

Glad that got linked, UEFI is really more an extension of the BIOS. So saying it "will be dead in three years" is somewhat misleading.

Re:A GUI for the motherboard?

[RulerOf]

It will only run under PXE boot, so it requires that you have control over DHCP wherever you are.

You might like to try gPXE. You can, either by chainloading SYSLINUX or PXELINUX or using COM32 modules, implement exactly what you describe using almost any medium you desire, whether that's floppy, PXE/DHCP/ProxyDHCP, local disk, USB, etc, configured as you desire, so that as long as it's on any network that can route to your boot server, it'll behave the same every time. You could even burn gPXE directly into the NIC of your target machines, and remove the need for a "virtual partition" altogether. Of course you can set everything up in the DHCP server, or, if you like, point the client at an HTTP server and sort it all out with PHP or something.

Most likely, you're looking to use an embedded script that wants DHCP from the local segment, then contacts a specific server every time, regardless of DHCP settings.

Also, gPXE already supports EFI in addition to BIOS based systems. In the meantime, I'm gonna go look at FOG :-)

Re:A GUI for the motherboard?

[inode_buddha]

I have an DEC Alpha box from the late 1980's that does just that. In 64-bits of course. The interesting thing is that the firmware includes a fairly complete OSF/1 UNIX implementation right there in the chip. This means that you can boot into a straight Sys V , complete with terminal and network, without even having anything on the disk. It actually works pretty good.

Re:A GUI for the motherboard?

[NJRoadfan]

The only thing I really want from a BIOS setup screen is some detailed online help for some of the options. Who here hasn't had a BIOS that had some obscure acronym titled option thats either missing in the manual or has a vague engrish description along the lines of "Turns Foo On/Off".

Re:A GUI for the motherboard?

[cupantae]

Okay, conspiracy theorists. If we are in the "Brave New World", where the fuck is my free drugs and obligatory orgies?

I wish there was a mod option for "poorly formed sig".

Re:A GUI for the motherboard?

[cupantae]

I haven't seen a floppy in almost 10 years.

I'm glad you got over your erectile dysfunction.

OhNo!

[rwiggers]

Am I the first to say that dumbing down low level config is a bad idea?

--
big idiot operating the system

But...

[Monkeedude1212]

Bios sounds cooler and is easier to say. (Yoo-fee? Yoo-Figh? ooweef... damnit)

And whenever that clunky UI comes up, computer illiterate people go into a daze and stop asking so many questions.

I guess I'll start spending as much time with it as I can before it goes away... Start - Shutdown - Restart. F12 F12 F12 F12 F12 F12 F12 F12 F12 F12 F12 F12

Re:But...

[Splab]

Depends on manufacturer, some is F2, some is F10, some is DEL, some is F12 and there are probably a lot more fun combinations (like the one where you access the "hidden" Dell software for testing).

Re:But...

[mlts]

This is something PCs need to standardize on. My server has F1, my desktop has F2, my laptop has F10, my old Thinkpad has something else.

My suggestion:

[ESC] -- boot menu (with the ability to be password protected)
[F1] -- BIOS setup.
[F2] -- Diagnostics.
[F3] -- RAID setup.
[F4] -- Boot into built in Linux or WinPE image.
[F5] -- BIOS on the serial port. Standard 9600/8/n/1.
[F6] -- BIOS on the network with some way of setting the IP with or without a DHCP server, and perhaps with a password. Preferably a ssh client.
[F7] -- Reset all CPU overclocking info, and go back to a default standard.
[F8] -- Turn on/off management tools and LOM. LOM is great for some uses, a BIG security hole for others. The reason this is separate from the regular BIOS is so businesses can turn it on and off and password protect it, while giving users the ability to set normal settings.
[F9] -- Put a number on every monitor the machine sees, either onboard or other, and allow the user to select which one. AIX does this the first time it boots so it knows which monitor is the primary LFT (or HFT if running 3.2.5.x), and what are secondary.
[F10] -- Recovery image access.
[F11] -- Network booting access (password protected as an option.) This way, a machine can be told to boot from the network headless.
[F12] -- DBAN/decommissioning mode. On consumer PCs, this would be made *very* hard to access. However, on company machines, having the ability to tell all hard disks to do a secure erase, erase the NVRAM, zero the BIOS out, zero the TPM out (and set it back to default disabled) and reflash to a known good version on a true ROM chip, and erase multiple times any other memory would be a big help. Even better would be to present an official note with a timestamp and some validation code that a machine with a certain BIOS ID was completely zeroed out for audit reasons, and offer to save it on a USB flash drive. This way, IT knows that when this command is run and a completion message is put on the screen, that the machine was completely wiped.

I read the article...

[mcgrew]

Very uninformative. It sounds like UEFI is a BIOS (basic input-output system), only it's mouse/graphics based rather than text based. What am I missing here?

Re:I read the article...

[BJ_Covert_Action]

What am I missing here?

So far as I can tell, it just means that now the BIOS is going to consist of a complicated, semi-unintelligible set of menus (and/or icons) and point and click options rather than a simple tree of text-based menus with descriptive names. Don't worry though, by fixing something that isn't broken, things will get better.

Re:I read the article...

[Hatta]

I'm just glad it's UFEI and not UFIA.

Re:I read the article...

[xianthax]

traditional BIOS are an archaic nightmare really.

Most new technologies in them are work around hacks required to maintain some support for very old communication protocols (6GB SATA drives still have to support IDE mode why?) etc.

Give this a read:

http://duartes.org/gustavo/blog/post/how-computers-boot-up

Re:I read the article...

[nine-times]

I think they're just wrong to put the stress on EFI being "a point and click interface". I was under the impression (correct me if I'm wrong) that the deal with EFI is that it was a design of firmware for the system that ditches a lot of old legacy stuff. Incidentally, by upgrading the design, it will allow manufacturers to create a GUI to configure this stuff. But the GUI isn't really the point.

Re:I read the article...

[dlenmn]

It may be _a_ basic input output system, but it is not the BIOS, which -- if I understand correctly -- was originally how all input/output was done through PCs. Nowadays, your computer only uses the BIOS for input/output during startup, and then switches to something more advanced for your actual interface. In short, it's a holdover from the early days of PCs, is now only used for this niche role, and has required backwards compatibility all the way back to the original PC. I don't think that's wasted a huge amount of resources or anything, but I've always thought of it as old cruft ready to be replaced.

Re:I read the article...

[fuzzyfuzzyfungus]

TFA is largely worthless; but EFI is actually a pretty big deal. In essence, it keeps the really hair and complex bits of the BIOS(y hello thar, ACPI, I am talking to you) and adds a giant heap of further complexity. Haven't you always wanted a BIOS that needs its own FAT32(or HFS+ in Apple's freaky nonconformant implementation) partition in order to store its own device drivers?

Re:I read the article...

[xianthax]

GPT is part of the EFI standard.

It is used on some BIOS based system.

The problem with the standard MBR is that it does not support _partitions_ (note partitions, not disks) greater than 2 TB.

It also doesn't allow the start address to be higher than 2TB. This means your boot partition has to start in the first 2TB of the disk and be smaller than 2TB. The disk can actually be larger than 2TB.

Re:I read the article...

[BJ_Covert_Action]

If phrases like, "CMOS Settings," and, "IDE Controller," aren't descriptive enough for you, or they seem complicated and semi-unintelligible then you have no business dicking around with the low-level settings of your motherboard.

Re:I read the article...

[h4rr4r]

The current names are very specific and meaningful on most of the boards I deal with. This will not stay that way in a lowest common denominator GUI.

Re:I read the article...

[zlogic]

AMI Winbios was GUI-based. And it existed in 1995!

Re:I read the article...

[Warbothong]

Very uninformative. It sounds like UEFI is a BIOS (basic input-output system), only it's mouse/graphics based rather than text based. What am I missing here?

If by "BIOS" you mean "the system which loads the OS" then indeed UEFI is just a BIOS. There are also loads of other such systems, like the OpenFirmware (OFW) which, from playing around on my OLPC XO-1, can do traditionally high-level things such as scanning for Wifi networks, displaying a live Webcam image, interacting with the mouse, etc. There is also CoreBoot (formerly LinuxBIOS) which was designed for boot speed (on supercomputers), and there are probably loads more. In fact, my Amiga 1200 from 1992 had a boot menu which used the same GUI as the OS (like this http://www.gregdonner.org/workbench/images/wb_30_1.gif ), since part of the OS was stored inside onboard chips.

"BIOS" also has another, more formal meaning though, which is the programming calls it implements. Using these calls within a piece of code will work on any system with a BIOS, but not necessarily on any of the alternatives. However, they can be emulated on top of these other systems without anything noticing (like BootCamp does).

Re:I read the article...

[vlm]

If phrases like, "CMOS Settings," and, "IDE Controller," aren't descriptive enough for you, or they seem complicated and semi-unintelligible

Replaced with icons that look meaningless like squashed bugs, and names like "My CMOS Settings" and "My IDE Controller"

And Clippy. Don't forget Clippy.

Re:I read the article...

[BJ_Covert_Action]

I do, I just felt like playing the role of the pissed off crotchety old man, rather than the snarky but optimistic slashdotter. Don't worry, tomorrow I'll be playing the role of McBeth so all my posts will be in Elizabethan. =D

Re:I read the article...

[Ungrounded Lightning]

It may be _a_ basic input output system, but it is not the BIOS, which -- if I understand correctly -- was originally how all input/output was done through PCs.

BIOS was originally the small part of CP/M that had to be tweaked with the details of how to get to the devices on your particular hardware. It consisted mainly of things like character drivers for the keyboard, console text display (if present), and serial ports, and sector read/write drivers for the floppy disks.

As of the early xx86 IBM PCs the equivalent functionality (and more) had been added to the boot ROM, rather than having the boot ROM be JUST a basic boot-and-launch driver. Then with bigger/cheaper ROM in successive generations there was a race between bloat, "feature protection" (such as anti-overclocking) and "trojan horse features" (DRM, AMT, ...) in the BIOS vs. OSes recovering control of the hardware interfaces to improve flexibility for functionality upgrades (at the cost of having to understand more about the particular machine's hardware).

These days even Wikipedia doesn't seem to cover the origins.

Re:I read the article...

[gyrogeerloose]

Don't worry, tomorrow I'll be playing the role of McBeth so all my posts will be in Elizabethan.

We will proceed no further in this business:
He hath honour'd me of late; and I have bought
Golden opinions from all sorts of people,
Which would be worn now in their newest gloss,
Not cast aside so soon.

Re:I read the article...

[multi io]

"IDE Controller,"

The correct term is "IDE host adapter" or "IDE host bridge". The IDE controller sits on the device, where the BIOS can't reprogram or otherwise influence it in any way...

Re:I read the article...

[msclrhd]

I see you are trying to boot your computer.

Do you want to:
        * mess around with the boot options to make it non-functional?
        * reformat your drive containing critical key data?
        * boot into the all new ClippyOS 3.1?

Re:I read the article...

[Nimey]

J. Random User doesn't care about partitions, and doesn't want to fool around with the things. Eventually drives will commonly be bigger than 2TB.

Also 640K should be enough for anyone.

Re:I read the article...

[fuzzyfuzzyfungus]

That seems logical enough(and, indeed, my HID-reporting UPS shows up in GNOME panel as a battery device, complete with historical charge statistics and stuff, upon the installation of an appropriate driver).

My point was just that, as in the case of USB_HID, a standard that is too flexible ends up not defining enough to save you from hardware-specific drivers. Outside of the (mostly) safe realm of mice, keyboards, and basic gamepads, "USB_HID" isn't much more of an assurance of "no 3rd party driver needed" than "PCIe device" is.

MSI, huh

[daemonenwind]

As soon as I have a good-to-great experience with an MSI motherboard, this will be relevant to me.

They've been nothing but finicky to me.

Now, if ASUS, Intel or Gigabyte pick this up, or at least a few other mainstream manufacturers, let me know.

about time

[v1]

Macs went to EFI over four years ago. Hard to believe it took the windows machines this long to take the leap?

BIOS is the bane of the PC service tech. That's where manufacturers lock up the hardware and prevent you from being able to fix it or work on it. Good bye, and good riddance.

Re:about time

[Microlith]

They'll do the same with EFI.

Re:about time

[zmollusc]

My thinkpad 600x has a gui bios for the date/time, this is about 1993 vintage. Back then apple were trying to sell tablet devices.

Re:about time

[fuzzyfuzzyfungus]

As with most Mac "firsts", it is and it isn't. The Gateway 610 Media Center came out with an EFI-based motheboard firmware in 2003, 3 years before Apple started shipping units with EFI. It offered no particularly compelling advantages over legacy BIOS, so there was no great rush among other manufacturers to do the same.

Apple's "first" was not doing it; but doing it exclusively across all their models.

Re:about time

[man_of_mr_e]

No, Microsoft implemented EFI in Vista, although they only put it in the 64 bit versions IIRC. I can't wait for 32 bit Windows to die a horrible death... then more people (like Adobe) will start fully supporting 64 bit windows (and no, 64 bit Photoshop is not enough, let's get a 64 bit flash).

Re:about time

[Angst Badger]

Macs went to EFI over four years ago. Hard to believe it took the windows machines this long to take the leap?

The average user doesn't know and wouldn't give a shit if they did. Ergo, this kind of change in the PC market is driven by the interests of the vendors, as the consumer essentially has none. That said, it's worth noting that some consumer PCs have used EFI since 2003 and Itanium workstations were using EFI back in 2000, and x64 versions of Windows added support for EFI in 2008.

BIOS is the bane of the PC service tech. That's where manufacturers lock up the hardware and prevent you from being able to fix it or work on it.

It's worth noting that one advantage of EFI to vendors is precisely that it better enables them to lock down a system than BIOS does. While it doesn't have to be used that way, you can safely bet that many vendors will use it that way to the detriment of the consumer. It's also not without (in my opinion, valid) criticism for adding additional complexity to the system without actually resolving the problems of BIOS.

The main advantage appears lie in offering a GUI for end users to manipulate system settings that they lack the knowledge or inclination to tinker with. To be fair, it does add some convenience features and better support for large drives, but I haven't seen anything about EFI to get terribly excited about.

Re:about time

[daveime]

It is far more locked down and proprietary than the BIOS has ever been

Why do you think Apple has been using it for years ?

It's just another for hardware vendors to bundle their own software (ala USB keydisks that insist on loading their own crapware services) together with the hardware.

And we'll end up having to write BIOS emulators to lay on top of all the proprietary UEFI versions just to get our bootloaders' INT13h calls to work.

Re:about time

[chargersfan420]

Good bye, and good riddance.

I agree 100%. I have a Lenovo Ideapad Y710 and I would like to punch in the face whoever wrote its BIOS. I'd also like to kick in the junk whoever his/her boss was who approved it.
This laptop is capable of VT-x and was ADVERTISED with it as a feature, but it's disabled in the BIOS and can't be turned on.
This laptop is incapable of hibernating and sleeping in any OS except the crappy Vista it came with. A few versions of Ubuntu ago I was able to patch my DSDT table using the Intel compiler and then I was finally able to hibernate, but doing so still took just as long (3 minutes maybe?) to boot, so it was useless anyway. Since then the linux kernel people took out the patch that allowed an alternate DSDT to be used.
The Intel compiler says I have 12 errors in my DSDT alone, and who knows how many other BIOS tables have screwups that the Microsoft compiler doesn't care about because it knows how to get around the errors when booting a Microsoft system. According to Lenovo, Vista is the only supported OS, so if Vista doesn't have problems, they're "not bugs". Bullshit.

Anyway, enough ranting. The keyword behind UEFI is the U, as in Universal. It's still a pretty vague concept but it is definitely an area that could use some improvement, and I could see more operating systems than just the "vendor supported" one benefiting from such a system.

Re:about time

[jd]

Well, MIPS-based machines like the Broadcom BCM91250E use a BIOS called the Common Firmware Environment (CFE). Sun machines use a BIOS called OpenBOOT. The OpenBIOS pages are a little... old, but still informative about non-PC BIOSes as well as the platform-independent standards and their own open-source replacement.

Let's see. Claim 1 of the GP: The BIOS is where manufacturers lock up the hardware. Well, use OpenBIOS, Coreboot, Intel's Open Source TianoCore or any other replacement for that defective closed-source product you're using. Don't blame BIOSes, blame the implementation. Just because one BIOS developer was high on substances of questionable legality does not make all BIOSes equal.

Implicit Claim of the GP: All BIOSes are One BIOS. There Can Be Only One! Muahahahahaha!

Reality: There's so many fully or partially Open Source BIOSes out there it's not funny. There are plenty of alternative Closed Source BIOSes you can use as drop-in replacements as well. If you don't like the BIOS, don't blame the concept, blame yourself for not replacing it with something you DO like.

(Me? Suffer fools gladly? There may be suffering involved, yes. I'd make a great Grand Inquisitor.)

Increasingly old and gray gen-xer says

[phrackwulf]

You kids today with your GUI firmware. Spoiled rotten! That's what you are! WHEEZE.. Excuse me while I go get more of these tattoo's removed. Ouch, arthritis.

Wow

[Anonymous Coward]

That is the worst reporting on EFI I've ever read. They spend half the article trying to make the false claim that the switch from BIOS to EFI has anything to do with its visual interface (I was using a pixel-and-mouse-based GUI BIOS 15 years ago and I was using a text-only EFI interface just a couple days ago). Then they end with a quote about how the biggest difference between BIOS and EFI is that EFI is written in C? How would that have any relevance? Maybe they were trying to say that EFI requires the execution of architecture-independent code (the EFI Bytecode)?

Sadly there was no mention of Open Firmware, either. Is there any reason Intel made their own Open Firmware knock-off beyond NIH syndrome?

Re:Wow

[man_of_mr_e]

EFI has been around for about 15 years, but was an Itanium thing... UEFI was created about 5 years ago and adapted it for use with x86 and x64 computers. Apple has been using it since 2006 in all their Mac based PC's.

Unfortunately, OpenFirmware was withdrawn from the IEEE in 1998, so OpenFirmware isn't really a standard. And there wasn't really an Open Source implementation until 2006 (a year after UEFI was introduced).

So to say (paraphrasing) "Why didn't intel use OpenFirmware instead of creating their own?" is to ignore the face that OpenFirmware was a non-player at the time.

That;s okay - I'll just get another battery for it

[tomhudson]

n/t

BIOS vs. EFI

[tepples]

Very uninformative. It sounds like UEFI is a BIOS (basic input-output system), only it's mouse/graphics based rather than text based. What am I missing here?

EFI, which is already used in Mac computers with Intel CPUs, doesn't implement the syscalls inherited from IBM PC BIOS. Things like Boot Camp add PC BIOS on top of EFI.

Re:BIOS vs. EFI

[0100010001010011]

Yo Dawg. I heard you liked using a basic input output system to boot your computer.
So we put a basic IO system to boot your basic IO system for your system.

BIOS is dead. Long Live BIOS?

I've moved all my machines to GPT. I understand the need to keep around some legacy stuff, but BIOS and the MS-DOS partition table really need to step aside for some new technology. They lasted us ~30 years, but the hoops you have to jump through to boot some newer stuff is getting annoying.

Re:BIOS vs. EFI

[Korin43]

It's to be expected that the Mac version of Steam would be slower than the Windows version, but not because Macs are slower. Games are generally heavily optimized in order to get decent frame rates, and those optimizations may be platform dependent. I expect that as time goes on, the different between the Mac and Windows version of games on Steam will become smaller.

More to the point, the person you were responding to was talking about hardware, as in "If you took that fastest Apple laptop vs the fastest non-Apple laptop and installed Windows on both, the Apple one would be faster." I doubt this is true anymore, but it's plausible that it was at some point.

Re:So ....

[vbraga]

Any modern operating system will not be affected.

Older operating systems, like DOS, used BIOS services to accomplish certain tasks - like accessing the floppy disk, if I recall correctly. This kind of legacy operating system will stop working when the BIOS is gone.

BIOS do have other rules. But nothing major.

BIOS has been dead for 10+ years already...

[Antony T Curtis]

The PC BIOS started out as a simple nifty way to abstract away the underlying hardware from the operating system so that we didn't have to have drivers for every little thing.

Nowadays, we have drivers for every freaking little thing.

Why? The BIOS failed to evolve into the 32bit era.

It would be great if there could be a piece of flash memory on the motherboard which contains all the Basic I/O driver for each of it's peripherals... And for all expansion cards to have a bit of flash memory for their drivers.

Then the operating system (Windows/Linux/whatever...) can just use all the devices through their firmware driver.

(Fed up of drivers)

Re:BIOS has been dead for 10+ years already...

[xianthax]

yea sounds great. Flashing my BIOS/EFI every time theres a driver update, can't wait.

Re:BIOS has been dead for 10+ years already...

[Rich0]

Well, the logic at that time was that the driver only exposed an API at a low level and wasn't buggy.

So, there wasn't a need to update the BIOS all the time.

Why exactly should drivers require frequent updates? When was the last time you flashed the firmware on your hard drive, or whatever?

In any case, the approach has its limitations as you indicate.

Re:BIOS has been dead for 10+ years already...

[nine-times]

Yeah, I've had a little bit of a longstanding beef with drivers. I don't frequently have problems any more (Mac user) but it's always kind of stupid when you install a new OS and then realize you don't have a driver for your networking interface. Nice little catch-22.

Of course I've always imagined that there was something better that could be done. Your idea of including some sort of flash memory onboard had occurred to me and is actually feasible these days. Years ago, I was thinking about ROM chips with the most basic drivers possible. Even if they've have to be updated later, it'd be nice to have something to get you going.

But then of course in the current open-source atmosphere, it's disappointing that hardware vendors can't standardize a bit. Maybe I'm stupid, but does each ethernet card need totally different drivers from the other ethernet cards, or could we get them to present a standard interface to the OS in a way that made them essentially interchangeable? Or printers? Or, I don't know, monitors? Lots of these pieces of hardware seem pretty simple to me, and it doesn't seem like their functions are being revolutionized every 6 months.

Can't this stuff be made simpler?

Oh, I hope not

[Anonymous Coward]

I looked into EFI a bit (the technical details of GPT partition tables), and it just screams overengineering to me. GPT, specifically, bothers me because it allows partition records to have variable size and even to cross sector boundaries, which makes bootloaders way harder to implement (that was the context in which I did this resarch). Despite all this, there is an upper bound to the number of partitions you can have (512 I think), which is not the case in DOS tables.

Now, I don't know all that much about the rest of EFI, but I have gotten the impression that things are the same here. It contains a complete driver infrastructure, with drivers that are guaranteed to be broken and incomplete, and reimplements basically everything. And what is the point of all of this? Prettier boot screens.

It's not even the right way to go about it! That would be to load Linux in the simplest way possible (for which BIOS is enough) and show a pretty menu using all of the available software and libraries, and switch OS using kexec (or equivalent in other OSs). If I were to write such a program, I could boot CDs, netboot, do power management (pretty off button) and have pretty 3D graphics, and perhaps even use a library like GTK. Then, what would be the point of all the stuff going on in the EFI? DRY is right. Let that thing die.

Re:Oh, I hope not

[tepples]

It's not even the right way to go about it! That would be to load Linux in the simplest way possible (for which BIOS is enough)

Even BIOS is overkill to load Linux if your chipset supports coreboot.

Re:Oh, I hope not

[Anonymous Coward]

I didn't know coreboot supported loading linux directly. For those of us stuck without it, a bootloader with linux support that fits in the MBR would be a good fit in the boot stack that I described previously. Coincidentally, I wrote such a bootloader (which is when I read up on EFI), and this seems as good a place as any to give it away. Here it is.

Re:Oh, I hope not

[LordVader717]

512 partitions should be enough for anyone.

Re:Oh, I hope not

[evilviper]

Despite all this, there is an upper bound to the number of partitions you can have (512 I think), which is not the case in DOS tables.

WTF are you smoking? For someone whose supposedly writing a boot-loader, you sure don't sound like you have a clue...

DOS partition tables have an upper limit of FOUR (4) partitions!!! Got that? Not unlimited. Not 512. FOUR (4)!

The hack to get around that limit is an EXTENDED partition, which then contains "logical" partitions. I doubt 512 partitions is going to start looking too limited any time soon, but when it does, someone will no doubt come up with a hacky cludge to work around that limit as well...

Bluetooth Keyboard/Mouse?

[SlothDead]

Will I be able to change BIOS/UEFI settings using my bluetooth keyboard/mouse, or will I still have to plug in my old keyboard whenever I want to configure something?

Re:So ....

[man_of_mr_e]

Linux has supported EFI for quite some time. And EFI has BIOS compatibility modes (or it can.. that's one of those "extensible" things). Mac's, for instance, use EFI and have since they went Intel (possibly earlier, but I think the Intel macs were the first).

Linus is not a big fan of EFI though.. says it's a bigger, clunkier bios.

So we get to replace a simplisitc load of crap...

[John Hasler]

...with an insanely complex load of crap (but it's "graphical" so it must be better).

*BSD and Linux support EFI

[tepples]

Is it likely to cause problems for Linux and BSD?

Intel Macs already use EFI; therefore at least one BSD (Darwin) already supports it. Linux supports EFI too.

Finally!

[Denis Lemire]

It's about time we drop the kludge that is BIOS. EFI is also required for Windows to be able to boot from GUID partition table drives which in turn are going to be needed to handle upcoming huge drives that exceed BIOS LBA limitations.

I for one will not miss the BIOS. It's about time commodity PCs catch up to standards that Apple has implemented way back in 2006 (all Intel Macs use EFI and GPT).

Re:Finally!

[visualight]

No sir, EFI is the kludge here. Slow to boot, needlessly abstract and complicated, doesn't bring anything to the table we don't already have...Anyone who thinks EFI is a good idea is either uninformed, misinformed, or employed by Intel.
Read: http://kerneltrap.org/node/6884

Linus continued in a followup email, "don't get me wrong - the problem with EFI is that it actually superficially looks much better than the BIOS, but in practice it ends up being one of those things where it has few real advantages, and often just a lot of extra complexity because of the 'new and improved' interfaces that were largely defined by a committee." He went on, "so EFI has this cool shell, a loadable driver framework, and other nice features. Where 'nice' obviously means 'much more complex than the simple things they designed in the late seventies back when people were stupid and just wanted things to work'. Of course, it's somewhat questionable whether people have actually gotten smarter or stupider in the last 30 years. It's not enough time for evolution to have increased our brain capacity, but it certainly _is_ enough time for most people to no longer understand how hardware works any more." As for BIOS, Linus noted, "not that I'd ever claim that the BIOS is wonderful either, but at least everybody knows that the BIOS is just a bootloader, and doesn't try to make it anything else."

Useless abstraction layers are useless.

Re:Finally!

[Denis Lemire]

Interesting counterpoint - I mean that, not being sarcastic.

Maybe EFI isn't a golden solution, I'm not familiar enough with EFI on a low level to comment. Perhaps I just blindly support it because I just want 'SOMETHING' to replace BIOS. Specifically I like that the Mac platform can be entirely managed from the OS, ie) setting boot device priority, power management etc along side the rest of your OS settings. The whole PC model of having certain settings configured only in BIOS and others via the OS seems rather odd by modern standards. It gets quirkier when there are overlaps in features between BIOS settings and OS settings (power management being the best example).

I'd also like better features on power-up. Specifically, as I still setup a few headless PCs for BSD and Linux servers, it annoys me that serial console is not available until, at a minimum, you reach the bootloader of the OS. All 'settings' in BIOS are completely inaccessible in a headless serial environment as things currently stand.

I also rather enjoy the 'target disk mode' on Macs that will instantly turn your system into an external firewire attached drive on startup. This is extremely handy for recovering files from an unbootable or otherwise corrupt OS without having to physically remove the drive.

Adopting EFI wouldn't necessarily mean we gain such features, but it seems to me EFI would make such features more feasible. I guess in summary, I'm not necessarily pro EFI, but I want to see something far more modern and capable replace the obsolete BIOS we are currently stuck with.

Perhaps eliminating BIOS and adopting EFI isn't even necessary to unify things and address the limitations, I may just be equating the two even if they are not necessarily mutually inclusive.

Regardless, the PC world needs something better than BIOS, I'm not aware of any alternatives to EFI that may better accomodate this.

Re:Finally!

[KonoWatakushi]

I feel just as strongly about replacing the BIOS, and indeed just about anything would be better. UEFI is not though; it effectively transfers ownership of your hardware to some untrusted third party. It is effectively DRM on the bare metal, which can't be removed.

If you want to advocate for something, try coreboot.

Just say no to "trusted computing" and "trusted platforms"; this is almost universally an indication that someone else can trust your hardware to enforce their restrictions.

Re:Finally!

[Denis Lemire]

I would be all for having a Linux based firmware like coreboot replace our current mess that is the BIOS! Wonder if that could actually gain ground or if it's just a pipe dream though?

Must EFI by necessity bring "trusted computing" with it though? Maybe I need to take a closer look at the specs. Though Apple systems are EFI based, they haven't really used it to lock down the computer in any sort of way. Are you suggesting they simply haven't decided to do that but the capability is ready and waiting, not sure I follow how the two rela to each other. I keep bringing Aplle up in this discussion seeing as how I can't think of any other mainstream vendor that has ditched BIOS and/or adopted EFI.

If a system was completely locked down beyond my personal threshold of tolerance, I simply wouldn't buy said motherboard or system. It should be possible to adopt EFI without implementing the closed systems you fear, no?

Re:Finally!

[KonoWatakushi]

Actually, it is ironic that Apple hasn't moved to UEFI. They are using one of the older versions of EFI before they stuffed it with the various "trusted" crap.

Unfortunately, coreboot continues to have very limited board support, as most vendors are not at all forthcoming with chipset documentation. It is surprising that the various board manufacturers haven't embraced it though; it would be one less thing to license. It may be that NDA issues prevent them from doing so.

I'm not sure if anyone can say with certainty what the future will hold if we embrace UEFI, and we may not even have the choice in many cases. With all the anti-competitive behavior in the industry though, it is certain to be abused.

Primordial?

[michaelmalak]

The PC was never "primordial". It was an assemblage of mostly off-the-shelf components that was inferior to its competition but had the IBM label slapped on it. Immediately, it became the reference standard against which competitors benchmarked themselves in order to be able to advertise "100% PC Compatible", with the ability to run Microsoft Flight Simulator being the strongest test of compatibility. A reference standard is not "primordial". To the contrary, it took years to add the slightest bit of flexibility to this rigid standard -- e.g. defining the bus timings independent of the CPU clock in order to accommodate faster CPUs.

BIOS is not dead

[Anonymous Coward]

From the faq at uefi.org:

Q: Does UEFI completely replace a PC BIOS?
A: No. While UEFI uses a different interface for "boot services" and "runtime services", some platform firmware must perform the functions BIOS uses for system configuration (a.k.a. "Power On Self Test" or "POST") and Setup. UEFI does not specify how POST & Setup are implemented.

Re:whats old is new again

[PalmKiller]

Hey here is a nice pic of WinBIOS I found...copyright was 1994, so you got the street date about right :).

http://www.funkygoods.com/schwarzschild/2008_11/ami_titan_05_s.jpg

Re:UEFI == BIOS

[man_of_mr_e]

I suggestion you spend some time here. While you can say "it's just a bios" with a very loose definition of "bios", it's really not. Saying so means you don't really understand what a bios is, nor what EFI is. BIOS is very specific.. it has a specific set of interrupt vectors it services with a specific set of commands. Whether or not it has a GUI is irrelevant, because there are already GUI based BIOS's and there are text based EFI's.

EFI, on the other hand, is extensible in that you can plug in different modules (such as a BIOS compatibility module), or a MacOS module. Apple use EFI, and part of bootcamp is to include a BIOS module for it's EFI.

BIOS is written in assembly. pretty much as to be. UEFI (other than the bootstrapper) can be written in almost any language, including C.. it's possible to use Java or C# or whatever, but it would require implementing a runtime that could work in EFI which I don't think exists right now.

In short, the BIOS has been holding PC's back for decades. Moving to EFI will allow a lot of new functionality.

I wish the whole Intel/Windows/PC ....

[AnonymousClown]

I wish the whole hardware architecture would change. The IBM PC was a hardware hack to begin with because IBM almost missed the PC boat and had to rush something out the door - and in the process made Microsoft what it is today. It was never designed properly. Over time to keep backward compatibility, the PC kept it's legacy crap.

If the hardware vendors got MS on board, they could change it and subsequently create some new machines with much better performance and the subsequent sales to go with it - it would bust the industry out of it's stagnation.

Re:So ....

[jimicus]

IIRC EFI also defines a standard way for the OS to update settings. So you could update BIOS settings on the fly without having to reboot.

Quite what the benefit of this is when any modern OS basically ignores the BIOS as soon as the kernel has started running is a separate issue entirely....

Re:Security

[e2d2]

HW Manufacturers will require EFI firmware to be signed in order to install it. See "executable verification" in this PDF

Re:Security

[fuzzyfuzzyfungus]

The sheer number of repetitions of "trusted computing" and "trusted platform" in that document make the hair on the back of my neck rise.

Re:Security

[alexborges]

SPARCs, PARISCs and virtually anything non-intel have this kind of thing. Believe me, security is MUCH worse on intel's BIOS than on those architectures. Thank god BIOS is to die.

Re:So ....

[vlm]

IIRC EFI also defines a standard way for the OS to update settings

That's "Enhanced Rootkit and Virii Support (tm)" not for the OS.

DRM with UEFI

[KonoWatakushi]

As far as I know, the major "feature" of UEFI over the original EFI is signed modules, ultimately allowing for control over what may be booted. The original EFI, while still bloated and overly complex (though considerably less so), would have been a clear improvement over the BIOS. However, the current incarnation of UEFI may be downright dangerous to our freedoms.

As bad as the BIOS is, at least we can run the OS of our choice. With UEFI, we still may--for now. Unfortunately, that "feature" may be removed in the future, just as Sony did with Linux on the PS3.

Or at least that is how I understand it. There was a lot of concern over this in the past, but strangely, I haven't seen much recently. I would love to be rid of the BIOS, but something like coreboot would be much better, as it would allow for a completely open platform, and is focused on actually booting the machine.

Dumbing down the bood is a GOOD idea.

[Ungrounded Lightning]

Am I the first to say that dumbing down low level config is a bad idea?

IMHO dumbing down the boot is a GOOD idea. There should be as little as possible between the raw hardware and the OS to tamper with the user's control of his system.

(Example of such tampering: Intel AMT - a built-in man-in-the-middle attack on the machine, sold to corporate IT departments as a FEATURE.)

But this stuff is not dumbing down (i.e. stripping down) the BIOS. It's adding MORE JUNK. Breaking the OLDER junk is incidental to doing a poor job adding the new crud (or deliberately suppressing the older functionality).

Re:Keep Apple's crap away from my PC.

[Mr. Slippery]

The only brand is USSR and all of the products suck but there is no alternative because they are the alternative

So, you're talking about Apple here, right?

Certainly your remarks make no sense if applied to free software. Free software OSes are available for a multitude of hardware, and free software users enjoy a variety of software choices. For kernels there's Linux, NetBSD, FreeBSD; for system level stuff there's the GNU and BSD tools; for GUIs there are many options built around Gnome, KDE, and Xfce. For the stuff I use my computers for -- e-mail, web browsing, text editing and word processing, music creation and playback, image manipulation, and video playback -- I find many alternatives available.

Have fun not using your computer for fun but to make a point.

I find freedom to be much more fun than its absence. If you don't, you have my pity.

Re:So ....

[bhtooefr]

OpenFirmware (or OpenBoot) is fairly extensible.

One thing with all of these... they all support a much more flexible device driver system. BIOS device drivers are a nightmare to deal with nowadays, whereas OF and EFI can run halfway decent drivers - the ultimate goal being, you can just install a driver for an "EFI-compatible graphics card," and whenever you upgrade your graphics card, EFI calls take care of everything.

Oh, and both EFI and OF are CPU architecture-independent in theory (and, EFI is architecture-independent in practice - the same card, with the same drivers, IIRC, will work in Itanium or x86, but a card that works in an OF Mac may not work in an OB Sun SPARC system, due to drastically different underlying system architectures.)

Re:So ....

[mister_dave]

I quite like Linus on EFI:

...EFI has this cool shell, a loadable driver framework, and other nice features. Where "nice" obviously means "much more complex than the simple things they designed in the late seventies back when people were stupid and just wanted things to work".

Re:Security

[lgw]

There are already BIOS rootkits (or malware of some sort that tires to re-infect you), and at least UEFI will attempt to address the issue (most PC motherboard BIOSs can be reflashed from Windows; a fact that has not escaped the notice of botnet writers. Ultimately we need something like trusted computing to lock down the BIOS, and as I understand it UEFI has some flexibility, so it doesn't have to be TPM-based.

Exactly

[Benfea]

Making the BIOS settings accessible to more stupid people will not make computer maintenance easier. Anyone too dumb to figure out how to use BIOS as it exists now has no business being there in the first place.

Apple uses EFI in all intel based machines

[theolein]

Apple has been using EFI in its intel based Macs since 2006. The EFI firmware allows the use of emulation modules so that, as an example, Mac EFI has a BIOS emulator allowing Macs to boot into Windows. On Macs the BIOS emulator is not perfect as there is no way you can actually edit or modify it without running the risk of bricking your machine after damaging the firmware, but there is an open source EFI interface for Macs called rEFIt that allows you to boot to a boot menu from where you can boot into Mac, Windows or Linux for example.

Amit Singh has written a book on prgramming the EFI interface on Macs which, for anyone considering getting into EFI programming is a good point to start with. Armed with a second hand Intel Mac Mini from ebay, you could get a head start by the time MSI release their motherboards.

Completely wrong!

[Noitatsidem]

I can't believe this is on /. This is completely wrong! BIOS Will not die, the UEFI Website itself says it. "Q: Does UEFI completely replace a PC BIOS? A: No. While UEFI uses a different interface for "boot services" and "runtime services", some platform firmware must perform the functions BIOS uses for system configuration (a.k.a. "Power On Self Test" or "POST") and Setup. UEFI does not specify how POST & Setup are implemented." -- From their website, if you don't believe me, http://www.uefi.org/about/ Please try to get your facts straight before posting.

Re:Security

[Lunix Nutcase]

That's the *chortle* brilliant *chortle* slashcode developers at work.