8 ms·

Debian offers around three years of support. Ubuntu LTS around five. Both pale in comparison with Red Hat and, by proxy, CentOS.

mmrezaie 6y ago
Honestly that support is meaningless for some areas I know. In our Data Center we have hit problems with old packages and at the end you will end up with a lot of your own packages. In the end I find Debian to be a good base, and you build the rest by yourself. Even though I use Fedora for Desktop, I always have a feeling Debian is the server choice which I can extend further.
joana035 6y ago
Right, but the price one pays are outdated packages. CentOS 8 was released few days ago with kernel 4.18, which not even LTS is, and is older than the current Debian stable kernel(!). If you need to install anything besides the base distro you need elrepo, epel, etc which I'm not sure can be counted as part of the support.
- citiguy 6y ago
  Agreed, the packages in Centos / RHEL are all super old. The RHEL license structure changes all the time and depending on which one you get it may or may not include the extended repos.
- CoolGuySteve 6y ago
  The patch delta for security fixes must get larger over time as these packages age further and further away from top of tree. I always wonder how many major vulnerabilities are introduced into these super old distros due to backporting bugs.
  - jtl999 6y ago
    Documented cases don't seem to be common, but what comes to mind is the Debian "weak keys" scandal (2008), and the VLC "libeml" vulnerability (2019)[1] [1]: https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security_issue/ https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security...
    - joana035 6y ago
      OpenSSL upstream was almost abandoned during those days. Software are always gonna have bugs, it's written by humans after all. The important thing is to acknowledge and work towards an ideal outcome.
    - kasabali 6y ago
      Xweak keys" didn't have anything to do with backporting fixes to older versions. It was introduced into the version in sid at the time.
  - bonzini 6y ago
    It's the opposite. Plenty of subsystems in the RHEL 8.3 kernel are basically on par with upstream 5.5 or so, as almost all the patches are backported. The source code is really the same to a large extent, and therefore security fixes apply straightforwardly.
    - CoolGuySteve 6y ago
      That's great but what about all the other packages?
      - bonzini 6y ago
        The upstream for most other packages generally move much more slowly than the kernel. The fast ones (e.g. X11, systemd, QEMU) are typically rebased every other update or so (meaning, roughly once a year). It also helps that Red Hat employs a lot of core developers for those fast moving packages. :)
    - Tom4hawk 6y ago
      So, why is RHEL not using the upstream kernel? It would allow them to avoid those issues with rust&go (and probably other software): https://news.ycombinator.com/item?id=25447752 https://news.ycombinator.com/item?id=25447752
      - waheoo 6y ago
        Security audit / certification would be my guess.
      - bonzini 6y ago
        RHEL maintains a stable ABI for drivers. Plus, there are changes (especially around memory management or scheduling) that are fiendishly hard to do regression testing on, so they are backported more selectively.
- naniwaduni 6y ago
  That's not a price, that's a feature. If your use case doesn't consider avoiding noncritical behaviour changes for a decade to be a feature, you have other options.
- syshum 6y ago
  if you need epel, or quicker life cycles then CentOS Stream should be just fine for you as well People that run CentOS in prod are normally running ERP systems, Databases, LoB Apps, etc, and the only thing we need is the base distro and the the vendor binaries for what ever is service/app that needs to be installed, and probably an old ass version is JDK... We need every bit of that 10 year life cycle, and we glad that we will probably only have to rebuild these systems 2 or 3 times in our career before we pass the torch to the next unlucky SOB that has to support an application that was written before we were born... that is CentOS Administration ;)
