SUSE is forking RHEL
suse.com
suse.com
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.
If there is a left over of Red Hat branding, you'd have a hard time proving any kind of purposeful infringement.
Both Red Hat and SUSE distributions make it easy because internally both companies need to do the trademark swap in their own engineering pipelines.
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.
One is easy. The other isn't.
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 )
$ 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)
$ cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)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
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.
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.
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.
For the average enterprise switching from SLES to SUSE RHEL means that update will happen in 5-7 years
I've been migrating to Ubuntu or retiring systems for the last two years and still not done. Hoping to be rid of RHEL 7 before updates stop.
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.
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.
RHEL, either officially paid for, or via CentOS / Oracle Linux, is everywhere though, gub'mnt, private, academia.
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.
Really smart.
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.
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.
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.
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.
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.
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.
But are the contracts actually useful? I wager that to have support from Red Hat is really useful beyond what you may view as "corporate politics".
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).
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.
That ONE time might have been fun, but with Arch, Ubuntu and so on, you get to have such fun times all the time.
I can’t count the number of times some rando Microsoft patch has boned a massive global infrastructure.
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
Two alternate kernels will restore most missing drivers, El Repo or the Oracle UEK.
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.
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.
Or perhaps they "don't give a flying fuck"?
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.
Sorry for my choice of words, you may be right after all, English isn't my native language. But of all idioms, yours isn't without irony either ;)
> 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.
https://en.m.wikipedia.org/wiki/List_of_common_misconception...
This specific case has been addressed multiple times by an authority. https://www.merriam-webster.com/words-at-play/could-couldnt-...
Are there time-to-patch metrics for comparison with and without stream as compared with IDK Fedora git?
Rpms/kernel explains: https://src.fedoraproject.org/rpms/kernel :
> 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.
Here are fedora's kernel patches: https://gitlab.com/cki-project/kernel-ark/-/commits/ark-patc...
RHEL <= 9 has kernel-lt (Long Term) and kernel-ml (mainline) kernel patchsets and packages: https://pkgs.org/search/?q=kernel-lt https://www.google.com/search?q=kernel-lt+kernel-ml
Notable Red Hat Enterprise Linux derivatives: https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux_deriv...
List of commercial products based on Red Hat Enterprise Linux: https://en.wikipedia.org/wiki/List_of_commercial_products_ba...
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
From https://news.ycombinator.com/item?id=36480033 :
> 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.
containers/container-selinux: https://github.com/containers/container-selinux/tree/main https://src.fedoraproject.org/rpms/container-selinux/blob/ra...
> Which distro has the best out-of-the-box output for:?
systemd-analyze security
SystemCallFilter=@basic-io
SystemCallLog=~@basic-ioLots of redhat there.
"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.
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?
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.
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.
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.
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.
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.
In terms of stability, as others have pointed out all that means is "the vendor won't change it and will keep providing it"
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.
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)
RHEL 7 is 10 years, and probably a little longer after their recently announced EL7 lifecycle extension ( from: https://access.redhat.com/support/policy/updates/errata/ )
If you open a support ticket and say "Hi I'm using Debian/Arch/Nix" they will just laugh and close the ticket.
SAP: https://community.sap.com/topics/linux/supported-platforms
PeopleSoft/Oracle RDBMS: https://docs.oracle.com/en/database/oracle/oracle-database/1...
But yielding that point would mean that RH/IBM would have you over a barrel on pricing. Probably why Suse is forcing the issue.
P.S. and Oracle is piling on ...
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.
Why, did dependability and enteprise long term stability needs go out of fashion?
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.
https://downloads.apache.org/httpd/CHANGES_2.4
verse
https://centos.pkgs.org/7/centos-updates-x86_64/httpd-2.4.6-...
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.
Until recently even Xilinx's tools would balk at installation on Centos.
When the corp has spent millions on EDA tools, RHEL's yearly subscription looks like peanuts.
Hey, here’s a comprehensive guide complete with commands, expected outcomes, and side effects of each command for setting up a Windows Domain using an RHEL domain controller: https://access.redhat.com/documentation/en-us/red_hat_single...
Oh, that’s for 7.5? One that’s 15 years old and no longer under standard support? It still works! Wait, but you’re a new customer. Sorry, here’s the one for 9: https://access.redhat.com/documentation/en-us/red_hat_enterp...
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.
Their incentives favour creating Red-Hat-specific documentation, and this then reduces their users' incentive to improve upstream documentation.
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...
The developer edition is now more inconvenient, as you have to reapply once a year.
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.
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.
Changing an industry standard isn't impossible, but it will be a paradigm shifting challenge akin to moving mountains.
* with blackjack! and public git repos!
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.
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).
Is the documentation for CentOS Stream that much worse? What does being RHEL-compatible get you over and above being CentOS Stream-compatible?
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.
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?
RHEL is entrenched in that world, perfect for IBM (which also lives off those clients).
I really like Nix so far (just started using it), but damn is the documentation ever shit tier.
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.
there is an ongoing, organized effort to help docs tho: https://discourse.nixos.org/t/fundraising-for-the-nix-docume...
In practice, your best bet is just asking around on community channels (https://nixos.org/community/)
That, IMO, is a killer feature. I really miss when consuming docs from commercial providers these days.
https://news.ycombinator.com/item?id=35588297
(Still amazed that no one understands these basic points)
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.
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.
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.
[1] https://www.jacksonville.com/story/news/2015/01/15/after-tak... [2] https://www.al.com/news/2023/04/target-store-closings-2023-s... [3] https://www.cleveland.com/news/2023/04/target-to-close-store... [4] https://www.irs.gov/pub/irs-pdf/p584b.pdf [5] https://www.reuters.com/article/us-wal-mart-stores-theft/wal... (from 2015) [6] https://www.wsaz.com/2022/12/09/walmart-may-close-stores-inc... [7] https://blog.gitnux.com/walmart-theft-statistics/
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
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.
[1] https://developers.redhat.com/articles/2022/05/10/access-rhe... [2] https://developers.redhat.com/articles/faqs-no-cost-red-hat-...
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?
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.
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.
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.
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.
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.
Whatever benefits their bottom line.
"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."
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.
I wonder how IBM / RedHat might react to that, were it to happen.
Not that I care personally, but this point seems to be very important for a lot of people.
Oracles and Almalinuxes announcements both state clearly that they aim to be compatible so long its possible, so no 1:1 binary compatibility promises.
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.
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 a little skeptical about this right now, but we’ll see how it pans out.
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.
Anybody on the same side as Oracle should be asking really hard questions.
I suspect that RedHat's moves were specifically aimed straight at Oracle with AWS a distant second.
The SUSE distro exists so that they can sell support for it. And it will be the same for the SUSE supported RHEL clone.
As a long term Leap and Tumbleweed user, I trust the openSUSE community to keep producing a nice distro.
1: https://news.ycombinator.com/item?id=30006699 2: https://docs.oracle.com/en/solutions/migrate-centos-ora-linu... 3. https://github.com/microsoft/CBL-Mariner
Between this and Rancher (which is gaining a lot of popularity within the enterprise), SUSE is really stepping it up.
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.
But SUSE isn’t just a package of Red Hat.
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.
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.
https://www.wired.com/2008/08/microsoft-novell-extend-contro...
"[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.
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.
RedHat should take this opportunity to pivot and do something else. Holding on to licensing is dying especially in the world of clones.
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.
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.
Undercutting a competitor for your "business" [interests] is business 101.
And RH deserves all the spite it can get too.
how can you be so sure? Do you have insights on Red Hat finance we don't know about?
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?
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.
https://www.zdnet.com/article/suse-bridges-the-gap-between-o...
* Suse releases a new distro, Purple Weed, rebased last public code of RHEL.
* With some reverse engineering effort or whatever, they provide migration path from RHEL to Suse Purple Weed ™. - for next few releases of RHEL.
* They expect customers to migrate to Suse Purple Weed ™ from RHEL (or clones), within a few versions.
Instead of RHELs proprietary-ish branch, they want their branch to take over and become defacto standard.
I guess.
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.
Right, they only pressured them to make more money, didn't tell them how exactly.
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.
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...
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.
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 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.
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.
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.
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'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.
I don't see any of these things as bad.
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.
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.
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.
or they go straight to FAIL:
Fully Asphyxiated and Impotent Linux
It's a bad look to say absolutely nothing.
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.
A lot of people want to wash their hands of their old employers and move on, even when they have actionable claims.
2. Agree with silisili's bafflement at how corporations are sticking to RHEL.
Fuck it, let's make a cpu-free distribution whilst we're at it.
It's called FreeBSD. HTH. HAND. ;-)
What? Well, it is! It's Linux-free, it has no systemd and no glibc, and no GPL code so it is de facto NU free.
But it has a Linux emulator and can run Linux binaries.
And there is Illumos, which can also run Linux binaries.
If you don't need the Linux binaries part, there are also DragonflyBSD, NetBSD and OpenBSD.
All FOSS, all current, all out there, working, with active communities.
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.