Also, Jon "maddog" Hall needs to get his mind right. Red Hat hasn't "relicensed" RHEL. Red Hat cannot "relicense" RHEL. Red Hat has changed the terms of their subscription.
Jon didn't say anything about RHEL being "re-licensed." That bit of confusion came from either the person who submitted the article, or from the Slashdot editor.
The nature of recent changes is frequently overstated, as it is here. RHEL has not been "re-licensed."
At any given time, there are something like 15 actively maintained released of RHEL -- as many as 5 releases in the same major release. Red Hat has historically published the packages from just one of those 5 releases via a fragile process. (They'd take the src.rpm that results from a package build, unpack it in a git repo, remove the primary source, de-brand and commit the rest, and push the result to a public source -- basically git as a complicated FTP.)
Now that Stream is a thing, it serves the purpose of publishing RHEL source code. It's not de-branded like the old process, but it provides a means of publishing one branch of RHEL. And for the purposes of building a downstream distribution and collaboration, it's a *much* better process.
But, while Red Hat's process for publishing code has changed, the licensing and subscription terms haven't.
as we all know, the business is a little short of cash at the moment, so is having to pass these costs on to users
No one is under an obligation to sell you services at a loss, friend.
This sense of entitlement seems to be coming up a lot lately. Where does it come from?
Except that it's not a support program. RH tried that and it nearly bankrupted them
I see Red Hat employees make a statement generally similar fairly often, but they are talking about "helpdesk" style support, and right now I am talking about a much broader enterprise support relationship.
They keep talking about Centos Stream being the community project
The first important clarification is that The CentOS Project is described as being "community-driven," but the CentOS Project is broader than merely CentOS Stream. The project includes the Special Interest Groups that extend CentOS Stream and build new variants or projects on top of Stream.
and RHEL is their proprietary product that is built from Stream sources with a bit of proprietary special sauce added
The second important clarification is that RHEL does not have "proprietary special sauce added". RHEL (the software) is nothing more than periodic snapshots of CentOS Stream that receive continued support in the form of fixes for critical bugs and security issues.
RHEL is better understood as a support program. I don't mean helpdesk style "support-me-when-something-breaks" support. Support isn't something that exists only during incidents, support is a relationship. It's periodic meetings with your account manager and engineers. It's discussing your roadmap and your pain points regularly, and getting direction from them. It's the opportunity to tell Red Hat what your needs and priorities are, and helping them make decisions about where to allocate their engineers time to address the real needs of their customers. It's setting the direction for the company that builds the system that sits underneath your technical operations. That kind of support is what makes RHEL a valuable offering.
Because there is no special sauce added after the fact, CentOS Stream has to conform to the policies for RHEL updates. It is the major-version stable branch for RHEL.
To understand that concept better, consider: https://medium.com/@gordon.mes...
It's important to note when discussing Steven Vaughan-Nichols writing that he works with Cathey Communications, which is a firm that provides PR services to CIQ, the company behind Rocky Linux.
https://twitter.com/GordonMess...
That's important because it tends to explain why, when he writes about Alma, he emphasizes that they've "moving away from 1:1 compatibility", but when he writes about CIQ developments that are forks of Red Hat products, they're a "Rocky-friendly" fork.
The way he frames the development of forks tends toward praise in CIQ's case, and FUD in Alma's case.
We used to refer to this sort of thing as AstroTurfing. It looks like grassroots support, but it's manufactured.
It also tends to explain why, in this article, Steven uncritically quotes people trolling in Red Hat's GitLab merge requests, extending more legitimacy to their toxic behavior than he does to the actual developers.
Sorry to hear that. I've never had a problem upgrading Fedora releases from one to the next, personally.
It can't. Flatpak is tightly coupled with user sessions. It only supports desktop applications.
For anything not desktop applications, you'd use containers.
I think it's fantastic that Amazon has chosen to base their cloud optimized OS on Fedora. As the foundation of one of the most successful Enterprise operating systems available today, Fedora seems like a natural choice for other LTS software distributions.
At the same time, Amazon Linux is an LTS with a two year release cadence and a five year life cycle. The biggest difference between that and CentOS Stream is the cadence (where Stream's cadence is 3 years.) I wonder if bringing in new major features slightly more frequently will prove to be worth the effort of maintaining an entire distribution, or if Amazon will eventually choose to shift to a schedule that allows them to base Amazon Linux on CentOS Stream instead... Especially since building a system on CentOS Stream would provide the added benefit of binary compatibility with RHEL.
If he didn't like surveillance state with no human rights, Russia is a pretty sad choice of places to relocate to
You make it sound like he chose to relocate there. He didn't. He was heading to Latin America from Hong Kong when US authorities cancelled his passport, which stranded him in Russia. He has been unable to leave since, because he doesn't have a valid passport.
avoidance of Red Hat related distros. Unfortunately, as long as Red Hat remains the corporate standard for Linux, that's going to be a tough job to pull off.
From a certain point of view, that's probably not possible at all. Based on source code provenance reviews, Red Hat is the largest organization contributing development to many of the components in the GNU/Linux stack, all the way from low-level stuff like the kernel, libc, and the compilers, up to user-facing stuff like GNOME. And that's pretty fundamentally why Red Hat is the corporate standard, because those customers want support from the people actually involved in the development of the features that they need, and with the experience needed to fix bugs up and down the stack.
The idea that you can have a distribution that doesn't involved Red Hat is an illusion.
Would you say that nearly all of the rest of RHEL is first developed, and tested in Fedora?
No, and mostly because I think the idea of "testing" by human users to be antiquated. By far, most testing is automated, and it happens before release. The problem with interactive testing by humans is that it's really not a very high quality signal. Humans are bad at fully testing complex code paths, so lots of operations go untested if they're done by humans. And worse, humans are reluctant to do tests for the sake of testing. So if the purpose of a distribution is to test the software, you're going to find that not many people want to use it. Humans don't want to be lab rats, they want reliable products.
As far as I know, all (or a reasonable approximation thereof) of the individual components that Red Hat releases under the RHEL umbrella are released in Fedora first, but that's not "for testing". It's because Red Hat has a long history of releasing Free Software, and of acquiring non-Free Software in order to re-license it and continue its development as Free Software. The thing that Red Hat sells is support contracts for that software, and re-branding applications under RHEL is a superficial aspect of the process of selling support contracts.
It is not, officially, a beta or gamma. And as a Fedora maintainer, I think I'm pretty well informed.
Fedora is bleeding edge. It is not a production stable distribution by design and definition
I don't know who told you that, but that is not the position of the Fedora organization. Fedora is intended to be a reliable OS, with 13 months of interface stability. It's production stable for many workloads.
Think of it as a beta of the next RHEL point release
Well, except that it's not a beta. CentOS Stream is intended to be production-stable, and bugs in Stream are regarded as bugs in RHEL. Packages get all the same testing and QA before release in Stream that they traditionally have got before release in RHEL.
Packages are released in CentOS Stream when they're ready for RHEL. (However, in order to provide extended support for RHEL minor releases, Red Hat has to delay release of some types of updates until the next minor release.) There *is* a chance that a bug will it Stream, but it's no greater than the chance of a bug hitting RHEL in the past.
"Here's something to think about: How come you never see a headline like `Psychic Wins Lottery.'" -- Comedian Jay Leno
