
GNU Guix 1.0 - brendyn
https://www.gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released/
======
vbrandl
I'd love to use Guix (or Nix for that matter) as my day-to-day system but (and
correct me, if I'm wrong) the package maintainer story is a bit off putting
for me. From what I've understood, packages are maintained in a public git
repository (GitHub [0] for Nix and savannah.gnu.org [1] for Guix), which might
be great if there are enough people submitting updates, but at least for
critical system components there should be clearly defined maintainers to make
sure all security patches are applied in time.

Also I'm not sure how I feel about a core part of my potential operating
system being hosted by a now Microsoft-owned company. On the other hand GitHub
might be more reliable and better fit to server a huge amount of users than
savannah...

[0]: [https://github.com/NixOS/nixpkgs](https://github.com/NixOS/nixpkgs)

[1]:
[https://git.savannah.gnu.org/cgit/guix.git/](https://git.savannah.gnu.org/cgit/guix.git/)

~~~
rekado
No "core part" of Guix is hosted on Github. If you're referring to the daemon:
it's being replaced with a Guile implementation (it's an ongoing student
project). It's not fetched from Github; our old copy of the daemon is part of
the Guix git repository.

~~~
vbrandl
Sorry for being unclear. The part about being hosted on GitHub actually
referred to Nix. That's the point where I'm unclear about what seems to be the
better solution. GitHub could take a turn for the worse but at least for now,
GitHub might be able to handle more users than savannah.

~~~
rekado
I don't think it matters much. You can use any git mirror in your
~/.config/guix/channels.scm file (including a local clone); you only need
access to the git repo when running "guix pull" to upgrade your copy of Guix.
I don't think that Savannah will become a bottleneck even with three times the
users we have now. If it ever becomes a problem it's trivial to move to
something else or to host dedicated infrastructure.

~~~
vbrandl
Yeah I just realized that. The binary caches might experience higher load but
it the worst case you would have to build the binary yourself.

I just had to reinstall guix since `guix pull && guix package -u` didn't seem
to upgrade guix itself but I think I will play around with it, at least for
non critical stuff in my OS.

~~~
rekado
"guix pull" upgrades Guix itself. It installs the latest version as
~/.config/guix/current/bin/guix. If you ran the "guix" command from a
different location before Bash's caching of command names can trick you. Guix
prints a recommendation to run "hash guix" to refresh this command cache.

------
joemccall86
Looks like a neat concept. Would anyone here with experience managing this in
production care to comment? Seems like it could be interesting if you need to
reproduce the exact same software/OS on several machines as deliverables.

~~~
rekado
I've been using Guix in production since 2014 at a research institute to
support reproducible bioinformatics workflows. It has come a long way since
then.

Guix takes reproducibility and "bootstrappability" very seriously. Its design
as an extension to Guile Scheme enabled the development of software built
around Guix, such as a workflow language, alternative user interfaces (e.g. an
Emacs interface or a web interface), etc.

The `guix system` family of commands is awesome because it can build
reproducible containers, disk images, virtual machines, or bare-metal systems
all from the same specifications.

What's still missing, in my opinion, is a tool to manage systems that have
been generated with Guix, e.g. to check on their state, build new
configurations and swap them out for old ones, etc. Some work has been done
towards this goal, but there's still some way to go there.

Other than that I'm very happy with it and use Guix systems and Guix as a
package manager on all my machines.

~~~
sterlind
How does writing Guix Lisp expressions compare to writing Nix? Is it pretty
succinct and intuitive? Do patterns make a little bit better sense?

It took me a long time to get the hang of the Nix design patterns like the
three different kinds of overrides and the module system. Curious if it plays
better in Lisp.

~~~
rekado
"succinct" is hard to answer. It depends a lot on the upstream package. For
most packages the package expression looks like data:

    
    
        (define-public r-valr
          (package
            (name "r-valr")
            (version "0.5.0")
            (source
             (origin
               (method url-fetch)
               (uri (cran-uri "valr" version))
               (sha256
                (base32
                 "14jhrwkiwmha3vlmm7b50n2xxyizj6ddmy89gb20mpzq7qhz1ika"))))
            (build-system r-build-system)
            (propagated-inputs
             `(("r-broom" ,r-broom)
               ("r-dplyr" ,r-dplyr)
               ("r-ggplot2" ,r-ggplot2)
               ("r-rcpp" ,r-rcpp)
               ("r-readr" ,r-readr)
               ("r-rlang" ,r-rlang)
               ("r-stringr" ,r-stringr)
               ("r-tibble" ,r-tibble)))
            (home-page "https://github.com/rnabioco/valr")
            (synopsis "Genome interval arithmetic in R")
            (description
             "This package enables you to read and manipulate genome intervals and
        signals.  It provides functionality similar to command-line tool suites within
        R, enabling interactive analysis and visualization of genome-scale data.")
            (license license:expat)))
    

This defines the name "r-valr" to be a "package" value with the given fields.
The "source" field describes how Guix should obtain the source tarball ("url-
fetch" is a procedure that implements a URL downloader, but there are others
like "git-fetch", "hg-fetch", etc) and what the hash of that data is supposed
to be. The "build-system" field tells Guix how to build the thing. "r-build-
system" is a very succinct way to say "do with this package as you do for all
other R packages: unpack the tarball, run `R CMD bla`, then run the tests,
etc". We've got quite a few such build systems: "gnu-build-system", "cmake-
build-system", "python-build-system", "ant-build-system", ... All of these can
be further configured via the "arguments" package field, which isn't used
here, because this is a boring package.

The "propagated-inputs" field is an association list of arbitrary labels to
actual package values --- the things on the right hand side are variable names
that are bound to package values, which are unquoted here, so this field
really contains actual references to these other package values. The result is
a lazily constructed graph of package values.

Some packages can be really nasty, though, when the developers decided to
ignore conventions and implement their very own way to build their very
special software. We can usually accommodate those packages by starting out
with e.g. the gnu-build-system and then modifying the build phases: deleting
the "configure" phase, adding a custom phase before the "build", replacing the
"install" phase, etc. The system is flexible enough for all of this, but for
really ... special software I would no longer call this "succinct" or
"intuitive".

That said, most packages are easy. Almost all R packages, for example, look
like the one above. But there are some really frustrating ones like Tensorflow
(due to the fact that we use CMake instead of Bazel because Bazel hasn't been
bootstrapped yet) or the old JDKs (that we use as part of a longer bootstrap
chain) that are plain ugly. You just need to know when to give up, I suppose
:)

~~~
sterlind
> _You just need to know when to give up, I suppose :)_

Oh gosh I relate to this. I tried to package 3DSlicer for NixOS, which uses a
cmake superbuild of dozens of dependent projects, which it fetched during
compile and required a very special GCC. I had to give up; it was making me
too depressed.

Thank you for sharing how Guix derivations work. It seems very similar
semantically to Nix, but I like the _build-system_ method. In nix we have e.g.
buildDotnetPackage, buildBazelPackage functions which are overridden, but
there's not a clean interface for build systems. I like it.

Is the module system similar to Nix's? Nix modules define imports, config
schema and config values, which are merged together to produce an expression
for the state of the whole system, e.g. configuration.nix. How's that work in
GuixSD?

~~~
rekado
> Is the module system similar to Nix's? Nix modules define imports, config
> schema and config values, which are merged together to produce an expression
> for the state of the whole system, e.g. configuration.nix. How's that work
> in GuixSD?

The way the Guix system is configured differs a lot from how it's done in
NixOS. (Note, though, that I've never used NixOS, so I'll just talk about how
it works in Guix.)

First about the term "modules" to avoid confusion: Guix code is organized in
Guile modules. A Guile module is a file containing definitions. A module can
export variable names. Other modules can use those variable names. That's just
like how you'd do "import foo" in Python --- in Guile you do "(use-modules
(where foo is))".

This is nothing to do with system configuration, of course; it's just a
language feature.

The way a system is configured is through the `operating-system` record. Much
like the `package` record for defining first class package values the
`operating-system` record is used to declare operating systems. Here's an
example straight from the manual:

    
    
        (use-modules (gnu))
        (use-service-modules networking ssh)
        (use-package-modules screen)
    
        (operating-system
          (host-name "komputilo")
          (timezone "Europe/Berlin")
          (locale "en_US.utf8")
    
          ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
          ;; target hard disk, and "my-root" is the label of the target
          ;; root file system.
          (bootloader (bootloader-configuration
                        (bootloader grub-bootloader)
                        (target "/dev/sdX")))
          (file-systems (cons (file-system
                                (device (file-system-label "my-root"))
                                (mount-point "/")
                                (type "ext4"))
                              %base-file-systems))
    
          ;; This is where user accounts are specified.  The "root"
          ;; account is implicit, and is initially created with the
          ;; empty password.
          (users (cons (user-account
                        (name "alice")
                        (comment "Bob's sister")
                        (group "users")
    
                        ;; Adding the account to the "wheel" group
                        ;; makes it a sudoer.  Adding it to "audio"
                        ;; and "video" allows the user to play sound
                        ;; and access the webcam.
                        (supplementary-groups '("wheel"
                                                "audio" "video")))
                       %base-user-accounts))
    
          ;; Globally-installed packages.
          (packages (cons screen %base-packages))
    
          ;; Add services to the baseline: a DHCP client and
          ;; an SSH server.
          (services (append (list (service dhcp-client-service-type)
                                  (service openssh-service-type
                                           (openssh-configuration
                                            (port-number 2222))))
                            %base-services)))
    

The "packages" field is for declaring globally available packages, nothing
special. What's interesting, though, is the "services" field. This is _not_
just about services in the sense of daemons (i.e. Shepherd services that can
be started and stopped), but about anything really to extend the system.

System services can be composed and may extend one another, see
<[https://www.gnu.org/software/guix/manual/en/html_node/Servic...](https://www.gnu.org/software/guix/manual/en/html_node/Service-
Composition.html>). This can be used for complex system setup like web
applications that require a web server configuration (e.g. by adding an nginx
server block), a database, and so on. An example is the Zabbix system service.
We also use the service framework for generating PAM policies, creating files
in /etc, for udev rules, etc.

This framework was described also in comparison with NixOS in a 2015 blog
post: [https://www.gnu.org/software/guix/blog/2015/service-
composit...](https://www.gnu.org/software/guix/blog/2015/service-composition-
in-guixsd/)

"guix system" operates on an "operating-system" value (read from a file or
read as a Scheme expression) to instantiate a VM, a container image, or a
bare-metal system.

------
dmos62
This seems like a large piece of software. I'm interested in the purely
functional, portable package manager aspect. I can see that it has [0] a lot
of packages that are a pain to build on my Slackware system (or even to
download prebuilt) because of the awesome number of dependencies. Downloading
mpv and its dependencies takes quite a bit of time, for example. If anyone has
experience with using guix this way, I'd be interested.

[0]
[https://www.gnu.org/software/guix/packages](https://www.gnu.org/software/guix/packages)

~~~
ferdek
At the beginning of this year I got hooked-up on this concept of functional
system and package management. I've read through all the Nix documentation
trying to get a feeling of how should I use it. And it just felt bad -
sometimes the documentation was outdated, sometimes it clearly contradicts
code on master, sometimes the programming style was inconsistent, sometimes
the examples were unclear, too simple or too contrived... Thousand ways to
achieve the same things and no clear "best practices" way.

Is guix's documentation any better? I mean - teach me the theory, but also
show me practical examples making use of it so I could remember?

~~~
equalunique
I prefer guix documentation because it feel more like a guide than a
reference.

~~~
ferdek
I think this is exactly what I wanted to hear, will give Guix a shot I guess.

------
opan
I've been using the Guix system since early 2018. It's a lot of fun. I've put
off some of the more complicated stuff (from a user's perspective) like
packaging new things, but it's managed to stay my daily driver just fine.

------
davexunit
I haven't been active for a couple of years, but I've contributed my fair
share of packages and features since 2013 that I'm proud to see have made it
all the way to 1.0. Congrats, Guix team!

------
akavel
As a person with ~intermediate knowledge of Nix/NixOS and only knowing Guix
from a distance yet:

\- I don't see a word about GuixSD there - what's the status of this? Is it
also 1.0 now?

\- (How) can I pin my whole config to a particular commit of the package
set/channel, and only update gradually? I'm kinda having trouble finding out
how to do this in NixOS

\- Can I package non-libre software for Guix? Are there third-party non-libre
package sets/channels? I know GNU proper doesn't want me to do this, and I'm
sympathetic, but not ready for the jump. What's the situation for me in
practice?

\- Can I replace kernel with L4Linux? I tried to do that in NixOS but gave up
because of complexity.

\- Does GNU mirror/archive all package sources used by Guix somewhere? If
github is sunset by MS, can I still build an OS from a 2018 snapshot?

\- What's the multi-user story? In Nix it's complicated.

\- Does Guix have something like Nix's home-manager?

TIA!

~~~
rekado
> \- I don't see a word about GuixSD there - what's the status of this? Is it
> also 1.0 now?

Yes. GuixSD is now called "Guix System".

> can I pin my whole config to a particular commit of the package set/channel

Yes, you can. You only need to describe the channels you want to use (and
possibly their commits) in ~/.config/guix/channels.scm and then run "guix
pull". You now have that particular version of Guix and it won't change until
you change the channel specification and run "guix pull" again. That's great
for reproducing a system elsewhere or at a different point in time.

> Can I replace kernel with L4Linux

I don't know if anyone has tried.

> Does GNU mirror/archive all package sources used by Guix somewhere

We cache sources for as long as possible on the build farm; we also fall back
to looking up sources through Nix caches; and finally we fall back to the
Software Heritage archive.

> Can I package non-libre software for Guix? Are there third-party non-libre
> package sets/channels?

Yes and yes. Adding channels is easy: just add a specification to
~/.config/guix/channels.scm

> Does Guix have something like Nix's home-manager

Sadly it doesn't. I'd love to see something like this in Guix.

~~~
akavel
Thanks! How about the multi-user story for non-OS Guix?

Also, can you share some links to third-party non-libre package sets/channels,
or some place where I can find them to see what's available?

 _Edit:_ As to kernel: are you using Hurd, or Linux? Or any one of them can be
chosen? If it's choosable, I imagine L4Linux should not be that hard. _Edit
2:_ I see there was some work being done on this:
[https://www.gnu.org/software/guix/blog/tags/gnuhurd/](https://www.gnu.org/software/guix/blog/tags/gnuhurd/)
but last news seems to be from Feb 2017. Did the work get integrated into
trunk, or did it bitrot in an old branch? _Edit 3:_ Found some info:
[http://lists.gnu.org/archive/html/guix-
devel/2019-04/msg0023...](http://lists.gnu.org/archive/html/guix-
devel/2019-04/msg00232.html) IIUC, not very stable (missing some Shepherd
stuff?), but at least the work seems upstreamed (?)

~~~
rekado
> multi-user story

I don't know what this means, so I'm just answering what I'm guessing this
means :)

Probably one of the biggest non-OS deployments of Guix is at the institute
where I work. We use Guix as a package manager on an HPC cluster. Hundreds of
users share the same Guix daemon but each of them can use their own version of
Guix with it. They simply invoke "guix pull" to upgrade whenever they feel
like it to get a new version of Guix and this affects nobody else.

Users are, of course, not limited to having just one profile. Just like Guix
can be used to manage different software environments _per user_ it can just
as well be used to manage separate software environments _per project_. At the
institute we do this all the time to create separate environments for
independent projects that each have their own upgrade schedule.

> Hurd?

We're using Linux libre by default. Guix runs as a package manager on a Hurd
system (such as Debian GNU/Hurd) and Guix has packages for building Hurd
servers as well, so a Guix System that uses the Hurd instead of Linux libre is
close to being ready. Most of this work was done by a very dedicated student
who did this as part of GSoC (twice) and who continued to fix problems
afterward.

Not all features of Guix will work on a Hurd system; Linux-style containers
obviously only work on Linux --- the Hurd has much prettier support for
container features, including unprivileged file system virtualization
(something I hate to miss on Linux).

The biggest problem with Guix + Hurd is that we aren't yet building packages
for the Hurd on our build farms, so no binaries are available. This means
there are only very few people who would be willing to use this and report
bugs or contribute fixes. I'm planning to attach some Debian GNU/Hurd VMs to
the build farm within the next few weeks so that this obstacle is removed.
Many of the Guix developers are Hurd enthusiasts (myself included), so I hope
now some of us can close the gaps that prevent us from having a native Guix +
Hurd GNU system.

> third party channels with non-free software

As one of the maintainers of Guix I'd rather not share links to channels
providing non-free software. I also sincerely hope that people will put their
time into improving free software than to develop workarounds to allow them to
keep software alive that does not respect their freedom and thus harms our
communities. That said, there are countless repositories on popular hosting
sites that provide package definitions of varying quality for non-free
software (also of varying quality :)) --- some of them are also used in HPC
deployments.

------
merricksb
Recent Guix discussions:

Guix: An advanced operating system (4 months ago, 313 points, 168 comments)
[https://news.ycombinator.com/item?id=18902823](https://news.ycombinator.com/item?id=18902823)

Software Heritage and GNU Guix join forces to enable long term reproducibility
(13 days ago, 168 points, 7 comments)
[https://news.ycombinator.com/item?id=19699031](https://news.ycombinator.com/item?id=19699031)

------
the_duke
Could someone provide a good comparison to Nix?

As in:

\- What differentiates the two?

\- What are respective drawbacks / advantages?

\- How usable are they? How painful is the manual creation of packages?

~~~
rekado
Here's something I wrote a few months ago (with minor changes) to clarify the
relationship between these two projects. I hope this helps.

\-------------------

As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what
I consider some important unique features of Guix:

\- Guix is all written in Guile Scheme (with the exception of parts of the
inherited daemon, which hasn't yet been completely implemented in Guile); this
extends to development tools like importers, updaters, to user tools like
"guix environment", and even bleeds into other projects that are used by Guix
System (the GNU system distribution built around Guix), such as the shepherd
init system. There is a lot of code reuse across the stack, which makes
hacking on Guix really fun and smooth.

\- Packages are first class citizens in Guix. In Nix the idea of functional
package management is very obvious in the way that packages are defined,
namely as functions. These functions take their concrete inputs from an
enormous mapping. In Guix you define first-class package values as Scheme
variables. These package values reference other package values, which leads to
a lazily constructed graph of packages. This emergent graph can be used as a
library to trivially build other tools like "guix graph" (for visualising the
graph in various ways) or "guix web" (for a web interface to installing and
searching packages), "guix refresh" (for updating package definitions), a
lovely feature-rich Emacs interface etc.

\- Embedded DSL. Since Guix is written in Scheme---a language for writing
languages---it was an obvious choice to embed the package DSL in the host
language Scheme instead of implementing a separate language that needs a
custom interpreter. This is great for hacking on Guix, because you can use all
the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a
debugger, etc. With its support for hygienic macros, Scheme is also a perfect
vehicle to implement features like monads (we use a monadic interface for
talking to the daemon) and to implement other convenient abstractions.

\- Graph rewriting. Having everything defined as regular Scheme values means
that you can almost trivially go through the package graph and rewrite things,
e.g. to replace one variant of a package with a different one. Your software
environment is just a Scheme value and can be inspected or precisely modified
with a simple Scheme API.

\- Code staging. Thanks to different ways of quoting code (plain S-expressions
and package-aware G-expressions), we use Scheme at all stages: on the "host
side" as well as on the "build side". Instead of gluing together shell
snippets to be run by the daemon we work with the AST of Scheme code at all
stages. If you're interested in code staging I recommend reading this paper:
[https://hal.inria.fr/hal-01580582/en](https://hal.inria.fr/hal-01580582/en)

\- Bootstrapping. Some of us are very active in the "bootstrappable builds"
community (see [http://bootstrappable.org](http://bootstrappable.org)) and are
working towards full bootstrap paths for self-hosting compilers and build
systems. One result is a working bootstrap path of the JDK from C (using
jikes, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping
problems serious and prefer to take the longer way to build things fully from
source instead of just adding more binary blobs. This means that we cannot
always package as many things as quickly as others (e.g. Java libraries are
hard to build recursively from source). I'm currently working on bootstrapping
GHC without GHC and without the generated C code, but via interpreting a
variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme.

\- Guix System, the GNU system distribution built around Guix. Guix System has
many features that are very different from NixOS. The declarative
configuration in Scheme includes system facilities, which also form a graph
that can be inspected and extended; this allows for the definition of complex
system facilities that abstract over co-dependent services and service
configurations. Guix System provides more Scheme APIs that apply to the whole
system, turning your operating system into a Scheme library.

\- I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many
perceived problems with the UI have been addressed, of course, but hey, I
still prefer the Guix way. I also really like the Emacs interface, which is
absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D
buffers over 1D command line strings.)

\- It's what I want GNU to be. I'm a GNU hacker and to me Guix is a
representative of a modern and innovative GNU. It's great to see more GNU
projects acting as one within the context of Guix to provide an experience
that is greater than the sum of its parts. Work on Guix affected other GNU
packages such as the Hurd, Guile, Mes, cool Guile libraries, and led to a
bunch of new GNU packages such as a workflow language for scientific
computing.

On the other hand, although Guix has a lot of regular contributors and is very
active, Nix currently has more contributors than Guix. Guix is a younger
project. The tendency to take bootstrapping problems very seriously means that
sometimes difficult packages require more work. Oddly, Guix seems to attract
more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with
Scheme after watching the SICP lecture videos); it seems to be the other way
around with Nix.

Having said all that: Nix and Guix are both implementations of functional
package management. Both projects solve similar problems and both are active
in the reproducible builds efforts. Solutions that were found by Nix devs
sometimes make their way into Guix and vice versa. The projects are not
competing with one another (there are orders of magnitudes more people out
there who use neither Guix nor Nix than there are users of functional package
managers, so there's no point in trying to get people who use Nix to switch to
Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who
invented functional package management and Nix) gave a talk on the future of
Nix surrounded by Guix hackers --- there is no rivalry between these two
projects.

\----

Now to the last question: How usable are they? I've been using Guix (as a
package manager and as an OS) since 2014 on all of my machines and I love it.
I have written hundreds of package definitions both manually and with the help
of "guix import", which generates them for me (even recursively). If you're
okay with Lisp it's not painful at all. I have experience with RPM spec files
and Arch PKGBUILDs and I love how declarative Guix package definitions are in
comparison. For well-behaved projects that's great. For projects that reinvent
build systems or come with custom build instructions or that assume
unreasonable things about the target system things can get pretty gnarly,
though.

Guix differs in that you don't use shell snippets to describe the installation
steps. This can be confusing for people coming from other packaging systems,
and it can be a little uncomfortable having to express things in Scheme
instead. On the plus side you have access to a much more flexible language and
don't have to mess with low-level shell. You can write procedures and reuse
them across packages, or you can abstract the whole build process so that all
that is ever needed is a declaration like `(build-system python-build-
system)'.

(Things that suck: packaging NPM/nodejs things. Guix folks are really into
building things from source, and there's a cultural mismatch with NPM folks.
There are workarounds but there's no silver bullet.)

------
chrisweekly
For those (like me) learning of Guix for the first time:

>"About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of
the GNU system that respects user freedom. Guix can be used on top of any
system running the kernel Linux, or it can be used as a standalone operating
system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management, per-
user profiles, and garbage collection. When used as a standalone GNU/Linux
distribution, Guix offers a declarative, stateless approach to operating
system configuration management. Guix is highly customizable and hackable
through Guile programming interfaces and extensions to the Scheme language."

Sounds pretty amazing!

------
Zenst
Link to x86 64bit .iso image:

[https://ftp.gnu.org/gnu/guix/guix-system-
install-1.0.0.x86_6...](https://ftp.gnu.org/gnu/guix/guix-system-
install-1.0.0.x86_64-linux.iso.xz)

x86 32bit [https://ftp.gnu.org/gnu/guix/guix-system-
install-1.0.0.i686-...](https://ftp.gnu.org/gnu/guix/guix-system-
install-1.0.0.i686-linux.iso.xz)

Gleaned from [https://www.gnu.org/software/guix/manual/en/html_node/USB-
St...](https://www.gnu.org/software/guix/manual/en/html_node/USB-Stick-and-
DVD-Installation.html#USB-Stick-and-DVD-Installation)

------
geokon
Is there a GUI/TUI for it? Like something akin to aptitude or at the very
least muon?

And does GUIX/Nix has something similar to Recommended/Suggested packages in
Ubuntu/Debian land? Or is each package an all-or-nothing kind of deal?

~~~
rekado
Guix has a very nice Emacs interface --- that's better than a bare TUI in my
opinion. Even if you aren't a die-hard Emacs user the Emacs interface has a
lot to offer.

There also is a web interface, but that's more useful for browsing the package
collection than to install things.

I don't know what you mean by "all-or-nothing kind of deal". You can easily
create package variants (thanks to first-class package record values that
support field inheritance), but in my experience you rarely need that as
packages are often composable at runtime --- you just install them into the
same profile.

~~~
michaelmrose
\- Package A recommends Package B, if the package maintainer judges that most
users would not want A without also having the functionality provided by B.

\- Package A suggests Package B if B contains files that are related to (and
usually enhance) the functionality of A.

\- Package A depends on Package B if B is a A can't work without B

Its possible for B to actually be optional but in fact be designated as
required if A is built with options that require B.

------
LargoLasskhyfv
But...has it USE Flags like Gentoo's Portage?

And variable CFLAGS and CXXFLAGS for explicitely choosing to optimize
whichever way i see fit, instead of using something generic? Individually, on
a per package base? Like described here for example:

[https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_...](https://wiki.gentoo.org/wiki/Complete_Handbook/Building_the_system)

[https://wiki.gentoo.org/wiki/Safe_CFLAGS](https://wiki.gentoo.org/wiki/Safe_CFLAGS)

~~~
Crestwave
As far as I know, it does not have USE flags, but you can customize the
compilation however you want, adding build options, patches, etc. They also
provide binaries for a good amount of packages if you don't want to build some
from source.

~~~
LargoLasskhyfv
I see. But that is not the point. I can customize any compilation anywhere.
But it is a hassle i can do without. I really miss the "automagic" of Gentoo
because this feature was intrinsic to their package management. I'm watching
Guix(XD/System/Whatever) since years, browsing the docs, reading this and
that, and it seems to me like just another rpm, deb with some nice addons. And
not too inviting at all, because who likes ghettos which ideologically shun
this and that which unfortunately is part of my life? Anyways, interesting
work whith reproducable bootstrapping in GNU Mes. (sigh)

~~~
Crestwave
It's not just like those at all... did you think that I was saying that you
can just compile things manually or something? You can define build options
and such for a group of packages using Guix; there just isn't an abstraction
like USE flags. You can find more info at [https://ambrevar.xyz/guix-
advance/index.html#orgc3c05c9](https://ambrevar.xyz/guix-
advance/index.html#orgc3c05c9).

And I don't consider its other features just "some nice addons". It's easy to
build things from source; in fact, it automatically does it by default if a
binary isn't available. It's contained in a directory, you can roll back to a
previous state, it's reproducible, everything can be configured through one
file, etc.

Guix is one of the package managers most different from apt and such; if
there's anything it's similar to, it's Nix, which IIRC it's based on/inspired
by.

Also, I'm curious as to what it is that you do that they shun? Is it working
on proprietary software or something?

~~~
LargoLasskhyfv
Thank you for that link, i'll park that in some tab for later reading after
skimming over. What i meant to say with shunning is exactly the thing with
proprietary software. I need that to work. All i ever read up until now was
handwavy referrals to some obscure "guix-channels". So i searched some, and
found none. It's not that i can't mobilize some hardcore search machine foo.
It's just that i don't want to do this anymore, because i feel it is wasted
time, which ends into subscribing into some ghettoish cult, chanting askew
"commercial baaaad, nooo goood, we better food...", ...while in reality i need
to get things f...ing done by whichever means. Which meant Windows for the
last few years. So, whenever i read about something interesting to me,
considering to spend my free time with it, this annoys me to no end, because
it feels like trying to make me jump through burning loops like some trained
animal. I can't stand this sort of stuff anymore. Especially given the fact
how much hardware only really works with binary blobs, at least when it's
current, and not some obsoleted gear or niche systems. Anyways // ENDRANT
(sorry)

------
na85
How does one pronounce "guix", anyways? Is it "goo-icks"?

~~~
Foxboron
It's a french spelling of the word "geeks" some devs told me.

~~~
oska
Not according to the french wiktionary [1].

There is a Catalan word _guix_ however, where it means chalk. [2]

[1] [https://fr.wiktionary.org/wiki/geek](https://fr.wiktionary.org/wiki/geek)

[2] [https://en.wiktionary.org/wiki/guix](https://en.wiktionary.org/wiki/guix)

~~~
pygy_
_Geek_ is a borrowed word in French, and the original English spelling is
used. If you wanted to write a word that respects French pronunciation and
sounded like "geeks" in English, you'd write it "guix", or "guiks". It is a
bilingual pun.

------
NateEag
I've been intrigued by nix then guix for several years now, but have yet to
give either one a test run.

I understand some of the technical differences, but can anyone explain the
implications of the license differences to me?

I know that NixOS is X11/MIT licensed, and that as a GNU project Guix is AGPL.

In practice, if I wanted to use Guix as a base system for hosting a
proprietary SaaS website, would there be issues with that? Either way, is
there an easier-to-read summary than the license itself anywhere?

------
shpx
Guix doesn't package proprietary software.

~~~
nyberg
Which is great. Means you have a clean install that's sure to be reproducible.
There's always the option to keep your own channel of non-free packages if you
really need them.

~~~
tadfisher
Proprietary packages may still be reproducible. Presumably, you verify a hash
of the inputs (e.g. upstream tarball/binary and patches), and the output
should still be bit-for-bit the same on any machine given the same inputs.

Not to mention that there are many open-source (as in OSI) packages that may
not be distributed with Guix System because they use non-FSF-approved software
licenses.

~~~
rekado
> Not to mention that there are many open-source (as in OSI) packages that may
> not be distributed with Guix System because they use non-FSF-approved
> software licenses.

This is not true; at the very least "many" is wrong in the above statement.
Generally, there is virtually no difference between the OSI set of approved
licenses and the FSF set.

Can you list examples of the many packages that would be considered "open
source" (according to the OSI definition) but not also Free Software as per
the FSF definition?

------
echohack5
The hardest thing to understand here about Guix is exactly what it does,
because there's only 3 tools out there that operate like this (that I'm aware
of, at least):

\- GNU Guix

\- NixOS

\- Chef Habitat

These three tools have some common themes but ultimately accomplish different
end goals.

Some common things:

\- They all provide a package manager that exists outside of the regular scope
of your operating system.

\- They all bundle together your compiled application code AND configuration
code AND runtime dependencies into one package, making it easy to just run
your application.

Some differences:

Nix. [Edit: It was pointed out that the package manager Nix, is separate from
NixOS, and this package manager can be run on any operation system).
([https://nixos.org/](https://nixos.org/))
([https://github.com/NixOS](https://github.com/NixOS))

GNU Guix has a larger focus on reproducibility and archival properties of
software. In other words, Guix uses it's ability to run software independently
of your operating system as a way of ensuring authentic, realistic, and 100%
portable applications. Guix wants to build your application FIRST, and ignore
whatever problems your OS might present to you. It lets you build a
development environment in a "clean-room" with the environment command. It
also lets you write those configurations and environments using Guile
programming interfaces and the Scheme programming language, which is super
powerful.
([https://www.gnu.org/software/guix/](https://www.gnu.org/software/guix/))
([https://github.com/pjotrp/guix](https://github.com/pjotrp/guix))

Chef Habitat is very similar to GNU Guix, except it also works for Windows
packages. It's primary goal is so that you can build and deploy your
applications completely independently of the constraints of your operating
system or runtime environment. Just like GNU Guix, this makes it super awesome
to take old applications that are "stuck" on old operating system environments
and quickly port them to whatever modern OS or runtime format you wish. Like
GNU Guix, it has a chrooted clean-room environment called the Studio and uses
Bash/Powershell to allow you to build packages. Chef Habitat diverges from GNU
Guix in that it provides a runtime process supervisor that has auto-update /
continuous delivery capabilities, and also provides a gossip protocol so that
applications can talk to each other and do things like leader election
automatically. ([https://habitat.sh](https://habitat.sh))
([https://github.com/habitat-sh/](https://github.com/habitat-sh/))

Overall, I think most people will be confused when they approach these tools
because they've never used anything like them before. But once you get your
hands in them you'll realize how awesome they really are.

~~~
jchw
Huh? Nix can run on other OSes. NixOS is just an OS built on Nix, the same way
GuixSD is an OS built on Guix. Am I missing something?

~~~
smilliken
Right, you don't need NixOS to run the package manager. The package manager
runs on Linux and MacOS.

I've been using Nix for years, in dev and production, and haven't bothered to
try NixOS yet.

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

------
dman
Any pointers/tutorial on how to get a gnome desktop up and running using guix?

~~~
rekado
The manual is really good, so I recommend looking through the installation
instructions there. The installation image comes with a text-based installer
where you can select GNOME.

(Personally, I prefer to install a bare-bones system and then reconfigure it
to something fancier. This way I can get to enjoy the features of the Guix
system much sooner --- including booting into older generations of the
system.)

------
pjmlp
I don't have any use for it, but it gets brownie points for its use of Scheme.

~~~
Koshkin
Me, I'll wait for GNU AI to take over everything.

------
berbec
Does the logo look similar to the female reproductive system to anyone?

~~~
mrmuagi
It looks like a V with bullhorns to me, which is weird -- what does the V
symbolise in this project?

~~~
rekado
It's a GNU ;)

