6 ms·

Trying Guix: A Nixer's impressions

201 points by todsacerdoti 1y ago

idlip 1y ago
Its nice read. We need more of comparative posts by user familiar with both nix and guix. We see bias with most discussions. Only cons with Guix I see is, lack of infrastructure and less volunteers to work on guix eco-system. If its solved, I can imagine guix can improve exponentially.
- kwk1 1y ago
  Guix recently moved from Savannah to Codeberg, which hopefully will help move the needle on infrastructure and volunteer quantity concerns.
- tempfile 1y ago
  The major con is in the article, it is super slow to update. Half an hour is just crazy, nobody will move to that if they know.
  - kyoji 1y ago
    I play around with a Guix install in a VM, and with less than half of my system resources, a `guix pull` with a `guix system reconfigure ...` takes about 10 minutes. That said, if a pull happens to include a kernel update it can take much longer. I think pinning large packages (like the kernel) that may not need incidental updating is key to keeping pull times lower.
    - tadfisher 1y ago
      10 minutes is still an order of magnitude slower than a nixos-rebuild if you're hitting the cache, and there's no issue with forgetting to rebuild the guix profile. If you include nonguix (as is required for the 99% of users who need nonfree blobs) you get the 30-50 minutes as described in the article. I believe Nix-the-language being lazily evaluated is a big part of this; you can even inadvertently evaluate nixpkgs multiple times and not notice.
      - opan 1y ago
        >(as is required for the 99% of users who need nonfree blobs) If you forgo the built-in WiFi, the ThinkPad T440p (Haswell) works fine without any blobs (speaking from experience). I think all newer gens need iGPU blobs, sadly, but I wanted to point out a viable middle ground between modern Nvidia gamerware setups and Librebooted X200s that can barely browse the web.
  - kwk1 1y ago
    It doesn't usually take that long, but the first `guix pull` is quite slow, and what should be a no-op of running it a second time immediately afterwards also takes too long. Edit: Just to provide a measurement, on my Framework 13 with AMD Ryzen 5 7640U, a `guix pull` which pulled in 1 nonguix commit and 64 guix commits took 2m10s, and a subsequent no-op `guix pull` took 1m18s.
  - nbf_1995 1y ago
    From the article: > My goal was to take my Unchartevice laptop with its strange Zhaoxin x86_64-compatible CPU... > Sure, this is a laptop with a CPU broadly equivalent to old Intel Atom CPUs... Yes, guix pull is slow, but the author is using some old/exotic hardware. The last time I tried guix on a 5th gen dual core i5, the initial pull was not that slow. And as other commenters have pointed out. The first pull is the slowest by far.
  - positron26 1y ago
    Important question is if its fixable. Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents. Nix's runtime is not magic. Guile should be able to expose a language and evaluate it in a similar way. For my part, I've not opted into Guix because it's a GNU project, and I've decided to avoid anything in the FSF sphere of influence. Their orthodoxy turns off contributors and they have a history of taking insular hard-liner approaches that are utopian. Outside of coreutils that are about to be fully subsumed by rewrite-it-in-Rust (which has a community that is not a fan of the GPL), what has had FSF backing and been successful? Linus starts two of the most influential pieces of software in human civilization and RMS wants to name the awards. The pragmatic culture that shifted away from the FSF has I think largely adopted Nix, and it shows. Nix is open for business, available on lots of platforms, has commercial entities built around its success.
    - kwk1 1y ago
      Agreed on the assessment, but for me, part of the appeal of Guix is a way to turn that ship around.
    - pmarreck 1y ago
      isn't there nonguix? you know, the Ashley Madison of guix?
    - bheadmaster 1y ago
      > what has had FSF backing and been successful? GCC is still indispensable. I doubt it will be rewritten in Rust any time soon.
      - positron26 1y ago
        GCC was one subject of The Cathedral and the Bazaar. The development process was changed to more closely mimic Linux and the original GCC steering committee was dissolved. Cygnus had a big role in GCC becoming an industry fixture for its hayday. Eventually the lack of big revenue meant that the license became an annoyance that industry could deal with by nurturing Clang and LLVM with acceptable quantities of money. In FSF orthodoxy, they were supposed to lose that fight.
  - davexunit 1y ago
    Regular updates do not take anywhere near a half hour.
  - tazjin 1y ago
    There's a few points to make here, actually, based on discussion of the article in the weeks before it hit HN: Two major and immediate reasons why the pulling is slow are clear and fixable: 1. Guix will try to substitute from unreachable caches for a LONG time before giving up, and Guix infrastructure is less developed than Nix. When I kept experimenting after this post I set up https://mirror.yandex.ru/mirrors/guix/ https://mirror.yandex.ru/mirrors/guix/ eventually which fixes the substitute problems for me (Guix mirror on bigcorp infra). 2. Guix by default pulls its channel from GNU Savannah which, for some reason, is incredibly slow in serving git. The project moved over to Codeberg, and setting the URL to there significantly speeds up pulling. In NixOS, channels (esp. the unstable ones) advance when CI finishes building a certain subset of packages successfully (this is what https://status.nixos.org/ https://status.nixos.org/ shows). CI populates the binary cache, so this means that a channel HEAD always has a large number of packages available in the cache. Guix has no such guarantees, so updating to any latest commit might even yield one where you end up rebuilding all of its Scheme from scratch or whatever. Picking a commit that's a few days old helps with this. I eventually switched to a laptop with a "normal" Intel CPU, and pulling did not magically turn fast. In fact, some of the slowest stages (there's one where it says "Computing Guix derivation") don't seem to exercise the CPU much at all. I haven't spent time looking at why (yet). Guix System does a lot more per-user stuff than NixOS by default, which means that you'll likely end up pulling multiple times. Pulling remains a much slower operation than Nix evaluation in any case. There's a few ways to make this all more palatable (e.g. the `guix time-machine -C $channels` setup), but those might be for a follow-up post in the future.
  - rolandog 1y ago
    I think that also one needs to be familiar with modifying the guix daemon service to allow substitutes be downloaded so that you don't have to build derivations [0], [1]. Once you modify the guix daemon service and approve the substitute server keys with `guix archive`, your experience should be much faster. [0]: https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html https://guix.gnu.org/manual/en/html_node/Substitute-Server-A... [1]: https://guix.gnu.org/manual/en/html_node/Getting-Substitutes-from-Other-Servers.html https://guix.gnu.org/manual/en/html_node/Getting-Substitutes...
- msgilligan 1y ago
  > We need more of comparative posts The article focuses on a comparison between GUIX _system_ and NixOS. It would be interesting to see an equally thoughtful comparison that just focuses on GUIX vs. NIX as package managers used on another Linux distribution (e.g. Debian.) In this case, GUIX might fare better as you won't have to worry about the complexities introduced by binary blobs needed for boot, etc.
  - spease 1y ago
    Personally, I’d really like a crossplatform declarative package manager in a mainstream or mainstream-style language, where the nixpkgs equivalent can be JITed or AOTed including the shell scripts, so it isn’t painful to work with and can switch into an environment almost instantly. Though nix the language syntactically isn’t that complex, it’s really the way that nixpkgs and things like overrides are implemented, the lack of a standard interface between environments and Darwin and NixOS, needing overlays with multiple levels of depth, etc that makes things complex. The infuriating thing about nix is that it’s functionally capable of doing what I want, but it’s patently obvious that the people at the wheel are not particularly inclined to design things for a casual user who cannot keep a hundred idiosyncrasies in their head memorized just to work on their build scripts.
- exe34 1y ago
  Would it be possible to automate nix->guix for packages? A lot of nix packages (e.g. python) I think are handled automatically. If guix could build on that huge package repo, it would really help.
  - amelius 1y ago
    I suppose an LLM could easily translate the build scripts. It will not be perfect, but probably will save a lot of work.
    - evolve2k 1y ago
      I can’t find the quote right now; but it’s along the lines. LLM’s can help with the first 80% of coding which is introducing bugs, but terrible at the other 80% of the time which is removing said bugs. Lean and agile theory says that quality is improved and efficiency gained by going upstream and eliminating the things that are producing poor quality in the first place. Llm code tools may be useful to give syntax tips, but like a thoughtless dev on a team, likely introduce more work than they get done.
      - exe34 1y ago
        The thing about chatgpt/cursor is that they seem very good at fixing things if they have verbose errors - and nix is very verbose about what it hates in your config. I've given errors to chatgpt and it fixed it for me. With cursor, I had something displaying in a really weird way (plotting a map in js), and I gave it a screenshot and it fixed it immediately. I would never use llm code in prod without understanding it, but for one-off utilities it has been really great so far.
CBLT 1y ago
I had a similar experience. After running `guix pull` a couple of times on an ancient laptop I shelved the project until I made a distcc cluster (I never did).
pkulak 1y ago
> why flakes are nonsense Oh wow, I want to hear more about that. I love flakes, but I've known they are controversial, and never really heard why.
- realo 1y ago
  I like flakes... I use flakes. You love flakes... keep using them! The rest is politics.
  - pkulak 1y ago
    For sure. But I find other people's opinions interesting.
    - chriswarbo 1y ago
      Here's some of my opinions on flakes, FWIW https://lobste.rs/s/6js1hj/flakes_have_failed#c_byu8ds https://lobste.rs/s/6js1hj/flakes_have_failed#c_byu8ds
- hamandcheese 1y ago
  - flakes perform very poorly in large repos. This might be changing soon with lazy-trees, but I've been waiting for that for 2+ years. - flake inputs are not fetched lazily. - flakes are somewhat restrictive in that you can't override an input with an arbitrary value. This matters if you want to pass in, say, a specially configured nixpkgs object. In practice, for non trivial use cases, flakes fail to solve the problem they set out to solve. Most flakes expose lib functions for these advanced use cases but that's pretty much equivalent to what you get with non-flakes.
- dawnofdusk 1y ago
  I mean they get evaluated in a weird way: for example you cannot use the `rec` keyword when declaring inputs.
- ethan_smith 1y ago
  Flakes are controversial primarily because they create a parallel ecosystem that breaks compatibility with the traditional Nix workflow, introduce additional complexity without solving core reproducibility issues, and were developed with limited community input despite representing a fundamental shift in how Nix works.
peterldowns 1y ago
Very interesting writeup, as a long-time Nix user I've always been interested in trying guix but never gotten around to it. Great post overall. > The thing is, I'm not actually sure if Guix's better documentation helps smooth the onboarding in any way because you have to already know Scheme, which is a more complex language than Nix. LMAO absolutely not. Nix-the-language is the worst programming language I've ever had the misfortune to interact with. I picked up Scheme in about 1 day during a class in college. It's night-and-day different.
- otabdeveloper4 1y ago
  > Nix-the-language is the worst programming language I've ever had the misfortune to interact with Nix-the-language is just a subset of Javascript with built-in laziness and a slightly different syntax. An absolute bog-standard and mainstream way of thinking about programs in 2025. That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development.
  - grep_name 1y ago
    > That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so. Nix only won out for me because of the mac compatibility, without which I can't really use it at work
    - 0x457 1y ago
      I think nix-the-language is pretty simple and easy to learn language. It's visually hard to parse and a lot of syntax decisions make you wonder, but it's not the worst. The problem is that you're very rarely exposed to it directly. You are always multiple layers of abstractions away from it. Most of these layers are completely undocumented.
hamandcheese 1y ago
The main thing holding me back from trying guix is that, as far as I know, there is no support for macOS.
- School-Cotton 1y ago
  Correct, Guix is Linux and Hurd only.
  - agumonkey 1y ago
    Are people using Hurd still ?
    - School-Cotton 1y ago
      Was anyone ever using it? I assume some nonzero number of hobbyists or true believers still are, but AFAIK those are the only ones who ever were.
      - agumonkey 1y ago
        At one point arch-hurd had some active members using it enough to update packages
- kwk1 1y ago
  It's still pretty early, but there's a "macOS Subsystem for Guix" project: https://superkamiguru.org/projects/msg.html https://superkamiguru.org/projects/msg.html
  - hamandcheese 1y ago
    If I understand correctly, that seems to virtualize a Linux system to work, which makes it quite different from nix on macOS.
    - kwk1 1y ago
guilhas 1y ago
I like them both, both interesting, quite similar, both with corner cases Annoyingly both fail at basic stuff like falling back the graphics card, something Debian had solved 10 years ago, no configs needed, no matter Intel/NVIDIA/AMD. Even without the correct driver or firmware falling back to VESA or fbdev should be a given. Never had so many black screens as now. Even Windows has done better job at giving you a basic resolution while you install the drivers Or maybe it's just the state of the Linux ecosystem, with the introduction of Wayland and NVIDIA open drivers, causing regressions Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default Which increases the amount of bugs, having frequent updates to a stable system To make it better you can add 2 channels, and call them nixos-stable v24 nixos-latest v25, keeping most of the system one version down increases stability a lot Of course the incorporated Grub boot build choices is great to revert back to a working system I really like the the separation Guix makes on having close source being a concern of a separate project But both of them are equally easy to install open source only or include proprietary
- yjftsjthsd-h 1y ago
  > But both of them are equally easy to install open source only or include proprietary Unless it really dramatically changed recently, I don't think that's true. Look, here's the official manual page that describes exactly how to enable use of the non-free packages that are right there in the main nixpkgs repo: https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree And here's the guix equivalent, maintained in a completely separate repo that you're not allowed to talk about, document, or refer to in any official channels: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix These are not equal.
  - guilhas 1y ago
    > These are not equal. Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes... Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki
hardwaresofton 1y ago
Guix SD will never catch on as long as they force non-systemd management. I don’t care to try Shepherd. Systemd is good enough and it has won. > I had to use nonguix to get internet working on the machine, which had very immediate technical effects that bring me to Stuff like this will The main reasons I’m interested in guix: - it uses a known-good language (lisp) - IIRC it is more repeatable (the contents used in derivations play into the hash). - It has a full source bootstrap Maybe someone with a focus on improving UX needs to build one of these afresh.
- deleted 1y ago
  [deleted]
- medstrom 1y ago
  I don't know if importing systemd would make any difference to the system declaration file that you write, where you'd still declare services in the Lispy way. Does it matter if it translates to systemd services under the hood or not?
  - hardwaresofton 1y ago
    > Does it matter if it translates to systemd services under the hood or not? I think so, because that's what most people are familiar with maintaining/configuring. Systemd at this point is quite robust, and it's sprawling ecosystem has a lot of functionality. Perhaps more importantly, this is the stuff you'll find the most support/integrations for.
- bjoli 1y ago
  After getting used to systemd, I decided to put my toes in the water and try guix. From a user's perspective you never really don't have to care much. Even complex services are pretty simple, and it is really not like you are doing anything different. The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later. My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.
abrookewood 1y ago
I'm actually more interested in the Niri "A scrollable-tiling Wayland compositor". It never occurred to me that a valid desktop/windowing paradigm would be one with an infinite horizontal strip. Not sure if I want it, but it's pretty unique. https://github.com/YaLTeR/niri?tab=readme-ov-file https://github.com/YaLTeR/niri?tab=readme-ov-file
- evgpbfhnr 1y ago
  I've switched from wmii (old suckless tiling wm) to niri a couple of months ago and I've been happier with it than with sway/i3 -- give it a shot :)
