Red Hat cutting back RHEL source availability
lwn.net
lwn.net
> 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
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
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.
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
Oracle fixes that.
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.
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.
Pre-IBM sure... Post IBM hardly
>>its hard to point to another company that does more across as much of the opensource ecosystem. Maybe google these days?
Really, you think google is a good example of Open Source... wow how far we have come..
Google worse than Microsoft when it comes to the EEE model
You are correct Canonical is not ideal, but I find them to be more ethical and upfront than Post-IBM RedHat and for sure google
Can you put some substance on that statement?
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.
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.
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.
Containers are mostly ephemerals when used for build and test purpose.
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.
So basically you are saying the author of an ansible book do not care spending a couple of minutes understanding a simple process to automatise it.
Sounds like great advertising for your books really.
(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!)
So yeah, 5 years is pretty recent, unless you started using linux last week.
If you have a source with the original announcement, by all means share it.
EDIT: found an announcement of march 2016 so we are talking +7years at least.
> 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.
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.
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.
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
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.
Free Software and Open Source are essentially the same, despite the philosophical differences. The issue here is against the copyleft (GPL and AGPL).
No ... no they are not
>>despite the philosophical differences.
And those differences are HUGE and make them incompatible
Then see how many of those are OSI approved licences (thus open source).
It was like this at least 20 years ago.
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).
> 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.”
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/licenses/license-list.en.html#apache2
https://www.gnu.org/licenses/license-list.en.html#X11License
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.
Does that make sense? Thanks for the correction.
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.
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.
> 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.”
This Venn diagram is FSF's view of the taxonomy:
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.
Is that about right?
That was what I meant initially: in HN there's a strong opinion against copyleft, not necessarily free software.
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.
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
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!
Thanks for sharing those links.
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.
(that doesn't mean the difference isn't important though)
I don't really get why people are for non-copyleft licenses. LGPL is fine license.
Yes they are, according to people who use both terms. All “free software” licenses are also “open source” licenses and vice versa.
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).
* 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".
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.
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.
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.
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.
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?
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.
CentOS wasn't selling support contracts tho.
Not that I think anything they are doing is in any way wrong mind you.
[1] https://www.redhat.com/en/about/open-source-program-office/c...
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.
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.
https://www.infoworld.com/article/3697733/chatgpt-s-parasiti...
That's funny, because that's how I tend to feel about Red Hat.
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]
[1] https://web.archive.org/web/20150313140846/https://starcount... (2015, archive.org)
The full article: https://web.archive.org/web/20190919121901/https://www.reddi...
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.
It boggles my mind.
> Nobody ever got fired for buying IBM
Nobody ever got fired for buying, Oracle or Microsoft or any big incumbent. The same could definitely not be said for choosing any free software.
Ironically RHEL is IBM now.
Fail to make your budget work 5 quarters in a row and see how long you last. ;)
Or wait for a legal case to come up: someones getting fired, wether its you or a scapegoat you sacrifice.
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.
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 ?
Oh, that’s easy. neither.
I use postgres predominantly.
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".
So ridiculous...
I remember our amazement on how we failed audit on having a cipher enabled in OpenSSH version that had that cipher removed in upstream...
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.
Regarding SSH, the FUTURE policy removes AES128, HMAC-SHA1 and DH Group 14.
I'm reminded of the definition of a linux distribution: a package manager and a source repository.
(that said, unbreakable linux, yeah)
But imagine being a contributor to a package which redhat incorporates and using it via centos/rocky.
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.
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.)
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.
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.
https://wiki.debian.org/LTS/Funding https://wiki.debian.org/ExternalEntities
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.
And it turned out near-nobody did so they turned it into stream so you could no longer have "same as RHEL" version.
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.
MySQL got great value
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.
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.
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.
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..)
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.
https://blog.prusa3d.com/the-state-of-open-source-in-3d-prin...
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.
Also note that IBM contributions to Linux kernel in 2000, was one of the reasons it actually took off.
Okay? Do you feel attacked because I wrote something negative about IBM? Not sure how that is relevant to my point.
> Also note that IBM contributions to Linux kernel in 2000, was one of the reasons it actually took off.
And that influences the motivations behind their current decisions how exactly?
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.
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.
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.
"At some level, the rest is history."
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.
https://www.zdnet.com/article/ibm-gets-100000-fine-for-peace...
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.)
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.
That alone looks quite alright for a dying company.
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.
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.
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.
That was quarter a century ago.
Their market caps are almost identical, and personally I'd say it'll be a cold day in hell before Oracle merges with, nevermind is acquired by, IBM.
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.
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.
> 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
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.
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'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.
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.
IBM is doing the thing IBM knows how to do, which is have their internal politics, honed over a century or so, dictate the customer experience.
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.
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, ...
RHEL has never used that, and Fedora has perennial discussions about killing it because the benefits rarely outweigh the costs anymore
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.
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.
DNF doesn't solve this specific problem.
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.
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.
Canonical's model is to ship the kitchen sink and wing it in case a customer wants support on something that is in a sorry state.
Different customers, different requirements.
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".
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.
For example fuzzywhatsit-3.0 in RHEL could be functionally equivalent to 3.5 in another distro.
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...
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.
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:
https://news.ycombinator.com/item?id=36292831
FWIW, I did add paste, a full cleaning. And this was purchased used rather cheaply 2 years ago. It is 9 years old now.
Why am I bothered by this ? This seems to be a weak first step of companies making Linux go proprietary. Already we need many proprietary blobs.
And funny, NASA just signed a contract with Rocky and CERN went with AlmaLinux,
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'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.
The LF who fought attempts to hold VMware accountable for alleged GPL breaches?
But the short version is Wayland does do everything I need, plus it is Linux specific.
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.
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.
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.
Thanks for the correction on the title.
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%.
https://news.ycombinator.com/item?id=36417968
Shouldn't be of relevance.
links to "SATPC0031698 Tab 04 SOW.pdf"
which has 2 line items,
- CIQ Rocky Enterprise Linux Per Person Advanced - Annual Subscription Service Period: June 1, 2023-May 31, 2024
- CIQ Rocky Enterprise Linux Per Person Advanced - Annual Subscription Service Period: June 1, 2024-May 31, 2025
Quantity of 3 for each of them.
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.
https://www.nas.nasa.gov/hecc/support/kb/news/transition-to-...
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.
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.
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.
The whole point of RHEL is the long term support (the back-porting), which is what they're going to stop publishing.
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.
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.
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.
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.
That sounds like a further restriction.
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
But I expect we'd have to see litigation to determine how broadly that can be interpreted.
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.
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.
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.
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).
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”).
https://www.redhat.com/licenses/Appendix_1_Global_English_20...
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.
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.
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.
> 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.
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.
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 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 only issue is that many cloud providers don't have RHEL as an OS option, so you can't use it on your average cheap VPS.
That assumes you trust them not to do another rug pull (CentOS 8)
https://docs.aws.amazon.com/linux/al2023/ug/relationship-to-...
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.
I don't think it will be much more difficult to obtain.
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.
The article states clearly that they are doing this, no need to speculate.
I also wonder how it will go if AWS provides RHEL for a server, and you ask them for the source.
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.