Unfortunately, it's hard to be sure when you buy a WiFi device whether it has the right chipset. Also, most laptops come with Intel WiFi, and that requires non-free firmware.
The idea was to show that there are several "levels" to take advantage of Guix for development, where the `guix.scm` file in David Thompson's blog post is the first level.
(Author here.) I'm biased but I do think that the blending between Guix and Shepherd is unique and supports a level of integration beyond what's usually achieved in distros.
The services-in-containers extension you mention is a good example of that: it is implemented on the distro side (in Guix) without any modification to the Shepherd itself. The good thing is that the distro is in a good position to determine how to set up that container since it knows about the package being run, its configuration, and so on.
Yes, and it's not an academic exercise: it's being used in Guix (together with related projects such as stage0, M2-Planet, and Gash) to build everything from source starting from a 357-byte program:
This gives the level of auditability and transparency that we desperately need.
However, the same problem of "yogurt software" manifests at higher levels of the stack, typically with compilers and build systems, some of which still cannot be built from source (GHC and Bazel come to mind).
The problem goes well beyond though: as far as I know, Guix is the only project that has a Git repository that users can authenticate when they pull from it.
The "service" mechanism in Guix System is designed in part as a reaction against those the NixOS module design you're describing: I think the ambient authority, free-style extension mechanism of NixOS modules makes it hard to reason about it (any module can change the config of any other module), and it makes it easy to shoot oneself in the foot (with infinite recursion in particular, as you write).
In Guix System, services extend one another, forming a directed acyclic graph of extensions. When a service extends another service, that connection is explicitly declared, there's no surprise.
Nix bombs out when it runs into a cyclic reference, so at least infinite recursion doesn't hang without any output. Likewise, it also rejects multiple definitions for a value (though to be fair some values like attribute sets are mergeable and it can be hard to wrap one's head around that).
The service model in Guix looks pretty neat! I've long been thinking it would be nice to have a configuration system for NixOS that uses isolated components with a defined (type-safe) interface. The current modules are kind of that, except it all gets squashed down into a single nested attribute set, so it's not really isolated and (understandably) can be confusing. How does Guix System handle multiple services competing for the same global resource (port allocation, file in /etc, ...)?
There's nothing to prevent multiple services from using the same port at this stage. For files in /etc, the "etc" service should detect that the same file appears more than once and error out--that is, it won't instantiate a "broken" system.
There are other things that are detected statically and prevent you from instantiating a broken system: missing modules in the initrd, invalid file system label/UUID, references to non-existent Shepherd services, etc. All this is possible because there are well-defined data types and semantics for the different components of the system.
Fair enough, NixOS doesn't completely solve this either (other than the aforementioned possibility to reference other parts of the system config and some integrity checks). I was just wondering if that's an area where more static checks are possible.
That sounds pretty good though, thanks! Maybe I'll try out Guix System some day.
From what I understand, channels can be used to extend Guix, but don't quite work like Flakes, more like the old Nix channels. The thing that makes Flakes special is that they allow you to treat Git repositories like software packages. No more need for a distribution to package the software, you can just drop a 'flake.nix' file into the Git repository and that makes it behave like a package that users can install and other Flakes can depend on. I am really fond of the ability to just run software straight from Git, e.g.:
nix run github:ggerganov/llama.cpp
Makes it really easy to switch versions, fork, patch or otherwise customize things.
One thing that's often overlooked with Nix (the language) is that it does not let you define new data types. For example, there's no "package" type in Nix and Nixpkgs; instead there are only functions that are passed "attribute sets" (key/value dictionaries).
That Nix can't tell what's a package and what's not is a hindrance for its user interface (e.g., it's hard to look up packages by name/version or to iterate over them) and for packagers (e.g., easy to end up with package definitions that don't follow the informal "schema").
https://guix.gnu.org/manual/devel/en/html_node/Hardware-Cons...
Unfortunately, it's hard to be sure when you buy a WiFi device whether it has the right chipset. Also, most laptops come with Intel WiFi, and that requires non-free firmware.
reply