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.
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.
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.
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/ 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/ 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.
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.
> 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.
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.
For what it's worth the association with GNU is basically historical at this point. RMS has never accepted the original vision of the project (to be the official GNU OS) and the project outgrew GNU's dilapidated infrastructure a long time ago, which the project is finally addressing with the migration to Codeberg. The FSF gave the project a place for people to donate specifically to Guix but have never really embraced it, otherwise. That has been superseded by a dedicated European nonprofit for Guix. The most recent Guix Days gathering before FOSDEM featured a lengthy conversation of breaking ties with GNU entirely but no decision has been made on that, yet.
It seems to me like the better strategy would be to "do the right thing" according to the internal values of the project and make GNU be the one who breaks ties, otherwise the opportunity for positively influencing something important is lost. Still a newcomer though, so that's just my 2c. Hope to be there with y'all in Brussels next year! By the time I found out about it, it was apparently already full.
> Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents.
While that may be true, it is particularly the case for nixpkgs; i.e., you may imagine a contender to nixpkgs that is less tangled.
I’ve recently enjoyed reading on research into simpler alternatives; GrizzlT’s deep-dive into nixpkgs design patterns, and nrdxp’s atom format:
Off the top of my head: GCC, Emacs, coreutils, sed, grep, find, parallel, Guile, Coreboot, GNOME, GIMP, GnuPG, Bash
In each case, development is the work of the developers, and they themselves deserve most credit. But the FSF and the GNU project have certainly been involved with lots of software that is important, widely used, and works well.
GNU software is still responsible for huge and often critical chunks of the stack in most Linux distros.
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.
Not necessarily. In (my understanding of) FSF orthodoxy the existence of a viable GPL alternative forces the hand of competitors in certain respects. LLVM could never drift towards a more proprietary model and expect to succeed at it so long as GCC remains viable.
"Best" doesn't matter, you just need a seed crystal that's good enough.
The vulnerability in the thinking is that if GNU can't reliably get crystals started, if the seeds that make it are dependent on some external force like Cygnus or Linux, and dominant GCC can become has-been GCC, maybe we're looking at an afterglow of some luck and experiment that has a very bleak future if left alone.
Maybe people realized the FSF model isn't sustainable, and a model dependent on mass-volunteerism and religious viral spread of cooperative behaviors falls off when the days become months and the months become years. What if the greys are not being replaced by the dabbers. If that's the case, there won't be another bang.
Maybe see what I'm up to with https://prizeforge.com. I'm hoping to get the MVP functioning with semi-decency today. Mac does not agree with the WASM and I have at least one small dirty hack to execute before I can go live.
Already happening my friend. uutils. It is MIT licensed. Funnily, I recall someone had a story at MIT about not liking passwords. I'm sure they were right?
It may be happening in your bubble, yes, but not outside of that. They are not 1:1 replacements at all, with probably logic bugs introduced (see their Issues page) as well (call them regressions). I would not hold my breath if I were you.
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.
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.
>(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.
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.
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.
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.
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.
Tbh for me both seems the same. I can ignore both digital notifications and open book/paper lying there to reminder me of a task.
Its the mental state of person to commit for getting things done.
Digital method gives lot of space for organizing tho.
Emacs is the most open software you will see. I'd say it has good community, extension (packages) and legacy of staying maintained.
You can craft emacs as you want, more than an editor. You can interface with various tools.
Heck the main USP you would realize is the god-tier documentation on everything and discovering tiny features.
Since you mentioned only note-taking, I'd say in that area, emacs excels.
But note that note-taking system is not everything, emacs will allow you to craft and build workflow as you require.
> Where do they shine compared to Obsidian?
emacs is: Editor + Note taking + Code editor + Integrate with tools ++ Extend more
> Where are they worse?
You might feel like packages or community is not that fast paced compared to other popular, trendy tools.
Emacs is a investment and journey, its not so I know emacs, its like I grow with emacs. You need lot of time to learn and understand to grasp it.
You can try two routes,
1. Replicate same workflow as obsidian in emacs, or
2. use emacs from scratch (minimal config) and understand the essence of it to build your own workflow.
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.