3 ms·

It won't be a popular answer, but the truth is nuke and pave every so often. The problem isn't Arch itself, the problem is that I like to try new things pretty

It won't be a popular answer, but the truth is nuke and pave every so often. The problem isn't Arch itself, the problem is that I like to try new things pretty regularly, and occasionally install junk that I don't want long-term, but that I forget to clean up. Quite a few years back I just started a bash script that stays in my dot files repo, that has all the base packages and configuration in it that I need for a new system. When it's time for a fresh install, I can run that script and have 95% of my system set up. I even include gnome settings and stuff in there using the CLI tools.

yjftsjthsd-h 2y ago
In fairness, that's not an issue with the OS - you can maintain a single install for a long time (see other comments in this thread running a continuous Arch system for over a decade), but equally nothing prevents you from accumulating mutations until it's easier to reinstall the whole thing, and Arch is probably more popular with folks who are inclined to tinker:) And to be clear, I say that without judgement - I've gotten better at not messing up my system over time, and for that matter knowing when something is likely to break things and so test in a VM or whatever, but a lot of my knowledge of how things work comes from having done terrible things to poor innocent machines. Of course, I've always been an incorrigible distro-hopper, so I always just took that as part of the lifecycle: Install shiny new OS, kick the tires, use it for a while, slowly accumulate hacks until the thing is slightly broken, then wipe and install the new shiny OS. It's just that after enough years, it takes longer and longer for it to get slightly broken:)
cookiengineer 2y ago
For this very reason I wish there was a different flag for pacman, which would allow to effectively differ between packages installed for the base system itself, and for the local packages that can be installed and wiped without bricking the system afterwards. Similar to how a rootless system works on MacOS, where restoring the OEM state involves just wiping the folders (e.g. /usr/local) with the differences that override changes to the base system. But for that to work, we desperately need a different POSIX incompatible filesystem structure, because /etc/ has to become /local/etc or something like that. /usr/local is theoretically there but on most distributions /sbin and others are just symbolic links these days, so they are pretty much pointless.

yjftsjthsd-h 2y ago

In fairness, that's not an issue with the OS - you can maintain a single install for a long time (see other comments in this thread running a continuous Arch system for over a decade), but equally nothing prevents you from accumulating mutations until it's easier to reinstall the whole thing, and Arch is probably more popular with folks who are inclined to tinker:) And to be clear, I say that without judgement - I've gotten better at not messing up my system over time, and for that matter knowing when something is likely to break things and so test in a VM or whatever, but a lot of my knowledge of how things work comes from having done terrible things to poor innocent machines. Of course, I've always been an incorrigible distro-hopper, so I always just took that as part of the lifecycle: Install shiny new OS, kick the tires, use it for a while, slowly accumulate hacks until the thing is slightly broken, then wipe and install the new shiny OS. It's just that after enough years, it takes longer and longer for it to get slightly broken:)

cookiengineer 2y ago

For this very reason I wish there was a different flag for pacman, which would allow to effectively differ between packages installed for the base system itself, and for the local packages that can be installed and wiped without bricking the system afterwards. Similar to how a rootless system works on MacOS, where restoring the OEM state involves just wiping the folders (e.g. /usr/local) with the differences that override changes to the base system. But for that to work, we desperately need a different POSIX incompatible filesystem structure, because /etc/ has to become /local/etc or something like that. /usr/local is theoretically there but on most distributions /sbin and others are just symbolic links these days, so they are pretty much pointless.