There's no such thing as "post-COVID." COVID remains a global pandemic.

We're post-emergency, for sure. But COVID remains.

The only issue I have with Doctorow's term is that everything he's describing seems to be to be already covered by the concept of monopolies, and we already have a legal structure to handle it. (We only really lack the political will to enforce the existing laws.)

Yes, that is one of the core outcomes of a monopoly. That's why we regulate them.

Yes, that is called "dumping", and we already have prohibition and regulations.

Yes, also already prohibited for monopolies.

It's less ZDNET, and more Steven Vaughan-Nichols. And since CIQ pays him to provide PR, it's really less ZDNET and more CIQ making that statement.

... so all of the sources for this story are CIQ employees. And what they're really pushing is not that Rocky Linux users should build and run the freely available LTS kernels available from the kernel developers, they're pushing CIQ's ELP program, which offers a build of those kernels -- that they don't maintain -- strictly to paying customers.

Dude... IBM acquired Lotus Notes in 1995. That was 30 years ago.

Maybe you should look at work IBM has done more recently? How many of the people in charge of the Lotus acquisition do you think are still running IBM?

Personally, I'm excited to see how this turns out. Red Hat had a long history of acquiring non-Free software (like Ansible Tower) and then re-licensing it under a Free Software license. IBM has also been a good steward of Free Software projects like OpenJDK.

There's another, larger problem. Every particle in the universe has numerous characteristics, like spin and charge. In order to simulate each particle, the simulation must store and evaluate those characteristics. The most efficient encoding of the characteristics of each particle requires at least one particle. So any simulation requires at least as much mass as the mass being simulated. That makes it extremely unlikely, probably infeasible, to simulate a even a portion of reality.

However, if the simulation isn't of reality, but merely the subjective experience of an individual in reality, that's probably feasible.

And that means that the question is not just, "why simulate the 2020s," but "why would an advanced civilization need to simulate *you*, at this place, in this time?"

Because POSIX and related specification offer an objective, formal definition of an OS, and GNU implements those interfaces. It is, therefore, objectively an OS.

Any other definition is subjective.

But Xorg, Chromium, and KDE do not make up the OS. No part of POSIX (or related specs) require any of those things. Therefore they are not part of the OS, and they have no bearing on the name of the OS.

I honestly don't know why this is complicated for some people.

...if you think Chrome OS doesn't count, then you're probably not talking about "Linux," you're talking about "GNU."

Chrome OS is reported separately, but it's still a Linux-based desktop operating system (built on Gentoo, as I understand it). Reporting these results as only 4% minimizes the success of operating systems using the Linux kernel.

Yes, and it shouldn't be too hard to understand why. China is aware that the world is likely to run out of construction-grade sand, and that concrete may become either very expensive or infeasible in the future. They've been building large, mostly-empty cities in preparation for that future, while most of the rest of the world has been ideologically incapable of that kind of long-term investment.

tl;dr: Users retain all of the rights granted by the software licenses. The subscriber agreement is very clear about this.

Critics are treating the software and the support as if they are the same thing, and they're not. Your rights and responsibilities to the software are laid out in licenses. Your rights and responsibilities to Red Hat's support program are laid out in a contract.

As a Red Hat customer, you retain all of the rights to the software which are guaranteed by the license. Those rights are explicitly recognized by the support contract, which further clarifies that it does not restrict those rights. If you choose to modify and redistribute code whose license explicitly gives you the right to do so, Red Hat could not pursue copyright claims against you, because your right to copy and distribute that code is granted by the license. The software remains Free Software.

However, nothing in the GPL or any other license restricts Red Hat's rights to set any terms they want for their support services. And, more importantly, nothing in the GPL requires Red Hat to publish any of their code to the public. The GPL is deliberately written this way, so that GPL software can be sold.

Red Hat isn't trying to stop anyone from sharing the software. Red Hat publishes the software to the public, through the CentOS Stream project. There are no features, capabilities, or components in RHEL that aren't in Stream. Stream is complete and fully functional. The software is Free. The support isn't. Red Hat's support contract requires that their customers pay for a license for each machine running the software. Their support contract has a number of terms that specifically address that requirement, and clarify that you can't evade that requirement by manually copying the software from subscribed systems to unsubscribed systems. You can't evade the requirement by providing the software to a third party who hasn't agreed to the contract, because that would allow customers to create a legally independent entity for their production operations, and run an unlimited number of machines while requesting support in the org that was subscribed. You can't evade the requirement by rebuilding the source code into "totally not RHEL" and running an unlimited number of machines with that distribution, while requesting support for a small number of licensed RHEL systems where you reproduce issues from your "totally not RHEL" production environment.

The restrictions that exist in the support agreement don't exist to prevent sharing the software. Red Hat publishes the software to the public, free of charge. The restrictions that exist in the support agreement exist to clarify that if you try to evade the basic requirement that you pay for the number of machines that run software supported by Red Hat, that Red Hat might cancel your support agreement.

That's what Red Hat Developer Subscription for Teams is for. You don't need a half-baked rebuild to have dev/qa servers with software identical to prod.

https://developers.redhat.com/...

Liam's article is complete nonsense. Alma's approach, in which they actually fix bugs that affect their users, is an *improvement* over merely rebuilding another product, not a "step down."

It's bizarre how badly wanting to defend the old CentOS process has warped some people's rational thinking.

The premise of Steve's article is preposterous. AlmaLinux isn't staying compatible "without RHEL's code", they're compatible because they have it. RHEL is entirely Open Source software, and its main git branch is published to the public.

What? glibc has *highly* stable interfaces. Where did you get this idea?