I regularly “deep freeze” or make read-only systems from Raspberry Pi, Ubuntu, Linux Mint LMDE and others Linux Distros whereas I disable automatic updates everywhere (except for some obvious config/network/hardware/subsystem changes I control separately).
I have had systems running 24/7 (no internet, WiFi) for 2-3 years before I got around to update/upgrade them. Almost never had an issue. I always expected some serious issues but the Linux package management and upgrade system is surprisingly robust. Obviously, I don’t install new software on a old system before updating/upgrading (learned that early on empirically).
Automatic updates are generally beneficial and helps avoid future compatibility/dependency issues on active systems with frequent user interaction.
However, on embedded/single purpose/long distance/dedicated or ephemeral application, (unsupervised) automatic updates may break how the custom/main software may interact with the platform. Causing irreversible issues with the purpose it was built for or negatively impact other parts of closed circuit systems (for example: longitudinal environmental monitoring, fauna and flora observation studies, climate monitoring stations, etc.)
Generally, any kind of update imply some level of supervision and testing, otherwise things could break silently without anyone noticing. Until a critical situation arises and everything break loose and it is too late/too demanding/too costly to try to fix or recover within a impossibly short window of time.
I disagree–a system (even Arch!) should be able to update after a couple months and not break! I recently booted an EndeavourOS image after 6 months and was able to update it properly, although I needed to completely rebuild the keyring first
I know this is how it’s supposed to be and how it should be but sadly it doesn’t always go this way and arch is notoriously known for this exact problem, the wiki itself tells you to check what’s being upgrades before doing because it might break. Arch is not stable if you don’t expect it to be unstable.
Arch and EndeavourOS are the same thing. There is no functional difference between using one or the other. They both use pacman and have the same repos.
Very true–the specific EOS repo has given me a bit of trouble in the past, but it takes like 3 commands to remove it and then you’ve got just arch (although some purests may disagree 🤣)
I’m using opensuse tumbleweed a lot - this summer I’ve found an installation not touched for 2 years. Was about to reinstall when I decided to give updating it a try. I needed to manually force in a few packages related to zypper, and make choices for conflicts in a bit over 20 packages - but much to my surprise the rest went smoothly.
Same with my arch install, didn’t touched it for 2 months even though laptop was turned off it decided to die when i launched it and run pacman -syu
I regularly “deep freeze” or make read-only systems from Raspberry Pi, Ubuntu, Linux Mint LMDE and others Linux Distros whereas I disable automatic updates everywhere (except for some obvious config/network/hardware/subsystem changes I control separately).
I have had systems running 24/7 (no internet, WiFi) for 2-3 years before I got around to update/upgrade them. Almost never had an issue. I always expected some serious issues but the Linux package management and upgrade system is surprisingly robust. Obviously, I don’t install new software on a old system before updating/upgrading (learned that early on empirically).
Automatic updates are generally beneficial and helps avoid future compatibility/dependency issues on active systems with frequent user interaction.
However, on embedded/single purpose/long distance/dedicated or ephemeral application, (unsupervised) automatic updates may break how the custom/main software may interact with the platform. Causing irreversible issues with the purpose it was built for or negatively impact other parts of closed circuit systems (for example: longitudinal environmental monitoring, fauna and flora observation studies, climate monitoring stations, etc.)
Generally, any kind of update imply some level of supervision and testing, otherwise things could break silently without anyone noticing. Until a critical situation arises and everything break loose and it is too late/too demanding/too costly to try to fix or recover within a impossibly short window of time.
I’d say that it’s your fault for running a system upgrade after 2 months and not expecting something to break but it’s not that unreasonable either
I disagree–a system (even Arch!) should be able to update after a couple months and not break! I recently booted an EndeavourOS image after 6 months and was able to update it properly, although I needed to completely rebuild the keyring first
I know this is how it’s supposed to be and how it should be but sadly it doesn’t always go this way and arch is notoriously known for this exact problem, the wiki itself tells you to check what’s being upgrades before doing because it might break. Arch is not stable if you don’t expect it to be unstable.
Arch and EndeavourOS are the same thing. There is no functional difference between using one or the other. They both use pacman and have the same repos.
Very true–the specific EOS repo has given me a bit of trouble in the past, but it takes like 3 commands to remove it and then you’ve got just arch (although some purests may disagree 🤣)
I’m using opensuse tumbleweed a lot - this summer I’ve found an installation not touched for 2 years. Was about to reinstall when I decided to give updating it a try. I needed to manually force in a few packages related to zypper, and make choices for conflicts in a bit over 20 packages - but much to my surprise the rest went smoothly.