7 ms·

I understand why people use RH and Rocky and even Oracle: the rpm wranglers. However its not for me. My earliest mainstream distro was RH when they did it jus

I understand why people use RH and Rocky and even Oracle: the rpm wranglers. However its not for me. My earliest mainstream distro was RH when they did it just for fun (pre IBM) and then I slid slightly sideways towards Mandrake. I started off with Yggdrassil. I have to do jobs involving RH and co and its just a bit of a pain dealing with elderly stuff. Tomcat ... OK you can have one from 1863. There is a really good security back port effort but why on earth start off with a kernel that is using a walking stick. Perhaps I am being unkind but for me the RH efforts are (probably) very stable and a bit old. It's not the distro itself either. The users seem to have snags with updating it. I (very generally) find that RH shops are the worst at [redacted]

dgfitz 1y ago
I’d rather use redhat than Ubuntu. I was handed a machine the other week with Ubuntu 23.10 on it, OS supplied from a vendor with extensive customization. Apt was dead. Fuck that. At least RH doesn’t kill their repos.
- gerdesj 1y ago
  I've got Ubuntu 22.04 lying around that still update because they are LTS. Ubuntu has a well publicised policy for releases and you will have obviously read them. Try do-release-upgrade. You also mention "OS supplied from a vendor with extensive customization. Apt was dead." How on earth is that Ubuntu's problem?
  - hshdhdhj4444 1y ago
    Isn’t Ubuntu basically killing apt? My Ubuntu became unusable because it kept insisting on installing a snap version of Firefox breaking a whole bunch of workflows. I do want to try a RH based OS (maybe Fedora) so they don’t keep changing things on me, but just where I am in life right now I don’t have the time/energy to do so, so for now I’m relying on my Mac. Hopefully I can try a new Linux distro in a few months, because I can’t figure it out yet, but something about macOS simply doesn’t work for me from a getting work done perspective.
    - nine_k 1y ago
      I've heard many good things about Pop OS. It's like Ubuntu done right, and it does have an apt package for Firefox. (I run Void myself, and stay merrily away from all these complications.)
      - tgmatt 1y ago
        I can highly recommend it. Have been using it for a couple years or so now, haven't had any serious issues.
      - ChocolateGod 1y ago
        > It's like Ubuntu done right But it is Ubuntu?
        nine_k 1y ago
        It's based on Ubuntu, but it's different enough: https://en.wikipedia.org/wiki/Pop!_OS https://en.wikipedia.org/wiki/Pop!_OS
      - severino 1y ago
        In Ubuntu, it's also possible to ditch Firefox from the snap store and install it using apt-get. Not from Ubuntu's repo, but from the official Firefox Debian repository: https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-deb-apt-ubuntu-22-04 https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-d... I know it's not the best but at least it can be done with little effort.
    - mulmen 1y ago
      I have been using Fedora Sway as my desktop operating system for a couple years now and I am very happy. It’s definitely worth a try. I have access to flatpak when I need it for apps like steam but the system is still managed by rpm/dnf. There’s of course some SELinux pain but that’s typically my fault for holding it wrong. Overall very impressed.
  - dgfitz 1y ago
    I cannot update the OS per the contract. It’s Ubuntu’s problem because they decide they’re smarter than their users and nuke their repos. Fuck all of that.
    - dismalaf 1y ago
      It's well publicized that they don't maintain support for old, non-LTS distros. They literally delivered what they promised. Could have been avoided by using an LTS distro. Fedora does the same. No corporate vendor supports 6 month cycle distros for more than a year. RHEL releases come super slowly, for example.
      - dgfitz 1y ago
        I didn’t have a say in the matter of OS choice, it doesn’t matter how well-publicized Ubuntu’s stance is, it’s wrong. I don’t care if it’s not an LTS, keep the fucking repos open and advertise you’re using an insecure OS. Let me, the user, make that choice. Don’t pretend I’m stupid and need some kind of benevolent dictator to make choices for me, or handicap me because they’re smarter than me. They’re not.
        dismalaf 1y ago
        "Keeping the repos open" has a cost on their part. Servers aren't free. If you think you're smart then mirror your own repos.
        dgfitz 1y ago
        Really? How much more can it cost to host their LTS and non LTS repos open at the same time? C’mon, that’s such a weak argument I think you know it.
        dismalaf 1y ago
        If there's no cost in time, effort or equipment then mirror it yourself. It's easy, right? Or just use an LTS distro like literally every single other organization that depends on Ubuntu for their business SMH. Like, it's absurd to even think about...
