3 ms·

> from every parts vendor for the servers we built for them that they would keep making those parts for at least a decade and do main vendors (amd, intel, nvid

> from every parts vendor for the servers we built for them that they would keep making those parts for at least a decade and do main vendors (amd, intel, nvidia, whoever build motherboards) provide guarantees that they continue production of specific version of product for the decade? > They also demanded RHEL exclusively. It's a great example of how extreme stability is there evidence that rhel is more stable than debian?

PlutoIsAPlanet 3y ago
> is there evidence that rhel is more stable than debian? Well, yes Debian versions are supported for 3 years, RHEL for 10+. "Stability" means changes, not crashes (although they can be caused by changes). A piece of software compiled 10 years ago will still run today and the systems can continue to get security updates, without needing to change the rug.
- riku_iki 3y ago
  > Well, yes Debian versions are supported for 3 years, RHEL for 10+. if upgrade path is easy and stable, it is obviously more sustainable to upgrade versions every N years, compared to situation when you got 10yo EOL infra far behind mainline with no clear way to support it in the future.
  - asoneth 3y ago
    > it is obviously more sustainable to upgrade versions every N years I've heard this kind of thing before, but it's worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to. Testing field upgrades takes years and the rollout often takes a year or more. There are hundreds of different teams involved and every one of them wants to ensure they don't miss the thing that bricks a submarine, satellite, transmission line, or IRS portal. If you can do this half or a quarter as often you can save taxpayers tens if not hundreds of millions of dollars. And in a surprising number of cases the software is never upgraded for the ~25 year or so lifetime of the hardware because the cost of the upgrade is comparable to the cost of buying new hardware. Sometimes that means some poor development team backports security patches for antique versions of DOS or Unix, but in more cases than you'd think they just airgap the computers and hope for the best.
    - donkeyd 3y ago
      > worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to. I worked on a government project where new software was being built on COBOL because they had those devs available. No commercial company in their right mind would build any new applications in COBOL, but government is a different animal.
      - rincebrain 3y ago
        New projects, perhaps not. But given the number of COBOL platforms available that have dwindling numbers of maintainers, someone with that skillset can demand a very decent chunk now, I'm told.
  - freeopinion 3y ago
    It's not that simple. Sometimes you care less about the OS than you care about the app. If your app vendor built against a specific version of an OS, you can't just upgrade the OS. You have to stick with the original OS to keep the support contract from your app vendor.
jonquest 3y ago
It doesn't matter if it's _more_ stable. It is stable, it's backed by commercial support from the same company that produces it and there is a financial incentive for that same commercial entity to make good on their promises of support and stability. This isn't a knock at Debian in any way and has nothing to do about whether or not it's more stable (in terms of uptime) or not.
bandrami 3y ago
For specific product lines, yes. There's a list of those parts DoD keeps. Anything off that list we have to get either the vendor's guarantee to keep making them or the supplier's attestation that they have N of them on hand. In terms of stability, as others have pointed out all that means is "the vendor won't change it and will keep providing it"
Spooky23 3y ago
> and do main vendors (amd, intel, nvidia, whoever build motherboards) provide guarantees that they continue production of specific version of product for the decade? Yes. Certain SKUs can be available for surprisingly long times. When you make that part of the RFP or whatever, you get models with that guarantee. For a specific use case where this mattered, my team procured a bunch of HPE servers and storage with a 10 year service commitment with a defined resolution time. So parts are pre-positioned and physical repairs will made within 4 hours. Drivers and such are required to be supported for that time as well. > is there evidence that RHEL is more stable than Debian? RHEL releases are fully supported (including fixes etc) for 10 years. Debian targets a 5 year lifecycle. There’s nothing wrong with Debian. But just like an enthusiast who wants to live in the edge wouldn’t be happy with Debian (because it’s too stable!), a F500 wouldn’t be for their own reasons.
worthless-trash 3y ago
> is there evidence that rhel is more stable than debian? Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years (from https://wiki.debian.org/LTS https://wiki.debian.org/LTS) RHEL 7 is 10 years, and probably a little longer after their recently announced EL7 lifecycle extension ( from: https://access.redhat.com/support/policy/updates/errata/ https://access.redhat.com/support/policy/updates/errata/ )

PlutoIsAPlanet 3y ago

> is there evidence that rhel is more stable than debian? Well, yes Debian versions are supported for 3 years, RHEL for 10+. "Stability" means changes, not crashes (although they can be caused by changes). A piece of software compiled 10 years ago will still run today and the systems can continue to get security updates, without needing to change the rug.

riku_iki 3y ago
> Well, yes Debian versions are supported for 3 years, RHEL for 10+. if upgrade path is easy and stable, it is obviously more sustainable to upgrade versions every N years, compared to situation when you got 10yo EOL infra far behind mainline with no clear way to support it in the future.
- asoneth 3y ago
  > it is obviously more sustainable to upgrade versions every N years I've heard this kind of thing before, but it's worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to. Testing field upgrades takes years and the rollout often takes a year or more. There are hundreds of different teams involved and every one of them wants to ensure they don't miss the thing that bricks a submarine, satellite, transmission line, or IRS portal. If you can do this half or a quarter as often you can save taxpayers tens if not hundreds of millions of dollars. And in a surprising number of cases the software is never upgraded for the ~25 year or so lifetime of the hardware because the cost of the upgrade is comparable to the cost of buying new hardware. Sometimes that means some poor development team backports security patches for antique versions of DOS or Unix, but in more cases than you'd think they just airgap the computers and hope for the best.
  - donkeyd 3y ago
    > worth considering that utility, government, and infrastructure software may be under different kinds of constraints than what you're used to. I worked on a government project where new software was being built on COBOL because they had those devs available. No commercial company in their right mind would build any new applications in COBOL, but government is a different animal.
    - rincebrain 3y ago
      New projects, perhaps not. But given the number of COBOL platforms available that have dwindling numbers of maintainers, someone with that skillset can demand a very decent chunk now, I'm told.
- freeopinion 3y ago
  It's not that simple. Sometimes you care less about the OS than you care about the app. If your app vendor built against a specific version of an OS, you can't just upgrade the OS. You have to stick with the original OS to keep the support contract from your app vendor.

jonquest 3y ago

It doesn't matter if it's _more_ stable. It is stable, it's backed by commercial support from the same company that produces it and there is a financial incentive for that same commercial entity to make good on their promises of support and stability. This isn't a knock at Debian in any way and has nothing to do about whether or not it's more stable (in terms of uptime) or not.

bandrami 3y ago

For specific product lines, yes. There's a list of those parts DoD keeps. Anything off that list we have to get either the vendor's guarantee to keep making them or the supplier's attestation that they have N of them on hand. In terms of stability, as others have pointed out all that means is "the vendor won't change it and will keep providing it"

Spooky23 3y ago

> and do main vendors (amd, intel, nvidia, whoever build motherboards) provide guarantees that they continue production of specific version of product for the decade? Yes. Certain SKUs can be available for surprisingly long times. When you make that part of the RFP or whatever, you get models with that guarantee. For a specific use case where this mattered, my team procured a bunch of HPE servers and storage with a 10 year service commitment with a defined resolution time. So parts are pre-positioned and physical repairs will made within 4 hours. Drivers and such are required to be supported for that time as well. > is there evidence that RHEL is more stable than Debian? RHEL releases are fully supported (including fixes etc) for 10 years. Debian targets a 5 year lifecycle. There’s nothing wrong with Debian. But just like an enthusiast who wants to live in the edge wouldn’t be happy with Debian (because it’s too stable!), a F500 wouldn’t be for their own reasons.

worthless-trash 3y ago

> is there evidence that rhel is more stable than debian? Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years (from https://wiki.debian.org/LTS https://wiki.debian.org/LTS) RHEL 7 is 10 years, and probably a little longer after their recently announced EL7 lifecycle extension ( from: https://access.redhat.com/support/policy/updates/errata/ https://access.redhat.com/support/policy/updates/errata/ )