
Nix 2.0 Released - jack_jennings
https://nixos.org/nix/manual/#ssec-relnotes-2.0
======
zapita
I love the core concepts behind Nix, and have great respect for their
engineering abilities. However I am skeptical of their ability to achieve
broad adoption beyond their current community of passionate experts.

There are two reasons for my skepticism:

1\. User experience. Unless you're one of the "passionate experts", the Nix
user experience is pretty terrible. The learning curve is punishing compared
to competing systems.

2\. Elitist culture. In my experience, the Nix community is too smart for its
own good. Their technical foundation is so far ahead of mainstream systems,
and their technical design so satisfying to passionate experts, that they've
forgotten how to live a day in the shoes of a mere mortal. Try pointing out
flaws in the user experience, or the need to offer more pragmatic ways to
migrate existing systems, and you will be met mostly with derision and
reminders of Nix's superior engineering. But superior engineering is not
everything. If you want to spread the amazing potential of Nix to everyone,
then you need to compromise with a flawed, imperfect world. You need to meet
users half-way, and guide them to the promised land, instead of waiting for
them to show up on their own. Otherwise someone will come along that will do
it for you.

All this is eerily similar to what happened to functional programming
communities.

~~~
grantwu
This, 100%.

Pain points I've run into:

1\. Lack of clarity as to how language/application package managers interact
with Nix (pip, stack, Vundle). Pretty much every time I've asked about this,
I've been told to go use `nix-shell` or to install things through Nix.
Increasingly, when I get odd behavior with applications I install through Nix,
my first resort is to uninstall the Nix version and install it from apt; it
might be a bit older, but I'm sure it'll work as expected. I've went through
the apt package -> Nix package -> apt package cycle three times from what I
remember off the top of my head, with python/ipython, Haskell tooling, and
Vim.

