Hacker News Reader

Comment by bonzini | Hacker News Reader

Red Hat's model is to only ship what they know they can support. For the rest there's EPEL which is community managed.

Canonical's model is to ship the kitchen sink and wing it in case a customer wants support on something that is in a sorry state.

Different customers, different requirements.

View on HN

Thats not true with Ubuntu Pro, which includes support for way more packages than RHEL, 10 thousand to be exact, and is much cheaper with more features like included kernel Livepatching.

I was referring exactly to Ubuntu Pro. They can support more packages for cheaper exactly because Red Hat won't ever have the same YOLO approach to support that Canonical has.

Did you try their support before coming to such opinions?

1) Canonical does not have enough testers. As a developer I have seen what kind of bugs are reported on Ubuntu, and some of them denote a serious lack of QA. There are packages in Ubuntu that are almost certainly shipped untested.

2) Canonical does not have enough developers, unless they found a magic recipe by which their relatively few employees know how to fix issues in all these packages while not contributing upstream and while also maintaining mir/upstart/snap whatever their latest fad is. So if you have say a performance regression or a kernel crash or a miscompilation they might just relay that to upstream developers and hope they fix it.

3) Regarding package count, PPAs are basically the same as EPEL or Copr, and are unsupported.

I'm not saying they are bad at support. I'm saying that they are betting on their customer not actually asking them to support some of the things they ship. Red Hat just says "no thanks, feel free to use EPEL or pip but we don't want to touch it".

Honestly I never use PPAs on Ubuntu, because Ubuntu universe has everything I ever need, and now its supported by Ubuntu PRO.

So here is an example. Universe has all system and user-mode emulators for QEMU, it's 20-odd packages. To what extent will Canonical fix bugs in there, even for very old emulated machines? You don't know, but you know that they have no contributions upstream and it's one of the largest packages they have, so your chances aren't great.

Red Hat only has the KVM-enabled binary because, as the #2 contributor to the upstream project, they know exactly what can and cannot be supported. It also has dozens people of employed just to test it. If you have an issue it may languish because no one is perfect, but your prior is a little better.

RHELs model is to support such ancient versions of software that they don't have to support many pieces of software, because the features most people would rely on aren't in 3, 5 or 10 year old software. If it wasn't effectively required (until recently) for most US government use, I would imagine they would have a substantially smaller customer base.

This is not entirely true; some packages have been removed from RHEL7 to 8 to 9, because the interpretation of "if we ship it we support it" has become stricter. RHEL9 is as new or sometimes newer than Debian 11 (bullseye).

RedHat also backports fixes, security patches, and (occasionally) features to existing RPMs without incrementing the minor version.

For example fuzzywhatsit-3.0 in RHEL could be functionally equivalent to 3.5 in another distro.

They even rebase packages to new upstream versions in point releases (where doing so maintains backwards compatibility, of course).

Reply on news.ycombinator.com