
Guix Further Reduces Bootstrap Seed to 25% - rekado
https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
======
qqii
I'm really glad that guix has been working on this area. Apart from using
scheme this is one of the core areas that really distinguish them from nix.

Just compare the difficulty of trying to use the third party nix-bundle to
produce a binary for another system versus guix pack.

------
rudolph9
Does anyone know of a recent comparison of NixOS vs Guix? Both these projects
are awesome and I’m a NixOS user but I want to learn more about Guix. I’ve
found older ones but nothing in the past year and with all the recent
developments in both communities I’d love to see a side by side comparison.

~~~
rekado
I generally don't like to talk about other projects negatively, because I
don't think that Nix and Guix should compete. They are different takes on the
same concept. But as I'm very familiar with Guix and have occasionally looked
at how they deal with some of the packaging problems I worked on in Guix I can
say that the Nix colleagues are often punting on problems instead of solving
them. Let me give you a few examples.

In Nixpkgs there are quite a few generated packages, some of which cannot be
built. I'm maintaining R packages (from CRAN and Bioconductor) in Guix and I
see that the equivalent packages in Nixpkgs do not accommodate some of their
quirks, so they cannot actually be built.

Another example where Nixpkgs does not build packages from source is TeX Live.
The SVN repository of TeX Live contains countless generated files, and all of
the TeX Live packages in Nixpkgs merely copy the generated files from SVN
instead of building them from source.

Java packages in Nixpkgs often seem to include pre-built jars whereas in Guix
we're going to great lengths to build _everything_ from source. This comes at
a cost, of course: Guix has fever Java packages because of that, but those
that it has are actually built from source.

Of course, I'm biased towards Guix, but I must say that I'm very fond of the
level of integration that Guix achieves. When I look at Nix I see a bunch of
seemingly separately developed tools that are written in a mix of languages
(with Shell code being rather common). In Guix all tools are written in
Scheme, use the same API, behave similarly, etc. It just feels much more
polished to me.

That said, there is no animosity between these communities, and I think we
would all be better off avoiding the mental pitfall of competition; we work on
the same problems with different values and thus our approach differs. This
leads to diversity rather than duplication of work.

