| Nice! Bravo for your contributions! After using and contributing NixOS for 3 years, I appreciated that I understood far more how Guix worked after just one 1-2 weeks of using it. Guix introduces abstractions, such as operating-system that has defined fields that make it clearer what structures are being built. NixOS, on the other hand, does not have such abstractions (or perhaps just not as well documented/discoverable). Alas, I found Guix a bit slow and a bit difficult to contribute to (mailing list workflow, and fewer reviewers), and don't have the capacity to help improve that, and so I'm back to NixOS. Guix is tackling multiple fronts: a blob-free kernel, a non systemd init, mailing list development, bootstrapability, no non-free software, high standards for commit messages. If they reduced the number of fronts they were tackling, they might increase contributions, but the current contributors seem to value their existing fronts. That's fair. |
NixOS had plenty of abstractions, so I don't quite understand this. All of NixOS is a compilation of abstractions for building an operating system environment. Could you elaborate on what abstractions are not present?
> Guix is tackling multiple fronts: a blob-free kernel, a non systemd init, mailing list development, bootstrapability, no non-free software, high standards for commit messages.
Except for the last one, all of these are noble achievements perhaps within a subset of an ecosystem, like Nix or Guix, but the deliberate and unwavering stapling of these goals to the ecosystem makes Guix unpalatable.