Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rocky Linux 9.0

rockylinux.org

Post reply on HN
Print view View original

91–100 of 178 posts

Re: Rocky Linux 9.0

#91

Post by djbusby »

jacobr1 wrote: post #54
carwyn wrote: post #52

Earlier quoted context omitted.

It goes further than that. If you file a bug on Red Hat's bugzilla with or without a support contract, you will quite often get a response if you put the effort into producing a detailed report. No guarantee, sometimes just others with the same issue, but still pretty good. You will also find Red Hat employees on the mailing lists for the OSS projects they contribute or depend on who actively participate in conversat…

Is this still true after the IBM acquisition?

I've been involved with companies buying from IBM for over 20 years. Since the Lotus Notes days I've always been impressed by their support chasing down hairy issues. Like, their tier1 would escalate to T3 when mostly needed. Compare to Google where robots lock you out for days. Expensive but never had a client be mad about it.

Re: Rocky Linux 9.0

#92

Post by wolverine876 »

5e92cb50239222b wrote: post #11

Note that AlmaLinux released 9.0 about 40 days ago. They're also significantly faster with releasing minor updates (including releases like 8.6). On top of that, I like their attitude a lot more compared to what I've seen from Rocky's developers (regarding community interactions and such stuff). https://lwn.net/Articles/896438/ https://en.wikipedia.org/wiki/AlmaLinux#Releases

> Note that AlmaLinux released 9.0 about 40 days ago. They're also significantly faster with releasing minor updates (including releases like 8.6).

'Faster' is not a recommendation for an OS developer, IMHO; I don't need operating systems faster - in fact, I like to give them time to mature in other people's hands and to test them myself. The only things I want ASAP are security fixes that are critical to my systems.

If Alma sells themselves on 'faster' (do they?), that would be a significant concern. Why would they do that? Why create a perverse incentive for themselves?

Re: Rocky Linux 9.0

#93

Post by josephcsible »

AdmiralAsshat wrote: post #16

What's the thought process behind buying commercial support for a free, binary-compatible RHEL clone, instead of just paying for Red Hat support? Is the calculation that the once-in-a-blue-moon call to a commercial Rocky Linux support vendor when your server catches fire would still be cheaper than the cost of a normal RHEL license?

It's not about the money. It's about not having to put up with subscription-manager. (I often use the free clones for this reason at work on my sandbox VMs, even though my employer has a paid Red Hat subscription.)

Re: Rocky Linux 9.0

#94

Post by awill »

wolverine876 wrote: post #92
5e92cb50239222b wrote: post #11

Note that AlmaLinux released 9.0 about 40 days ago. They're also significantly faster with releasing minor updates (including releases like 8.6). On top of that, I like their attitude a lot more compared to what I've seen from Rocky's developers (regarding community interactions and such stuff). https://lwn.net/Articles/896438/ https://en.wikipedia.org/wiki/AlmaLinux#Releases

> Note that AlmaLinux released 9.0 about 40 days ago. They're also significantly faster with releasing minor updates (including releases like 8.6). 'Faster' is not a recommendation for an OS developer, IMHO; I don't need operating systems faster - in fact, I like to give them time to mature in other people's hands and to test them myself. The only things I want ASAP are security fixes that are critical to my systems.…

Why is this a concern? If Alma and Rocky are essential identical, speed is the only/main differentiator, and it matters. If an urgent vulnerability gets patched in RHEL, and I'm using Rocky or Alma, I want the one that gets patched sooner. Right now, that's Alma.

Re: Rocky Linux 9.0

#95

Post by awill »

js4ever wrote: post #45
freedomben wrote: post #18

Earlier quoted context omitted.

Disclaimer: I'm a former Red Hat employee, but only speak for myself. I'm also going to speak very frankly. You got it. From the customer side support from them is cheaper than Red Hat's (sometimes much cheaper). From the supplier side, they don't have to bear much (or any) of the cost of development (beyond infra hosting and re-branding), so they can beat Red Hat's price very easily. I personally find that gross and…

What I find gross and unethical is your attitude, it's open source or not? If yes don't be shocked when someone is reusing your code legally.

I don't think it's fair to be that harsh. Ultimately Red Hat incurs costs from engineering RHEL. They fund that through support contracts. So obviously a company that doesn't incur these costs can sell support contracts for cheap. While it's legal, I agree there are grey areas around the ethics. Of course it's OSS, so you can't have expectations, but just imagine if all RHEL customers switched to 3rd party support. Red Hat would stop existing. Then what would these 3rd party support companies do? They'd go under too, as they'd have nothing to support.

Re: Rocky Linux 9.0

#96

Post by awill »

