More #inxi / #pinxi CPU issues, it looks like #fedora / #rhel have changed a default standard path in /sys for unknown reasons, thus breaking inxi cpu speed collection. This tripped need to do more refactors, this time to the fake cpu data debugger logic, it was not complete.
Also, a new codeberg issue pointed out that in many #Linux I can get basic RAM/RAM array data from udevadm, which appears to dump some dmi data into itself, available to user.
I get the feeling too many people are sleeping on CentOS Stream because of how the CentOS #Linux EOL thing went down.
I mean sure, the messaging wasn't great but it happened and it is what it is. Don't let that detract from the greatness of the #CentOS Stream project in its own right and as a collaboration point for all the #RHEL based distros.
The gravity seems lost on most that for the first time ever the RHEL development process happens in the open. That's amazing. I love it. #community
Here's why #GNOME absolutely should drop Xorg support, GNOME is the default #Linux desktop for #Ubuntu, #RHEL, and these are very popular distros for business use, this is the kick in the balls #NVIDIA needs to fix the drivers, business partners won't take NVIDIA's shit for long.
This is the first of, probably, many posts about the changes to how Red Hat distributes RHEL sources, RHEL clones in general. Not to mention the past, present, and future of FOSS development and business.
Short version: There's probably something in this post for everybody to disagree with.
Can we all agree to stop referring to the RHEL source export decision as CentOS drama? It doesn't affect CentOS at all. CentOS knew the rebuild model was fundamentally flawed and moved on to something better.
So I asked RMS what he thought about the whole RHEL story, since he's one of the co-authors of the GPL, and his answer was that he's not reached a conclusion yet and that "it's complicated".
Keeping Open Source Open https://rockylinux.org/news/keeping-open-source-open/ It seems like the Rocky Linux team is willing to find creative solutions to problems, even if it requires a bit of hacking. I am curious if Red Hat is willing to engage in this game of whack-a-mole. Was it truly beneficial RedHat? Was it worth it? #rhel#redhat#opensource#linux
Open Source community after Red Hat decides to go closed source 😂 #linux#redhat#rhel#opensource By limiting the RHEL public sources to CentOS Stream, it will now be more difficult for community/off-shoot enterprise Linux distributions like Alma Linux, Rocky Linux, Oracle Linux, etc, to provide 1:1 binary compatible builds against given RHEL releases.
I've been seeing lots of "the sky is falling" takes around Red Hat pulling out of LibreOffice RPM maintenance in Fedora. Here's a reality check: the vast majority of packages in Fedora are not maintained in an official capacity (i.e. part of their job) by Hatters. That's because only a small subset (~10%) of Fedora packages make it into RHEL. Currently RHEL 9 has 6,501 RPMs (from 2,393 SRPMs), while Fedora 38 has 60,807 RPMs (from 23,281 SRPMs).
Hot take: RHEL "rebuilds" were never about actual 1:1 RHEL compatibility for most users but "close enough" with less drama and overhead. When you needed better than "close enough", you bought #RHEL. Simple proposition. The threat seems to be that the new community rebuilds were just too good at that "close enough" with RHEL security patches hitting them before they were in CentOS Stream. This change specifically impacts those security patches that hit RHEL first. #Linux
As much flack as I've given #RedHat over #RHEL source shenanigans, they've kept #Ansible AWX #opensource and available to the public, very much to their credit. Tower was proprietary when they bought it and they opened it and kept it open.
And yes, this post is really about #Hashicorp. Don't do false equivalent arguments. Hashicorp definitely did the worse thing.
I really really hate the term "bug-to-bug compatibility". I hate how #RHEL clones story normalized it and people now talk about it like this is the main and only thing in the world.
While it doesn't make any technical sense.
Why?
Because ask yourself - is RHEL bug-to-bug compatible with RHEL?
Earlier today at #almalinux we patched CVE-2023-38403 in iperf3 and released it prior to anyone else in the EL-ecosystem. We promptly submitted PRs with #centos and #fedora.
A lot was learned during this process so we can nail down the processes of doing our own patches while contributing upstream and ultimately deliver on our promises from https://almalinux.org/blog/future-of-almalinux/
I just heard in a @christitus that #Redhat is close-sourcing #RHEL, but I'm failing to find the news on the Redhat websbite. Does anyone know the source?
Also I'm very surprised that I have seen nothing related to RHEL on my timeline. If this is real, it is a big deal, and a suite that other Linux distros might follow.
The elephant in the room nobody talks about when discussing the #RHEL changes is the reliance of so many applications and users on a "stable" "enterprise" release because they're themselves to under-resourced to do the work to keep up with the actual speed of #OpenSource development.
I have to admit that whenever I have weird server problems on #CentOS Stream, there's always a question of whether or not it's Stream or something else and that lack of certainty usually is just enough that I often might not file an issue for Stream, but also just enough that I second guess running CentOS Stream over #AlmaLinux in cases where I don't want/need full on #RHEL. When stuff breaks on AlmaLinux, I'm less likely to question the distro (even though bugs happen everywhere).
Red Hat’s commitment to open source: A response to the git.centos.org changes (www.redhat.com)
More about Red Hat's decision to make CentOS Stream the primary repository for RHEL sources.