9 ms·

> 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 i

> 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”.

gjsman-1000 3y ago
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.
- smarx007 3y ago
  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/ 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#Releases_5.x.y 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?
  - bonzini 3y ago
    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.
    - smarx007 3y ago
      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.
      - cylo 3y ago
        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 https://github.com/oracle/linux-uek/commits/uek7/u1
        deleted 3y ago
        [deleted]
      - bonzini 3y ago
        See here for an article that describes how it's done --> https://news.ycombinator.com/item?id=36763935 https://news.ycombinator.com/item?id=36763935
- chabad360 3y ago
  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.
- picozeta 3y ago
  > Linus' "security problems are just bugs" approach has been worrisome. Aren't they?
indymike 3y ago
> 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.
- deleted 3y ago
  [deleted]
- dralley 3y ago
  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.
weare138 3y ago
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.
- MatthiasPortzel 3y ago
  Oracle Linux, Red Hat, and Debian are all “fully open source”. What you mean is “not maintained by a corporation.”
  - marcosdumay 3y ago
    Well, RHEL is now only "fully open source" with quotes, and won't allow code redistribution anymore.
- tosihakkeri 3y ago
  > 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.
  - noizejoy 3y ago
    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?
  - weare138 3y ago
    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.
zokier 3y ago
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.
- mbreese 3y ago
  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.
  - pxc 3y ago
    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.
    - comex 3y ago
      Nope, API compatibility is also explicitly disavowed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
      - pxc 3y ago
        Thank you for sharing this! Nothing helps you remember a fact like having been wrong about it in public. :)
vbezhenar 3y ago
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.
deleted 3y ago
[deleted]

gjsman-1000 3y ago

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.

smarx007 3y ago
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/ 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#Releases_5.x.y 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?
- bonzini 3y ago
  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.
  - smarx007 3y ago
    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.
    - cylo 3y ago
      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 https://github.com/oracle/linux-uek/commits/uek7/u1
      - deleted 3y ago
        [deleted]
    - bonzini 3y ago
      See here for an article that describes how it's done --> https://news.ycombinator.com/item?id=36763935 https://news.ycombinator.com/item?id=36763935
chabad360 3y ago
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.
picozeta 3y ago
> Linus' "security problems are just bugs" approach has been worrisome. Aren't they?

indymike 3y ago

> 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.

deleted 3y ago
[deleted]
dralley 3y ago
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.

weare138 3y ago

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.

MatthiasPortzel 3y ago
Oracle Linux, Red Hat, and Debian are all “fully open source”. What you mean is “not maintained by a corporation.”
- marcosdumay 3y ago
  Well, RHEL is now only "fully open source" with quotes, and won't allow code redistribution anymore.
tosihakkeri 3y ago
> 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.
- noizejoy 3y ago
  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?
- weare138 3y ago
  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.

zokier 3y ago

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.

mbreese 3y ago
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.
- pxc 3y ago
  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.
  - comex 3y ago
    Nope, API compatibility is also explicitly disavowed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    - pxc 3y ago
      Thank you for sharing this! Nothing helps you remember a fact like having been wrong about it in public. :)

vbezhenar 3y ago

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.

deleted 3y ago

[deleted]