> That's true in a literal-but-useless sense. Developers-RHEL might be bit-identical to real-RHEL at some dates, but as a product it's of course very very different due to lack of interim updates. And that's aside of the smaller speedbumps of registration and having to involve Legal if you want to run in a company.
Again, stop moving goalposts. Your comment was "why can't they just put it on FTP/WWW without support". That's exactly what they do. You aren't required to register it in any way, including downloading. You want a free "product". That isn't their business model. At least they make the sources for everything available, which took Canonical years for Landscape.
> I don't know how true that is, the CentOS wiki makes it sound like like the debranding part is non-trivial/manual labour intensive. So according to you the main bottleneck is hardware / buildservers? If that's true, one wonders why even the minor CentOS 8.x releases lag RHEL 8.x by 4 to 6 weeks.
This is literally the build system. I have real-life experience branding a number of Red Hat products, including rebranding Anaconda and the base system. See for example https://github.com/oVirt/ovirt-release/blob/master/ovirt-rel...
The lag is because Koji (which is also used internally) uses a hierarchical build/tag system. See https://docs.pagure.org/koji/using_the_koji_build_system/ and https://docs.pagure.org/koji/tag_inheritance/
For a base release, a mock root needs to be bootstrapped. This is more or less by hand, and does definitely require incremental builds of and the rest of the base system. I guarantee the CentOS releng team has scripts that do this, but I don't know where they'd keep them (I never worked directly with that team). Once they're in a koji buildroot, that buildroot can be used to bootstrap its way to a 'release' buildroot, with successive tags. Again, this is something that any build engineer should be familiar with.
The real wrench with 8 is modularity, which is also present in Fedora. If you really want to help CentOS go help them fix it:
https://lwn.net/Articles/805180/
Issues like "special version of RPM in the buildroot" are weird non-issues specifically related to how Koji works, but Modularity does have real problems.
> Sure, I largely believe the long-running narrative that a lot of core Linux development is paid/done by Red Hat, and that most other distros, including Debian/Ubuntu are free-riding to some extend. That's why I not really behind the cheering for Rocky, and think it's fairer in the end to either pay up, or roll up the sleeves and do a real _community_ enterprise OS based on Debian instead of cloning RHEL.
This is a no true Scotsman argument. I don't know what isn't "real" or "community" about CentOS other than the fact that there was/is overlap between CentOS maintainers and RH employees. Just because they have day jobs doesn't mean they can't be part of the community, too. Hand wringing about what's fair defeats the purpose of using a distro like a tool to accomplish goals.
> The first part might be true of RHEL customers, but I don't think it's true for CentOS customers. The customer base is of course diverse, but my guess is that for a very large part of the (CentOS, not RHEL) users, objections to moving to Debian/Ubuntu are practical (legacy/switching costs, maybe followed by maybe proprietary software support), much more than principled/legal.
You inverted this argument and you're asking the wrong questions. The question isn't "why aren't people moving off CentOS?", it's "why did they use CentOS in the first place?"
It's because they were already familiar with RHEL from previous jobs, and wanted familiar tooling (apt may be nicer than yum was, but dpkg is a dumpster fire for package maintainers compared to RPM, and RPM's tooling is much more cohesive than digging around in 10 different manpages for apt-cache || apt-file || dpkg -L || whatever to get information). Kickstart is nicer in many ways than preseed. Sure, the costs of swapping all of that are non-trivial both in the time investment for administrators to rewrite tooling and for the marginal loss in productivity until they re-learn tooling.
Going forward, container-first distros are getting the brunt of new deployments, which is exactly why RHEL isn't a growing revenue stream for Red Hat anymore, and why it doesn't make sense to keep pouring money into CentOS.
Red Hat is focused on OpenShift/OKD as the new "platform". Containers have their place, and it isn't everywhere for lowly end-users, but RH didn't drop CentOS to fuck over the community. They reduced support for the community because RHEL (and CentOS) are increasingly irrelevant to a company which has put their eggs in the CoreOS+Openshift basket as their future. That isn't specific to them.
All of the major vendors see the writing on the wall. What's better than making your systems easy to manage? Making it so they don't need management at all. Do everything in k8s and update a single system image quarterly (or whatever), and leave traditional workflows as an afterthought. Red Hat is lucky enough to already have RHEL, but if I were starting a new for-profit Linux company in 2020, I'd do exactly what CoreOS did or Rancher does.