> has always enjoyed the reputation of being the most bulletproof distro if you could afford it.

I've always heard that said about Debian more than about Red Hat (though Red Hat certainly is pretty stable).

Red Hat has a lot more success in businesses though because you can get contractual support; which may not only be useful if you don't want to get the skills in-house but also because your own customer may contractually require it.

Debian also has an impressive reputation for quality. In many cases it has achieved, through its vast user and developer network, what Red Hat could only achieve through paid staff and commercial resources.

But this is not true in all areas, especially in some aspects that matter to companies such as training/certification and having good up-to-date documentation.

And as a volunteer-driven project, I don't think Debian can ever be as responsive to end-user problems or requirements as a commercial product can be.

But it definitely gives Red Hat a good run for its money. For example, the Debian LAMP stack has long been and still is the gold standard.

Debian is truly a solid alternative. Ubuntu, less so. They're shipping an impressive amount of new features, even on LTS releases, but their QA is nowhere as good as Debian or Ubuntu's.

Back when Solaris 7 was a thing, dependency hell was very much a thing.

UNIX vendors didn't normally ship releases or updates that introduced dependency issues. Part of their job was doing testing and quality assurance, that's what you were paying good money for. Most such issues were introduced locally.

A good sysadmin would know how to avoid dependency hell. For example this might include taking basic precautions such as testing changes in a chroot or development/testing environment, before rolling them out.

I'm not saying the problem didn't exist, only that it wasn't an actual problem if you knew what you were doing.

The problem with dependency hell was more that RedHat back then didn't have such a thing as a "rolling release" or "testing" in Debian speak. So while "RedHat 6" worked fine, trying to upgrade (say) OpenOffice would require that you download the rpm from OO's website, which would require that you upgrade Gnome, which would require that you upgrade X, which would require that you upgrade glibc, and down the rathole. Considering that most people then were still on dialup, it was horribly annoying.

Also, RedHat didn't ship with (relatively) much software (install everything was an option). Now you've got to configure; make; make install. Now you've got two parallel installations of libraries and software.

Oh. And the RPM database would die periodically (rpm anything would hang), requiring a reinstallation.

Since moving to Debian over a decade ago, I think I had to configure; make; make install something only once (it was an old and unmaintained Java library on SF.net). Almost everything (open source) is in the Repos.

I maintain several RHEL and CentOS clusters.

I never install anything from source. Packages from yum repositories only.

Upgrade OpenOffice with a downloaded RPM? No. The point of RedHat is stability for enterprises. If you want the latest version of everything, RedHat is the wrong distribution.

This was RedHat Linux, not RHEL. This was _way_ before the RHEL/Fedora split.

Aha -- I saw RedHat 6 and read "RHEL 6"

As someone who used Redhat since 5.0 - the RPM database never died for me. But then, I've never used 'rpm --force', which many did and I suspect was the major factor in RPM database death.

I think it was more of a problem on the BerkeleyDB side than on the side of data. BDB was giving an impression of quite fragile thing back then, but it was (and AFAIK still is) the only source of data about installed packages.

Except this really has nothing to do with rolling releases, or the amount of software the vendor ships in the official repositories. Switching to Debian won't solve the problem either.

There is no distro today that provides packages for all the software you will ever want, or the specific version that you need. At some point, you will resort to installing software from outside the officially-supported sources, whether from experimental or user-maintained package repositories, or from a third party in binary or source form.

Until recently, this was an operation that wasn't guaranteed to be easy or straightforward or risk-free. In the worst case, it could even screw up your system in ways that are time-consuming to diagnose and fix.

In the example you gave, I would conclude that OpenOffice didn't package their RPM well, because it ended up driving RH6 users down the rabbit hole. At the very least, they could have unpacked all the files under /opt and provided static binaries, or included all the libs in the archive. Many packages still do that today, such as Vagrant, which installs under /opt/vagrant and includes its own Ruby interpreter there.

Nowadays there are efforts underway to make installing custom software safe and easy, projects like: flatpak, OSTree, appimage, and snap. Hopefully we can reach a point where you can install whatever version of whatever software you want without breaking anything.

We're talking about different levels.

Generally, nowadays you keep a system relatively up to date using apt-get update and upgrade, pacman or yum. Back then all you had was RPM (the equivalent of dpkg).

The attitude was "you want new versions? Go to upstream, download the .RPM and install".

Now, OO (don't remember if it existed back then) depends on certain versions of (say) GTK.

What do you do?

Go to gtk.org and download the rpm.

Rinse and repeat

If that's what you call dependency hell then you've had it easy!

What timeframe are you talking about? I remember it didn't "just work" for me when I first started experimenting with it (V4.2, IIRC). Yes, I was new, but it wasn't the easy-install experience that it now is, for sure.

I started at around the same time -- Red Hat Linux 4 era. Yum didn't exist yet. I was also quite new to Linux, but I'm reasonably sure there really wasn't something that would do dependency resolution for you. You either had to find an RPM that had the right version, or you had to find a tarball somewhere and run configure and make yourself.

Installing software on an OS, shouldn't be something that requires ANY experience. What exactly is the point of an OS without the software running on it? If it's not immediately obvious how to do any of it, for a total noob, to a veteran. Then it's a garbage OS in my opinion.

That's missing the point of Linux entirely. Your average end user isn't using Linux as their day-to-day desktop environment as it requires some skill to maintain. They are using Windows/OSX because they don't have to focus on the platform and are able to carry on with their workflow applications, needing minimal back end maintenance. On the flip side, many sysadmins will not run back end operations on a Windows box as you simply don't have the same level of control, configurability, and customization that you can achieve with a properly set up Linux solution. And calling any OS requiring knowledge to operate and maintain garbage is downright ignorant, as this entire thread and article proves otherwise.

Except all I've been hearing about for the last 20+ years, is that THIS YEAR is going to be the year everyone uses Linux on the desktop. That's not ever going to happen with how archaic it is to do basic tasks.