
Attempting to Use GNU Guix - stargrave
https://zge.us.to/guix.html
======
ninjin
Sad to see GNU Guix struggling, they are young though and I have hopes for the
future. About a year ago I made a choice between trying out GNU Guix and
NixOS, since this week I now run NixOS on all my servers and desktops after
gradually phasing out my old Ubuntu stack.

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.

~~~
zaphirplane
Something I couldn’t get about nix by skimming the documentation is how it
manages application configuration. Using traditional systems when you upgrade
the package responsible for the network configuration my current configuration
is carried thru or merged into the new format if the package changes it’s
configuration syntax. How does nixos manage /etc ?

~~~
evil-olive
For the majority of changes, it "just works". For example, here's the part of
nixpkgs that configures wireless networking via wpa_supplicant, as well as the
actual package build of wpa_supplicant:

[https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modu...](https://github.com/NixOS/nixpkgs/blob/nixos-19.09/nixos/modules/services/networking/wpa_supplicant.nix)

[https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-
sp...](https://github.com/NixOS/nixpkgs/blob/nixos-19.09/pkgs/os-
specific/linux/wpa_supplicant/default.nix)

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](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).

~~~
takeda
Files in /etc shouldn't be modified directly. You edit configuration.nix and
it generates these files.

How it is done, depends on a module.

------
foopdoopfoop
I don't know that much about Guix, other than "super-free Nix with scheme"
(and the article wasn't particularly illuminating other than boiling down to
"Guix isn't really ready for most users right now"), but it's neat that
there's momentum in the declarative OS-space. I hope that both Guix and NixOS
keep growing and that more people start switching.

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 :)

[1] [https://github.com/nix-community/NUR](https://github.com/nix-
community/NUR)

[2] [https://github.com/rycee/home-manager](https://github.com/rycee/home-
manager)

~~~
T-R
I'm hoping that maybe Flakes[1] will help ease the issue/pull request
situation by letting some of the namespaces move out of the main repository.

[1]
[https://github.com/NixOS/rfcs/pull/49](https://github.com/NixOS/rfcs/pull/49)

~~~
aseipp
There are significant advantages to having the entire Nixpkgs package set in a
mono repository. While I think Flakes are quite interesting for a number of
reasons, I hope it doesn't result in the primary package set getting split up
too much. They conceptually act a lot like Git submodules, and going overboard
with that is a very easy way to make your life miserable, and significantly
increase development turnaround for changes that "cross" package sets. A group
of packages just being "conceptually related" isn't a high enough bar to move
things out.

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.

~~~
takeda
I think at very least (and easy to implement) nix needs a bot that closes old
tickets. The number of open issues is ridiculous and basically it makes easier
for an issue to be overlooked and further increase the count. The number of
open issues also causes some people think nix is very buggy and not suitable
in production or even exploring.

~~~
aseipp
There are probably some people who see a 3k bug report number and think that,
but realistically tons of projects have thousands of open tickets for any
number of things from legitimate bugs to duplicates to actual user questions.
Linux, projects like LLVM, etc. It's natural when you have a project that is
in active every-day use by literally thousands and thousands of people.
Nixpkgs is simply a big project! But the actual numbers might tell another
story.

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.

~~~
takeda
There are, that was response from one of my colleague after mentioning Nix to
him. Having 3k open bugs, don't help with anything there's no way all of them
will ever be addressed and important ones could get lost between them.

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.

~~~
MayeulC
I personally hate it when a bot closes an issue I wrote. What's the point of
closing unresolved issues? Just assign them a label (it could be a "stale"
label like some projects do). Otherwise it just feels like hiding your mess
under the bed. Other sorting tools can provide the same list as automatically
closing bugs would achieve. The opposite isn't true, unless assigning a
specific label when manually closing an issue.

------
pmoriarty
Guix in general just needs a lot more contributors and lot more work to come
anywhere close to being a competitor to the mainstream (or even near-
mainstream) distros and package managers.

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.

~~~
martinflack
> 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

Would you elaborate on why you think compilation on Guix is slower than
Gentoo? Thanks.

~~~
pmoriarty
It's not that compilation itself was slow with Guix, but (to my memory) it was
because all Guix packages are completely separate by design and have
dependencies which are not shared, so you might have to compile, say, five
different versions of guile to satisfy those five different dependencies in
five different packages.

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.

~~~
70rd
Just out of curiosity, why not use distcc?

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.

------
MrBingley
I understand and perhaps admire the GNU project's insistence on being blob-
free, but that also means Guix won't run out of the box on 99% of all people's
computers. The options are buy (old) hardware that doesn't need blobs (which
sometimes isn't even possible), or compile the default kernel to include the
binary firmware yourself (which the Guix documentation won't explain for
ideological reasons). Both of these will sadly limit the appeal of this
distribution to enthusiasts-only, which is unfortunate since Guix probably has
the most advanced package manager of any Linux system.

~~~
dorfsmay
True for workstations, but most services are running on VMs these days. OS
shouldn't need blobs to run on VMs.

~~~
big_chungus
Right, but now you have two separate operating systems to manage which are
different at the kernel level (as your host is probably linux, bsd, esxi,
etc.) This means you often have to manage twice the amount of tooling,
documentation, scripts, etc. and makes it impractical for many cases.

------
m45t3r
I would recommend the author to try NixOS instead. It is not like that you
wouldn't have issues however mostly things works (never had the kind of issue
the author reported in this post, for example).

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.

------
jwilk
> For a new package to be accepted into the [Debian] stable branch, it has to
> pass a number of days without any bug reports.

Um, that's not even remotely close to what the actual stable inclusion rules
look like.

~~~
justinsaccount
It is close to the rules for a package to get included into 'testing' from
unstable, they must have gotten the branches mixed up.

~~~
daptaq
(I wrote the text)

I mixed the two up, will fix.

------
enriquto
i feel very alienated by the guix developers due to the way they are betraying
the gnu leadership.

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.

~~~
jwilk
> they are betraying the gnu leadership

What do you mean?

~~~
cwyers
My guess is that they're referring to the open letter from people working on
many GNU projects calling for Stallman to resign.

~~~
jwilk
I think this is the letter in question:

[https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-
pr...](https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/)

~~~
takeda
I still don't know what Stallman did.

~~~
bugbug99
Got caught up in an organized witch-hunt to remove him from power. Too much
freedom of speech for the current FSF.

~~~
takeda
I'm hoping you're joking, because petition for him to step down, because he
took part in with hunt to have himself removed sounds ridiculous. I'm still
interested in a real answer.

------
p0cc
Thank you for shedding light on a distro I didn't know existed!

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.

~~~
chaorace
Seems like normal Solarized to me?

~~~
XaspR8d
Must be rendering differences among us -- I don't think solarized uses white
on yellow...

EDIT: Ahh it's probably that the site uses `prefers-color-scheme` media
queries, but missed a couple cases.

------
Someone
_”Just run guix package --roll-pack to “undo” an installation.”_

I don’t know guix, but that looks like a typo to me. Shouldn’t that be _back_
, not _pack_?

~~~
opan
'guix package --rollback' is what's in my shell history, so it should probably
say that.

------
Iv
I love the style of packets organization that they describe. I think it has a
name, I have seen it promoted as an alaternative to the typical mess that is
"install everything in various parts of /usr/ and /opt/, put things in /etc/
or ~, silently overwrite old versions"

------
mmahut
Go Nix.