- deleted 1y ago
  [deleted]
- ndsipa_pomu 1y ago
  Well that's just plain incompetent on the part of your vendor. 23.10 is not an LTS version and Ubuntu only provide updates for a short period of time (6 months or so after the next version is released), so the vendor should have upgraded it to 24.04 which IS an LTS version. It's like you're complaining to Microsoft about a vendor giving you an old XP machine and that you can't update it.
  - chithanh 1y ago
    I think the more apt (pun not intended) comparison would be to macOS? Trying to install macOS High Sierra from the Internet without hackery will lead to "the recovery server could not be contacted" error message, because certificates have expired. Like if your Mac came with High Sierra and you want to do a factory reset. Windows from that era still updates. Though up next will be expiration of Windows UEFI CA 2011 which will certainly lead to boot problems for some.
- GuinansEyebrows 1y ago
  you need to file a support ticket with the organization that provided the laptop. they chose to provide you with what amounts to a technology preview with a very limited lifespan. [0] 0: https://ubuntu.com/about/release-cycle https://ubuntu.com/about/release-cycle
copperx 1y ago
I have to confess that my early experiences with RedHat as a teenager and dealing with the nightmareish RPM dependencies soured me from the distribution. I went to Debian and then its many descendants and never looked back; APT seemed magical in comparison. I assume they have a package manager that resolves dependencies well now? Is that what an RPM wrangler is?
- bigfatkitten 1y ago
  rpm dependencies has been a solved problem with yum (and now dnf) for about two decades.
  - speakspokespok 1y ago
    Yum was borrowed from yellow dog Linux.
    - znpy 1y ago
      Which in turn was based on RHEL/CentOS: https://en.wikipedia.org/wiki/Yellow_Dog_Linux https://en.wikipedia.org/wiki/Yellow_Dog_Linux
    - microtonal 1y ago
      To be pedantic, yum was not from Yellow Dog, it is Yellow dog Updater Modified after all. It was a rewrite of the Yellow Dog Updater by people at Duke University. (Yellow Dog Linux was based on Red Hat.) There was a lot of competition around package managers back then. For RPM, there were also urpmi, apt-rpm, etc.
- speakspokespok 1y ago
  First impressions really matter. This is also why I went Debian. You shouldn't be getting marked down for saying it. Many of us were running on 28.8 dial-up. Internet search was not even close to a solved problem. Compiling a new kernel was an overnight or even weekend process. Finding and manually downloading rpm dependencies was slow and hard. Same era when compiling a kernel went overnight or over the weekend. You didn't download an ISO you bought a CD or soon a DVD that you could booted off of. Compare that to Debian's apt-get or Suse's yast/yast2 of the time, both just handled all that for you. Debian and Suse were fun and fit perfectly into the Web 1.0 world; RedHat was corporate. SystemD was pushed by RedHat.
bigstrat2003 1y ago
> Tomcat ... OK you can have one from 1863. There is a really good security back port effort but why on earth start off with a kernel that is using a walking stick. Because old software is battle-tested and reliable. Moreover, upgrading software is ever a pain so it's best to minimize how often you have to do it. With a support policy of 10 years, you just can't beat RHEL (and derivatives) for stability.
- tanelpoder 1y ago
  Yep, when you have thousands of different production apps, installed and running directly on Linux - not talking about containers or microservices here - you’ll have very little appetite to upgrade all of them to the latest and shiniest technologies every couple of years. Stability & compatibility with existing skillsets is more important.
- rubitxxx10 1y ago
  I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. I know they give back to Linux, and I’m thankful for the enterprises that pay for it because of that. It’s not a bad company, though it’s strange that you could be a great developer and lose your position there if your project gets cut, unless another team picks you up, from what I hear. But when Linus created Linux, he didn’t do it for money, and RH just seems corporate to me like the Microsoft of Linux, way back before Microsoft had their own Linux. I want my Linux free-range not cooped. They don’t do anything wrong. They just don’t give the vibe. Anyone asking for money for it doesn’t “get it” to me.
  - microtonal 1y ago
    I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. Does anyone remember glint (graphical UI for RPM) that was part of Red Hat? Must have been Red Hat 4.x or thereabout.
    - LeFantome 1y ago
      Yes indeed. How about AwesomeWM? Not the one that exists now. The one from Red Hat 4.x or so.
