Reply to post: No, but seriously ...

No, but seriously ...

Because computers didn't work properly with BIOS.

Computers did, of course, work properly with BIOS.

Well, if they didn't (and most didn't, at least some of the time) it usually wasn't the BIOS's fault.

UEFI is veritably the road to hell -- paved with good intentions. The good intentions are many: It's supposed to support booting from hard disks that are larger than a BIOS can handle. It's supposed to provide a mechanism whereby a an x86 PC can boot straight into protected mode, so the chip makers can finally stop supporting legacy real mode operations in their precious silicon. It's supposed to enable expansion cards to be made with on-board firmware that can work in a PCI/PCIe slot of any computer regardless of the type of CPU fitted (Intel wanted this so that cards designed for x86 could be used in Itanic^WItanium systems). It's supposed to provide an OS-agnostic pre-boot environment from which system administration functions can be run. It's supposed to provide a level of security that will ensure that a system will only boot from a properly signed and authorised image.

The big problem is that it was designed by a committee, a committee of interested parties who each wanted to bring their own pet feature to the standard, and who apparently didn't pay too much attention to what else was getting in through the door; a committee that didn't have the budget, the trust, or the authority to take actual responsibility for the monster they created.

Have you seen the size of the UEFI spec? Have you ever tried to read it? It's a fine example of a document that was put together by people who knew what they were trying to say, but didn't think to say it in a way that would be accessible by anyone else. To say that it was impenetrable would be kind. It's hardly surprising that it's taken several generations of supposedly UEFI-compliant motherboards and their firmware to get to anything that works somewhat consistently between different boards and vendors. The standard is far too ambitious, encompasses far too much, and explains far too little. Someone should have taken it in hand and whittled it down to usable size.

Secure Boot is actually a very good idea -- it's in the users' interest to be able to have some confidence that the OS on a PC hasn't been suborned by malware. The problem with it is that the UEFI Forum didn't -- wasn't in a position to -- create a master set of vendor-neutral keys and set up a service whereby OS providers could get their OS images signed. The meant that Microsoft, as the biggest commercial provider of OS images, set up the signing infrastructure themselves, and own the main OS verification keys that board manufacturers supply preinstalled on their boards. This means that the boards that are sold accept only Microsoft-signed OS images, at least out of the box, and in order to install another image it is necessary either to get Microsoft to sign that image with their keys (which some Linux distros have done) or to add a new set of keys to the board (which not all boards allow).

For most users, the main advantage of UEFI is that it supports GUID partitioning, and so enables disks larger than 2TiB to be visible at boot time. Even that's becoming less important than it once was, as many PCs are now fitted with a small (certainly less than 2TiB, at today's prices) SSD and larger spinning rust for storage, but the spinning rust doesn't have to be visible at boot time, so a traditional real-mode BIOS booting a GUID-capable OS will work just fine.

When SSDs drop in price by another order of magnitude it may again be important to be able to boot from GUID disks, but by then I hope UEFI will have died the death it so richly deserves and been replaced by Coreboot or Open Firmware or something else that does the jobs that actually matter without the bloat of UEFI.