Alternative to modules?
Alternative to modules?
Posted Oct 30, 2024 9:38 UTC (Wed) by taladar (subscriber, #68407)In reply to: Alternative to modules? by dsommers
Parent article: Kadlčík: Copr Modularity, the End of an Era
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?
> That's my experience at least. YMMV.
Alternative to modules?