Hacker News Reader

Comment by brightball | Hacker News Reader

I'm curious to see how many companies on here use RedHat for their server infrastructure?

What are the benefits and costs?

As someone who does both sysadmin work, and programming/modeling&simulation work, at a significant research nonprofit in the US...

RedHat is stable: Which has the benefit that it's stable, and the cost that it's always behind the times.

Security is deadly serious, and RedHat make it easy. STIGs are available for RHEL; they're also available for SuSE [very recently] and Ubuntu LTS releases, but we're heavily invested in RHEL infrastructure, training, etc, so switching to Canonical would be expensive and hard. A few years ago I earnestly looked at us coming up to speed on Ubuntu, but with Canonical's recent behaviour around packaging I'm kind of glad we didn't.

We rolled with CentOS in a few places for a while [all the benefits of the training and experience], but the recent changes in that make it useless for our needs.

I've been around for long enough that I remember when Linux sucked; I started using it around 1997. Nowadays, I find that all modern distros are in the same ballpark of "pretty much work pretty much all the time"; so while I don't love RHEL, it's been a safe stable choice and doesn't bite me in the ass.

I think this was linked on HN the other day, and it basically covers anyone using RHEL: https://boringtechnology.club/

  I think this was linked on HN the other day, and it basically covers anyone using RHEL: https://boringtechnology.club/

God, I think you can tell the real engineers that have gone through the trial by fire and the ones that haven't simply by how much they agree with that presentation. At some point in your career, at 2AM when your debugging that fantastic new opensource library, for the 10th time, that you rewrote everything because it did exactly what you needed, and made you a hero for a week, you switch from gabbing the latest cool thing to picking those old technologies that everyone knows why they suck.

Because knowing why something sucks when you pick it, is more important than knowing why its good.

RHEL sucks because in 10 years you will be running some horrendously "outdated" software. Its fantastic because over those 10 years you will have made a pile of money selling your product and adding features rather than spending cycles being an upgrade monkey for things you didn't know you needed until someone sold them to you. And your customers, they don't care what OS your running as long as its reliable. Which is something RH provides in spades.

Especially if you know why it sucks you can work around the suckage; but 99% of everything sucks, so if you don't know why the new shiny thing sucks, you're gonna have to find that out yourself, under fire.

(This can even happen between various old and established things; if you know MySQL and all its warts well, perhaps switching to the relatively unknown PostgreSQL "because it's better" isn't the best use of your time. You should be able to explain why and why not before making the switch. When in doubt, do what everyone else is doing - unless it's your differentiator.)

Ten years, yep, sounds about right. We're finally getting rid of our last few RHEL6 boxes. It got pretty long in the tooth at the end there, but it never gave me any hassle.

In the software world, RH is not just old, it's practically antique. Their kernel age can really hold you back. Compare it to the way SLES releases their minor versions. I've done alot of work with RH, but I do not recommend it or enjoy it.

If all you are doing is running a webserver, java app, and database the kernel version pretty much doesn't matter. This is the use case most companies are in.

I don't know about "on here" because HN tends towards startups and freelancers, but in the US Enterprise sector, Red Hat is what you buy when you want a vendor-supported Linux in your expensive lights-out datacenters.

If you take a look at the Fortune 500, it wouldn't surprise me if Red Hat was in use by at least 490 of them.

Yeah it's common in the traditional, established firms. Something about compliance as well as the fact that some of the proprietary enterprise software packages they use only support RHEL.

Working for one of the hyperscalers as an architect, this is exactly my finding too. RHEL is the standard, everybody runs it. Exceptions are for SAP (SUSE) and some container workloads. RHEL for all the rest.

I'm a NASA contractor and until recently we used CentOS a lot. With the changes made to CentOS by Red Hat, we are now moving to RHEL or Ubuntu. The Agency prefers to have an OS with official, paid support. (I do not speak for NASA, my employer, or anyone else, and I'm retiring in two weeks, so there.)

Hope you enjoy your retirement :-)

> The Agency prefers to have an OS with official, paid support.

How did CentOS fit into that? I guess I would have naively expected you to be on RHEL to begin with.

Where I was projects started on CentOS. Often once they got big / went to production, they were switched to RHEL.

