> then Red Hat are freeloaders for relying on the Linux Kernel

"freeloaders"

Most Active Linux 6.1 Employers [1]

By Changeset

[...]

7. Red Hat 672 4.8%

By Lines Changed

[...]

10. Red Hat 24073 3.1%

Most active employers, 5.16 through 6.1

By changesets

3. Red Hat 4916 5.7% (behind Google and "Unknown")

By lines changed

8. Red Hat 202698 3.3%

[1] https://lwn.net/Articles/915435/

> If you're a freeloader...

It's dishonest to leave that conditional off the quote. The work and risk/stress involved in running a supportless shop is quite high. So if they are freeloading by using Rocky then Red Hat is also freeloading.

I do think it's funny that they weren't even number 1 on that list though. Guess they are at least getting a lot of volunteer work from other companies!

The others are almost all hardware manufacturers doing new hardware enablement.

It's hard to tell without more context of your own whether you're supporting what I said, or refuting the argument that Red Hat are freeloaders, which is an argument I did not make.

There's also different types of contributions. Hardware vendors like Intel and AMD are mostly contributing their own hardware drivers (and a lot of that, especially in AMD's case, is just autogenerated hardware definitions), whereas Red Hat is mostly contributing to core kernel functionality.

and that's just the kernel. Red Hat also runs or contributes to a bunch of other projects that are significant, especially relating to containers.

Not just containers, all the core linux stuff. gcc, binutils, gnome, systemd, etc.

One of the major differences between buying a support contract with RH and buying one from literally any other vendor is that RH doesn't sell support for things without having someone active in that project's community.

AKA, there is a good chance the gatekeeper that your !RH support provider is talking to is a RH employee or funded by RH. Put another way, rocky can't afford to hire 1k engineers to maintain all those packages, nor can anyone else so your trusting that the bug you want fixed can be fixed by a drive by contributor. This is part of the reason that RHEL has such a small package list too, just about every single package in that list has someone working upstream.

So, you won't get stuck like i did 15 years ago with a glibc bug that the company your paying a support contract to can't fix. Sure that distro patched their own version, but the change got dropped a couple years later during a rebase, and it was the only distro with the fix. Meaning our product only ran on that specific distro + version until we reopened the bug with RH and they actually got it fixed upstream.

To be clear, you're less likely to get stuck like that. There's plenty of bugs open that Red Hat doesn't fix because it's either too problematic or affects too few people. Sometimes that's eventually solved with a point release and them rebasing to a newer package version which includes an upstream fix, sometimes it just persists. I'm not saying it's common, but it's happened, and happened to us. Encountering a bug and finding the KB article with only workarounds and then a bugzilla entry that's been open for a couple years isn't exactly common, but I also wouldn't count it as all that rare in my experience.

Also to be clear, I'm wasn't making a case abovec that Red Hat doesn't provide a lot of benefit to the open source community, just that Red Hat could not exist without that same community. I do not begrudge Red Hat making money. I do think they're being extremely shortsighted if and when they shut off the larger open source community's uses of their core OS product. They're making their whole ecosystem much harder to get talent for if they do that, and it's not like entities running Rocky or Alma are just going to spring for RHEL. We trade on our staff's skill as System/Linux Administrators, and the core OS is not as important as all that. It's like if Python started requiring licensing fees. You'd get some short term return on that and some larger entities will just pay, but you'd see python usage in the general community plummet, with all that entails about its future.

Maybe to their eyes it makes more sense in this current world of startups and VC to just exclude the smaller players, since those companies that grow organically to a size where Red Hat's pricing makes sense are much rarer?

>Not just containers, all the core linux stuff. gcc, binutils, gnome, systemd, etc.

Depending on who you're talking to, this may not be a good thing.

... and looks like they're locking many of those changes to the source code behind their own paywall.

While it may technically be legal (ie crafted by lawyers to make sure of it), that still seems like a pretty shitty thing to do.

Red hat upstreams a lot of their patches, much more than Debian or Ubuntu.

I'm aware, I used to work for Red Hat (2010-2015). :)

Thanks for the feedback!

