On Thu, Oct 15, 2015 at 02:00:32AM -0400, Scott Sullivan wrote:
... understand it's not evil, just some of it's implementers are.
The subject of UEFI carries a lot of FUD around it because of some nasty moves on Microsofts part in how it 'certifies' windows hardware, but not of that has to do with the Standards. That's just someone else policy on top of its mechanisms.
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-wo...
This came up as an after meeting discussion from Chris Tyler's talk this month.
Please read the article before making snap reply to this (I did it over a few bus rides, it's not short. But a heck of a lot short then the actual standards docs).
Certainly the change from MBR partition table to GPT is a great change. Much much better partition table design. Running in 32 or 64bit sure beats the old BIOS code, and the services provided are much better than the old BIOS software interrupt calls. It isn't perfect (rom code being interpreted forth and hence architecture independant in openfirmware makes a lot of sense, but intel would hate anything that doesn't lock you into their architecture. It would be awful if your video rom could run on a non x86 machine after all). I do wonder actually why arm went with UEFI rather than openfirmware, although x86 users are at least starting to be familiar with UEFI so I guess it is less scary than openfirmware (although if Apple was able to use openfirmware, it can't be that scary for the user). Certainly the secureboot feature that UEFI can provide is not a bad one. The only bad thing is how Microsoft and some system vendors are choosing to use it. As long as the owner of the machine can choose the trust keys, it is a good feature. If you take that away, then it stops being a good feature, since you no longer own your hardware. -- Len Sorensen