Live data from Hacker News

The Red Hat model only worked for Red Hat

opencoreventures.com

121–130 of 222 posts

Re: The Red Hat model only worked for Red Hat

#121
post #95

Earlier quoted context omitted.

Once you are the default choice that has other network effects, so yes. For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a…

And this is something that CentOS Stream breaks and that makes it not an alternative anymore. RHEL did ABI or kABI breaks only with minor releases. CentOS Stream can do them randomly, just like any other distribution.

Considering that CentOS Stream represents the between state of RHEL minor releases, it's not "randomly".

That said, the CentOS Kmods SIG generates reports on how the kABI churns in CentOS Stream[1] and RHEL[2].

[1]: https://sigs.centos.org/kmods/kabi/c9s/

[2]: https://sigs.centos.org/kmods/kabi/c9/

Re: The Red Hat model only worked for Red Hat

#122
post #92

Earlier quoted context omitted.

People used CentOS because it was extremely stable. It was the safest dsitribution to pick for a long-term support version of something, e.g. if you are distributing hardware to customers and you know you will have to maintain support for that hardware for 5-10 years. Companies that want this don't really care about community bugfixing and all that. They're happy with security patches so that their products look good…

They can just use Alma Linux now, Red Hat does not see anything wrong with that.

For now. That may well change soon, who knows? They saw nothing wrong with CentOS until a year or two ago, for years.

Re: The Red Hat model only worked for Red Hat

#123
post #95

Earlier quoted context omitted.

Does redhat have customors who don't need government compliance? If so, why do they use red hat?

Once you are the default choice that has other network effects, so yes. For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a…

> only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP).

Other distros also don't change kernel version during stable phase so I don't even know what you mean by that. Hell, RHEL kernels have more changes than say a Debian kernel over lifetime of a version.

What Red Hat uniquely does is to backport features into older version of the kernel, so statements like "you need kernel x.y.z for this to work" don't really apply, you need to find whether they backported that feature or not.

We've also experienced some "fun" with how they manage it and versions in general for example:

* Driver bug was backported from newer kernel (they backported "performance improvements" not bugs) in rhel5, so we lost VLANs on our upgrade canary * Same bug was backported to rhel6 with same disastrous result 6 months later * One of servers stopped booting because they changed version of LVM in STABLE DISTRO (think it was rhel6), and new LVM version deprecated/renamed some flag that we used, that made it fail on boot.

So yeah, we're very happy we migrated off it. And in Debian distro upgrade works too!

Re: The Red Hat model only worked for Red Hat

#124
post #44

Earlier quoted context omitted.

>A business model is promising to fix a customer's problem, certify their software, and get vendors to support them. This can also be described as assuming liability. Fact of the matter is people don't want to assume liability themselves. If they can pay to get someone else to assume that liability (which Red Hat is happy to do) they will. The rest of the FOSS ecosystem on the other hand is all about assuming liabili…

I've not seen any license accept liability. "Assume" is a different word, it means implicitly accept. There is no such thing as an implicit clause in any contract. Definitely willing to be shown otherwise, but I've never seen any vendor accept liability for there product beyond "you can have your money back, we'll take our software back".

Red Hat offers their paying customers indemnification from software patents for code from their products: https://www.redhat.com/en/about/open-source-assurance

That's a HUGE deal for multinationals, and virtually nobody else offers that.

Re: The Red Hat model only worked for Red Hat

#125

Reasons why people pay for Red Hat: 1. Customer support 2. Certifications 3. Vendor support I don't know another distribution of Linux that provides all these things to the extent Red Hat does. You don't use Red Hat because you want to, you use it because it's the only choice. Any business could do exactly the same thing, and do it better than Red Hat. But there's really not much reason for a customer to move away fr…

It's a shame your number one reason is customer support, when at least in my experience it has been woefully lacking.

Despite having a reasonably large contract with them at work, we had multiple support tickets go without response for months, with at least one that I am aware of being left open for almost 2 years before being closed as "won't fix"