- dralley 6y ago
  RHEL kernel versions are basically incomparable with vanilla kernel versions. They have hardware support and occasionally entire new features that have been backported from newer kernels in addition to the standard security & stability patches. This means that RHEL 7 using a "kernel version" from 2014 will still work fine with modern hardware for which drivers didn't even exist in 2014.
  - the8472 6y ago
    That is not a good thing. RH frankenkernels can contain subtle breakage. E.g. the Go and Rust standard libraries needed to add workarounds because certain RH versions implemented copy_file_range in a manner that returns error codes inconsistent with the documented API because patches were only backported for some filesystems but not for others. These issues never occurred on mainline. And for the same reasons that the affected users chose a "stable" and "supported" distro they were also unable to upgrade to one where the issue was fixed.
    - deleted 6y ago
      [deleted]
    - dralley 6y ago
      True, but it is a matter of weighing risks. I can't find it now, but I remember a few years ago there was a news story about how an update to Ubuntu had caused hospitals to start rendering MRI scan results differently due to differences in the OpenGL libraries. For those sorts of use cases, stable is the only option.
      - smarx007 6y ago
        I think this is a perfect use case for CentOS/RHEL as opposed to Ubuntu when the machine has only one job and nothing shall stand in its way, ie when you expect everything to be bug-for-bug compatible. But I fail to understand why a vendor of an MRI machine charging tens of thousands for installation/support cannot provide a supported RHEL OS which costs $180-350/yr in the cheapest config [1]. [1]: https://www.redhat.com/en/store/linux-platforms https://www.redhat.com/en/store/linux-platforms
- houseofzeus 6y ago
  The kind of people that are up in arms that CentOS 8 isn't going to be supported through to 2029 are using it because it has outdated packages.
unethical_ban 6y ago
Arguably, no one should be running a server that long in 2020. I would say a better reason is that while both are Linux distributions, they are distinct dialects and ecosystems. It isn't impossible to switch, but for institutions that have complex infrastructure built around the RHEL world, it is a lot of work to convert.
- joana035 6y ago
  > Arguably, no one should be running a server that long in 2020 The main reason people choose Linux is due to its stability. It is totally ok to run servers in 2020. Also your statement seems the default cloud vendor lingo used to push people to adopt proprietary technology with high vendor lock-in.
  - mdeeks 6y ago
    I think they only meant "that long". In other words, not for 5+ years without an upgrade. Not that you shouldn't run them at all. Not everything can be highly ephemeral or a managed service, so running servers yourself is totally okay like you said.
    - joana035 6y ago
      You are right, I misunderstood his message.
  - that_guy_iain 6y ago
    Honestly, 10 years is a long time for a server. I would be honestly surprised if a server lasted 10 years. But I agree I also get the tone of "servers should be cattle and not pets, just kill them and build a new one". Which can also be done on bare metal if you're using vms/containers. It seems like most people forget these cloud servers need to run on bare metal.
    - bcrosby95 6y ago
      Really? We've colocated our servers for the past 18 or so years. We have about 40. The oldest is around 17 years old. Our newest server is 9 years old. Our average server age is probably around 13 years old. The most common failure that completely takes them out of commission is a popped capacitor on the motherboard. Never had it happen before the 10 year mark. Never had memory failure. Have had disk failures, but those are easy to replace. Had one power supply failure, but it was a faulty batch and happened within 2 years of the server's life.
geofft 6y ago
Debian eLTS offers 7 years: https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended That said, if you're really in the position of depending on a free project for over five years of security support, you probably will be totally fine with just ignoring the fact it's out of support. Just keep running Debian 6 for a decade, whatever. The code still runs. Pretend you've patched. Sure, there are probably some vulnerabilities, but you haven't actually looked to see if the project you're actually using right now has patched all the known vulnerabilities, have you? (Spoiler, it hasn't: https://arxiv.org/abs/0904.4058 https://arxiv.org/abs/0904.4058)
goodpoint 6y ago
This is false. Debian provides LTS with a 5-years timespan. [1] And there is even commercial support for Extended LTS now [2] Also, it's worth noticing that Debian provides security backports for a significantly larger set of packages and CPU architectures than other distributions. [1] https://wiki.debian.org/DebianReleases https://wiki.debian.org/DebianReleases [2] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended
- tmoravec 6y ago
  Good catch, I stand corrected. But the point still holds - five (or even seven) years is still not match for Red Hat.
- antoncohen 6y ago
  Do you trust Debian LTS? As much as RHEL? The documentation about Debian LTS always made me think it is not a fully fledged thing. I've always felt like Debian releases reached EOL on their EOL date, not their LTS EOL date. > Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. https://wiki.debian.org/LTS https://wiki.debian.org/LTS
uep 6y ago
Do you know something I don't? A few years back, Debian changed their LTS policy to 5 years in response to Ubuntu. > Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. > Thus the Debian LTS team takes over security maintenance of the various releases once the Debian Security team stops its work. https://wiki.debian.org/LTS https://wiki.debian.org/LTS