And devs often used CentOS when playing around (ie, setting up VM's etc at home or just randomly) because you didn't need to talk to anyone to do so.

AlmaLinux with paid support on demand by Cloudlinux?

In my experience CentOS basically let you get all the security benefits from RHEL with none of the costs. So it has been popular to minimize budgets.

Sure, but that's the exact opposite of having paid support, which is why I was confused

The agency tolerated CentOS but was never happy about it. The fact that it was directly derived from RHEL and could be expected to get timely security fixes probably helped make them comfortable with it. The agency is also concerned about Python2 remaining the default in both CentOS 7 and RHEL 7. Red Hat has committed to back porting security fixes for Python 2 proper, but that leaves a large universe of add on packages that might not get patched. Thus the move from both CentOS 7 and RHEL 7 to RHEL 8.

Oracle is an option (especially for converting CentOS without reinstalling), but it has become stunningly more expensive.

There used to be a $99/yr "support in name only" option, with no ability to file service requests (community discussion boards only). The basic level of support was $500/yr.

It now appears that basic support is $1,200/yr. Of course, ISO downloads and yum support are still free, but the support contract is now much more expensive.

Oracle also still offers free KSplice kernel updates for Ubuntu, but it appears that Fedora support was removed.

A couple years ago I worked for a different federal agency and RHEL was used extensively, but was being replaced with OpenShift. The base images being used were all over the map and the whole process was quite a convoluted mess.

Many companies are conservative and want a "vendor" for support. Last time I saw RedHat being widely used was at a defense contractor and a state government agency. This was before Ubuntu was popular, in the late 2000's.

I never saw this "support" actually used. The benefits are more a CYA thing.

The thing is not about calling support, but having a contractual agreement so you got somebody to sue in case something goes wrong. That makes lawyers happy. And is useful when offering your own services as you can state that potential liabilities at covered by the vendor. How well that would play out in reality is a different story, but gives people some better rest at night.

Absolutely. That's why I said it was more a CYA thing.

It does get used, though. There are some very intractable issues with modern software implementations, especially with OpenShift container storage. Unless you've worked with it tons, it's not exactly something a first-year sysadmin can solve. Personally, I tend towards Debian for infrastructure because while I have experience with RHEL, I prefer the Debian layout, package management, and freely-available help from very knowledgeable people. Not saying that RHEL are pillars of intransigence, they're not, but I've found it easier to solve my own issues. As an almost 3-decade senior sysadmin/devops guy, I know where to go and who to speak with if I run into something really odd. Fortunately, that's rare. Once you've used Linux from a sysadmin POV for a few years, things begin to make sense from a file system, maintenance, and overall "keeping everything alive" approach. I was mentored back in the 90s by a Debian guru at our local LUG. He's since passed into eternity, but much of what he taught me and others still applies. The beauty of POSIX systems. Now... when systemd got released, I didn't know what to make of it, but now after many years, I've gotten used to it. I still prefer the old BSD-style init files and non-binary approach, but what to do with modernity? It will pass you by if you don't embrace it.

Most places I've worked ran commercially supported Linux on their on-prem production systems, with the "free / community" edition (read: CentOS) on dev/test.

Having a support contract in place was often a requirement for the clients, perhaps due to regulatory reasons.

We have someone to call who knows how to debug io perf

The benefit is support and access to their support pages, you can also make general administration easier through some of their tools. But it's pretty expensive

What tools? Cockpit?

That's why we dropped it. It just got to be too expensive. Yes you got access to their support knowledge base, which was sometimes helpful but if you did a little work you could almost always find the answers elsewhere.

The main thing I liked about RHEL was its stability. Not a lot of churn, and for running any other vended software, support for RHEL was never a question.

Converted everything to CentOS. When Red Hat killed that distro, that was a bridge-burning event. We use Ubuntu now.

Compared to RHEL alternatives like Alma/Rocky: possibly faster access to patches, support, insights (cloud based analytics and analysis of your workloads/security).

Compared to other Linux distros: some COTS software requires RHEL, risk adverse orgs probably need to layer RHEL support with their COTS support contracts to meet SLAs/support requirements.

Alma/Rocky are downstream of RHEL. By definition they will never have faster access to patches because they pull them from RHEL.

I guess you misunderstood the direction of comparison

Until we moved serverless, we did - business folks wanted someone to blame when sh*t hit the fan, so they felt it was worth it.

As a developer, I love working with it.

But now nearly everything we deploy is on AWS Fargate and our images are Debian based.

Just curious: why did you switch to Debian, especially with RHEL being more or less free for containers?

A lot of the base images we ended up using are Debian so we just wanted to be consistent, whereas before we were running software from the RHEL repositories.

We use a TON of RHEL, mostly for their support, but also to have a product that is supported. Helps with audits and compliance. I imagine most big places have similar rationales.

Don’t exactly run servers, but they’re FIPS certified and they’re the first (often only) distribution hardware vendors support

Normally it's because the application vendor supports RHEL/CentOS. So that's what you run.

Some software vendors annoyingly require particular distros (like rhel8) to use their support lines

> companies

plenty of activity each day that is not in that category

Reply on news.ycombinator.com