This is otherwise known as "industry standard".

Changing an industry standard isn't impossible, but it will be a paradigm shifting challenge akin to moving mountains.

If I were Rocky, Alma, Oracle and/or SUSE, I'd be collaborating to define our own point-release schedule off CentOS Stream*, and trying to make our blessèd commits usurp Red Hat's as industry standard.

* with blackjack! and public git repos!

SUSE might do that.

Rocky, Alma, and Oracle cannot do that because they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.

The point releases of a RHEL fork are meaningless unless they are identical to RHEL. If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.

> they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.

That's precisely what I'm suggesting they attempt.

> The point releases of a RHEL fork are meaningless unless they are identical to RHEL.

Why? (I'm not trying to be belligerent here — I genuinely don't understand why.)

> If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.

I thought CentOS Stream essentially is an incompatible point-release — or rather, RHEL is a point-release off CentOS Stream's rolling release.

Does Red Hat provide that much worse documentation for CentOS Stream than for RHEL?

I guess I just don't understand what is the “secret sauce” that makes CentOS Stream so useless, but RHEL so compelling (or even a rebranded-but-otherwise-identical rebuild of RHEL like CentOS 7).

CentOS Stream and RHEL diverge. (a) many bug fixes are back ported to RHEL 9.x, but not to the Stream 9 at the same time (b) they fix bugs right away on RHEL 9.x, but delay them for a long time (c) some packages in the Stream are from the latest upstream, and many major versions ahead of the same in RHEL 9.x

I wish I could upvote this 10,000 times.

Documentation isn't sexy or something. I don't know why Linux documentation sucks so much, but Redhat makes it suck must less. It takes lots of effort, money and writer hours to create the kind of documentation that Redhat maintains and businesses love documentation. A HOWTO or a FAQ are not documentation.

I actually prefer man pages and I dropped Linux for my personal project years ago in favor of OpenBSD (sometimes FreeBSD) precisely because their man pages are well maintained and really well written. I still have to interact with Linux sometimes and it's almost always Debian or Redhat. And I gotta say Redhat beats Debian on documentation.

Well, part of the reason Linux documentation often isn't very good is that Red Hat doesn't treat documentation work as something that should be submitted upstream.

Their incentives favour creating Red-Hat-specific documentation, and this then reduces their users' incentive to improve upstream documentation.

There is a difference between package documentation and system documentation. Red Hat contributes package documentation upstream, but system documentation is by its nature distro-dependent.

Red Hat has contributed work that made distros more homogeneous (cough systemd cough) and excellent package documentation for that work; but also got flak for that...

They also have soooo many good articles (which are helpful not just to RHEL) behind a subscription wall. If you do a lot of work in the rpm ecosystem, they're like the Experts Exchange of Google search, with how many times you see an exact bug report, then you get to the page with a tease of your exact answer, but it fades into the login required bit.

If you download the Red Hat developer edition and run a "yum update" once every couple of months, then you will get access.

The developer edition is now more inconvenient, as you have to reapply once a year.

And it used to be open, until Oracle started closing their tickets for paid support with essentially cut-and-paste of access.redhat.com. That's why you can't have nice things.

Arch has excellent documentation. It definitely stands out.

Because most devs hate writing and maintaining documentation. Simple as that.

Since we're generalizing: most devs aren't great at writing documentation either.

Technical writing is a field of its own and it's important to recognize that. We could ever be so lucky if such writers were as attracted to free software as some developers are.

>I don't know why Linux documentation sucks so much

because you need to pay competent people to do it. As FOSS is made up of lots of volunteers, lots of documentation isn't up to the standard we would want it to be.

I still don't really understand why being RHEL-compatible as opposed to CentOS Stream-compatible is so important (except in the specific case where you're running RHEL in production, e.g. on desktops, and need bug-compatible pre-production boxes).

Is the documentation for CentOS Stream that much worse? What does being RHEL-compatible get you over and above being CentOS Stream-compatible?

CentOS stream is not versioned. Packages do not move in lockstep. The documentation is good and accurate if you are on the latest version. What do you do six months from now, when some packages have been updated and others haven’t? What doc version do you use then?

Technically, CentOS Stream is versioned. The difference being it is versioned at the major release, hence CentOS Stream 8, 9, and 10.

It is true there are no minor releases of CentOS Stream, but that's due to how it fits in the overall RHEL pipeline. A minor release of RHEL is just an internal fork of Stream at a point in time before release where it essentially becomes "patch only", while Stream will continue on with its developments.

Big big big enterprises outsource IT to big big enterprise vendors, and they benefit a lot from standardizing on RHEL, because they employ people, who benefit a lot from documentation and tutorials and so on.

I would have thought that all the documentation and tutorials would apply equally to CentOS Stream — as I understand it, the only real difference is the schedule for releasing minor patches and bugfixes.

Is it the case that RHEL provides vastly better, more detailed changelogs for minor/bugfix updates (even to the public without an RHEL subscription) and that's what makes so much difference that an exactly-compatible rebuild of RHEL is useful but CentOS Stream isn't?

Bigbigbig enterprises have bigbig compliance departments, and audits, and so on.

RHEL is entrenched in that world, perfect for IBM (which also lives off those clients).

Whereas Nixs documentation is… well. I was looking through nix package code to sort out issues with nix on Hyper-V.

I really like Nix so far (just started using it), but damn is the documentation ever shit tier.

The documentation exists. That's the best thing about it and it's a whole lot better than none. It has been worse too. Compared to Red Hat though, there's just no comparison.

< Continuing on the offtopic thread >

When Eelco wrote his PhD thesis 20+ years ago, with the first version of nix, it was just an academic project. Now it's a lot more.

Although nix has a very good community, and plenty of contributor activity, there is way more code contributed than docs.

Additionally, very few people are technical writers in the nix community (there is a lot of expertise tho, but mostly on the code side). Therefore we get today's nonstructured docs.

Finally, RH has WAY more money than the NixOs foundation. RH sells stuff. Nix and NixOs are community projects, relying solely on donations. They probably have people whose job is to write docs.

there is an ongoing, organized effort to help docs tho: https://discourse.nixos.org/t/fundraising-for-the-nix-docume...

In practice, your best bet is just asking around on community channels (https://nixos.org/community/)

Yep, one thing I really liked at RH was the legion of professional technical writers they hired. The ones I worked with were the kinda unicorns that combined "understands code and complex systems" with "can express complex technical ideas simply and comprehensively".

That, IMO, is a killer feature. I really miss when consuming docs from commercial providers these days.