Hacker News Reader

Comment by cheekibreeki2 | Hacker News Reader

Rh 4.2 ran half the planet, where are you getting this from?

From my experience as a Linux sysadmin? RedHat ran half the planet because they had the best sales force and legal team (as exhibited by my example), but they did not have the best technology.

Wrong. Two reasons actually:

1. RHEL was the first distro directed at enterprise deployment (meaning, strong preference of rock solid stability and predictability over constant churn). Which made it the only distro Dells and HPs of the world recognized and agreed to support.

2. RHEL was created on legacy of RedHat Linux, which was the best distro for non-hobbyist environments (from reproducible deployments to the breadth of packages available) - since 3.0.3 onwards. RedHat JUST. WORKED.

I don't think "Wrong" is a very interesting, helpful, or productive response to someone's lived experience.

My experience disagrees strongly.

1. Debian always had more stability and predictability than Red Hat in practice. Too much so. The Dells and HPs of the world didn't recognize it because it was not a company.

2. My impression was again that Debian was technically better than RedHat in every way I might care about. We happily installed it at $work, and the experienced Unix sysadmins I knew could use RedHat but didn't like it so much.

> Dells and HPs of the world didn't recognize it [Debian] because it was not a company.

IIRC Debian maintainers formed companies for that reason.

I was a Debian user because it suited me. It was obvious (to me at the time) that suits were going to choose RedHat, and we ran it a bit to have experience.

How wrong I was. Ubuntu made Debian every bit as much as a "choice of the suits" as Redhat.

It looks like RHEL zealots never die from the other people’s comments. RHEL had plenty of problems just like all the other OSes and distros.

I think you're romanticizing it. Until RHEL and LTS releases for Debian/Ubuntu, most distros you never knew if running and update was going to break something because there simply wasn't effective quality control testing in the hobbyist distros. Best you could do was run a version behind, but that hurt if you needed security updates.

