2 ms·

Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel? And all these users are companies who c

Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel? And all these users are companies who can't afford a license? Or universities who can't afford an education license? What are these users doing, that can't be done with good ol' Debian, or any other of the million distros? I'm genuinely interested in that.

epolanski 3y ago
Things are more complex when requirements and documents were drafted time ago. A requirement may specifically include all security updates asap for that software on that version and it is nobody's interest to change kernels (especially by who charges the clients for this routine constant work).
iamwpj 3y ago
We have plenty of licensed RHEL, but in isolated environments the hurdle of connecting to a Satellite server or their subscription hub on the internet is too high -- at least with Rocky and the ilk available. For this set up, the licensing model doesn't match reality, at least not easily. Are we really going to build out compatible configuration management, monitoring, logging, etc? -- it's not a seamless transition. How much time do we have to put towards this? And yes -- there is software compatibility issues. Look at the OpenHPC software distribution, it's designed for SUSE or Enterprise Linux: https://github.com/openhpc/ohpc/wiki/2.X https://github.com/openhpc/ohpc/wiki/2.X
- not_your_vase 3y ago
  I guess testing with broken licensing terms is a valid usecase, thank you. But does that mean most of the uproar is caused by this root cause? This noise is actually coming from actual RHEL subscribers, who don't want to pay such throwaway systems (rightfully), and not from non-RHEL subscribers?
lelanthran 3y ago
> Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel? It's not unimaginable. Think systems which have been certified by some regulatory body. So, most of finance and banking, some of health, all of munitions and arms, many aviation systems, many industrial systems, etc. I worked in EMV and munitions, and a lot of the time it was simply cheaper to continue making the old system than it was to certify a whole new system. The fastest certification process I knew off took about 6 month. The longest took about 2 years. At those timescales it becomes expensive.
- not_your_vase 3y ago
  But I imagine these industries are exactly the ones who will not rely on random free rebuilds, but will shell out the RHEL subscription without flinching, and then sleep with a peace of mind. I guess not these users making this big news (Though this is a blind guess, and could be totally wrong...)
  - lelanthran 3y ago
    Actually you're on the money and I should have considered more context when making my previous reply. Those users (of which I used to be part of) find it a lot cheaper (almost negligible) to pay for things like RHEL instead of re-certifying. You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro?
    - stonith 3y ago
      > You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro? The scientific community, who run extremely high core counts and thus get a raw deal on licensing, but need the drivers for their hardware to be completely reliable as well as software compatability to work with anything from proprietary vendors that their community might need. Eg. CERN who are backing Alma linux.
9659 3y ago
At my previous employment, we used RHEL. Why? It is the only linux on the governments list of "security acceptable software products". And lot's of CentOS. Mainly for development. If I needed a virtual machine to troubleshoot something, I would make a CentOS one. A lot easier to not worry about the license keys. Same for build machines and temp lab setup machines, CentOS was quick to set up. Delivered machines required RHEL. The others did not.

epolanski 3y ago

Things are more complex when requirements and documents were drafted time ago. A requirement may specifically include all security updates asap for that software on that version and it is nobody's interest to change kernels (especially by who charges the clients for this routine constant work).

iamwpj 3y ago

We have plenty of licensed RHEL, but in isolated environments the hurdle of connecting to a Satellite server or their subscription hub on the internet is too high -- at least with Rocky and the ilk available. For this set up, the licensing model doesn't match reality, at least not easily. Are we really going to build out compatible configuration management, monitoring, logging, etc? -- it's not a seamless transition. How much time do we have to put towards this? And yes -- there is software compatibility issues. Look at the OpenHPC software distribution, it's designed for SUSE or Enterprise Linux: https://github.com/openhpc/ohpc/wiki/2.X https://github.com/openhpc/ohpc/wiki/2.X

not_your_vase 3y ago
I guess testing with broken licensing terms is a valid usecase, thank you. But does that mean most of the uproar is caused by this root cause? This noise is actually coming from actual RHEL subscribers, who don't want to pay such throwaway systems (rightfully), and not from non-RHEL subscribers?

lelanthran 3y ago

> Are there really so many users who rely on 100% RHEL compatibility, and support for 10 years of the same ancient kernel? It's not unimaginable. Think systems which have been certified by some regulatory body. So, most of finance and banking, some of health, all of munitions and arms, many aviation systems, many industrial systems, etc. I worked in EMV and munitions, and a lot of the time it was simply cheaper to continue making the old system than it was to certify a whole new system. The fastest certification process I knew off took about 6 month. The longest took about 2 years. At those timescales it becomes expensive.

not_your_vase 3y ago
But I imagine these industries are exactly the ones who will not rely on random free rebuilds, but will shell out the RHEL subscription without flinching, and then sleep with a peace of mind. I guess not these users making this big news (Though this is a blind guess, and could be totally wrong...)
- lelanthran 3y ago
  Actually you're on the money and I should have considered more context when making my previous reply. Those users (of which I used to be part of) find it a lot cheaper (almost negligible) to pay for things like RHEL instead of re-certifying. You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro?
  - stonith 3y ago
    > You do make me wonder, though, about who the vocal users are: RHEL is not important enough to license, but important enough to not move to a different distro? The scientific community, who run extremely high core counts and thus get a raw deal on licensing, but need the drivers for their hardware to be completely reliable as well as software compatability to work with anything from proprietary vendors that their community might need. Eg. CERN who are backing Alma linux.

9659 3y ago

At my previous employment, we used RHEL. Why? It is the only linux on the governments list of "security acceptable software products". And lot's of CentOS. Mainly for development. If I needed a virtual machine to troubleshoot something, I would make a CentOS one. A lot easier to not worry about the license keys. Same for build machines and temp lab setup machines, CentOS was quick to set up. Delivered machines required RHEL. The others did not.