
Guix: An advanced operating system - Ambrevar
https://ambrevar.xyz/guix-advance/index.html
======
sterlind
I started using NixOS over Christmas and I have no trouble whatsoever with the
language. It seems pretty lazy for the author to shoot Nix down on the grounds
that DSLs are "always a bad idea." He even has the nerve to mention Mozilla as
failing with XUL, while ignoring the success of Rust!

Nix is lightweight, pure and maximally lazy. It's a simple DSL that evaluates
targets -> derivations (build specs.) Considering it can build an entire OS
with so few features, I'm not sure adding a numeric tower and Turing-
completeness is really desirable.

Also, I'm surprised this article doesn't mention Hydra. Reproducible binary
caches and automatic testing are one of the key advantages of these systems --
does Guix use it?

~~~
jchw
I also started using NixOS around Christmas time. I really love NixOS, but I'm
at best lukewarm on Nix as a language. Honestly, though, the language is not
my current concern. My current concern is actually more about
compartmentalization.

Being able to run `nix-shell -p` and get a shell with a program installed is
super cool. Also, being able to add a package to the system declaratively is
super cool. However, one thing I wonder about is workflows.

For example, I have a lot of Jetbrains IDEs installed for various languages,
but I don't want to pollute my global environment with tools, especially
command line tools that pollute the PATH. Let's say I want to use Jetbrains
Rider. I can easily start a shell with the dotnet SDK with `nix-shell -p
dotnet`, then start Rider under that shell. This is OK, but it feels wrong to
me. It feels weird that launching Rider outside of nix-shell won't ever work,
yet it's installed globally. And yet, I also kind of want it to be globally
installed...

Another solution would be to have Nix expressions for every project I work on.
This actually seems better and I've adopted it for a couple projects, but it
also irks me because it feels half-baked. I don't know where to put these
expressions other than next to the project, but I don't think it belongs in
version control. Also, I'm very mixed for what belongs in these environments.
Should it be personally suited, with my IDE and developer tools? If I do that,
I can't share the same code I'd use for my tooling as I would for my Nixpkg
(assuming there is a nixpkg) which leads to a divergence I don't like. (Though
maybe that can be solved?)

I almost want a robust system of working environments that encapsulates this.
So, I could think about my Nix workflows as separate environments. Declarative
or imperative, and ideally with more encapsulation than a typical nix-shell.
Maybe instead of orienting my workflow around opening an IDE and opening a
project, I can orient it around opening a project environment and then opening
an IDE inside of it.

At this point I'm just rambling. I still prefer NixOS for practical reasons,
since it makes my complex IOMMU setup a cinch and keeps all of the
configuration for it surfaced and documented. But dang, the potential here to
shift workflow paradigms is enormous, it feels.

~~~
majewsky
> I also started using NixOS around Christmas time.

Hah, me too. :)

> I really love NixOS, but I'm at best lukewarm on Nix as a language.

My biggest issue as of now is that the documentation focuses on which
individual files you need to touch, but doesn't really explain the big
picture. For example, /etc/nixos/configuration.nix contains a function that
takes { config, pkgs, ... }. Where do these come from? Where can I find
documentation for them? What is in the ellipsis? More generally, where can I
find a high-level overview of how the different components interact with each
other during, for instance, nixos-rebuild?

~~~
sterlind
All the quirks are little design patterns that look pretty weird at first, not
language features themselves. The resource you're looking for is the _Nix
Pills_ series [0]. The LearnXInYMinutes on Nix is also a good overview of the
syntax.[1] nix repl is also essential for feeling it out.

To answer your question, { config, pkgs, ... }: declares a function that takes
an attribute set containing values for "config" and "pkgs". The ellipsis
indicates that it's okay to pass extra attributes.

Nixos-rebuild calls your function by: with (import <nixpkgs> {}); callPackage
./configuration.nix {}

<nixpkgs> is a file containing the set of all symbols (packages are under
pkgs, Nix config lives in config, etc.) like a root namespace. callPackage
inherits all those symbols and passes them to the function, which is how they
got bound.

