Hacker News new | ask | show | jobs
by brnt 1088 days ago
I don't understand all these CentOS forks: you're still dealing with Red Hat and reinforcing their ecosystem for free. What if those forks poured the effort behind Debian? A truly democratic distro that cannot pull rugs from under your feet.
3 comments

Debian LTS only has 5 years of support, without guarantees, on a volunteer basis.

RHEL has 10 years of support, with the option of 13 years.

I like debian, but sometimes you have to have long term support. And I fully understand why you wouldn't support 13 year old software without getting paid for it.

> Debian LTS only has 5 years of support, without guarantees, on a volunteer basis.

Seems like there's plenty of volunteering in the CentOS fork community. Why not put that wood behind Debian LTS arrow? Seems like a much better idea than continue trying to build on an unreliable partner like Red Hat.

But the work is mostly to repackage RHEL patches. To support Debian LTS for longer you have to do all the backports which is obviously much more work.
Seems like a great time for Debian to step up, and offer 'sponsored' 10 year LTS support for their releases..
> RHEL has 10 years of support, with the option of 13 years.

The problem here is that the people who need 13 years of support are perfectly OK with paying Red Hat for that. No one is saying that doesn't have great value if you need it... problem is you don't need it for an awful lot use cases.

Red Hat didn't get to a billion dollar business on the back of not "needing it for an awful lot of use cases". We may not see it since we're developers reading HN, where it's all about the latest tech stack, but those 13 years if support are a huge money maker for Red Hat. They'd do 15 and 20 if their engineers wouldn't revolt. Outside of sexy tech is companies that want really really really stable, don't ever want to upgrade, and can afford to pay not to, until the very end. Hence that whole Y2K rush to update software.

There's a ton of Python 2 code still out there that won't get updated to 3 if it can be helped.

It doesn't look big, but it's like an iceberg. 9/10ths of it is invisible, and just sits there, raking in money.

> Debian LTS only has 5 years of support, without guarantees, on a volunteer basis.

Less than that if you care about security patches. Debian's Security team stop after ~18-24 months, at which point it transitions off to, quote, "Debian LTS is not handled by the Debian Security team, but by a separate group of volunteers and companies interested in making it a success.".

In practice I don't think this is a huge problem. It seems the Debian LTS team only gives up on maintaining packages once it becomes nearly completely impractical to do so.

For example, here are the unsupported packages in Debian 10. These are the sorts of packages that don't get included with RHEL or SLES in the first place. https://salsa.debian.org/debian/debian-security-support/-/bl...

and RHEL has paid, by-the-vendors-themselves support options.

unless you're going to have an entire org full of Linux SMEs -- and most businesses aren't going to do that, they're not software companies -- then you need a support option.

Debian ain't got that, and Canonical is something of a basketcase.

If you want Debian, just use Debian. The idea behind CentOS and its successors is to have a free distro that is bug-for-bug compatible with RHEL, so that you can support users of your software who are on RHEL, or use software supported only on RHEL for free.
That's the idea, but Red Hat is making that ever more difficult. And I can understand why. Why would you build your world on such shifting sands, when all those forks could pitch in on Debian long term support instead?

Or just shell out for RHEL?

> Why would you build your world on such shifting sands, when all those forks could pitch in on Debian long term support instead?

Because RHEL is considered a standard in the enterprise circles, and software may not support distros that aren’t RHEL.

> Or just shell out for RHEL?

Why would you do that for smaller projects? Why would you do that for ephemeral containers? Why would you do that if you don’t care about RHEL support but want RHEL’s stability or are tied to RHEL for some reason?

Because it hasn't hurt Apple to have their proprietary garden and Red Hat has learned from that. Once you're big enough, people are going to do the work to support your nonsense (eg Asahi Linux) and build their world on your shifting sand. So why would you, as Red Hat, put in extra effort and not be capricious and hard to work with? It just costs you money that you apparently don't have to spend. Call it the Elon Musk is an Asshole (EMA) era of business.
The gratuitous anti-Apple remark. Walled gardens are at least as old as video game consoles and I can run whatever I want on macOS even if I can’t on my phone.

Somehow, whenever anyone spots a flaw in the FOSS model, it’s Apple’s fault. This is what people wanted, this is libre. Red Hat can sell for money. Remember, kids, CC violates a freedom!

This is what people wanted. Red Hat wants to be paid for their modifications to GPL code, and they've gotten their wish. They can't override the conditions of the license, but they knew that when they started making contributions. There's no world in which Red Hat has their hands tied by a license they opt-in to using. Red Hat can sell their own OS and block redistribution if they want, just not with GPL code.

You can only characterize it as "a flaw in the FOSS model" if you consider these patches to be Red Hat's property. They can sell it for as much as they want, just never "own" it.

> Walled gardens are at least as old as video game consoles

Walled gardens have existed much longer than that. But, so to speak, shooting someone at the country club doesn't give you the right to deny state police an investigation.

The idea was that Red Hat was doing things right, no need to punish them. But if they became a problem, there were other ecosystems.