
What is Nix and why you should try it - vletrmx
https://yakking.branchable.com/posts/what-and-why-nix/
======
dhruvio
I can vouch for the immense improvement Nix has made to my software
development process. I use NixOS on my desktop and laptop. At the OS-level, it
gets a lot of things right: reproducible, immutable system configs;
lightweight containers; devops with declarative configs. At a software project
level, nix-shell is an indispensible tool. Compilers and interpreters aren't
even part of my system-wide config; instead each project has it's own
shell.nix file that installs all dependencies I need on the fly without
polluting system state or virtualization. Nix is a god-send, and the
developers that contribute to it are nothing short of awesome!

The area that needs improvement is the documentation. Once you learn the Nix
language, reading the source code is pretty helpful, but it would be nice to
make it more approachable. For example, the nixpkgs repo has a bunch of Nix
helper functions that are useful to developers when writing their own
packages, but these functions' documentation is either buried in a long
manual, or non-existent.

~~~
nerdponx
_these functions ' documentation is either buried in a long manual_

This is a problem with lots of feature-rich software, even with meticulously-
documented APIs. What we need is _reverse-indexed_ documentation. That is, an
extensive API reference is only useful for someone who already knows what
functions are in the API and just needs to remember how to use them. But even
the most thorough API reference does nothing to promote _discovering_ new
functionality. This is often left to the authors, who then have to go about
writing a User's Guide that gradually explains concepts, idioms, etc. in
prose.

Thorough User's Guides are rare because they are tough to write, and even
tougher to write well. Users don't often have the time to read through
potentially hundreds of pages of prose to find what they're looking for. We
need a better way to let users search or browse for _concepts_ , and then be
given a list of the functions that implement each concept.

That is, addition to documentation like:

    
    
        size_t strlen(const char * s);
          RETURN: Length of string s.
    
        size_t strnlen(const char * s, size_t maxlen);
          RETURN: Length of string s, or maxlen (whichever is smaller).
          NOTE: Stops reading after maxlen.
    
        char * stpcpy(char * dst, const char * src);
          Copy src to dst.
          RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL.
          NOTE: Undefined behavior if dst and src overlap.
    
        char * stpncpy(char * dst, const char * src, size_t len);
          Copy up to len bytes from src to dst.
          RETURN: pointer to trailing '\0' of dst, or dst[n] if no trailing NUL.
          NOTE: Undefined behavior if dst and src overlap.
    
        char * strcpy(char * dst, const char * src);
          Copy src to dst.
          RETURN: dst.
          NOTE: Undefined behavior if dst and src overlap.
    
        char * strncpy(char * dst, const char * src, size_t len);
          Copy up to len bytes from src to dst
          RETURN: dst.
          NOTE: Undefined behavior if dst and src overlap.
    

We also need to be able to "tag" functions. So we might have the following
tags that allow us to search for _concepts_ :

    
    
        strcpy
          TAGS: "concept":"data type":"text", "concept":"attribute":"length",
                ".input":"array", ".input":"char", ".input":"pointer",
                ".return":"string", ".return":"pointer"
        strncpy
          TAGS: "concept":"data type":"text", "concept":"attribute":"length",
                "concept":"data type":"array":"max-length operator",
                ".input":"array", ".input":"char", ".input":"pointer",
                ".return":"array", ".return":"pointer"
    

And a tag browsing page that looks like

    
    
        concept
        └─ data type
           └─ text
           └─ array (conceptual)
              └─ max-length operator
        └─ attribute
           └─ length / size
        data structure
        └─ char
        └─ array (implementation)
        └─ pointer
        

Which the user could then scan, and identify keywords to search for:

    
    
        '"concept":"data type":"text" AND "concept":"attribute":"length"'
    

And be given "strlen" and "strnlen" as the top two hits, followed by "wcslen"
and "wcsnlen".

It seems like a PITA at first, but I'm pretty sure tagging functions in their
docstrings is easier than writing a whole new User's Guide.

~~~
neilparikh
One great approach is the Hoogle search engine for Haskell [1]. The idea with
that is that you search by type, instead of name. So if you were looking for a
function to take a item, and return a list with n copies of that item, you
would search for `a -> Int -> [a]`, which would give you back replicate.

