21–30 of 233 posts
But then, these are common linux components, not specific to fedora. They are old and battle tested by now, do they really require significant resources to maintain beyond running some automated tests?
Not looking forward to having to deal with this one.
Earlier quoted context omitted.
Because "removing legacy" was one of the key arguments of EFI enthusiasts, and its still plenus bovis stercus.
Your point is a bit moot because removing bios support will actually allow the maintainer to stop maintaining the bios parts regardless of the fact some other old things are kept. While actually not removing bios support won't allow you to get rid of the aformentionned MS techs such as fat support. Having said that I think this is a wee bit early.
I cannot believe BIOS boot support is even close to the amount of code required for UEFI boot.
Before you say "UEFI is much older than 10 years old", please remember that UEFI only started being a default ever since Windows 8 (10 years old). Windows 7 can't even boot on UEFI (it requires BIOS emulation to be active). I have a system from 7 years ago that while it claims to have an UEFI BIOS, it is so full bugs it is unusable except to boot Windows. I mean, critical bugs, as in, you boot Linux with UEFI just once, you risk the UEFI var storage getting corrupted and the motherboard becoming a paperweight.
> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered usi…
- FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader that FAT doesn't support?
- Yeah in an ideal universe we wouldn't have to deal with PE binaries and we wouldn't have to deal with the Windows 64-bit calling convention for jumping into the firmware and also we've solved all of this shit and it just isn't a big deal any more. We can look at any platform and complain about the implementation details, but at least this one is better documented than the BIOS interface ever was.
In summary: Linux has to boot on computers that exist, and most computers that exist have UEFI. The Linux community has had the opportunity to make meaningful improvements to the UEFI spec in a way that wasn't true with BIOS. UEFI isn't ideal, but it's better than what came before in this respect.
[1] Partitions could be identified as "Linux", but that gave you no information about what they were or where they should be mounted. Current systemd-driven development has allowed us to define the partition mount point as part of the GPT data, which means they can be automatically mounted in the correct place without static configuration about partition layout
Earlier quoted context omitted.
What replacement do you propose, then? Especially what replacement do you propose that works with the kind of typical hardware that non-specialty linux distros like Fedora want to support? Intel systems make up a large chunk of the hardware Fedora is used on, and as far as I can tell they're all-in on EFI. So Fedora has to use EFI to be able to boot on Intel systems.
OpenFirmware: https://en.wikipedia.org/wiki/Open_Firmware Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification. Dynamic hardware enumeration is performed by every OS anyway, the only hardware that must be initialized is the bootloader/kernel storage. For the x86 platform, this could be implemented via coreboot (libreboot always reads to me as lib-reboot…
That would be a massive step backwards in hardware support.
Like I said: They don't really have the option of not supporting EFI.
Alternatively they can support EFI and OpenFirmware, but that increases the number of supported paths instead of decreasing them.
> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered usi…
- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…
Earlier quoted context omitted.
- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…
Quoted post unavailable.
Earlier quoted context omitted.
- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…
Quoted post unavailable.