thebeardisred 1y ago
Hi! I'm sorry this has been your experience. I'm one of the Red Hatters who's been working behind the scenes to get this over the finish line. I do say my genuine thanks for your earnest expression. The version and ABI guarantee is not for everyone. At the same time some folks around these parts know that I'm "not an apologist for running an out of date kernel". I can assure you that everything shipped in the forthcoming P550 image is fresh. GCC 15. LLVM 19, etc. It's intended for development to get more software over the finish line for RISC-V. Conflict of interest statement: I work for Red Hat (Formerly CoreOS), and I'm also the working group lead for the distro integration group within RISE (RISC-V Software Ecosystem).
- jabl 1y ago
  > The version and ABI guarantee is not for everyone. As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it.
  - pabs3 1y ago
    Is anyone trying to get those drivers upstreamed?
    - globalc 1y ago
      That, and if not possible one can try to get the used kABI symbols graylisted at Red Hat, to get informed when they change.
    - jabl 1y ago
      Yes, and yes. The kernel parts of MOFED are largely backports of the latest and greatest upstream kernel drivers to the various distro kernels their customers actually run. (The non-kernel parts of MOFED is mostly open source but does contain some proprietary special sauce on top, like IIRC SHARP support isn't available in FOSS.). The HPC community does tend to want to use the latest RDMA drivers as those are critical for at scale performance. For Lustre, the client driver was upstreamed into staging, where it sat AFAIU largely unused for a few years until it was ripped out again. The problem was that Lustre developers didn't adopt an upstream-first development approach, and thus the in-kernel driver was basically a throw over the fence fork that nobody cared about. I think there is an effort to try again and hopefully adopt an upstream-first approach, remains to be seen whether it'll succeed.
worthless-trash 1y ago
Disclaimer: I'm very involved in the kernel part of this for $company. The RHEL kernels themselves do see many improvements over time, the code that you'll see when the product goes end of life is considerably updated compared to the original version string that you see in the package name / uname -a. There are customer and partner feature requests, cve fixes and general bug fixes that go in almost every day. The first problem of 'running old kernels' is exacerbated by the kernel version string not matching code reality. The second probelm is many companies don't start moving to newer rhels when its out, they often stick to current -1, which is a bit of a problem because by the time they roll out a release, n-1 is likely entering its first stage of "maintenance" so fixes are more difficult to include. If you can think of a solution to this, I'm all ears. The original reason behind not continually shipping newer kernel versions is to ensure stability by providing a stable whitelisted kABI that third party vendors can build on top of. This is not something that upstream and many OS vendors support, but with the "promise" of not breaking kabi, updates should happen smoothly without third party needing to update their drivers. The kabi maintenance happens behind the scenes while ensuring that CVE fixes and new features are delivered during the relevant stage of the product lifecycle. The kernel version is usually very close to the previous release, in the case of rhel10 its 6.13 and already with zero day fixes it has parts of newer code backported, tested, etc in the first errata release. The security landscape is changing, maybe sometime Red Hat Business Unit may wake up and decide to ship a rolling better tested kernel (Red Hat DOES have an internal/tested https://cki-project.gitlab.io/kernel-ark/ https://cki-project.gitlab.io/kernel-ark/ which is functionally this ). Shipping this has the downside is that the third party vendors would not have the same KABI stability guarantees that RHEL currently provides, muddy the waters of rhels value and confuse people on which kernel they should be running. I believe there are two customer types, ones who would love to see this, and get the newest features for their full lifecycle, and ones who would hate it, because the churn and change would be too much introducing risk and problems for them down the line. Its hard, and likely impossible to keep everyone happy.
- jabl 1y ago
  As I mentioned in another comment on this thread: > As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it. I'm not sure what the underlying problem here is, is the kABI guarantee worthless generally or is it just that MOFED and Lustre drivers need to use features not covered by some kind of "kABI stability guarantee"?
znpy 1y ago
> I have to do jobs involving RH and co and its just a bit of a pain dealing with elderly stuff. Tomcat ... OK you can have one from 1863. It's 2025, you can run whatever version you need in containers.
LeFantome 1y ago
Things like Flatpak and Distrobox are game changes for these “stable” distros like RHEL or even Debian. Core system stays static and you do not get blindsided by changes in packages you do not care about. At the same time, you can easily install very up-to-date apps and dependencies if you need them.

dgfitz 1y ago

I’d rather use redhat than Ubuntu. I was handed a machine the other week with Ubuntu 23.10 on it, OS supplied from a vendor with extensive customization. Apt was dead. Fuck that. At least RH doesn’t kill their repos.

gerdesj 1y ago
I've got Ubuntu 22.04 lying around that still update because they are LTS. Ubuntu has a well publicised policy for releases and you will have obviously read them. Try do-release-upgrade. You also mention "OS supplied from a vendor with extensive customization. Apt was dead." How on earth is that Ubuntu's problem?
- hshdhdhj4444 1y ago
  Isn’t Ubuntu basically killing apt? My Ubuntu became unusable because it kept insisting on installing a snap version of Firefox breaking a whole bunch of workflows. I do want to try a RH based OS (maybe Fedora) so they don’t keep changing things on me, but just where I am in life right now I don’t have the time/energy to do so, so for now I’m relying on my Mac. Hopefully I can try a new Linux distro in a few months, because I can’t figure it out yet, but something about macOS simply doesn’t work for me from a getting work done perspective.
  - nine_k 1y ago
    I've heard many good things about Pop OS. It's like Ubuntu done right, and it does have an apt package for Firefox. (I run Void myself, and stay merrily away from all these complications.)
    - tgmatt 1y ago
      I can highly recommend it. Have been using it for a couple years or so now, haven't had any serious issues.
    - ChocolateGod 1y ago
      > It's like Ubuntu done right But it is Ubuntu?
      - nine_k 1y ago
        It's based on Ubuntu, but it's different enough: https://en.wikipedia.org/wiki/Pop!_OS https://en.wikipedia.org/wiki/Pop!_OS
    - severino 1y ago
      In Ubuntu, it's also possible to ditch Firefox from the snap store and install it using apt-get. Not from Ubuntu's repo, but from the official Firefox Debian repository: https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-deb-apt-ubuntu-22-04 https://www.omgubuntu.co.uk/2022/04/how-to-install-firefox-d... I know it's not the best but at least it can be done with little effort.
  - mulmen 1y ago
    I have been using Fedora Sway as my desktop operating system for a couple years now and I am very happy. It’s definitely worth a try. I have access to flatpak when I need it for apps like steam but the system is still managed by rpm/dnf. There’s of course some SELinux pain but that’s typically my fault for holding it wrong. Overall very impressed.
- dgfitz 1y ago
  I cannot update the OS per the contract. It’s Ubuntu’s problem because they decide they’re smarter than their users and nuke their repos. Fuck all of that.
  - dismalaf 1y ago
    It's well publicized that they don't maintain support for old, non-LTS distros. They literally delivered what they promised. Could have been avoided by using an LTS distro. Fedora does the same. No corporate vendor supports 6 month cycle distros for more than a year. RHEL releases come super slowly, for example.
    - dgfitz 1y ago
      I didn’t have a say in the matter of OS choice, it doesn’t matter how well-publicized Ubuntu’s stance is, it’s wrong. I don’t care if it’s not an LTS, keep the fucking repos open and advertise you’re using an insecure OS. Let me, the user, make that choice. Don’t pretend I’m stupid and need some kind of benevolent dictator to make choices for me, or handicap me because they’re smarter than me. They’re not.
      - dismalaf 1y ago
        "Keeping the repos open" has a cost on their part. Servers aren't free. If you think you're smart then mirror your own repos.
        dgfitz 1y ago
        Really? How much more can it cost to host their LTS and non LTS repos open at the same time? C’mon, that’s such a weak argument I think you know it.
        dismalaf 1y ago
        If there's no cost in time, effort or equipment then mirror it yourself. It's easy, right? Or just use an LTS distro like literally every single other organization that depends on Ubuntu for their business SMH. Like, it's absurd to even think about...
deleted 1y ago
[deleted]
ndsipa_pomu 1y ago
Well that's just plain incompetent on the part of your vendor. 23.10 is not an LTS version and Ubuntu only provide updates for a short period of time (6 months or so after the next version is released), so the vendor should have upgraded it to 24.04 which IS an LTS version. It's like you're complaining to Microsoft about a vendor giving you an old XP machine and that you can't update it.
- chithanh 1y ago
  I think the more apt (pun not intended) comparison would be to macOS? Trying to install macOS High Sierra from the Internet without hackery will lead to "the recovery server could not be contacted" error message, because certificates have expired. Like if your Mac came with High Sierra and you want to do a factory reset. Windows from that era still updates. Though up next will be expiration of Windows UEFI CA 2011 which will certainly lead to boot problems for some.
GuinansEyebrows 1y ago
you need to file a support ticket with the organization that provided the laptop. they chose to provide you with what amounts to a technology preview with a very limited lifespan. [0] 0: https://ubuntu.com/about/release-cycle https://ubuntu.com/about/release-cycle

copperx 1y ago

I have to confess that my early experiences with RedHat as a teenager and dealing with the nightmareish RPM dependencies soured me from the distribution. I went to Debian and then its many descendants and never looked back; APT seemed magical in comparison. I assume they have a package manager that resolves dependencies well now? Is that what an RPM wrangler is?

bigfatkitten 1y ago
rpm dependencies has been a solved problem with yum (and now dnf) for about two decades.
- speakspokespok 1y ago
  Yum was borrowed from yellow dog Linux.
  - znpy 1y ago
    Which in turn was based on RHEL/CentOS: https://en.wikipedia.org/wiki/Yellow_Dog_Linux https://en.wikipedia.org/wiki/Yellow_Dog_Linux
  - microtonal 1y ago
    To be pedantic, yum was not from Yellow Dog, it is Yellow dog Updater Modified after all. It was a rewrite of the Yellow Dog Updater by people at Duke University. (Yellow Dog Linux was based on Red Hat.) There was a lot of competition around package managers back then. For RPM, there were also urpmi, apt-rpm, etc.
speakspokespok 1y ago
First impressions really matter. This is also why I went Debian. You shouldn't be getting marked down for saying it. Many of us were running on 28.8 dial-up. Internet search was not even close to a solved problem. Compiling a new kernel was an overnight or even weekend process. Finding and manually downloading rpm dependencies was slow and hard. Same era when compiling a kernel went overnight or over the weekend. You didn't download an ISO you bought a CD or soon a DVD that you could booted off of. Compare that to Debian's apt-get or Suse's yast/yast2 of the time, both just handled all that for you. Debian and Suse were fun and fit perfectly into the Web 1.0 world; RedHat was corporate. SystemD was pushed by RedHat.

bigstrat2003 1y ago

> Tomcat ... OK you can have one from 1863. There is a really good security back port effort but why on earth start off with a kernel that is using a walking stick. Because old software is battle-tested and reliable. Moreover, upgrading software is ever a pain so it's best to minimize how often you have to do it. With a support policy of 10 years, you just can't beat RHEL (and derivatives) for stability.

tanelpoder 1y ago
Yep, when you have thousands of different production apps, installed and running directly on Linux - not talking about containers or microservices here - you’ll have very little appetite to upgrade all of them to the latest and shiniest technologies every couple of years. Stability & compatibility with existing skillsets is more important.
rubitxxx10 1y ago
I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. I know they give back to Linux, and I’m thankful for the enterprises that pay for it because of that. It’s not a bad company, though it’s strange that you could be a great developer and lose your position there if your project gets cut, unless another team picks you up, from what I hear. But when Linus created Linux, he didn’t do it for money, and RH just seems corporate to me like the Microsoft of Linux, way back before Microsoft had their own Linux. I want my Linux free-range not cooped. They don’t do anything wrong. They just don’t give the vibe. Anyone asking for money for it doesn’t “get it” to me.
- microtonal 1y ago
  I’m old. I used one of the original boxed RH distros. It was cool then. That was almost 30 years ago. Does anyone remember glint (graphical UI for RPM) that was part of Red Hat? Must have been Red Hat 4.x or thereabout.
  - LeFantome 1y ago
    Yes indeed. How about AwesomeWM? Not the one that exists now. The one from Red Hat 4.x or so.

thebeardisred 1y ago

Hi! I'm sorry this has been your experience. I'm one of the Red Hatters who's been working behind the scenes to get this over the finish line. I do say my genuine thanks for your earnest expression. The version and ABI guarantee is not for everyone. At the same time some folks around these parts know that I'm "not an apologist for running an out of date kernel". I can assure you that everything shipped in the forthcoming P550 image is fresh. GCC 15. LLVM 19, etc. It's intended for development to get more software over the finish line for RISC-V. Conflict of interest statement: I work for Red Hat (Formerly CoreOS), and I'm also the working group lead for the distro integration group within RISE (RISC-V Software Ecosystem).

jabl 1y ago
> The version and ABI guarantee is not for everyone. As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it.
- pabs3 1y ago
  Is anyone trying to get those drivers upstreamed?
  - globalc 1y ago
    That, and if not possible one can try to get the used kABI symbols graylisted at Red Hat, to get informed when they change.
  - jabl 1y ago
    Yes, and yes. The kernel parts of MOFED are largely backports of the latest and greatest upstream kernel drivers to the various distro kernels their customers actually run. (The non-kernel parts of MOFED is mostly open source but does contain some proprietary special sauce on top, like IIRC SHARP support isn't available in FOSS.). The HPC community does tend to want to use the latest RDMA drivers as those are critical for at scale performance. For Lustre, the client driver was upstreamed into staging, where it sat AFAIU largely unused for a few years until it was ripped out again. The problem was that Lustre developers didn't adopt an upstream-first development approach, and thus the in-kernel driver was basically a throw over the fence fork that nobody cared about. I think there is an effort to try again and hopefully adopt an upstream-first approach, remains to be seen whether it'll succeed.

worthless-trash 1y ago

Disclaimer: I'm very involved in the kernel part of this for $company. The RHEL kernels themselves do see many improvements over time, the code that you'll see when the product goes end of life is considerably updated compared to the original version string that you see in the package name / uname -a. There are customer and partner feature requests, cve fixes and general bug fixes that go in almost every day. The first problem of 'running old kernels' is exacerbated by the kernel version string not matching code reality. The second probelm is many companies don't start moving to newer rhels when its out, they often stick to current -1, which is a bit of a problem because by the time they roll out a release, n-1 is likely entering its first stage of "maintenance" so fixes are more difficult to include. If you can think of a solution to this, I'm all ears. The original reason behind not continually shipping newer kernel versions is to ensure stability by providing a stable whitelisted kABI that third party vendors can build on top of. This is not something that upstream and many OS vendors support, but with the "promise" of not breaking kabi, updates should happen smoothly without third party needing to update their drivers. The kabi maintenance happens behind the scenes while ensuring that CVE fixes and new features are delivered during the relevant stage of the product lifecycle. The kernel version is usually very close to the previous release, in the case of rhel10 its 6.13 and already with zero day fixes it has parts of newer code backported, tested, etc in the first errata release. The security landscape is changing, maybe sometime Red Hat Business Unit may wake up and decide to ship a rolling better tested kernel (Red Hat DOES have an internal/tested https://cki-project.gitlab.io/kernel-ark/ https://cki-project.gitlab.io/kernel-ark/ which is functionally this ). Shipping this has the downside is that the third party vendors would not have the same KABI stability guarantees that RHEL currently provides, muddy the waters of rhels value and confuse people on which kernel they should be running. I believe there are two customer types, ones who would love to see this, and get the newest features for their full lifecycle, and ones who would hate it, because the churn and change would be too much introducing risk and problems for them down the line. Its hard, and likely impossible to keep everyone happy.

jabl 1y ago
As I mentioned in another comment on this thread: > As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it. I'm not sure what the underlying problem here is, is the kABI guarantee worthless generally or is it just that MOFED and Lustre drivers need to use features not covered by some kind of "kABI stability guarantee"?

znpy 1y ago

> I have to do jobs involving RH and co and its just a bit of a pain dealing with elderly stuff. Tomcat ... OK you can have one from 1863. It's 2025, you can run whatever version you need in containers.

LeFantome 1y ago

Things like Flatpak and Distrobox are game changes for these “stable” distros like RHEL or even Debian. Core system stays static and you do not get blindsided by changes in packages you do not care about. At the same time, you can easily install very up-to-date apps and dependencies if you need them.