We've just about finished transitioning to 100% Rocky, coming from a 50/50 setup with many of the bare metal installs being Ubuntu. But Ubuntu left a real bitter taste in my mouth with the snap enforcement (I can't even start this snap thing in my Ubuntu Docker container? And you took away the native apt? Wow.), so we started a migration to 100% Rocky.

Telling my manager that we'll have to work something out after we just about finished working something out will be my own peril as well. Let's see where this will end.

I would wait a bit to see how this shakes out before raising the alarm. I'm waiting to see what Alma/Rocky do, as well as holding out a small amount of hope that RH and others will agree to something.

Yeah, we were late on CentOS 8, and had just put 3-4 systems and VMs into production when the Stream announcement hit, which made us stop in our tracks. We eventually accepted Rocky and started actually getting newer systems in place once 9 was out, so we just jumped to using 9 and in-place upgraded our Rocky 8 systems to 9.

We're only about a quarter migrated though, so still have a few hundred Centos 7 boxes to eventually get off of, and we'll see if that ends up being Rocky or something else.

I will note that this episode of The FOSS Pod[1] with a Debian lead actually made me think switching to Debian itself way back in the past (since we've been doing this for almost three decades now) would have been a safer path. I highly recommend it, it cleared up a few misconceptions I had as a Red Hat/CentOS user about what Debian is really attempting and why, and how that would fit with our needs. For example why their goal of pure open source licenses isn't an ideological choice, but a choice to benefit the Debian ecosystem, since the goal is to make downstream distros of Debian easy and without problem (e.g. no extra legal review needed based on licensed included).

1: https://fosspod.content.town/episodes/debian-linux-with-jona...

Same here, we still have 2 or 3 CentOS 8 to Rocky conversions to go from before we even started replacing Ubuntu!

I have to admit, while I share a lot of the values of Debian, I never really liked the product. Especially the apt package mangler, err, manager. They've also carried some Debian in-house patches that really caused me some grief in the past.

I've started running FreeBSD on my personal servers. Unfortunately it's not an option at work.

I've never really Debian it in the past, so can't comment on the reality, just what I've heard, and even my Ubuntu experience is lacking. I'm running it as a virtual desktop now, but I try to keep my use of it to an MUA, web browser and terminals so I don't have to spend the time to become familiar with it, given it's got no other use for me so far.

Our director loves FreeBSD, and we actually use it for firewalls, so it's not a spectacularly hard sell. I'm not sure it's significantly different from the problems of Stream to make it worthwhile, at least not without some external patching and support entity in addition, but it's been a long time since I looked at the specifics of their packaging and ports systems. I don't actually mind something like Stream for a personal server actually. It's just when trying to manage a fleet in the tens and hundreds when it becomes a real liability and increased possible admin support load IMO.

Asking from curiosity, what is the problem you had with apt? I'm using Debian close to 20 years now, and liked Debian and .deb a lot, more then RPM even.

Honestly, having built some packages and maintaining a derivative provided me more insight than a regular user, but even before that I was using Debian without any problems.

BTW, Ubuntu is not Debian with a different UI. They're pretty different on fundamental things, even.

A broken pre/post install script (often the problem is not expecting the current state of your machine) that fails while running `apt-get install -f` it the common culprit.

Just curious, why didn't you migrate from Ubuntu to Debian? Wouldn't that have been a smaller change?

Because we already had a solid base of RockyLinux VMs, so standardizing made sense. And I personally dislike apt / Debian.

Did you really compare our freeloading shop against one of the biggest software contributors to Linux and supporting ecosystem? RH is a top 5 contributor of patches across the most important core components.

Red Hat adds to the open source projects, they didn't write them from scratch (in most cases). Using freely provided software and building your business on it is perfectly acceptable, whether it's us using Red Hat's sources or Red Hat using the Linux Kernel sources and hundreds to thousands of other open source projects. We extend the OS where it doesn't fit our needs, and submit patches and feedback and bugs to both Red Hat through a subscription for a system we have for just that purpose, as well as to the upstream projects RHEL is based on, just as Red Hat contributes to the upstream projects.

So yes, I made that comparison. If you think a company using a RHEL derivative product is freeloading, I'm not sure how you can believe Red Hat isn't also freeloading on the open source community, but feel free to explain you position.

I, for one, think neither is freeloading, but just making use of the open source community to provide extra value for ourselves and our customers.