Here are some more things I wrote comparing Nix and Guix in the past:
[https://news.ycombinator.com/item?id=19807042](https://news.ycombinator.com/item?id=19807042)

~~~
AnIdiotOnTheNet
> This comes at a cost, of course: Guix has fever Java packages because of
> that, but those that it has are actually built from source.

Truly this is much more valuable than actually being able to use the software.

~~~
e12e
If you just wanted to download and run a binary (or jar) - you can still do
that?

While freedom zero (the most important!) is the ability "to use the software"
\- being able to improve, patch and adapt the software is also very important!

~~~
AnIdiotOnTheNet
> If you just wanted to download and run a binary (or jar) - you can still do
> that?

If it were that simple, why would we need package managers at all? Sadly, the
Linux community as a whole have dedicated themselves to a structure that makes
this seemingly simple task remarkably difficult.

~~~
craftyguy
> If it were that simple,

It is that simple.

> why would we need package managers at all? Sadly, the Linux community as a
> whole have dedicated themselves to a structure that makes this seemingly
> simple task remarkably difficult.

Because there's a huge difference between a user downloading/running a binary,
and software package management in an OS. The former is not maintainable, your
binaries will be out of date soon, etc. But, if you insist on wanting to do
this, there's absolutely nothing preventing you from doing it. Have fun.

~~~
AnIdiotOnTheNet
> if you insist on wanting to do this, there's absolutely nothing preventing
> you from doing it. Have fun.

I really do want to do this, precisely because the software in the repo is
often out of date, if it is even there at all! I really don't like the idea of
a mandatory middleman between the developer and the user.

And since I really do want to do this, and do it often, I can say with quite a
bit of certainty that

> It is that simple.

Is complete and utter _bullshit_! Sometimes you get lucky and the developer
produces AppImages or a static binary, sometimes you're less lucky and have to
grab the binary and its dependencies and write a startup script that sets
LD_LIBRARY_PATH, sometimes you're even less lucky than that and get to use
patchelf to force it to use a compatible ld.so, but most of the time you end
up having to compile the damn thing from source like it is 1975.

~~~
Quiark
Oh wow that sounds exactly like the kind of problems package mamagers solve.
Your complaint basically boils down to - nobody prepared a one click package
of latest version for free for me.

~~~
AnIdiotOnTheNet
My complaint comes down to the following: why must there be a middle man
between the developer and user, why must there be a separate middleman for
every repo, why must said repo prevent me from installing older versions, why
must the package manager prevent me from installing to alternative paths...
basically, why does the community insist that this simple task that was the
de-facto way to install software for DOS, MacOS (classic), NeXT, RiscOS, and
MacOS (recent) insist on being complicated and restrictive in Linux?

And if package managers really solved the problem, why do so many projects
deploy with Docker? Why do FlatPak and Snap exist, let alone my preferred
AppImage?

~~~
jnxx
> why must there be a middle man between the developer and user, why must
> there be a separate middleman for every repo,

Guix allows you to easily write own package definitions which are treated as
part of the whole system. If you submit them and they are accepted, they
simply become part of Guix.

> why must said repo prevent me from installing older versions,

Precisely this is a case that Guix solves extremely well: One can start
environments with specific versions of packages, like in Pyhon's virtualenv.

And by the way, the complexity is caused by the issue that many many
components need to fit together. That does not happen by chance, it is a
massive amount of work to make it fit in a manageable way, and check that it
works. That's what distributions do.

~~~
AnIdiotOnTheNet
And yet many operating systems throughout history have not needed to do that.
The complexity is not inherent to the problem space, it is a creation of the
community.

------
nvahalik
Who funds Guix development? This this one of those experimental/hobby/academic
projects? I never hear anything about Guix outside of HN or F/OSS boards (and
even then, very little). How does it continue?

~~~
artistsvoid
It's part of GNU [0] (which in itself is a community), but GNU as a whole is
additionally funded in part by the FSF [1] ; And then as always: volunteers. I
suspect since Guix heavily utilizes Lisp quite a few Emacs lovers might watch
Guix closely and even contribute ; students might pick GNU projects as part of
a thesis et cetera.

And I am unsure how 'active' development is, I have no insight, but it has
been in existence for so long and still no one I know has ever used it. On the
other hand NixOS[2] (or Nix as a package manager in similar vein) seems to be
used heavily by some Power Users.

[0]
[http://www.gnu.org/software/software.html](http://www.gnu.org/software/software.html)

[1] [https://www.fsf.org/campaigns/](https://www.fsf.org/campaigns/)

[2] [https://nixos.org/](https://nixos.org/)

~~~
qqii
In GNU fashion they're using savannah mailing lists and email patches so to
those who are comfortable with git{hub,lab} it's slightly less familiar.

Here is their git repository:
[https://savannah.gnu.org/projects/guix](https://savannah.gnu.org/projects/guix)

Here is the web interface to their issues and patches mailing list:
[https://issues.guix.gnu.org/](https://issues.guix.gnu.org/)

As you can see although the project is less popular, it is no less actively
developed and you can easily find system configurations by searching
git{hub,lab}.

~~~
artistsvoid
I fear it being 'GNU' they will shoot themselves in the foot somehow. Bad
marketing, unnecessarily geeky and childish nomenclature, GPLv3 and make it
all free software, no proprietary drivers, hard to get proprietary third party
software to install et cetera...

'GNU Guix is a transactional package manager and an advanced distribution of
the GNU system that respects user freedom.'[0]

NixOS is developed using the MIT license and does seem to just want things to
work.

I am bringing this up purely as a question, is that fear justified or am I
missing something? Would be glad for a take on this from someone who knows
more.

[0]
[https://savannah.gnu.org/projects/guix](https://savannah.gnu.org/projects/guix)

~~~
qqii
I guess it depends on what you mean by shoot themselves in the foot. There are
major differences in philosophy and bar the "superficial" differences these
are quite different projects.

For one nix simply doesn't have a project focused on bootstrapping. As another
example compare rust bootstrapping[0] versus using a rust binary[1]. Nix also
has no alternative to guix challenge[2] or guix pack[3]. Even a comparison of
their documentation shows this difference.

The question is if you consider these measures useful, and if you think
bootstrapping is even an issue in the first place. To me this is the bigger
question when comparing the two projects, as depending on your philosophy guix
is either taking necessary precautions or unnecessary mitigations.

Given posts like this their marketing is okay, I haven't seen much unnecessary
childishness - but both projects are fundimentally complicated thus have to
invent words for concepts and there's nonguix[4] and most people run nix on
GuixSD for their non free software needs.

I doubt guix will be more popular than nix anytime soon, but I don't think
NixOS will be more popular than Arch anytime soon either.

[0]: [https://guix.gnu.org/blog/2018/bootstrapping-
rust/](https://guix.gnu.org/blog/2018/bootstrapping-rust/)

[1]:
[https://github.com/NixOS/nixpkgs/pull/85542](https://github.com/NixOS/nixpkgs/pull/85542)

[2]: [https://guix.gnu.org/manual/en/html_node/Invoking-guix-
chall...](https://guix.gnu.org/manual/en/html_node/Invoking-guix-
challenge.html)

[3]: [https://guix.gnu.org/manual/en/html_node/Invoking-guix-
pack....](https://guix.gnu.org/manual/en/html_node/Invoking-guix-
pack.html#Invoking-guix-pack)

[4]: [https://gitlab.com/nonguix/nonguix](https://gitlab.com/nonguix/nonguix)

~~~
matthewbauer
Nix has `nix build --check` which should do the same thing as `guix
challenge`. I think there may be more fine tuned options in challenge though.

~~~
rekado
It's not the same. Guix also has "guix build --check" which builds a package a
second time to compare potentially different results.

"guix challenge" challenges different substitute servers and also compares
what they offer with what you may have installed (whether you built it locally
or downloaded it from elsewhere). It's really quite different from "guix build
--check".

------
xedrac
I love the idea of Guix. I also love Scheme and Free software. It seems Guix
and I would be a match made in heaven. But then I read things like this:
[https://guix.gnu.org/blog/2020/deprecating-support-for-
the-l...](https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-
kernel/) (turns out this was an April fools joke)...

I'm not sure I love Hurd so much. Admittedly, I have not used it, but would be
hesitant to rely on it for any important work. Maybe it will prove me wrong.
It just seems like it has been an awful lot of work to get Linux to where it
is, and it was a pretty bumpy ride at times.

Edit: I guess I'm pretty dense. I hate April fools jokes! But now I'm happy I
can start using Guix without fear of being forced into Hurd. That said, I will
try out Hurd just for the fun of it.

------
LockAndLol
I see that guix is a declarative package manager like nix. Where does it have
a leg up over nix?

And how's the GUI integration with KDE and gnome? Is there a backend for KDE
Discover or the Gnome Software Center?

Finally, I see that installation goes over a "curl | bash", which imo is a
pretty insecure method of installation. I can understand why such an insecure
method exists (so many different ways of installing software on linux), but
that's like saying HTTP is a good idea because it's easier than HTTPS.

~~~
qqii
This post is a pretty good example, for I don't know of any nix projects that
are attempting to work on the bootstrapping problem. Guix pack[0] solves a
parallel issue of distributing your nicely dependancy managed ecosystem
whereas nix's alternative with nix-bundle barely works.

At the moment neither have gui integration and unfortunately both could use a
lot of work with onboarding and beginner (I'm taking non programmers)
friendliness.

[0]: [https://guix.gnu.org/manual/en/html_node/Invoking-guix-
pack....](https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html)

~~~
ssivark
> _At the moment neither have gui integration and unfortunately both could use
> a lot of work with onboarding and beginner (I 'm taking non programmers)
> friendliness._

I think non-programmer friendliness can wait till there are enough technical
users that the superficial daily-experience bugs get ironed out, and also the
newbies have a social support system for onboarding. Trying to jump that curve
will prove painful in the long term.

I would love to see the guidance and tools for _technical_ users to try this
out and start switching over the next few years.

AFAIK, Gnome/KDE or some other DE can be built/installed like any other
package, so one can certainly have pretty much any GUI, just like any other
Linux distribution.

------
dilandau
Is anybody using this? What do you like about it versus a more typical linux
or unix? Is hardware support good enough to run on a relatively recent laptop?

~~~
rekado
I'm using Guix System on new Dell servers, old Sun servers, a Dell laptop, a
Purism Librem laptop, an old Thinkpad --- it works just fine.

I think the fear of missing drivers when using Linux without blobs is
extremely overstated. Yes, certain WiFi cards won't work without blobs, and
yes, the 3D graphics situation is not great thanks to NVIDIA and AMD.

> What do you like about it versus a more typical linux or unix?

Oh, so many things... But most important for me is stateless configuration,
reproducible builds, no-nonsense application bundles without all that
Dockeresk cruft via "guix pack", ad-hoc environments, etc.

~~~
jabirali
> 3D graphics situation is not great thanks to NVIDIA and AMD.

AMD is now one of the good guys when it comes to open source:

[https://en.wikipedia.org/wiki/AMDGPU](https://en.wikipedia.org/wiki/AMDGPU)

Basically, since 2015, AMD has offered an official driver under an MIT license
for Linux and *BSD. Personally, I'm definitely choosing AMD for my next laptop
:).

~~~
davexunit
Unless things have changed recently, AMD GPUs still require proprietary
firmware and thus do not work on a fully free system. I bought an AMD GPU a
few years ago to try it out and it didn't work.

~~~
tadfisher
As do Intel[1] and Nvidia[2].

[1]:
[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/LICENSE.i915)

[2]:
[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/LICENCE.nvidia)

------
blahbhthrow3748
This is extremely neat but the name "gash" is... a poor choice. Gory in
standard English, worse as a slang term

~~~
enriquto
Why do you pronounce it like that, though? I pronounce it like "geesh" or
"guish" or "guiche" (not sure how to write it phonetically). It is just the
Catalan word for "chalk".

~~~
burkaman
Not Guix, Gash:
[https://savannah.nongnu.org/projects/gash](https://savannah.nongnu.org/projects/gash)

~~~
benbristow
Gash is a slang term for the female sexual organ.

Not a good name for a project.

~~~
gmanley
If we were to reserve every word that is also used as slang for sexual organs
we'd be out a lot of words. Peach, purse, shaft, sheath, tool, pocket, etc,
these are all slang as well, yet we still use these for their original
meaning. It's all about context. I'd also say 'gash' is quite regional. I've
only ever heard it used in the U.K.

~~~
lukego
Australia too. Quite vulgar but not especially common nor especially rare.