mmrezaie 6y ago

Honestly that support is meaningless for some areas I know. In our Data Center we have hit problems with old packages and at the end you will end up with a lot of your own packages. In the end I find Debian to be a good base, and you build the rest by yourself. Even though I use Fedora for Desktop, I always have a feeling Debian is the server choice which I can extend further.

joana035 6y ago

Right, but the price one pays are outdated packages. CentOS 8 was released few days ago with kernel 4.18, which not even LTS is, and is older than the current Debian stable kernel(!). If you need to install anything besides the base distro you need elrepo, epel, etc which I'm not sure can be counted as part of the support.

citiguy 6y ago
Agreed, the packages in Centos / RHEL are all super old. The RHEL license structure changes all the time and depending on which one you get it may or may not include the extended repos.
CoolGuySteve 6y ago
The patch delta for security fixes must get larger over time as these packages age further and further away from top of tree. I always wonder how many major vulnerabilities are introduced into these super old distros due to backporting bugs.
- jtl999 6y ago
  Documented cases don't seem to be common, but what comes to mind is the Debian "weak keys" scandal (2008), and the VLC "libeml" vulnerability (2019)[1] [1]: https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security_issue/ https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security...
  - joana035 6y ago
    OpenSSL upstream was almost abandoned during those days. Software are always gonna have bugs, it's written by humans after all. The important thing is to acknowledge and work towards an ideal outcome.
  - kasabali 6y ago
    Xweak keys" didn't have anything to do with backporting fixes to older versions. It was introduced into the version in sid at the time.
- bonzini 6y ago
  It's the opposite. Plenty of subsystems in the RHEL 8.3 kernel are basically on par with upstream 5.5 or so, as almost all the patches are backported. The source code is really the same to a large extent, and therefore security fixes apply straightforwardly.
  - CoolGuySteve 6y ago
    That's great but what about all the other packages?
    - bonzini 6y ago
      The upstream for most other packages generally move much more slowly than the kernel. The fast ones (e.g. X11, systemd, QEMU) are typically rebased every other update or so (meaning, roughly once a year). It also helps that Red Hat employs a lot of core developers for those fast moving packages. :)
  - Tom4hawk 6y ago
    So, why is RHEL not using the upstream kernel? It would allow them to avoid those issues with rust&go (and probably other software): https://news.ycombinator.com/item?id=25447752 https://news.ycombinator.com/item?id=25447752
    - waheoo 6y ago
      Security audit / certification would be my guess.
    - bonzini 6y ago
      RHEL maintains a stable ABI for drivers. Plus, there are changes (especially around memory management or scheduling) that are fiendishly hard to do regression testing on, so they are backported more selectively.
naniwaduni 6y ago
That's not a price, that's a feature. If your use case doesn't consider avoiding noncritical behaviour changes for a decade to be a feature, you have other options.
syshum 6y ago
if you need epel, or quicker life cycles then CentOS Stream should be just fine for you as well People that run CentOS in prod are normally running ERP systems, Databases, LoB Apps, etc, and the only thing we need is the base distro and the the vendor binaries for what ever is service/app that needs to be installed, and probably an old ass version is JDK... We need every bit of that 10 year life cycle, and we glad that we will probably only have to rebuild these systems 2 or 3 times in our career before we pass the torch to the next unlucky SOB that has to support an application that was written before we were born... that is CentOS Administration ;)
dralley 6y ago
RHEL kernel versions are basically incomparable with vanilla kernel versions. They have hardware support and occasionally entire new features that have been backported from newer kernels in addition to the standard security & stability patches. This means that RHEL 7 using a "kernel version" from 2014 will still work fine with modern hardware for which drivers didn't even exist in 2014.
- the8472 6y ago
  That is not a good thing. RH frankenkernels can contain subtle breakage. E.g. the Go and Rust standard libraries needed to add workarounds because certain RH versions implemented copy_file_range in a manner that returns error codes inconsistent with the documented API because patches were only backported for some filesystems but not for others. These issues never occurred on mainline. And for the same reasons that the affected users chose a "stable" and "supported" distro they were also unable to upgrade to one where the issue was fixed.
  - deleted 6y ago
    [deleted]
  - dralley 6y ago
    True, but it is a matter of weighing risks. I can't find it now, but I remember a few years ago there was a news story about how an update to Ubuntu had caused hospitals to start rendering MRI scan results differently due to differences in the OpenGL libraries. For those sorts of use cases, stable is the only option.
    - smarx007 6y ago
      I think this is a perfect use case for CentOS/RHEL as opposed to Ubuntu when the machine has only one job and nothing shall stand in its way, ie when you expect everything to be bug-for-bug compatible. But I fail to understand why a vendor of an MRI machine charging tens of thousands for installation/support cannot provide a supported RHEL OS which costs $180-350/yr in the cheapest config [1]. [1]: https://www.redhat.com/en/store/linux-platforms https://www.redhat.com/en/store/linux-platforms