2\. Nix on Ubuntu feels like a second class citizen. Things that interact with
graphics drivers often don't work properly, e.g. video players. (I understand
that there are technical reasons why this is the case, but there's no warning
that this is the case.) There only appears to be online package search for
NixOS
([https://nixos.org/nixos/packages.html#](https://nixos.org/nixos/packages.html#))
and not for Nix on other platforms. Nox helps, but it doesn't seem to be the
same feature wise (no ability to see the info you get by clicking the package
name) and is also slow.

3\. In general package quality is not great for less frequently used packages.
Inkscape was missing potrace for a while. Rarely used packages go
unmaintained.

4\. Poor CLI. Needing to pass `-A` to a lot of commands to use them the "right
way" smells of a poorly thought out design. No feedback or suggestions if you
type the wrong thing to `nix-env -e`. It looks like there are major changes to
this in 2.0, so this might have been improved.

Despite being someone who's gotten their toes wet contributing to nixpkgs, I'm
likely not going to be installing Nix when I upgrade from Ubuntu 16.04 to
18.04.

~~~
pknopf
I built Darch to give me what I crave from NixOS.

Immutability.

[https://godarch.com/](https://godarch.com/)

~~~
grantwu
What does... how is this relevant to anything I said?

~~~
taohansen
If I may rush to the commenter's rescue: Darch addresses your issues with
NixOS by combining a familiar set of tools (Arch Linux) with stateless
architecture. Its a fantastic welding of extreme package availability and
best-in-class documentation with declarative dependability.

~~~
grantwu
It's not clear to me that this really solves the same problems that Nix does.

I'd imagine this solution inherits any problems that pacman has. The Arch wiki
states that "if two packages depend on the same library, upgrading only one
package might also upgrade the library (as a dependency), which might then
break the other package which depends on an older version of the library."
([https://wiki.archlinux.org/index.php/System_maintenance](https://wiki.archlinux.org/index.php/System_maintenance))
This is one of the problems Nix does not have by design; in fact Nix lets you
mix and match packages painlessly.

This also doesn't seem to allow unprivileged users to install packages, which
is kind of a side benefit of using Nix.

Docker-esque solutions' issues with reproducibility are well known; I look at
[https://godarch.com/concepts/images/](https://godarch.com/concepts/images/),
particularly how packages are installed:

    
    
      #!/usr/bin/env bash
      pacman -S steam --noconfirm
    

and I see the same issues that [https://blog.wearewizards.io/why-docker-is-
not-the-answer-to...](https://blog.wearewizards.io/why-docker-is-not-the-
answer-to-reproducible-research-and-why-nix-may-be) warns of. Heck the author
even admits this is the case in an adjacent comment: "I want a machine that
can be declared and rebuilt deterministically _(at least semi-
deterministically, rolling distro and all)_ " (emphasis mine).

Also, frankly, I don't want to run my personal computer like a server, with
complete immutability and the need to build fat image files every time I want
to try out an additional program. That seems to me like a workflow that's
better suited for servers where spending a few minutes for a deploy isn't a
blocking operation, and where stateless service design is considered best
practice.

~~~
pknopf
> if two packages depend on the same library, upgrading only one package might
> also upgrade the library

Yes, you are inheriting the nuances of whatever package manager you choose.
Maybe another distro can give you a truly fixed package versions? You can also
use apt to pin versions. This isn't something that Darch introduced, but also,
it isn't something it solves. So yes, if you need 100% deterministic, Nix is
your guy. I don't think this is a big issue though on Ubuntu systems, or most
non-rolling distros. Their apt updates are typically well tested and don't
bump major versions.

> need to build fat image files every time I want to try out an additional
> program

You can install your packages and use them when you like, without requiring a
rebuild. Hell, that is even part of my workflow for some applications like
docker. I have dotfiles with a "install-docker" and "install-vmware" aliases
that installs it whenever I need it, instead of baking it into images.

> That seems to me like a workflow that's better suited for servers where
> spending a few minutes for a deploy isn't a blocking operation, and where
> stateless service design is considered best practice.

I disagree. If this was the case, then why Nix then? Obviously, stateless is
valuable. I have multiple machines that I perform common tasks on. I hate
having to always manage the updates when I get back to each one of them. With
Darch, I can deploy one single image to all devices, and be confident they
will never drift in installed packages/configuration. I never again have to
ask my self "what machine am I on again?". Stateless may be the definitive way
to run servers, but that by no means restricts it to only servers. I have been
running Darch for a few months now, and I find it incredibly useful and
calming.

~~~
grantwu
> So yes, if you need 100% deterministic, Nix is your guy.

There are two orthogonal problems here: a lack of package isolation and
nondeterminism.

Nix isolates packages, such that updating one package has no impact on any
other packages (with unavoidable exceptions like the graphics driver,
presumably).

You're right that package isolation isn't much of a problem on non-rolling
distros. One of the benefits of Nix is that you get some of the stability and
predictability of an LTS distro with the freshness of a rolling distro when
desired, without having to deal with package conflicts.

Incidentally, Nix doesn't need to be used in a deterministic manner. In fact,
I don't think most desktop users of Nix care too much about determinism for
most packages they run. I certainly don't; I'm happy to follow along with
whatever arrives in my channel. Nix has features that support determinism, and
I'm certainly glad they exist for when I end up needing them, but they're not
necessarily why people use Nix.

> Obviously, stateless is valuable.

When I said "stateless", I was referring to the whole "cattle, not pets" view
of servers, where the running state of any particular server is unimportant,
with nothing in the filesystem being of value. I was arguing that needing to
build a new image and reboot in order to change which packages are installed
are a poor fit for the desktop use case, where frequent reboots are much more
inconvenient than for the server use case.

I'm not sure what taohansen meant when they used the word "stateless"; they
seem to mean something different when they say that.

Anyways, this point is not really applicable anymore, since you've stated:

> You can install your packages and use them when you like, without requiring
> a rebuild.

Presumably if you install additional packages uncontrolled by your tooling,
then your systems can start to drift away from each other.

Nix does not have this compromise; there's no build step. At any given point
in time you can reproduce whatever configuration you have on one machine on
another machine, regardless of how piecemeal you arrived at that
configuration.

------
vishvananda
I have been using nix for a while to build binary packages for crashcart[1]
and I really love the premise of isolated source-based builds.

Unfortunately, over time I've become quite frustrated with the pull-everything
from the internet model. If you are building packages from scratch each time
instead of pulling down cached version using the nix command, the build breaks
quite often.

Mostly it is silly stuff like the source package disappearing from the net. A
particularly egregious offender is the named.root[2] file being updated, which
will cause everything to fail to build until the sha is updated in the build
def.

I don't know that there is a great solution for this problem. Maybe there
needs to be a CI system that does from scratch build of all of the packages
every day and automatically files bugs. Alternatively, a cache of sources and
not just built packages could ease the pain. This issue probably affects ver
few nix users, but it has demoted my love of nix down to "still likes but is
somewhat annoyed by".

[1]:
[https://github.com/oracle/crashcart](https://github.com/oracle/crashcart)
[2]:
[https://www.internic.net/domain/named.root](https://www.internic.net/domain/named.root)

~~~
TheChaplain
I've not tried Nix but this seems like a huge oversight if there is no local
cache?

Not everyone is blessed with unlimited gigabit fiber.

Edit: Seems like I was wrong, and I'm happy about it. :)

~~~
jbboehr
If you use a content-addressable scheme (fetchurl with sha256, for example),
it will retain the source archives until you run garbage collect.

If you use builtins.fetchTarball, I don't think this is the case.

Since this all uses CAS, you can use the nix prefetch scripts to import an
arbitrary file:// or other URI into the nix store.

~~~
manveru
fetchTarball now also supports an optional sha256 argument. It'll then be used
indefinitely without checking for changes after the TTL expires.

------
lukego
Hurray!

I love Nix and I have been looking forward to this new makeover of the UI with
the 'nix' command. It seems like the original command line usages developed
incrementally over time, making them quirky and inconsistent, and so it is
really welcome to have them redone based on long experience. (Thanks, Nix
hackers!)

Seeing this released as Nix 2.0 is a really lovely surprise for me this
morning :).

------
hedning
I guess this is a good place to plug the fairly new bash completion support
for Nix (including Nix 2.0)[1]. For those like me who can't stand using a cli
without completion.

[1] [https://github.com/hedning/nix-bash-
completions](https://github.com/hedning/nix-bash-completions)

------
Lilian_Lee
> _It introduces a new command named nix, which is intended to eventually
> replace all nix-_ * _commands with a more consistent and better designed
> user interface_

This is pretty nice. I've been using nix on my Mac for more than a year now,
it works well on mac. But the separated commands are not easy to remember and
the help documentation is also separated. This change really improves command
line UX

------
TremendousT
Heh- after a many years haitus from running any kind of UNIX/Linux at home, I
was thinking about installing a Linux based distro and NixOS was near the top
of my list to try. How does this 2.0 Nix release effect a new install of
NixOS- should I wait a bit for a corresponding overhaul of NixOS to come out?
I suspect theoretically it's not necessary, but wondering if NixOS will be
tracking this Nix release in some way shortly... Anyone know?

~~~
pxc
I upgraded my personal laptop to NixOS 18.03 (currently still nixos-unstable;
the release branch hasn't been cut) a week ago and I've had no problems

You can switch which version of Nix you're using whenever you want, and you
can install multiple versions of Nix side-by-side if you want to, just like
with any other package. To install Nix 2.0 on an older release of
Nixpkgs/NixOS, just use the package `nixUnstable`. You can install it with
`nix-env` if you want to try it out right now.

The only real differences between a typical upgrade and upgrading between
releases are:

1\. You'll need more storage space for the course of the upgrade, because most
of your dependencies have been updated.

2\. You might have to change your config up a little, because a few packages
have been removed, renamed, or are out of date.

You still get all the nice rollback features that you're used to, and if Nix
1.x is part of your old system profile and 2.0 part of your new one, when you
roll back, Nix will roll back, too.

To more directly answer your question: NixOS 18.03 will indeed include Nix
2.0.

~~~
TremendousT
Thanks.

Is there any idea about the release date for 18.03 (or 18.0X, whatever is 2.0
based)?

~~~
pxc
.03 means March, and that's as much as I know.

~~~
mysticmumble
More precisely end of march: [https://groups.google.com/forum/#!topic/nix-
devel/9sps8NLdwI...](https://groups.google.com/forum/#!topic/nix-
devel/9sps8NLdwIY)

------
bfrog
It looks like they're at least attempting to work towards user friendliness,
which is by far my biggest complaint.

My other big complaint is that when something goes wrong its damn near
impossible to figure it out. Trying to figure out why I couldn't get postgres
working with postgis was nightmarish last year sometime when I last tried
nixos.

I'm still really optimistic that this will someday replace arch for me. I just
don't know _when_

------
thomastjeffery
Finally, a better command-line interface!

Hopefully, this means I can stop using the website search for packages.

~~~
Filligree
Have you tried the 'nox' package?

------
thinkpad20
As a nix user for several years this is pretty exciting. I hadn’t been
following the 2.0 development, but I was really hoping to see a mention of
support for something like a .gitignore equivalent when hashing directories
from the filesystem. Seems that that isn’t in this release :(

~~~
lukego
Have you seen the library function cleanSource() and related routines? I use
these for excluding files (e.g. by filename extension) from being visible in
builds. This might suit your use case too.

[https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix](https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix)

~~~
thinkpad20
Yeah, and I use cleanSource, but I find it to be pretty obtuse and full of
edge cases.

------
canadaduane
That's a really impressive list of contributors. 99 if I've counted correctly.

------
tarruda
It appears that by using a CoW filesystem like Btrfs I can have some of the
same advantages of using Nix:

\- Parallel installation of multiple OSes sharing the same storage pool

\- Snapshot/rollback

How does using Nix compare to using a CoW filesystem such as Btrfs or Zfs?

~~~
rekado
The main difference is that functional package management lets you _declare_
the system state. Free rollbacks are a consequence of being able to fully
describe the system state.

With a file system the storage pool is dumb and all meaning of higher-order
abstractions (such as packages) is lost.

You don't use functional package management _just_ for deduplication, but in
order to be able to declare and reason about state.

(I work on Guix, which is an implementation of functional package management,
but with different abstractions.)

~~~
michaelmrose
What are the advantages of guix vs nix?

~~~
rekado
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, sablevm, 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 GNU. 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, 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 reading SICP); 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.

Let me end with a comment that's actually on topic for the original post:
Congratulations on the Nix 2.0 release! Long live functional package
management!

------
Ixiaus
Very exciting release notes. Nix is great and this makes it even better.

------
eridius
How do I upgrade my existing Nix installation? After updating the nixpkgs-
unstable channel, nixpkgs.nix is still 1.11.16 (and nixpkgs.nixUnstable is a
2.0 pre-release).

~~~
matthewbauer
Look up channels status here:

[http://howoldis.herokuapp.com](http://howoldis.herokuapp.com)

It will prob take like 5 hours to be updated. Run nix-channel --update then
reinstall nix.

~~~
eridius
Would it be safe to run `curl
[https://nixos.org/nix/install](https://nixos.org/nix/install) | sh` (safe as
in it won't screw with my existing installed packages), and if so, will that
get me Nix 2.0? Or do I still have to wait for nixpkgs-unstable to rebuild?

~~~
thomastjeffery
If you already have Nix installed, what you want to do is change the channel,
and do an upgrade.

~~~
eridius
Change the channel to what? It's already on nixpkgs-unstable.

~~~
HIPisTheAnswer
nix.package = pkgs.nixUnstable;

------
alexashka
This looks really nice.

For basic users who have a DigitalOcean droplet with Ubuntu, to run a web
server - how does this compare?

~~~
FreedomWarrior
To do a car analogy (this is Slashdot, right?):

With Ubuntu, every time you want to fix something with your car, you roll it
into the garage, pop open the hood and get to work. It's intensive labour,
results will vary, and undoing a change can be really difficult.

With NixOS, it's like 3D printing a new car every time. You'll design a model,
press a button, and the car gets built from scratch. If you don't like it,
tweak the design a bit, and print a new car. If the new car breaks, just go
back to the previous known-good one, which is already in your garage. You can
even take the design documents to your friend and generate an exactly
identical model.

~~~
rlpb
> With Ubuntu, every time you want to fix something with your car, you roll it
> into the garage, pop open the hood and get to work. It's intensive labour,
> results will vary, and undoing a change can be really difficult.

You can do it that way, but I wouldn't recommend it. If your Ubuntu system
becomes that way, it has become unmaintainable.

All modern server deployment methods describe the deployment in code so you do
"print a new car" every time you change something. This includes Ubuntu.

On the desktop, you largely don't need to pop open the hood at all. If you
find yourself doing that, you have yourself an experimental system and not
production system.

~~~
majewsky
> On the desktop, you largely don't need to pop open the hood at all.

So you're not installing updates on desktop machines at all? That sounds
incredibly dangerous.

~~~
rlpb
Huh? No. Updates ship as part of Ubuntu. From your perspective, updates
happen. You don't need to pop open the hood at all to get them.

~~~
michaelmrose
Unfortunately sometimes you do need to pop open the hood to see whats going
on. Regarding ubuntu or rather its derivative mint for example I had to fiddle
with xorg.conf to allow me to manually set the fans on a card because the
desktop was overheating even with reasonable cooling in a small apartment with
no ac in the middle of summer.

In case you didn't know nvidia driver doesn't let you manually set the fan
without enabling this in xorg.conf or drop a file in /etc/X11/xorg.conf.d Not
knowing about xorg.conf.d at the time I merely set xorg.conf and was very
confused to find that it continued to overheat and further that my file was
not modfified but gone. This happened periorically seemingly at random.

Turns out their driver manager mints gui for installing proprietary drivers
had installed the optimus package to enable a laptop with dual gpus to work
properly on a desktop and that the post install script for this package was
helpfully removing /etc/xorg.conf every time it was run when said useless
package was updated.

Moving the snippit to xorg.conf.d was helpful as was finding and removing the
useless package but we are still looking at an issue on a relatively recent
machine that couldn't be fixed without grep and a xorg config file in a recent
version of a ubuntu derivative.

