The value of UEFI is surely dubious. I recently had to update my BIOS using Windows PE since there was no way of doing this on Linux. Of course my default boot was reset. The funny thing was though that I could repair my Linux boot using Win PE.
Before the only way was either fdisk /mbr to reset for Windows or boot a Linux system on stick/CD and rebuild grub/lilo. The latter has gotten unreasonably complex though so I rather wouldn't do this manually.
My verdict is that UEFI does something right, but created for the enterprise sector carries way too much complexity. Obviously so complex that everybody ends up using the original same code base.
Your computer's awful implementation says nothing about UEFI as a whole, it just means that the vendor you bought your hardware from sucks at writing firmware. I update my UEFI from the standard fwupdmgr command in Linux and it maintains the standard bootloader. In fact, unlike BIOS, it allows me to select a bootloader on startup if I want.
The absolute hackery that was necessary for BIOS to do something as basic as booting an operating system was due for removal. And looking at the rest of the bootstrapping landscape (ARM phones, Linux routers, you name it), I'll take UEFI over any of its competitors any day of the week.
Unfortunately, there's plenty of vendors that suck at writing firmware, and most usually give up on updating it immediately after they've EOL'd the hardware revision. The hackintosh project mostly works by replacing the bugs from the vendor firmware into the bugs that apple expected from their x86 line of pcs.
If most vendors suck at writing firmware, it might be a problem with the spec though.
BIOS didn't have a spec at all, it was hacks stapled to reverse-engineered chips that were Good Enough To Ship for IBM decades ago.
Most of the alternatives require brand+model specific kernels and boot mechanisms, at least UEFI has a standard. I dream of the day smartphones run UEFI instead of the weird factory bootloader + custom uBoot mess that we're in right now.
Look, it's a step in the right direction for sure. It's just too big of a leap for my taste.
To boot an OS you need to initialize core 0, RAM and some storage controller. Throw in a serial port for debugging. Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.
Having a display, mouse, keyboard or network is an opinion. GUID partitions are an opinion. And if it comes to opinions, I'd rather all of the extras be handled by third parties instead of within a giant spec that will be vibe-conformed to.
Initializing core 0 on a modern system requires a Pentium CPU preconfiguring Minix to bootstrap the CPU. Training RAM is a whole new challenge. The simplistic designs of the 20th century don't apply anymore. Having USB to control boot is a necessity now and with Thunderbolt offering DMA access, configuring trust at a low level has also become a requirement.
There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.
I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.
Yeah, and booting the raspberry pi is done via the GPU. What was that you were saying about shitty vendors?
USB is a value-added feature (with a spec that rivals UEFI in complexity), and despite having owned 5 apple machines, I'm not sure I have ever used thunderbolt... EVER
With regards to trust, the only reasonable approach is "can be overridden by the legitimate owner" with a "delete everything on request by whomever has physical access to the device" fallback. Yeah, theft will be a problem but 1984 would be a bigger problem.
That's how it works on ARM, but other people in this same comments section are complaining about having to build u-boot and Linux differently for every device model because there's no commonality.
Also why initialize RAM? Isn't cache-as-RAM enough for a stage zero bootloader?
Eh, I was thinking more along the lines of populating the memory regions mapped to hardware.
Having to build u-boot for every device model is a good thing, it means that there's less functionality abstracted-away by some never-to-be-updated vendor-provided firmware.
It's good from the hardware designer's perspective since less things are their problem. It's bad for the software creator since more things are their problem, and for the user since it's hard to find compatible software for their hardware.
It's also the normal way the entire history of computers has always worked, except for the IBM PC and its derivatives. If you want to install an OS on a 2025 OnePlus Blahdy Blahdy Blah you need to find an OS explicitly built for a 2025 OnePlus Blahdy Blahdy Blah - one for a 2025 OnePlus Blahdy Blahdy or for a 2026 Blahdy Blahdy Blah will not work and will likely just brick your phone. And nobody is out there building every OS for every phone model. But I can install Linux built for a Lenovo laptop onto a Dell desktop or a SuperMicro server.
We are in agreement that phones (and embedded devices in general) are worse. My claim is that they are worse because UEFI is too fucking complicated to implement, so nobody bothered. Which resulted in linux being built with the hardware descriptor table for the device in question, itself implemented by the vendor and published (and eventually merged upstream) due to gpl restrictions. It's also not uncommon for the 2026 edition to use a completely different SoC than the 2025 version (as in different vendor and even CPU arch) - routers even do this for the same model with a different hardware revision.
As to your other point, software is always easier to change than hardware, even if easy means hooking up a ch341a chip. Hardware however always transitions from sand to electron prison to rock to sand.
> Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.
Putting it all in a single location on the storage device means that 1. Multibooting will always suck because Windows will unconditionally overwrite whatever is there with its own bootloader that only boots Windows, and 2. you now have to have local storage, which would be somewhat annoying to those of us trying to do diskless network boot (or anything else more interesting than "always boot internal disk0").
"Think" (thinkpad, thinkcentre, etc.) series have AFAIK completely different R&D team plus the whole aspect of building on top of what was done for earlier models, and on those the UEFI Capsule mechanism (which allows passing firmware updates from booted OS to firmware) works just fine - it's also used to ship firmware upgrade as part of Windows Update.
Lenovo's business/prosumer line is one of the best in terms of firmware that I've seen so far (though I do have my gripes with their decisions on laptops with Nvidia GPUs).
I don't even want to touch Lenovo devices that don't have "think" in their name, and even that has been tainted by their consumer brand at this point.
> Lenovo's business/prosumer line is one of the best in terms of firmware that I've seen so far
A few years ago Lenovo put out a buggy firmware update for the Thunderbolt controllers in a couple generations of Thinkpads (the list is here: https://pcsupport.lenovo.com/ca/en/solutions/ht508988 ) that caused excessive writes to the controller's EEPROM. This would eventually wear out the EEPROM, which would stop the controller from functioning. You would then have issues like USB-C devices not working, display over USB-C not working, and charging over USB-C not working. Lenovo released a firmware update to fix the issue, but everyone whose controller had already broken needed a motherboard replacement. If your device was out of warranty, Lenovo made you pay full price for the new motherboard even though it had broken because of their firmware update.
I am aware and my laptop was one of the devices that needed the patch.
And yet, I'm still of the opinion that Lenovo's firmware is up there. It's actively maintained and it fails less often than the firmware I've experienced from other brands.
This is less of a compliment to (a branch within) Lenovo, and more of an insult to other brands; production quality for computers and laptops is absolutely awful unless you pay a ridiculous amount of money for the "pro" branding.
> Your computer's awful implementation says nothing about UEFI as a whole
This is just a copout. Of course the crappy implementations many people have to deal with cast the whole thing in a bad light. If nothing else, UX is a distant-to-nonexistent concern of the UEFI standards, and that's part of the problem.
However, you are also right that this doesn't hardly make UEFI any worse than BIOS.
Needing to do special Windows boot and somehow wiping the boot config has nothing to do with the standard.
UX is meaningless for a boot mechanism standard. You cannot apply the same requirements to all UEFI devices. Tablets need touch-sensitive operations that work without keyboards. Servers need headless management with detailed configuration available through remote management. Desktops and laptops a mix of both. Managed Linux environments such as Chromebooks need a whole different sort of boot mechanism where the user has minimal control.
The update delivery mechanism is specified already. Wiping user settings can also be a necessity. Could be to prevent malicious firmware downgrades, could be to clear out NVRAM-triggered exploits, or maybe because the update necessitated restructuring configuration or whatnot.
Plus, as many have probably already noticed, the UEFI spec is more of a suggestion anyway. The only party bothering to check it might be Microsoft, and even then they only care about the parts that make Windows work. No matter how good or specific your spec is, a shoddy company will release shoddy firmware for it.
> UX is meaningless for a boot mechanism standard.
Well, all I can really say to this is that yes, this attitude is exactly the problem here.
Of course, the world looks different now than it did 25-30 years ago, and all Intel really set out to do back then was to get away from BIOS and all of its limitations. This was especially important for their now-defunct "IA-64" (Itanium) project, but it ended up lasting anyway due to x86-64 happening.
Nevertheless, for most of us, UEFI rolled out in the 2010s, at a time when Internet connectivity was generally a given, and hardware capabilities had already moved well beyond where they were when Intel handed the matter off to UEFI in the 2000s.
Hardware makers have consistently shown contempt for software and user experience, regarding it somebody else's problem. Of course, a consortium of many hardware makers is not likely to develop opinions or sentiments that none of them individually would have. But it does show how parochial and short-sighted they were and often continue to be.
Yes, there are multiple different platforms that use UEFI. They can each have their own standard way of using it, though.
UEFI provides a way to update in OS agnostic way, unfortunately motherboard vendors do not necessarily provide archives that can be uploaded this way (assuming they updated to new enough version to support the interface in the first place).
Unfortunately we're suffering from "eh, it boots windows, ship it" mentality of many hardware manufacturers, whether back in horrible era of BIOS emulating faux IBM PC 5150, or with modern UEFI
Before the only way was either fdisk /mbr to reset for Windows or boot a Linux system on stick/CD and rebuild grub/lilo. The latter has gotten unreasonably complex though so I rather wouldn't do this manually.
My verdict is that UEFI does something right, but created for the enterprise sector carries way too much complexity. Obviously so complex that everybody ends up using the original same code base.