CIQ, Oracle, SUSE Create Open Enterprise Linux Association
suse.com
suse.com
https://en.wikipedia.org/wiki/United_Linux
> "No subscriptions. No passwords. No barriers. Freeloaders welcome."
I'm sure they're trying to be cheeky. But it also comes off as confirming Red Hat's position. OpenELA isn't about community, it's about having a base (i.e. bug-for-bug RHEL clone) upon which to sell support contracts.
If you really want to stay in the Red Hat ecosystem, I'd suggest going with AlmaLinux instead. They seem to have a more honest understanding of what "community" means.
Some people are throwing the word "freeloaders" around. It seems clear that "freeloaders" are not people running RHEL clones, but indeed there are some "freeloaders" in the community.
I tend to respect the AlmaLinux way of doing things, but I respect where the others are coming from.
Red Hat never allowed CentOS to have any kind of election. It was never a community driven project after Red Hat bought it.
So, very interesting to see these companies banding together to give us back CentOS by another name. It will be interesting to see what Rocky and Alma do.
End of story.
As you so point out your bias, it would be really nice if you didn't speak on behalf of your employer and let others make their own conclusions without hearing from those biased.
This is one factor in my determination to never allow them into my regional data center. There are several other factors.
"United Linux was an attempt by a consortium of Linux distributors to create a common base distribution for enterprise use, so as to minimize duplication of engineering effort and form an effective competitor to Red Hat. The founding members of United Linux were SUSE, Turbolinux, Conectiva (now merged with MandrakeSoft to form Mandriva) and Caldera International (later renamed to The SCO Group). The consortium was announced on May 30, 2002. The end of the project was announced on January 22, 2004."
It never really worked from a business perspective but Caldera becoming faux-SCO was pretty much the final straw.
why not donating a certain amount of money to some distros instead? there's an expected level of entitlement when it money's involved.
> they only have annual subscription
You are not buying the software. You cannot buy the software. All you can buy is a support subscription. That is what RH sells, not software.
and the chance to scream at their customer service. /j
I can tell you that even inside the company, everyone I knew who had the beginning of a clue ran Fedora. Only those with zero tech knowledge and who didn't want to learn ran RHEL... and they get it for free, obvs.
Probably some RH folk will now pop up to tell me I am totally wrong and it's all changed. That is 100% normal. You can ignore them. I do. ;-)
> SELF-SUPPORT (1 YEAR)
> Does not include Red Hat customer support.
> Starting at US$179
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser... > SELF-SUPPORT (1 YEAR)
> Does not include Red Hat customer support.
> Total US$349There is more to the sub than getting someone on the phone.
Updates are probably the #1 thing.
Secondly, "support" means things like "access to full documentation" and "access to source code".
Free software from 0racle? There are gonna be strings attached... to lawyers.
In this case, it might be Oracle's lawyers preventing them from being aggressive, because they wouldn't fare well trying to challenge Red Hat. If they screw up their treading-lightly strategy, or if they get into legal trouble, there could no longer be a suitable operating system to run Oracle Database on.
They need to give it away for those same strategic reasons that they created it.
Many in very important subsystems. The XFS maintainer (who just recently stepped down from this role) and contributor Darrick Wong works for Oracle. Meanwhile, btrfs is the creation of Chris Mason, who worked there until 2012. Modern filesystems on linux owe a decent debt to Oracle. Good luck running an Oracle-free linux.
I often find it interesting when people imply the company is freeloading for having chosen the path of making an RHEL clone. They cloned RHEL because an unhealthy, dependent ecosystem was built around the one, singular linux distribution, not because they are unwilling to fund work.
Giving some serious competition to Red Hat can only be a good thing.
They cloned RHEL to spite Red Hat for the JBoss acquisition in the mid-2000s.
Oracle and Red Hat both entered the bidding for JBoss and Red Hat ended up winning. Larry Ellison took this very poorly.
I really remembered the BEA acquisition as the prior event.
Oracle went after Red Hat when Red Hat bought JBoss. Larry said as much. They didn’t like Red Hat actually competing with them, so Oracle sought to undermine RHEL & have a full stack so they didn’t have to share customer spends.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
If you search for that paragraph, you'll find lots of examples of it being reproduced verbatim.
If this is a commitment to a set of source then the players can compete on ease of use, support or other stuff.
Let's Encrypt has their own infrastructure, governance, etc., but I don't use Let's Encrypt products to interact with Let's Encrypt. Instead, I interact with Let's Encrypt via products like Certbot from the EFF.
If OpenELA's going to provide source, and I access that source through builds provided by CIQ or SUSE or someone else, then I'll be thinking of it in the same way as I think about Let's Encrypt.
I'm sure there's a reason for it with all the discussions, but if I want to use CentOS, why wouldn't I just use CentOS Stream that RH is providing? If I want RHEL, I'll go get RHEL that afaik is also free. If I want to see the future of RHEL, there's Fedora Server. And if I believed RH was being intentionally hostile, why would I support them at all and not go with a completely unrelated distro like SUSE?
You can't get RHEL for free.
Things I read online say it's free, including https://developers.redhat.com/products/rhel/download
As I understand, the only costs with RHEL include using it across a large number of machines in enterprise, and customer support. Someone using it on a few machines in a home lab should be fine I imagine?
16 machines is more devices than I have in my house, and enterprise seems like they can just pay for RHEL. I'm also betting there's not some thorough verification process that would prevent you from running RHEL free on more than 16 machines (seems almost too easy, but just make multiple free accounts per-16 machines? RH I'm sure would be happier to have people running RHEL at all than intentionally seeking out free license violators)
16 licenses is the proverbial tip.
we know what happens next.
Pre-Stream CentOS was never my preference, but I did spend some time running it to learn the RHEL way. The free licenses would fill that gap.
At work we run RHEL where we needed support and Alma where we don't. It was chosen for me. I'm watching to see how this plays out, but not incredibly concerned.
That said, I can understand how one wouldn't want to do that. For a home lab, I'd say any distro is totally fine.
Does that include virtual machines?
"The no-cost Red Hat Developer Subscription for Individuals grants the ability to install Red Hat [...] on 16 physical or virtual nodes"
"The Red Hat Developer Subscription for Individuals is a single subscription, which allows the user to install Red Hat Enterprise Linux on a maximum of 16 systems, physical or virtual, regardless of system facts and size."
[1] https://developers.redhat.com/articles/faqs-no-cost-red-hat-...
What I'm not understanding is why people need to use RHEL and would resort to free random forks of it, instead of just using CentOS Stream or Fedora that are basically the same thing, actually from RH, and 100% free. RHEL is not that special.
I'm on the fence about that. I wish people were more willing to financially support open-source development, but I've worked with dozens of customers using RHEL over the last 10 years and never seen a single one of them open a support request - on that basis I can see why people feel that the price is too high. When the options are "get gouged" or "be labelled a freeloader", the outcome is pretty obvious.
> just using CentOS Stream or Fedora
I think the rise of free alternatives (Amazon Linux) and a DevOps-style mindset (no patching, just burn it down and redeploy when updates are needed) are exactly what has motivated this squeeze - RHEL is losing relevance in a lot of places, so RH/IBM are left with fewer potential customers and so just end up squeezing them harder.
In other words you pay for not having to open support requests.
Being an open source company means that RH has a non-standard business model and should expect non-standard profits. Their business model is inevitably doomed, but rather than innovating they are going with the "lock-in and gouge" model, exactly like Oracle.
Red Hat supports 15-ish release streams at this time between RHEL7, RHEL8 and RHEL9. A lot of customers need that because validating a base system update takes months and they cannot afford not having security updates in the meanwhile.
In my opinion 99% of end users would be served well by CentOS Stream, but the strong marketing of bug-for-bug compatible distros on part of Rocky (and to be honest it's a fig leaf to pretend CIQ is not behind that) hampered the adoption of CentOS Stream and the users' perception of its stability.
How is that lock-in from Red Hat's part?
No support requests usually means everything is working. No news means good news
RHEL could have survived for a while in hostile mode if everybody was complacent (maybe making the entire thing profitable). But this is exactly people not being complacent.
Anyway, you can bet there will be infighting once this is established. But well, the power that free software grants for people to misbehave is very limited.
I'm getting the vive that some people just want free RHEL, feel entitled to have it, and don't realize that actual RHEL is free within reason (apparently up to 16 simultaneous machines). Nobody remotely concerned about security is running a non-mainstream distro and public-facing services in an age of randomware and crypto.
Only SUSE has its own distro, or rather, whole family of them: SLE, openSUSE Leap, and openSUSE Tumbleweed.
The others are rebuilds of CentOS Linux source.
- Are you going to kill Leap and Tumbleweed?
- Are you going to handle the "community" as you do with the openSUSE community?
MicroOS is and will be its own cool thing AFAIK. I'm guessing they will provide a MicroOS based on Leap in the future.
Google Chrome 112.0.5615.165 (Official Build) (64-bit)
Revision c262f36e6b1d711ee42d4fbe1343b49960593f18-refs/branch-heads/5615@{#1297}
OS Linux
JavaScript V8 11.2.214.14
User Agent Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/112.0.0.0 Safari/537.36
Command Line /usr/bin/google-chrome-stable --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=WebGPU
Executable Path /opt/google/chrome/google-chromeSo they're not trying to create something like RHEL but in a way that is committed to being more 'open' somehow. They're still shooting for the bug-for-bug stuff, and still an effort that's parasitic on RHEL in terms of its substantive development.
This whole situation sucks.
Idk. How is that standing on its own? SUSE already has a perfectly good enterprise Linux distro in SLE. If the point is to have an alternative standard that anyone can build from, why not just use that as the base?
Seems to me that all the RHEL derivatives were perfectly content to let RH set the standards for enterprise linux. RH doesn't like that arrangement. SUSE probably wouldn't mind it.
All the derivatives have their EL8 and EL9 based distributions they've committed themselves to support for some time, so I'm sure they'll maintain bug for bug compatibility as best they can given the circumstances. No reason for them to keep following RH after that.
Just FWIW I can point to a dozen other CentOS Linux rebuilds, at least one backed by Huawei and another backed by HPE.
So no, this is badly wrong.
In many ways, Red Hat and IBM are the modern Sun Microsystems and AT&T, so it's not surprising that their competitors are essentially doing the same thing.
OSF was developing an operating system[1] based on Mach, a file system from IBM, and BSD's IP stack, that intentionally had very little in common with AT&T UNIX.
OpenELA is trying to create a carbon copy of their competitor's product, guided by the slogan "bug-for-bug compatible".
These reactions couldn't be further apart.
zypper is probably the best 'classic' package manager there is (although dnf is great too; it's more of an argument against Debian and its derivatives).
Then there is https://build.openbuildservice.org which automatically builds packages for all supported distributions and architectures from a single RPM spec file and creates a ready to use repository for you.
OpenSUSE Leap is built from SLES sources and is thus comparable in its stability guarantees to the old CentOS (or any of the current RHEL rebuilds).
I'm confused on the differences in repo priority between zypper (oS TW) and dnf (Fedora). Apparently dnf also allows setting repo priority, but I've never had to do it, and packages seem to come from expected repos without having to specify (stuff comes from RPM Fusion if I have those repos added). On TW I had to manually specify repo priority to something other than 99 and set a flag to allow vendor changes to have similar behavior; I like that kind of control but I didn't need to do it on Fedora.
OBS is nice in-concept but I don't like the idea of using it outside of openSUSE. I think Launchpad/PPAs for Ubuntu, Copr for Fedora, and AUR for Arch. I think OBS for openSUSE and don't like the idea of using OBS for other distros, even if that's one of the big benefits and point to OBS.
--
1: https://yast.opensuse.org/documentation
It's not the same thing at all, or even very comparable, AFAICS.
Your site produces a Fedora COPR. One of the people on the COPR team spent 10 min trying to explain to me what COPR meant at a Flock conference a few years ago. The actual answer is:
"It's a PPA but for Fedora instead of Ubuntu."
SUSE OBS does not build repos and it does not build openSUSE packages. I am running native Debian packages on Ubuntu right now built on OBS (Waterfox, notably.)
OSB builds anything for any OS. It's basically a free public CI/CD server, and it's platform-neutral.
I have not checked but I believe it can also build Windows and macOS binaries as well.
The same point has been made twice, so the response is identical..?
> "It's a PPA but for Fedora instead of Ubuntu."
So I'm not sure the analogy holds 100%.
I, as a software developer, want to distribute my SW. I use COPR to build RPMs that run on any RPM-based distro, e.g. openSUSE, Fedora, RHEL, CentOS, ...
You, as the consumer, can enable the COPR repository and consume my packages (or you can manually download the RPMs if you prefer).
> OSB builds anything for any OS. It's basically a free public CI/CD server, and it's platform-neutral.
That is indeed different. Thank you, I might take a look at OSB.
I've ran Ubuntu and openSUSE servers and aside from a profile issue with PHP and openSUSE, I don't know if AppArmor is even protecting anything. Everything just works and it makes me think AppArmor is only applied to specific apps/services and not globally.
SELinux (at least on Fedora) is present, everywhere, and will gladly let you know if something is blocked because of it. I prefer this kind of protection even if it's more annoying at times :p Just a few weeks ago I learned about bin_t and that made my SELinux config for that service a lot more simple.
The great value of RedHat was supported software. You could buy one of those $10,000 per seat software packages for some engineering discipline that was guaranteed to work by RedHat and the vendor and if it wasn't they were quite motivated and helpful in fixing your problem quickly.
RedHat also was trusted to monitor and fix security problems quickly, and was in the privileged position of getting notifications about them before they were public so they could be fixed.
The question is how do you get people to fund these two things?
I'm inclined to believe them, with the caveat that this reality may not have come to be had IBM never bought Red Hat. That still doesn't imply IBM forced the change.
It's public record that Paul Cormier has considered the way CentOS worked a problem for years... https://m.youtube.com/watch?v=ITRol3YAV-E&t=360s
Why do you think this is a bad change? I was thinking additional players in the space would make for a more robust ecosystem.
For example, LWN's most-recent report[0] on who contributed Linux kernel patches puts either three or four different companies above Red Hat, depending on if you're looking at changesets or lines changed.
Regardless, if leadership is theirs to lose, then they're doing a good job of it.
Kernel contributions are only one metric / piece of a distro, and these days a lot of the code churn is hardware if I’m not mistaken. It makes sense that Red Hat has slipped because the big changes are in new support for hardware.
Come to think of it, why is SUSE considered as a serious replacement for RHEL and not Ubuntu?
SLES and RHEL are somewhat similar, in that they both use the RPM package format, and they both have a 10 year support lifecycle. They are not entirely compatible though. They also make management software that is supposed to be as interoperable as possible with competitor distributions.
Anyways, last month SUSE announced they would be making an actual RHEL fork, so that's the real reason they are joining this new partnership -- it's not related to SLES, but a new distro they are making.
As for Ubuntu -- it is often touted as an alternative to RHEL. However, people don't like the weird ways in which Ubuntu diverges from the rest of the Linux community (Snap, LXD, ufw, etc.), so some attention is diverted towards Debian and RHEL, which are more focused on packaging software that is already proven. Red Hat does their innovation in Fedora, waits a few years to see if it catches on, then implements it in RHEL. This tends to have a greater degree of success than pushing it suddenly on users like Ubuntu does.
I don't think there are any corporate entities reselling a rebuilt Ubuntu
OEL is just rebuilt RHEL.
Ubuntu has live kernel patching also, but with a different technology. And it's called different.
After Oracle acquired the company that developed ksplice and took the technology private, SUSE started to develop kGraft[1] and Red Hat started to develop kpatch[2], and these were eventually merged and upstreamed[3] into Linux.
[1] https://lwn.net/Articles/596854/ [2] https://lwn.net/Articles/597407/ [3] https://lwn.net/Articles/619390/
Ubuntu is downstream from Debian. They get a lot of packaging for free.
I don't think I know a single package in Ubuntu that is a Debian package. That is what Ubuntu _does_ -- it takes Debian, repackages and tests and integrates it.
There really aren’t rebuilders for Ubuntu in the same way, and Canonical has a very different place in the industry. I think there was a thing a few years ago about Canonical going after some of the distros based on Ubuntu, but I think that was over pointing directly to Canonical’s repos (rather than hosting their own binaries), which is reasonable.
If Canonical were a public company or owned by one and had a multi-billion dollar business being undermined by clones and freeloaders… I think you’d see similar actions.
See for example this security update, the versions back to 20.04 have links to launchpad, the older versions have no link but say "Available with Ubuntu Pro".
https://news.ycombinator.com/item?id=37079769 (ZDnet story, 5 comments)
https://news.ycombinator.com/item?id=37078603 (Phoronix story; no comments on HN)
https://news.ycombinator.com/item?id=37085519 (ZDNet again, no comments)
The incentives between these two structures make a world of difference.
501(c)(3): Organizations under this classification must primarily serve a public interest and not a private interest. Any private benefit must be insubstantial.
501(c)(6): These organizations are designed to serve the private interests of their members, as long as those interests align with the broader industry or line of business.
Everything else follows from this distinction IMHO. You see it play out in the Linux or Rust foundation, in contrast to the Python or Zig software foundation. It's easier to get attention and members with a trade organization, but over time, over the long term, there's a stark difference that I believe is not disputed.
I'm not sure what you mean by "incentives". Perhaps you could elaborate.
[1] https://en.wikipedia.org/wiki/501(c)(3)_organization#Types
[2] https://en.wikipedia.org/wiki/501(c)_organization#Contributi...
(I'm not sure exactly what the current support is like; I left the board over a year ago. I think it's around 10 folks that donate somewhat regularly.)
Certainly the political activity provision of 501(c)(6)s are beneficial for this association, and I guess they'd have more scrutiny as three large companies instead of a few high schoolers.
- The Linux Foundation (which includes the CNCF and OpenJS Foundation)
- Rust Foundation
- Bytecode Alliance
I don't mean to provide an opinion on incentives (and they are different as the parent suggests). I just mean to share that trade organizations are already common.
Disclaimer: I work for SUSE but not on OpenELA. I am also a maintainer of CNCF projects and on the CNCF TOC.
As much as any large evilcorp can be the good guys anyway.
And now even Oracle is looking like the reasonable player?
A broken clock and so on. Oracle has absolutely no reason to misbehave here, and everything to gain by being ethical. At this point, they would only do something wrong if the compulsion was too strong.
I used Warty myself. But while Debian was around in 1997, Ubuntu was not.
You can't have been using Ubuntu in 1997 because it didn't exist yet.
I also would add a question:
Debian in 1997 did not have automatic package dependency resolution yet, AIUI, because this was before APT.
So, what made Debian worth using before APT?