131–140 of 307 posts
Earlier quoted context omitted.
Some software vendors - e.g. major engineering applications - only support their products on RHEL.
Yep. A ton of proprietary software (like anything from IBM) supports only RHEL or SLES. If you open a support ticket and say "Hi I'm using Debian/Arch/Nix" they will just laugh and close the ticket.
Earlier quoted context omitted.
> 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…
> 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.
Earlier quoted context omitted.
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 t…
The Rocky Linux folks pointing out some of the things that make it hard: https://rockylinux.org/news/keeping-open-source-open/
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.
Earlier quoted context omitted.
> I can't figure out why RHEL compat is so desirable. 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 custom…
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?
Earlier quoted context omitted.
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).
> mostly independent from IBM (who didn't participate in this decision). Right, they only pressured them to make more money, didn't tell them how exactly.
Earlier quoted context omitted.
For what?
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.
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
> Dirk-Peter van Leeuwen, CEO of SUSE, said, 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.
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.
Earlier quoted context omitted.
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?
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.
You would think they would publish the srpms of SLES so there could be a RHEL type clone but based on SUSE and fill that void.
OpenSUSE Leap is just that, it uses binaries directly from SLES https://www.zdnet.com/article/suse-bridges-the-gap-between-o...