houseofzeus 6y ago
The kind of people that are up in arms that CentOS 8 isn't going to be supported through to 2029 are using it because it has outdated packages.

unethical_ban 6y ago

Arguably, no one should be running a server that long in 2020. I would say a better reason is that while both are Linux distributions, they are distinct dialects and ecosystems. It isn't impossible to switch, but for institutions that have complex infrastructure built around the RHEL world, it is a lot of work to convert.

joana035 6y ago
> Arguably, no one should be running a server that long in 2020 The main reason people choose Linux is due to its stability. It is totally ok to run servers in 2020. Also your statement seems the default cloud vendor lingo used to push people to adopt proprietary technology with high vendor lock-in.
- mdeeks 6y ago
  I think they only meant "that long". In other words, not for 5+ years without an upgrade. Not that you shouldn't run them at all. Not everything can be highly ephemeral or a managed service, so running servers yourself is totally okay like you said.
  - joana035 6y ago
    You are right, I misunderstood his message.
- that_guy_iain 6y ago
  Honestly, 10 years is a long time for a server. I would be honestly surprised if a server lasted 10 years. But I agree I also get the tone of "servers should be cattle and not pets, just kill them and build a new one". Which can also be done on bare metal if you're using vms/containers. It seems like most people forget these cloud servers need to run on bare metal.
  - bcrosby95 6y ago
    Really? We've colocated our servers for the past 18 or so years. We have about 40. The oldest is around 17 years old. Our newest server is 9 years old. Our average server age is probably around 13 years old. The most common failure that completely takes them out of commission is a popped capacitor on the motherboard. Never had it happen before the 10 year mark. Never had memory failure. Have had disk failures, but those are easy to replace. Had one power supply failure, but it was a faulty batch and happened within 2 years of the server's life.

geofft 6y ago

Debian eLTS offers 7 years: https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended That said, if you're really in the position of depending on a free project for over five years of security support, you probably will be totally fine with just ignoring the fact it's out of support. Just keep running Debian 6 for a decade, whatever. The code still runs. Pretend you've patched. Sure, there are probably some vulnerabilities, but you haven't actually looked to see if the project you're actually using right now has patched all the known vulnerabilities, have you? (Spoiler, it hasn't: https://arxiv.org/abs/0904.4058 https://arxiv.org/abs/0904.4058)

goodpoint 6y ago

This is false. Debian provides LTS with a 5-years timespan. [1] And there is even commercial support for Extended LTS now [2] Also, it's worth noticing that Debian provides security backports for a significantly larger set of packages and CPU architectures than other distributions. [1] https://wiki.debian.org/DebianReleases https://wiki.debian.org/DebianReleases [2] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended

tmoravec 6y ago
Good catch, I stand corrected. But the point still holds - five (or even seven) years is still not match for Red Hat.
antoncohen 6y ago
Do you trust Debian LTS? As much as RHEL? The documentation about Debian LTS always made me think it is not a fully fledged thing. I've always felt like Debian releases reached EOL on their EOL date, not their LTS EOL date. > Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. https://wiki.debian.org/LTS https://wiki.debian.org/LTS

uep 6y ago

Do you know something I don't? A few years back, Debian changed their LTS policy to 5 years in response to Ubuntu. > Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. > Thus the Debian LTS team takes over security maintenance of the various releases once the Debian Security team stops its work. https://wiki.debian.org/LTS https://wiki.debian.org/LTS