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.
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.
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.
Good point. It's telling that many Nix vs. Guix discussions focus on three topics: DSL, popularity, and non-free packages. Few people talk about package quality control even though it's rather crucial for day-to-day use.
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").
Well, with more than 23K packages, it's fair to say that Guix can satisfy the needs of many people, too. A lot of programming languages are pretty well represented!
I guess it serves some of the same purposes as Flakes, and it comes with other bells and whistles such as authentication (which I think is kinda important!).
For the rest, your description of Guix is largely incorrect ("has none of that", "you have to roll back the complete Guix system", etc.), but as a Guix hacker I'd be interested in better understanding your experience and perceptions if you'd like to get in touch with us on the mailing lists!
On top of that, one can use Guix from the comfort of Emacs:
guix install emacs-guix
The Emacs interface includes Magit-style popup menus, lets you install/remove/upgrade/browse packages, roll back, edit package definitions, navigate system services, and more.
In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats:
Guix System uses Linux as its kernel, so no driver "is GNU", whatever that means.
The choice to use the Shepherd rather than systemd is motivated by a vision that we can get better integration using a single language and set of tools all the way down. As an example, this gave us services in containers several years ago:
Overall Guix System alone gives a coherent and unified view of the system; systemd also does that to some extent, but it's not in as good a position as Guix's declarative OS configuration to do that. For example, this is the kind of system exploration that Guix enables:
Grafts in Guix support this use case: you know you're providing an ABI-compatible package replacement and don't want to rebuild everything that depends on it:
We use that for security updates, but also in other situations where we know we can take advantage of it such as the new `--tune` package transformation option, which tunes a package for a specific CPU:
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.