It seems this Dirk-Peter guy is a long time Red Hat guy and he probably knows Red Hat Linux inside out.
This can be 2nd most important Linux distro announcement for the good of the community by a company after Canonical's announcement of Ubuntu back in 2004, but time will tell if this going to take-off by spinning a new generic enterprise Linux distro based on RHEL.
Interestingly the last Red Hat for community (most popular at the time) is Red Hat 9 before it gone fully enterprise by launching Fedora back in 2004. Coincidentally Ubuntu was launched around the same time (now most popular Linux distro). Probably the last Red Hat Enterprise is RHEL 9 as we know it.
They're admitting that the Linux that enterprise people want is RHEL (or RHEL-based) and not SLES.
Also, if CIQ follows them and SUSE bases this on CentOS Stream (at least for RHEL9; CentOS Stream 8 is admittedly a bit messy), this is exactly what Red Hat was hoping to achieve.
The US market is primarily RHEL. Historically the EU market and SAP shops were SLES. I admit I’m far enough removed today that I’m not sure if that still holds true.
Enterprises don't care what distro they use, and SuSE knows that. Enterprises care about the reputation of their professional services provider.
RHEL is increasingly seen as threatening its own place in the market, and enterprises want to be sure their multi million dollar investments will be stable over the long term. Paying SuSE for support makes sense if you believe they will support you better over the long term than RHEL will. Time will tell who provides more value, but SuSE does appear to be out-IBMing IBM.
From what I've seen big enterprises have thousands of RHEL or SLES licenses and the whole thing is managed by one guy who can hardly migrate from RHEL 7 to RHEL 8 because of the huge backlog of work he has.
For the average enterprise switching from SLES to SUSE RHEL means that update will happen in 5-7 years
I've done a few of those RHEL/CentOS/Ubuntu moves myself, and even though it was a pain I'm still somewhat impressed over how painless the actual move was when I had good documentation and also still terrified of what it feels like to try to transition undocumented boxes.
I dislike windows and the M$ ecosystem but as far as server management for undocumented servers it's much easier to deal with them than for Linux stuff. For an undocumented Windows server, you send out an email, wait 2 weeks, shut it down and listen for the screams.
For an undocumented Linux server, you send out an email, wait 2 weeks, prep the fire extinguishers, batten the hatches, and wait for the mob of angry villagers to storm the DC with pitchforks because thanks to you their print server for their paper checks is now printing in Klingon and it can't be fixed without resurrecting the guy that wrote the software 6 days before he died of terminal terminal disease.
No. Just that Windows servers are much easier to navigate to find what files and systems are running.
With Linux systems, sure, you can check chron and top and find what is running and where it is but it's a bit more unwieldy than the windows GUI, plus you don't always have a full list of the file and folder permissions and getting a full list of those requirements for whichever softwares are accessing them.
I remember that way back when, Deutschebank standardised on SuSE because they were a major shareholder in the company. DB had an IT department bigger than most entire companies, so I'm sure that had a pretty big effect on the ecosystem.
As an engineer I don't care. In my career I have worked on SunOS, SLES, Debian, Ubuntu, RHEL, CentOS, Alpine and probably more.
I prefer something that is kept reasonably up to date so that I don't have to fight ancient long-fixed issues or missing features. But I really don't care, if it pays the bills I'll use it.
Going back about 15 years with this, but I used to prefer Debian / Ubuntu as a user, but for automating pxe installations and setting up package repos, Redhat/Centos were miles better.
I think they are positioning their own professionally supported enterprise distro as “the best” while positioning this Red Hat clone as the free-est ( both in the free beer and freedom sense ).
It is a good move. They siphon off customers from the competition to a free option and dramatically raise awareness of their paid service.
If it turns out that they still cannot make headway in North America with SLES, they can create paid support options for Liberty. Just like Red Hat, they will have the credibility of being the distro maintainer.
Given the staffing and infrastructure they already have to maintain for SLES, maintaining a RHEL-a-like may not even be that much work.
Actually, quite the opposite. Going all the way upstream to Fedora, the trademarks are designed to be easy to change out. Going from Fedora to CentOS Stream shows one brand swap over. And if you have RHEL, you can easily compare the package sets between CentOS Stream and RHEL to see which packages are swapped for branding.
Both Red Hat and SUSE distributions make it easy because internally both companies need to do the trademark swap in their own engineering pipelines.
Rocky Linux is trying to specifically recreate RHEL exactly. That adds a new set of challenges that most people shouldn't care about.
If you want to create a derivative of any Fedora/CentOS distribution, that's not hard. But if you're trying to recreate, that's a different story. You have to care about things like build sequencing, NVRs, etc.
For example, if I'm creating Kudo Linux as a RHEL-compatible distribution by deriving from CentOS Stream, I only need to swap the branding packages and call it a day. The rest of my engineering effort can be spent in Fedora or CentOS Stream as appropriate. But if I'm creating Kudo Linux as a distribution that re-creates RHEL, then I need all the source packages to build, figure out build orders, and swap out branding. I also have to do my own lifecycling and validation. I am also now responsible for the maintenance of all the software and ensuring people get updates.
I would guess Suse is trying to do the harder one. I could be wrong, but I think the intended audience is people that want to drop RedHat and the associated cost, but with minimal changes to everything in their ecosystem other than the OS itself.
If Suse thinks they are going to make money in this space via support contracts rather than licensing, it's sort of a "commoditize your complements" thing...commoditizing the paid license subscription part. That's a guess though. It's not clear to me how they plan to make money with this move.
- damage and embarrass Red Hat, their direct competitor
- enhance their own brand, brand awareness, and reputation with customers of their competitor. Sell more of their own existing enterprise offerings as a result.
- create an alternative distribution that they can monetize if it turns out to be more popular than their own offerings ( even if only in one geography )
And in fact you probably won't create a perfect reproduction given you don't have access to the very complex RHEL build system. (CentOS didn't either.) Which makes some of the angst over just using CentOS Stream because it's not a downstream rebuild a bit misplaced.
I believe the idea is that RedHat will likely be more thorough with a commercial entity than they were with CentOS. Yes, I'm sure it's technically possible, but also possible they will get into some back-and-forth with RedHat.
Redhat debranded RHEL for CentOS. It was one of the things CentOS compalined about, so RedHat made it easier for them. Maybe it saved RedHat money overall by avoiding trademark protection (IANAL).
$ ssh me@myol7.myplace.com cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 7.9
Red Hat Enterprise Linux Server release 7.9 (Maipo)
$ ssh me@myol8.myplace.com cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 8.8
Red Hat Enterprise Linux release 8.8 (Ootpa)
$ ssh me@myol9.myplace.com cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 9.2
Red Hat Enterprise Linux release 9.2 (Plow)
I guess Oracle doesn't remove all the branding. I don't remember how CentOS handled this.
My understanding is /etc/redhat-release needs to be there because some (dumb) blob drivers specifically check that file to see if you're running a compatible RHEL system before it'll even attempt to install.
At a previous job, we had a wrapper script that swapped the file out before attempting to launch Dell software installers/firmware updaters, because they sometimes checked for hardcoded exact strings like that in there, and errored out, and whether or not it did that varied back and forth over the years.
Doesn't matter. IBM/Red Hat has deep pockets, they can drag competitors into meritless lawsuits for as long as they want just for the sake of deterrence. Having hired a former VP who probably knows a trade secret or two sounds like a good enough excuse to cry wolf.
> IBM/Red Hat has deep pockets, they can drag competitors into meritless lawsuits for as long as they want just for the sake of deterrence
If IBM sues SUSE, Oracle might try to intervene, on the grounds that a ruling against SUSE could negatively impact them as well.
I'm not sure if IBM vs Oracle is a lawsuit either would want to have. Both have very deep pockets, and substantial corporate experience with litigation. So, that factor may help protect SUSE
Oracle will never second Open Source, I assure you. They will defend themselves. Occasionally that may benefit you accidentally. If so, I would not bet on it continuing.
I'm continually baffled that so many companies follow RHEL compatibility to this day.
I've been using Linux for nearly 30 years. Admining as a profession for at least a quarter of that. 20 years ago, it made a ton of sense. Today, less so.
The 'stable version but we backport patches' mantra doesn't make any sense today. I can't even describe how many things that have broken that you can't even find an answer for because it was some RH specific patch.
Between Debian, Nix, Arch, and others, I can't figure out why RHEL compat is so desirable. I'll go as far as to say that my Arch boxes have been far more predictable than my RHEL boxes.
It is like this for everything. The documentation is clear, concise, comprehensive, complete, and versioned. This is what being RHEL compatible gets you.
Documentation isn't sexy or something. I don't know why Linux documentation sucks so much, but Redhat makes it suck must less. It takes lots of effort, money and writer hours to create the kind of documentation that Redhat maintains and businesses love documentation. A HOWTO or a FAQ are not documentation.
I actually prefer man pages and I dropped Linux for my personal project years ago in favor of OpenBSD (sometimes FreeBSD) precisely because their man pages are well maintained and really well written. I still have to interact with Linux sometimes and it's almost always Debian or Redhat. And I gotta say Redhat beats Debian on documentation.
Well, part of the reason Linux documentation often isn't very good is that Red Hat doesn't treat documentation work as something that should be submitted upstream.
Their incentives favour creating Red-Hat-specific documentation, and this then reduces their users' incentive to improve upstream documentation.
There is a difference between package documentation and system documentation. Red Hat contributes package documentation upstream, but system documentation is by its nature distro-dependent.
Red Hat has contributed work that made distros more homogeneous (cough systemd cough) and excellent package documentation for that work; but also got flak for that...
They also have soooo many good articles (which are helpful not just to RHEL) behind a subscription wall. If you do a lot of work in the rpm ecosystem, they're like the Experts Exchange of Google search, with how many times you see an exact bug report, then you get to the page with a tease of your exact answer, but it fades into the login required bit.
And it used to be open, until Oracle started closing their tickets for paid support with essentially cut-and-paste of access.redhat.com. That's why you can't have nice things.
>I don't know why Linux documentation sucks so much
because you need to pay competent people to do it. As FOSS is made up of lots of volunteers, lots of documentation isn't up to the standard we would want it to be.
Since we're generalizing: most devs aren't great at writing documentation either.
Technical writing is a field of its own and it's important to recognize that. We could ever be so lucky if such writers were as attracted to free software as some developers are.
When Eelco wrote his PhD thesis 20+ years ago, with the first version of nix, it was just an academic project. Now it's a lot more.
Although nix has a very good community, and plenty of contributor activity, there is way more code contributed than docs.
Additionally, very few people are technical writers in the nix community (there is a lot of expertise tho, but mostly on the code side). Therefore we get today's nonstructured docs.
Finally, RH has WAY more money than the NixOs foundation. RH sells stuff. Nix and NixOs are community projects, relying solely on donations. They probably have people whose job is to write docs.
The documentation exists. That's the best thing about it and it's a whole lot better than none. It has been worse too. Compared to Red Hat though, there's just no comparison.
I still don't really understand why being RHEL-compatible as opposed to CentOS Stream-compatible is so important (except in the specific case where you're running RHEL in production, e.g. on desktops, and need bug-compatible pre-production boxes).
Is the documentation for CentOS Stream that much worse? What does being RHEL-compatible get you over and above being CentOS Stream-compatible?
CentOS stream is not versioned. Packages do not move in lockstep. The documentation is good and accurate if you are on the latest version. What do you do six months from now, when some packages have been updated and others haven’t? What doc version do you use then?
Technically, CentOS Stream is versioned. The difference being it is versioned at the major release, hence CentOS Stream 8, 9, and 10.
It is true there are no minor releases of CentOS Stream, but that's due to how it fits in the overall RHEL pipeline. A minor release of RHEL is just an internal fork of Stream at a point in time before release where it essentially becomes "patch only", while Stream will continue on with its developments.
Big big big enterprises outsource IT to big big enterprise vendors, and they benefit a lot from standardizing on RHEL, because they employ people, who benefit a lot from documentation and tutorials and so on.
I would have thought that all the documentation and tutorials would apply equally to CentOS Stream — as I understand it, the only real difference is the schedule for releasing minor patches and bugfixes.
Is it the case that RHEL provides vastly better, more detailed changelogs for minor/bugfix updates (even to the public without an RHEL subscription) and that's what makes so much difference that an exactly-compatible rebuild of RHEL is useful but CentOS Stream isn't?
If I were Rocky, Alma, Oracle and/or SUSE, I'd be collaborating to define our own point-release schedule off CentOS Stream*, and trying to make our blessèd commits usurp Red Hat's as industry standard.
Rocky, Alma, and Oracle cannot do that because they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.
The point releases of a RHEL fork are meaningless unless they are identical to RHEL. If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.
> they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL release.
That's precisely what I'm suggesting they attempt.
> The point releases of a RHEL fork are meaningless unless they are identical to RHEL.
Why? (I'm not trying to be belligerent here — I genuinely don't understand why.)
> If you cannot get real RHEL, your better off with CentOS Stream than an incompatible point release.
I thought CentOS Stream essentially is an incompatible point-release — or rather, RHEL is a point-release off CentOS Stream's rolling release.
Does Red Hat provide that much worse documentation for CentOS Stream than for RHEL?
I guess I just don't understand what is the “secret sauce” that makes CentOS Stream so useless, but RHEL so compelling (or even a rebranded-but-otherwise-identical rebuild of RHEL like CentOS 7).
CentOS Stream and RHEL diverge. (a) many bug fixes are back ported to RHEL 9.x, but not to the Stream 9 at the same time (b) they fix bugs right away on RHEL 9.x, but delay them for a long time (c) some packages in the Stream are from the latest upstream, and many major versions ahead of the same in RHEL 9.x
Yep, one thing I really liked at RH was the legion of professional technical writers they hired. The ones I worked with were the kinda unicorns that combined "understands code and complex systems" with "can express complex technical ideas simply and comprehensively".
That, IMO, is a killer feature. I really miss when consuming docs from commercial providers these days.
Our contract with the Air Force required that we document guarantees from every parts vendor for the servers we built for them that they would keep making those parts for at least a decade. They also demanded RHEL exclusively. It's a great example of how extreme stability is more important than any other question in a lot of business decisions.
> from every parts vendor for the servers we built for them that they would keep making those parts for at least a decade
and do main vendors (amd, intel, nvidia, whoever build motherboards) provide guarantees that they continue production of specific version of product for the decade?
> They also demanded RHEL exclusively. It's a great example of how extreme stability
is there evidence that rhel is more stable than debian?
> and do main vendors (amd, intel, nvidia, whoever build motherboards) provide guarantees that they continue production of specific version of product for the decade?
Yes. Certain SKUs can be available for surprisingly long times. When you make that part of the RFP or whatever, you get models with that guarantee.
For a specific use case where this mattered, my team procured a bunch of HPE servers and storage with a 10 year service commitment with a defined resolution time. So parts are pre-positioned and physical repairs will made within 4 hours. Drivers and such are required to be supported for that time as well.
> is there evidence that RHEL is more stable than Debian?
RHEL releases are fully supported (including fixes etc) for 10 years. Debian targets a 5 year lifecycle.
There’s nothing wrong with Debian. But just like an enthusiast who wants to live in the edge wouldn’t be happy with Debian (because it’s too stable!), a F500 wouldn’t be for their own reasons.
> is there evidence that rhel is more stable than debian?
Well, yes Debian versions are supported for 3 years, RHEL for 10+.
"Stability" means changes, not crashes (although they can be caused by changes). A piece of software compiled 10 years ago will still run today and the systems can continue to get security updates, without needing to change the rug.
> Well, yes Debian versions are supported for 3 years, RHEL for 10+.
if upgrade path is easy and stable, it is obviously more sustainable to upgrade versions every N years, compared to situation when you got 10yo EOL infra far behind mainline with no clear way to support it in the future.
> it is obviously more sustainable to upgrade versions every N years
I've heard this kind of thing before, but it's worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to.
Testing field upgrades takes years and the rollout often takes a year or more. There are hundreds of different teams involved and every one of them wants to ensure they don't miss the thing that bricks a submarine, satellite, transmission line, or IRS portal. If you can do this half or a quarter as often you can save taxpayers tens if not hundreds of millions of dollars.
And in a surprising number of cases the software is never upgraded for the ~25 year or so lifetime of the hardware because the cost of the upgrade is comparable to the cost of buying new hardware. Sometimes that means some poor development team backports security patches for antique versions of DOS or Unix, but in more cases than you'd think they just airgap the computers and hope for the best.
> worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to.
I worked on a government project where new software was being built on COBOL because they had those devs available. No commercial company in their right mind would build any new applications in COBOL, but government is a different animal.
But given the number of COBOL platforms available that have dwindling numbers of maintainers, someone with that skillset can demand a very decent chunk now, I'm told.
It's not that simple. Sometimes you care less about the OS than you care about the app. If your app vendor built against a specific version of an OS, you can't just upgrade the OS. You have to stick with the original OS to keep the support contract from your app vendor.
It doesn't matter if it's _more_ stable. It is stable, it's backed by commercial support from the same company that produces it and there is a financial incentive for that same commercial entity to make good on their promises of support and stability.
This isn't a knock at Debian in any way and has nothing to do about whether or not it's more stable (in terms of uptime) or not.
For specific product lines, yes. There's a list of those parts DoD keeps. Anything off that list we have to get either the vendor's guarantee to keep making them or the supplier's attestation that they have N of them on hand.
In terms of stability, as others have pointed out all that means is "the vendor won't change it and will keep providing it"
> is there evidence that rhel is more stable than debian?
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years (from https://wiki.debian.org/LTS)
That's the right sort of ballpark for the systems my team maintains. We don't run RHEL.
"Stability" in the RHEL sense is akin to ossification: you don't change anything, and then you can't change anything, and then you've got problems. The costs aren't necessarily as obvious as pursuing stability via dynamism, and in any case can often either be avoided by limiting the lifespan of the system as a whole or at least punted on to a successor.
For military applications, the trade off is even more intense: you build things hoping that they'll never be used, but knowing that they need to work when called upon. Stuff that'll be on the front line tomorrow can have a very different set of lifecycle guarantees from stuff that's got a planned life of 25 years but which (from experience) you know will probably still be around in 50.
We are at 500k/hour for at least one system i know of at my current client (energy). Not sure what causes these expenses. It can be missing out on trading, or fines. There may be more of these systems :)
> I'm continually baffled that so many companies follow RHEL compatibility to this day.
Because RHEL, and subsequently it's clones, are a really good server OS. You get updates for 10 years, Red Hat or it's employees maintain a large chunk of the generic-Linux stack, large software support, Cockpit, more modern features when compared to the Debian version at the same time (e.g. dracut, firewalld, systemd, NetworkManager, Podman etc).
Then when you want commercial support, converting to RHEL (or vice versa) it's painless and quick.
Red Hat offers corporate support contracts, while other distros have community or consultant support at best. This is attractive to executive managers in corporations, as they can be seen as investing into a mature technology, and the systems are contractually guaranteed to keep running by a 3rd party, so shifting blame is easy.
Yes, very. I previously worked for RH and there really wasn't a top end of support options. I knew of companies with a contract that had RH maintaining custom kernel patched for them. Another paid for a highly skilled SRE to be in their office ready to help anytime. A small number of companies are willing to pay a lot of money for these kinds of options.
Long-term support is critical. For example, Microsoft excels in that area and has patched its really old products to meet new PCI recommendations such as TLS 1.3, which can actually save a lot of money.
Maybe not, but when your certification requires using supported OS and patching know exploits as soon as possible, then you don't have much distro options to choose from if you want easier time to pass an audit.
This is a common type of reply, and it’s not inaccurate, but it’s also extremely cynical and misses the bigger point. Pay to blame is only a minor benefit, while stability and having a standard snapshot as a target is far more important.
> I can't figure out why RHEL compat is so desirable
RHEL compat per se is irrelevant, it's the 10 years guaranteed maintenance enterprise customers are after, plus a path forward for their third-party software investments only certified on RHEL (because of said guarantees) and internal IT deployment/admin line processes. Despite making the rounds on HN, enterprise and other commercial users give a flying fuck to io_uring, systemd (up until RHEL 7 when they were forced to), namespaces, and other Linux "innovations" which in fact are just annoyances to justify contracts for 30+ years of ongoing maintenance of an age-old POSIX core operating system once developed in a couple of months and praised for its minimalism.
This ommission of the negative really grinds my gears, and I couldn't care less about American Idiom when it literally changes the meaning of the words.
Irregardless is a word.[74][75] Nonstandard, slang, or colloquial terms used by English speakers are sometimes alleged not to be real words, despite appearing in numerous dictionaries. All words in English became accepted by being commonly used for a certain period of time; thus, there are many vernacular words currently not accepted as part of the standard language, or regarded as inappropriate in formal speech or writing, but the idea that they are not words is a misconception.[76] Other examples of words that are sometimes alleged not to be words include burglarize, licit,[77] and funnest[78] which appear in numerous dictionaries as English words.[79]
You know what grinds my gears? Needless pedantry and linguistic prescriptivism.
> This ommission of the negative really grinds my gears, and I couldn't care less about American Idiom when it literally changes the meaning of the words.
Tough luck? Language is like that, idioms especially. Just get used to the fact that not everybody speaks the same dialect of English as you do, and none of them are objectively the correct one in any sense.
You clearly knew what they meant, so there's no communication barrier here. You're being pedantic for the sake of it.
Perhaps I understood, because I have previous knowledge of the idiom, especially when it comes to the "couldn't care less" variation. However someone encountering it for the first time can only go with what is written, which clearly states that the subject "could care less" or "give a flying fuck", when the intent is entirely opposite.
> The kernel is maintained in a source tree rather than directly in dist-git. The specfile is maintained as a template in the source tree along with a set of build scripts to generate configurations, (S)RPMs, and to populate the dist-git repository.
There used to be a stack of numbered kernel patches in the kernel SRPM Source RPM, but now what is the best way to diff centos-stream-9's main branch with Torvalds/git:main? AFAIU kernel distributors must dist patches because GPLv2; packaging workflows are irrelevant to license terms?
https://gitlab.com/redhat/centos-stream/src/kernel/centos-st...
Fedora and many other distros do a lot of valued work, too.
FWICS there are FIPS kernel variants for Ubuntu <= 20.04 LTS (2020) but not 22.04 LTS (2022), and Debian and Ubuntu don't have the selinux policy set that Fedora and RHEL+EPEL have. https://ubuntu.com/kernel
> Would it be feasible to sed-replace the RHEL and/or Fedora selinux and container-selinux rulesets for use with other Linux distros?
> "AFAIU only SUSE can run both AppArmor and SELinux?
> And browsers are running as unconfined in selinux with like all major distros; even on ChromiumOS
Act like you added `systemd-nspawn respawn` to every SysV-init script and correctly formatted the epoch time in the correct column of each of the log files to merge and then logship again.
Conda-forge's GitHub PRs to feedstocks model works, but there are no grub or uboot or selinux-policy-targeted or container-selinux or kernel packages in conda-forge or Alpine linux.
> I can't figure out why RHEL compat is so desirable.
When you're a part of an international research infrastructure which works on the same stack for a decade and half, being supported by RH for free (because of CERN) and creating tons of software at every layer of this research stack over that time period is one of the bigger reasons, but it's not the only one.
I personally use Debian for my personal computers and small servers elsewhere for 15+ years, but when it comes to infrastructure homogenization amongst high thousands of nodes, it's a different story.
The time (some years back now, it was a 5.10 patch and a 5.8 rpm) they mis-backported a perl patch to work around a bug in a deprecated CPAN module for one of their enterprise customers and in the process caused a 2x-30x slowdown of lots of other newer code (including the library that had replaced it in the majority of production environments by that point) was 'fun'.
Took me a couple years to get together a coalition of commercial support customers to apply sufficient pressure that they'd listen when I got the original author of the patch to break out the small words and crayon drawings and explain what they'd done wrong and how to backport it properly.
Happily, they now generally snapshot Fedora's perl builds pretty directly and the current Fedora team have been fantastic to work with as a downstream but it was a spectacular mess at the time and there are plenty of people out there who still haven't forgiven them (I think I try to act -as if- I've forgiven them but I'm not sure I actually have).
>The time (some years back now, it was a 5.10 patch and a 5.8 rpm) they mis-backported a perl patch to work around a bug in a deprecated CPAN module for one of their enterprise customers and in the process caused a 2x-30x slowdown of lots of other newer code (including the library that had replaced it in the majority of production environments by that point) was 'fun'.
That ONE time might have been fun, but with Arch, Ubuntu and so on, you get to have such fun times all the time.
To be honest it's a pretty good track record if you can only remember one instance of botching a backport, it's many years old, and it didn't have any security impact unlike Debian's ssh key generation.
Given I work for https://shadow.cat/ and we do primarily perl/CPAN contracting, consultancy and commercial support (and don't run RHEL ourselves) I remember this one because I had to help multiple customers and probably by the end three digits' worth of companies via community support to work around the debacle.
I suspect more man-hours were lost to the (now reversed for quite a while thanks to the Fedora team) decision to have their 'perl' package only be half a perl install (and to mass report the resulting problems that decision created to cpan authors without ever sending a single patch) but the original subject was things they botched by accident rather than things they broke deliberately.
Though the uninformed arrogance behind the poor decisions and dismissive attitude to the resulting problems, even when they were impacting RHEL support customers, was very similar in both cases.
Had they responded to realising they'd completely broken a bunch of paying customers' primary revenue generating applications by actually trying to do something about it I would have been happy to file the original mistake under "shit happens." As it is, I don't think 'pretty good track record' applies, I'm afraid.
True. The one I remember is when they mis-backported some version of libncurses so it was the v4 ABI but had the v3 soname, but that was like two decades ago :-)
I saw RedHat backport kernel bugs... we had one that bricked VLAN support on certain NIC that was put into Centos 5.
For those that do not know, RHEL kernels are a bit of an abomination with both bugfixes and new features backported, just so they can tell to customers that the kernel version is "stable" (which is a bit of clown fiesta as Linux doesn't break backward compat on kernel level anyway) and that was one of the things mis-backported and not even tested, just copied bug from upstream.
.... which half a year later got backported to Centos 6 too...
They also do nasty shit like re-enabling/backporting legacy ciphers to software (like OpenSSH) that removed them or disabled them in code base. So you go thru audit, there are points about not using this and that now-insecure ciphers, but you look and see "hey, this one was disabled by default in <current version of OpenSSH in RHEL>, we're fine", and discover that you're NOT fine because RHEL in their infinite wisdom enabled it by default because some old legacy customers needed it and couldn't be bothered to edit their own configs.
After near-two-decades I want to get off Mr. Red Hat weird ride. Just fucking use Debian
"Nobody ever got fired for buying CentOS". Till recently.
In terms of actual, material benefits I believe it's simply because transitive "certifications" (hardware, support, continuity, ...) that are implied by Red Hat's corporate presence.
To add to this from personal experience; we sell proprietary software that runs on multiple platforms. Our market is broadcasters, CDNs, telcos, media companies.
We target Ubuntu and Alpine, but also ship CentOS/Rocky/RHEL/Oracle/Alma and Windows. Even though customers rarely ask for the latter targets, we need to offer those simply because we wouldn't be taken seriously if this major market segment were absent on our website.
I'm not totally surprised as most employee's don't know how they fit into their current organization as a whole or how their organization fits into their current market, never mind other companies and vendors. Its along the same lines as people evaluating company licensing and equipment costs as if its coming out of their pocket.
Its almost as bad as people believing that Walmart, Target, etc are closing their stores because of "so much theft" as if shrink budgets weren't a thing. Having a loss prevention department is a misnomer, its a paperwork and accounting department so that the losses can be written off to the IRS. These places have KPI's for everything and probably know the locations where they have a store but a majority of people are ordering online. I'm sure their lease has some notion of financial hardship which "theft" falls into allowing them to exit the contract early.
> Its almost as bad as people believing that Walmart, Target, etc are closing their stores because of "so much theft" as if shrink budgets weren't a thing.
I may not be understanding your point here, but having a shrink budget and closing due to theft aren't mutually exclusive.
It is possible for theft to exceed the shrink budget and make a store too costly to operate.
You are most certainly correct and I suppose without the actual numbers its a bit of speculation.
My main point was that there is no additional cost, even if you exceed the shrink budget. The losses are all written off because with a loss prevention department you have shown, to the insurance company /or IRS, that you are putting in a reasonable effort to deter theft. Stores don't want anyone to actually stop people for a number of reasons the main one being they are writing the loss off or being reimbursed.
An employee getting harmed, the thief getting harmed, employee's getting summons to court, another customer getting harmed are all more costly than just documenting what was stolen. Even in the cases where they build up evidence so that the amount gets close to grand larceny is just paper work. They already have people and technology deployed to do the work its not a new investment.
I did a bit of digging and while "theft" is listed as one of the items "reduced foot-traffic"[2] seems to be the main culprit. They throw out some fancy percentages but the quoted stats seem to be from 2015 and theft is only 1% of their annual revenue[7]. It would be interesting to see the raw data.
Just like McDonald's: it isn't the best meal you can get, whether in quality, nutrition or taste. But you will know what you are getting, even when you appear on the other side of the planet. You would be better off with a meal in a some local restaurant, but that one is unknown to you.
So corporate will get something they know for their people. Most of them have zero interest in exploring better options, just want their job done today and go home.
You are correct on this observation. The answer is most people/organizations don't actually know if they need to be RHEL compatible. Outside of any places that have a compliance requirements, where saying you are RHEL compatible by using CentOS is the easiest path to checking a box. However if you are operating in an arena where compliance certification is needed you would just pay for RHEL and charge the cost to your customer.
We paid for support for RHEV/RHV for a number of years and it was useless. You ended up troubleshooting most of the work yourself and in our case we could have just run Ovirt and skipped the whole inventorying and licensing of cores.
The "having someone to blame" or a support contract baffles me for open source. Why advocate for using open source if executive suite is concerned with downtime? They aren't passing the savings back to you and what did having a contract save you if you have to get director or c-level people on the phone to escalate? Presumably they are getting paid more per hour than a number of other people. You have now paid support, plus Dev/Ops troubleshooting, then getting an executive involved. Not to mention how big does your organization need to be for a vendor to consider "your" issue to be a real issue to them.
The back porting and LTS that most people talk about seems to be out of place for a time in which security is now falling under insurance and you need to be regularly updating anyway. Every security audit has one of these "banner shows this version, oh but wait did you check OVAL, or its a back-ported version" conversations. Wasn't this the point of all the fancy DevOps tools, workflows, containerization, etc. Shouldn't you be able to roll out new packages and OS versions quickly since you have all your automated tests implemented?
Right, but I think the OP's question is why are you using RHEL compat instead of just getting licensed RHEL. In your example a company is already fine with paying full price for major engineering applications why wouldn't you do the same for your underlying OS.
> I can't figure out why RHEL compat is so desirable.
If you cannot figure out, then you are not working with Linux, despite 30y+ of experience.
Big Companies need certifications, maintenance, support and compatibility is necessary. Specially companies running linux in mainframe, or for instance, delivering embedded devices like storages or medical devices
Why would you be dependent upon CentOS(RHEL compat) if you are in those industries? If you need certification and LTS then pay for it by purchasing RHEL licenses.
It seems very silly for people to be getting upset now that a free OS hasn't taken their business considerations to heart. Unless of course you were going for the model of charging everyone enterprise rates for your devices/software/work/etc and pocketing what you would have to normally pay in enterprise licensing because its a "community" OS, which everyone is free to do, but these are the risks that come with that.
One scenario that I can imagine, is for development environment. People had CentOS as dev environment and deployed RHEL. Or ran CentOS guests on RHEL hosts (VM or Docker)
Thats a good point. Looks like RedHat considered this and offer free company/professional developer RHEL images for non-production use[1]. In 2021 they allowed zero-cost licensing for individuals[2].
How exactly is the dependability and stability determined? By back-porting you are already changing the original version of software. What then becomes the difference at that point verse tracking the actual project version? Assuming both go through regular testing.
It seems more straight forward to be able to look at a change log from the application, lets say httpd, then to go search for cherry picked back-porting changes.
I just picked httpd since its a common application and as far as I can tell all the updates are minor release numbers. If you have another example that would be useful to see for consideration as I'm genuinely curious which applications change so much that people are dependent upon back-porting for stability.
The 'stable version but we backport patches' mantra
Just because Redhat handles this poorly (like pretty much everything), does not make the model bad.
For example, almost every single security update on Debian, is backported when not handled by upstream. And there is a lot of that.
You lose so much stability, if you track all-new. In fact, you literally spend more time chasing underlying bugs, instead your bugs, and dealing with api changes, if your stack is bleeding edge.
When enterprise-sized IT departments wanted to switch away from cumbersome, expensive commercial Unix systems, RHEL was there to step in. As a result, it became the default enterprise Linux distribution and vendor.
The reason why it is still special is because even in 2023, if any commercial enterprise applications and hardware support Linux at all, it is generally only RHEL.
Hell, even in my homelab I’ve moved past wanting new shiny. I just want NFS to play nicely and stop silently failing with nary a log message.
Playing around with distros and bleeding edge is fun until you just want the OS to get out of your way so you can do stuff. Then you regret your decisions.
So if stability is a strict requirement why are you dependent on an OS that you have no contractual obligation with? I mean if the community OS model was working for the CentOS team why go under the RedHat umbrella? My guess is going to be people demanding enterprise support without enterprise licensing costs[1].
"In 2014, the CentOS development team still had a distribution with far more marketshare than resources."
> This investment will preserve the flow of innovation for years to come and ensures that customers and community alike are not subjected to vendor lock-in and have genuine choice tomorrow as well as today.
Wow, that's pretty rich from a company that has made good money from vendor lock-in. I'm still bitter when they drastically increased our SLES-prices for academic institutions, that was probably around 2010/11, and I've never touched SUSE since. That they now fork RHEL is pretty funny, since I vividly remember talking to a SUSE sales rep at that time, and I said we would now switch away from SLES to Scientific Linux, and he called it a "parasite project". Of course, you are allowed to make money off FLOSS software, but please, get off your high horse when others do the same.
Don't get me wrong, I am very happy with this announcement, however it bothers me slightly when I see these kind of announcements with the tone of "we love open source and we want to give this to the community" when the rationale for this probably was "RHEL is going to lose a bunch of customers and we can profit off of that". If it was a non-profit they might convince me but as a Linux for enterprise-kind of company I am not fully convinced behind the motivations.
Likewise it grinds my gears when people think that a company should just do things to do them. At the end of the day they need to make a profit to be sustainable, to pay employees, to perform R&D, keep the lights on, etc. Altruism isn't enough on its own.
Why not both? Capitalizing on customers who need a solution while also helping the community? Not preparing for an influx of new business is a foolish business decision.
That is the freemium model and more or less the model that I thought the open source community had long ago agreed was acceptable. Open source development for free is cool with what spare time you have, but at a certain point you have to pay your own bills to keep a roof over your head, food in your belly, maintain your health, and actually be able to enjoy your life. Value added features and support have long been the way open source companies have been able to do that.
Not sure if the comment was addressed specifically to mine. If it was: I am OK with companies trying to make money, that's what they are for. It was more about how they phrase things. If you are a company that truly has open source as a driver, then make whatever claims you wish, however if your company's main driver is revenue (as SUSE likely is) don't make business announcements with "WE LOVE OPEN SOURCE" as your main rationale, just say "there's an opportunity for our business to grow" or any other corporate wording.
What is this supposed to be? SUSE responding to Red Hat obstructing RHEL clones by creating a new RHEL clone? Or are they forking RHEL into something that will try to remain compatible, while not being a clone?
The latter is what Red Hat seems to want: a broader ecosystem that competes with Debian on community, while allowing Red Hat to sell RHEL with an "original recipe" sticker.
SUSE coming out with an announcement that effectively cannibalizes its existing enterprise distribution kind of makes Red Hat's move look risky, but perhaps not dumb after all.
> The latter is what Red Hat seems to want: a broader ecosystem that competes with Debian on community, while allowing Red Hat to sell RHEL with an "original recipe" sticker.
This depends if SUSE will use stream as a base or not.
But Oracle and almalinux will probably base on it with their own patches / support.
> SUSE coming out with an announcement that effectively cannibalizes its existing enterprise distribution kind of makes Red Hat's move look risky, but perhaps not dumb after all.
They already have SUSE liberty linux, which includes support for RHEL and CentOS.
Yea, we are going to destroy RHEL by doing what they want us to. RH wants more people using and building distros off of centos stream instead of using RHEL clones. I don't think they see this as a negative, especially since it devalues suse in the process because they are basically admitting RHEL is more desirable.
Oracle today is what Microsoft was 15 years ago. It would be shocking to see Oracle resemble what Microsoft is today to open source, but I'm not holding my breath for it.
"Finally, to IBM, here’s a big idea for you. You say that you don’t want to pay all those RHEL developers? Here’s how you can save money: just pull from us. Become a downstream distributor of Oracle Linux. We will happily take on the burden."
I still don't forgive SUSE for buying Rancher and then unceremoniously killing k3os. They just left the website up and everything, made no announcement, made no attempt to help the community take over, just left the Github repo to rot: https://k3os.io/
Hard to have confidence in SUSE's commitment to another open source operating system side project after that. SUSE's announcement at the time:
Like SUSE, Rancher is 100% open source and equally as passionate as SUSE about true open source innovation, community empowerment, and customer success. SUSE and Rancher share the same goal – happy and satisfied customers.
Could Alma, Rocky, SUSE and Oracle team up, coordinate with each other, pool their resources? (The announcement mentions Rocky and SUSE working together, but not Alma or Oracle.)
I wonder how IBM / RedHat might react to that, were it to happen.
Oracle and almalinux would probably base on Stream with their own patches.
The maintenance burden will be much smaller than a full fork, as red hat will still be the main contributor.
I had a feeling SUSE would smell blood in the water when Red Hat shot itself in the foot. I don't know what Red Hat was thinking. They grievously misread their position in the market and are far more vulnerable than they seem to have realized.
I've been saying RHEL is only relevant because it's an agreed-upon standard with an adequately slow rate of change. Entities want to be able to easily use code and documentation from elsewhere, and easily hire experts to support it (1). Some of that is inertia driven, but nothing else about it really matters. Thinking they can generate their own network effects is a really classic IBM blunder (2).
Much of RH's historical relevance was basically "RedHat exists to launder Linux for the National Labs" and that basis is not a terribly deep moat - hell the big physics centers maintained their Scientific Linux fork for 16 years before fully shifting onto CentOS then getting rug-pulled... which is not the kind of relationship maintenance you want to do with the customers whose network effects create your value proposition.
The death condition for RH is if the Alma/Rocky CentOS community successors and the Oracle type commercial clones all agreed to a different reference point for "Standard Enterprise Linux"(3), and the big producers of code people want to use (your large Physics centers and and NIH scientific compute projects, and/or the shared infrastructure like OpenHPC) tracked that other reference point, suddenly RH brand EL is mostly irrelevant.
SuSE running their own EL fork is interesting because there was not an obvious successor reference point to coordinate the non-RH ELs and/or major users if they have trouble tracking RHEL, and now there kind of is - it'll be really interesting to see what happens if there is any divergence.
(1) The support point is "why not Debian," they've never had the commercial support partners, certs, etc. Having that was a huge part Ubuntu/Canonical's proposition, but they never really got the enterprise/scientific compute/HPC penetration that RH has.
(2) Ya'll remember PS/2 and MCA (Micro Channel Architecture)? IBM was gonna take back control of the PC industry by setting an new (much more license controlled) standard and... the PC cloner industry set up outside coordination points and end-ran them with EISA/VLB and eventually PCI.
(3) It might not get called SEL for SuSE or Standard because that would be confusing/trademark problems with the adjacent-industry Schneider Electric. I half jokingly translate the "Enterprise Linux" terminology into "Srs Bsns Linux" some of the time anyway, so the name game will surely be funny.
This is very positive news, I wonder though how far will compatible mean? My biggest problem with opensuse is the lack of cockpit support and integration that RHEL has.
Also that they use apparmor instead of selinux as default, I wish that selinux would become the standard MAC, with really good tools (cli and gui alike) for handling selinux policies.
I’m not sure it’s positive, they are very light on details. If this is a hard fork, is it really going to deviate from RHEL? Is a $10m investment enough to carry an enterprise distro for a decade?
I’m a little skeptical about this right now, but we’ll see how it pans out.
That I look forward to, if they can make SELinux and cockpit work flawlessly I'm finally going to have the perfect distro I ever wanted (although I'll admit I'm not sure if NetworkManager vs SUSE own network manager is better).
It was only a year ago that Oracle was attempting to argue in front of the Supreme Court of the United States that adopting any kind of preexisting API was copyright infringement, and also shouldn't fall under fair use.
To hear them talking about "freedom" and "openness" only makes me chuckle at their incredible hubris.
If they believed in these words they wouldn't have closed off Solaris (to everyone, including their customers), kept ZFS in licensing purgatory for their own benefit, or attempted to victimize all of FOSS in pursuit of shaking down Google for loose change.
I'm not exactly thrilled with the recent series of events, but I somehow do not find Oracle's attempt at shaming very convincing.
Companies using RHEL or SUSE and paying for support usually don't switch. This is one of the rare moments where SUSE has a real chance to expand their market share in this space.
From https://www.suse.com/c/at-suse-we-make-choice-happen/
"It goes without saying that SUSE remains fully committed to SUSE Linux Enterprise (SLE) and Adaptable Linux Platform (ALP) solutions as well as the openSUSE Linux distributions."
As a long term Leap and Tumbleweed user, I trust the openSUSE community to keep producing a nice distro.
Would a migration path be feasible, the fork getting some "stuff people coming from openSUSE would need" added/ported? Then it might effectively be as much a merge as a fork. Of course if that did happen, I'd expect the "people" in "stuff people need" to be specifically the subset who happen to be paying customers. Not sure if there are many users left outside that subset?
Whether you pay the for SLES or their fork of RHEL probably does not make much a difference to them. And for customers who run both SLES and RHEL (not sure if that is a common scenario, though), having a single vendor to a deal with is probably a plus.
It is announced last year [1] called SUSE Liberty Linux . I think priciple converting current RHEL/CentOS repository to own inhouse repository like Oracle did [2] or MS did [3], and get the money from providing subscription for support and security.
I knew suse used rpm packages, but I always thought they were their own... good to know they are putting in the work to distance themselves from the IBM mess.
They are, their distro is their own - this is them announcing a RHEL fork as well as their in-house distro.
You'll find SUSE Linux Enterprise in quite a few places in Europe but their penetration in the US has always been kinda pants, so providing a compatible alternative to RHEL will hopefully be a net win for them commercialy as well as a net win for the community.
Yes, they used the RPM format with their own tool (Zypper instead of DNF/Yum), but packages weren’t (necessarily) compatible with Fedora/RHEL as far as dependencies and such.
I have seen independent projects provide rpms that are supposed to work on both RedHat/Fedora and SLES/openSUSE, with some caveats as to what versions of each are supported/tested for.
Sure. Really depends on, well, the dependencies. The rpm command shipped with all those distributions should be compatible with the format of any recently created package.
But you can run into snags if you have a dependency that doesn't exist on the target system or its repos, or if the packages are named differently, the pre- and post-install commands have assumptions about the system that aren't true on the target distro, etc.
But if all the package exists for is to drop a few binaries on the system, it can be fine. Especially for things like proprietary software that's going to just dump a bunch of stuff into, say, /opt and will only break if the kernel or glibc are spectacularly old or too new, etc.
Sometimes you can even get away with using "alien" or similar to convert Debs to RPMs if it's only packaged as a Debian package. Sometimes.
He he, I tried using alien a looong time ago, without success. In retrospect, I was young and naive, only had a rather vague idea of what I was doing. So I can't say for sure if it was alien's fault or if I was doing something stupid.
Setting aside the implications of the move Red Hat made for a moment, can we all just appreciate what a perfect storm of terrible messaging they've settled into with this one? From what it sounds like, the announcement surprised a lot internal associates not working on RHEL that are now falling into this trap that Red Hat created.
Back in the old RH Linux days, I remember SUSE had as much market share as Red Hat. It was actually the distro that people suggested I should use because it was more polished.
But SUSE was bought and sold a few times to shady companies, wasn't it? My memory is blurry but this might explain why people don't immediately think of it.
"[SuSe] ... announced it is forking publicly available Red Hat Enterprise Linux (RHEL) and will develop and maintain a RHEL-compatible distribution available to all without restrictions."
How will they confirm that their fork is compatible? Probably using RedHat supplied UBI docker/container images. So they're just becoming another add-no-value clone. Wow, give whoever came up with this idea a nobel peace prize.
Instead they could focus on their own offerings which add value/different value propositions than just being a clone of RHEL. I can't believe folks would be okay with companies coming in and undercutting your validation work -- even if you see RHEL as anachronistic and obsolete in teh world of containers and such it still has value for some folks for its RHEL-ness -- and then coming in and selling clones undercutting support and other licensing/revenue streams to pay for the QA/R&D/devel, etc.
> How will they confirm that they're fork is compatible?
The only thing they need to ensure right now is that their stable release remains compatible to existing RHEL. Everything needed for that is around.
Going forward, maybe "RHEL v+1 compatible" doesn't even matter anymore (to quote that press release: "CIQ is thrilled to collaborate with SUSE on advancing an open enterprise Linux standard.") RHEL became the defacto "Enterprise Linux" because everybody willingly handed them the control over the direction Enterprise Linux takes (including, but not limited to, by merely repackaging their work).
As long as that new community system (Rocky intends to work with SUSE according to that article) remains RHEL9.2 compatible, they might be able to force IBM to adopt the community's idea of an Enterprise Linux for future RHEL releases. Keeping some "RHEL9.2 mode" around indefinitely (next to a further developed platform for contemporary workloads) is relatively simple with containers and the like.
IBM might have just killed the one thing that kept RedHat dominant in that space: the goodwill of nearly everybody else to let RedHat lead and not rock the boat too much themselves.
i may be completely wrong on this (and i hope i am wrong) but i have the impression that licensing is the only thing really profitable in the corporate world. i believe support only works if it is combined with licensing because the margins are much lower otherwise. red hat could not pay for all the engineers they have now on support contracts alone.
Could be. It very well could be that the whole RH model dies with the success of clones. I was more-or-less just spitballing. But what are they to do? I guess double down? And try to increase their value add but then if it comes from software quality or their QA/validation that goes into making RHEL the clones will get it for free too
i don't think the clones themselves are the problem, but the commercial support available for clones is taking away business from red hat, and that is where the conflict lies.
in a way it is actually a similar problem with amazon and the like offering commercial support for databases.
that is an inherent problem in the FOSS model. on one hand it is great that anyone can offer support for any FOSS software, but when big companies offer that support without giving back to the projects themselves they are undermining the sustainability of the projects.
but i don't have a clue how to solve that, other than everyone just being more considerate and not take advantage of the developers.
> "i don't think the clones themselves are the problem, but the commercial support available for clones is taking away business from red hat, and that is where the conflict lies."
exactly what i mean when I say 0-value-added-clones because they then turn around and sell support on the clones which seems seemingly unethical to me somehow -- though i am still working through that thought process.
I would not want to be RedHat here actually. It's a tough situation.
most of the clones themselves are not selling support, at least not at the scale that would be a problem for redhat. clones do add value because they allow small companies to use a version of RHEL without having to pay for license/support they can't afford. when these companies grow they then can become red hat customers.
at least that was my understanding of the goals behind centos and also why redhat took it on and made it part of their products.
the problem is not all third-party support, but only companies that compete for large corporate contracts like oracle.
when a company hires me to install centos or some other clone for them, and then calls me when there are issues with their servers, then technically i am selling support on clones. but i very much doubt that in that case i am taking away business from redhat. heck, most likely i would have been the one who recommended centos to them, when i could have recommended debian as well. these companies come to me because they trust me, not because i am selling them a big brand on the cheap.
RedHat also built their business on the backs of other peoples work, sure they make contributions back but I’m sure they’re minuscule when compared to profit. They read, understood and accepted licences for the products they on-sell and are now throwing their toys out of the pram when the free market does what it was always inevitably going to do with their in-house tech.
Totally agree, that was my first impression after reading. If anything, it seems antagonistic and petty. I mean, why would you not just focus on your own product rather than put resources towards this strange 'Look we're helping! Red Hat Bad!' stance that offers no value to anyone.
SUSE has customers with mixed-distro deployments that were supported by SUSE Liberty Linux. Those customers might have had questions about what happens now. This seems to be one part of the answer.
I always assumed that SUSE was rolling their own rpms, but were they? Maybe they were somehow dependent on RH to the extent that this move now makes sense also for the rest of their business?
They do maintain their own RPMs - but they also offer support for CentOS / RHEL for customers who use SUSE and RHEL. Their hand me be somewhat forced, as they have to continue to fulfill these contracts.
Name one distro apart from the EL clones that offer MAC policies for the software in the core repos. SELinux in Debian is a joke, so are the AppArmor policies.
The tangle of suse/opensuse is confusing to me, but I know that the opinionated rolling versions like MicroOS, Aeon, and Kalpa standardized on SELinux. And I know that there are policies for both AA and SELinux for at least some software in the repo.
This is just a weak PR statement. Alma and Rocky already revealed that these things are not trivial to maintain and I fail to see beyond pure fork how on earth would SUSE maintain RHEL compatibility and avoid litigation from IBM at the same time.
And then SUSE might be sold off again to some predatory company similar to IBM. What's even the point then of not using pure community distros like Debian?
Red Hatter here, but just my personal opinion. I don't think there would be any litigation. We can terminate accounts for people downloading SRPM's to redistribute them but we can't stop the redistribution itself. There is nothing illegal about making a RHEL clone minus our trademarks.
Correction, you're legal team thinks you can terminate accounts that choose to exercise their rights. That theory has yet to be put to an actual legal challenge. Will be interesting to see the ultimate outcome.
Support and long term stability. You can hire a sysadmin to do everything manually, but it is worth the money to a lot of big businesses to have somewhere to call when things get screwey. Also having a server that doesn't need to be turned off for ~10 years is a huge W for businesses as well.
I've always had a fondness for SuSE. My first experience with Linux was a boxed set of SuSE 7.3 (released in 2001 with Kernel 2.4!) purchased at a Borders book store in Glendale, CA. My dad taught me how to quit vim, use make to install software, etc.
I haven't used it since then - Debian convert thru and thru - but I keep meaning to take Tumbleweed for a spin as I hear great things about it.
I switched to Tumbleweed last weekend. Coming from Fedora, the installer was a bit confusing and the distro on the whole does seem to lack a bit of polish. But overall it was quite painless.
I'm with you, that would be cute! But that might be too on the nose...However, green beret or olive cap might be cooler! Either way, yeah, they should name it something related to headwear with a green-ish color.
I guess the unwritten part of that press release is the fact that Red Hat are taking RHEL in some sort of proprietary direction? Is anybody able to TL;DR me an explanation of what's going on?
Red Hat announced that they are no longer providing updates to the downstream repo at git.centos.org and blamed that a lot of people are taking the sources and not contributing back, essentially just rebuilding and rebranding "their code".
To obtain access to the git repo you now need to subscribe to Red Hat Developer Portal, but there are other ways to obtain the package sources as Rocky Linux is going to do in the future.
This move by RH is not proprietary per se but it does indicate that they are growing hostile towards open source as a whole because it is affecting their business model, and since they were acquired by IBM, now they only really care about the revenue RHEL generates.
> essentially just rebuilding and rebranding "their code".
I don't think that's the bit that they're angry about, it's the aggressive undercutting of their support contracts, from people who are essentially rebranding their distro.
Red Hat (along with IBM) still contributes an insane amount of open source code that they appear to happily upstream.
On the Code Radio podcast[1] there was some commentary on Red Hats move, and I'm kinda on their side. Why is it that we're unhappy with Red Hat wanting to be paid for their work. You're getting all the open source benefits, if you don't like RHEL, or Red Hat that's fine, you can still benefit from their work, but you might want to pick a different distribution.
And I can see the point, people are upset that Red Hat would like to get pay and yet they expect to be able to profit from a SaaS platform they build on CentOS or Rocky Linux. For some unknown reason, Red Hat is the only company that's not allowed to profit from their work, despite them contributing to everything from the kernel to X, happily upstreaming and maintaining stuff that few others want to deal with.
> I've started to see 2023 as the Year of Freeloader Ousting
I'm ... oddly actually not opposed.
Things being "free" has distorted a lot of markets and ossified them--even in open source (See: GitHub, for example).
If things actually cost something, people can get paid to do them. In addition, things that cost real money don't have the same pressure to go for giant network effects in the hopes to get a lock-in monopoly. It also sidesteps the advertising pathologies.
> Red Hat is the only company that's not allowed to profit from their work, despite them contributing to everything from the kernel to X, happily upstreaming and maintaining stuff that few others want to deal with.
no, this is not the issue. The issue is that there is a megacorporation behind Red Hat which claimed they wouldn't affect any RH decisions and RH would be the good ol' Red Hat we always knew. And they have shown this to be false.
As you said it yourself, Red Hat has a legacy of contributing to open source and this recent move to somehow paywall access to the updated git repo is literally going against their own legacy.
As I see it, very little is actually moving "behind a paywall" (not trying be demening, just lacking a better term). Is systemd moving behind a paywall, no. Neither is Podman, Ansible, kernel patches, X11 patches and pretty much everything. It will all be available in CentOS stream and Fedora or upstreamed... But that's not what people want, they want RHEL, they just don't want the cost. Red Hats contributions was never about what went into RHEL, it is about what they upstream and maintain for the benefit of all distributions, which is a lot more than many believe.
The only thing you cannot get, without a subscription, is the source RPMs and the bit of tooling they need to build RHEL for their customers.
For what I've been hearing, and reading, this is a Red Hat decision, not an IBM decision. If we trust that or not, well... Still I'm not seeing how their contribution to open source isn't intact.
> and blamed that a lot of people are taking the sources and not contributing back
Yet when commercial entities take code and don't contribute back, it is “just how things work”.
While I appreciate that RedHat has been a good player overall compared to many others, this comes across as the kid at school happy to throw icy snowballs at everyone else moaning because they got hit by return fire. How unfair of the open source world using open source licenses the same way the commercial world does.
They contributed because it's in their best interest, and they also took down a route with Systemd that went against the philosophy of nix systems. If we're not careful we'll end up losing control of Linux or large parts of it to profit seeking corporations that don't have the free and open software movement on their agenda at all.
I didn't at all say they had been perfect community members…
Also, they didn't exactly force systemd on everybody. Must as you might not like it (I'm not its biggest fan, but mainly due to being old and familiar with what came before). Other options are still commonly available if it offends you overly.
They chose a business model built on open source, and now they don't like it because they can't suck enough profit from it. Maybe they should just build their own proprietary operating system from scratch.
> […] essentially just rebuilding and rebranding "their code".
Thereby creating an eco-system of RH-based systems that people learn about and get familiar with, so when it comes to going into production the natural default is to just purchase the official RHEL for those systems.
I think RH/IBM are being short-sited on how useful the free eco-system is.
This gets stated a lot, but I don't think it's actually true and RH has stated they don't see an actual benefit from this. Plus, they already have that ecosystem that isn't just free-version of RHEL with CentOS Stream and Fedora.
Note that the last paragraph is a supposition that is not rooted in reality. Red Hat is still doing upstream first development and is still mostly independent from IBM (who didn't participate in this decision).
Even if that was the intended meaning, it's quite an extrapolation that Red Hat is "growing hostile towards open source as a whole", especially since people say that of Red Hat roughly every two years.
They abandoned CentOS, created CentOS Stream which has its own set of issues, mostly you need to send an email to the actual package maintainer to remind them to update the package. And now the package sources are held behind a subscription portal.
This is being hostile towards open source. And as someone else pointed out, the reason we're mad at Red Hat is because they were built because of the open source community, but now they've shown that since their acquisition by IBM, their goals have profoundly changed - they are now seeking to be more profitable, if it's by IBM's orders or not, we can only speculate, but there is a correlation here and it's not just a coincidence.
No, that's not being hostile towards open source. It's being indifferent towards people who want all your beer to be free.
Red Hat is contributing upstream of RHEL in three different ways (actual upstream, Fedora, CentOS Stream). Asking for even more is nothing but entitlement.
> there is a correlation here and it's not just a coincidence.
There is obviously a time correlation, but whether it's a coincidence or not you cannot know.
And the correlation becomes a lot more murky if you consider that Red Hae was allegedly causing lock-in or being hostile towards open source when Lennart started systemd (and for multiple other episodes in the systemd saga), when they stopped distributing the broken out patches of the RHEL kernel, when they acqui-hired CentOS, etc. And also people gave Red Hat 3 years of life when IBM announced the acquisition. Perhaps y'all need to tune your crystal ball...
> Red Hat is contributing upstream of RHEL in three different ways (actual upstream, Fedora, CentOS Stream). Asking for even more is nothing but entitlement.
I heard that a lot of RHEL packages are actually built from Fedora repos, which are maintained by voluntary contributors. Did Red Hat ask those maintainers if they are okay with providing the source for their RPMs behind a paywall? They didn't, and some Fedora maintainers even orphaned their packages as result of this change.
Like someone said, when big companies use free software and give nothing back, business as usual, but when it's the other way around suddenly it's unbelievable that people are taking products for free and not giving a single cent back to those same companies that exploit FLOSS!
I don't understand how can someone back Red Hat and find it totally okay that a company that was built on open source and essentially became what it is today because of the open source community that it created, is now giving a huge middle finger to that same community that made them what they are today.
> I heard that a lot of RHEL packages are actually built from Fedora repos, which are maintained by voluntary contributors
Most RHEL packages are at least co-maintained by paid Red Hat employees. Bring numbers please.
> is now giving a huge middle finger to that same community that made them what they are today
Oh, give me a break. Stop hiding behind open source and just admit that you want the free beer. You want all the beer to be free more precisely. While Red Hat is not only contributing a lot back to the community, probably more than any other company in existence, it's giving away not one but two distros.
They're completely within their rights as stated by the GPL to do this.
They're also placing themselves into a niche; not sure if they care. Aside from production RHEL installs using the clones and not making them money, they're also trying to prevent people from running their distro for free to learn it. That will raise the price of RHEL admins, certified or not. And maybe reduce even paid installs.
That's their problem IMO. What I really don't like them for is supporting Poettering. Only yesterday I had to disable parts of systemd because it insisted on using dhcp on a network card I wanted a static IP on.
Calm down. Don't ascribe to me things you made up in your head. Also it would make communication with you easier if you didn't write like you're on 4chan, and wrote your question formulated like a proper normal question.
Unsubstantiated claims from a single ex-employee. If the claims had merit he should have taken his evidence to the German government instead of a blog rant.
Ignoring it is the correct move. They aren't serious allegations, otherwise they would have been made in a serious manner.
The guy claims that he was wrongfully terminated for antisemitism in Germany of all places. Do you really think the German government wouldn't take that seriously and investigate? But all he decided to do was blow hot air on his blog, because his allegations are nothing more than a cynical lie meant to hurt his ex-employer.
He didn't wash his hands and move on, he took to his blog and tried to spread the story around the net. If he were serious he would go to the authorities.
Actually, are there companies which offer "corporate, RHEL/SLES-like support" for a BSD distribution, or FreeBSD particularly? That's also a niche I wish we could see.
There are already excellent libre systemd-free distros, with release cadences ranging from rolling (Guix) to RHEL-level glacial (Slackware). That's not a hole in the market right now.
It's somewhat of a whole in the market for distributions with commercial-corporate-handholding.
But you're right in that a company like SUSE could, instead of introducing a new distribution, decide they're "adopting" an existing FOSS distribution (systemd-free or otherwise) and offering hand-holding, call-us-any-time support for corporations deploying it.
Last I checked the most popular container distro is Alpine; the slimmer options definitely have their place. But then Guix is the opposite of a slim distro...
According to LinkedIn Dirk-Peter started at Suse 3 months ago as CEO and worked for Red Hat for 18 years and was a Senior VP at Red Hat.
I think this move of Suse could be a credible threat to IBM / Red Hat's RHEL.