Live data from Hacker News

SUSE is forking RHEL

suse.com

141–150 of 307 posts

Re: SUSE is forking RHEL

#141

Earlier quoted context omitted.

I wish I could upvote this 10,000 times. 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…

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...

Re: SUSE is forking RHEL

#142
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.

Re: SUSE is forking RHEL

#143

> 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.

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.

Re: SUSE is forking RHEL

#144

1. If SUSE wants to preserve choice, it should offer a systemd-free distribution. 2. Agree with silisili's bafflement at how corporations are sticking to RHEL.

They should also offer a Linux-free distribution, and a GNU free distribution, and a glibc free distribution. Fuck it, let's make a cpu-free distribution whilst we're at it.

> They should also offer a Linux-free distribution, and a GNU free distribution, and a glibc free distribution.

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.

Re: SUSE is forking RHEL

#145
post #70

Earlier quoted context omitted.

pivot to what? 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.

Re: SUSE is forking RHEL

#147
post #120

Earlier quoted context omitted.

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.…

I really hope that you are right. Never thought there would come a day when I must root for Oracle to help defend open source, but here we are.

Re: SUSE is forking RHEL

#148
post #143

Earlier quoted context omitted.

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.

My feeling is that most engineers outside of Germany prefer RHEL to SLES.

Re: SUSE is forking RHEL

#149

Earlier quoted context omitted.

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…

> 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.

Re: SUSE is forking RHEL

#150
post #4

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 beca…

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?

Post reply on HN