Attempting to Use GNU Guix
zge.us.to
zge.us.to
It has generally been smooth sailing, with the occasional hick up that required me to draw upon my general Unix skills. What caught me off guard is how having a solid configuration to revert to has made me start tinkering with my operating system again akin to how I did when I started using Linux/BSD in the early 00s. But, enough about NixOS, I hope GNU Guix continues to make progress as there needs to be more competition in this space. If you have an evening to spare, I highly recommend trying a distribution like this out in a VM to get a taste of what it feels like to use it – it is, different… but in a good way.
https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modu...
https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-sp...
Because they're contained within the same git repo, if a new version of wpa_supplicant changed the syntax of wpa_supplicant.conf, the upgrade could be handled easily (assuming the user-facing options in NixOS didn't need to change).
For more complicated changes, there's `system.stateVersion`:
https://nixos.wiki/wiki/FAQ/When_do_I_update_stateVersion
An example of this would be if NixOS version A ships with Postgres version X by default, while NixOS version B upgrades to Postgres version Y. stateVersion allows a sane upgrade path where you can update to NixOS version B without breaking your database immediately (because stateVersion is still A).
How it is done, depends on a module.
After switching to NixOS, I'd find it very frustrating to go back to an OS with imperative-style package/service management. It's clearly the better way.
A frustrating thing about NixOS--coming from Arch Linux and being used to the AUR--is that adding packages/updating packages can be a bit slow due to the sheer volume of PRs/Issues on the nixpkgs repo. There's always the NUR[1] but it hasn't picked up that much momentum yet (probably because it's kind of hard to search the darn thing). Eitherway, the packages are just Nix expressions and repos are just collections of these expressions, so nothing's preventing a real AUR alternative other than momentum.
It's interesting that Guix uses scheme instead of a home-baked configuration language like NixOS. While I don't find Nix particularly offensive, I don't find it particularly great either. And maybe this is naivity/Nix-inexperience on my part speaking, but I really wish that Nix had a proper type system and was strictly typed.
I guess my pipe dream is "HaskellOS" that's basically NixOS configured with Haskell (just think of xmonad-style configuration for your whole OS). That'd be really nice. And my secondary-pipe dream is a baked in, extremely-comprehensive home-manager[2] so we can bid dotfiles goodbye once and for all and have your entire system-state defined in a single file.
Maybe one day :)
https://propellor.branchable.com/
http://joeyh.name/blog/entry/unifying_OS_installation_and_co... kinda talks about this sort of thing
As a long time contributor, I'd much, much rather see our bug reporting, triage, and discovery/resolution strategies improve first -- long before going as far as splitting up the mono-repository. That's the part that's frustrating for users (their reports get lost, forgotten, duplicated) -- not the fact the default set merely has a lot of packages.
For reference, the LLVM bug tracker has exactly ten thousand open bugs as of this writing, and I assume that number is only so perfectly rounded because Bugzilla search refuses to return any more results in a single page that already brings scrolling in Chrome to its knees. You won't find any lack of praise for LLVM's high quality and extensible nature, though -- they can all be true at once!
The nixpkgs label tracker isn't highly accurate since auto-labeling only started earlier as of this year, but as of this writing, of the 3k open issues, about 500 of them are directly marked as bugs, while 41 are marked as regressions. There are 200 enhancement requests, and 50 open packaging requests. So of 3,300 bugs, about 800 can be quickly classified, and about half of those are actual bugs. This is a very ballpark number (GitHub search doesn't allow XOR). Considering nixpkgs is literally shipping thousands of other software projects, I think this is pretty good -- even though I wouldn't argue it could be cleanly extrapolated to the whole set of bugs, because of a long tail of old bugs.
In terms of cadence, over the last month there were ~466 new PRs, and ~1,600 merged PRs. ~220 closed issues vs 215 new ones. This is done by nearly 350 contributors. I would think this is also very good and the sign of a healthy project with hundreds of active developers. IMO, if just a raw number of "3,000 open github issues" has to mean anything ("this software is unstable"), then these numbers have to mean something too. It's just that GitHub doesn't "helpfully" post them on every single page concerning your project...
But I do agree we should have better mechanisms for discovery and keeping things clean. Duplicates certainly happen and are annoying, and nobody likes drudging through 1,000 of the oldest open reports to close old stuff, etc. Some of this is also limited by GitHub and other things, unfortunately.
Personally as a developer (not a user!), I think bots that close old tickets are often very annoying (to everyone) and rarely do much other than feed a human desire to hit "inbox zero", but this desire is not (to my knowledge) based on any actual scientific criteria that leads to better software development or happier, better cared for users. It is more a way of externalizing a deep human desire for "cleanliness" and using it as a yardstick for "quality" rather than evaluating the numbers for yourself. You can also find tons of 0-issue repositories on GitHub, but this doesn't mean they're actually good, or they do what you want -- and I doubt most of them have as much momentum as we do.
I don't think closing such bugs is "feed a human desire to hit "inbox zero"" even with that you'll never get there. From my perspective it is all about not losing track of important issues. Having bots close tickets makes sure that only tickets are opened are ones that someone cares about. There are tickets that are from 2013, a lot changed since then, they might no longer be relevant anymore.
Yes there is many advantages to nixpkgs being a single repo. In fact, it is one of the main strength of Nix.
It gives you all the advantages of corporate style source monorepo without the inconvenience.
Out of order:
- It avoids the multi-version diamond dependency problem and the necessity of a SAT solver.
- It allows transactional upgrade of multiple packages.
- The detection of any break / problem of an update for any software depending on it automatically.
- A consistent view on the entire dependency tree at each instant. With possibility of rollbacks.
> and the article wasn't particularly illuminating other than boiling down to "..."
Yeah, I usually don't like writing these kinds of things. When reading about a distribution, especially a new and interesting one, one (or at least I) tend to forget what could go wrong. This text (I intentionally avoid using the word "article") is a reminder to stop, think and consider if one is up for the challenge. As in my case university just started last week, my conclusion was I didn't have the time.
> It's interesting that Guix uses scheme instead of a home-baked configuration language like NixOS.
I consider that to be one of Guix selling points. An established language, with many independent libraries make it a joy to work with (assuming a set up environment). From what I head, that's not really the case with Nix, although I understand the lure of a type system.
I'm coming from Gentoo myself, and I've tried to get Guix working on Gentoo a couple of times over the years, and have always been frustrated by how much work and hacking was involved in doing so. I'm no Linux novice, either. I've been a professional Linux/UNIX admin for decades, I know and love Scheme, and am no stranger to putting in a lot of work to get something to run on Linux, but I failed in two major attempts with Guix, despite having lots of thorough assistance from Guix developers on #guix on IRC.
So back to Gentoo's package manager I went.
A typical user would not have put in nearly that much work to trying it out, nor would they have had the skills or knowledge to get nearly as far as I did. Though, to be honest, I did have some requirements (like doing my own compilation of everything on my own old, slow laptop, just as I'd been doing with Gentoo, and not trusting their binary distribution) that a typical user would not.
The other lesson I got from my last attempt was that trying to compile everything in Guix from scratch on an old laptop is just way too slow. Doing this on Gentoo is slow and painful enough, but it's way worse on Guix, and simply unworkable. You really have to have a fast, modern system (or offload your compilation to another machine which will crank away for weeks on end and that you can then download the binaries from) to constantly compile everything you need for Guix.
That said, Guix has really come a long way over the years, and it's impressive to see how far they've come, and I'd absolutely love to see them succeed, but they've got a long, long, long way to go.
Would you elaborate on why you think compilation on Guix is slower than Gentoo? Thanks.
Compiling guile from scratch was, by the way, insanely slow, and because I struggled to get Guix working right on my first try, I had to compile it over and over again, which took about a day each time. A "guix pull" took four hours on my system, and I had to do it twice each time, once for root and once for my own user. My first "guix pull" took two weeks due to all the errors, toubleshooting and restarts the process took as I tried to get Guix working as it should.
In addition, it seems that Guix packages don't have optimizations enabled, which is a deal breaker for me, as optimizing the packages I install is a significant reason I compile them from scratch in the first place, as I'm running on an old, slow machine which could use all the performance boosts it can get.
Finally, I might have a broken environment on my system which makes compilation even slower still than it otherwise would be, but until I get it fixed I have to live with it, and so for all of these reasons compiling everything from scratch on Guix is just not practical for me right now.
Maybe with a newer, much faster machine I'd be ok with it.
I have a recent i7 and still compile essentially all packages on my homelab, I feel that the benefit would be even more marked for you.
Hard for a user, but simple for distribution or legal.
I think the difference between NixOS and Guix, excluding the language of choice of course, is that NixOS has the community to make it work. For example, I had a issue last night that I opened a issue in GitHub, and in a few hours the maintainer of the problematic package answered me and the problem was fixed.
Um, that's not even remotely close to what the actual stable inclusion rules look like.
I mixed the two up, will fix.
This is sad because it is such a nice and important project. But I cannot easily separate the work from the people who did it.
What do you mean?
https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr...
One tip: The contrast on your code blocks is terrible with white text against a light white background. Consider changing the `background` of line 3 of style.css to `purple`, `darkorange`, or some other dark color.
EDIT: Ahh it's probably that the site uses `prefers-color-scheme` media queries, but missed a couple cases.
I'll try to fix it as soon as possible.
I don’t know guix, but that looks like a typo to me. Shouldn’t that be back, not pack?