4 ms·
»Defenders will counter that this is a necessary tradeoff – you can’t have both stability and being fully up-to-date on security fixes. I’m not convinced that’s
by cbmuser 3y ago
»Defenders will counter that this is a necessary tradeoff – you can’t have both stability and being fully up-to-date on security fixes. I’m not convinced that’s true as there are other Linux distributions that have shown you can have both. Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing. Additionally, distributions like Fedora Linux, while not technically a rolling release, do tend to hew close to upstream versions at a more regular cadence.«
I'm sorry, but this paragraph proves that the author has not fully understood the purpose of enterprise distributions.
The primary selling point is not the stability of the software, but the stability of the API and ABI. There is closed source software such as SAP that is compiled against the ABI of RHEL and SLES. And lots of expensive enterprise hardware ships Linux kernel drivers in binary form only, so that a stable, i.e. never-changing kernel ABI is required. Examples for such hardware is the SGI UV series whose drivers come in binary form only and therefore the hardware is supported on enterprise distributions only.
Both RedHat and SUSE put a lot of effort into keeping their API and ABI stable, so that enterprise customers are guaranteed that no distribution update is going to break the software that they're running on the hardware they're using.
Also, when you deploy Linux on hundreds or thousands of clients, a rolling release distribution would be a pure nightmare. Given the large amount of clients and applications, there will always be a combination of applications and use-cases that will break after a distribution package was updated to a completely new upstream version.
Companies don't want software that changes all the time since they want to control the time for an update rollout themselves.
- StillBored 3y agoRight, and part two, is that in the case of RHEL they backport features required to run on newer hardware, or enable things required for newer software stacks (crypto protocols for example). It just depends on whether its possible to maintain API/ABI stability and support the newer feature. Vs, the other LTS distros that just track the upstream LTS kernel. That kernel both breaks things, as well as is "old" because its only generally taking security and bug fixes.
- dralley 3y agoAlso when it comes to things like medical imaging, changes to the graphics stack (which includes userspace drivers) can and have altered how (e.g.) an MRI renders. So you can't go around making major updates to that stack every other week. It has to be certified and then re-certified after major updates and the vendor might need to be involved in that process. And you can't just skip it and "hope" that the MRI results are rendering properly. Expand that out to all the other similar kinds of applications.
- RMPR 3y agoI fully agree, moreover this: > Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing Shows the author hasn't used Tumbleweed for any reasonable amount of time himself[0][1][2]. I daily drove it for a short while before moving to Fedora. 0: https://github.com/Foundry376/Mailspring/issues/533 https://github.com/Foundry376/Mailspring/issues/533 1: https://forums.opensuse.org/t/tumbleweed-breaks-after-update/129478/5 https://forums.opensuse.org/t/tumbleweed-breaks-after-update... 2: https://www.reddit.com/r/openSUSE/comments/v09hnc/tumbleweed_breakk_too_much/ https://www.reddit.com/r/openSUSE/comments/v09hnc/tumbleweed...