Live data from Hacker News

I'm Done with Red Hat (Enterprise Linux)

jeffgeerling.com

261–270 of 410 posts

Re: I'm Done with Red Hat (Enterprise Linux)

#261

Earlier quoted context omitted.

Fedoras big strength is the update speed. The problem with distros is that you're always picking an update cycle tradeoff. Debian has decades old versions of packages that they'll backport security fixes into till pretty much the end of time (RHEL also does this but is well, commercially backed while Debian is entirely volunteer driven, which has opened up Debian to maintainer shenanigans a couple of times). Ubuntu i…

Just a quick note: debian stable has a new release every two years. So in the very worst case "decades" means like three years. The horror, the humanity, just remembering how software used to be three whole years ago causes me to shudder.

That can still be ages depending on the maintainer spats.

When I say maintainer spats, I'm referring to shit like how avconv was given undue credence for ages because the split happened right around a Debian release and the packager for ffmpeg on Debian was on the avconv side, which caused a false deprecation notice to be present for quite some time.

And yes, with how quick some software moves, two to three years can very much result in a mess of hacks and patches.

Re: I'm Done with Red Hat (Enterprise Linux)

#262

Earlier quoted context omitted.

Genuine question (I'm not intimately familiar with all the terms of the GPL) -- does the GPL require you to release the source code to anyone and everyone (even non-customers)?

No but it gives every customer the right to redistribute the sourcecode to software they bought if that code is covered by the GPL under the same terms as RedHat got from their upstream. It looks like RedHat might be trying to avoid that clause by threatening to stop selling any software to people who might use that part of the GPL.

I had missed this part earlier. Thanks for clarifying. It certainly changes the picture.

Re: I'm Done with Red Hat (Enterprise Linux)

#263

I don't think this sort of emotional, loose-facted "hot take" style response is real constructive. I'm unhappy about this decision by Red Hat, and am also very concerned about the trajectory RH is on. For the first time in well over a decade I'm re-evaluating which ecosystem to base all my work (and the company(ies) for who I make decisions). I don't believe that Red Hat's leadership cares a whole lot about open sour…

Regardless whether Red Hat said it or not, why not call it what it is? Not every CentOS user was a freeloader and the same is true for its spiritual successors. However, a large majority of CentOS users were not contributing back in any way to CentOS or the larger FLOSS community. Secondly, a substantial chunk of those users used CentOS because they wanted all the benefits of Red Hat EL without paying for it. That pr…

The term freeloading is stupid.

There are customers who genuinely don't need and don't want support. And there are customers who do need support and should pay for it.

It's that simple. Don't bundle them together as all freeloaders.

Re: I'm Done with Red Hat (Enterprise Linux)

#264
post #248

Earlier quoted context omitted.

> That pretty much sounds like freeloading to me. I'll bite. The value in RHEL was supposed to be in the support. CentOS helped establish and maintain RHEL as the defacto standard that everyone targetted and prevent the development of another. I mean if Debian becomes the default that actual reduces RHEL's value proposition for their paying customers. Reinforcing a platform's dominance is contributing value.

"CentOS helped establish and maintain RHEL as the defacto standard" Not exactly. Maintain, perhaps, but Red Hat Linux was the standard before RHEL existed and everybody wanted a clone of Red Hat AS/RHEL to continue enjoying the free ride. Let's also not forget that CentOS had a rocky (no pun intended) few years before Red Hat stepped in later on. A lot of folks gloss over the fact that there were periods of disarray…

A CentOS Stream release only gets updates as long as its equivalent RHEL release is in its "full support" period. In practice, this means that the support duration is cut from 10 years to 5 years.

Additionally, CentOS Stream updates often lag behind RHEL updates. This is because Red Hat won't commit an embargoed security update to CentOS Stream until after it ships in RHEL, so the developers responsible for the update will sometimes forget to commit it to CentOS Stream until a week or two after it's shipped. You end up in a weird position where you get most updates faster than RHEL users, but you often have to wait to get critical security updates. I would be wary about using a system like this in production.

Re: I'm Done with Red Hat (Enterprise Linux)

#265
post #197

Earlier quoted context omitted.

Fedoras big strength is the update speed. The problem with distros is that you're always picking an update cycle tradeoff. Debian has decades old versions of packages that they'll backport security fixes into till pretty much the end of time (RHEL also does this but is well, commercially backed while Debian is entirely volunteer driven, which has opened up Debian to maintainer shenanigans a couple of times). Ubuntu i…

> Debian has decades old versions of packages that they'll backport security fixes into till pretty much the end of time I don't know what filthy corner of the internet you get this misinformation from, but it is completely wrong. Please stop.

To be clear, I have nothing against them doing that, I'm just saying that this is how Debian generally operates. Their extended support model still allows for backporting fixes into jessie of all things, which released almost 8 years ago.

It's really good that they do that, I respect the niche they work in, but Debian has the nasty knock-on effect of having a lot of guides made for it by third parties that recommend really outdated versions of debian which can be a nasty suprise for someone new to Linux.

(It also results in notable forks like Raspbian having a poor update cycle - I remember in particular that it took about 2 years to move from the regular EOL of wheezy to jessie.)

Re: I'm Done with Red Hat (Enterprise Linux)

#266
post #219

Earlier quoted context omitted.

I agree with most of what you said, but: > If that angers you, I heartily encourage folks to build Debian up as the standard we all certify against. Or start your own business that overtakes Red Hat and earns the place RHEL has today. This strikes me as a variation of the "if you don't like Apple or Google's rules, make your own phone" or "if you don't like Youtube's content policies, then start your own video compan…

It's also, as has been demonstrated, wildly impractical for Red Hat to continue exactly as before without others undermining its business. The thing is that everybody is only lobbying Red Hat to make concessions, but nobody's going after Oracle or Rocky or Alma or other clones to say "hey, cool it. Red Hat's trying to keep a business going here. You're undermining their business. If you keep this up, they're going to…

> It's also, as has been demonstrated, wildly impractical for Red Hat to continue exactly as before without others undermining its business.

How was that demonstrated? RH became, famously, a billion-dollar company under the old model; why would continuing that not work?

Re: I'm Done with Red Hat (Enterprise Linux)

#267
post #263

Earlier quoted context omitted.

Regardless whether Red Hat said it or not, why not call it what it is? Not every CentOS user was a freeloader and the same is true for its spiritual successors. However, a large majority of CentOS users were not contributing back in any way to CentOS or the larger FLOSS community. Secondly, a substantial chunk of those users used CentOS because they wanted all the benefits of Red Hat EL without paying for it. That pr…

The term freeloading is stupid. There are customers who genuinely don't need and don't want support. And there are customers who do need support and should pay for it. It's that simple. Don't bundle them together as all freeloaders.

Redhat offers self-supported versions though, for half the price.

Re: I'm Done with Red Hat (Enterprise Linux)

#269
post #181

RHEL has a major ecosystem advantage related to drivers that they may not be aware of. They risk ruining this, as I will try to explain. At the time industry started to take Linux seriously, RHEL was the dominant distro. As a result, and by accident, RHEL+derivs became the primary target for commercial hardware drivers. As an example - it's easier to get obscure low-latency network and packet-capture cards working on…

If you don't mind, what makes more niche hardware drivers work / build better against RHEL? I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel. Beside the driver developers apparently using RHEL / CentOS (so on…

> I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel.

No, I think that's exactly the difference; Linux (in)famously has no stable ABI for drivers, and regularly makes changes that break things if you don't recompile against the updated kernel. Part of the value in RHEL was that they froze significantly more ABI surface, which made it possible to write proprietary drivers that would work across at least minor kernel updates without needing to be changed. That won't work on an upstream kernel because upstream doesn't go out of their way to freeze that ABI surface.

Re: I'm Done with Red Hat (Enterprise Linux)

#270

Earlier quoted context omitted.

Just a quick note: debian stable has a new release every two years. So in the very worst case "decades" means like three years. The horror, the humanity, just remembering how software used to be three whole years ago causes me to shudder.

That can still be ages depending on the maintainer spats. When I say maintainer spats, I'm referring to shit like how avconv was given undue credence for ages because the split happened right around a Debian release and the packager for ffmpeg on Debian was on the avconv side, which caused a false deprecation notice to be present for quite some time. And yes, with how quick some software moves, two to three years can…

> And yes, with how quick some software moves, two to three years can very much result in a mess of hacks and patches.

If you don't like the stable release, you could just run testing/unstable.

Post reply on HN