Live data from Hacker News

SUSE is forking RHEL

suse.com

201–210 of 307 posts

Re: SUSE is forking RHEL

#201
post #164
post #68

Earlier quoted context omitted.

> The time (some years back now, it was a 5.10 patch and a 5.8 rpm) they mis-backported a perl patch to work around a bug in a deprecated CPAN module for one of their enterprise customers and in the process caused a 2x-30x slowdown of lots of other newer code (including the library that had replaced it in the majority of production environments by that point) was 'fun'. That ONE time might have been fun, but with Arc…

With Arch you don't get such fun times because Arch doesn't generally backport patches. They just update.

That's where the fun times come from.

Re: SUSE is forking RHEL

#203
post #159
post #23

Earlier quoted context omitted.

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

I saw RedHat backport kernel bugs... we had one that bricked VLAN support on certain NIC that was put into Centos 5. For those that do not know, RHEL kernels are a bit of an abomination with both bugfixes and new features backported, just so they can tell to customers that the kernel version is "stable" (which is a bit of clown fiesta as Linux doesn't break backward compat on kernel level anyway) and that was one of…

Red Hat also removes drivers for older hardware. SAS RAID has been a recent victim.

Two alternate kernels will restore most missing drivers, El Repo or the Oracle UEK.

Re: SUSE is forking RHEL

#204

Earlier quoted context omitted.

There is a difference between package documentation and system documentation. Red Hat contributes package documentation upstream, but system documentation is by its nature distro-dependent. Red Hat has contributed work that made distros more homogeneous ( cough systemd cough ) and excellent package documentation for that work; but also got flak for that...

They also have soooo many good articles (which are helpful not just to RHEL) behind a subscription wall. If you do a lot of work in the rpm ecosystem, they're like the Experts Exchange of Google search, with how many times you see an exact bug report, then you get to the page with a tease of your exact answer, but it fades into the login required bit.

And it used to be open, until Oracle started closing their tickets for paid support with essentially cut-and-paste of access.redhat.com. That's why you can't have nice things.

Re: SUSE is forking RHEL

#205

Did SUSE ever publicly address the claims of antisemitism within the company?

Unsubstantiated claims from a single ex-employee. If the claims had merit he should have taken his evidence to the German government instead of a blog rant.

Re: SUSE is forking RHEL

#206
post #7

I wonder how this will affect openSUSE, will they announce a new product based on this RHEL fork from SUSE?

+1. Will they compete with there own products?

Whether you pay the for SLES or their fork of RHEL probably does not make much a difference to them. And for customers who run both SLES and RHEL (not sure if that is a common scenario, though), having a single vendor to a deal with is probably a plus.

Re: SUSE is forking RHEL

#207
post #96

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.

Yes, they used the RPM format with their own tool (Zypper instead of DNF/Yum), but packages weren’t (necessarily) compatible with Fedora/RHEL as far as dependencies and such. But SUSE isn’t just a package of Red Hat.

I have seen independent projects provide rpms that are supposed to work on both RedHat/Fedora and SLES/openSUSE, with some caveats as to what versions of each are supported/tested for.

Re: SUSE is forking RHEL

#208

Earlier quoted context omitted.

> essentially just rebuilding and rebranding "their code". I don't think that's the bit that they're angry about, it's the aggressive undercutting of their support contracts, from people who are essentially rebranding their distro. Red Hat (along with IBM) still contributes an insane amount of open source code that they appear to happily upstream. On the Code Radio podcast[1] there was some commentary on Red Hats mov…

> Red Hat is the only company that's not allowed to profit from their work, despite them contributing to everything from the kernel to X, happily upstreaming and maintaining stuff that few others want to deal with. no, this is not the issue. The issue is that there is a megacorporation behind Red Hat which claimed they wouldn't affect any RH decisions and RH would be the good ol' Red Hat we always knew. And they have…

As I see it, very little is actually moving "behind a paywall" (not trying be demening, just lacking a better term). Is systemd moving behind a paywall, no. Neither is Podman, Ansible, kernel patches, X11 patches and pretty much everything. It will all be available in CentOS stream and Fedora or upstreamed... But that's not what people want, they want RHEL, they just don't want the cost. Red Hats contributions was never about what went into RHEL, it is about what they upstream and maintain for the benefit of all distributions, which is a lot more than many believe.

The only thing you cannot get, without a subscription, is the source RPMs and the bit of tooling they need to build RHEL for their customers.

For what I've been hearing, and reading, this is a Red Hat decision, not an IBM decision. If we trust that or not, well... Still I'm not seeing how their contribution to open source isn't intact.

Re: SUSE is forking RHEL

#209

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.

The way my engineering professor put it was so: when even 5 minutes of off-time costs $5,000 of product you want to be sure your systems are stable.

That's the right sort of ballpark for the systems my team maintains. We don't run RHEL.

"Stability" in the RHEL sense is akin to ossification: you don't change anything, and then you can't change anything, and then you've got problems. The costs aren't necessarily as obvious as pursuing stability via dynamism, and in any case can often either be avoided by limiting the lifespan of the system as a whole or at least punted on to a successor.

For military applications, the trade off is even more intense: you build things hoping that they'll never be used, but knowing that they need to work when called upon. Stuff that'll be on the front line tomorrow can have a very different set of lifecycle guarantees from stuff that's got a planned life of 25 years but which (from experience) you know will probably still be around in 50.

Re: SUSE is forking RHEL

#210

Earlier quoted context omitted.

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

So the enterprise and commercial users do care? 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.

Irregardless is a word.[74][75] Nonstandard, slang, or colloquial terms used by English speakers are sometimes alleged not to be real words, despite appearing in numerous dictionaries. All words in English became accepted by being commonly used for a certain period of time; thus, there are many vernacular words currently not accepted as part of the standard language, or regarded as inappropriate in formal speech or writing, but the idea that they are not words is a misconception.[76] Other examples of words that are sometimes alleged not to be words include burglarize, licit,[77] and funnest[78] which appear in numerous dictionaries as English words.[79]

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

Post reply on HN