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.
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.
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.
> 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.
> 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.
> 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).
"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.
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?
> 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
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.
> 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.
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.
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.
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.
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.
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.
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.
"[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.
[+] [-] jsiepkes|2 years ago|reply
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.
[+] [-] teleforce|2 years ago|reply
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.
[+] [-] bonzini|2 years ago|reply
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.
[+] [-] nicce|2 years ago|reply
[+] [-] kijin|2 years ago|reply
[+] [-] pelasaco|2 years ago|reply
[+] [-] silisili|2 years ago|reply
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.
[+] [-] freeone3000|2 years ago|reply
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.
[+] [-] bandrami|2 years ago|reply
[+] [-] PlutoIsAPlanet|2 years ago|reply
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.
[+] [-] imiric|2 years ago|reply
[+] [-] tannhaeuser|2 years ago|reply
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.
[+] [-] bayindirh|2 years ago|reply
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.
[+] [-] mst|2 years ago|reply
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).
[+] [-] pipo234|2 years ago|reply
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.
[+] [-] rwmj|2 years ago|reply
https://news.ycombinator.com/item?id=35588297
(Still amazed that no one understands these basic points)
[+] [-] pcw888|2 years ago|reply
[+] [-] ZeroSolstice|2 years ago|reply
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?
[+] [-] B1FF_PSUVM|2 years ago|reply
[+] [-] pelasaco|2 years ago|reply
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
[+] [-] coldtea|2 years ago|reply
Why, did dependability and enteprise long term stability needs go out of fashion?
[+] [-] SanjayMehta|2 years ago|reply
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.
[+] [-] b112|2 years ago|reply
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.
[+] [-] bityard|2 years ago|reply
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.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] itomato|2 years ago|reply
[+] [-] znpy|2 years ago|reply
[deleted]
[+] [-] deng|2 years ago|reply
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.
[+] [-] binary_ninja|2 years ago|reply
[+] [-] CrLf|2 years ago|reply
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.
[+] [-] t0m44c|2 years ago|reply
[+] [-] themgt|2 years ago|reply
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.
https://www.suse.com/c/suse-acquires-rancher/
[+] [-] skissane|2 years ago|reply
I wonder how IBM / RedHat might react to that, were it to happen.
[+] [-] weare138|2 years ago|reply
[+] [-] PAPPPmAc|2 years ago|reply
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.
[+] [-] 0dayz|2 years ago|reply
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.
[+] [-] Decabytes|2 years ago|reply
[+] [-] dralley|2 years ago|reply
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.
[+] [-] diffeomorphism|2 years ago|reply
[+] [-] bsder|2 years ago|reply
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.
[+] [-] evasb|2 years ago|reply
[+] [-] xinayder|2 years ago|reply
[+] [-] gtirloni|2 years ago|reply
[+] [-] haytamoptika|2 years ago|reply
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
[+] [-] nunez|2 years ago|reply
Between this and Rancher (which is gaining a lot of popularity within the enterprise), SUSE is really stepping it up.
[+] [-] nubinetwork|2 years ago|reply
[+] [-] cloin|2 years ago|reply
[+] [-] mariuolo|2 years ago|reply
[+] [-] pipo234|2 years ago|reply
[+] [-] gigatexal|2 years ago|reply
"[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.