I use a mixture of systemd-nspawn and different user logins. This is sufficient for experimentation, for actual use I try to package (makepkg) those tools to have them organized by my package manager.

Also LVM thinpools with snapshots are a great tool. You can mount a dedicated LV to each single user home to keep everything separated.

After many years of using multiple devices and even servers with Archlinux installed it never broke because of an update (spoiler: I use systemd-boot instead of grub). If a system is to be used by a less experienced user, just install linux-lts Kernel instead.

Unstable does not mean it crashes/breaks often, it just means it does not guarantee to not bump to the newest upstream version and that it does not do backports. This can be a problem when using unmaintaned software that does not like using a recent python/php.

This is also great because if you find a bug in a software you can report it to upstream directly. Debian maintainers only backport severe bugs, not every one of them. It can take over a year for new features to arrive - especially painful with applications like gimp, krita, blender, etc. You can use debian-unstable of course, which is close to upstream as well.

But…isn’t unsupervised backfeeding the same as simply overtraining the same dataset? We already know overtraining causes broken models.

Besides, the next AI models will be fed with the interactions from humans with AI, not just it’s own content. ChatGPT already works like this, it learns with every interaction, every chat.

And the generative image models will be fed with AI-assisted images where humans will have fixed flaws like anatomy (the famous hands) or other glitches.

So as interesting as this is, as long as humans interact with AI the hybrid output used for training will contain enough new “input” to keep the models on track. There are already refined image generators trained with their own but human-assisted output that are better than their predecessor.

GoogleTalk once federated with XMPP/jabber, good times until their userbase was big enough to deferedate again, crippling the jabber network. It will happen again if we let it.

Metas plan is to draw users into their network and use the fediverse as an initial catalyst (“look! so much content already there!”). Once their userbase is large enough, they will deferate again claiming protocol difficulties or something equally vague, but they will just want to start rolling out advertising which would not be displayed to users from other instances. Most users will not keep two accounts and jusy stay with the big corp and leave the original fediverse again.

Well, NASA trusts Linux enough to send it to Mars. They build rockets, so it should be good enough for flying busses. Unless you don’t trust your software engineers, but then having them build a custom microkernel OS instead sounds not much better.

systemd-path is the cleanest and most portable solution. You define a path service to watch your directory for changes and trigger another service to perform certain actions then. It uses inotify.

https://man.archlinux.org/man/systemd.path.5.en

Here is a full example from our currently so beloved redhat: https://www.redhat.com/sysadmin/introduction-path-units

Regardless of the distro, unless you use Kernel live patching (https://wiki.archlinux.org/title/Kernel_live_patching) you should boot a new Kernel when it is released by your distro with a security warning. Running unpatched old Kernels just for 100% uptime is not safe.

Oh and, I never had issues with Arch changing spontaneously - what event are you speaking of?

We use Ansible as well, it keeps all servers happily upgraded and all packages in working order - even the weirdest custom software instances. Nodjs is available as lts packages im arch and it, again, just works.

I have zero issues with upgrades on desktop and server except once last year when my old Core2Duo notebook I use in the kitchen did not suspend correctly for a whole week until the Kernel bug was fixed. (I ran linux-lts for a week, it was… smooth sailing).

During that time we had 3 failed migrations of old PHP software to the new Ubuntu LTS and were fighting almightly RHEL because it simply did not provide the packages the customer required - we are now running an Arch container on the RHEL box…

I know this discussion is a little bit like religion, and obviously luck and good circumstances play a role. We both speak from experience and OP can make their own decision.

Once a year there is a manual intervention. Last one was the repo merge, and that did not even break then. Before that… hmmm… I dont even remember.

On Desktop with nvidia and a lot of other AUR stuff it is more work, but the servers run smooth as butter.

I have a GPD micro running Archlinux just fine. HDMI was flaky, but I havent tested it in a while.

My vote is Archlinux. Debian is sometimes a little too “optimisitic” when backporting security fixes and upgrading from oldstable to stable always comes with manual intervention.

Release-based distros tend to be deployed and left to fend on their own for years - when it is finally time to upgrade it is often a large manual migration process depending on the deployed software. A rolling release does not have those issues, you just keep upgrading continuously.

Archlinux performs excellent as a lightweight server distro. Kernel updates do not affect VM hardware the same they do your laptop, so no issues with that. Same for drivers. It just, works.

Bonus: it is extremely easy to build and maintain your own packages, so administration of many instances with customized software is very convenient.