HN user
There are some relatively widespread WiFi chipsets for which free firmware is available:
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.
On the same topic, check out this how-to on software development with Guix from the Cookbook (author here):
https://guix.gnu.org/cookbook/en/html_node/Software-Developm...
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.
Shameless plug but probably relevant in the context of supply chain security: https://programming-journal.org/2023/7/1/
(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:
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
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).
Shepherd takes a service graph as input. The `herd graph` command gives a GraphViz representation of that graph: https://www.gnu.org/software/shepherd/manual/html_node/Jump-...
To be clear, I think Nix (like Guix) signs its pre-built binaries ("substitutes").
However, only Guix has signed commits in its repository (the repo contains package definitions) and a mechanism for secure updates: https://guix.gnu.org/en/blog/2020/securing-updates/
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.
To see what it means in practice, check out the Explorer: https://notabug.org/civodul/guix-explorer
I believe the use of Guix channels shown in the article is comparable to Flakes.
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.
A while back I wrote about what it means to package something like PyTorch with the kind of quality control Guix has: https://hpc.guix.info/blog/2021/09/whats-in-a-package/
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!
Guix channels (not to be confused with Nix channels) let you turn a Git repo into a package collection:
https://guix.gnu.org/manual/devel/en/html_node/Channels.html
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
Speaking of Guix and dotfiles, you may like Guix Home, a tool to manage one's "home environment": to deploy software and associated config files.
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:
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!
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:
https://guix.gnu.org/en/blog/2017/running-system-services-in...
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:
https://guix.gnu.org/en/blog/2020/grafts-continued/
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://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu...
Similarly, as a user, you can "graft" a replacement straight from the command line using `--with-graft`:
https://guix.gnu.org/manual/devel/en/html_node/Package-Trans...
As with Debian, wifi devices are about the only thing you might have "troubles" with when opting for Linux-libre:
https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...
The build farm is set up to build substitutes for a selection of x86_64 micro-architectures, as the article mentions. If you tune for one of them, you'll get substitutes and won't have to build locally; otherwise, Guix will transparently fall back to building the tunable package locally.
Guix is dedicated to ensuring user freedom. It doesn't provide non-free software so that users can make informed choices: they might choose to use third-party channels that provide non-free packages, or install non-free software via flatpak or some other tool, but they can trust Guix itself will never provide non-free software.
Part of allowing for informed choices is about raising awareness, for instance by explaining why some WiFi devices won't work out of the box (which is really the only practical issue one might stumble upon): https://guix.gnu.org/manual/en/html_node/Hardware-Considerat...
"guix describe" and "guix time-machine" make it rather easy to pin a Guix revision (and thus the whole package set) and to restore it anytime:
https://guix.gnu.org/manual/en/html_node/Replicating-Guix.ht...
(Disclaimer: Guix developer and former NixOS developer here.)
The OS configuration of Guix is declarative, like that of NixOS:
https://guix.gnu.org/manual/en/html_node/Using-the-Configura...
However, it was designed to be more hackable and easy to inspect, which is facilitated by the fact that it's integrated in a general-purpose language.
As an example, that allows the `guix system` to verify properties before you deploy a system: that the config does not refer to non-existing file systems, that the initrd doesn't lack modules needed to mount the root file system, that there are no references to undefined system services, etc.
Inspectability is best illustrated here:
https://notabug.org/civodul/guix-explorer
Another big difference is that the relation between services in Guix is explicit, as can be seen above. Conversely, a NixOS service can modify anything in the whole system config, which can make it harder for users to understand how the final config came to be.
Side effect (NixOS users will understand): someone writing a Guix service doesn't have to worry about `mkIf` and other contrived constructs, they won't even have to care about fixed points and infinite recursion. :-)
Guix, apt, yum, etc. are effectively language-independent package managers. They can and do provide large numbers of Python, Rust, Go, R, etc. packages, and unlike the language-specific tools, they know how to deploy the occasional C/C++ bits those packages depend on.
The problem is not so much technical but rather social in my view. For one, it's quite "natural" for language developers to try to grow their community around its very own tools, even if those tools effectively "cut corners".
The other "social issue" has to do with practices: packagers and users of the generic GNU/Linux tools I mentioned have different expectations in terms of having a curated package set, ensuring common conventions are followed, building software from source, and so on. This is at odds with the practices encouraged by some of the language-specific package managers.
Npm does not try to manage complexity, as explained at https://dustycloud.org/blog/javascript-packaging-dystopia/, Java packages often come with opaque jars that nobody builds from source, sometimes due to circular dependencies, and so forth.
I think many (most?) Guix System users are desktop users. Having transactional upgrades and rollbacks, downgrade prevention, and secure updates is great whether you're a desktop user, a developer, or a server admin.
To tweak packages, Guix has "transformation options" that make a number of tweaks readily accessible from the command line: https://guix.gnu.org/manual/en/html_node/Package-Transformat...
For a detailed "Guix vs. Nix" comparison, see: https://news.ycombinator.com/item?id=16490027 and https://news.ycombinator.com/item?id=23529932.
In a nutshell, these are two different projects, with common foundations, but also different technology and different focuses--just like Julia and Clang are different, even though they both use LLVM.
The project blogs and documentation should already give a feel of how those differences play in practice!
That's not quite true anymore: Guile 3.0 has an optimizing compiler and a JIT and it performs pretty well.
See for instance: https://wingolog.org/archives/2019/06/26/fibs-lies-and-bench...
Nowadays most Guile users write exclusively Scheme code, resorting to the FFI for code reuse rather than for performance reasons.
Or:
guix install ungoogled-chromium
For example, the Nix language doesn't have the ability to define new data types, and it doesn't have a "package" or an "operating system" data type. That means that all the entries in Nixpkgs look alike, which in turn prevents building a "package-aware" or "OS-aware" user interface.
The Guix CLI "knows" about packages and versions, and package transformation options are an example of how the CLI can take advantage of that abstraction.
Likewise, the "guix system" command knows about services, which gives it convenient introspection capabilities such as "guix system extension-graph" and "guix system shepherd-graph".
It really isn't about parentheses vs. braces. :-)
It wouldn't be a nice interface for packagers to use.
More importantly, it's not enough to implement grafts because it's not recursive, as discussed at https://guix.gnu.org/en/blog/2016/timely-delivery-of-securit... .