Criticism of gnu guix and nix. How to improve them

Guix
1

gnu guix is like nixos.

Files automatically installed into /etc by FHS-compliant package managers now have to be configured manually in the global declarative configuration file. The global declarative configuration often doesn’t provide a way to configure every little detail.

For example, /etc/pam.d/swaylock comes with FHS-compliant package managers. Now, it has to be configured manually with guix or nix. The declarative configuration may not allow you to configure pam-gnupg in /etc/pam.d/swaylock because it doesn’t account for pam-gnupg.

Because every little thing should be accounted for by nix or guix, core maintainers are now forced to approve declarative configuration options for every software package.

Forcing one small group to approve configuration options for every software package never scales well.

I propose potential solutions.

  • Bundle package configuration options with packages. This way, individual package maintainers are now responsible for package configuration options. This also distributes maintenance workload among various private guix channels.
  • Make guix or nix transparent to package executables. Package executables are automatically injected into FHS environment. If you want to modify /etc files, apply package transformation to modify /etc files in packages. Or, make it possible to inject files into a package’s FHS environment. This is more flexible than the first option because people now don’t have to write declarative options for every little thing.
2

I retract my criticism.

I thought guix packages should come with automatically enabled services.

However, I learned that guix services automatically install packages and I should use services instead of packages when there are services.

Services are the way to modify gnu guix system outside /gnu/store and install the necessary guix packages.

2 Likes
3

This is an issue for pretty much every distro; even Debian doesn’t have enough hands to review and update everything it needs to. Unixdigest posted an article The Delusions of Debian that touches on this a bit.

It’s not an insurmountable problem, however. My impression from the few months I’ve been working with Guix is that the community focuses primarily on those packages that most heavily used by those using the distribution. So core packages and things like Emacs are going to be well covered, while more obscure packages will likely be packaged privately by that one user who needs it.

2 Likes
4

They can still share what they have on toys search engine, and they can try to get more things merged into official or semi-official channels over time.

1 Like
5

I package stuff on my https://codeberg.org/kakafarm/guix-kakafarm-channel/ and then send a patch to the Guix bugs mailing list when they’re ready.