The comments there are insightful and actually make me think this is the right move:
> Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusion of these two RHEL clones’ success would be to eliminate their host, leading to their own demise, which is why one person in the Linux space called them the “dirtbags” of open source.
> If there are any real parasites, it's Oracle Linux.
> Oracle Linux (abbreviated OL, formerly known as Oracle Enterprise Linux or OEL) is a Linux distribution packaged and freely distributed by Oracle, available partially under the GNU General Public License since late 2006.[4] It is compiled from Red Hat Enterprise Linux (RHEL) source code, replacing Red Hat branding with Oracle's.
I had no idea that Oracle Linux was essentially RHEL with %s/Red\ Hat/Oracle/g and Oracle has a market cap of $330bn
I avoid anything Oracle. Their licensing model is hell. Their products are usually terrible compared to competition. Cloud products are subpar. Products tend to require a support contract since it’s proprietary dogshit.
Some tidbits of Oracle and Larry Ellison (founder, CEO):
- in the early days of Oracle DB, it was benchmarked and compared against other RDBMS and Oracle DB was found to have poor performance. Ellison and Oracle tried to get the professor fired and introduced language into their EULA preventing benchmarking [1,2]
- then there is the growing list of controversies documented on Wikipedia [3]
Also in terms of security, Oracle's "forks" are decades behind. They managed to make RedHat unsecure with their own dogshit changes.
There are so many CVEs for Oracle specifically that are just bad default usernames and passwords, where they still dispute the CVE reports because it is "intended behaviour".
RHEL also introduced some.... interesting changes few times, like re-enabling ciphers removed from upstreams because their clients needed them for something.
I remember our amazement on how we failed audit on having a cipher enabled in OpenSSH version that had that cipher removed in upstream...
I always have to chuckle a little when git tells me that Azure DevOps is too unsecure to connect to because of a deprecated cipher they still use today :D
Losely related: I've audited so many BSD instances that were using MD4/NTHASH in their passwd and shadow files because they wanted to keep compatibility with their Windows infrastructure... it's stunning to see what is still possible in terms of misconfigurations. Things that should have been removed a long time ago.
The neat thing about RHEL is that there's a single 'crypto-policies' package which configures available TLS versions and algorithms for everything in the system: TLS, SSH, IPSec, DNSSEC, Kerberos and so on.
Regarding SSH, the FUTURE policy removes AES128, HMAC-SHA1 and DH Group 14.
Yet people are really happy to buy into Oracle because they have a free tier[0] (which, you probably should avoid anyway[1])
Or they argue to exhaustion that MySQL (not MariaDB) is totally fine for production, despite decades the company who now owns MySQL strangling companies to near death over minutia.
My Oracle free tier VM got destroyed without any info with no prompt or anything.
Then my account was put in such state where I couldn't even pay to upgrade it to paid one
> Or they argue to exhaustion that MySQL (not MariaDB) is totally fine for production, despite decades the company who now owns MySQL strangling companies to near death over minutia.
Who you gonna trust, billion dollar corporation, or man that sold that DB off to them then started making a fork ?
No really, nobody ever gets fired for going with Oracle or any of the big blue chip dumpster fires.
Any org with deep enough pockets to afford Oracle at scale has a deep enough org structure and bureaucracy that those huge wasteful projects produce nothing but promotions.
This is only true it RHEL was self contained OS Project with no Upstream sources itself...
That is not the case, RHEL is not possible with out the wider ecosystem, and to say Rocky Linux is a "dirtbag" for repacking RHEL, would be like saying RedHat is a "dirtbag" for packaging any number of free software projects they consume into their product.
It completely antithetical the free software movement for which Linux is Licensed
However it is perfectly on brand of the "Open Source" corporatist movement that seems to be supplanting free software
I'm not going to call Rocky or Alma "dirtbags" (does anybody use that phrase these days?) but comparing what Red Hat does to Rocky is misleading.
RHEL Clones: Take finished source code, rebuild, test, release.
RHEL: Work upstream to develop features / submit features upstream before inclusion in RHEL, maintain specific versions of upstream, test hundreds of upstreams together to make sure they can be shipped together as an operating system, develop "glue" software like Anaconda to install + manage the whole thing, take source, build, test, release, accept bugs, start over again for next minor release or major release as needed.
And, of course, this elides all the certification work that makes RHEL an attractive enough project to rebuild in the first place because people want very specifically a RHEL compatible distribution to run an application or applications on top of.
What people get pissed at Red Hat about isn't that they don't get to access the source. They're pissed they don't get the convenience. Largely speaking, the people who get pissed aren't concerned about Free Software, either - they just want easy to run binaries. As I understand it "get binaries for free" is not mandated by the four freedoms. The source code is still out there for people to study, change, use, and redistribute. That seems entirely compatible with the free software ethos - but incompatible with the freeloader ethos.
Rocky and Alma are doing exactly what CentOS pre-Stream did for _six_ years. Now they're frustrated that their decision to kill the CentOS idea didn't stick?
Red Hat might have the legal right to gate their product, but it seems really slimy to build RHEL on the work of who knows how many people that publish it for free and then to put road blocks around their derivative.
I don't really like reductionist blaming, but I feel basically forced to wonder what Red Hat would be doing if IBM wasn't involved.
Take a look at this [1] and tell me one company that comes close. RH has surely made questionable decisions, and yes that seems to be increasing since IBM. But the heat they get is precisely because people are used to having free lunch and then feel it's been taken away. I don't see AWS, Oracle, and others getting the same treatment for benefiting immensely from open source, without contributing much in return. Would you rather have an industry dominated by RH-like companies or the others?
Without exaggerating, I think I've read maybe two kind comments about Oracle _ever_. Their handling of the Sun IP alone could overfill thread after thread with vitriol.
And I think an analogy is apt. Someone was one telling me that religions that are slightly different (think Protestantism versus Catholicism) lead to far greater strife than religions that are vastly different (like Buddhism and Catholicism.) Maybe people are just louder about the things they care about and feel close to.
"it seems really slimy to build RHEL on the work of who knows how many people that publish it for free and then to put road blocks around their derivative"
I'm always curious that people get angry at Red Hat profiting on the work of others, but few people get angry at the companies that use a RHEL clone to run their business and pay nothing and contribute nothing.
Red Hat is still releasing source code. The only thing that it's not doing is making it super-convenient to rebuild exactly its product.
Seriously - for most purposes CentOS Stream is just fine if what you want is a distro that feels like RHEL. Its one drawback is that it's not a one-for-one clone of RHEL, which generally only really matters if you are using it to run your business. Which gets me back to - why are people so pissed at Red Hat but not all the organizations that make money using RHEL but don't pay towards its development?
> Red Hat is still releasing source code. The only thing that it's not doing is making it super-convenient to rebuild exactly its product.
Releasing only to their customers and only if not redistributed. If you held redhat to the same standard for the open source they redistribute they couldn't exist.
> Rocky and Alma are doing exactly what CentOS pre-Stream did for _six_ years. Now they're frustrated that their decision to kill the CentOS idea didn't stick?
CentOS wasn't selling support contracts tho.
Not that I think anything they are doing is in any way wrong mind you.
The RESF / Rocky Linux project does not sell support contracts. That is a contract for CIQ. Any company is free to sell support services for Rocky Linux (and many do, including OpenLogic, MontaVista, CIQ, TuxCare, etc).
> However it is perfectly on brand of the "Open Source" corporatist movement that seems to be supplanting free software
This has been happening on HN too. The vilification of GPL and AGPL as ”not free in the truest sense of the word”, the usage of RMS and his personal image to label the free software movement outdated/fanatical/toxic is a testament to how corporate rebranding efforts have succeeded in replacing free software with open-source — software that is conveniently licensed so that corporations can bake it into their product without a single concern for the longevity or well-being of the developer or the software itself.
> , the usage of RMS and his personal image to label the free software movement outdated/fanatical/toxic
What if i love and use the AGPL, but also won't involve myself with the FSF because I think they are runining the movement and also definitely want no direct association with RMS.
I think RMS is an active harm to the cause of Free Software.
Yeah. Open source is a wealth transfer from developers to corporations. I've reached the conclusion that anything other than AGPLv3 means we're working against our own interests. Giving up the leverage provided by the GPL benefits only corporations.
I think I get the gist of your sentiment, and somewhat agree, but let me clarify.
GPL, only enforces redistribution of software you distribute, "to" the people you desteibute it to, aka customers.
Most other licenses (MIT, Apache, BSD, etc) don't require any code redistribution (though some require attribution).
GPL ~= redistribution to customers
Other ~= no redistribution
Red Hat is complying with the GPL requirements even for BSD, Apache, and BSD licensed code, which I think is good.
I think a more sinister trend forming is around open core, and essentially proprietary code mixed with no code redistribution at all. This makes open core essentially closed source for all intents and purposes. Companies are using open core simply for free marketing and to drive technology adoption in the sales/marketing funnels.
* the term "open source" predates the term "free software" in the FSF sense
* "open source" was proposed as a synonym for "free software" in the late 90s
* liguistically, the term "free software" emphasizes freedom, while "open source" emphasizes source-available
* there is no law mandating everyone use OSI's definition of "open source"
* consequently, there is ambiguity in the term "open source", ambiguity exploitable by those who want the social cachet of free software but are not philosophically aligned with it
* there is ambiguity in the term "free software" as well but don't worry, if they mean it in the FSF sense they will certainly take the time to explain
I humbly submit therefore that the GP framing is essentially correct, that RMS was right not to endorse the term "open source", and that whatever OSI says the term is philosophically compromised and should be "considered harmful".
The inverse is also true (barring possibly some insignificant exceptions). Can you name any mainstream open source license that is not considered free software?
It absolutely does. The difference between these two movements is purely philosophical; practically they describe the same things, they just do it in a different way and for different reasons.
(that doesn't mean the difference isn't important though)
Name an open source license that you don’t consider free software, then. Note that “source available” (Business Software License, etc.) is not the same thing as “open source”.
It's not about what you consider or not. The Free Software movement is very clear. It is about the freedom of the user: "I, the copyright owner of my own code, allow you to use my code as long as you let your users have (some kind of) access to my code in the product they buy".
Really as an end user, I just don't understand who would be against the Free Software philosophy: either you don't care, or you want as much control as you can on what you buy, but why would you ever say: "I don't want those weird licenses that give me more access to the stuff I buy, I want the other ones that make it completely proprietary and inaccessible".
Of course as a company, you want permissive licenses, such that you can use it for free, but keep it proprietary (because companies like to think that this one bugfix they made is very strategic IP).
It sounds like you're implying that permissive licenses don't count as free software licenses, but that has never been true. FSF has always said that permissive licenses are free software licenses and that permissively licensed software is free software. However, they advocate the position that this might not be the best way to protect all downstream users' freedom.
> When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “free beer.”
Right, so you might have, for example, FreeBSD, which as distributed by the FreeBSD developers is free software, but which can also potentially be used in a proprietary downstream product, which is not free software. The FreeBSD developers did not deny users any of the four freedoms. They just allowed other people to potentially do so.
I was wrong indeed, thanks for the precision :-). So:
Permissive licenses are free in the sense that they allow making free software (but they also allow making non-free software).
GPLv3 enforces the complete derived work to be free. LGPLv3 says that the particular library should stay free.
GPLv2, LGPLv2 and MPLv2 say that the source code (either of the whole derived work or just the library) should stay free, but tivoization allows making the product non-free.
Please note that "Tivoisation" isn't what Tivo actually did and both the GPLv2 and GPLv3 ban "Tivoisation" but allow what Tivo actually did. "Tivoisation" as it is popularly known refers to blocking the running of modified GPL code, while what Tivo actually did was block running their proprietary software (their UI etc) on top of modified GPL code (here Linux). Both GPL versions block the former while allowing the latter. At least according to Software Freedom Conservancy.
That's interesting, I remember thinking that the original notion of Tivoization did apply to what Tivo did (including what you describe).
I wonder if this is a point of disagreement between FSF and SFC -- I know they now have several disagreements.
In a similar time frame, I criticized attestation features in trusted computing because they would allow (in fact one of their main purposes was to allow) network services to allow only certain software configurations to interact with them. And I thought I was talking about a similar concept!
You may be thinking of SFLC, their disagreements with FSF are much larger. SFC's disagreements with FSF are mostly related to keeping RMS around.
Attestation is indeed a big problem today, especially around Android devices and proprietary apps that won't run on libre Android distributions. The attestation feature of WebAuthn could also become a problem, but that is somewhat mitigated by the Apple passkeys not being attestable.
I get why companies can make more profit in a world where most software is under a permissive license. I just don't really see how it benefits users and, more importantly, developers as individuals.
To me, writing software in my free time and open sourcing it under a permissive license is shooting myself in the foot. I did the work for free, it may as well benefit me as a user. At minimum it should be MPLv2.
That matches my understanding. Some people might potentially only say "tivoized" (or a more explicit "incorporated in a product that prevents the user from modifying it in practice" or "incorporated in a locked-down product" or something) rather than "non-free" for a hardware product, but I guess "non-free" could also make sense for a hardware product.
MIT, BSD, Apache, anything that is open source but allows you to make the code proprietary.
> When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “free beer.”
Permissive licenses are "free" in the sense that they allow to distribute free software (e.g. I can distribute a binary together with its sources even if they are MIT-licensed, and that would be free), but they also allow to distribute non-free software (e.g. I can take MIT code and distribute a proprietary binary).
Copyleft licenses enforce the freedom downstream.
I guess my original point is that I don't understand why people don't like copyleft, because copyleft enforces free binaries.
Yes, that sounds right to me. “Free Software” and “open source” are synonyms, with the FSF preferring to use one term over the other, despite recognizing they’re synonyms, because they are ideologues who are obsessed with language use. Permissive and copyleft are two different types of free software/open source licenses, with the FSF preferring copyleft.
To answer your underlying question: I like permissive licenses because I am not ideologically opposed to unfree software, and I’d rather software be used by a company than not at all.
> I like permissive licenses because I am not ideologically opposed to unfree software, and I’d rather software be used by a company than not at all.
My opinion differs here. First, the free philosophy is nice for me as a user: for instance say I buy a Marshall "smart" speaker, for which the software kind of sucks and is essentially not maintained (but still it connects to the internet...). I don't see how it would hurt Marshall to enable an open source ROM. After all, they sell the hardware, right? And a big part of the software running on that speaker is open source; they did not pay anything for it, and more often than not, they "forget" attribution for permissive code.
But companies try to minimize their costs, and contributing a bugfix back upstream is seen as a cost (conveniently ignoring that they did not pay for the software in the first place). With a copyleft license, of course the company can keep ignoring the license (like they do for attribution in permissive licenses), but at least it gives the developer an argument for contributing back upstream.
And it doesn't have to be GPL. LGPL and MPL are easy to handle.
> I’d rather software be used by a company than not at all.
If the software has value, I am convinced that they can deal with copyleft (see Linux). And if the majority of open source software was copyleft, then companies would be used to it. Copyleft is really not that bad, it is just perceived as a source of cost by companies.
You're wrong and probably mistaking these terms with copyleft and permissive licenses. Both of these kinds of licenses are both Free Software and Open Source.
In practice, pretty much every Open Source license is also Free Software license and vice versa (there are some very nitpicky exceptions, but I guarantee they're not where you'd expect them to be).
I don't dislike your sentiment and don't see Rocky Linux as dirtbags, but I think it is important for GPL that you have to[1] provide source only if you provide binaries (IANAL, lawyers correct me). So you should be able to have a business where you sell software and the people who buy receive the GPL'd source code (that they can then modify and share). You don't have to develop in public, or use version control programs: participate in the whole "GitHub culture".
GPL tries to guarantee an environment for user freedom (not developer convenience, like permissive licenses). It has builtin protection against someone closing the source. It doesn't protect against some company pulling an Internet Explorer on you (i.e. providing a free equivalent) with your own code, because this doesn't directly concern user freedoms. You don't have to be actively helping them though.
I think ultimately free-of-charge mirrors should exist, but I see good potentials in companies discovering business merits of GPL, and hopefully AGPL. We need more vigor for those, after getting lucky once with Linux. We cannot rely on good will of corporations (only enforced law works on them), so any sign of luring them into copyleft somehow is a good thing. This would be a long road, but who knows what could happen in the current "AI" chaos and regulation scares.
[1] Of course only have to assuming that you are not the original author and you're building on someone else's code received under GPL.
I thought that was well known, it's not like they were secretive about it, in fact they openly advertised it. Their sales pitch, I think was, that many customers ran Oracle software on RHEL, and this way they would have a single provider of support for both the OS and the software running on it.
Given Oracle's rather well-earned reputation, that does not sound like an attractive proposal to me, but there's a chance orgs that are on the hook for anything Oracle already might not share that assessment.
IIRC, Oracle's move to eat part of Red Hat's lunch was considered the reason Red Hat stopped making the kernel source available in the form of mainline tree + patches, thus making it less convenient for Oracle's staff to provide support at the same level of expertise as Red Hat, but I don't think anyone working at Red Hat has commented on this on the record.
When Oracle started offering support for the oracle db on RHEL, whenever there are performance issues and other issues, Oracle used to blame RHEL. So oracle DBAs are trained to go back Redhat for issues. Usually, these support issues bounce back and forth: Oracle blames Redhat, which says it’s an oracle issue. In the mean time, oracle support folks just buy sweet time. Then came Oracle enterprise linux: oracle supporting the whole stack, OS and databases. Which enterprise customer doesn’t want that. Not only that, many corporate customers of RHEL switched to Oracle Linux, as oracle charges way less for each installation.
As an employee, I dont think anyone can. I'd make speculation here, but we all know how that ends up being twisted into misunderstanidng. The current kernel source is available on gitlab though (centos-streams) because now centos streams is upstream of rhel kernel.
Is not this something what Open Source exactly suppose to allow you to do ?
I have no love for Oracle but I would imagine one of the reasons Oracle embraced RedHat Enterprise Linux early on was the fact they could fork it if it was in their interest - this was tremendous value for RedHat for a time and helped its establishment as leading Linux for Enterprise.
Remember also what RedHat itself "stands on the shoulders of the giants" - there are a lot of packages which RedHat includes. Years ago when I worked at MySQL AB RedHat used to include MySQL packages, say they are covered by their "subscription" but have no revenue share with MySQL AB (as creators)
Note I'm not complaining I'm saying this is exactly how things upposed to work - MySQL got great value from being Open Source and allowing Linux distributions to include it (and make money on it) freely.
The "Unbreakable Enterprise Kernel" includes full btrfs, extensive device support (that is removed from the stock kernel), is tuned for the eponymous database, and is always more current. There are several scenarios where it is very attractive.
Oracle bought K-Splice several years ago, which was the first rebootless patch solution for Linux. It's only available with a premium license; Kernelcare is a lot cheaper.
Supported Oracle Linux versions are also available for WSL1 inside of Windows.
C:\>wsl.exe -l -o
The following is a list of valid distributions that can be installed.
The default distribution is denoted by '*'.
Install using 'wsl --install -d <Distro>'.
NAME FRIENDLY NAME
Ubuntu Ubuntu
Debian Debian GNU/Linux
kali-linux Kali Linux Rolling
Ubuntu-18.04 Ubuntu 18.04 LTS
Ubuntu-20.04 Ubuntu 20.04 LTS
Ubuntu-22.04 Ubuntu 22.04 LTS
OracleLinux_7_9 Oracle Linux 7.9
OracleLinux_8_7 Oracle Linux 8.7
OracleLinux_9_1 Oracle Linux 9.1
SUSE-Linux-Enterprise-Server-15-SP4 SUSE Linux Enterprise Server 15 SP4
openSUSE-Leap-15.4 openSUSE Leap 15.4
openSUSE-Tumbleweed openSUSE Tumbleweed
Oracle Linux came into existence shortly after Red Hat bought JBoss. As Oracle had also bought BEA Weblogic (IIRC), this was not taken well.
> The "Unbreakable Enterprise Kernel" includes full btrfs, extensive device support (that is removed from the stock kernel), is tuned for the eponymous database, and is always more current. There are several scenarios where it is very attractive.
I'd never go for btrfs in anything enterprise.
But it does annoy me how RHEL moves normal open source software to the separate repos that are available with extra support packages, it just makes managing it annoying
RH generally only removes features in major releases. The exception is when they introduce features as a technology preview. Those are subject to potential removal before the EOL of that major release, though they rarely do.
That was what I had thought. I'm confused with the original statement being a problem as both vendor and the os both need to support the hardware. If there is a problem with the firmware who will RHEL go to keep its agreements ?
The UEK is more dedicated to following long-term-release kernels. Oracle's re-wrap is known as the "Red Hat Compatible Kernel."
v7-rhck-3.10.0-1160.92.1.0.1
v7-uek-5.4.17-2136.320.7.1
v8-rhck-4.18.0-477.13.1
v8-uek-5.15.0-102.110.5
v9-rhck-5.14.0-284.11.1
v9-uek-5.15.0-102.110.5.1
Kernel version 3.10 has always been stock rhel7's version, but the UEK has jumped through v4 to v5.
Red Hat made a big deal about io_uring availability in v9, but I am guessing that it is available in v8's UEK.
I will say that the Oracle database group's support for v9 is very poor at this point; for some reason, they are holding to v8, and releasing few products for the newer platform.
> Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success.
CentOS was huge towards equipping smaller IT departments, startups and student on the RHEL ways, allowing them to jump on "real RH" when they got bigger. Alma Linux is the same. Rocky Linux does sell support, but even then it's still advertising RHEL.
CentOS was also huge towards allowing a lot of larger companies to just run CentOS in production instead of RHEL and avoid paying anything at all.
However you may feel about Red Hat's actions, I'd trust that folks at Red Hat have done enough legwork to figure out that "CentOS as a loss leader for RHEL" wasn't working out the way people like to imagine it would.
(Note: I am a former Red Hat employee, but I do not have and haven't had specific access to any data estimating what CentOS Linux was expected to add to or subtract from the bottom line. But I feel pretty sure that many deals won and lost have been examined, many customers spoken to, and numbers crunched to inform their actions.)
And I'm not sure I'd agree with their analysis, but they're clearly free to make the decision.
If larger companies can run CentOS in production, they also can run Debian or any other distro without a support contract. They could even use a competing loss leader distro like OpenSuse Leap.
Yes, they could. But they (often) don't. The certification / training ecosystem that exists around RHEL has a lot value, even if a lot of folks like to handwave it away. The engineering that goes into RHEL and the very predictable lifecycle has a lot of value, too. I'm not going to say that Debian or SUSE aren't equally good, engineering-wise, but it seems like a lot of large companies have chosen RHEL clones over Debian. (Not all! I am sure plenty of companies do as you suggest with Debian.)
Don't get me wrong - I think it'd be great if Debian became the standard, assuming that meant that companies helped develop Debian and poured resources into it as a commons. That'd be much better than depending on Red Hat to do all the work and then not paying for it.
Lots of companies do contribute to Debian and this has been happening for a long time. To start with Canonical employs people to contribute back. For a while HPE was donating large amounts of server hardware. Several companies (early HP, ARM etc) contributed lots of work on new ports like arm64, hppa, etc. Almost the entirety of the LTS effort is funded by companies. The current status is summarised on on the wiki:
Many companies just needed some linux. So, choosing between Debian and Centos was pretty much choosing between rpm and apt. Many companies were not choosing between the commercial RHEL and Centos to begin with.
Now they are just fine with just containers.
It used to be for standardization, but I've seen more commercial tools provide Debian / Ubuntu support than Red Hat lately, since the late 2010s. I also think the amount of changes and the issues with licensing here mean that more people might up and convert to Debian than before. But IDK. I also hear that more ML work is done on Debian, and yes - with the containers becoming big - less need to run any particular linux, so I could see swapping out the underlying Linux.
And from a company perspective, Red Hat has already done a big swap out from satallite to Foreman / Puppet to really pushing Ansible. Similarly, they've stopped doing oVirt in favor of cloud style OpenStack, nee OpenShift. Which is great if you're building your own cloud fabric, but not really the VMWare / HyperV competitor oVirt was which is something lots of mid size orgs need. ProxMox still seems to be going.
And for people who aren't paying for support - I imagine they have skilled in house teams that can certainly figure out Debian if they've been orchestrating CENTOS and now Alma say.
> CentOS was huge towards equipping smaller IT departments, startups and student on the RHEL ways, allowing them to jump on "real RH" when they got bigger.
And it turned out near-nobody did so they turned it into stream so you could no longer have "same as RHEL" version.
There's nothing stopping them from using CentOS still? The latest rolling releases are so close to RHEL you'd never notice. Use an older more reliable version locked release that works to your needs and update periodically. these problems are solved for small shops quite easily.
Regardless of your views of cloning a commercial Linux distro like that, alling Rocky Linux and Alma Linux 'dirtbags' misses the point of the entire reason they exist in the first place, RedHat discontinuing CentOS (and drastically shortening the support window on CentOS 8).
Besides it isn't true they don't contribute. As you say, they are filling the gap left by CentOS, and that helps sustaining an ecosystem that benefits RHEL.
It's in one of the comments on the linked article, and was reposted in the top comment in the thread in which you're replying. It seems to be sourced originally from here:
RedHat actually helps Rocky and co by basing RHEL on Centos Stream. Rocky and co can now file bugs on Centos Stream and have it fixed faster for their distribution. Before they could not do that. They had to report further upstream and had to wait until that landed in RHEL. Also RedHat is helped by these fixes. Only winners here.
IIRC they even have a tool to "convert" a RHEL system into Oracle. And it's not just RHEL, they shamelessly distribute AWX (upstream for Ansible Tower, a product 100% made by RH from scratch) under a different name without contributing anything back. Oracle is truly a parasite of the open source ecosystem.
The only outcome I see for these "business models" at Oracle, Rocky, Alma, etc. is increasingly less availability of software for us regular users. Say what you might about RH but you can't argue that they put out massive amounts of open source code out there for all to use. Or they did anyway.
When Red Hat didn't yet provide free download and free hobbyist licensing for their SO CentOS is what allowed me to learn the RHEL way and learn enough to pay 560 euro to get RHCSA certified.
I can see their problem with Oracle, but Rocky linux is probably bringing them business.
If my job wouldn't mandate a specific distro, I would use Rocky Linux where the management doesn't want to pay for support, and RHEL whenever possible.
Yeah... had it not been for CentOS, I would've never touched anything in the RHEL-side of things after I discovered Ubuntu in the 10/12 era.
Because CentOS existed, I made sure most of my open source work would run just as well on all RHEL derivatives as it does on Debian.
If Rocky didn't exist, I would quickly drop all my RHEL support because operating thousands of test machines and containers based on UBI and having to keep up with their licensing game would cost too much of my time.
Rocky and Alma are the only reason devs like me still build anything for RHEL.
I'd have to check if it is still the case but RHEL has provided free developer licenses for RHEL for years (decades?).
EDIT: checked and it still exist and allow usage of up to 16 physical or virtual nodes for development " to develop software (including open source software), perform prototyping or quality assurance testing and/or for demonstration purposes.
> The Individual Developer
Subscriptions allow you (as an individual, natural person) to use certain Red Hat Subscription Services in connection with Red Hat
Software for Individual Development Use and for Individual Production Use subject to these Program Terms at no cost.
> “Individual Production Use” means any use other than for Individual Development Use including, but not limited to, using the
Software (a) in a production environment, (b) with live data and/or applications and/or (c) for backup instances
Red Hat also have a no-cost Developer Subscription for Teams agreement for organizations.
The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds (for dozens of projects) means I won't do it.
That's why I stuck with Rocky Linux instead of just dropping all RHEL support entirely.
And there are _a lot_ of test runs where I have more than 20-30 test containers running simultaneously with Rocky Linux 8 and 9.
Do I have to write new software that limits my test infrastructure to only run 16 tests at a time or something idiotic like that? Do I have to even wonder about that using Debian, Arch, heck even Amazon Linux? No.
FYI containers aren't their own entity for subscription management purposes. A subscribed host can run as many containers as it wants, the host's subscriptions work inside the containers.
(That said I agree that dealing with subscription-manager at all is a lot more annoying than ... not having to do so with RHEL derivatives!)
I know there move to CentOS Stream cost them my business, Since that announcement 2 years ago I have replaced all Licensed RHEL servers with Ubuntu Servers...
Which is an odd choice when comparing RH and Canonical. The former has been almost religious about living to the open source ideals, going so far as open sourcing products they purchase, and making sure new products they create have opensource upstreams. I don't think the same can be said of Canonical which seems at every turn to in need of $ so they try desperate ploys to monetize new projects they work on by developing them in house and dropping releases, or trying to lock up markets and charge for features not available in the open source version.
So, while they definitely aren't ideal, its hard to point to another company that does more across as much of the opensource ecosystem. Maybe google these days? But one needs only look at some of the google projects governance model to see the difference between RH and Google.
> The former has been almost religious about living to the open source ideals, going so far as open sourcing products they purchase, and making sure new products they create have opensource upstreams.
We are having this conversation on an article about them doing their best to avoid sharing their source code in order to kill their downstreams.
I don't really agree. RHEL is nothing special. Important for Enterprise and thus free availability is handy for people having an interest in becoming a sysadmin to learn it. Dogfooding work stuff is the only reason I'd consider using it or its derivatives at home. But I don't care even about that and my stuff all runs BSD :P
But other distros are much better IMO.
There's good reasons that a totally free distro like Debian is forked so much. It's just a really solid base. Software doesn't need to have a business model to be great.
I'd be a lot sadder to see Debian disappear than RHEL and its derivatives.
There is no single criterion by which you can decide which distro is better.
All I know is anecdotes. RHEL 7 and Ubuntu 14.04 came out around the same time. Around May, upstream QEMU started getting bug reports from Canonical developers that you couldn't reset a virtual machine that had been created in 12.04 and migrated to 14.04 due to some firmware incompatibility.
In RHEL we had started testing cross-version migration 6 months in advance.
There's a huge difference between Rocky/Alma, and Oracle.
Oracle actually tries to steal RHEL business. They offer support, which I think is ludicrous when they don't even build the product.
Alma/Rocky aren't to my knowledge offering any support (and if they plan to, they shouldn't). Are customers cross-shopping RHEL with Alma? You either want support, and buy RHEL, or you don't, and you use something else (Alma/Rocky, or Debian/Ubuntu etc..)
Rocky can offer support on helping you install it. But they can't offer real support. They can't fix bugs or do any real work on RHEL beyond requesting that Red Hat accept a fix. If Red Hat declines, Rocky can't even ship their own fix.
Doesn't Rocky offer their own repositories, where if they had an upstream fix that was important enough, they could just include it in their own repositories?
Yeah I really think people are way out over their skis if they think that Red Hat/IBM doesn't have at least a somewhat justifiable case to make here. You can still disagree, but at least you need to admit that you can understand why they would be pissed about something like Rocky. They do offer downloads of RHEL for free (or is that gone too?) for anybody not using it commercially, this isn't some poor student cloning RHEL because they couldn't afford it or anything like that.
>The comments there are insightful and actually make me think this is the right move
They are not. Maybe this is how the YC/VC crowd sees everything. Dollar went in, two dollars come out. Two points:
1) RHEL is not an island. It uses (and contributes) upstream.
2) They undercut the spirit, if not the letter, of GPL by forbidding customers from releasing the sources. Don't want derivatives ? Don't use copyleft free software. Can't have your cake and use it too.
RHEL became the enterprise Linux distribution because it was the one used and supported by Oracle, back then, when many companies still used Oracle as their database.
I am talking about 15 years ago.
Even nowadays at work, we all use Ubuntu in our workstations, but the servers run CentOS (another repackaging of RH).
Without the support of Oracle, we all would be using SUSE in our servers, instead of a Red Hat based distro.
I don’t understand what game IBM is playing with Red Hat. I was under the impression they were profitable prior to the acquisition so I’m not sure why they’re squeezing so hard and ruining the great brand and good will Red Hat had built up.
IBM is slowly ruining everything they produce. Their systems are incredibly secure because it's extremely difficult to even run them normally as an operator, much less hack in. The byzantine/circular documentation and downloads pages on their site are woefully inadequate in enabling developers. Web searches reveal little information if you have a problem, as not many people run these systems. You generally have to pay stunning amounts to 3rd party professionals to manage your platform for even what should be relatively simple things like patching (PTFs), OS updates, and language upgrades. They will balk if you tell them they have bugs in their systems unless you can produce code yourself pinpointing the problem. They aren't interested in working with schools/universities to train young people to create fresh workers knowledgeable on their systems. Seems like they are milking the company and coasting until it expires.
When I think of ibm, I think of how my wife had to attend special training on how to get paid at her government job due to how unreliable and chaotic the phoenix payroll system is. How it’s sometimes like a part time job sorting through it, and how they are all given time each month as needed to spend days on the phone trying to get somebody to manually fix issues that come up
> By July 2018, Phoenix has caused pay problems to close to 80 percent of the federal government's 290,000 public servants through underpayments, over-payments, and non-payments.
> Instead of saving $70 million a year as planned, the report said that the cost to taxpayers to fix Phoenix's problems could reach a total of $2.2 billion by 2023
I heard from a former employee at IBM that management has been offended the media used FAANG to describe big tech, because they are delusional and still think they are relevant enough to be big tech…
The slightly, but not too much, sad part is that if they had played their cards right, IBM could be a lot more relevant today than it is. Some aspects of their tech still are quite impressive and unmatched by offerings in the open systems space.
But the profit margins on their mainframe business are (last I heard anything about it) really juicy, and in today's business world, that appears to incentivize IBM management to go for the low hanging fruit of milking that while effectively cannibalizing their own market in the long run.
IBM has known how to play vendor lock-in and death by a thousand related products since before computers could fetch instructions from memory, when most of the world still thought just shipping what their customers need was where it’s at. (Evidently—if unfortunately for my worldview—that doesn’t contradict there being a lot of very good engineers there.) They may be dying a slow death, I don’t know for sure but I can imagine that, but just making their stuff worse for business reasons is not by itself a symptom of that—it’s simply part of their normal lifecycle.
IBM is stuck in a cycle of constant re-invention, because they somehow manage to always re-invent themselves in ways that are even worse and more complicated for customers, which they try to fix by re-inventing themselves again. Even if they initially planned on leaving Red Hat alone, every re-invention is a chance for some executive to make the decision to squeeze a little tighter on existing customers. So the question shouldn't be "what game is IBM playing with Red Hat", but "how long until nothing usable is left". I'd say maybe 20 more re-inventions, or 1-2 years.
I'd argue that IBM's contributions in that timeframe were more about about validating it from a large business perspective than about technical contributions (that tended to focus on large system performance which wasn't actually that important for Linux taking off).
Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical.
Likewise, a lot of Linux's development inertia and cultural acceptance came from being a cheap and consistent alternative to screwing around with the profusion of expensive and mutually incompatible proprietary Unixes in the Server and (as clusters co-evolved) HPC market.
On the broader issue, the tension here is that IBM thinks the value proposition of RHEL is "Supported" and (I suspect) almost everyone else regards the value proposition of RHEL as "standard base." I think it's more likely that the "standard base" for srs bsns Linux in the markets where RHEL is the standard would rebase than IBM having any success trying to squeeze customers, and if that happens the value of "Owning RHEL" suddenly shrinks dramatically. Honestly, all it would take is the RHEL-likes like Alma and Rocky to agree on a coordination mechanism that isn't matching RHEL - could be through a major public interest like CERN, could be through an existing commercial interest like coordinating with Oracle (ew), could be via one of the several entities that does commercial support for RHEL-likes ... there are options.
Oracle being a gigantic litigious parasite on society is a broader issue, and I understand regarding commercial RHEL-likes as more of a problem, but even they have been funding a lot of backport-to-LTS type work.
>Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical.
It was certainly needed over time but capabilities from things like RCU out of Sequent weren't that important in the 2000 timeframe. And a lot of IBM's contributions didn't come online until the v4 kernel.
None of this is to minimize IBM's contributions to Linux over time but I'd argue pretty strongly that IBM's endorsement of Linux for enterprises in January 2000 is what really moved the needle in the short run.
Here's what one of the people most directly involved told me a few years ago:
"By the late 90s, it was clear that Linux was becoming more and more important. And we formed a major task force to see to what extent IBM should embrace Linux and this happened in 1999. And the task force came back and said, we absolutely should embrace Linux, that it was going to be an incredibly important part of computing, that we should embrace Linux across all of IBM's offerings. And that IBM should become a major supporter of Linux.
"And I still remember very well in December of ‘99, I called Sam Palmisano, the head of IBM Systems Group. And I said, Sam, the task force recommends that we should embrace Linux. And Sam said, okay, Irving, we will do that. But you have to now come over and run an IBM Linux initiative. And I said to Sam, okay, we were pretty much done with our internet strategy. So I was no longer needed to run the Internet division And I said to Sam, when do you want to announce it? And Sam said, how about now? And I said Sam. It's the Christmas holidays. Maybe we should wait until the new year. And in the second week of January of 2000, we made a major announcement saying that IBM would embrace Linux across all of these offerings. And in fact, later that month in January of 2000, I gave a keynote at LinuxWorld, which was taking place in the Javits Center in New York City, about IBM’s Linux initiative.
I was mixing up where the big multiprocessor changes that went into the 2.5 series in that 2000-2005 era came from.
I was thinking of the the basic kernel preemption stuff and sched_setaffinity syscall + userspace plumbing like taskset that is _extremely_ consequential on little multicore/SMT machines, but the prominent name on a lot of that was Robert Love and he was at MontaVista at the time.
The Dynix parts that arrived via IBM were, as you say, mostly NUMA and RCU stuff based on Paul McKenney's work, which also went in in the same major overhaul during the 2.5 series but weren't quite so immediately consequential to smaller systems.
I hadn't heard that anecdote, but that is a neat tale of IBM using their gravitas at the time to legitimize Linux.
SGI also did a lot of scalability work in that time frame, as part of their migration from MIPS+Irix to Itanium+Linux. In the end they got Linux working on IIRC up to 4096 processors.
Yes, certifying DB2 for Linux (back in 1998, https://slashdot.org/index2.pl?fhfilter=db2+linux, scroll to bottom) was an absolutely earth-shattering event that announced that Linux had arrived. I think that event (and of course Oracle and Sybase a few months prior) really sounded the death knell for big-iron UNIX.
But in 1999, IBM ported Linux to run on System 390 (https://slashdot.org/index2.pl?fhfilter=mainframe+linux) and I remember there was a story that some IBM scientist booted more than 30,000 Linux instances on a mainframe on his lunch break. This research led to the big SUSE partnership, as well as open-sourcing other enterprise-y software like JFS and putting a big devteam to make the kernel ready for real SMP (Linux didn't have efficient+mature SMP even into the early aughts, although a few companies had built some massive SMP boxes.)
>Linux didn't have efficient+mature SMP even into the early aughts, although a few companies had built some massive SMP boxes
Including IBM. (Forget when they did their big stackable X-series server.) A lot of the tech eventually became applicable to even super-mainstream dual-socket servers but I wonder how much money was largely wasted on building and trying to sell larger scale-up boxes.
But, yeah, IBM was one of the big investors in OSDL (and their own Linux Technology Center) which had a lot of scale-up focus which made a lot of the legal claims of another 3-letter company pretty much misaligned with the timeline.
HN loves to hate Oracle, IBM, SAP, Adobe and friends, without getting the point that many startups that go through HN programs never achieve half of what they produce.
What do startups have to do with IBMs business direction and processes? How does this relate to my point? Not every startup being successful somehow means that I shouldn't comment on IBMs recent business decisions?
We seem to even be hating on RedHat now. (I was bummed about the Centos thing too). People on this thread are acting like Redhat doesn't even release any free software.
Well, they used to. Now there's software to be had in exchange for money. Mostly written by people outside of IBM. And the source access they used to provide is disappearing one move at a time. Which leaves a void and an opportunity, but also a lot of annoyance at IBM.
Except roll the clock back a bit and your would have been talking about Lotus, Machine Learning, and Unix/PowerPC.
And we see what IBM has done with leadership in those areas, as well as a long line of other areas where they somehow managed to turn themselves into a 3rd rate competitor despite being in the right place at the right time.
So, you have to ask yourself, for example how its possible that people are falling over themselves to build a RISCv ecosystem from the ground up, when openpower has been around for a decade now, and IBMs been looking for partners there since the original AIM alliance.
Looking at their yearly revenue, doing quite alright.
The RISCv ecosystem is a pipe dream that people will finally get it when they start dealing with major boards relying on extensions, or board designs that aren't as open as the CPU itself.
There have yet to evolve practical applications for current quantum computers.
No one cares about Java anymore, beyond legacy support. They bought RedHat with their massive reserve of capital from more successful times.
IBM is still in business because they can build on massive reserves from the time where they literally created the market for commercial computing. That was indeed influential. Now they slowly burn those reserves and have a crackhead sales team that knows how to sell mainframes and subsequently suck those customers dry.
The new generation of graduates has no idea what IBM does, let alone what a mainframe is. New talent for maintaining Cobol codebases is so rare to come by, that they pay the Linux foundation to offer free courses on Cobol.
IBM's success is a relict of the past. It will die when the last guy that knows how to maintain Cobol dies. Good riddance.
How much of that is lingering brand value, though? That and simple ties into existing and old industries.
You are also comparing to startups? Which... yes, most things die. Sometimes, it is the old things that die. Often taking a lot of other younger things with them.
I think you are being very pessimistic. All of their acquisitions are used to fund reinventions but due to their existing mainframe and other support contracts it makes a moat that people have a hard time crossing. I could see Oracle being merged or bought by IBM.
I definitely am pessimistic, but that is probably due to my time working for them :) I can't remember any acquisition during my time there that didn't get significantly worse. Red Hat was the one hold-out, but this thread is example enough for me to know that nothing has changed since.
> I don’t understand what game IBM is playing with Red Hat.
And this is yet another part of the reason why I don't understand the big push for RedHat specific tooling. Podman comes up a lot. But, just like with everything RHEL it seems as though RedHat / IBM wants to be the Apple of Linux. I'm not a fan of that. I also don't believe IBM is a good steward of OSS based on how I've seen them try to sell it in the enterprise.
> I don't understand the big push for RedHat specific tooling
I'd wager it is driven by RH simply being "least worst" of the options which can be relied on to stick around long enough for enterprise users.
Canonical are doing their best to screw the pooch with snap and similar nonsense, leaving the only other option being cobbling together a collection of tools from fly-by-night small projects - which might go full unicorn-wannabe and adopt an open-core SaaS model any second.
Offhand I don't know enterprise level support for any of them, but I expect 'support' solutions are offered for all of them, even if not first party as an outside source.
SUSE is the other one I thought about mentioning - but I have only really seen it used with SAP.
A big part of the problem is ISVs refusing to test their software on more than just RH - which is not in itself a totally unreasonable position - but it does now give IBM too much clout.
I guess I should have been more clear. What I meant was that there seem to be a lot of die hard RedHat fans that hock the RedHat ecosystem for no apparent gain. I failed to make my point clearly, however. Podman is one of those tools that seem to follow up that narrative. RedHat could invest in the container ecosystem to make things better. Instead they strive to compete and hang their hat on very specific arguments against products that were (and still are in many cases) more complete.
> I was under the impression they were profitable prior to the acquisition so I’m not sure why they’re squeezing so hard and ruining the great brand and good will Red Hat had built up.
Some growth metric that can't be realized quick enough through innovation (new products or services), so the only recourse is to cut costs or get more revenue from existing products without improving them.
They bought it for Notes, Notes was good before IBM purchased it, rel 4 was pretty good. New Releases it got worse and worse. They finally dumped it I think two years ago and sold it to another company.
I wish this encourages companies to look for more alternatives to RHEL and its clones. There are certainly cases where the stability of RHEL makes sense. But too often teams use them when they need latest versions of software, resulting in pointless packaging work.
The worst part about the packaging work is, the tools used to create RPM packages is showing its age. RPM macros, the language for describing packages, is based on text substitution which makes it tricky to write. [1] RPM builds don't do build-time sandboxing, so a package won't build consistently across machines without extreme care taken in both the package descriptions and the build environment. Even if the package itself builds and runs on the same machine, it isn't guaranteed to run on other machines too because it lacks a way to ensure reproducibility.
[1]: For example, commenting out a macro might not work as expected because the expanded text might include a newline.
> I wish this encourages companies to look for more alternatives to RHEL and its clones.
The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled.
Setting up SELinux in any other distro is, in my experience, an uphill battle. You need to become an SELinux expert to do so.
> The worst part about the packaging work is, the tools used to create RPM packages is showing its age.
Most people don't really create RPM packages, they just install them. And in this area dnf[1] is cutting edge: file-level dependency solver, delta-package downloading, parallel downloading, ...
Fedora is to RHEL what Debian Sid is to Debian stable.
Yes, it's not that simple, and there are some customization done. But Fedora is the playground for the next RHEL. I woudn't consider Fedora "an alternative" according to what the top-poster was describing.
I've heard that a lot but I don't think this is an adequate comparison (yes even with the disclaimer in the next paragraph). First of all because of the relative stability of Fedora, I've been updating my OS since Fedora 29 and every major upgrade is mostly boring. Second, there are some decisions made in Fedora that wouldn't make sense if it was merely a test bed, removing the whole Java stack comes to mind, or more recently the libreoffice debacle.
This (SELinux) is why I started using RH-family OSs more and more, and one of a few reasons why I stick with it, even though Debian's minimalism is incredibly nice. I have a book (as yet unopened) on my desk about SELinux administration, but it's huge and CentOS, Fedora, RHEL, et al. Just Work (okay, with the occasional small tweak to policies or booleans).
Same here. I never want to go back to another distribution where all of the services on a system, including containers, are not segregated from one another by SELinux.
I was specifically talking about people using RHEL when they need latest versions of software. For that use case, RHEL is a poor choice. You absolutely need to create custom packages, because there are no preexisting packages.
To reiterate:
> There are certainly cases where the stability of RHEL makes sense. But too often teams use them when they need latest versions of software, resulting in pointless packaging work.
>The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled.
Why is this a dealbreaker ? Ubuntu has apparmor which is similar. Maybe selinux is stricter/granular etc., but that's not a business level differentiator. Your company won't fail or succeed because of selinux.
RHEL gives really good audit. They're very good with security updates, they support things for a very long time. And if you wander into Federal Government land, it's hard to use anything else.
I just use Fedora. When I used Red Hat briefly, I didn't notice any major differences between the two except one is the "base" of Red Hat. I can get pretty much whatever I need through dnf or flatpak. I get that Red Hat has support, but otherwise for regular consumers like me I am not sure why I would go for a Red Hat clone when Fedora exists.
Red Hat is valuable for situations where you want to leave a computer running for 10+ years and not have to worry about updates breaking anything. If you are fine with doing a full OS update every 6 months and always want the latest and greatest features, you're not in the target market.
The problem is that RHEL is too expensive for people who don't need support.
IBM is getting greedy and screwing up its pipeline.
Our dedicated servers are about $100/month for pretty serious hardware (2 x 8-core CPUs, 64 GB RAM, 2 x 8TB HDD, 30TB transfer). Paying $349/year is a significant percentage of that. It is worse for smaller servers, and ludicrous for small virtual machines in the cloud.
I would not mind throwing them a bone to have e.g. security updates at some reasonable cost. Their official repositories don't have enough packages, so I end up having to use 3rd-party repos for normal things, e.g. Postgres. Having a more full-featured repo of up-to-date software would be useful to me.
I have been running CentOS 7, but when that is no longer supported, I will switch to something else like Ubuntu or Debian, whatever our hosting providers support. I am already using Debian or distroless for containers.
And then RHEL will be completely irrelevant to me. Good job, IBM.
Thats not true with Ubuntu Pro, which includes support for way more packages than RHEL, 10 thousand to be exact, and is much cheaper with more features like included kernel Livepatching.
I was referring exactly to Ubuntu Pro. They can support more packages for cheaper exactly because Red Hat won't ever have the same YOLO approach to support that Canonical has.
1) Canonical does not have enough testers. As a developer I have seen what kind of bugs are reported on Ubuntu, and some of them denote a serious lack of QA. There are packages in Ubuntu that are almost certainly shipped untested.
2) Canonical does not have enough developers, unless they found a magic recipe by which their relatively few employees know how to fix issues in all these packages while not contributing upstream and while also maintaining mir/upstart/snap whatever their latest fad is. So if you have say a performance regression or a kernel crash or a miscompilation they might just relay that to upstream developers and hope they fix it.
3) Regarding package count, PPAs are basically the same as EPEL or Copr, and are unsupported.
I'm not saying they are bad at support. I'm saying that they are betting on their customer not actually asking them to support some of the things they ship. Red Hat just says "no thanks, feel free to use EPEL or pip but we don't want to touch it".
So here is an example. Universe has all system and user-mode emulators for QEMU, it's 20-odd packages. To what extent will Canonical fix bugs in there, even for very old emulated machines? You don't know, but you know that they have no contributions upstream and it's one of the largest packages they have, so your chances aren't great.
Red Hat only has the KVM-enabled binary because, as the #2 contributor to the upstream project, they know exactly what can and cannot be supported. It also has dozens people of employed just to test it. If you have an issue it may languish because no one is perfect, but your prior is a little better.
RHELs model is to support such ancient versions of software that they don't have to support many pieces of software, because the features most people would rely on aren't in 3, 5 or 10 year old software. If it wasn't effectively required (until recently) for most US government use, I would imagine they would have a substantially smaller customer base.
This is not entirely true; some packages have been removed from RHEL7 to 8 to 9, because the interpretation of "if we ship it we support it" has become stricter. RHEL9 is as new or sometimes newer than Debian 11 (bullseye).
I am so pissed by this move, it is totally against the spirit of free software and GPL. Using additional contracts to subvert the free software licenses. You get to see the software, but you can't share it further. RedHat would not be here if someone behaved like this 25+ years ago.
I would prefer a variant of GPL which strictly forbids this (imo it should already be forbidden, these are clearly additional restrictions). Let's put "GPL v2 or later" to good use...
> Using additional contracts to subvert the free software licenses. You get to see the software, but you can't share it further.
This wouldn't be the first time. The very origin of the DD-WRT router distro was a hard fork of SveaSoft's "if you share this, we cut off your access to updates" license.
I find it hard to believe RHEL will get away with this. I hope the Linux Foundation weighs in, but it seems to have been bought by IBM, Microsoft, Oracle and many other large corps.
All the drama in Linux with Wayland, RHEL sponsored init, snap/flatpak and now IBM/RHEL has been causing me to seriously evaluate the BSDs. I have been doing that for a couple of years.
I would be fully on OpenBSD now, but the hardware I have is one of those with 2 videos, integrated and Nvidia. And that system does NOT allow me to disable the Nvidia Chip.
When using Nvidia, that chip is correctly ignored by OpenBSD, but it gets so hot I can almost fry an egg on it. I have some mitigations in place, but it still gets rather hot, CPU and disk stays normal.
The same is true with NetBSD, I have not tried FreeBSD yet.
This RHEL thing may be the last straw, I may bite the bullet and see if the heat causes failures and if so evaluate this:
The BSD with the most support for Nvidia is the one you never tried. Arguably it's the only BSD that is best suited for a desktop user. Also has better wifi support as well.
We all want to love BSD, and it does get love in proprietary spaces like Netflix, Playstation and Apple, but those companies have the resources to actually create the pieces they need and do not have an obligation to share it. (E.g. MacOS is literally a certified UNIX, but the GUI layers are private.)
For non-corporate users, in some ways it is like what Debian faced when they realized they really did need to start including wifi firmware into the install media, because people were like, why doesn't this connect to the router? What's wrong with this? This is actually something that I've run into personally.
At the end of the day though, BSD isn't realistic as a desktop. OpenBSD disables stuff for security reasons which harms performance, so it wouldn't be first choice as a desktop. NetBSD is what Open forked off of many years ago and I recall NetBSD as one of those "let's try to make it install on anything" show and tell pieces, but not something you'd really be using for anything. FreeBSD was the only one that was reasonably usable. Dragonfly is another fork (this time off FreeBSD).
All of them have to port the Linux video drivers, Linux desktops, etc.
It's actually somewhat unusual that Linux is the one that won the battle for resources, because corporations hate sharing and being open.
"I find it hard to believe RHEL will get away with this. I hope the Linux Foundation weighs in"
I'm curious what role you think the LF plays here, or what they'd do to prevent Red Hat from "getting away" with doing something that is entirely within Red Hat's rights to do.
The Linux Foundation is a trade organization. It was created from the merger of the Open Source Development Labs (OSDL) and Free Standards Group. The OSDL was funded by several large corporations - including IBM, Intel, HP, Fujitsu and others.
LF wasn't "bought" by IBM and others. It was literally created by them. Granted, Microsoft is a newcomer (relatively speaking). But the LF is and always has been a trade organization that supports the interest of companies that want to do business with open source.
What drama with Wayland or flatpak?
Its what the community has decided, every distro except Ubuntu has adopted flatpak.
And Wayland is the default for both KDE and Gnome.
I've been using Red Hat and Fedora since the early RH4 days when the video driver only supported monochrome for my GPU. I'm now going to start switching to something not controlled by a corporation. Yes, I'm not happy about it but it's necessary. The days of being naive about Linux are over.
I still consider Fedora one of the best distros out there (bleeding edge and polished as much as possible) and I prefer to use the same-ish distro on my personal computers and on the servers but this is another nail in the RH-based distro coffin for me.
Until today I preferred to use Fedora on desktops and RHEL/Rocky/CentOS on servers, so I'm already used to different paces of development.
But it seems Debian unstable on desktops and Debian 12 stable on servers might work just fine. Truth be told, I only need a 5.x/6.x kernel with cgroups/namespaces/ebpf on my servers and flatpak on the desktops and I'm fine.
Fedora is sponsored by Red Hat and many of its developers are employed by Red Hat. Much of the work in Fedora is done by Red Hat.
Red Hat did not fire the FPL. They laid off the Fedora Program Manager, which is a different role entirely. I would still say that was a lousy decision, but the FPL is a very different role that goes back a very long time and AFAIK remains filled by Matthew Miller.
I've seen the two roles conflated here and there so I figured it was worth correcting here so it doesn't continue to spread.
A few years ago the figure was "several hundred" but the exact number is fluid because some people (like Matthew) are paid to work on Fedora full time, while others work on Fedora as part of their job but not their whole job.
It's also further confused by the fact that some Red Hatters contribute to Fedora but not as part of their day job.
I think it'd be fair to say more than 60% of the work that goes into Fedora's official releases is paid for by Red Hat. Maybe more. If you factor in spins and such, it might be less than 60%.
NASA recently made a deal with Rocky Linux, which is literally just RHEL with branding replaced afaik. Probably pissed IBM real bad since they're usually the government's darling for tech contracts
Yeah this decision had to have been in discussion for 6 months or more, maybe even 2 years back to the CentOS Stream decision. It didn't happen because a few days ago NASA bought support for 3 Rocky licenses
I believe NASA does use RHEL, I remember a story last year where they were moving some systems from SUSE to RHEL.
My guess is that IBM was so difficult to deal with that they decided to move away from RHEL wherever they could. Perhaps getting the actual support they purchased was too much of a challenge.
If IBM is pissed, they should take a good hard look in the mirror before they malign other distributions.
NASA's IT used to be split into the field centers and a central core IT organization. The field centers managed their own stuff, but anything agency-wide was handled by the core IT organization. Central IT also usually won out when there was a conflict.
When NASA combined their disparate field center mail systems into one (OneNASA
and later NOMAD) massive mail system in 2006-2008 they deployed everything that wasn't the squishy Exchange underbelly on SuSE Enterprise 10.
The field centers were very invested in RHEL. Mostly for scientific software and Oracle.
JPL has traditionally been separate from the rest of NASA and works with CalTech for their infrastructure.
The US Government has been sour on large contractors for almost 10 years now, but the quandary is how to prevent the small contractors they support from becoming the dinosaurs they hate? For a while OSC O/ATK was a darling, but NG gobbled them up. Same thing with Millennial (now Boeing). Space-X is probably too big for acquisition now, so they are on course to become just another dinosaur.
Looks like this will be the end of the road for RHEL based distros for me... I love using AlmaLinux, always super stable and everything just works (at least for what I use it). I guess the next best option will be SUSE?
I suppose SUSE makes a lot of sense. Until some time ago SUSE Linux Enterprise Server and openSUSE were related, but not exactly the same. That changed with Leap 15.3, since which openSUSE is now based on the same packages as SLE.
I've been personally using Tumbleweed on my personal devices and it's been great. I've not had a single issue with stability and almost always gotten extremely recent versions of software.
I've also had great experiences with Tumbleweed for the most part, but be careful using ZFS, as it frequently breaks with updates. Probably not something most people use, but it does force me to run Leap on my home server.
My main issue with SUSE is 3rd party support.
For example docker doesn't have an official repo for openSUSE/SUSE, so you are stuck with their outdated version or Podman, which is also outdated.
Isn't 'everything just works' because it is a rebuild of RHEL sources? I don't know how else it claims to have 1:1 ABI compatibility witb RHEL otherwise?
I've used Debian before but always had a disdain for how their packaging works. Dpkg seems completely over engineered (why are there more package states than just installed/not installed?) and the way they package things is just annoying. At random times an install or upgrade asks you questions in a wizard style and they always mess around with the configuration files and directories to the point where I don't even know what's the right way to do it, forcing you to search for the Debian specific way of doing things (which usually ends up with a stackoverflow answer) instead of just being able to use the upstream docs.
Just as a word of warning (because I can't tell if this is satire): NixOS does not provide the same experience as a typical Red Hat or Debian-derived distro. It's a vastly different paradigm where your system (including its configuration, packages, etc.) consists (almost) entirely of the output of a program you write in a functional language.
I think it's phenomenal and worth a try (or multiple; I didn't get it the first or second time but now I wouldn't want to go back to something else). But if you go in expecting a traditional Linux distro, you will be disappointed/confused.
RHEL X.Y isn't a simple snapshot of CentOS Stream X at a specific point. It is a fork of CentOS Stream, with cherry-picks and so on. The specific details of what patches made it into RHEL and when and how to create reproducible builds are now only being provided to customers.
In the past, customers have been able to redistribute the RHEL repos freely. I assume that will remain the case as long as CentOS Stream is open source.
Edit: Actually, it wouldn't surprise me if IBM put some content in the RHEL repo that is under restrictive licenses that couldn't be redistributed just to complicate things, but all the important parts will remain open source, due to close ties to CentOS Stream and Fedora. Rocky/Alma already have to replace trademarks, and this wouldn't be much different, but they would have to obtain access to the repos as customers themselves, or have another customer strip the bad stuff out before throwing it over the fence. We'll have to see how hostile they want to be about it.
> In the past, customers have been able to redistribute the RHEL repos freely. I assume that will remain the case as long as CentOS Stream is open source.
There's a duality here. Yes, by the nature of the distribution, GPL, and licensing general, Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing. IIRC, the Enterprise Agreement makes it pretty clear the services and offerings provided by the subscription are for the customer and the customer only. Going outside of that violates the subscription's terms, not the softwares' licenses, therefore allowing Red Hat to end business with said customer.
For those concerned about the final year of CentOS 7: it will not be touched. It will continue to see source exports to git.centos.org as there is no parallel CentOS Stream 7 platform. Also, git.centos.org is not EOL either because it is used by other groups than Red Hat, like CentOS Special Interest Groups.
> Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing.
IANAL, but not so sure about that. From GPLv3:
> You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
Yeah this is really pushing a gray area. Looking at it one way Red Hat is not obligated to do business with anyone, and if they stop doing business with a customer that customer still has all the rights granted to them by licenses of software they have already received, so in that sense Red Hat hasn't restricted the customer's rights in that software.
However, on the other hand refusing to do business with someone in retaliation for exercising the rights granted by the licenses smells a lot like a restriction.
> Is applying a consequence as a result of an action the same as restricting that action?
I mean, I don't disagree this needs to be tested in court if it hasn't, but what alternative ways of restriction do you think this is referring to? Do you expect it to only apply to the distributor physically restraining the licensee when attempting to redistribute it? Even the examples given in the license such as imposing fees are applying a consequence.
I don't think it is a further restriction on the rights you have. Those rights extend to the code you have, they are only terminating the business relationship going forward.
Not a lawyer, so maybe someone else more knowledgeable about the space will expand on this.
I imagine that RH/IBM has had lawyers look into this before the policy was announced.
> Actually, it wouldn't surprise me if IBM put some content in the RHEL repo that is under restrictive licenses that couldn't be redistributed just to complicate things, but all the important parts will remain open source, due to close ties to CentOS Stream and Fedora.
I'm not so sure. They're obligated to release the GPL'd code, which of course covers Linux itself, but they're under no such obligation for the non-GPL'd software they include.
They could license their RHEL-specific backport patches for non-GPL'd software such that they could not be redistributed, and if that code gets merged into CentOS Stream it could just be dual licensed from that port forward (so Stream could stay open but RHEL would be locked down).
CentOS 7 is supported and will be EOL at the same time as RHEL 7.
Stream does have major versions so you can continue to use CentOS Stream 8 and get backports. You only lose anything if you're tied to some minor version of EL for some reason.
It only takes a single customer with a RHEL subscription to republish the source, so this is really just a middle finger out of spite to Centos competitors.
>It only takes a single customer with a RHEL subscription to republish the source, so this is really just a middle finger out of spite to Centos competitors.
That is a violation of their terms of service and will result in a termination of your subscription unless I'm misreading it (section d):
Unauthorized Use of Subscription Services. Any unauthorized use of the Subscription Services is a material breach of the Agreement.
Unauthorized use of the Subscription Services includes: (a) only purchasing or renewing Subscription Services based on some of the total
number of Units, (b) splitting or applying one Software Subscription to two or more Units, (c) providing Subscription Services (in whole or
in part) to third parties, (d) using Subscription Services in connection with any redistribution of Software or (e) using Subscription Services
to support or maintain any non-Red Hat Software products without purchasing Subscription Services for each such instance (collectively,
“Unauthorized Subscription Services Uses”).
RHEL is obliged to provide source code for their GPL packages.
You ask for source code, you'll get it.
You distribute the source code, RH will terminate the contract with you because they don't want to see you as a customer anymore.
They're free to do business with whoever they want, peeking people who will not distribute RH sources.
Every party is in their right here. That's my understanding.
Red Hat did that for many years. They maintain extended support branches for RHEL which provide fixes for very old software. Those fixes AFAIK were never "leaked" despite the fact that every customer could receive it. If it was as simple as crowd-funding single subscription and then publish all the sources, someone would do it and we would have CentOS Extended LTS.
It does not. As the other comment in this thread notes there are two agreements in play here: the open source license agreements and Red Hat's Enterprise Agreement. Under no circumstances can Red Hat prevent an entity from sharing their FOSS software, however they can absolutely view that action as a violation of the EA Contract, and terminate the subscription. This doesn't undo the action, but prevents further access to updates and sources.
My Assumption would be Section 1.4 over rides in the case of Source Code which is governed by GPL and implicitly allows redistribution, that is the entire purpose of CopyLeft
So the prohibition on "redistribution" in this context would be on the compiled binaries. i.e you could not pay for a subscription and then mirror the yum repos publicly.
You're conflating your legal right to redistribute the software (they can't sue you) to your contractual right to redistribute (them terminating your support contract).
They cannot sue you for redistributing the software, or claim damages because you did so. They can ABSOLUTELY tell you that your right to the subscription is terminated if you do so.
I am not conflating anything, I am reading section 1.4 of the agreement which specifically 1.4 that says
> Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license
So if the preceding section 1.2(F) and 1.2(G) do prohibit redistribution of SOURCE CODE, then it is in fact limiting your rights under to software code under the terms of an open source license.
1.2(F) and 1.2(G) would limit your right to distribute "software" generally defined a complied code, but not source code.
Yep you can redistribute it. But they can terminate your subscription so they don't have to give you the next round of updates. Basically a new "customer" would have to pop up and leak the sources each time there is an update to a package for a bug-for-bug RHEL clone to exist
I wonder if you're RedHat Subscriber and Customer and have access to the source what is the license ?
In general though it is clear what RedHat does not seems to want to play Open Source game any more, at least when it comes to RHEL.
Similar to Amazon/AWS RedHat seems to be moving to Open Source of convenience, where you have portions of your software Open Source when it helps your business, and not so much if it does not.
> Similar to Amazon/AWS RedHat seems to be moving to Open Source of convenience, where you have portions of your software Open Source when it helps your business, and not so much if it does not.
I guess it’s quite pragmatic from the short- and even medium-term perspective, although it likely may become well poisoning in the long term.
There used to be an understanding that since Red Hat is making a lot of buck on the shoulders of contributors making FOSS available, they have an obligation of giving a considerable amount of goodwill in return. It looks like they are now pulling a Reddit, but making it a long game.
I mean, right now it looks like they are protecting their business (you really want to get paid for having to backport fixes to some library which has been EOLed and forgotten by its upstream half a decade ago, and for all stability promises no vendor is giving!), but it’s opening a way to shittier practices, if you get my drift.
The specs themselves usually come from Fedora first, where they are MIT by default (per Contributor Agreement, at least). So RH can do anything they please as long as they acknowledge the authors (which is done trivially by not mucking with %changelog).
Anything they please likely includes terminating your account if they sniff you using it to avoid the fees or enabling others to do so. If you are contemplating, say, using a Red Hat Individual Developer Access (or what they call it) to redistribute the sources, they have a provision in the terms you have to agree to just against such cases.
I'm interested in how IBM will try to refuse selling to Alma/Rocky/Oracle. You'd think those guys would already have a paid Red Hat subscription. The lawsuits between Oracle and IBM will be epic.
Most T&C have a clause allowing them to simply end any subscription without needing a clear reason.
And I doubt rocky or almalinux want to start a cat and mouse game of opening accounts and these accounts getting banned by Red Hat.
I would assume the people that actually develop those either already are RHEL customers or they would just pay a single subscription so they can download the code and keep it in sync
I have edited my question from official to legal (at least from a US-perspective). Another commenter in this thread has stated that it would be against their TOS.
Grass Green;
Sky Blue;
Corporate entity that subversively pushed systemd into as many Linux distros as possible still engaging in user-hostile, FLOSS-hostile activity
good decision from red hat. oracle, alma and rocky cant just take other peoples work, profit (not just monetary) and give nothing back. thats not what community means.
If Red Hat chooses not to perform their duties under the GPL, then any holder of copyright can require Red Hat to remove the owner's source packages from the commercial distribution.
Red Hat could minimally perform this duty by providing the source only to those who download the binary releases. As there are several avenues for free downloads (developer, 16 free licenses for small business, etc.), the source will be available by that route.
>Red Hat could minimally perform this duty by providing the source only to those who download the binary releases. As there are several avenues for free downloads (developer, 16 free licenses for small business, etc.), the source will be available by that route.
If you read the original announcement, this is exactly the case
"For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."
In theory nothing prevents Rocky and Alma from buying a license, downloading the sources, and rebuilding the packages from there. The terms of service restrict only redistribution of binaries, not sources, and the GPL dictates that those would remain available.
Currently you need a Red Hat account to download an ISO image, but you don't need to be a customer. IBM/Red Hat's announcement says that you need to be a customer or partner to download the source, so one could be able to download binary but refused the source.
I also wonder how it will go if AWS provides RHEL for a server, and you ask them for the source.
I doubt most RHEL packages use the GPL. They were publishing full source out of goodness of their hearts (or maybe to conquer more market share and then potentially convert some of that into sales if you're more cynical).
It was more about the second part of your comment. Even if they're forced into providing source for the few essential system libraries (plus the kernel), I don't see what it gives you without the rest of the system (most of which is under pushover licenses because we can't learn from our mistakes).
IIUC (I work for Red Hat but not on how sources are distributed), there is absolutely no change in practice.
CentOS Stream RPM sources are stored in GitLab therefore the whole history is available including past minor releases of RHEL. The only change is that the repositories will not be mirrored to git.centos.org.
git.centos.org (g.c.o) has been the historical canonical local for RHEL sources that have been exported out of Red Hat. On any given package you would see several branches, one for each major release and other organizational artifacts (e.g. c7, c8, c9, etc). Initially CentOS Stream 9 was exported to g.c.o as it wasn't a true upstream in the full sense of the word, but with CentOS Stream 9 that changed. c9s is developed in full on GitLab, and now c8s as well, while the final RHEL sources for those packages are still output to the c8 and c9 branches on g.c.o.
What changes here is that Red Hat will no longer be exporting the c8 and c9 content to any git platform (c7 will continue as exists until its EOL). Customers can access sources as needed via the Customer Portal and CDN repositories, but sources in git form will not be publicly available for those artifacts. Moving forward, only c8s and c9s sources will be available, and g.c.o will not see any updates for EL8 and EL9.
While most (I'd estimate at least 95%) of the platform will match in terms of NEVRA between versions available in CentOS Stream and their RHEL counterparts, there are some packages that will not due to the way they are developed.
> Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusion of these two RHEL clones’ success would be to eliminate their host, leading to their own demise, which is why one person in the Linux space called them the “dirtbags” of open source.
> If there are any real parasites, it's Oracle Linux.
https://en.wikipedia.org/wiki/Oracle_Linux
> Oracle Linux (abbreviated OL, formerly known as Oracle Enterprise Linux or OEL) is a Linux distribution packaged and freely distributed by Oracle, available partially under the GNU General Public License since late 2006.[4] It is compiled from Red Hat Enterprise Linux (RHEL) source code, replacing Red Hat branding with Oracle's.
I had no idea that Oracle Linux was essentially RHEL with %s/Red\ Hat/Oracle/g and Oracle has a market cap of $330bn