There were plenty of people and small highly knowledgeable shops and academics that thought 6 hours fixing a bug after custom compiling a patch was fine and normal (and a RHEL subscription at least meant RedHat would have a team doing that part for you if absolutely necessary), but its not the way companies operated. RHEL at least meant whatever release was stable and an actual QA team put patches through their paces on various hardware and configurations (especially those enterprise high end server configs with special SCSI/RAID controllers, high end network cards, and other chipset other distros simply didn't have the means to test on). The QA/support team wasn't bug reports and guys on usenet going "it works for me, you should have gotten the exact same hardware I have, or be willing to go through the code and figure it out and patch it, and submit it to the source, like a good user should". Or tell you go back to Micro$oft if you want support for your storage controller that the kernel module for worked fine in the last version. Those were the zealots, the rest were sys admins with too much other things on their hands to do than deal with Slackware or whatever the hot distro was on distrowatch.

My Redhat experience always seemed to devolve into "this package that I want has a dependency that isn't listed yet..." (cue 2 hours of recursively and manually tracking down dependencies on the early web).

But I was a lot younger and didn't know a lot of what I do now, so was probably doing everything RPM wrong.

I had the dependency spiral issue on every distro (I played with quite a few), compiling with something like Gentoo made it worse. RPM Forge existed, I think the Linux experience in general was bad back then, and RedHat actually was one of the least problematic. Until Ubuntu, it was the easiest and most approachable to use for novices.

Using redhat before yum, meant visiting rpmfind.net and manually collecting what you needed.

In some ways, RHEL is still like that, because popular packages are usually a major version or two behind if they're even there at all. You have to hunt down an EPEL that has whatever you need.

Yeah, I don't miss the old days. Like another poster though, I remember apt-get being decent while pre-yum RedHat was still pretty bad.

But I also realize my perspective was that of a hobbyist, not an enterprise sysadmin who was probably upgrading to well-known versions through known paths.

I worked with sysadmins who used rpm based distros back then and their experience was basically mine: hunting down the right rpms that both satisfied the constraints and actually worked.

You bring back memories. In my early Linux days, every attempt to upgrade an RPM based distribution lead to me needing to wipe the system.

The first time I did a major version upgrade on Ubuntu, I was shocked it worked.

I think you are exaggerating.

Computers of all stripes are more reliable now. In the late nineties I ran apache + mod-perl built from source.

We had a lot of problems, but I cannot recall ever having a problem with those two.

We tested every update, of course, but it was not a huge burden.

If you were running Apache fine, I think Linux in the late 90s was the work horse of web servers. That might have been the one thing that just worked. I was using it as a workstation and for everything else. Try getting your window manager to work with your Xserver and graphics card. Upgrade a package that needs a newer packlage, that needs another package that no one has built yet, so now you need to custom compile the library, but if it replaces the existing library it breaks something else that relies on the older library.

That's inbetween figuring out how to get things to compile and the dependencies of dependencies, etc.

I got Linux to work, but it was also a love hate relationship, when I got it working, it worked and worked for months, but I had almost a PTSD reaction when it was time to upgrade anything, I knew what was coming and I was afraid.

You are not wrong...

This was pre DNF/YUM days. RedHat could be a pain installing stuff from RPM’s that had crazy dependencies back in the day.

First time I installed Linux, I was trying to Gaim on it.

I managed to compile Gaim before I managed to install it from RPM packages.

Using Debian was a moment of pure epiphany.

Good times.

I remember using Mandrake (later Mandriva) - it also used rpm. Dependency hell was an issue there too; it probably had to do with state of rpm more than the distro itself.

Dependency hell was a thing for sure. I had at the time made a script to easily install rpm's at with a shell script that was searching the mirrors. It didn't handle dependencies but would show what was missing. But so many years later now looking back, a big issue was really just a lack of understanding of rpms with all the other os's with rpms, different arcs and versions. yum was a welcome changed especially since apt had for so long solved dependency issues.

up2date was before then

My main experience with RedHat has been needing to bend over backwards to support its wildly outdated library versions. Because RedHat “supports” operating systems for about a decade, there’s always an argument that a library should be written to support whatever toolchain is provided by the oldest supported RHEL version.

RHEL’s “support” should be seen as “your software will continue to run unmodified when on this system”, but is frequently interpreted as “this is a sane platform for current development”.

Current development was better done on Fedora, the upstream of RHEL, I think they were pretty clear that's what it was for. RHEL was for when you needed everything to work no matter what. Fedora was for new development and latest and greatest.

The problem with needing “everything to work no matter what” is that it just doesn’t exist. The type of stability that RHEL provides is conditional on never using third-party libraries. RHEL backpoets security fixes to packages that it provides, but you’re on your own for anything else. For example, RHEL 7 was released in 2014, has production support for another year, and extended support until 2026. As libraries are requiring C++17 support today, maintaining compatibility with stock RHEL 7 requires running older versions of a library.

That level of backwards compatiblity with legacy versions exists on other platforms (Windows, z/OS, AIX), especially those implemented in enterprise environments. If I have a Windows app written in Win32 API, it'll run on Windows 11 on 64-bit architecture. That's what companies want. That's how Linux became viable for those customers. Even Edge has an IE mode because that's what enterprise environments need, support for older libraries and APIs. I won't deny RHEL was higher technical debt for sure, but that was the trade off, because that's what enterprises prioritized, support, stability, and knowledge that an update during their monthly patch cycle and change window for rebooting the server won't break the business applications they rely on for fundamental operations, at least not on the same major release version.

RHEL was never supposed to be the latest, I think even a every new major release they'd be on a kernel and library version that was 2 years behind but had been through its paces. IOW, it was a feature not a bug, and its what companies were paying for (their customers were boring legacy Fortune 500s not startups). As a business model, it was solid, and the most successful in the commercial market by far because it catered to their customers needs, even if they're not our own, even Ubuntu Server took pages from their book.

They're talking about stuff that predates RHEL by half a decade.

True, more adding it as agreement on RedHat being consistently and intentionally behind the curve.

For a while, Python binary wheels (packages) for Linux had a standard that was defined, essentially, in terms of RHEL (or rather, CentOS) as a baseline platform for this exact reason.

https://peps.python.org/pep-0513/

https://peps.python.org/pep-0571/

https://peps.python.org/pep-0599/

Windows ran half the planet, where are you getting this from?

These statements are not mutually exclusive. Math checks out :)

Only if MS and RH were the only thing that existed 20 years ago, which we know is false. Sun Microsystems, for one. Debian for another.

And the thing is I was being conservative about MS running half the planet. They had their grubby hooks in everything.