Hacker News Reader

Comment by mbreese | Hacker News Reader

> The Case for Oracle Linux

I did not see that twist coming.

Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.

View on HN

> Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel.

This is probably a lot better than expecting it to be possible to maintain a secure release with a level of compatibility guarantee for 10+ years.

Maybe, but it's not obvious. There are plenty of novel vulnerabilities in interfaces like io_uring and so forth. It's not that those features are bad, I'm just saying that there are tradeoffs to always getting the new stuff.

Maybe the compromise solution is to use newer kernels but keep certain features turned off until they "bake" properly.

But what stops Oracle from just pulling a Red Hat when people switch over to Oracle Linux? Oracle hasn't exactly proven itself to be trustworthy over the years and that's putting it lightly.

I think we need a fully open source alternative to RHEL not bound to any company. Something akin to the Debian project that can serve as an upstream reference distro and repository.

Oracle Linux, Red Hat, and Debian are all “fully open source”. What you mean is “not maintained by a corporation.”

Well, RHEL is now only "fully open source" with quotes, and won't allow code redistribution anymore.

> I think we need a fully open source alternative to RHEL not bound to any company

I believe the problem is not that there wouldn’t be open source alternatives but that that’s not what enterprise wants. Enterprise wants a company behind the distribution.

Of course, think about the relationship between Ubuntu and Debian. The idea is the upstream would be a fully open-source project that vendors build off of downstream. This way we can prevent vendors from subjugating a distribution like with Red Hat and CentOS and if a vendor pulls out of the market or goes out of business it doesn't take down the ecosystem with it.

But arguably, there's also a pretty large world that wants enterprise type of solutions (for some use cases) without being actual enterprises.

Or am I the only one?

At the same time it is not that convincing point because in lot of cases the value from freezing is pretty small for kernel compared to other software, because kernels strong "do not break userspace" attitude. Version freezing is far more valuable for various other projects that do not take backwards compatibility that seriously.

I thought the Linux kernel had a strong “don’t break userspace” attitude, but it was a free for all in kernel space. If you’re developing kernel modules or have custom hardware with drivers, I could see having a backported kernel as being a major problem for support and development.

My (spectator's) understanding is that ABI compatibility is not a priority for kernelspace in Linux, but there is care taken for backwards compatibility in other ways (like at an API level). You're just expected to recompile your out-of-tree kernel modules when there's a new kernel version.

Nope, API compatibility is also explicitly disavowed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Thank you for sharing this! Nothing helps you remember a fact like having been wrong about it in public. :)

If you're using proprietary hardware drivers which target RHEL, you need stable kernel.

Also kernel updates breaking drivers is a thing.

So there's definitely value with frozen kernel version. And its almost the same value as frozen software. It just works and it won't break after update.

I actually did really like the point; but I would be very interested in hearing a rebuttal or counterargument from Red Hat.

Linus' "security problems are just bugs" approach has been worrisome.

I would expect that tracking the Linux kernel master just 4 weeks behind is going to cause more cases where, combined with enterprise software of typical quality, you'd need vendor support than with the RH way of changing as little as possible for as long as possible. And support is exactly what Oracle sells.

To be clear, I only used Oracle Linux briefly while playing with the free tier of Oracle Cloud.

Edit: sorry, but I don't get it, please break it down for me. Latest UEK 7 is based off 5.15 LTS ( https://docs.oracle.com/en/operating-systems/uek/ ), that puts them at branching off a kernel released on 2021-10-31 (according to https://en.wikipedia.org/wiki/Linux_kernel_version_history#R... ). How is that even remotely 4 weeks behind master?!

Edit 2: my bad, I didn't read the "behind the tip of the LTS tree" part carefully. So, the difference is that Oracle tries to ship all LTS kernel updates, while RH tries to cherry-pick critical security and bug fixes only?

Red Hat doesn't change as little as possible, at least 30% of the changes to Linux make it to RHEL.

Most of the RHEL kernel is a few months behind upstream despite the old version. The next minor release of RHEL, to be released in November, probably will have features up to 6.3 for many subsystems and bugfixes up to 6.5 for example.

Interesting, thank you for the details. This means that in some way, RHEL is ahead of Oracle Linux in terms of kernels? I don't see an UEK version tracking Linux 6.1 at all, AFAIK.

It's true that Red Hat does pull in changes from upstream for several subsystems of Linux. It's genuinely a frankenkernel mixed with code from 6.3, 6.1, etc.

But you're still beholden to what the Red Hat maintainers are pulling in and focusing on. It's still not a general follow upstream wholesale.

You can see and track what UEK is doing by looking at their Github: https://github.com/oracle/linux-uek/commits/uek7/u1

See here for an article that describes how it's done --> https://news.ycombinator.com/item?id=36763935

In his defence, most bugs in the kernel can be exploited, so it doesn't necessarily make sense to treat a "bug" with a PoC better than one without.

> Linus' "security problems are just bugs" approach has been worrisome.

Aren't they?

Reply on news.ycombinator.com