this post was submitted on 26 Jun 2023
758 points (98.7% liked)
Linux
47559 readers
704 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I dont understand how redhat is going to police this policy of "we'll keep source code open to paying customers, but reserve the right to cancel a customer that shares said source".
Toss in GUID's or randomly place identity files to anyone that downloads the RHEL source hoping they get accidentally published as an identifying attribute if someone does decide to publish it elsewhere.
And make sure that identifier scheme still works if different people on different subscriptions download the source and compare to filter identifiers like that out...
They could try that but I suspect it would be rather easy to find anomalies like that. These are ultimately patches to an upstream and already open-source project, so one can just diff the RHEL version with the release it's based on and quickly notice that random GUID in the sources or random spaces/indentation. Or have multiple sources leak the code independently, and then you can diff them all between eachother to verify if you got exactly the same code or if they injected something sneaky to track it, and remove it.
Lots of companies in enterprise also want to host their own mirror because the servers are airgapped, so they can't even track who downloaded all the sources because many companies will in fact do that. And serving slightly modified but still signed packages sounds like it would be rather computationally expensive to do on the fly, so they can't exactly add tracking built into the packages of the repos either. And again easy to detect with basic checksumming of the files.
I don't think that many companies have their shit together well enough to mirror the source code, besides the RHEL repos aren't small, so that'll cost.
The companies I've helped either had a minimalist mirror to reduce the surface area of what was installable or to save on cost.
It's possible that a few enterprises do a full mirror of all RHEL sources, but i doubt it's many
I don't know, I've worked in Debian/Ubuntu companies mostly. Last two had thousands of servers and both had an apt-mirror custom repo including the deb-src ones. Otherwise we just get ourselves banned from the official mirrors when thousands of VMs pull updates from the same NAT IP.
Not sure how that works exactly on the RHEL side, maybe it's not nearly as easy or common to do that.
TBF i was a contractor so i was almost exclusively working for disfuncional companies.
IIRC If you pay RHEL money it's pretty easy to do with Satellite, otherwise you had to JerryRig Spacewalk to do the same thing, but it's been a while and i never actually set up Satellite as the enterprise companies I'd worked for were cheap.
There are like 3 or 4 downstream distros they needed to keep track of. They probably aren't going to police everyone, but if rocky and Oracle keep churning out releases like this, they will probably target them, and because it's a simple one off specific customer, they can dedicate a couple people to tracking that down without making big changes or embedding guids and such.
Unenforceable for individual users, maybe. But the distros that depended upon it will need to be open and honest about their sources so cannot do that. Users trust distros because of transparency.
This is not about an individual sharing the source. This is about near verbatim copy distributions like Oracle Linux. And they can easily see who contributes code from RHEL into those distributions.
I think Jeff has a point that a Linux distribution is a collective effort, but I honestly don't see why he can't just target Fedora which is for all intends and purposes the testing release for RHEL and most of the development work that Red Hat does goes directly into Fedora. RHEL adds little of value to that other than some compliance BS for large companies.
Oracle really does eat Red Hat lunch. Oracle practically recommends using Oracle Linux to their own customers. After paying a lot of money to Oracle, you probably aren't thrilled to pay for yet another expensive license and just install oracle linux.
https://docs.oracle.com/en/database/oracle/oracle-database/23/ladbi/operating-system-checklist-for-oracle-database-installation-on-linux.html
doesn't Fedora drift fairly well ahead of RHEL with new major releases of components from upstream with every release? Especially with the kernels getting so far out of sync with between the two.
As far as kernels go, I wonder if it is at all practical to do what Arch does and provide a linux-lts package. Maybe they do and I am simply not aware of it. I haven’t used Fedora in a while.
Yeah, but that is Red Hat's problem then, no?
Well I wouldn't go around asserting software that I develop works on RHEL on account of me testing on Fedora because even with 13 month of package updates for Fedora, a supported RHEL release could be running a kernel 4 years older than any currently supported Fedora version. If I have customers who demand RHEL compatibility, I have to either lose that business or test on RHEL
Fedora isn't the testing distribution for RHEL, CentOS is. Fedora is upstream of CentOS and could be viewed as the bleeding edge in that regard. CentOS used to be downstream of RHEL, but that changed a few years ago when IBM did its first shitty thing at Red Hat. The tree is like:
Fedora (Top of code stream, "unstable" from a business perspective)
|
|
v
CentOS (midstream, much less frequent feature updates)
|
|
v
RHEL (end of stream, stable/predictable/reliable/etc)
And I couldn't disagree more about RHEL adding little value. You're not going to run a server on Fedora for something you want/need to rely on, and especially rely on not to change much/cause breaking changes. That's what RHEL is for and it is the gold standard in that regard.
And that's not even mentioning the fact that Red Hat support is some of the absolute best in the world. Motherfuckers will write a bespoke kernel module for you if that's what it takes to fix your issue. Not sure if that's still true after the IBM takeover though, but that was my experience with them before that.
You can absolutely run important services on Fedora server edition. Most of the stuff in containerized anyways, so having a more up to date version of the base system is actually an advantage.
It is really only those large corps with massive closed source lagacy applications and loads of compliance regulation that need a stale but long term supported distribution like RHEL.
I use redhat at home for proprietary video, once I pulled out flatpak it’s become my favorite distro. I hate the changes redhat made, but from a business standpoint I totally get it.