EwanToo wrote: post #72
AdmiralAsshat wrote: post #16

What's the thought process behind buying commercial support for a free, binary-compatible RHEL clone, instead of just paying for Red Hat support? Is the calculation that the once-in-a-blue-moon call to a commercial Rocky Linux support vendor when your server catches fire would still be cheaper than the cost of a normal RHEL license?

I tried to speak to Redhat about getting support for servers that didn't fit into their annual per-server subscription model. They didn't even reply to multiple emails. Redhat sales are now firmly set in the IBM enterprise model. I'm sure it works for them, but it didn't work for us as a potential customer moving from Centos. https://www.redhat.com/en/store/linux-platforms

sounds like Alma/Rocky would be a good choice :)

Re: Rocky Linux 9.0

#97

Post by josephcsible »

carwyn wrote: post #52
bityard wrote: post #37

Earlier quoted context omitted.

I think (or at least I hope) that anyone who buys a support contract from a third-party company for a third-party distribution understands that they are not getting the same level of support that they would from Red Hat. There is lots of room in the enterprise sector for third-party support. This is, for example, what almost all consultants effectively are. The third-party vendor can solve a lot of problems that the…

It goes further than that. If you file a bug on Red Hat's bugzilla with or without a support contract, you will quite often get a response if you put the effort into producing a detailed report. No guarantee, sometimes just others with the same issue, but still pretty good. You will also find Red Hat employees on the mailing lists for the OSS projects they contribute or depend on who actively participate in conversat…

This isn't my experience at all. I've personally had three paid support cases attached to Bugzilla issues. Two of them were for bugs that had one-line fixes that were already committed upstream, along with test cases, and that I just needed Red Hat to backport. They sat for about 6 months before I got any response other than the automated monthly "our engineers are working on the Bugzilla." The third was for a problem that existed upstream too. It was opened over 2 years ago and still isn't fixed.

Re: Rocky Linux 9.0

#98

Post by jillesvangurp »

I find it interesting that there's a need for Rocky to exist at all. IBM basically killed Centos, which was the unofficial Red Hat release that came into existence when Red Hat stopped providing free versions of Red Hat which Red Hat then grand fathered in as a thing they actively supported. That whole process was just weird. I did not encounter a single project that actually used Red Hat after that happened: world + dog used Centos at the time. That seemed like a horrible process to put up artificial hurdles for people to transition to Red Hat. Killing Centos and then having Rocky and Alm emerge immediately after makes this even less likely. As a business strategy this just seems pretty misguided.

These days, I don't deal with the whole red hat ecosystem at all (why would I?). Software ships in docker form these days and I'll typically either deploy it on whatever my cloud provider uses without really messing with that directly or setting up a simple Ubuntu server with Docker using things like Ansible. My daily driver is a Manjaro laptop currently. I like it because I get current versions of everything I need as opposed to old stuff like Gnome 40. Do people actually put Rocky on workstations? My impression is that that whole ecosystem is more about servers and that Fedora is the preferred thing for people in that ecosystem on desktops.

Re: Rocky Linux 9.0

#99

Post by bonzini »

josephcsible wrote: post #97
carwyn wrote: post #52

Earlier quoted context omitted.

It goes further than that. If you file a bug on Red Hat's bugzilla with or without a support contract, you will quite often get a response if you put the effort into producing a detailed report. No guarantee, sometimes just others with the same issue, but still pretty good. You will also find Red Hat employees on the mailing lists for the OSS projects they contribute or depend on who actively participate in conversat…

This isn't my experience at all. I've personally had three paid support cases attached to Bugzilla issues. Two of them were for bugs that had one-line fixes that were already committed upstream, along with test cases, and that I just needed Red Hat to backport. They sat for about 6 months before I got any response other than the automated monthly "our engineers are working on the Bugzilla." The third was for a proble…

BZ number for the third? Also what components?

Re: Rocky Linux 9.0

#100

Post by josephcsible »

jaboutboul wrote: post #85
CamJN wrote: post #73

Earlier quoted context omitted.

Alma is not as RHEL-compatible as rocky, they use subkeys for signing whereas rocky just uses their signing keys. This is enough that I can’t use alma for building my rpm’s using mock.

This is not correct. The issue is trying to use Alma 8’s mock chroot on a CentOS 7 host. The (older) versions of yum and rpm there don’t support subkeys. There is a Red Hat BZ issue here: https://bugzilla.redhat.com/show_bug.cgi?id=2017069

Do RHEL/Rocky/CentOS Stream 8's mock chroots work on CentOS 7 hosts? If so, then this does seem like a legitimate binary incompatibility.
Post reply on HN