Hacker News Reader

Comment by xyzzy_plugh | Hacker News Reader

> 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).

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.

View on HN

AFAICT, NixOS has no equivalent to the type https://guix.gnu.org/manual/en/html_node/operating_002dsyste... , which makes it clear what an OS contains, and allows you to query the OS.

Instead, NixOS has many options, whose only structure is that they form a tree. When trying to understand a host, it's unclear how to begin to analyze this tree: no option is at a higher level of abstraction than any other, or if it is, it's difficult to infer that.

Arguably I could just look at my host's config, and that will tell me what this host does, but it doesn't. It actually describes my how machine differs from the default NixOS machine. (How do I learn what a default NixOS machine do? Query for all services "enabled" option is set to true?)

With Guix, I follow the code: how is this host's OS "services" field populated.

The type problem is starting to be solved by flakes; the equivalent to the type `operating-system` is the type `nixpkgs.lib.nixosSystem`.

To analyze a NixOS system configuration, I look for all modifications to the `services` attr (representing all the services of the system, e.g. `services.mpd.dir = "~/Music"`). If I want to know even more I can look for all the `.enable` keys to see if any hardware/program/etc options have been enabled, and the sources are easy to read so I can open the corresponding module file in Nixpkgs if I want to know what a particular option does. The default NixOS machine does literally nothing so I don't have to worry about that.

Guix does look really cool, and I would try it if it had more support for nonfree software (I depend on some nonfree software in my day-to-day.)

Nice. I've migrated to flakes and much prefer it.

Flakes provides abstractions at a per-repo level.

Guix offers abstractions all the way down: an OS contains a bootloader, which is also its own type.

> The default NixOS machine does literally nothing so I don't have to worry about that.

The default NixOS machine chooses a bootloader, enables nscd, has default users, enable DHCP, ...

... and those are just the parts I was able to guess at, and then confirm by checking whether their 'enable' option defaulted to true.

It's unclear how to determine (from the source code) what a default machine does in NixOS.

It was only when I tried Guix that I had the visibility into what my machine was actually composed of.

Reply on news.ycombinator.com