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…
SUSE is forking RHEL
291–300 of 307 posts
Re: SUSE is forking RHEL
#292Name 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.
Re: SUSE is forking RHEL
#293Earlier 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…
> 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-ioRe: SUSE is forking RHEL
#294Earlier 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…
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
#295Earlier 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…
Re: SUSE is forking RHEL
#296Earlier 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.
RHEL, either officially paid for, or via CentOS / Oracle Linux, is everywhere though, gub'mnt, private, academia.
Re: SUSE is forking RHEL
#297Earlier 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.
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
#298Earlier 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.
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
#299Earlier 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.
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
#300Earlier 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)
[1] https://developers.redhat.com/articles/2022/05/10/access-rhe... [2] https://developers.redhat.com/articles/faqs-no-cost-red-hat-...