> Bios is wonderful because it's limited; Nobody wants to try shoving more functionality into it. No system management, no drivers, nothing.
Haha oh if only. I've probably worked around more UEFI bugs than any other single individual, and I've still had to deal with more non-UEFI BIOS bugs in my life. BIOS provides no kind of standardised interface to the OS, and so every vendor built their own and every vendor fucked up at some point. UEFI means there's much more shared code than before, and we're definitely benefiting from that.
Not even that! It loads the first 512-byte sector of your boot disk and jumps to it in 16-bit mode. Usually that bit of code loads in a few more sectors (using BIOS disk IO calls), enough to load a real bootloader's image (like GRUB), which subsequently understands your filesystem and loads the real kernel.
It's kind of a hack but I completely agree, much better to leave it in the hands of the systems developer -- firmware that tries to do too much often just gets in the way.
BIOS just runs whatever is in the first 512 byte sector.
Unless it fits in 512 bytes this is not a "kernel" but is just instructions to jump to another address, where there is more small bootstrap code that loads another program, maybe a bootloader that loads another program, maybe a kernel.
Those who multiboot Windows with some other OS that uses disklabels may notice that Windows expects to always be the first OS. Any other bootstrap code put into that first sector will be overwritten by a Windows install.
PXE is good (someone needs to sit down with me and a bottle of rum and work out why PXE behaves differently after a hard reboot in VirtualBox), but I've got to hand it to Apple, Target Disk Mode is nice. They also had some kind of multicast netboot-installer before most OSes.
It may also initialize some of your hardware by calling the firmware supplied with that hardware in ROM (for instance: video cards, network adapters and RAID controllers).
(Off-topic) I was curious to see what other information that site might offer, and was amazed to find a curated list of hundreds of other useful discussions.
Yep, the Yarchive is awesome. Some of the older discussions on computer architecture and programming languages have real historical value and are hard to find anywhere else on the net. Great work Norman did there.
Does anyone know why the references to the original threads (through Google Groups) don't work anymore? Did Google Groups stop carrying the content or can't they search by Message-ID anymore?
Does anyone disagree that UEFI has the capability to be an OS itself?
If it is only used as a "BIOS" then is it unreasonably adding the surface area for bugs and attacks? Is it much larger and more complex than legacy BIOS?
Is this trade-off proportional to the benefits it provides: obviating need to for developers to understand backwards compatibility?
The point of UEFI is not to avoid the need for kernel developers to know how to get into 64-bit mode. If you can't manage to get a computer to do that pretty easily, kernel programming is not for you, and this is mostly limited to the bootloader anyways.
As much as people like to rag on it, UEFI provides a lot of benefits:
- UEFI graphics firmware improves compatibility, and makes things like PCI pass through of GPUs to virtual machines much easier/possible.
- UEFI allows for much faster boot times by cutting out a lot of 16-bit mode/32-bit mode transitions that BIOSes generally used.
- Every operating system doesn't need to fight over the master boot record of your drive, with UEFI they can live in relative peace.
- Things that were simply impossible with a lot of BIOS implementations (e.g. Booting off > 2TB hard drives) are now possible.
It's over-engineered, but so is ACPI (IMO To an even greater degree). Does anyone want to return to the old plug-and-play compatibility mess?
> It's over-engineered, but so is ACPI (IMO To an even greater degree). Does anyone want to return to the old plug-and-play compatibility mess?
In my experience, those who like to rag on UEFI, for whatever problem they deem it to suffer from, are rarely interested in providing other options or solutions to the problems UEFI provenly solve.
That's true of any piece of tech. The solution to C++'s problems didn't come from the people who avoided that language entirely, it came from Mozilla, who are up to their eyeballs in C++. People who hate Sexprs still haven't come up with a good replacement.
They've got XML
Many of the people behind that were Lispers. And anyways, I said a GOOD replacement.
But yeah, the solutions to a problem with a system don't come from the people who hate its guts and won't touch it: It comes from people who use it, need its functionality, and need those warts fixed.
http://yarchive.net/comp/linux/efi.html