6 ms·

We're the same, but a little larger. Don't let anyone convince you you're a freeloader. If you're a freeloader, then Red Hat are freeloaders for relying on th

We're the same, but a little larger. Don't let anyone convince you you're a freeloader. If you're a freeloader, then Red Hat are freeloaders for relying on the Linux Kernel and all the open source software in their distros as well. What we both are are power users that don't really need their support. Our company has an entitlement so we can use the KB articles (to our benefit) and view/submit bug reports to them (which is to their benefit). I have no problems telling them that (and for the most part did last week), and if someone on the call were to argue me on that point, I'd have happily gotten into it with them. I know they're adding a lot to linux and open source, and pay for a lot of developers to maintain and add to projects (including Linux itself), but that's just the point, they're adding to something that already exists that they use. They don't own it, and they can't expect to require payment for it. They aren't Microsoft, and the only reason they've ever been able to compete in that space is because they're standing on the shoulders of what the open source community has made possible. It's a symbiotic relationship, and they can mess with it at their peril.

izacus 3y ago
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.
- kbenson 3y ago
  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.
e844dbe8fb 3y ago
[dead]
op00to 3y ago
> 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/ https://lwn.net/Articles/915435/
- freedomben 3y ago
  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.
  - StillBored 3y ago
    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.
    - kbenson 3y ago
      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 wasn't making a case abovc 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?
avhception 3y ago
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.
- freedomben 3y ago
  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.
- kbenson 3y ago
  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-jonathan-carter https://fosspod.content.town/episodes/debian-linux-with-jona...
  - avhception 3y ago

izacus 3y ago

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.

kbenson 3y ago
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.

e844dbe8fb 3y ago

[dead]

op00to 3y ago

> 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/ https://lwn.net/Articles/915435/

freedomben 3y ago
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.
- StillBored 3y ago
  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.
  - kbenson 3y ago
    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 wasn't making a case abovc 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?

avhception 3y ago

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.

freedomben 3y ago
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.
kbenson 3y ago
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-jonathan-carter https://fosspod.content.town/episodes/debian-linux-with-jona...
- avhception 3y ago