3 ms·

To be fair, if you zoom out the timeline, Linux distros change userspace so much between releases I can't blame them. I know the new solutions are mostly for th

To be fair, if you zoom out the timeline, Linux distros change userspace so much between releases I can't blame them. I know the new solutions are mostly for the better, but it's a moving target.

hericium 5y ago
Linux is not macOS - you can patch/install security fix without forced UI redesign and configurability deprivation.
bravetraveler 5y ago
Long term support releases like those from Red Hat and Ubuntu aim to address this by not introducing breaking functionality in their releases Version 8.x or 22.y that you get won't change in their minor releases in terms of behavior. They save the breakage for N+1, such as 9.x and 23.y They go through a ton of effort to backport the security fixes. This keeps things generally way more predictable. Problems do happen (eg: misaligned symbols from partial updates/restarts), but they're not as common as one would assume
- mananaysiempre 5y ago
  My experience on desktop with Debian vs Arch is that I honestly can’t tell if the LTS approach makes things better or not. (I did run Red Hat once upon a time, but given that was even before it’s split into RHEL and Fedora, it was probably nothing like it is today in this respect.) Arch (or any other mostly-unpatched rolling distro, I expect—don’t know how, say, CentOS Stream does on the former point) requires constant tending, but every weekly or monthly update is pretty much painless. Sometimes one thing breaks, but usually with an accompanying warning, and if you put it there you know how to unbreak it. Upgrading and especially dist-upgrading Debian IME felt like you were running around putting out fires for a couple of hours every time, even if those upgrades were much rarer. (It’s like the old joke about regular paradise vs college paradise: in the regular one everything’s peachy except a man comes every evening and hammers a single nail up your arse, in the college one everything’s wonderful for months but then a man comes with a bucket of nails and tells you it’s the end of the semester.) I don’t know which ends up requiring more effort in the integral sense, and if that’s even the measure that matters, in particular on servers (even “pet” ones), I only know that I dread updating on a single Arch machine much less than I do a Debian one. I’m sure this won’t scale, but keeping a herd of like a homogeneous dozen servers on a rolling distro with a reproducible setup (Arch+aconfmgr, or hell, even NixOS unstable) doesn’t sound like an inherently stupid idea. (If you need ABI stability, e.g. if you’re running a proprietary database, none of this applies, but in such a case a rolling distro is probably not an option anyway for other reasons.)
  - bravetraveler 5y ago
    Thanks for taking the time to reply! dist-upgrades like you mention are where I would actually expect a little bit of that discomfort you mention. That's [if memory serves] where the 'major' upgrades come in (eg: 8 -> 9) where we'd expect some surprises. I hold the somewhat controversial opinion that CentOS Stream should be fine for most people, as you'd generally be hard pressed to notice differences between minor revisions [outside of compliance/certification efforts] I think the smaller upgrades are especially painful on Apt/deb based distributions. Updates tend to require some attention, if nothing else to answer this question: "Keep the modified configs, or accept the vendor defaults?" Those based on RPM tend to handle that case a little bit better in my experience. If a config is modified it's trusted, but the vendor configs are available as '.rpmnew' files. This way, if you find a problem - you have a way to find yourself back to comfort. While Apt can be configured similarly, it doesn't come that way [as far as I'm aware, on the big representations - Debian/Ubuntu] I can't say for other families as I haven't had quite the experience managing fleets of those! None of this is to say it's a 'magic bullet' of sorts. Some discipline is certainly still rewarded! There's usually tiers of environments where you try it out with fairly low stakes [such as development/integration areas], then you work your way up the pipeline to upgrading the thing that matters. Another approach is to simply replace the old with new. Depending on the elasticity of the environment you may favor one over the other.

To be fair, if you zoom out the timeline, Linux distros change userspace so much between releases I can't blame them. I know the new solutions are mostly for the better, but it's a moving target.

hericium 5y ago

Linux is not macOS - you can patch/install security fix without forced UI redesign and configurability deprivation.

bravetraveler 5y ago

Long term support releases like those from Red Hat and Ubuntu aim to address this by not introducing breaking functionality in their releases Version 8.x or 22.y that you get won't change in their minor releases in terms of behavior. They save the breakage for N+1, such as 9.x and 23.y They go through a ton of effort to backport the security fixes. This keeps things generally way more predictable. Problems do happen (eg: misaligned symbols from partial updates/restarts), but they're not as common as one would assume

mananaysiempre 5y ago
My experience on desktop with Debian vs Arch is that I honestly can’t tell if the LTS approach makes things better or not. (I did run Red Hat once upon a time, but given that was even before it’s split into RHEL and Fedora, it was probably nothing like it is today in this respect.) Arch (or any other mostly-unpatched rolling distro, I expect—don’t know how, say, CentOS Stream does on the former point) requires constant tending, but every weekly or monthly update is pretty much painless. Sometimes one thing breaks, but usually with an accompanying warning, and if you put it there you know how to unbreak it. Upgrading and especially dist-upgrading Debian IME felt like you were running around putting out fires for a couple of hours every time, even if those upgrades were much rarer. (It’s like the old joke about regular paradise vs college paradise: in the regular one everything’s peachy except a man comes every evening and hammers a single nail up your arse, in the college one everything’s wonderful for months but then a man comes with a bucket of nails and tells you it’s the end of the semester.) I don’t know which ends up requiring more effort in the integral sense, and if that’s even the measure that matters, in particular on servers (even “pet” ones), I only know that I dread updating on a single Arch machine much less than I do a Debian one. I’m sure this won’t scale, but keeping a herd of like a homogeneous dozen servers on a rolling distro with a reproducible setup (Arch+aconfmgr, or hell, even NixOS unstable) doesn’t sound like an inherently stupid idea. (If you need ABI stability, e.g. if you’re running a proprietary database, none of this applies, but in such a case a rolling distro is probably not an option anyway for other reasons.)
- bravetraveler 5y ago
  Thanks for taking the time to reply! dist-upgrades like you mention are where I would actually expect a little bit of that discomfort you mention. That's [if memory serves] where the 'major' upgrades come in (eg: 8 -> 9) where we'd expect some surprises. I hold the somewhat controversial opinion that CentOS Stream should be fine for most people, as you'd generally be hard pressed to notice differences between minor revisions [outside of compliance/certification efforts] I think the smaller upgrades are especially painful on Apt/deb based distributions. Updates tend to require some attention, if nothing else to answer this question: "Keep the modified configs, or accept the vendor defaults?" Those based on RPM tend to handle that case a little bit better in my experience. If a config is modified it's trusted, but the vendor configs are available as '.rpmnew' files. This way, if you find a problem - you have a way to find yourself back to comfort. While Apt can be configured similarly, it doesn't come that way [as far as I'm aware, on the big representations - Debian/Ubuntu] I can't say for other families as I haven't had quite the experience managing fleets of those! None of this is to say it's a 'magic bullet' of sorts. Some discipline is certainly still rewarded! There's usually tiers of environments where you try it out with fairly low stakes [such as development/integration areas], then you work your way up the pipeline to upgrading the thing that matters. Another approach is to simply replace the old with new. Depending on the elasticity of the environment you may favor one over the other.