Live data from Hacker News

SUSE is forking RHEL

suse.com

291–300 of 307 posts

Re: SUSE is forking RHEL

#291

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…

Likewise it grinds my gears when people think that a company should just do things to do them. At the end of the day they need to make a profit to be sustainable, to pay employees, to perform R&D, keep the lights on, etc. Altruism isn't enough on its own. 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 deci…

Not sure if the comment was addressed specifically to mine. If it was: I am OK with companies trying to make money, that's what they are for. It was more about how they phrase things. If you are a company that truly has open source as a driver, then make whatever claims you wish, however if your company's main driver is revenue (as SUSE likely is) don't make business announcements with "WE LOVE OPEN SOURCE" as your main rationale, just say "there's an opportunity for our business to grow" or any other corporate wording.

Re: SUSE is forking RHEL

#292
post #242

Name one distro apart from the EL clones that offer MAC policies for the software in the core repos. SELinux in Debian is a joke, so are the AppArmor policies.

The tangle of suse/opensuse is confusing to me, but I know that the opinionated rolling versions like MicroOS, Aeon, and Kalpa standardized on SELinux. And I know that there are policies for both AA and SELinux for at least some software in the repo.

Re: SUSE is forking RHEL

#293

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

If LTS contracts are that lucrative, are the new Stream release models missing the market? 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 b…

From "Systemd service sandboxing and security hardening" (2022) https://news.ycombinator.com/item?id=29995566 :

> Which distro has the best out-of-the-box output for:?

   systemd-analyze security
And e.g. this in systemd units:

   SystemCallFilter=@basic-io
   SystemCallLog=~@basic-io

Re: SUSE is forking RHEL

#294
post #84

Earlier quoted context omitted.

I wrote this a few months ago explaining why Red Hat makes money: https://news.ycombinator.com/item?id=35588297 (Still amazed that no one understands these basic points)

I'm not totally surprised as most employee's don't know how they fit into their current organization as a whole or how their organization fits into their current market, never mind other companies and vendors. Its along the same lines as people evaluating company licensing and equipment costs as if its coming out of their pocket. Its almost as bad as people believing that Walmart, Target, etc are closing their stores…

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

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.

Re: SUSE is forking RHEL

#295

Earlier quoted context omitted.

Had to laugh at that, as I still have a good deal of RHEL/CentOS 7 and I'm the "one guy" managing these systems. 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've done a few of those RHEL/CentOS/Ubuntu moves myself, and even though it was a pain I'm still somewhat impressed over how painless the actual move was when I had good documentation and also still terrified of what it feels like to try to transition undocumented boxes. 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 s…

so what you're saying is nothing business critical runs on Windows?

Re: SUSE is forking RHEL

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

That tracks with my experience. I played with OpenSuSE but only ever found SLES when dealing with SAP.

RHEL, either officially paid for, or via CentOS / Oracle Linux, is everywhere though, gub'mnt, private, academia.

Re: SUSE is forking RHEL

#297
post #187

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?

Big big big enterprises outsource IT to big big enterprise vendors, and they benefit a lot from standardizing on RHEL, because they employ people, who benefit a lot from documentation and tutorials and so on.

I would have thought that all the documentation and tutorials would apply equally to CentOS Stream — as I understand it, the only real difference is the schedule for releasing minor patches and bugfixes.

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?

Re: SUSE is forking RHEL

#298
post #294

Earlier quoted context omitted.

I'm not totally surprised as most employee's don't know how they fit into their current organization as a whole or how their organization fits into their current market, never mind other companies and vendors. Its along the same lines as people evaluating company licensing and equipment costs as if its coming out of their pocket. Its almost as bad as people believing that Walmart, Target, etc are closing their stores…

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

You are most certainly correct and I suppose without the actual numbers its a bit of speculation.

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/

Re: SUSE is forking RHEL

#299

Earlier quoted context omitted.

If I were Rocky, Alma, Oracle and/or SUSE, I'd be collaborating to define our own point-release schedule off CentOS Stream*, and trying to make our blessèd commits usurp Red Hat's as industry standard. * with blackjack! and public git repos!

SUSE might do that. 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.

> they are never going to write the documentation, do the testing, or provide the certifications that make a RHEL release a RHEL 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).

Re: SUSE is forking RHEL

#300

Earlier quoted context omitted.

Why would you be dependent upon CentOS(RHEL compat) if you are in those industries? If you need certification and LTS then pay for it by purchasing RHEL licenses. 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 w…

One scenario that I can imagine, is for development environment. People had CentOS as dev environment and deployed RHEL. Or ran CentOS guests on RHEL hosts (VM or Docker)

Thats a good point. Looks like RedHat considered this and offer free company/professional developer RHEL images for non-production use[1]. In 2021 they allowed zero-cost licensing for individuals[2].

[1] https://developers.redhat.com/articles/2022/05/10/access-rhe... [2] https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

Post reply on HN