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’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.
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 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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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’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’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.
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 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.
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.