Re:Rocky Linux 9.0
by freedomben on Thursday July 14, 2022 @04:30PM
(#32101064)
You make some great points, thanks (side note: I love HN for conversations exactly like this one). You've won me over somewhat. As long as the support vendor isn't misrepresenting what they offer and how it differs from Red Hat, it doesn't seem nearly as unethical as it felt initially. I've only had experience with a handful of vendors, but all of them marketed themselves as "same support as Red Hat, 1/4 to 1/2 the price." I find that gross, but if it were "we'll help you setup and configure your machine" rather than "use us instead of Red Hat" I don't really have an issue with that.
Nobody ever got fired for hiring red hat for red hat support. To the other post’s point those may not be the contracts red hat wants. They want big enterprise where there is 0 reason to not go red hat.
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 conversations there.
If you have a support contract though and open a case, the level and quality of support is usually very high.
Re:Rocky Linux 9.0
by josephcsible on Thursday July 14, 2022 @11:45PM
(#32104400)
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.
Same experience with RHEL support. We just didn’t bother in the end. We fix our own bugs or work around them.
CentOS/Rocky has better ROI is better when stuff doesn’t get fixed on something you are paying money for.
BZ number for the third? Also what components?
Re:Rocky Linux 9.0
by josephcsible on Thursday July 14, 2022 @11:57PM
(#32104454)
The components for the first two were NSS (Network Security Services, not Name Service Switch) and GCC, and the third was Kerberos. I don't have the BZ number handy right now.
For the first two it's probably that they were considered not bad enough for an asynchronous release. With CentOS Stream, you would have a better understanding of when the patch was committed and more certainty of whether it would be fixed in the next minor (6-months cadence) release.
Feel free to write to me at [email protected], I don't work on Kerberos myself but I know people in the team.
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.
There's been absolutely no change for most employees after the acquisition.
Re:Rocky Linux 9.0
by worthless-trash on Thursday July 14, 2022 @08:47PM
(#32103221)
Can confirm. No change in product security.
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 customer may not have the experience to deal with and can be well worth the price paid. But at the end of the day if there's an actual bug all the way upstream in RHEL, only RHEL can (permanently) fix that.
I've dealt with Red Hat in the past and one good thing about their support is that if you have a particularly thorny problem or a genuine bug, you will often eventually end up talking directly to someone who is either wrote the code or sits next to the person who did.