Balancing advancement and legacy

Later today, I’ll submit a contentious Change proposal to the Fedora Engineering Steering Committee. Several contributors proposed deprecating support for legacy BIOS starting in Fedora Linux 37. The feedback on the mailing list thread and in social media is…let’s call it “mixed”.

The bulk of the objections distill down to: I have old hardware and it should still work. Indeed, when proprietary operating systems vendors (both in the PC and mobile spaces) embrace varying forms of planned obsolescence, open source operating systems can allow users to continue using the hardware they own. Why shouldn’t it continue to be supported?

Nothing comes for free. Maintaining legacy support requires work. Bugs need fixes. Existing code can hamper the addition of new features. Even in a community-driven project, time is not unlimited. It’s hard to ask people to keep supporting software that they’re no longer interested in.

I think some distros should strive to provide indefinite support for older hardware. I don’t think all distros need to. In particular, Fedora does not need to. That’s not what Fedora is. “First” is one of our Four Foundations for a reason. Other distros focus on long-term support and less on integrating the latest from upstreams. That’s good. We want different distros to focus on different benefits.

That’s not to say that we should abandon old hardware willy-nilly. It’s a balance between legacy support and advancing innovation. The balance isn’t always easy to find, but it’s there somewhere. There are always tradeoffs.

I don’t have a strong opinion on this specific case because I don’t know enough about it. We have to make this decision at some point. Is that now? Maybe, or maybe not.

Sidebar: it’s hard to know

One of the benefits of (most) open source operating systems also makes these kinds of decisions harder. We don’t collect detailed data about installations. This is a boon for user privacy, but it means we’re generally left guessing about the hardware that runs Fedora Linux. Some educated guesses can be made from the architecture of bug reports or from opt-in hardware surveys. But they’re not necessarily representative. So we’re largely left with hunches and anecdata.

Flavor of Love

One of the nice things about Linux is that there are so many different flavors to chose from.  Although you can customize it to meet your exact needs, there a good chance that someone has already made a flavor to suit your tastes.  Which flavor you choose is largely a matter of what you’re trying to do, and your favorite way to do it.  At my workplace, we’re a Red Hat shop.  I happen to be fond of the Red Hat products so that works well for me.  However, I find myself facing a bit of a decision.

In 2003 or 2004, whenever my predecessor set up our Linux environment, he put Fedora Core 1 on the workstations and Red Hat Enterprise Linux 3 and 4 on the servers and the larger desktops (the Dell Precision line can be rather finnicky).  I took my job in September 2006, with things largely unchanged.  Since I work at a University, making major changes during the school year is considered bad form, so I had to wait until summer 2007 to begin doing upgrades.  The downside is that FC1 went out of support in the late winter of 2007, but the good news is that I got nearly a full year to re-build software packages and test configurations.  My fellow sysadmin and I, at the encouragement of my boss, decided to put RHEL4 on all of the machines to simplify support.

In the past year, RHEL has proven itself to be a very stable OS, and Red Hat has been quick to release security fixes.  However, there have been several occasions where an updated application has been needed, but it had dependencies that could not be met via up2date.  For example, the Java web plugin for the x64 architecture only works on Firefox 2+.  As of this writing, RHEL4 still uses Firefox 1.5.0.12 (with security patches worked in by Red Hat).  That, at least, was a simple matter of grabbing the RPM.  Of course, now we’re responsible for making sure the subsequent updates get installed by hand.  Even worse is when a package needs a newer glibc than what is provided.  Here’s a hint friends:  if it requires a newer glibc than your distribution provides, don’t bother!

Next summer, I plan to upgrade again.  But what do I put on the workstations?  RHEL is a solid platform, and works exceptionally well in a server environment.  If all you want to do at your desk is check e-mail, surf the web, and type up TPS reports, RHEL provides a good experience to do that.  If you’re trying to run the latest version of your research applications, I’m not sold that it’s the best solution.  There are advantages and disadvantages to choosing RHEL vs Fedora for the desktop

I run Fedora on my desktop/server at home, and it performs like a champ.  It’s not that Fedora crashes with any regularity, but it isn’t necessarily designed for stability.  RHEL is pretty thoroughly tested, so you can pretty much be guaranteed that when a package gets upgraded, it won’t break things.  Fedora gets you newer packages much quicker, but there’s no promises that foo-3.7 won’t break bar-4.2  Fedora also has new releases more frequently than RHEL, and has a much shorter support life (roughly 13 months versus 5 years) – which forces you to update more often.  Of course, if your software’s dependencies necessitate an upgrade regularly, that’s a moot point.

There’s also the issue of package security.  With RHEL, you’re getting your packages from Red Hat’s servers.  With Fedora, you’re generally getting your packages from mirrors.  Generally, you can consider that to be safe.  However, a story featured on Slashdot today shows that it’s not a guarantee.  Is that a reason to forsake Fedora?  Unless your machines contain hyper-sensitive information, the answer is no.

Actually, the second sentence in the previous paragraph isn’t necessarily true (apart from the fact that you can set up your own proxy for the RHN servers).  Beginning in RHEL 5, the up2date package manager is gone, in favor of yum.  Personally, I think yum is better than up2date (although Debian’s apt may be the best), but that wasn’t the reason Red Hat made the switch.  What yum gives you, though, is the ability to add custom repositories.  Which means you can get outside packages easily, and keep them up to date without having to install the updates by hand every time.  It also means that you can set up your own repository for your local custom software.  You have no idea how excited I am about the idea of using rpms in a yum repository to install software on our machines instead of using rdist.

The differences in configuration between Fedora and RHEL are minor, but generally sufficient enough that you’ll need separate configuration trees.  Does adding another OS to your environment cause you to reach for your Rolaids, or can you comfortably absorb it?  For my own workplace, the latter is the case.  So what have I decided?  I have nine more months until next summer, so I’ll punt for now. 🙂