Alternative to modules?
Alternative to modules?
Posted Oct 29, 2024 10:47 UTC (Tue) by taladar (subscriber, #68407)In reply to: Alternative to modules? by nim-nim
Parent article: Kadlčík: Copr Modularity, the End of an Era
Part of why it reappears is that many developers and stakeholders in companies fundamentally misunderstand the problem. They think the problem is "the system won't allow me to use an old version" when the actual problem is that the explosion in the number of interactions between versions means we literally don't have the people on Earth to test all the combinations of versions.
Posted Oct 29, 2024 11:10 UTC (Tue)
by dsommers (subscriber, #55274)
[Link] (4 responses)
From an ISV point of view ... the challenge is the gap between different wanted aspects. A customer installing a package from an ISV to be used in a production environment wants to run a long term stable system. They want to be sure their production environment is stable and does not require lots of efforts putting out fires regularly. RHEL provides 10 years support for each major release.
An ISV delivers a product, lets say it's built on a Python stack. This product will need to be able to work on a broad set of distributions and versions. If we for this example reduces the span to RHEL - The span can be as broad as from RHEL-7 (which went EOL in June this year, yes) to RHEL-9 ... there are 3 different Python versions in this span with the default distro Python stack - and a lifetime span of approx 15+ years, since RHEL major releases may overlap 4-5 years or so.
The customers wants the latest and greatest features in the ISV product - and the ISV will at some point need to say, "your distribution is too old". Because it becomes too hard to provide the same feature set across 3 different Python version stacks. It becomes hard because newer features the ISV product will depend on needs a newer Python stack.
And that's where the modules filled a real gap for ISVs. It enabled them to just tell customers to "enable the Python 3.11 module before installing our product". The customer would then have a long term stable system with fully supported packages from the ISV for the life time of the distribution.
Without modules, customers will need to upgrade much more frequently the base distro to be able to get the new ISV features they want to make use of. And that implicitly gives a shorter lifespan for the distribution itself, which gives more maintenance time and cost for the customer.
I am not saying that providing such kind of module support comes for free. I know there's a lot of efforts required, especially in the enterprise distribution segment, with QA, testing, support and maintenance. But that does not invalidate the argument that distro users have use cases where modules makes life a lot easier. The question is who is going to pay for this and how. Because long term stability itself, does have a cost - no matter product or project.
Posted Oct 30, 2024 9:38 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (3 responses)
I am not even convinced it lowers the maintenance costs because supporting such a wide range of versions has a huge cost both for all kinds of tools that have to work the same over the whole range of currently supported versions and also at the point of migration when, instead of doing the same well tested procedure you do regularly you essentially have to catch up with all the changes from many years and when something breaks you have a significantly harder time which of the <all packages on the system> you just updated caused the breakage. Not to mention the cost of backporting itself.
Posted Oct 30, 2024 10:12 UTC (Wed)
by dsommers (subscriber, #55274)
[Link] (2 responses)
May I ask you about your real-life experience running enterprise Linux distributions?
I've maintained public servers for about 25+ years, which has run everything from Slackware, Gentoo, Novell, Crux, Ubuntu, Fedora and RHEL (including clones) - and probably even a few more ones I've forgotten about. The last 15+ years, it's mostly been RHEL and clones of it. These servers has provided a broad variety of e-mail/collaboration services, web, database (pgsql, mariadb), VPN, proxy gateways, firewalls, VM hypervisors, etc.
My personal experience is that the enterprise Linux distributions (RHEL with clones, Novel SUSE) are quite hassle free and stable compared to the rest. When enabling auto-updating of security/bugfix updates, those servers just run. I take them for a reboot every 4-8 weeks, unless there are urgent/critical kernel/glibc updates. Not because I always need to do a reboot (one or two isolated internal hosts has many moths uptime), but to ensure they can boot cleanly and ensure the system configs are still correct. For those few situations where a reboot can't be done in a timely manner, kpatch can often do a reasonable job until the next reboot window.
The main difference between "ordinary" and enterprise distros is that the latter ones does go through a pretty good QA cycle before it hits its users. And still with QA, critical updates are made available within days after the discovery of the issue was done. This QA step is what results in a stable experience.
I barely spend time on (system) maintenance these days, compared to the days with the non-enterprise distros. Currently I'm responsible for keeping about 15-20 machines running, and spend around 4-8 hours per month on the pure system maintenance, which gives more time to actually maintain the service provided by these systems (mostly tackling various bruteforce attacks, etc). And while Ubuntu LTS is better than a lot of the other distros, in my experience, it comes nowhere near the stability I experience with RHEL and clones.
That's my experience at least. YMMV.
Posted Oct 30, 2024 14:00 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
My experience is that except for the recent freeradius patch which did change behavior and required admin intervention that an RHEL update has never broken anything on a production system that required a response so they are pretty safe and low risk to apply. I suppose some of the difference might be between systems which are use to tinker with and experiment with different organizing principals vs systems which only exist to run (commercial) workloads, you can use a more experimental system for work if you have the expertise and want to but for most the baseOS is boring and you don't want to have to think about it, you just want it to support your applications.
Posted Oct 31, 2024 9:27 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
About 20 years of maintaining various Linux server distros, mostly Debian, Ubuntu and RHEL/Centos out of which RHEL was by far the worst to support.
Alternative to modules?
Alternative to modules?
Alternative to modules?
Alternative to modules?
> That's my experience at least. YMMV.
Alternative to modules?