- cenamus 1y ago
  Is it similar to the Gnome plugin PaperWM?
  - emaro 1y ago
    Yes, Niri is inspired by PaperWM afaik.
- sunshine-o 1y ago
  Scrollable-tiling is the best. Especially if you have two wide monitors side by side.
- nicman23 1y ago
  i used to do something like that with i3. binding meta+tab to go to the next workplace and some combos to move the windows with the same base. then i realized that it is basically just want i did with compiz or kwin and moved back lol
- yencabulator 1y ago
  Think of it less as an "infinite strip" (with implications of windows being lost in the mist, far away) and more as "each workspace is laid out in a strip". Most of my workspaces have 2-5 columns, with 2-3 fitting on an ultrawide monitor at once.[1] It's more like "what if tiling window manager, but with even less time spent on adjusting window sizes". [1]: Let's agree not to talk of the insanity that contains my open browser windows. That is as near infinite as 96 GB RAM lets me have..

201 points by todsacerdoti 1y ago

Its nice read. We need more of comparative posts by user familiar with both nix and guix. We see bias with most discussions. Only cons with Guix I see is, lack of infrastructure and less volunteers to work on guix eco-system. If its solved, I can imagine guix can improve exponentially.

kwk1 1y ago
Guix recently moved from Savannah to Codeberg, which hopefully will help move the needle on infrastructure and volunteer quantity concerns.
tempfile 1y ago
The major con is in the article, it is super slow to update. Half an hour is just crazy, nobody will move to that if they know.
- kyoji 1y ago
  I play around with a Guix install in a VM, and with less than half of my system resources, a `guix pull` with a `guix system reconfigure ...` takes about 10 minutes. That said, if a pull happens to include a kernel update it can take much longer. I think pinning large packages (like the kernel) that may not need incidental updating is key to keeping pull times lower.
  - tadfisher 1y ago
    10 minutes is still an order of magnitude slower than a nixos-rebuild if you're hitting the cache, and there's no issue with forgetting to rebuild the guix profile. If you include nonguix (as is required for the 99% of users who need nonfree blobs) you get the 30-50 minutes as described in the article. I believe Nix-the-language being lazily evaluated is a big part of this; you can even inadvertently evaluate nixpkgs multiple times and not notice.
    - opan 1y ago
      >(as is required for the 99% of users who need nonfree blobs) If you forgo the built-in WiFi, the ThinkPad T440p (Haswell) works fine without any blobs (speaking from experience). I think all newer gens need iGPU blobs, sadly, but I wanted to point out a viable middle ground between modern Nvidia gamerware setups and Librebooted X200s that can barely browse the web.
