3 ms·

My main experience with RedHat has been needing to bend over backwards to support its wildly outdated library versions. Because RedHat “supports” operating sys

My main experience with RedHat has been needing to bend over backwards to support its wildly outdated library versions. Because RedHat “supports” operating systems for about a decade, there’s always an argument that a library should be written to support whatever toolchain is provided by the oldest supported RHEL version. RHEL’s “support” should be seen as “your software will continue to run unmodified when on this system”, but is frequently interpreted as “this is a sane platform for current development”.

surge 4y ago
Current development was better done on Fedora, the upstream of RHEL, I think they were pretty clear that's what it was for. RHEL was for when you needed everything to work no matter what. Fedora was for new development and latest and greatest.
- MereInterest 4y ago
  The problem with needing “everything to work no matter what” is that it just doesn’t exist. The type of stability that RHEL provides is conditional on never using third-party libraries. RHEL backpoets security fixes to packages that it provides, but you’re on your own for anything else. For example, RHEL 7 was released in 2014, has production support for another year, and extended support until 2026. As libraries are requiring C++17 support today, maintaining compatibility with stock RHEL 7 requires running older versions of a library.
  - surge 4y ago
    That level of backwards compatiblity with legacy versions exists on other platforms (Windows, z/OS, AIX), especially those implemented in enterprise environments. If I have a Windows app written in Win32 API, it'll run on Windows 11 on 64-bit architecture. That's what companies want. That's how Linux became viable for those customers. Even Edge has an IE mode because that's what enterprise environments need, support for older libraries and APIs. I won't deny RHEL was higher technical debt for sure, but that was the trade off, because that's what enterprises prioritized, support, stability, and knowledge that an update during their monthly patch cycle and change window for rebooting the server won't break the business applications they rely on for fundamental operations, at least not on the same major release version. RHEL was never supposed to be the latest, I think even a every new major release they'd be on a kernel and library version that was 2 years behind but had been through its paces. IOW, it was a feature not a bug, and its what companies were paying for (their customers were boring legacy Fortune 500s not startups). As a business model, it was solid, and the most successful in the commercial market by far because it catered to their customers needs, even if they're not our own, even Ubuntu Server took pages from their book.
oblio 4y ago
They're talking about stuff that predates RHEL by half a decade.
- MereInterest 4y ago
  True, more adding it as agreement on RedHat being consistently and intentionally behind the curve.
int_19h 4y ago
For a while, Python binary wheels (packages) for Linux had a standard that was defined, essentially, in terms of RHEL (or rather, CentOS) as a baseline platform for this exact reason. https://peps.python.org/pep-0513/ https://peps.python.org/pep-0513/ https://peps.python.org/pep-0571/ https://peps.python.org/pep-0571/ https://peps.python.org/pep-0599/ https://peps.python.org/pep-0599/

surge 4y ago

Current development was better done on Fedora, the upstream of RHEL, I think they were pretty clear that's what it was for. RHEL was for when you needed everything to work no matter what. Fedora was for new development and latest and greatest.

MereInterest 4y ago
The problem with needing “everything to work no matter what” is that it just doesn’t exist. The type of stability that RHEL provides is conditional on never using third-party libraries. RHEL backpoets security fixes to packages that it provides, but you’re on your own for anything else. For example, RHEL 7 was released in 2014, has production support for another year, and extended support until 2026. As libraries are requiring C++17 support today, maintaining compatibility with stock RHEL 7 requires running older versions of a library.
- surge 4y ago
  That level of backwards compatiblity with legacy versions exists on other platforms (Windows, z/OS, AIX), especially those implemented in enterprise environments. If I have a Windows app written in Win32 API, it'll run on Windows 11 on 64-bit architecture. That's what companies want. That's how Linux became viable for those customers. Even Edge has an IE mode because that's what enterprise environments need, support for older libraries and APIs. I won't deny RHEL was higher technical debt for sure, but that was the trade off, because that's what enterprises prioritized, support, stability, and knowledge that an update during their monthly patch cycle and change window for rebooting the server won't break the business applications they rely on for fundamental operations, at least not on the same major release version. RHEL was never supposed to be the latest, I think even a every new major release they'd be on a kernel and library version that was 2 years behind but had been through its paces. IOW, it was a feature not a bug, and its what companies were paying for (their customers were boring legacy Fortune 500s not startups). As a business model, it was solid, and the most successful in the commercial market by far because it catered to their customers needs, even if they're not our own, even Ubuntu Server took pages from their book.

oblio 4y ago

They're talking about stuff that predates RHEL by half a decade.

MereInterest 4y ago
True, more adding it as agreement on RedHat being consistently and intentionally behind the curve.

int_19h 4y ago

For a while, Python binary wheels (packages) for Linux had a standard that was defined, essentially, in terms of RHEL (or rather, CentOS) as a baseline platform for this exact reason. https://peps.python.org/pep-0513/ https://peps.python.org/pep-0513/ https://peps.python.org/pep-0571/ https://peps.python.org/pep-0571/ https://peps.python.org/pep-0599/ https://peps.python.org/pep-0599/