3 ms·

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 sy

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

flatbub 4y 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.