- kwk1 1y ago
  It doesn't usually take that long, but the first `guix pull` is quite slow, and what should be a no-op of running it a second time immediately afterwards also takes too long. Edit: Just to provide a measurement, on my Framework 13 with AMD Ryzen 5 7640U, a `guix pull` which pulled in 1 nonguix commit and 64 guix commits took 2m10s, and a subsequent no-op `guix pull` took 1m18s.
- nbf_1995 1y ago
  From the article: > My goal was to take my Unchartevice laptop with its strange Zhaoxin x86_64-compatible CPU... > Sure, this is a laptop with a CPU broadly equivalent to old Intel Atom CPUs... Yes, guix pull is slow, but the author is using some old/exotic hardware. The last time I tried guix on a 5th gen dual core i5, the initial pull was not that slow. And as other commenters have pointed out. The first pull is the slowest by far.
- positron26 1y ago
  Important question is if its fixable. Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents. Nix's runtime is not magic. Guile should be able to expose a language and evaluate it in a similar way. For my part, I've not opted into Guix because it's a GNU project, and I've decided to avoid anything in the FSF sphere of influence. Their orthodoxy turns off contributors and they have a history of taking insular hard-liner approaches that are utopian. Outside of coreutils that are about to be fully subsumed by rewrite-it-in-Rust (which has a community that is not a fan of the GPL), what has had FSF backing and been successful? Linus starts two of the most influential pieces of software in human civilization and RMS wants to name the awards. The pragmatic culture that shifted away from the FSF has I think largely adopted Nix, and it shows. Nix is open for business, available on lots of platforms, has commercial entities built around its success.
  - kwk1 1y ago
    Agreed on the assessment, but for me, part of the appeal of Guix is a way to turn that ship around.
  - pmarreck 1y ago
    isn't there nonguix? you know, the Ashley Madison of guix?
  - bheadmaster 1y ago
    > what has had FSF backing and been successful? GCC is still indispensable. I doubt it will be rewritten in Rust any time soon.
    - positron26 1y ago
      GCC was one subject of The Cathedral and the Bazaar. The development process was changed to more closely mimic Linux and the original GCC steering committee was dissolved. Cygnus had a big role in GCC becoming an industry fixture for its hayday. Eventually the lack of big revenue meant that the license became an annoyance that industry could deal with by nurturing Clang and LLVM with acceptable quantities of money. In FSF orthodoxy, they were supposed to lose that fight.
