4 ms·

The catch with switching from RHEL to SUSE (or Ubuntu, or whatever), is what does your vendor support? Big fancy medical records software at the hospital? It u

The catch with switching from RHEL to SUSE (or Ubuntu, or whatever), is what does your vendor support? Big fancy medical records software at the hospital? It used to run on either RHEL or CentOS. They stopped supporting 8. They won't do stream. You only have to buy one Red Hat License (unless you want to run CentOS 7.9 for the next 11-12 months), and it's tiny in comparison to what the actual software license and support costs, and we won't even get into the hardware that you're required to buy.

thesuperbigfrog 3y ago
>> what does your vendor support? Will your vendor be buying RHEL to develop their product? Anyone developing products for RHEL will now need to buy RHEL licenses unless Rocky Linux / Alma Linux are able to maintain 100% compatibility. This will probably make the RHEL ecosystem more expensive for everyone using it.
- totallywrong 3y ago
  https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux https://developers.redhat.com/articles/faqs-no-cost-red-hat-...
  - bluedino 3y ago
    > The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities
    - TheNewsIsHere 3y ago
      That page also makes it pretty clear where Red Hat is going generally. The idea of a business is effectively caged to “enterprise”. Sounds like IBM.
    - Hfdlmsh 3y ago
      There is a different subscription for "Teams", aka business use.
oneplane 3y ago
This is why I try to avoid healthcare and banking etc. Too much legacy vendor stuff which is hard to modernise. This whole "supported distro" stuff wouldn't matter if they just packaged their software in the shape of a container, even with container persistence. No more "required" distros. They would probably still have some CPU feature requirements and maybe a kernel version support range.
- TheNewsIsHere 3y ago
  Containers don’t necessarily solve this challenge. Containers still run (on top of) an OS. What you want in EMR and banking is stability and reliability. Validating your logic against a stable, consistent suite of APIs, binaries, etc is a basic building block of those use cases. The industry would ask the same of containers. You could take a more abstract approach instead, but you’re really just passing the validation and certification buck around the stack.
  - oneplane 3y ago
    If they deliver their EMR as a container, it no longer matters what host OS it runs on because the container doesn't have to interact with it. Just like RHEL doesn't have to care if it runs on AMD or Intel or if it is virtual or physically hosted, or if the RAM is from Samsung or Micron. And if it needs to talk to a database, say, Oracle, it really doesn't care if it's oracle on Oracle Linux or oracle on SunOS, or if it's in the same rack, or even hall. It just wants to talk to oracle, and it probably has a latency and TNS requirement and that's about it from the hosts's perspective. With 'install my package in a userland' you bind to the userland. But with 'run my container' you only bind to a container runtime, which has a very small and very portable interface in comparison. So no, I don't think the host OS would be relevant at all in a containerised case, as long as it can run containers. As for the userland inside the container: that's up to the EMR provider to choose and deliver. Instead of delivering RPMs you'd get OCI images (or tgz images). In a way, it would work the same way an OVA delivery would work, but smaller and more portable. In some other markets this is already done for WMS software for example, albeit using outdated methods like having a Swarm dependency so you're still runtime-locked.

thesuperbigfrog 3y ago

>> what does your vendor support? Will your vendor be buying RHEL to develop their product? Anyone developing products for RHEL will now need to buy RHEL licenses unless Rocky Linux / Alma Linux are able to maintain 100% compatibility. This will probably make the RHEL ecosystem more expensive for everyone using it.

totallywrong 3y ago
https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux https://developers.redhat.com/articles/faqs-no-cost-red-hat-...
- bluedino 3y ago
  > The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities
  - TheNewsIsHere 3y ago
    That page also makes it pretty clear where Red Hat is going generally. The idea of a business is effectively caged to “enterprise”. Sounds like IBM.
  - Hfdlmsh 3y ago
    There is a different subscription for "Teams", aka business use.

oneplane 3y ago

This is why I try to avoid healthcare and banking etc. Too much legacy vendor stuff which is hard to modernise. This whole "supported distro" stuff wouldn't matter if they just packaged their software in the shape of a container, even with container persistence. No more "required" distros. They would probably still have some CPU feature requirements and maybe a kernel version support range.

TheNewsIsHere 3y ago
Containers don’t necessarily solve this challenge. Containers still run (on top of) an OS. What you want in EMR and banking is stability and reliability. Validating your logic against a stable, consistent suite of APIs, binaries, etc is a basic building block of those use cases. The industry would ask the same of containers. You could take a more abstract approach instead, but you’re really just passing the validation and certification buck around the stack.
- oneplane 3y ago
  If they deliver their EMR as a container, it no longer matters what host OS it runs on because the container doesn't have to interact with it. Just like RHEL doesn't have to care if it runs on AMD or Intel or if it is virtual or physically hosted, or if the RAM is from Samsung or Micron. And if it needs to talk to a database, say, Oracle, it really doesn't care if it's oracle on Oracle Linux or oracle on SunOS, or if it's in the same rack, or even hall. It just wants to talk to oracle, and it probably has a latency and TNS requirement and that's about it from the hosts's perspective. With 'install my package in a userland' you bind to the userland. But with 'run my container' you only bind to a container runtime, which has a very small and very portable interface in comparison. So no, I don't think the host OS would be relevant at all in a containerised case, as long as it can run containers. As for the userland inside the container: that's up to the EMR provider to choose and deliver. Instead of delivering RPMs you'd get OCI images (or tgz images). In a way, it would work the same way an OVA delivery would work, but smaller and more portable. In some other markets this is already done for WMS software for example, albeit using outdated methods like having a Swarm dependency so you're still runtime-locked.