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?
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.
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.
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.
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.
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.
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.
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.
In terms of stability, as others have pointed out all that means is "the vendor won't change it and will keep providing it"
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)
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/ )
"Stability" in the RHEL sense is akin to ossification: you don't change anything, and then you can't change anything, and then you've got problems. The costs aren't necessarily as obvious as pursuing stability via dynamism, and in any case can often either be avoided by limiting the lifespan of the system as a whole or at least punted on to a successor.
For military applications, the trade off is even more intense: you build things hoping that they'll never be used, but knowing that they need to work when called upon. Stuff that'll be on the front line tomorrow can have a very different set of lifecycle guarantees from stuff that's got a planned life of 25 years but which (from experience) you know will probably still be around in 50.
Lots of redhat there.