top | item 32512938

(no title)

virchau13 | 3 years ago

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

discuss

order

flatbub|3 years ago

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.