Hacker News Reader

Comment by silisili | Hacker News Reader

Not to rain on this parade, but what specifically is the target user for Centos/Rocky these days?

I've been a Linux user for more than 20 years. I absolutely saw the value of Mandrake/RedHat/Debian for years. Boring, stable. Got it. Those are important qualities. And Centos gave a free, easy to acquire and use taste of said stability.

But today... everything is so different. I run rolling release, have a billion random services running at any time because it's a dev machine, and... nothing really ever breaks. I get kernel vulnerability patches in a couple days, vs waiting weeks for some hacked together 2.6.8294 backport.

Even if that weren't the case, between snapshotting filesystems and containerized everything, it just feels like such cautious, controlled OS software is a thing of the past.

As always, happy to be told I'm incorrect and/or hear use cases.

View on HN

About 18 years ago I wrote an internal intranet application for someone in PHP (yuck). This runs one of their core business processes. Every 3 years we do a review of the system, replace the hardware and update the software. This is exactly where CentOS variants sit for me. The last two upgrade cycles, the computer has not been down at all in the interim. It has literally been up for 3 years. The only changes have been to support later versions of Postgres and PHP and to move the backups to S3 rather than tape.

Why not the cloud? The company is in a rural location with a shitty internet connection and 50 users. When initially provisioned there was no internet connection at all!

There’s a lot of stuff which is in the territory of “if it’s not broken, don’t fix it” and that’s where these distributions sit. That may cover industrial, office, line of business apps, temporarily connected or fully offline systems. Or just stuff you don’t want to piss around with.

Also never underestimate the power of having stuff you don’t have to touch or even go near. When was the last time you got paid monthly to do something once every three years?

> Also never underestimate the power of having stuff you don’t have to touch or even go near. When was the last time you got paid monthly to do something once every three years?

This is not the reality for 99,9% of the world. If it is online, you need to patch security vulneralibities. Because your system is not immune to them.

I'm not saying it isn't patched. It is just not bleeding edge or changing rapidly therefore the tradeoffs are different.

There's stuff out there that is nearing relic status that is still up and running and not patched or supported. Some of it isn't even touching a network so that's fine.

  # dnf install dnf-automatic
  # systemctl enable --now dnf-automatic-install

I tend to actually test stuff before we patch it. RH have broken stuff in the past.

Supercomputing centers and all the servers are prime candidates, where the hardware and software stack never change for the lifetime of the computer (which is around 7-8 years at least).

Do note that what users can use on that, and what system admins use is a completely different stack. Users get an update almost every 3 months. The stability is more for the hardware drivers and things like that, where things are still very iffy because a lot of hardware is actually latest hardware, so not all bugs have been sorted. Infiniband for example is not stable and mainstream at all.

Ubuntu will go through two LTS releases in that time, while you can continue with a single RHEL/CentOS release.

Supercomputing... Note that Summit changed from RHEL7 to RHEL8 mis-stream. (IBM insisted the system I work on had to do the same on similar hardware because the RHEL 7.9 distribution I could see didn't exist. It allowed more recent CUDA, but that wasn't the rationale.)

I don't know what "system admins use is a completely different stack. Users get an update almost every 3 months" is about. Infiniband is fine, and typically quite up-to-date in RHEL, but you end up having to deal with the Mellanox nightmare, at least for Nvidia GPU support; roll on RoCM. That area is a good demonstration of the practical evil of proprietary software.

There are entire industries that cannot and will not use rolling releases. That can either be regulatory requirements, or it can be environment where you need/want to be sure that the platform is identical to a reference system.

The best examples are perhaps hospitals, and medical equipment. I previously worked with a hospital where the software is only certified to run on RedHat, and where the system is very tightly controlled. A patch can only be deployed in production, if it has parsed testing and staging environments.

I've also read about research projects, where different versions of glibc, would yield different results. In this case I will continue to argue that this is pretty bad for reproducibility and more of a problem with the people doing the science and not underlying operation system.

Errors, bugs, security holes do sometimes make it into rolling releases, and in some environments regressions are catastrophic or deadly.

Personally I tend opposite world view compared to you. Rolling release are great, for a very small niche, such as desktops for office workers or developers in certain industries.

Rocky Linux is self is a great project, because it allows you to have an environment identical, or close to identical, to the RedHat installations that will eventually run test, staging, QA and production environments, but without the cost. I had been skeptical that Rocky Linux would deliver, but I'm very please and happy that they do.

The target audience is the machines that host your vms, these need to have a stable environment for a long time(of course patched for security when needed).

I want to tell you that you are incorrect even I upvoted your comment :). There are industries which cannot use rolling distros for whatever reason. I switched jobs at the beginning of this year from a cloud-application development where everything could work on rolling releases and more or less lived on the bleeding edge to developing and provisioning a cloud platform (not everything can work on a public cloud: energy companies, essential telecommunication, many healthcare providers don't want to do that etc). Two worlds so close together physically but totally different philosophies.

We don't use CentOS or Rocky. Our customers pay for RedHat or SLES. But I can see that someone wants RHEL and don't want to pay for the license and don't want to switch to Ubuntu/Debian or OpenSUSE either. I don't understand that, they are not that expensive for what they are but ... I am a software developer by profession, not an accountant. (I even saw industries paying for Windows Servers or HP UX, the prices were pretty eye-watering; the Linux-based options are either cheaper or at the same level as MS Win which for multi-million Euro company is not THAT much and even can pay off when you need to call support.)

For me, it's about having a stable platform for something; not all (or even most) components in a software system benefit at all from following the latest releases, and what "stable" distributions give me is the ability to keep those components up-to-date security-wise very easily and without having to worry that everything could explode due to major changes when I run "dnf update" (breakage does happens, but it's rare). I can have hundreds of hosts auto-patching themselves and still sleep soundly.

Something also needs to run your Kubernetes, and that can't always be AWS.

server machines or machines offering an installed product like an ATM or a bus schedule display

If you want to make a static build with an ancient glib (so it runs everywhere) but you want to use a recent compiler then CentOS is the straightforward option. It provides modern toolchains over an ancient base system

I think this is how you make Appimage files that run on all distros (maybe someone can correct me if I'm wrong)

It's what you get support for. At my job we run several third party applications that are targeted at RHEL/RHEL-clones. Sure, they might run on other distros, but if you need the vendors support, you better be running RHEL/CentOS/Alma/Rocky.

Reply on news.ycombinator.com