Guix Blog

I'm a huge fan of Nix, and I'm glad to have stuck with the often times daunting process of getting into it - and I have to agree with the author's point regarding the documentation. That's not a fault of the people who actually did sit down and document their process, or distill their learning path into a tutorial - I myself understand it well enough to use it, but not well enough to really explain it without confusing people even more, but it's still a pity that finding good, exhaustive documentation for Nix is really difficult.

Another pitfall is the usage of flakes, which, on the one hand are (imho) great, recommended everywhere and often times even assumed to be used implicitly, but on the other hand are still experimental. I myself started using flakes not because of the promised benefit (although I did realize the benefit later on) but just because multiple tutorials I've read gave me the feeling that flakes were the de facto way to do Nix from now on - and mind you, that was in late 2020.

I'm using Nix for setting up my work machine (Mac via nix-darwin), my private machines (NixOS), selfhosting that's not in my k8s (also NixOS), and some private projects (dependencies, ci, and containers) - where the issues I've described don't really bother me, but for professional projects, where I'd have to convince and/or instruct colleagues, Nix feels a bit too rough around the edges for me right now.

Edit: I also think it's important to distinguish between Nix the technology…

I am going to be hated and downvoted for that but let's go...

Bazel, like Bucks and other, try to bring on table a build system / deployment system that is multi-language, multi-platform and developer oriented. A holy Graal that many developer ( like me ) looked for decade and that many (large) organizations more or less tried to do one day (and most failed)

It is a good idea. It is a required tool to improve productivity. However, if the idea is good on paper, in the implementation, Bazel is damn wrong.

- Bazel is centered around "mono-repo" culture, making it much harder to integrated with multi-source, multi-repo, multi-version projects like many of us have. If I have no doubt that it is great at Google, the external world is not google.

- Bazel is made in JAVA, requires the JVM and this is a problem. That make Bazel not a "light" tool easy to deploy in a fresh VM or in a container.

- Bazel mix the concepts Build System ( like Make, ant, co ) and Deployment System like ( rpm, pkgsrc, etc). That makes Bazel pretty hard to integrate with projects that have existing build system, and almost impossible to integrate INSIDE an other Deployment System (usual package manager, deployment pipeline). The problem that Bazel faces with some languages ( python, go ) is a cause of that.

- Bazel venerates and follows the cult of "DO NOT INSTALL": compile and execute in workspace, there is no "make install", not installation phase. If "convenient" in mono-repo, this is often a…

If you like Nix than probably try GNU Guix [1] and if possible use Guix System on server side. This is one of the most modern development in operating systems.

In the modern security conscious world where most companies run their workloads on virtual machines controlled by other companies, it's imperative that applications are deployed on such predictable, secure and reproducible operating systems.

Guix supports transactional upgrades and roll-backs, unprivileged package management, and more. When used as a standalone distribution, Guix supports declarative system configuration for transparent and reproducible operating systems.

I still think Amazon, Google and Azure will take a decade or two to build and offer something like this to it's customers. Indeed Google's Fuschia is trying to do the same, but I feel it's at least a decade away.

It has one of the best wonderful documentation [2] to get started and explore with all the details.

[1] https://guix.gnu.org/

[2] https://guix.gnu.org/manual/en/html_node/

> I started because I wanted Claude Code to manage my system, not just my code.

I have two reactions to this.

First: respectfully, this is hilarious. LLMs are good at many things, but judgement is not one of them. At the outset, this was firmly in the "terrible ideas" category. (EDIT: ugh; I misread you. I thought you said Claude Code wanted to manage your system. I need more coffee...)

Second: sometimes from terrible ideas come great creativity. (I'm actually not sure what epistemic basis creativity flows from, if not simply the habit of adding entropy to a search path, and you sure chose a high entropy path!) I don't know anything about the stack you chose, but I've spent many hours almost being enticed by https://guix.gnu.org/ and this sounds similar. And the part where you have recovered from a borked system about 15 times is genuine evidence that you're doing something right. I applaud your grit and hope you're having as much fun as it sounds like you are.

If you're interested in what's going on with GNU in general, GUIX is awesome. It's a package manager like Nix but purely GNU (using GNU Guile scheme). It's developed in tandem with the GNU Shepherd init system (instead of sysvinit/systemd/openrc/etc.) and there are distributions based on GNU Hurd kernel (or the Linux-libre kernel).

Wikipedia has a pretty good rundown [3] but I recommend booting up a VM image. It's actually quite beautiful. I love the purity of GNOME on a GNU/Hurd system with GUIX and Shepherd where the whole thing is configured in guile[4]. There's just something very aesthetic about the combination. I wish I could use it as my daily driver.

1. https://guix.gnu.org/

2. https://www.gnu.org/software/shepherd/manual/shepherd.html

3. https://en.wikipedia.org/wiki/GNU_Guix

4. https://www.gnu.org/software/guile/

> Does every service have hooks for possible extensions? What if a new service doesn't fit existing extension hooks?

No, only few services define service extensions.

It's more common for services to be configured solely via their configuration struct.

See the following for docs:

* https://guix.gnu.org/manual/en/html_node/Service-Composition.html

* https://guix.gnu.org/manual/en/html_node/Service-Types-and-Services.html

This is less flexible-by-default than NixOS module, where any module can modify any other module. That is by design. The Guix developers see NixOS's approach as failing the principle-of-least-authority, where any arbitrary module (even those imported via flakes) can add a root SSH key.

I use NixOS, but it's an interesting tradeoff.