9 ms·

Guix System First Impressions as a Nix User

199 points by todsacerdoti 9mo ago

shevy-java 9mo ago
I understand his enthusiasm with NixOS but: > With Nix, however, it was a matter of just describing a few packages in a shell and boom, Ruby in one folder, no Ruby (and thus no mess) everywhere else. This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really). > I started adding shell.nix files to all my little projects I appreciate that NixOS brought good ideas to Linux here; having reliable snapshots is good. If a user has a problem, someone else might have solved it already, so you could "jump" from snapshot to snapshot. No more need for StackOverflow. The HiveMind took over. But with all its pros, the thing I hate by far the most in NixOS is .. nix. I think the language is ugly beyond comparison; only shell scripts are uglier. I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead? Or simple config files? I am very used to simple yaml files; all my system description is stored in simple yaml files. Since +20 years. That approach works very well (ruby expands these to any target destination; for instance, I have aliases for e. g. bash, but these are stored in yaml files and from that ruby then generates any desired target format, such as also cmder on Windows and so forth). > In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. I am glad to not be the only one to dislike nix, but boy ... scheme? Aka Lisp? Seriously??? Young people use lisp? I somehow doubt that. (cons* (channel (name 'nonguix) (url "https://gitlab.com/nonguix/nonguix") Erm, no thanks. Why would users know what cons* does, anyway? That's stupid. YAML files exist for a reason. Keep. Things. Simple. (I know, I know, many use YAML files in a complex manner with gazillion nested indentation. Well, they are using it in a wrong way, then they complain about how bad yaml is.) > Since the code is pretty much just Scheme and the different mechanisms available are fairly well documented (see caveat below), the barrier to entry is much lower than with Nix in my opinion. Can't evaluate this. To me it seems as if NixOS may have changed, but Nix was always a big barrier. I decided to not want to overcome it, since I did not want to be stuck with a horrible language I don't want to use.
- k__ 9mo ago
  I used both Guix and Nix and found both their languages okay for the use-case. Nix was slightly better, since it's easier to format automatically than Lisp.
  - anthk 9mo ago
    >Easier to format automatically than Lisp You wish. Emacs did that for free since the 80's.
    - arikrahman 9mo ago
      Yes, I found init.el even more straight forward than nix and even home packages.
      - anthk 9mo ago
        Emacs has Geiser to edit Scheme/Guile code with ease. For sure Emacs users know how to handle Scheme which is just another Lisp (even MIT Scheme bundles an old Emacs release) and have at least partial knowledge of Common Lisp (and being able to grasp it in minutes).
- AreShoesFeet000 9mo ago
  I am young (29). I like computers because they are essentially something hacky. There’s nothing more hacky than Lisp IMO. I will never complain about Lisp. I just like it.
  - arikrahman 9mo ago
    Same here, I'm 22 and Uncle Bob sold me on the Lisp language. Reading SICP and Land of Lisp gave me a newfound appreciation for programming and design.
- microtonal 9mo ago
  This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really). Nix already existed in 2003. Besides that Nix store directories are more ingenious than versioned application directories (or hashed directories), the hash in the output path is the hash of the normalized derivation used to build the output path (well, in most cases, let's keep it simple). Derivations work similarly (also using hashes). Moreover, since a derivation can contain other derivations as an input, the Nix store represents hash/Merkle trees. This makes it very powerful, because you can see which parts of the tree need to be rebuilt as a result of one derivation changing. But with all its pros, the thing I hate by far the most in NixOS is .. nix. I think it depends on your background. I did some Haskell at some point in my live and I like Nix. It is a very simple, clean, lazy, functional programming language. The primary thing I'm missing is static typing. I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead? Because what nixpkgs does is not easily expressible/doable in Ruby. First, the package set is one huge expression in the end. That might seem weird, but it allows for a lot of powerful things like overlays. However, for performance reasons this requires lazy evaluation. Also other powerful abstractions require lazy evaluations (e.g. because there are some infinite recursions in nixpkgs). Second, the Nix packaging model requires a purity (though this gap was only properly closed with flakes). You have to be able to rely on the fact that evaluating an expression evaluates to the same result. Otherwise a lot of things would break (like substitution from binary caches). Third, things like overlays rely on fixed points, which can be done easily in a lazy functional language. --- Having used Nix for 8 years now, I have a long list of criticisms as well though :).
aidenn0 9mo ago
> I am lucky enough to live in a household with fiber-optic internet, that merely shrugs at bandwidth of up to a gigabyte per second... Probably a typo, unless the author really has 8gigabit network
- opan 9mo ago
  Quantum Fiber provides 8gbps, so it's not unheard of.
peter_d_sherman 9mo ago
>"But NixOS isn't the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme..." I'd be curious if a list exists of all declarative Linux distros out there, along with the configuration language (Nix, Scheme, etc.) I'd also be curious as to how easy it would be to convert Scheme to the Nix language or vice-versa, in other words, it seems to me that there might be a "parent language" (for lack of a better term) out there for all lisplike and functional programming language (a subset of Haskell, F#, or some other functional programming language perhaps) that sort of might act as an intermediary conversion step (again, for lack of a better term!) between one functional or lisplike programming language and another... Probably unrelated (but maybe somewhat related!) -- consider Pandoc... Pandoc is a Haskell program that basically uses a document tree structure to convert between one type of document format and another... maybe in terms of programming languages you'd call that an AST, an Abstract Syntax Tree... so maybe there's some kind of simplified AST (or something like that) out there that works as the base tree for all functional and lisp-like programming language (yes, lisp/lisplikes sort of preserve its/their own tree; their own AST -- via their intrinsic data structure, and that would seem to be true about functional programming languages too... so what is the base tree/AST of all of these, that all languages in this family can "map on to" (for lack of better terminology), that could be used (with AI / LLM's) as an "Intermediary Language" or "Intermediary Data Structure" (choose your terminology) to allow easily converting between one and the other? Anyway, if we had that or something like that, then Nix configurations could (in theory) be easily converted to Guix, and vice-versa, automatically, as could any other Linux configured by a functional and/or lisplike language... That, and I found the article very interesting! I may have to try Guix in the future!
- arikrahman 9mo ago
  I was thinking the same thing. Since scheme is in the Lisp family, it should be straightforward to modernize it to something like Clojure, which is similar to Haskell as you mentioned. Being functional, but from a Java/Lisp ecosystem that might be more viable in the typical modern software environment.
sheepscreek 9mo ago
My favourite line in the article. > it didn't take long for me to realize the initial problem that caused my previous install to be unbootable was of course found between the chair and keyboard. I think we’ve all been there! It still happens to me, exactly 5 seconds after calling Claude/Codex/Gemini names and dismissing their ability to follow instructions.
MarsIronPI 9mo ago
I may be the odd one out here, but I actually prefer Nix (the language) to the Guile libraries and DSLs I've seen in Guix. And it's not that I hate Lisps; my favorite language is Common Lisp. But IMO the Guix libs/DSLs are more awkward to use for declaring a system than Nix. I think it's because Nix's module system is more intuitive for me, or that I find it more elegant. Maybe if Guix were designed more along those lines. Also flakes: a declarative distro without a flakes equivalent makes little sense to me.
- Pay08 9mo ago
  Mostly, the DSL in Guix has the syntax of (field value), I don't really see the problem with them. There are some more complex DSLs relating to service/package modification but those tend to take imperative code blocks. IMO the most difficult it gets are g-expressions, which are quasiquoting for the Guix daemon.
  - MarsIronPI 9mo ago
    Eh, I think it's that with Nixlang one can write foo.bar = true; as a shorthand for foo = { bar = true; }; which makes deeply-nested options much easier to write out. In general Nix looks a lot more like a config file to me.
    - Pay08 9mo ago
      I've never seen more than one level of nesting in a piece of Guix code, but that comes with the caveat that Guix is quite happy to extract fields that would perhaps be nested with other languages into their own top-level fields, like the build-system and arguments fields being separate in package definitions.
Pay08 9mo ago
I don't know if the author is reading this, but the issues with the nvidia driver was likely because he didn't use an LTS kernel. The nonguix README says that the nvidia driver is only compiled for the current LTS kernel (i.e. the linux-lts package) but it's easy to miss. BTW, there's a list of mirrors for the substitute servers at https://libreplanet.org/wiki/Group:Guix/Mirrors https://libreplanet.org/wiki/Group:Guix/Mirrors, they tend to be way faster.
- nickserv 9mo ago
  > nvidia Just don't. I'm always amazed people actually still use their products in a Linux system. More expensive and worse software support than AMD or Intel.
  - Pay08 9mo ago
    I'm writing this on machine with a 1660 TI on Guix with the open source(ish) drivers from nonguix and it works just fine.
zeratax 9mo ago
my biggest issue with guix by far is that it doesn't use systemd. i just can not use a distro nowadays without systemd
uriahlight 9mo ago
With respect, the author sounds too fickle for me to ascribe value to their "first impressions" of a distro.
- hazebooth 9mo ago
  seems like they have pretty clear goals in mind. if they were changing distributions haphazardly id otherwise agree, but to me it reads that they're refining their taste.
- 6ak74rfy 9mo ago
  I didn't read any fickleness in the post. Sure, they tried multiple distros - who hasn't - and that too over ten years.
4corners4sides 9mo ago
From my perspective he seemed to go through a lot of trauma to end up with an otherwise regular linux install (NVIDIA driver failure, KDE plasma failure, extremely slow downloads, solution speeds). Though at some point I should trial one of these declarative OSes for development be it Nix or guix. As a recovering emacs user I had a pretty visceral reaction to seeing a “cons” cell in code. In all my ramblings about a post-syntax world and chasing higher and higher abstractions seeing the level of abstractions of “cons” cells, a linked list implementation detail, mingled in with the orchestration of a whole operating system just feels like a despicable and cruel joke. It’s like studying system design and hearing some peanut brain in the other room say something like “let’s use a for loop” - not the level that one should be thinking at.
user3939382 9mo ago
Modern GPU drivers are a nightmare for open source. Wifi no better but slightly less critical. Power management. Forget Linux this should be the year of the NetBSD desktop but we can’t have nice architectures bc of economics in computing. The whole scenario makes sense but the emergent result sucks.
- bayindirh 9mo ago
  > Modern GPU drivers are a nightmare for open source. Modern NVIDIA drviers. Let me fix that for you. Intel and AMD has their full stack in mainline already, and AMD made great effort to enable their cards fully under open source drivers, as their agreements and law allows. You can even use HDCP without exposing sensitive parts, if you want. Intel also works completely fine. However, NVIDIA's shenanigans and HDMI forum's v2.1 protectionism is something else completely.
  - plagiarist 9mo ago
    I went with AMD for compatibility playing games, but AFAICT AMD ROCm is not in a great state for computation. Why can't I have both? That's something like what they're describing as "a nightmare," isn't it? "As agreements and law allows," is part of the nightmare. Under a modern OS, it should not be difficult to have the full capability of the hundreds or thousands of dollars worth of hardware you paid for.
    - Fnoord 9mo ago
      There is ZLUDA [1] for CUDA, Ollama works on AMD [2], and there's OptiScaler [3] for DLSS. For older AMD GPU there's also FSR 4 INT8, see howto here [4] [1] https://github.com/vosen/ZLUDA https://github.com/vosen/ZLUDA [2] https://ollama.com/blog/amd-preview https://ollama.com/blog/amd-preview https://github.com/likelovewant/ollama-for-amd https://github.com/likelovewant/ollama-for-amd [3] https://github.com/optiscaler/OptiScaler https://github.com/optiscaler/OptiScaler [4] https://github.com/007Lore/AMD-FSR-4-INT8 https://github.com/007Lore/AMD-FSR-4-INT8
  - adrian_b 9mo ago
6ak74rfy 9mo ago
I've had a passing curiosity about Guix, so it was good to read this report. One thing I didn't find is Guix on servers. I am all-in on NixOS for both my daily driver desktop and couple of servers, and adding more of either will be simple modifications to my flake repository. I really appreciate that simplicity and consistency. Does Guix offer that? The other thing is package availability: it's amazing on Nix. Plus, they remain relatively fresh on the unstable channel. How's that on Guix?
- k__ 9mo ago
  How do you deploy NixOS to your servers? I started a project with nixos-anywhere, deploy-rs, and compose2nix. However, I struggle a bit with secret management.
  - drdaeman 9mo ago
    There are plenty of options: nix-sops, or nix-age, or whatever you would like - past the overall idea the implementation details are purely a matter of taste how you fancy things to be. Key idea is to have encrypted secrets in the store, decrypted at runtime using machine-specific credentials (host SSH keys are a typical option to repurpose, or you can set up something else). For local management you also encrypt to the “developer” keys (under the hood data is symmetrically encrypted with a random key and that key is encrypted to every key you have - machines and humans). Alternatively, you can set up a secrets service (like a password manager/vault) and source from that. Difference is where the secrets live (encrypted store or networked service, with all the consequences of every approach), commonality is that they’re fetched at runtime, before your programs start. I’m currently using deploy-rs, but if I’d redo my stuff (and the only reason I don’t is that I’m pretty much overwhelmed by life) I’d probably go with plain vanilla nixos-rebuild --target-host and skip any additional layers (that introduce extra complexity and fragility). Just a crude and somewhat haphazard summary but hope it helps.
    - diarrhea 9mo ago
      I have been using nixos-rebuild with target host and it has been totally fine. The only thing I have not solved is password-protected sudo on the target host. I deploy using a dedicated user, which has passwordless sudo set up to work. Seems like a necessary evil.
gurjeet 9mo ago
TLDR: ... I'm getting a comparable experience to NixOS, with all the usual pros a declarative environment brings and without having to put up with Nixlang.
- oasisaimlessly 9mo ago
  Instead, put up with a flavor of Scheme that looks suspiciously like Nix with some extra parentheses...
  - eikenberry 9mo ago
    How the errors/debugging compare? From what I've read this is the main pain point with Nix where a more mature language like Guile should have a much better experience here. The article touches on this but I'd be curious of a more extensive comparison about this aspect.
    - anthk 9mo ago
      Emacs + Geiser can do everything from a REPL in order to debug it. Emacs and Guile integration both come for free since decades.
    - assbuttbuttass 9mo ago
      Just a personal anecdote, but the errors from Guix are terrible. I had to reinstall because I couldn't figure out the scheme errors for my system config
      - Pay08 9mo ago
        It's generally a problem with Guile. If you get decently good with Geiser or stare at the stack traces long enough, you can figure out the problem but I shouldn't have to do either.
  - bsder 9mo ago
    And which an LLM/AI model can apply the huge training set of Lisp/Scheme to help solve your problem. Nixlang is so infuriatingly obtuse that I generally have to fire up Discord and bug the local Nix acolyte when something goes wrong. I've bounced Nixlang off of the LLM/AIs, but I have learned that if the AI doesn't give you the correct answer immediately for Nixlang then you need to stop; everything forward will be increasingly incorrect hallucinations. I suspect LLM/AIs will hallucinate far, far less with the Scheme from Guix.
kkfx 9mo ago
My issue with Guix coming from NixOS is the missing first-class zfs support for root, crypto included, RustDesk, few other common services who are hard to package. Guix potential target IMVHO should be desktop power users, not HPC, NixOS while mostly developed for embedded systems (Anduril) or servers in general still take care of desktops, Guix apparently not and that's a big issue... Nowadays outside academia I doubt there are many GNU/Linux users who deploy on plain ext4...
- akshitgaur2005 9mo ago
  See this config for an example guix config with zfs - https://codeberg.org/hako/Testament/ https://codeberg.org/hako/Testament/
  - autumn-antlers 9mo ago
    > Guix channels in use: > - guix (additional patches are used locally for root on ZFS support) i'm hopeful too, but think it may not be so simple (yet) >u< here's a more precise link https://codeberg.org/guix/guix/pulls/1917#issuecomment-6976089 https://codeberg.org/guix/guix/pulls/1917#issuecomment-69760...
  - kkfx 9mo ago
    Thanks! A very nice set of configs. I've done something similar for NixOS and my LAN but never advanced at such point in Guix.
- blm126 9mo ago
  For desktop usage, I would be absolutely shocked if ext4 isn't the most common filesystem by a pretty wide margin. Its the default on Ubuntu, Debian, and Mint. Those are the 3 leading desktop distros. No one is going to write a blog post titled "Why I just used the default filesystem in the installer" but that is what most people do. Things like btrfs and zfs are useful, complicated technologies that are fun to write about, fun to read about, and fun to experiment with. I'd be careful about assuming that leads to more general use, though. Its a lot like Guix and NixOS, in fact. They get all the attention in a forum like this. Ubuntu is what gets all the people, though.
dietr1ch 9mo ago
> merely pulling in Nixpkgs is an effort, due to the repository being massive. I've embraced daily shallow clone/fetches and the burden is now mostly just the 2GB of disk space. It's a bit annoying though that git doesn't make it easier. No one would shallow clone later screw up and download every commit anyway, I feel shallow clone repos should be set up with a different configuration that fully-embraces shallow history (not that the configuration options even exist today AFAIK).
- bsimpson 9mo ago
  I've only been doing this for a few weeks, so too early to tell if it's a good setup, but I added a GitHub Action that rebases my personal fork atop nixpkgs-weekly. I'm hoping that will help keep me from having a stale-by-default personal nixpkgs. (I use a personal nixpkgs to stage PRs waiting to be merged upstream.) https://github.com/appsforartists/nixpkgs/commit/769a72d3a6ffeab2bc7511b2a2b5a0da63a40376 https://github.com/appsforartists/nixpkgs/commit/769a72d3a6f...
  - dietr1ch 9mo ago
    I remember thinking about doing that, but found value in having my fork tell me when was the last time I synced with upstream which was something useful to assess if I wanted to rebase my patch once again. Eventually my change got upstream and I stopped tracking my own fork though.
    - bsimpson 9mo ago
      I started doing it this way (auto-rebase) when I started sharing one home-manager config across different devices. This lets me do `nix flake update` on my home-manager config to have all my in-flight patches + the canonical nixpkgs from any device, and trust that they can all see the shared GitHub to sync. Hopefully will make updating less of a chore. Only time it's bit me so far was when godot3 was broken in nixpkgs-weekly but worked in 25.11. Forced me to go write a PR for that and get it upstream to get my build working again, but that was more of a nixpkgs-weekly problem than a personal fork one. One of the wrinkles of getting home-manager going on a bunch of different devices is that it liked to copy my local git checkout of nixpkgs to /nix/store a lot. That's why I'm preferring to have flake.lock point at my github.com branch, and then I can test uncommitted changes as-needed by passing --local to my home-manager switch incantation: https://github.com/appsforartists/device-config/blob/c09d6bc167f6c44dbac24c6c33c97a8f98c27c83/modules/terminal/zsh.nix#L62-L85 https://github.com/appsforartists/device-config/blob/c09d6bc...

199 points by todsacerdoti 9mo ago

I understand his enthusiasm with NixOS but: > With Nix, however, it was a matter of just describing a few packages in a shell and boom, Ruby in one folder, no Ruby (and thus no mess) everywhere else. This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really). > I started adding shell.nix files to all my little projects I appreciate that NixOS brought good ideas to Linux here; having reliable snapshots is good. If a user has a problem, someone else might have solved it already, so you could "jump" from snapshot to snapshot. No more need for StackOverflow. The HiveMind took over. But with all its pros, the thing I hate by far the most in NixOS is .. nix. I think the language is ugly beyond comparison; only shell scripts are uglier. I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead? Or simple config files? I am very used to simple yaml files; all my system description is stored in simple yaml files. Since +20 years. That approach works very well (ruby expands these to any target destination; for instance, I have aliases for e. g. bash, but these are stored in yaml files and from that ruby then generates any desired target format, such as also cmder on Windows and so forth). > In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. I am glad to not be the only one to dislike nix, but boy ... scheme? Aka Lisp? Seriously??? Young people use lisp? I somehow doubt that. (cons* (channel (name 'nonguix) (url "https://gitlab.com/nonguix/nonguix") Erm, no thanks. Why would users know what cons* does, anyway? That's stupid. YAML files exist for a reason. Keep. Things. Simple. (I know, I know, many use YAML files in a complex manner with gazillion nested indentation. Well, they are using it in a wrong way, then they complain about how bad yaml is.) > Since the code is pretty much just Scheme and the different mechanisms available are fairly well documented (see caveat below), the barrier to entry is much lower than with Nix in my opinion. Can't evaluate this. To me it seems as if NixOS may have changed, but Nix was always a big barrier. I decided to not want to overcome it, since I did not want to be stuck with a horrible language I don't want to use.

k__ 9mo ago
I used both Guix and Nix and found both their languages okay for the use-case. Nix was slightly better, since it's easier to format automatically than Lisp.
- anthk 9mo ago
  >Easier to format automatically than Lisp You wish. Emacs did that for free since the 80's.
  - arikrahman 9mo ago
    Yes, I found init.el even more straight forward than nix and even home packages.
    - anthk 9mo ago
      Emacs has Geiser to edit Scheme/Guile code with ease. For sure Emacs users know how to handle Scheme which is just another Lisp (even MIT Scheme bundles an old Emacs release) and have at least partial knowledge of Common Lisp (and being able to grasp it in minutes).
AreShoesFeet000 9mo ago
I am young (29). I like computers because they are essentially something hacky. There’s nothing more hacky than Lisp IMO. I will never complain about Lisp. I just like it.
- arikrahman 9mo ago
  Same here, I'm 22 and Uncle Bob sold me on the Lisp language. Reading SICP and Land of Lisp gave me a newfound appreciation for programming and design.
microtonal 9mo ago
This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really). Nix already existed in 2003. Besides that Nix store directories are more ingenious than versioned application directories (or hashed directories), the hash in the output path is the hash of the normalized derivation used to build the output path (well, in most cases, let's keep it simple). Derivations work similarly (also using hashes). Moreover, since a derivation can contain other derivations as an input, the Nix store represents hash/Merkle trees. This makes it very powerful, because you can see which parts of the tree need to be rebuilt as a result of one derivation changing. But with all its pros, the thing I hate by far the most in NixOS is .. nix. I think it depends on your background. I did some Haskell at some point in my live and I like Nix. It is a very simple, clean, lazy, functional programming language. The primary thing I'm missing is static typing. I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead? Because what nixpkgs does is not easily expressible/doable in Ruby. First, the package set is one huge expression in the end. That might seem weird, but it allows for a lot of powerful things like overlays. However, for performance reasons this requires lazy evaluation. Also other powerful abstractions require lazy evaluations (e.g. because there are some infinite recursions in nixpkgs). Second, the Nix packaging model requires a purity (though this gap was only properly closed with flakes). You have to be able to rely on the fact that evaluating an expression evaluates to the same result. Otherwise a lot of things would break (like substitution from binary caches). Third, things like overlays rely on fixed points, which can be done easily in a lazy functional language. --- Having used Nix for 8 years now, I have a long list of criticisms as well though :).

aidenn0 9mo ago

> I am lucky enough to live in a household with fiber-optic internet, that merely shrugs at bandwidth of up to a gigabyte per second... Probably a typo, unless the author really has 8gigabit network

opan 9mo ago
Quantum Fiber provides 8gbps, so it's not unheard of.

peter_d_sherman 9mo ago

>"But NixOS isn't the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme..." I'd be curious if a list exists of all declarative Linux distros out there, along with the configuration language (Nix, Scheme, etc.) I'd also be curious as to how easy it would be to convert Scheme to the Nix language or vice-versa, in other words, it seems to me that there might be a "parent language" (for lack of a better term) out there for all lisplike and functional programming language (a subset of Haskell, F#, or some other functional programming language perhaps) that sort of might act as an intermediary conversion step (again, for lack of a better term!) between one functional or lisplike programming language and another... Probably unrelated (but maybe somewhat related!) -- consider Pandoc... Pandoc is a Haskell program that basically uses a document tree structure to convert between one type of document format and another... maybe in terms of programming languages you'd call that an AST, an Abstract Syntax Tree... so maybe there's some kind of simplified AST (or something like that) out there that works as the base tree for all functional and lisp-like programming language (yes, lisp/lisplikes sort of preserve its/their own tree; their own AST -- via their intrinsic data structure, and that would seem to be true about functional programming languages too... so what is the base tree/AST of all of these, that all languages in this family can "map on to" (for lack of better terminology), that could be used (with AI / LLM's) as an "Intermediary Language" or "Intermediary Data Structure" (choose your terminology) to allow easily converting between one and the other? Anyway, if we had that or something like that, then Nix configurations could (in theory) be easily converted to Guix, and vice-versa, automatically, as could any other Linux configured by a functional and/or lisplike language... That, and I found the article very interesting! I may have to try Guix in the future!

arikrahman 9mo ago
I was thinking the same thing. Since scheme is in the Lisp family, it should be straightforward to modernize it to something like Clojure, which is similar to Haskell as you mentioned. Being functional, but from a Java/Lisp ecosystem that might be more viable in the typical modern software environment.

sheepscreek 9mo ago

My favourite line in the article. > it didn't take long for me to realize the initial problem that caused my previous install to be unbootable was of course found between the chair and keyboard. I think we’ve all been there! It still happens to me, exactly 5 seconds after calling Claude/Codex/Gemini names and dismissing their ability to follow instructions.

MarsIronPI 9mo ago

I may be the odd one out here, but I actually prefer Nix (the language) to the Guile libraries and DSLs I've seen in Guix. And it's not that I hate Lisps; my favorite language is Common Lisp. But IMO the Guix libs/DSLs are more awkward to use for declaring a system than Nix. I think it's because Nix's module system is more intuitive for me, or that I find it more elegant. Maybe if Guix were designed more along those lines. Also flakes: a declarative distro without a flakes equivalent makes little sense to me.

Pay08 9mo ago
Mostly, the DSL in Guix has the syntax of (field value), I don't really see the problem with them. There are some more complex DSLs relating to service/package modification but those tend to take imperative code blocks. IMO the most difficult it gets are g-expressions, which are quasiquoting for the Guix daemon.
- MarsIronPI 9mo ago
  Eh, I think it's that with Nixlang one can write foo.bar = true; as a shorthand for foo = { bar = true; }; which makes deeply-nested options much easier to write out. In general Nix looks a lot more like a config file to me.
  - Pay08 9mo ago
    I've never seen more than one level of nesting in a piece of Guix code, but that comes with the caveat that Guix is quite happy to extract fields that would perhaps be nested with other languages into their own top-level fields, like the build-system and arguments fields being separate in package definitions.

Pay08 9mo ago

I don't know if the author is reading this, but the issues with the nvidia driver was likely because he didn't use an LTS kernel. The nonguix README says that the nvidia driver is only compiled for the current LTS kernel (i.e. the linux-lts package) but it's easy to miss. BTW, there's a list of mirrors for the substitute servers at https://libreplanet.org/wiki/Group:Guix/Mirrors https://libreplanet.org/wiki/Group:Guix/Mirrors, they tend to be way faster.

nickserv 9mo ago
> nvidia Just don't. I'm always amazed people actually still use their products in a Linux system. More expensive and worse software support than AMD or Intel.
- Pay08 9mo ago
  I'm writing this on machine with a 1660 TI on Guix with the open source(ish) drivers from nonguix and it works just fine.

zeratax 9mo ago

my biggest issue with guix by far is that it doesn't use systemd. i just can not use a distro nowadays without systemd

uriahlight 9mo ago

With respect, the author sounds too fickle for me to ascribe value to their "first impressions" of a distro.

hazebooth 9mo ago
seems like they have pretty clear goals in mind. if they were changing distributions haphazardly id otherwise agree, but to me it reads that they're refining their taste.
6ak74rfy 9mo ago
I didn't read any fickleness in the post. Sure, they tried multiple distros - who hasn't - and that too over ten years.

4corners4sides 9mo ago

From my perspective he seemed to go through a lot of trauma to end up with an otherwise regular linux install (NVIDIA driver failure, KDE plasma failure, extremely slow downloads, solution speeds). Though at some point I should trial one of these declarative OSes for development be it Nix or guix. As a recovering emacs user I had a pretty visceral reaction to seeing a “cons” cell in code. In all my ramblings about a post-syntax world and chasing higher and higher abstractions seeing the level of abstractions of “cons” cells, a linked list implementation detail, mingled in with the orchestration of a whole operating system just feels like a despicable and cruel joke. It’s like studying system design and hearing some peanut brain in the other room say something like “let’s use a for loop” - not the level that one should be thinking at.

user3939382 9mo ago

Modern GPU drivers are a nightmare for open source. Wifi no better but slightly less critical. Power management. Forget Linux this should be the year of the NetBSD desktop but we can’t have nice architectures bc of economics in computing. The whole scenario makes sense but the emergent result sucks.

bayindirh 9mo ago
> Modern GPU drivers are a nightmare for open source. Modern NVIDIA drviers. Let me fix that for you. Intel and AMD has their full stack in mainline already, and AMD made great effort to enable their cards fully under open source drivers, as their agreements and law allows. You can even use HDCP without exposing sensitive parts, if you want. Intel also works completely fine. However, NVIDIA's shenanigans and HDMI forum's v2.1 protectionism is something else completely.
- plagiarist 9mo ago
  I went with AMD for compatibility playing games, but AFAICT AMD ROCm is not in a great state for computation. Why can't I have both? That's something like what they're describing as "a nightmare," isn't it? "As agreements and law allows," is part of the nightmare. Under a modern OS, it should not be difficult to have the full capability of the hundreds or thousands of dollars worth of hardware you paid for.
  - Fnoord 9mo ago
    There is ZLUDA [1] for CUDA, Ollama works on AMD [2], and there's OptiScaler [3] for DLSS. For older AMD GPU there's also FSR 4 INT8, see howto here [4] [1] https://github.com/vosen/ZLUDA https://github.com/vosen/ZLUDA [2] https://ollama.com/blog/amd-preview https://ollama.com/blog/amd-preview https://github.com/likelovewant/ollama-for-amd https://github.com/likelovewant/ollama-for-amd [3] https://github.com/optiscaler/OptiScaler https://github.com/optiscaler/OptiScaler [4] https://github.com/007Lore/AMD-FSR-4-INT8 https://github.com/007Lore/AMD-FSR-4-INT8
- adrian_b 9mo ago

6ak74rfy 9mo ago

I've had a passing curiosity about Guix, so it was good to read this report. One thing I didn't find is Guix on servers. I am all-in on NixOS for both my daily driver desktop and couple of servers, and adding more of either will be simple modifications to my flake repository. I really appreciate that simplicity and consistency. Does Guix offer that? The other thing is package availability: it's amazing on Nix. Plus, they remain relatively fresh on the unstable channel. How's that on Guix?

k__ 9mo ago
How do you deploy NixOS to your servers? I started a project with nixos-anywhere, deploy-rs, and compose2nix. However, I struggle a bit with secret management.
- drdaeman 9mo ago
  There are plenty of options: nix-sops, or nix-age, or whatever you would like - past the overall idea the implementation details are purely a matter of taste how you fancy things to be. Key idea is to have encrypted secrets in the store, decrypted at runtime using machine-specific credentials (host SSH keys are a typical option to repurpose, or you can set up something else). For local management you also encrypt to the “developer” keys (under the hood data is symmetrically encrypted with a random key and that key is encrypted to every key you have - machines and humans). Alternatively, you can set up a secrets service (like a password manager/vault) and source from that. Difference is where the secrets live (encrypted store or networked service, with all the consequences of every approach), commonality is that they’re fetched at runtime, before your programs start. I’m currently using deploy-rs, but if I’d redo my stuff (and the only reason I don’t is that I’m pretty much overwhelmed by life) I’d probably go with plain vanilla nixos-rebuild --target-host and skip any additional layers (that introduce extra complexity and fragility). Just a crude and somewhat haphazard summary but hope it helps.
  - diarrhea 9mo ago
    I have been using nixos-rebuild with target host and it has been totally fine. The only thing I have not solved is password-protected sudo on the target host. I deploy using a dedicated user, which has passwordless sudo set up to work. Seems like a necessary evil.

gurjeet 9mo ago

TLDR: ... I'm getting a comparable experience to NixOS, with all the usual pros a declarative environment brings and without having to put up with Nixlang.

oasisaimlessly 9mo ago
Instead, put up with a flavor of Scheme that looks suspiciously like Nix with some extra parentheses...
- eikenberry 9mo ago
  How the errors/debugging compare? From what I've read this is the main pain point with Nix where a more mature language like Guile should have a much better experience here. The article touches on this but I'd be curious of a more extensive comparison about this aspect.
  - anthk 9mo ago
    Emacs + Geiser can do everything from a REPL in order to debug it. Emacs and Guile integration both come for free since decades.
  - assbuttbuttass 9mo ago
    Just a personal anecdote, but the errors from Guix are terrible. I had to reinstall because I couldn't figure out the scheme errors for my system config
    - Pay08 9mo ago
      It's generally a problem with Guile. If you get decently good with Geiser or stare at the stack traces long enough, you can figure out the problem but I shouldn't have to do either.
- bsder 9mo ago
  And which an LLM/AI model can apply the huge training set of Lisp/Scheme to help solve your problem. Nixlang is so infuriatingly obtuse that I generally have to fire up Discord and bug the local Nix acolyte when something goes wrong. I've bounced Nixlang off of the LLM/AIs, but I have learned that if the AI doesn't give you the correct answer immediately for Nixlang then you need to stop; everything forward will be increasingly incorrect hallucinations. I suspect LLM/AIs will hallucinate far, far less with the Scheme from Guix.

kkfx 9mo ago

My issue with Guix coming from NixOS is the missing first-class zfs support for root, crypto included, RustDesk, few other common services who are hard to package. Guix potential target IMVHO should be desktop power users, not HPC, NixOS while mostly developed for embedded systems (Anduril) or servers in general still take care of desktops, Guix apparently not and that's a big issue... Nowadays outside academia I doubt there are many GNU/Linux users who deploy on plain ext4...

akshitgaur2005 9mo ago
See this config for an example guix config with zfs - https://codeberg.org/hako/Testament/ https://codeberg.org/hako/Testament/
- autumn-antlers 9mo ago
  > Guix channels in use: > - guix (additional patches are used locally for root on ZFS support) i'm hopeful too, but think it may not be so simple (yet) >u< here's a more precise link https://codeberg.org/guix/guix/pulls/1917#issuecomment-6976089 https://codeberg.org/guix/guix/pulls/1917#issuecomment-69760...
- kkfx 9mo ago
  Thanks! A very nice set of configs. I've done something similar for NixOS and my LAN but never advanced at such point in Guix.
blm126 9mo ago
For desktop usage, I would be absolutely shocked if ext4 isn't the most common filesystem by a pretty wide margin. Its the default on Ubuntu, Debian, and Mint. Those are the 3 leading desktop distros. No one is going to write a blog post titled "Why I just used the default filesystem in the installer" but that is what most people do. Things like btrfs and zfs are useful, complicated technologies that are fun to write about, fun to read about, and fun to experiment with. I'd be careful about assuming that leads to more general use, though. Its a lot like Guix and NixOS, in fact. They get all the attention in a forum like this. Ubuntu is what gets all the people, though.

dietr1ch 9mo ago

> merely pulling in Nixpkgs is an effort, due to the repository being massive. I've embraced daily shallow clone/fetches and the burden is now mostly just the 2GB of disk space. It's a bit annoying though that git doesn't make it easier. No one would shallow clone later screw up and download every commit anyway, I feel shallow clone repos should be set up with a different configuration that fully-embraces shallow history (not that the configuration options even exist today AFAIK).

bsimpson 9mo ago
I've only been doing this for a few weeks, so too early to tell if it's a good setup, but I added a GitHub Action that rebases my personal fork atop nixpkgs-weekly. I'm hoping that will help keep me from having a stale-by-default personal nixpkgs. (I use a personal nixpkgs to stage PRs waiting to be merged upstream.) https://github.com/appsforartists/nixpkgs/commit/769a72d3a6ffeab2bc7511b2a2b5a0da63a40376 https://github.com/appsforartists/nixpkgs/commit/769a72d3a6f...
- dietr1ch 9mo ago
  I remember thinking about doing that, but found value in having my fork tell me when was the last time I synced with upstream which was something useful to assess if I wanted to rebase my patch once again. Eventually my change got upstream and I stopped tracking my own fork though.
  - bsimpson 9mo ago
    I started doing it this way (auto-rebase) when I started sharing one home-manager config across different devices. This lets me do `nix flake update` on my home-manager config to have all my in-flight patches + the canonical nixpkgs from any device, and trust that they can all see the shared GitHub to sync. Hopefully will make updating less of a chore. Only time it's bit me so far was when godot3 was broken in nixpkgs-weekly but worked in 25.11. Forced me to go write a PR for that and get it upstream to get my build working again, but that was more of a nixpkgs-weekly problem than a personal fork one. One of the wrinkles of getting home-manager going on a bunch of different devices is that it liked to copy my local git checkout of nixpkgs to /nix/store a lot. That's why I'm preferring to have flake.lock point at my github.com branch, and then I can test uncommitted changes as-needed by passing --local to my home-manager switch incantation: https://github.com/appsforartists/device-config/blob/c09d6bc167f6c44dbac24c6c33c97a8f98c27c83/modules/terminal/zsh.nix#L62-L85 https://github.com/appsforartists/device-config/blob/c09d6bc...