Until one day we get that coveted Kiwi distro I want to ask if any other kiwis had some suggestions after NixOS is now fucked probably even for the end user. I've used it for years because I want something I can install lots of stuff on and have it not fuck itself. It didn't matter what packages I threw at it dependencies were mangaged neatly enough that when updating one day a program I use daily wouldn't break like they would Arch, Gentoo, Ubuntu, etc.
I've always liked the idea of Debian stable, but I'd find I need one too many packages to be on the latest version meaning I'd have to go through too much effort installing/maintaining random debs or through source instead of using the package manager properly.
I don't have recent experience, but I did run Debian testing on one machine about a decade ago for a couple of years, updating it regularly. This wasn't in the middle of a major KDE (which I used at the time) version shift, so there really wasn't that much to break, and things basically seemed to work fine. Occasionally you would update the package lists and run 'upgrade' and get told that something important-sounding was going to be uninstalled, but it didn't take too much common sense to just leave it a few days and then try again in those cases.
I imagine you could do the same with testing today, as long as you do backups (gaaaaaaaaaaaay) or have a handy boot USB to fix up anything messed up.
I found an intriguing post on the Devuan forums about someone who has really
taken this process to the logical extreme.
He asserts that, to avoid being stuck with an unstable system in the case of a set of bad packages, he runs a system where he can boot to either the previous stable version, stable, testing, or unstable ('ceres', the equivalent of Debian 'sid'). To the degree I understand what he's aiming at, he would have a home partition shared by all systems, an oldstable root partition that could pretty much be left alone, a stable root partition where he could run the security updates but otherwise avoid using (and be able to use it as a template to copy over testing and unstable at any time), and then partitions for testing and unstable. He then runs most of the time in unstable, but by using chroot is able to keep his stable and testing systems up to date (without having to manually boot into them to do so) in case he has to drop down to them.
I have a bit of trouble visualizing how his booting would be set up so that it doesn't get fucked up by having multiple systems updating the GRUB config. I think there are two ways:
- one way you would use MBR/BIOS booting/partition tables and have a boot partition for each system/release version. GRUB would be installed in the MBR, with a config that doesn't boot any system directly, but just chainloads to the GRUB installs maintained by each release in their boot partitions. Each release version would just maintain it's own boot partitions. You'd never have to touch the MBR copy of GRUB unless you wanted to rename the initial boot options.
- you can also tell grub to inline load grub.cfg config files from other locations, so in theory you could just have one of the release versions' set up to do the actual installs to the UEFI partition (presumably the stable release) and the others never actually installing directly but being pulled in when you manually ran grub-install from a chroot to that release. I imagine this could be tricky with UEFI but I'm sure it could be made to work with a bit of trial and error.
It's tempting to mess around with this idea the next time I get a new old laptop with a bit of storage space available.