Noting that its only my personal experience I am sure plenty of others have had the opposite experience, however I have found canonical support to be vastly superior as as such I would never chose RH if support was the primary thing I was after.

Re: The Red Hat model only worked for Red Hat

#126

Earlier quoted context omitted.

And this is something that CentOS Stream breaks and that makes it not an alternative anymore. RHEL did ABI or kABI breaks only with minor releases. CentOS Stream can do them randomly, just like any other distribution.

Considering that CentOS Stream represents the between state of RHEL minor releases, it's not "randomly". That said, the CentOS Kmods SIG generates reports on how the kABI churns in CentOS Stream[1] and RHEL[2]. [1]: https://sigs.centos.org/kmods/kabi/c9s/ [2]: https://sigs.centos.org/kmods/kabi/c9/

Randomly as in any dnf update can bring the breakage that you might not know upfront.

With minor releases you would read release notes, check your modules and knew, whether you can update or not.

Re: The Red Hat model only worked for Red Hat

#127

Earlier quoted context omitted.

Does redhat have customors who don't need government compliance? If so, why do they use red hat?

They also make Fedora which is the distro of choice for me and hundreds of thousands of others. And I use RHELlikes (Alma/Rocky) in my homelab just cause its similar to Fedora and Red Hat's documentation is much better than reading random blogs on how to do stuff on Ubuntu/Debian.

Documentation is good but... that's generic documentation about how software works, RHEL-specific stuff is maybe 5% of it.

I often hit it from search results (mostly for software made/supported by RHEL) and it works fine for Debian

Also, OS upgrades work

Re: The Red Hat model only worked for Red Hat

#128

Earlier quoted context omitted.

Great, so you won't make the piles of money that RHEL does, but maybe you'll enjoy your work more.

You can have work that 1) you enjoy, 2) is well paid and 3) is legal. Pick two.

Tell me more about this well paying and enjoyable work please.

Re: The Red Hat model only worked for Red Hat

#129
post #92

Earlier quoted context omitted.

They can just use Alma Linux now, Red Hat does not see anything wrong with that.

For now. That may well change soon, who knows? They saw nothing wrong with CentOS until a year or two ago, for years.

It cannot change because of how copyright works. If you mean dropping CentOS Stream, that of course can happen but then all the Alma Linux folks have to do is go back to how CentOS was developed in 2010.

It's also not that Red Hat saw something wrong with CentOS Linux. To put it simply, between 2014 and 2019 Red Hat learnt that the company needed a free RHEL upstream more than they needed a free RHEL downstream. CentOS Stream is all about sharing participation to the CentOS community so that everybody does what they need and they don't have to ask mom Red Hat. Just read https://www.theregister.com/2021/07/09/centos_stream_greg_ku... ("Greg Kurtzer: Red Hat did the right thing and the new scenario is better than the old").

In fact, a lot of effort went towards making it possible to ship RHEL's upstream as a rolling release. Consider that ten years ago you had to ask specifically, months in advance, about updating a package in a RHEL minor release. In 2010, a quality engineer and I spent a few weeks working on grep just to make sure that the bugs were fixed in Fedora before RHEL 6 forked, because otherwise we'd be stuck with those bugs for years. These days I could just open a merge request on CentOS Stream and ask to update to a newer version of grep.

Re: The Red Hat model only worked for Red Hat

#130
post #123
post #95

Earlier quoted context omitted.

Once you are the default choice that has other network effects, so yes. For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a…

> only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). Other distros also don't change kernel version during stable phase so I don't even know what you mean by that. Hell, RHEL kernels have more changes than say a Debian kernel over lifetime of a version. What Red Hat uniquely does is to backport features into older version of the kernel, so statements like "you…

> so I don't even know what you mean by that

Clearly you've no idea what kABI means. This article (for Red Hat customers) explains it: https://access.redhat.com/solutions/444773

Edit: A different link which isn't paywalled: https://developers.redhat.com/blog/2018/03/28/analyzing-bina...

Post reply on HN