BIOS Will Be Dead In Three Years 532
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.'"
A GUI for the motherboard? (Score:2, Funny)
Re:A GUI for the motherboard? (Score:5, Informative)
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? (Score:5, Informative)
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: (Score:3, Informative)
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
Re: (Score:3, Informative)
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. [etherboot.org] 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
Re:A GUI for the motherboard? (Score:5, Funny)
I haven't seen a floppy in almost 10 years.
I'm glad you got over your erectile dysfunction.
Re:A GUI for the motherboard? (Score:5, Informative)
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? (Score:5, Interesting)
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? (Score:5, Insightful)
Re:A GUI for the motherboard? (Score:4, Funny)
"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? (Score:4, Insightful)
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? (Score:5, Informative)
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? (Score:5, Informative)
Oblig:
http://en.wikipedia.org/wiki/UEFI [wikipedia.org]
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? (Score:4, Interesting)
Exactly (Score:5, Insightful)
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.
Re: (Score:3, Informative)
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 sp
Apple uses EFI in all intel based machines (Score:5, Interesting)
Apple has been using EFI in its intel based Macs [wikipedia.org] 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 [sourceforge.net] 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 [osxbook.com] 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.
Re:A GUI for the motherboard? (Score:4, Interesting)
Re: (Score:3, Funny)
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: (Score:3, Informative)
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?)
OhNo! (Score:2, Insightful)
Am I the first to say that dumbing down low level config is a bad idea?
--
big idiot operating the system
Re: (Score:2)
Dumbing down the bood is a GOOD idea. (Score:3, Interesting)
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 do
But... (Score:5, Funny)
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: (Score:3, Informative)
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: (Score:3, Insightful)
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
I read the article... (Score:5, Insightful)
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?
BIOS vs. EFI (Score:5, Informative)
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 (Score:5, Insightful)
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: (Score:3, Insightful)
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 no
Re: (Score:3, Insightful)
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. F
Re:I read the article... (Score:4, Insightful)
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... (Score:5, Insightful)
Re:I read the article... (Score:5, Funny)
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... (Score:5, Funny)
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: (Score:3, Informative)
"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: (Score:3, Funny)
Re: (Score:3, Insightful)
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... (Score:4, Insightful)
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: (Score:3)
I'm just glad it's UFEI and not UFIA.
Re:I read the article... (Score:5, Informative)
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 [duartes.org]
Re:I read the article... (Score:5, Insightful)
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... (Score:4, Insightful)
It may be _a_ basic input output system, but it is not the BIOS, which -- if I understand correctly -- was originally how all [wikipedia.org] 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... (Score:4, Informative)
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... (Score:5, Insightful)
Re: (Score:3, Interesting)
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
Re:I read the article... (Score:4, Informative)
AMI Winbios was GUI-based. And it existed in 1995!
Re:I read the article... (Score:5, Interesting)
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 [gregdonner.org] ), 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: (Score:3, Informative)
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: (Score:3, Funny)
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.
So .... (Score:2)
Other than the fact that there won't be any BIOS left, how does this affect most of us?
Is it likely to cause problems for Linux and BSD? Or is it just all going to be status quo but with an old piece of technology no longer present? Will the *AA's insist that the replacement allow them to lock down machines so we can only do what they approve of?
I really have no idea of the ramifications of the loss of BIOS.
Re: (Score:2)
Is it likely to cause problems for Linux and BSD?
Nothing big other than another variable to throw in the mix... Macs have never had a BIOS and seem to run Windows, Linux, and BSD pretty well. IIRC, they just emulate a BIOS.
Re: (Score:3, Informative)
Re:So .... (Score:4, Informative)
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.
Re:So .... (Score:4, Interesting)
I quite like Linus on EFI: [kerneltrap.org]
Re: (Score:3, Interesting)
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 architect
*BSD and Linux support EFI (Score:5, Informative)
Is it likely to cause problems for Linux and BSD?
Intel Macs already use EFI [wikipedia.org]; therefore at least one BSD (Darwin) already supports it. Linux supports EFI too.
Re: (Score:3, Interesting)
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:So .... (Score:4, Insightful)
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.
MSI, huh (Score:3, Insightful)
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 (Score:2, Insightful)
Macs went to EFI [wikipedia.org] 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 (Score:5, Insightful)
They'll do the same with EFI.
Re: (Score:2)
Exactly
Of course MS didn't bother with it (maybe Windows 7 is compatible, I'm not sure about Vista), and manufacturers neither.
I'm not sure it's going to be better (that is, they're going to do it properly)
What, floppy drive for installing Win XP in Sata?? EFI would take care of that
Re:about time (Score:5, Informative)
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: (Score:3, Informative)
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: (Score:3, Informative)
Apple's "first" was not doing it; but doing it exclusively across all their models.
Re:about time (Score:5, Insightful)
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: (Score:3, Interesting)
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 wa
Re: (Score:3, Insightful)
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: (Score:3, Insightful)
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 [openbois.org] 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 [sourceforge.net] or any other replacement for that defective closed
ugh (Score:2)
That screenshot lowers sperm count.
If they can't make it look nicer then I'll keep the old clunky, please.
Increasingly old and gray gen-xer says (Score:4, Funny)
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 (Score:5, Interesting)
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 (Score:5, Informative)
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 (Score:4, Funny)
n/t
BIOS has been dead for 10+ years already... (Score:5, Interesting)
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: (Score:3, Insightful)
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 w
Re: (Score:3, Interesting)
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.
Oh, I hope not (Score:4, Interesting)
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 (Score:4, Insightful)
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 (Score:5, Funny)
512 partitions should be enough for anyone.
Re: (Score:3, Insightful)
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 lo
Bluetooth Keyboard/Mouse? (Score:4, Interesting)
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?
So we get to replace a simplisitc load of crap... (Score:5, Funny)
...with an insanely complex load of crap (but it's "graphical" so it must be better).
Finally! (Score:3, Interesting)
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! (Score:5, Informative)
Read: http://kerneltrap.org/node/6884 [kerneltrap.org]
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! (Score:4, Interesting)
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: (Score:3, Insightful)
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 [coreboot.org].
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: (Score:3, Insightful)
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 su
Re: (Score:3, Insightful)
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
Primordial? (Score:3, Informative)
BIOS is not dead (Score:5, Informative)
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.
DRM with UEFI (Score:5, Interesting)
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 [coreboot.org] would be much better, as it would allow for a completely open platform, and is focused on actually booting the machine.
Completely wrong! (Score:3, Informative)
Re:whats old is new again (Score:5, Interesting)
http://www.funkygoods.com/schwarzschild/2008_11/ami_titan_05_s.jpg [funkygoods.com]
Re: (Score:3, Insightful)
I suggestion you spend some time here [wikipedia.org]. 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 differe
Re:Security (Score:5, Informative)
HW Manufacturers will require EFI firmware to be signed in order to install it. See "executable verification" in this PDF [intel.com]
Re:Security (Score:5, Interesting)
Re: (Score:3, Informative)
That's the *chortle* brilliant *chortle* slashcode developers at work.
Re:Security (Score:4, Interesting)
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.