Looks like the Nix expression language is untyped, so this wouldn't work
directly, but maybe adding a rough type signature in the docstring would get
some of those benefits (and it should be a bit better for discover-ability,
since you wouldn't need to guess the same tags/concept the author choose).

[1] - [https://www.haskell.org/hoogle/](https://www.haskell.org/hoogle/)

~~~
tonyg
Some Smalltalks (Squeak and Pharo) have a wonderful tool called a "Method
Finder".

The way it works is you write a sequence of _arguments_ and an expected
_result_ , and it suggests a method to call.

For example, I just now tried it, entering

    
    
      3. 4. 7
    

in the input. It suggested the following methods:

    
    
      3 + 4 --> 7
      3 bitOr: 4 --> 7
      3 bitXor: 4 --> 7
    

Clicking on any of these opens a browser on the class and method concerned.

Another example: input of

    
    
      'hello world'. #('hello' 'world')
    

yielded the single suggestion

    
    
      'hello world' substrings --> #('hello' 'world')
    

Another:

    
    
      '  abc  '. 'abc'
    

yields

    
    
      '  abc  ' asLegalSelector --> 'abc'
      '  abc  ' withBlanksTrimmed --> 'abc'
    

;;--

It's a total hack, of course, but none the less effective or useful for that.

It has a list of methods marked "safe to experiment with", and simply tries
them out.

It gets a big boost from being able to evaluate the receiver (the first in the
input list) to a concrete object, and then only consider methods on that
object's class.

~~~
nerdponx
That's pretty cool. Is the technique for this documented somewhere, or do I
have to read the Squeak or Pharo source?

~~~
terminalcommand
I've looked into it a bit. Visualworks smalltalk documentation gave me an
idea[1].

In Smalltalk everything is an object, that is including numbers, characters
etc. The standar method-lookup searches from the innermost class methods to
the outermost class methods.

The method finder could simply iteratively go through all applicable methods
that return the class requested and match results.

[1]: [http://esug.org/data/Old/vw-
tutorials/vw25/vw25ug.pdf](http://esug.org/data/Old/vw-
tutorials/vw25/vw25ug.pdf) (page 42 method-lookup)

------
SideburnsOfDoom
That article on "What is Nix and .. " does not contain the words "Nix is a..."
A quick read gave a vague sense that it was about installs and file paths so
maybe something package-related? Nothing definite.

If you click through to [https://nixos.org/nixos/nix-pills/why-you-should-
give-it-a-t...](https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-
try.html)

you will see "Nix is a purely functional package manager and deployment system
for POSIX"

~~~
sundarurfriend
I get the feel that Nix does something like what virtualenv does for python,
but more generalized to make that work for other software. Is that
approximately right?

~~~
aws_ls
Yes, I also was immediately reminded of Python's conda based environment
management. E.g. 'source activate <env1>' may have python3 but when used with
<env2> will use python2 and different version of other libraries.

------
rhn_mk1
My experience with Nix was a real pleasure, and a complete failure.

I set out with the goal of building a development environment for a software I
was working on. I thought - Nix sounds like a better Docker, where it's
possible to choose package versions independently of the rest of the system.
It's perfect for testing!

I found the package description language refreshing - it was powerful without
getting _too_ complicated. Over the course of a couple of days I was able to
adapt a few packages and create my own too, with the build environment.

It was almost finished, but the last problem remained: installing CUDA and the
userspace portion of the Nvidia driver. It's not rocket science – I thought –
all I need is a few .so's, it even works with Docker.

Alas, after battling Nix for another couple of days, trying to use generic GL,
installing the Nvidia one, ignoring it altogether or trying to using the host
version - I gave up. I found no way to build a package linked against OpenGL
that would actually work.

Despite that, I hope to use Nix with a different project in the future.

~~~
ris
Although other people have different opinions to me, I don't really see Nix as
something for the desktop, but for development, deployment and server software
it's a killer solution for me.

~~~
Filligree
None of what he mentioned was desktop-specific. GPUs are useful, and if CUDA
is involved then it's being used for acceleration of some kind, which can
perfectly well be done on servers.

I agree that Nix is hard to deal with when it comes to binary distributions of
any kind, which includes CUDA.

~~~
tome
> I agree that Nix is hard to deal with when it comes to binary distributions
> of any kind, which includes CUDA.

That's really interesting to me. Why is a binary package not considered a
source package where "compiling" it is a no-op?

~~~
Filligree
It's a problem of altering the embedded paths to point at the nix store. There
are some tools for doing that -- patchelf, etc. -- but it's far more difficult
to get all that right than to compile from source.

A source package using autoconf will, in general, just work. A binary package
always needs extra work.

------
jf
I'm very excited about Nix and the possibilities that it opens.

If you want to learn more about Nix, I suggest starting with this excellent
article on InfoQ: [https://www.infoq.com/articles/configuration-management-
with...](https://www.infoq.com/articles/configuration-management-with-nix)

I also gave a talk about why I think Nix is so great:
[https://vimeo.com/album/4676161/video/223525975](https://vimeo.com/album/4676161/video/223525975)

Finally, I highly recommend the PhD thesis that Nix is based on:
[https://nixos.org/~eelco/pubs/phd-
thesis.pdf](https://nixos.org/~eelco/pubs/phd-thesis.pdf)

------
Jeaye
I recently wrote about my experience using NixOS on my VPS [1]; it's truly a
very different way of approaching systems administration and Nix is at the
heart of it. While I think the Nix expression language has a negative impact
on usability, Nix still ends up being a net gain for not only entire OSs, but
also reproducible environments for packages on many other OSs.

1: [https://blog.jeaye.com/2017/07/30/nixos-
revisited/](https://blog.jeaye.com/2017/07/30/nixos-revisited/)

~~~
afarrell
Oooh! Thanks for linking this write-up. I've been thinking of playing around
with Nix and basically only be able to do it on a VPS.

Before I get started though, what things could I consider implicit
prerequisites of running Nix? For example: I've never built a Debian or RPM
package. Would I be better served gaining some background in OS package
management before diving into this?

~~~
Filligree
Most of what you'd learn playing with other OSs, you'd need to unlrearn to
work with Nix. So... nothing much really.

Read the Nix Pills series, that'll teach you more than any amount of playing
with non-Nix software.

~~~
afarrell
Thanks!

[https://nixos.org/nixos/nix-pills/](https://nixos.org/nixos/nix-pills/) for
others

------
jingwen
On my macOS work machine, Nix has replaced Homebrew. The ability to switch
between generations of your system state [1] when a new install goes awry is
underrated, IMO.

[1] [https://nixos.org/nix/manual/#sec-
profiles](https://nixos.org/nix/manual/#sec-profiles)

~~~
j_s
Why not both? Does Homebrew conflict with Nix in such a way that only one is
possible at a time?

I can definitely see giving Nix priority for work-related development, but I
would like to know if Homebrew can still fill in as a backup option.

~~~
pfranz
I've installed both without issue. It might be a headache long-term because of
libs and installing things in both systems, etc. Just make sure you know which
comes first in PATH.

------
georgewsinger
We used Nix to vastly simplify the build process of Simula:
[https://github.com/SimulaVR/Simula](https://github.com/SimulaVR/Simula)

Simula is a bleeding edge VR Desktop project for Linux; virtually all of its
dependencies are highly novel and require building from source for almost any
distro. Nix allowed us to reduce the effort to building our project from 1hr
of sifting through build documentation to a single build command.

Nix's only issue is that it so far can't handle OpenGL dependencies very well.
I'm not sure if this is something in principle it cannot handle, or if it just
hasn't been done yet. I'm praying it's the latter.

~~~
joepie91_
So, OpenGL is a bit of a weird case.

Hardware is the one thing that actually varies between systems no matter how
declarative your configuration is - this is normally not a problem, since the
kernel abstracts it away.

The problem with OpenGL, then, is that every graphics driver provides _its own
set_ of OpenGL libraries that is subtly different from all the others. This
means that applications need to be built against a specific set of OpenGL
libraries from a _specific_ graphics driver, and the kernel is of no help
here.

That's fundamentally where the OpenGL issues come from; Nix packages typically
expect the libraries to be semi-statefully provided in a `/run` directory.
This gets especially hairy when targeting different distros.

EDIT: And because the package doesn't know what graphics drivers it'll be
running against on non-NixOS, it can't automatically build against a copy of
the correct drivers in nixpkgs either.

~~~
jancsika
Does the Guix choice of a more expressive language for defining the packages
help here?

~~~
arianvanp
No. I think both languages are equally expressive in the end (though one will
be a bit uglier than the other). But the problem is probably less big in Guix
because only a few graphics drivers are actually supported due to the fact
that all the drivers needs to be Free and free of binary blobs.

~~~
rekado
> But the problem is probably less big in Guix because only a few graphics
> drivers are actually supported due to the fact that all the drivers needs to
> be Free and free of binary blobs.

This is a property of Linux libre, not of Guix per se.

------
austinl
I recently wrote a blog post about how we use Nix at Pinterest (just the
package manager, not the OS). It helps us give all developers and CI an
identical environment. On iOS, we run most build commands and other tools
through the nix-shell. New engineers set up their environment by just running
a script that installs nix and enters the shell.

[https://medium.com/@Pinterest_Engineering/continuous-
integra...](https://medium.com/@Pinterest_Engineering/continuous-integration-
for-ios-with-nix-and-buildkite-ef5b36c5292d)

------
ldlework
I have recently started looking into Nix to solve the problem of dotfile
deployment to new OSX workstations. When you get a new laptop, you clone your
dotfiles, maybe symlink them to your home directory -- and then what? Nix
solves this problem for me by coupling my dotfile deployment with the
installation of the related software.

The learning curve has been absolutely tremendous, however. That said, the
support on Freenode has been some of the best I've encountered in more than a
decade.

[https://nixos.org/nix/manual/#chap-package-
management](https://nixos.org/nix/manual/#chap-package-management)
[https://rycee.net/posts/2017-07-02-manage-your-home-with-
nix...](https://rycee.net/posts/2017-07-02-manage-your-home-with-nix.html)

~~~
k__
Nice. I started using macOS 5 months ago and it felt a bit as a step back
coming from Linux.

Does Nix work good with macOS?

~~~
kccqzy
I should mention that on High Sierra there’s a bug with kill(-1, ...) that
sometimes causes Nix builds to lock up the whole system.

~~~
wmertens
Also, the OS X windowmanager has a memory leak and you have to resart every so
often. Yesterday mine was 22GB and after restart <100MB… Nothing to do with
Nix, just venting ;-)

~~~
tejasmanohar

      you have to restart every so often
    

I've never had that happen. Maybe things that don't have to do with Nix...
really just don't have to do with Nix ;-)

------
johnramsden
I switched from Arch Linux to NixOS last year and it was a great experience
[https://ramsdenj.com/2017/06/19/switching-to-nixos-from-
arch...](https://ramsdenj.com/2017/06/19/switching-to-nixos-from-arch-
linux.html). The community is relatively small and easy to get into, with lots
of people ready to help out beginners.

It took a while to get used to, especially considering the way to learn how
something works seems to always be to go and read source code on GitHub. There
are good things and bad things about this approach but I fear it makes it
difficult for your average user to use since it is a bit of a barrier to
entry.

I loved how extensible the system was, and how easy it was to make
modifications simply by modifying configuration.nix. It made it really feel as
though my system was truly 'mine', in some ways being similar to the feeling I
get from setting up an Arch machine. Being able to just recreate a machine by
cloning your configuration onto the new machine, and running 'nixos-rebuild
switch' is extremely powerful. Being able to roll back machine is also
amazing. Something else that really impressed me was how great though ZFS
support was. Setting up a ZFS system on Nix is one of the best experiences
I've had using ZFS on Linux. It really feels as though ZFS is a first-class
citizen on Nix, not something tacked on top. It's possible to set up ZFS
without adding any sort of external repository like with Arch.

I ended up leaving NixOS after running into an issue that I would get related
to UEFI, and at that point didn't have the time to track down the problem, but
I'm really excited for where NixOS is going in the future, especially when
declarative user environments
[https://github.com/NixOS/nixpkgs/pull/9250](https://github.com/NixOS/nixpkgs/pull/9250)
(user configuration) with NixUP becomes a thing. I will definitely be coming
back to it in the future.

~~~
CyberShadow
If you're using Arch Linux now, you may find this project useful:
[https://github.com/CyberShadow/aconfmgr](https://github.com/CyberShadow/aconfmgr)

------
k2enemy
I'm a big fan of Nix, but I really with there was a declarative way to define
a user's environment similar to what NixOS has with
/etc/nixos/configuration.nix.

It seems a little strange to me to have a functional package manager, but an
imperative package install process. I think there are a few projects like
NixUP and home-manager that are looking to address this, but I'm hoping Nix
will provide an official way to do it.

~~~
johnramsden
It's coming:
[https://github.com/NixOS/nixpkgs/pull/9250](https://github.com/NixOS/nixpkgs/pull/9250)

~~~
clhodapp
That's a bit too strong a statement to make based on a two-year-old still-open
PR with an uncertain future. It seems like it _might_ be coming _at some point
in the future_.

~~~
johnramsden
No, there's actually a fair bit of activity around it, if you read through the
comments in the pull request it has a fair bit of activity.

They recently got a fair bit of interest on the mailing list
[https://goo.gl/kvNwC1](https://goo.gl/kvNwC1) and raised some money for it as
well
[https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-3208...](https://github.com/NixOS/nixpkgs/pull/9250#issuecomment-320860635).

I'm pretty sure I read somewhere that it's planned to go in the next release.

------
Animats
Every problem in computer science can be solved by adding another layer of
indirection. Except too many layers of indirection.

------
CMCDragonkai
For those new to NixOS, the default package installation method is through a
concept called channels. It can be a bit confusing reconciling the nature of
channels and the real strength of NixOS which is functional reproducibility. I
wrote a blog post explaining what channels really are and an alternative which
is to use Git commit hashes instead [https://matrix.ai/2017/03/13/intro-to-
nix-channels-and-repro...](https://matrix.ai/2017/03/13/intro-to-nix-channels-
and-reproducible-nixos-environment/)

------
kaushalmodi
I do pretty much that using GNU Stow. Of course I then build packages and
libraries on my own, in my $HOME, because I don't have root access on that
machine.

I install any PACKAGE of version VERSION in:

    
    
        ~/stow/pkgs/PACKAGE/VERSION/
    

So taking nim for example, I'd have:

    
    
        ~/stow/pkgs/nim/0.17.1/
    

Under that, I'd have the whole FHS system for __just __nim 0.17.1:

    
    
        ~/stow/pkgs/nim/0.17.1/bin/
        ~/stow/pkgs/nim/0.17.1/lib/
        ~/stow/pkgs/nim/0.17.1/share/
    

I set ~/stowed/ as my STOW_TARGET. So on running stow, symlinks to all:

    
    
        ~/stow/pkgs/PACKAGE/VERSION/{bin,lib,share,..}/..
    

get created in:

    
    
        ~/stowed/{bin,lib,share,..}/..
    

I then have aliases set up to do something like "unstow PKG/OLD_VER" and
"restow PKG/NEW_VER" when I want to change the package version.

I skip the "restow" step if I just want to "soft uninstall" a package i.e.
remove it from PATH, PKG_CONFIG_PATH, MAN_PATH, .. by removing it only from
the STOW_TARGET ~/stowed.

"Hard uninstall" would be simply:

    
    
        \rm -rf ~/stow/pkgs/PACKAGE/VERSION_I_DONT_WANT/
    

Or even:

    
    
        \rm -rf ~/stow/pkgs/PACKAGE_I_DONT_WANT/

------
cstrahan
A copy of what I commented on the blog:

Nice post, and I'm glad you're enjoying NixOS!

I'm a NixOS contributor/committer, and the principle author (and co-
maintainer) of the Bundler-based packaging integration. If you or anyone
reading this has any feedback and/or questions about NixOS and Ruby (or NixOS
in general) feel free to shoot me a message. I idle on #nixos on Freenode (as
cstrahan), and you can email me at charles {{at}} cstrahan.com.

Cheers!

-Charles Strahan (cstrahan)

------
pradeepchhetri
Recently, I got the opportunity to play with Nix. To me, it felt to be a very
nice way to bundle the dependencies along with the application. But there are
few questions which always come to my mind were - how people run it in
production. Can they achieve all the things (eg monitoring, debugging..)
easily just like the app hosted on a linux machine ?

~~~
jitl
Sure? It’s still Linux underneath and all the same skills and strategies carry
over.

~~~
pradeepchhetri
Thank you, I definitely need to play with it more to understand it better.

------
marcinkuzminski
RhodeCode is one of projects that build their installer on top of nix package
manager. Check out this blog post: [https://rhodecode.com/blog/61/rhodecode-
and-nix-package-mana...](https://rhodecode.com/blog/61/rhodecode-and-nix-
package-manager)

------
dim-an
Is there a way to install nix into home folder (suppose I don't have sudo on
server). I spend some time recently trying to setup nix in such environment
and failed. I ended up compiling recent versions of neovim and tmux myself.

~~~
pfranz
Yes and no (mostly yes). Ideally, you have /nix/ where everything gets
installed, then folders with symlinks in your homedir (one that builds your
workspaces and another that versions them) with an environment variable in
your bash_rc to hook you in.

You can put that /nix folder anywhere, but you can no longer use their binary
package caches and it will recompile everything. This is because they hard-
code paths for dependencies during build time.

------
Annatar
_what would happen if we want to install, for example, two different versions
of ruby at the same time?_

This is treating the symptom instead of the root cause, that being ineptitude
to design backward-compatible software. We as an industry should fight such
band aids and take a stand. Yes, designing backwards compatible software is
hard, but exactly that is the difference between engineering and amateurism.
And if one is getting paid to program, I’m going so far as to argue that it’s
one’s job to have their head hurt solving such difficult problems so that
users of computers don’t have to.

------
hyperion2010
Sounds like a similar solution to gentoo's slotted ebuilds [0]. Switching the
'default' implementation system wide or per user (eselect) has the same issues
discussed. Not sure if there is an existing utility (beyond your standard
shell script) that can produce sane per-shell environments.

0\. [https://devmanual.gentoo.org/general-
concepts/slotting/index...](https://devmanual.gentoo.org/general-
concepts/slotting/index.html)

~~~
ben0x539
Mhm, doesn't sound all that similar to me. This looks like something that
needs to be maintained on a per-package basis as a fairly ad-hoc solution for
different library versions, in Nix the whole thing just falls out of the way
it's set up in general.

------
distantsounds
Gobolinux does something similar, and has been around for years:
[https://www.gobolinux.org/](https://www.gobolinux.org/)

~~~
infinisil
Funnily enough, NixOS has had its initial release in the same year as
Gobolinux, 2003.

I'm not sure how Gobolinux organizes files exactly, but with NixOS, the hash
in /nix/store/<hash>-packagename is produced by combining every input that
might influence the package. By input I mean for example:

\- The source: git revision / source url / etc.

\- All dependencies, which means if a dependency of a dependency of this
package changes, it gets a new hash

\- Build instructions, including build flags

This wouldn't be possible with a more conventional file structure.

------
j_s
Just a heads-up in case anyone is confused as I was: Nix is not 100% bit-for-
bit deterministic/reproducible yet, though they do deliver functional
equivalence.

~~~
FrozenCow
There are efforts to get deterministic builds in NixOS, but it comes with
downsides like very high build times.

~~~
sly010
Can you elaborate? I always thought deterministic builds would enable faster
builds (because it would basically allow for downloading and verification of
binaries).

~~~
wmertens
As an example, gcc includes code generators that try a few random things in
order to optimize code. So two builds, on the same system, won't result in the
same byte code.

Also, build stamps like time, PID, path etc.

------
infinitebyte
Software Collections
([https://www.softwarecollections.org/en/](https://www.softwarecollections.org/en/))
give you the power to build, install, and use multiple versions of software on
the same system, without affecting system-wide installed packages. Is this
what Nix OS is able to do? Install multiple versions of software and select
which version to use before running?

------
pknopf
I have used NixOS. It's fustrations led me to develop this.

[https://github.com/pauldotknopf/darch](https://github.com/pauldotknopf/darch)

It is essentially Docker, but you can boot bare-metal with it. It even uses
Docker under the hood.

Every boot is a fresh boot. You can read-write during boot, but all changes
are made to ram. You mount with fstab things you want persisted, like home.

~~~
icebraining
Interesting. Isn't that essentially a livecd? Have you considered using
Archiso? If so, what do you see as the advantages of darch?

~~~
pknopf
Archiso/etc are similar, but that lack some things.

\---

Layering

\----

I can change my inherited build without rebuilding everything.

For example: base > xorg-nvidia > plasma > homepc I can easily switch desktop
environments by making "homepc" inherit "i3", or w/e.

Each layer is essentially a "Dockerfile". If you understand docker, you
understand how the images are built and managed.

\---

Fast switching.

\---

I can create images for different dev environemnts/clients. I can create an
image purely for gaming. I can create an image steam.

Darch integrates with grub, so entries will dynamically show up on boot.

\---

Sharing with DockerHub.

\---

Sharing with other machines (and other people).

Since they are docker images, I can easily upload them to DockerHub.

I can update my local build by doing "docker pull && darch extract && sudo
darch stage".

I will soon setup Travis-CI to auto build and push to DockerHub. Then, I never
have to build locally. A cron job will queue a build every few days to make my
image "rolling". I can easily revert back to previously working docker images
(all tagged by date).

~~~
icebraining
Thanks!

------
c3534l
I'm gonna need a better reason to switch distros than that. I do think that is
an improvement that needs to be adopted in the OS. But, I mean, it's not that
much of a improvement over containers. I don't feel like it gives me, the
user, that much more power over the OS and would be a feature that I would
only use very rarely.

~~~
infinisil
The blogpost just highlights one nice aspect of it, there's more though:

\- The really powerful NixOS module system, which let's you specify your
system declaratively and rather simply: Which programs should be installed,
what systemd services should run, use grub for booting, allow this ssh key to
login to this user, enable the IPFS daemon, etc. All options (for the 17.09
release) are available here:
[https://nixos.org/nixos/options.html](https://nixos.org/nixos/options.html)

\- System generations: Upon changing an option in your system config, you run
`nixos-rebuild switch` which will build, activate the new system and add it to
the system generations. All of these are bootable from your bootloader! So if
something breaks miserably, you can just rollback to a previous one that
worked. New kernel breaks on your hardware? No problem, just roll back.

\- If you have a new nixos machine, you don't need to run a bunch of odd
commands to have it set up. Since the config is declarative, everything you
set up is right there, and all you need is a `nixos-rebuild switch` to make it
work.

\- Wanna test some configuration but are too afraid to use your machine? Just
build a VM with it by doing `nixos-rebuild build-vm`. Like with everything
else with nix, this fetches all dependencies, no need to install them
manually.

------
stylishmunda136
That's a bit too strong a statement to make based on a two-year-old still-open
PR with an uncertain future.
[https://socialworldblog.com/](https://socialworldblog.com/)

------
konschubert
So, it's like virtualenv, but for all software and not just Python?

~~~
pfranz
Kind of. You can version your workspace, too. Updates are basically atomic.
You build the new workspace (with updated versions), then under the hood it
just moves a symlink to the new version.

It's got some clever fundamentals that allow for really cool (and clean)
features because of it.

------
bfrog
Nix is pretty cool but has some significant usability issues.

~~~
philipov
Having never used Nix before, I would like to know what kind of usability
issues it faces.

For me, the biggest one is that I can't use it at clients running a Windows
shop. That's a blocker.

~~~
nextos
I think biggest ones are i) nix command is a bit complex, but it's getting
redesigned [1] & ii) nixpkg definitions sometimes contain a lot of cruft.

I've found Guix and GuixSD, which are a GNU-blessed Guile Scheme-based
reimplementation of Nix and NixOS, more aesthetically pleasing. Quite simple
and elegant in fact.

The major differences are that Guix DSLs are implemented on top of Scheme,
whereas Nix uses a custom DSL. Furthermore, Guix avoids systemd and uses GNU
herd instead.

[1]
[https://github.com/NixOS/nix/issues/779](https://github.com/NixOS/nix/issues/779)

~~~
gcoda
For my practical reasons I can not use pure GNU distributions, I am not aware
of easy community way to re use packages for other distro or something hacky
like that. Not everyone have brainpower and time to build custom packages for
rare distro, it is a shame, I really like Guix. NixOS got some recepies for
using not 100% libre software.

~~~
jitl
This is also what keeps me away from Guix. I get that there are third-party
repos with non-free software, but using a fringe package of a fringe packager
is too far for me.

There’s no good choice here: Nix package definitions and tools are inscrutable
and user-hostile; and the alternative Guix is burden with GNU/free software
zealotry and GPL.

A somewhat comparable third option is Habitat, from Chef. It also has a pure
build system, a package source, and pure, discrete environments. But it’s also
got a bunch of service orchestration parts...

Hopefully the Nix redesign will make the tools more palatable for mortals.

~~~
nextos
What kind of non-free tools are you missing from Guix?

The only notable omission is linux, as Guix is based on linux-libre instead.
But changing this is a matter of 1 LOC.

~~~
thomastjeffery
> But changing this is a matter of 1 LOC.

And how difficult is it for a new user to find that line?

------
_ibu9
Nix the package manager is great. Poorly documented, but it works as expected.
I've also had uneventful experiences using NixOS on a server.

On the other hand, trying to use NixOS on my laptop has been struggle after
struggle. Every update breaks something. Many times updates cause the entire
system to crash. Different combinations of display managers, window managers,
and various system level daemons interact in complex ways.

None of this is the fault of NixOS, really it is the fault of the Unix
philosophy scaled to the level of the desktop Linux ecosystem, combined with
the traditional assurance on upstream developers that packagers in distros
like Ubuntu will fix their shit.

What would be really great for NixOS would be a set of various well tested
base configurations for the various DE/WM combos, like all the spinoff Ubuntu
distros. These would fix the versions of all the fragile graphical components
on some kind of release schedule, while probably still using nixos-unstable
underneath for all the relatively reliable stuff like the kernel, emacs, vim,
coreutils, etc.

~~~
matthewbauer
Yes, this is something that I think is really important in the future. NixOS
really needs something like Ubuntu is to Debian or Manjaro is to Arch. Lots of
polishing that a standard Linux user can start using out of the box (no
instructions required).

------
amelius
Python solves this problem with "virtualenv", where the user creates a virtual
environment and installs all programs and libraries into that environment. The
user can have multiple virtual environments, and it is easy to switch between
environments.

~~~
pfranz
virtualenv solves virtual environment as much as pip solves OS package
management. Not that it's not useful, but you see all over where you have
little fiefdoms that work pretty well for their little ecosystem, but become a
mess if you integrate stuff outside (virtualenv, rbenv or pip, npm, gem, rpm,
apt or make, ant, scons, jam).

A lot of these systems are just reimplementations tailored to language-X. Nix
is pretty unique and clever. For example, you can effectively version control
you virtual environment, it's at the OS level, and accommodates major
languages and libraries (Python, Perl, Lua, Java, Go, Qt).

------
zzzeek
"To deal with this nix provides the nix-shell utility which constructs an
environment on demand and runs a new shell based on that environment."

I'm sure nix is cool but this sort of sounds like something we just end up
using docker for these days (for better or worse).

~~~
zzzcpan
Yes, Docker is a competing solution. Hopefully in the future we will see a
better one, more nix-like.

~~~
Crespyl
Does Docker actually compete with Nix?

It seems that Docker is more concerned with containment and Nix with packages.
I would love to be able to use Nix to define my project+dependencies and
Docker to run it.

I'd be surprised if someone hasn't already made a baseline NixOS docker image
to build off of.

