I think the least that distros can do, is allow listing all packages and system settings in config files like .toml, rather than having to type in every single package to install, or click through system setting GUIs to setup. Would that require using a whole programming language or system like NIx?
While NixOS works much differently from most distros, that’s the only reason I use it: package and system settings in text files. If I fix something, it’s fixed permanently, I don’t need to hunt down files in random directories if I want to change a setting. If I ever need to reinstall the OS I don’t have to write dnf install every single damn package and manually setup all that up all over again. Having daily-drove Windows macOS & Fedora as throughout the years, my setups have felt hacky as well as houses of cards as I’ve wanted or had to set them up again (I don’t mean Fedora specifically, but distros in general).
Basically it feels insane that it’s the way most linux users and servers in the world operate. If I, a humble computer hobbyist can figure out Nix, why don’t more users do so, and why is Nix so niche?
Why don’t distros support listing packages and system settings in text file(s)?
Short answer: Because it would be bad software design.
More detailed answer: I can definitely understand the feeling but a large part of it is that text files are not databases. Trying to use them for that purpose leads to quickly running into a brick wall of scalability problems. Seriously, that wall is hit faster than one might expect.
Why use a db in the first place? Well, when a package manager installs a package, it does a lot more than install files in their specified paths and store the name. Every package also has a ton of metadata. This includes everything from the software version number and versions that it obsoletes to repo that the package is from to signatures to verify package authenticity and checksums to verify file integrity.
Storing all of this info is the sort of thing that databases excell at and text flatfiles are terrible at. The db also includes integrity checks for itself. Since the data is already stored in a db, also storing even a subset in a flatfile would be poor software design as it is unnecessarily wasting storage space in a manner that would perform significantly worse and is much more prone to data integrity failures.
So, how do you work around that for backup? Just script a dump of the installed packages from the package manager. It’s trivial with apt and dnf/yum. Then, store it with dot files in your backups.
To restore, I’d recommend Ansible because it works nicely with lists of packages and has minimal dependencies.
If you don’t want to interact with the package manager and like domain specific languages (or don’t dislike the syntax), just use Nix and be done with it. Noone whose opinion matters is going to bully you for the choice. If, like me, you strongly dislike DSLs and the Nix syntax, the choices are pretty much Fedora Atomic, GUIX, and/or Ansible.
<packagemanager1> list >> apps.txt<packagemanager2> list >> apps.txt<packagemanager3> list >> apps.txt…dpkg --get-selectionsIt has been part of my backup scripts since forever. And of course backing up
/etcis possible on every distribution.For what its worth, many package managers support some method of exporting a list of installed packages to a file (or in a way that can be easily piped to a file), and its not difficult to pipe a file of packages into a shell loop to get the behavior as described.
Native support in the package manager would be nice, sure, but the Unix philosophy of providing tools that can easily augment each other to solve problems means this is generally a trivial thing to implement by anyone in a way that works best for their use case.
its not difficult to pipe a file of packages into a shell loop to get the behavior as described
It’s possible, but “not difficult” is a bit of a stretch. FWIW I’ve used this in the past, among other hacky solutions that don’t always work as expected:
# Print packages installed from different origins. # Exclude standard Ubuntu repositories. grep -H '^Origin:' /var/lib/apt/lists/*Release | grep -v ' Ubuntu$' | sort -u \ | while read -r line; do origin=${line#* } echo $origin: list=${line%%:*} sed -rn 's/^Package: (.*)$/\1/p' ${list%_*Release}*Packages | sort -u \ | xargs -r dpkg -l 2>/dev/null | grep '^.i ' echo done
You could build a Debian installation with user-defined list of packages since way back in 2010. It’s just a bit too technical for an average spreadsheet cowboy who decided to ditch M$ Losedows.
Also, Docker does exactly what you describe, just inside the VM. There’s a whole ass new position for Dockerscript coders, called devops or something. I think there should be an easy way to install Docker image onto the real hardware with no Docker inbetween too, this question deserves researching.
As a non-Nixer I completely share your frustration. Immutability, i.e. tracking of config changes, is so obviously a good idea. It’s high time it became universal.
You want ansible
NixOS?
I’d love having a file that lists all software like in nix. It has always been a miracle to me why I don’t have a history of installed packages. Before I moved to atomic fedora, I created a shell script that was like “sudo apt install openssh \ yt-dlp \ firefox”. With this I would’ve known what I had installed previously. Since packages are built on top of the system image on atomic distros, they have to keep track now and I don’t have to do it anymore.
To me, nix is still young in the sense that it is not as mature and user friendly as other distros. There are still “3 major different” ways to use nix. (I actually have no idea how many ways but it seems like you can do everything). It needs to be very simple.
I actually use home manager on my device and the package landscape is still not as reliable as on fedora, in my experience.
Tell me you’re a Nix fan without telling me you’re a Nix fan.