0\. [https://nixos.org/nixos/nix-
pills/index.html](https://nixos.org/nixos/nix-pills/index.html)

1\.
[https://learnxinyminutes.com/docs/nix/](https://learnxinyminutes.com/docs/nix/)

EDIT: I guess it's also like Git where it's really confusing until a moment of
enlightenment where it all makes sense.

~~~
arianvanp
NixOS doesn't actually use callPackage. it uses lib.evalModules. The fact
there is a difference between how NixOS is evaluated, vs how Nixpkgs is
evaluated is something I actually find quite annoying. Whilst nixpkgs is all
about functions and dependency injection, NixOS is all about merging
dictionaries.

Here is some context, with corresponding criticsm by the person behind Guix,
which might give some interesting insights

[https://discourse.nixos.org/t/best-resources-for-learning-
ab...](https://discourse.nixos.org/t/best-resources-for-learning-about-the-
nixos-module-system/1177/4)

------
tomp
I only skimmed, but parts of this article read as just another pro-LISP
piece... A rant against other languages (which the author terms "DSLs" simply
because they're not Turing complete) like LaTeX, HTML, regex, SQL etc. and
lists alternatives, all of which are S-expression-based. Well, the superiority
of S-expressions is just, like, your opinion, man. Personally, I consider them
inferior to pretty much any other syntax (joke languages like Brainfuck,
Whitespace, JavaScript excluded). An in absolute terms, the whole civilisation
was built on syntax-full DSLs (law, math, engineering, ...).

I mean, how is this (Skribilo):

    
    
         (define (freedom . body)
           (ref :url "http://www.gnu.org/philosophy/free-sw.html" :text body))
    
         (p [Skribilo is a ,(freedom [free]) document production tool that takes a structured document ...])
    

better than this (LaTeX):

    
    
        Skribilo is a \href{http://www.gnu.org/philosophy/free-sw.html}{free} document production tool that takes a structured document ...

~~~
Ambrevar
The article is for the bigger part about operating systems, only a minor part
is about programming languages (which is important for the matter at hand).
It's not pro-Lisp in particular, it's pro-"general-purpose, well tested and
well designed programming languages". I don't exlude other programming
languages from the picture. The alternative I gave as examples are the ones
that I know of, but sure thing there are others out there in Python, Lua,
Ruby, you name it.

I personally like S-expressions because they are very general and have deep
semantic implications (eval-apply, a.k.a. code is data) that go beyond mere
syntactic considerations.

Regarding your examples, if I understand correctly they are not equivalent, so
they don't exactly compare.

Here LaTeX would require the \begin{document}...\end{document} bits.

But regardless, TeX is very painful to program with (lack of proper data
structures and control structures). It's very important in my opinion.

~~~
_emacsomancer_
TeX itself is Turing-complete, if not exactly an ideal language for computing
things not directly related to typography.

But Lua(La)TeX exists, which allows for more user-friendly scripting in Lua
(not my favourite language, but...), and I think that is the only real
'competitor' of (La)TeX.

I love Lisp, but the majority of what I write is in (La)TeX, and I don't know
of anything comparable for dealing with creating and typesetting academic-type
work. Most of its 'competitors' use TeX on the back-ends, and though I've
tried writing more in Org mode and exporting to LaTeX, in the end for anything
beyond trivial text, it's easier just to write directly in LaTeX.

~~~
Ambrevar
All this is definitely true, but in my opinion not ideal. LuaTeX adds a
significant layer of complexity to an already way-too-complex system.

At this point we might want to step back and wonder why this has become so
hard.

TeX is a poor foundation to build upon, so I don't think LuaTeX, despite being
the best solution currently, is the right direction to explore.

~~~
_emacsomancer_
> TeX is a poor foundation to build upon

I still disagree with this characterisation. TeX is a really beautiful
solution to a non-trivial problem, and its implementation in WEB is really
quite interesting. _La_ TeX adds quite a lot of complexity and messiness, but
does also add very useful functionality and abstraction away from low-level
typesetting. Org-mode and similar 'mark-up' languages are very nice in more
rigidly-defined domains, but they don't have the power of (La)TeX for academic
writing. I don't see any real 'competitors' to (La)TeX that aren't themselves
just adding layers on top of TeX (for better or worse). TeX is nearly as old
as (original) Emacs and has similarly become complex in perhaps not-entirely-
ideal ways, but - like Emacs - there's no substitute.

~~~
Ambrevar
I'm not criticizing the power of TeX in terms of typesetting, I'm only
referring to the _language_ here. (And you are aboslutely right, Org and other
markup languages are not competing with TeX.)

Imaging the capabilities of TeX with a good programming language.

I don't find WEB beautiful. In my opinion, literate programming (at least in
this case) is a pretext to hide a terrible, unexpressive programming language.

As you're saying, Emacs had the good taste to use a Lisp back in those days,
so it really is a pity that TeX didn't.

~~~
_emacsomancer_
Well, I agree a Lisp or at least more Lispy interface with TeX would be much
preferable. But I am dubious how anything comparable to TeX and the TeX-
ecosystem would be developed at this point.

~~~
_emacsomancer_
Additional: I did come across [https://github.com/mbattyani/cl-
typesetting](https://github.com/mbattyani/cl-typesetting) , though its
homepage seems to have disappeared.

~~~
Ambrevar
Nice! Thanks for sharing!

------
orangeshark
Guix and GuixSD are definitely interesting. I am currently running Guix on top
of Fedora for my desktop and just recently started running GuixSD on my
laptop. Probably my favorite feature that I use the most is guix environment
which can help me set up all the necessary packages needed to build and work
on projects.

I think there is a lot of hidden potential in Guix, especially with the choice
of Guile as the language. The article demonstrates a bit of what you can do
from Guile with some small script examples. A lot of the functionality of Guix
is exposed and can be used to create tools and scripts. I sort of wonder what
interesting tools and scripts will be made using this.

~~~
vindarel
Nice. What languages do you build environments for ? Are they ready for a
typical python & JS (vuejs) project ?

~~~
rekado
Python: sure. JS: ... it's complicated.

See this article for an introduction to the problems of attempting to match
npm with principled package management:

[https://dustycloud.org/blog/javascript-packaging-
dystopia/](https://dustycloud.org/blog/javascript-packaging-dystopia/)

------
dman
Any pointers to an opinionated install guide that does not require me to
configure every aspect of the system? Something that yields a working
gnome/kde desktop with less than 10 minutes of effort would be ideal.

~~~
Ambrevar
A more user-friendly installer is in the works and should hit Guix with 1.0.

Currently, Guix comes with pre-filled operating system declarations so that
beside filling out the hostname and a few other options, there is little to do
but run `guix system init`.

While Guix install is completely different from any other system (except Nix),
it is suprisingly easy with nothing else but 2-3 steps (if you have Linux-
libre compatible hardware, that is to say).

~~~
dman
Thanks - really looking forward to moving my workstations to something like
GUIX, the productivity gains will be immense.

------
macintux
> TeX, LaTeX (and all the derivatives), Asymptote (better ideas: scribble,
> skribilo)

It’s hard to take screeds like this seriously when their suggested
alternatives use LaTeX for output!

~~~
rekado
Skribilo can use lout for output.

------
fwip
> GuixSD strimes at being the “fully-programmable OS."

What does this mean? Google is suggesting it has something to do with weed-
whackers, and I'm guessing that's not right.

~~~
syrrim
probably s/strimes/strives

~~~
Ambrevar
Indeed, thanks for catching the typo!

------
bscphil
_> GNU/Linux distributions in general lack the aforementioned perks of Guix.
Some of the most critical points include:_

 _> Lack of support for multiple package version, or “dependency hell”. Say,
when the latest mpv requires a new ffmpeg, but upgrading ffmpeg breaks most
other programs relying on it, we are stuck we dilemma: either we break some
packages or we stick to older versions of other packages. Worse, a program
could end up not being packaged or support by the OS at all. This issue is
inherent to most distributions which can simply not provide the guarantee to
fulfill their primary objective: package any program._

I disagree. Having multiple versions of a package means having _old_ versions
of a package, and that's something most users should not be messing with
because they are not in a position to track and backport security fixes.

It's always undesirable to have to a dependency on an old, probably
unsupported version of a library. The distributions that do it have a
correspondingly huge maintenance burden. One of the advantages (from my point
of view) of a lighter rolling distribution like Arch is that because all the
software on the system is expected to be compatible with a library version
that is upstream-supported, there is significantly less maintenance work to be
done. Note that this is compatible with, say, packaging both GTK2 and GTK3
programs, since both of those are supported upstream. The OS is perfectly
_compatible_ with shipping multiple versions of a library, but Arch sensibly
(IMO) chooses not to do so by default.

One way to quickly experience the pain points of the OP's way of doing things
is to try to use or distribute software written in a language with a "modern"
build tool like npm or cargo. These systems implicitly encourage hardcoding a
single version (or a small set of versions) as dependencies, and the
convenience of this means that many developers rarely update the list even if
the new library versions are fully compatible with their code. So as the user
building the software, or someone who wants to distribute it, you can either
run with libraries that have known vulnerabilities, or you can update the
libraries yourself and run an unsupported configuration, hoping you don't
break anything in the process. A more reasonable position is that it is a
_bug_ if your program crashes with the latest version of a library.

~~~
zapzupnz
> A more reasonable position is that it is a _bug_ if your program crashes
> with the latest version of a library

This makes sense for actively maintained code.

There are a lot of pieces of software that aren't actively maintained but that
don't exhibit any breaking bugs and people continue to rely on them. If the
libraries that these pieces of software ever make breaking changes, either (a)
someone has to step up and start maintaining the software again, (b) an older
version of the library must be installed, or (c) the software dropped,
annoying a lot of people who still depend on the tool.

What macOS has is .frameworks, which let you version shared dynamic libraries.
When building a project against a framework, one can either choose to build
against a specific version or (more commonly) leave the version unspecified
and use the latest. No fuss, no muss.

~~~
white-flame
> _When building a project against a framework..._

That still implies active maintenance, ie doing new builds.

If it's assumed to work with the "latest version", but then breaks in the
future, it is a decision outside of the build itself as to which version of
the library it should link up with.

The only thing that should be baked into the software is which specific
version of the dynamic lib it was compatible with, then externally the system
can determine which most-recent version of the library is still compatible.

~~~
zapzupnz
> then externally the system can determine which most-recent version of the
> library is still compatible

This is great until a more recent version of a library still has the same
interface but a completely different behaviour or seriously breaking bug in
the implementation.

~~~
white-flame
That's exactly what I'm talking about. That compatibility information is what
needs to be captured, and is outside any future preference that the program
was originally built to.

Instead, most automatic systems just blindly say "this version number is
newer, so use that" and break everything. Programs were built to a specific
version which worked, and only those versions compatible to that specific
version should be used.

------
rekado
Guix co-maintainer here.

The article says "Guix is a fork of Nix", but this is not correct. Guix uses
the same format for derivations (~ a low-level representation of builds), so
that it can reuse the Nix daemon, but that doesn't make it a fork.

Guix builds upon the very same idea of functional package management that was
pioneered with Nix, so they _are_ very close and they do have shared roots.
But that's not what "fork" is usually understood to mean.

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
GuixSD (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.

\- GuixSD, the GNU system distribution built around Guix. GuixSD 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. GuixSD 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 and GuixSD 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.

~~~
jancsika
> \- 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.

Tell us about graph rebuild times.

When there's a security update to glibc and you do the equivalent of `apt-get
upgrade` in Guix, how long does that generally take to complete?

~~~
rekado
In cases like that we use a mechanism called "grafting". See
[http://www.gnu.org/software/guix/manual/en/html_node/Securit...](http://www.gnu.org/software/guix/manual/en/html_node/Security-
Updates.html) for a description.

We usually put changes that cause the world to be rebuilt on a separate branch
and have the build farm build binaries for it. This can take quite a while,
but it's not something a user generally needs to worry about.

------
equalunique
Nix and Guix both excite me a lot. Guix as a Guile scheme API is a very
exciting, but what I like more is, as a result of that, Guix & it's
derivations are all part of the same repo. Because they are one in the same I
can be sure I'm not going to build a package that hasn't been tested against
the version of guix I am running. It simplifies integration testing if I
decide to create a new branch of Guix packages.

------
SeaDude
I really want the things Guix provides, but I'm not a computer scientist.
Feels like you need to be to make it work somewhat like the linux desktop I
enjoy computing on (text editor, graphical web browser, sky, virtualbox,
postman, osb, keepassxc, etc.)

~~~
Ambrevar
If you look at [https://guix-hpc.bordeaux.inria.fr/browse](https://guix-
hpc.bordeaux.inria.fr/browse)? you'll find most of your wishes there, and many
more to come hopefully.

Guix is also working on an installer to help reducing the friction. I'd
personally like to work on a fully graphical install + package management.

While Guix sounds like some heavy scientific stuff, it really is a powerful
base that allows anything to grow on top, including user-friendly interfaces.

------
mark_l_watson
I have a question for GuixSD users here: I have a laptop with NVidia CUDA,
TensorFlow, mxnet, Python, Julia, etc. installed.

I experimented with NixOS last year, liked it, and being long time Lisp user I
would like to also try GuixSD. Would I have problems with CUDA, etc.?

~~~
rekado
CUDA is problematic. There is no package for CUDA in the official Guix
channels, because it is non-free software.

There is a patch for a Tensorflow package, which is built without GPU support
(because that requires CUDA), but it hasn't been merged yet, because it isn't
really pretty. (I didn't use Bazel to build Tensorflow, because Bazel depends
on dozens of Java archives that cannot easily be built exclusively from
source.)

You can use Nix as an additional package manager on top of a Guix system, of
course, but this might not be as satisfying as using one package manager
exclusively.

------
vemv
Exciting stuff. There's been bit of a Lisp renaissance over the last 5-10
years (thanks to the Emacs packaging system, Clojure) so this could be the
next logical step for someone who writes parens for a living.

------
ethanpil
I don't understand why these config systems can't be less 'programmy' (less
technical).

All of these (Nix/Guix/NginX Lua, etc) config systems are all so complex with
layers of interesting syntax and punctuation.

Why can't these use simpler (INI/YAML/TOML/CSON or even JSON) configuration
schemes? It would reduce barrier to entry - simplify parsing and automation,
and a whole lot of other things. Why do I need to learn yet another language
just to configure and manage my system?

~~~
kodablah
> Why can't these use simpler [...] configuration schemes?

Because you inevitably need something less simple at some point. It's a hard
balance to strike. Want only a config format? Get angry advanced users. Want
only a programming language? Get angry beginners. Want both? Get a hodge-podge
of half-and-half configs calling out to built extensions and in general a
bunch of beginners finding poor code-based solutions on the internet.

In general, you need a simple programming language to manage this stuff or it
becomes unwieldy once it leaves hobbyist size. And mixing config formats and
full-blown languages (or worse, template languages) just adds ambiguity on the
best way to do something coupled with loose synchronization between the two
formats, "extension hell", and half-developed code solutions with an
exponential number of poorly tested combinations of exported features that
beginners try to use. To see examples of all these problems, one simply has to
look at the historical landscape of orchestration engines and build tools.

~~~
edwintorok
Some food for thought: [https://dhall-lang.org/](https://dhall-lang.org/)
looks like an interesting balance between config file format and
programmability. Would it be suitable for describing packages?

~~~
Ambrevar
I don't think that would be enough. At the end of the article I linked the
paper "Code staging in GNU Guix"
([https://arxiv.org/abs/1709.00833](https://arxiv.org/abs/1709.00833)) which
explains why 2 stages of code execution are so central in Guix. In practice,
this means that a Turing-complete language (Scheme) is used both at the
declaration level and the build level. Lots of packages make use of this
feature, it brings tremendous flexibility to packaging.

------
_emacsomancer_
I'd really like to see Shepherd used outside of GuixSD. In theory, since Guix
can be installed on top of other distros, this could be leveraged to be make
swapping in Shepherd easier. Of course, systemd is much more complex, so
replacing the init in systemd-based distro would probably be trickier, but it
should be more manageable in places like Void Linux.

~~~
theamk
Shepherd is quite scary outside of GUIX. It basically runs package-supplied
code in PID 1, with no protection. A badly written init script will halt
startup completely and render system unbootable.

GUIX (I believe) has this "choose previous version from GRUB" dialog, so you
can recover from bad init script by rolling back the whole thing. Any other OS
will require manual fixes, and this is going to be quite a pain.

~~~
_emacsomancer_
Ah, thanks for the additional information. That's too bad though, I like the
model of a Scheme-based init. I suppose I'll stick with runit for now then.

------
k__
I tried NixOS a few years ago when they talked about better UX for the CLI.
Anyone know if this happend?

~~~
akavel
It does slowly happen. There's a new `nix` command (a.k.a. Nix 2.0), which has
a better CLI, though it's not yet 100% complete, I believe. But already useful
(e.g. `nix search`).

[https://nixos.org/nix/manual/#ssec-
relnotes-2.0](https://nixos.org/nix/manual/#ssec-relnotes-2.0)

~~~
k__
Nice.

Does Guix have a better CLI?

~~~
civodul
Compared to Nix 1.x (not sure about 2.x), I think it's simpler to use (Guix
co-maintainer here and before that a Nix contributor). This is the reference
of 'guix package' (analogous to 'nix-env'):

[https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-
pac...](https://gnu.org/s/guix/manual/en/html_node/Invoking-guix-package.html)

Because it's all Scheme, Guix has well defined APIs for all sorts of things.
For instance, there's an API for search paths (environment variables you need
to define when you install packages), one to create application bundles, one
to create VMs containing GuixSD, etc.

That, in turn, leads to clean CLIs in my opinion: 'guix package --search-
paths', 'guix pack', 'guix system vm', etc.

------
hardwaresofton
Guix seems interesting but I almost stopped reading when I read "Nix". For all
the benefits the Nix ecosystem provides, they haven't crossed the usability
gap for me. First was naming their packages so confusingly, Nix the language
vs NixOS vs Nix the package manager. Then there's the whole promise of it
being usable from multiple platforms ("you don't even have to use NixOS, just
use the package manager for awesome builds") -- It was supposedly amazing for
building some software packages, but the reality was always so sticky and
never quite panned out.

To be fair I have seen/heard lots praise it a lot for delivering stability to
the servers they manage, but in this day and age, I'm not sure it's even worth
trying to learn something to manage servers when the cattle approach is so
much better (just shoot it). Even when stateful applications get involved,
distributed storage is springing up to make it easier than ever to take down a
server but have the data it had still be accessible, granted it was
replicated, and sync if/when the machine ever comes back up. If the world
evolves in that direction, it seems like people will only care about packages
at VM/container/whatever base layer build time.

Don't want to be the downer here but I don't think it's likely that Guix is
going to cross the usability chasm. I've invested a lot of
time/interest/effort in projects that were better, but never crossed the
usability/mindshare chasm and while I hope I'm wrong, this feels like some of
the other ones.

Completely unrelated to that though, this quote rang true to me:

> Guix is a fork of Nix and addresses the main issue that Nix didn’t get
> right: instead of comming up with a homebrewed domain-specific language
> (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-
> fledged programming language. (And a good one at that, since it’s Guile
> Scheme, a Lisp-based language.)

I think Hashicorp has this problem with HCL (see the recent updates[0]
announced at the last HashiConf, the `for` keyword is now in HCL) -- though
I'm not recommending they fix the problem with lisp, people need to stop
making DSLs then bridging the gap between their DSL and a full programming
language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots
of rope to hang themselves with ("recursive infrastructure building
functions...why not?").

[0]: [https://www.hashicorp.com/resources/keynote-terraform-
free-s...](https://www.hashicorp.com/resources/keynote-terraform-free-saas-
tier-hcl-upgrades)

[1]:
[https://pulumi.io/reference/how.html](https://pulumi.io/reference/how.html)

~~~
sterlind
NixOS fangirl here... you're totally right about usability!

Git was self-hosting from day 3, but consisted only of a few pieces of exposed
plumbing. As more porcelain was bolted on, it got to the point where flashy
UIs could exist. Porcelain isn't all trivial either - consider "git rebase"!

NixOS today is like early Git.. usable and powerful, but not user-friendly. It
needs a good UI, a graphical installer, and high-level porcelain to hide the
plumbing unless you need to drop into it.

As for the cattle question, I think Nix's real power will come from efficient,
declarative "Dockerfiles" and serving as a Bazel-like build system. There was
a project for this, Hocker, but it seems inactive.

~~~
hardwaresofton
> NixOS today is like early Git.. usable and powerful, but not user-friendly.
> It needs a good UI, a graphical installer, and high-level porcelain to hide
> the plumbing unless you need to drop into it.

I'm not sure even that's enough, Nix is trying to win the lottery 3 times --
pushing a (essentially universal) package manager, a programming language, and
linux distribution into the mainstream at the same time. What you noted
_might_ solve package management, but I'm convinced no one actually knows just
how to make programming languages/OSes popular enough to hit and stay in the
mainstream, outside of lots of money for marketing or serendipity.

All this said... Nix (OS + package manager) is definitely on my list of things
to take for a spin -- I watch and read stuff about it but haven't taken the
plunge just yet. It's very popular in the Haskell Ecosystem [0].

[0]: [http://www.tpflug.me/2019/01/14/haskell-nix-
vim/](http://www.tpflug.me/2019/01/14/haskell-nix-vim/)

~~~
akavel
Interestingly, historically, at first there was only Nix the package manager +
language. The NixOS distribution came to be purely as a subsequent experiment,
a bright idea by a single another person (AFAIK), kinda "what if?..." Which
then became a runaway success (relatively speaking — not mainstream yet), with
more and more people realizing the potential and the benefits. Moreover, in
fact the original Nix was also a one-person experiment, a PhD thesis by Eelco
Dolstra.

I believe there's not that much "pushing" anything, rather the ideas being
just inherently awesome and breakthrough, and many people quickly realizing
this notion after being exposed to them :)

------
IshKebab
> Even if the devs don't need Turing-completeness, not adding it to a project
> is effectively limitating what the user can do with a program.

But limiting what people can do with build systems is generally a _good_
thing.

~~~
Ambrevar
Why?

Also one core feature of Guix is that it cannot break: you can always roll
back.

~~~
IshKebab
Because then tools can reason about the build system. Also it limits the crazy
things people try to do.

------
theusername
I don't get it. Yeah guix is good. But AFAIK GuixSD has no support for modern
hardwares due to their policy toward firmware blobs. So how's a OS being
advanced without good hardware support?

------
wuschel
Looks to me like Guix is Nix with a Scheme based language (Guile) instead of
the Nix specific DSL.

------
eadmund
I do really wish that Guix used Lisp rather than Scheme.

~~~
draven
You mean Common Lisp ? Because Scheme is a Lisp.

Guix is from GNU, Scheme is their official extension language (with Guile as
the implementation.)

~~~
darkpuma
It's a tedious fruitless argument that goes back years. Some people in the
"Common Lisp camp" believe that Common Lisp has the "rights" to the 'Lisp'
"trademark."

~~~
delish
As someone who programs in Clojure--and therefore has no justification for
weighing in--I _believe_ that it's a cultural or generational difference. That
is, for certain programmers (working in the 1980s? 1990s?) "Lisp" (capital-L,
lower-case isp) meant Common Lisp, and many agreed.

I am sure that people tediously, fruitlessly argue about it. But it's also
true that for a wide swath of programmers, Lisp is Common Lisp.

I wonder if hn's lisper or lispm could weigh in...

~~~
darkpuma
Arguments about labels are always tedious and fruitless. They don't advance
anybody's understanding of anything important, like the substance of the
whatever those labels might apply to. Arguing about whether or not "Lisp"
means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.

~~~
kazinator
The sentence at the root of this subthread, namely "I do really wish that Guix
used Lisp rather than Scheme" isn't an argument about labels.

~~~
darkpuma
No, but the terminology of the root was plainly coming from the camp of _"
Scheme isn't Lisp, Common Lisp is Lisp."_ The child comment was confused by
that peculiar terminology, so I provided context for that terminology in a way
that I hoped would head off yet another argument about labels. It was my
intent to stop the argument before it began.

~~~
kazinator
The terminology is troublesome because "Scheme" more specifically determines
the language than "Lisp", so "I'd prefer to use Lisp over Scheme" or _vice
versa_ is somewhat "apples versus vegetables".

