> 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).