Comment by BeefWellington | Hacker News Reader

Comment by BeefWellington | Hacker News Reader

This is a bit of a tone deaf idea to explore right now. If anything, the environment and chip shortage issues should be pushing people to promise extending support for older systems for another decade.

That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market.

There are a lot of Dell R710s for sale on eBay still (700+ listings). These are commonly suggested as a good "intro to homelabbing" server in a variety of places. These systems were released in 2009, often featuring CPUs from 2007-2008. They support UEFI 2.1.

Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows.

I think 10 years is probably too close a cutoff but I do think that eventually it becomes a lot more work to maintain it (like i386 builds, x32 builds, etc.) and becomes not worth it except for niche distros.

If we factor in things like environmental impact, it makes a great deal more sense to continue to support older systems for some longer period of time.

> That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market.

I have lots of UEFI hardware with never-to-be-fixed bugs that are mitigated by just using BIOS boot. These are from Dell and Supermicro.

The Dells when set for UEFI would boot 50% of the time and 100% of the time in BIOS mode. The workaround was well known and is the only reasonable thing to do. It's EOL from dell it will never be patched.

The Supermicro's would work great in UEFI but the factory default was BIOS boot. The trouble is that these particular systems had a reasonably high chance of loosing BIOS setup data if they took a power hit (APC UPS are complete garbage FWIW). We'd have to send someone to a remote location to switch it back to UEFI or just reinstall in BIOS mode. By default they would remarkably turn back on when the power was restored and would recover fine if they could boot.

This stuff isn't useless or even THAT old. It's just unreliable in UEFI mode. While most newer stuff from these brands have more reliable UEFI, we're going to keep using hardware that is good enough. We work around hardware/firmware problems because there's nothing out there that doesn't have quirks. "Old" hardware has known quirks that have workarounds that have already been "paid for" with expended labor. New hardware has new quirks that you have to pay off.

Of course it's all moot for this discussion as we don't use rolling quirk factories like Fedora.

> Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows.

UEFI specifications are like Web specifications: they're good to wipe your ass with, but on the Web when the rubber meets the road, the only "standard" that matters is "does it work in Chrome" (in the past, IE). Similarly the only standard that a UEFI implementation need comply with is "does it boot Windows".

Side note: Red Hat disabled the kernel code for the Perc 6/I raid card which is standard in the basic R710 chassis starting with RHEL8.

Unless you have the higher end H710 raid controller or whatever else, Red Hat rendered this chassis controller inoperable with their custom in-house kernel patching process.

Reply on news.ycombinator.com