- davexunit 1y ago
  Regular updates do not take anywhere near a half hour.
- tazjin 1y ago
  There's a few points to make here, actually, based on discussion of the article in the weeks before it hit HN: Two major and immediate reasons why the pulling is slow are clear and fixable: 1. Guix will try to substitute from unreachable caches for a LONG time before giving up, and Guix infrastructure is less developed than Nix. When I kept experimenting after this post I set up https://mirror.yandex.ru/mirrors/guix/ https://mirror.yandex.ru/mirrors/guix/ eventually which fixes the substitute problems for me (Guix mirror on bigcorp infra). 2. Guix by default pulls its channel from GNU Savannah which, for some reason, is incredibly slow in serving git. The project moved over to Codeberg, and setting the URL to there significantly speeds up pulling. In NixOS, channels (esp. the unstable ones) advance when CI finishes building a certain subset of packages successfully (this is what https://status.nixos.org/ https://status.nixos.org/ shows). CI populates the binary cache, so this means that a channel HEAD always has a large number of packages available in the cache. Guix has no such guarantees, so updating to any latest commit might even yield one where you end up rebuilding all of its Scheme from scratch or whatever. Picking a commit that's a few days old helps with this. I eventually switched to a laptop with a "normal" Intel CPU, and pulling did not magically turn fast. In fact, some of the slowest stages (there's one where it says "Computing Guix derivation") don't seem to exercise the CPU much at all. I haven't spent time looking at why (yet). Guix System does a lot more per-user stuff than NixOS by default, which means that you'll likely end up pulling multiple times. Pulling remains a much slower operation than Nix evaluation in any case. There's a few ways to make this all more palatable (e.g. the `guix time-machine -C $channels` setup), but those might be for a follow-up post in the future.
- rolandog 1y ago
  I think that also one needs to be familiar with modifying the guix daemon service to allow substitutes be downloaded so that you don't have to build derivations [0], [1]. Once you modify the guix daemon service and approve the substitute server keys with `guix archive`, your experience should be much faster. [0]: https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html https://guix.gnu.org/manual/en/html_node/Substitute-Server-A... [1]: https://guix.gnu.org/manual/en/html_node/Getting-Substitutes-from-Other-Servers.html https://guix.gnu.org/manual/en/html_node/Getting-Substitutes...
msgilligan 1y ago
> We need more of comparative posts The article focuses on a comparison between GUIX _system_ and NixOS. It would be interesting to see an equally thoughtful comparison that just focuses on GUIX vs. NIX as package managers used on another Linux distribution (e.g. Debian.) In this case, GUIX might fare better as you won't have to worry about the complexities introduced by binary blobs needed for boot, etc.
- spease 1y ago
  Personally, I’d really like a crossplatform declarative package manager in a mainstream or mainstream-style language, where the nixpkgs equivalent can be JITed or AOTed including the shell scripts, so it isn’t painful to work with and can switch into an environment almost instantly. Though nix the language syntactically isn’t that complex, it’s really the way that nixpkgs and things like overrides are implemented, the lack of a standard interface between environments and Darwin and NixOS, needing overlays with multiple levels of depth, etc that makes things complex. The infuriating thing about nix is that it’s functionally capable of doing what I want, but it’s patently obvious that the people at the wheel are not particularly inclined to design things for a casual user who cannot keep a hundred idiosyncrasies in their head memorized just to work on their build scripts.
exe34 1y ago
Would it be possible to automate nix->guix for packages? A lot of nix packages (e.g. python) I think are handled automatically. If guix could build on that huge package repo, it would really help.
- amelius 1y ago
  I suppose an LLM could easily translate the build scripts. It will not be perfect, but probably will save a lot of work.
  - evolve2k 1y ago
    I can’t find the quote right now; but it’s along the lines. LLM’s can help with the first 80% of coding which is introducing bugs, but terrible at the other 80% of the time which is removing said bugs. Lean and agile theory says that quality is improved and efficiency gained by going upstream and eliminating the things that are producing poor quality in the first place. Llm code tools may be useful to give syntax tips, but like a thoughtless dev on a team, likely introduce more work than they get done.
    - exe34 1y ago
      The thing about chatgpt/cursor is that they seem very good at fixing things if they have verbose errors - and nix is very verbose about what it hates in your config. I've given errors to chatgpt and it fixed it for me. With cursor, I had something displaying in a really weird way (plotting a map in js), and I gave it a screenshot and it fixed it immediately. I would never use llm code in prod without understanding it, but for one-off utilities it has been really great so far.

CBLT 1y ago

I had a similar experience. After running `guix pull` a couple of times on an ancient laptop I shelved the project until I made a distcc cluster (I never did).

pkulak 1y ago

> why flakes are nonsense Oh wow, I want to hear more about that. I love flakes, but I've known they are controversial, and never really heard why.

realo 1y ago
I like flakes... I use flakes. You love flakes... keep using them! The rest is politics.
- pkulak 1y ago
  For sure. But I find other people's opinions interesting.
  - chriswarbo 1y ago
    Here's some of my opinions on flakes, FWIW https://lobste.rs/s/6js1hj/flakes_have_failed#c_byu8ds https://lobste.rs/s/6js1hj/flakes_have_failed#c_byu8ds
hamandcheese 1y ago
- flakes perform very poorly in large repos. This might be changing soon with lazy-trees, but I've been waiting for that for 2+ years. - flake inputs are not fetched lazily. - flakes are somewhat restrictive in that you can't override an input with an arbitrary value. This matters if you want to pass in, say, a specially configured nixpkgs object. In practice, for non trivial use cases, flakes fail to solve the problem they set out to solve. Most flakes expose lib functions for these advanced use cases but that's pretty much equivalent to what you get with non-flakes.
dawnofdusk 1y ago
I mean they get evaluated in a weird way: for example you cannot use the `rec` keyword when declaring inputs.
ethan_smith 1y ago
Flakes are controversial primarily because they create a parallel ecosystem that breaks compatibility with the traditional Nix workflow, introduce additional complexity without solving core reproducibility issues, and were developed with limited community input despite representing a fundamental shift in how Nix works.

peterldowns 1y ago

Very interesting writeup, as a long-time Nix user I've always been interested in trying guix but never gotten around to it. Great post overall. > The thing is, I'm not actually sure if Guix's better documentation helps smooth the onboarding in any way because you have to already know Scheme, which is a more complex language than Nix. LMAO absolutely not. Nix-the-language is the worst programming language I've ever had the misfortune to interact with. I picked up Scheme in about 1 day during a class in college. It's night-and-day different.

otabdeveloper4 1y ago
> Nix-the-language is the worst programming language I've ever had the misfortune to interact with Nix-the-language is just a subset of Javascript with built-in laziness and a slightly different syntax. An absolute bog-standard and mainstream way of thinking about programs in 2025. That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development.
- grep_name 1y ago
  > That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so. Nix only won out for me because of the mac compatibility, without which I can't really use it at work
  - 0x457 1y ago
    I think nix-the-language is pretty simple and easy to learn language. It's visually hard to parse and a lot of syntax decisions make you wonder, but it's not the worst. The problem is that you're very rarely exposed to it directly. You are always multiple layers of abstractions away from it. Most of these layers are completely undocumented.

hamandcheese 1y ago

The main thing holding me back from trying guix is that, as far as I know, there is no support for macOS.

School-Cotton 1y ago
Correct, Guix is Linux and Hurd only.
- agumonkey 1y ago
  Are people using Hurd still ?
  - School-Cotton 1y ago
    Was anyone ever using it? I assume some nonzero number of hobbyists or true believers still are, but AFAIK those are the only ones who ever were.
    - agumonkey 1y ago
      At one point arch-hurd had some active members using it enough to update packages
kwk1 1y ago
It's still pretty early, but there's a "macOS Subsystem for Guix" project: https://superkamiguru.org/projects/msg.html https://superkamiguru.org/projects/msg.html
- hamandcheese 1y ago
  If I understand correctly, that seems to virtualize a Linux system to work, which makes it quite different from nix on macOS.
  - kwk1 1y ago

guilhas 1y ago

I like them both, both interesting, quite similar, both with corner cases Annoyingly both fail at basic stuff like falling back the graphics card, something Debian had solved 10 years ago, no configs needed, no matter Intel/NVIDIA/AMD. Even without the correct driver or firmware falling back to VESA or fbdev should be a given. Never had so many black screens as now. Even Windows has done better job at giving you a basic resolution while you install the drivers Or maybe it's just the state of the Linux ecosystem, with the introduction of Wayland and NVIDIA open drivers, causing regressions Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default Which increases the amount of bugs, having frequent updates to a stable system To make it better you can add 2 channels, and call them nixos-stable v24 nixos-latest v25, keeping most of the system one version down increases stability a lot Of course the incorporated Grub boot build choices is great to revert back to a working system I really like the the separation Guix makes on having close source being a concern of a separate project But both of them are equally easy to install open source only or include proprietary

yjftsjthsd-h 1y ago
> But both of them are equally easy to install open source only or include proprietary Unless it really dramatically changed recently, I don't think that's true. Look, here's the official manual page that describes exactly how to enable use of the non-free packages that are right there in the main nixpkgs repo: https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree And here's the guix equivalent, maintained in a completely separate repo that you're not allowed to talk about, document, or refer to in any official channels: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix These are not equal.
- guilhas 1y ago
  > These are not equal. Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes... Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki

hardwaresofton 1y ago

Guix SD will never catch on as long as they force non-systemd management. I don’t care to try Shepherd. Systemd is good enough and it has won. > I had to use nonguix to get internet working on the machine, which had very immediate technical effects that bring me to Stuff like this will The main reasons I’m interested in guix: - it uses a known-good language (lisp) - IIRC it is more repeatable (the contents used in derivations play into the hash). - It has a full source bootstrap Maybe someone with a focus on improving UX needs to build one of these afresh.

deleted 1y ago
[deleted]
medstrom 1y ago
I don't know if importing systemd would make any difference to the system declaration file that you write, where you'd still declare services in the Lispy way. Does it matter if it translates to systemd services under the hood or not?
- hardwaresofton 1y ago
  > Does it matter if it translates to systemd services under the hood or not? I think so, because that's what most people are familiar with maintaining/configuring. Systemd at this point is quite robust, and it's sprawling ecosystem has a lot of functionality. Perhaps more importantly, this is the stuff you'll find the most support/integrations for.
bjoli 1y ago
After getting used to systemd, I decided to put my toes in the water and try guix. From a user's perspective you never really don't have to care much. Even complex services are pretty simple, and it is really not like you are doing anything different. The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later. My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.

abrookewood 1y ago

I'm actually more interested in the Niri "A scrollable-tiling Wayland compositor". It never occurred to me that a valid desktop/windowing paradigm would be one with an infinite horizontal strip. Not sure if I want it, but it's pretty unique. https://github.com/YaLTeR/niri?tab=readme-ov-file https://github.com/YaLTeR/niri?tab=readme-ov-file

evgpbfhnr 1y ago
I've switched from wmii (old suckless tiling wm) to niri a couple of months ago and I've been happier with it than with sway/i3 -- give it a shot :)
cenamus 1y ago
Is it similar to the Gnome plugin PaperWM?
- emaro 1y ago
  Yes, Niri is inspired by PaperWM afaik.
sunshine-o 1y ago
Scrollable-tiling is the best. Especially if you have two wide monitors side by side.
nicman23 1y ago
i used to do something like that with i3. binding meta+tab to go to the next workplace and some combos to move the windows with the same base. then i realized that it is basically just want i did with compiz or kwin and moved back lol
yencabulator 1y ago
Think of it less as an "infinite strip" (with implications of windows being lost in the mist, far away) and more as "each workspace is laid out in a strip". Most of my workspaces have 2-5 columns, with 2-3 fitting on an ultrawide monitor at once.[1] It's more like "what if tiling window manager, but with even less time spent on adjusting window sizes". [1]: Let's agree not to talk of the insanity that contains my open browser windows. That is as near infinite as 96 GB RAM lets me have..