Hacker News new | past | comments | ask | show | jobs | submit login

These UEFI firmware bugs are completely avoided by choosing an interface with a smaller footprint. As in: not much of an interface at all. This is what makes ChromeOS work while UEFI still fails at times.

No moving parts means no worries - that's a lesson the UEFI architects never understood.

So they built that living hell of runtime composable components for something that generally tries to get out of the way in as few milliseconds as possible. Some of these components survive long into the operating system's domain, messing things up there. The architecture doesn't allow for build time controls (eg. why did boot services used by runtime services, a common bug a couple of years ago, not trip up a linker? because they incapacitated the linker through this design).

And best of all, thanks to Intel relentlessly pushing that crap into the market, we'll get to "enjoy" it for the next three decades or so.

Apart from being able to check the "Windows" checkbox on marketing material, I actively avoid UEFI because of this horrid imitation of software design.

UEFI is that bad.




Yes, I know UEFI is not perfect, but the problem with PC OEMs only caring about Windows existed long before UEFI, and my point is that Chromebooks using different firmware only make the problem worse. ARM SBSA uses UEFI and ACPI BTW even though there is no Windows Server RT.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: