
What Is Nix? - elsewhen
https://engineering.shopify.com/blogs/engineering/what-is-nix
======
nilkn
This article is a good explanation of how nix works at a high level, and I'm
excited to see nix getting some really prominent support, but for some reason
it never tells you what the point of all of this is, so I think many folks
might feel turned off by it. In other words, I don't believe it ever
compellingly answers the question that constitutes its title. The word
"package" doesn't even appear until near the end of the article! This is
probably a second or third article to read about nix rather than the very
first thing that exposes you to it.

The point of nix is just to create completely reproducible builds and package
management, including support for multiple versions of packages side-by-size
with no issues. It's sort of a next-generation package management system that
tries to avoid most of the pitfalls that OS package managers have fumbled with
up to this point. It's really that simple.

"nix" as a term refers to a system of multiple components that work together
to achieve that goal. There's the package manager itself (called Nix), the
language that build instructions are written in (also called Nix), an existing
ecosystem of predefined packages (called nixpkgs), and an optional Linux
distro that uses Nix the package manager as its package manager (called
NixOS).

~~~
nerdponx
What I'd really like to see is a realistic, end-to-end tutorial for either 1)
deploying a relatively straightforward web application (like Dokuwiki or ZNC),
or 2) setting up a basic desktop for day-to-day use. I feel like I've seen a
lot of "snippets", I feel like I understand how Nix works and what it's
supposed to be good for, but I don't have a coherent sense of the steps
involved in actually using it for mundane things.

~~~
Ericson2314
Look for nix users' "this is not a dotfiles repo" repo on GitHub.

~~~
nerdponx
Care to clarify and/or add a link? I'm not sure what this means. (Edit: I did
not downvote you)

~~~
Ericson2314
[https://github.com/ihebchagra/dotfiles](https://github.com/ihebchagra/dotfiles)
I guess sometimes they are called dotfiles haha.

[https://www.google.com/search?q=personal+config+github+nix](https://www.google.com/search?q=personal+config+github+nix)
seem to be a good search

Perhaps I misremembered how many of them make throw shade on dotfiles repos,
or perhaps it is just that google isn't good at finding such things ("not
dotfiles" won't work).

------
austinl
We're using Nix where I work as well, and while I can say it was not the most
user-friendly to set up, once we got it in place it has reliably worked for
the last two years.

We used to have a long and flaky shell script which set up the development
environment for new engineers and CI machines (for iOS development on macOS,
specifically). Now we have a very simple script which just installs nix and
runs alls builds through the nix-shell. This makes builds on local machines
and CI very easily reproducible. It also means that when dependencies change,
we just update our nix config, and the new dependencies will automatically be
fetched for all of our engineers and CI machines — no need to manually re-run
the setup script.

This is my favorite part of Nix — you can do `nix-shell --run "<some
command>"`, and it will make sure you have all of the correct dependencies
(downloading if necessary), then run the command with those exact
dependencies. This is especially magical when engineers working on other
platforms have conflicting dependencies — a problem we no longer need to worry
about.

~~~
takeda
You can use Nix on MacOS X and with nix you don't need brew.

I used it for few years that way.

If you use nix-darwin + home-manager you can also configure your mac the way
you would NixOS.

Amazing tools that discovered not long ago (they aren't specific to os x) is:

niv - makes pinning to specific repos/versions in repos much easier which
helps with reproducibility, especially pinning of nixpkgs version which is now
controlled in your source code.

direnv + lorri - you no longer need to invoke nix-shell just cd the directory
and all tooling you need for your project is suddenly available which is
AWESOME.

Here's an example of using them together with packaging a python project[1] if
you have lorri and direnv installed and cd to the directory, not only you have
the right python version installed but also all dependencies and even the
"hello" command becomes available, as if you installed it through `pip -e .`

[1]
[https://github.com/takeda/example_python_project](https://github.com/takeda/example_python_project)

~~~
tomberek
I've had luck with using the approach in here
[https://nixos.wiki/wiki/Python#Emulating_virtualenv_with_nix...](https://nixos.wiki/wiki/Python#Emulating_virtualenv_with_nix_shell)
because it allows the escape hatch of using pip if something isn't packaged
and I want to quickly try something out. I have also been meaning to try mach-
nix which may obviate the need for pip at all. Having a good standard skeleton
for a python/nix project would be super helpful to add to the wiki, etc.

~~~
takeda
I tried multiple solutions myself, this one is the closest to what I want,
because:

\- overlays the packages on top of nixpkgs \- understands setup.cfg and can
get dependencies from it

It is still not perfect, but when I find some time I think to submit a PR to
nixpkgs to improve setupcfg2nix. Particularly it doesn't understand
tests_require which you can list dependencies to run unit tests. Nix has
equivalent checkDepends.

------
bsima
A lot of misunderstanding and overexplaining in these comments. The reality is
that Nix is a complex system of many parts, under active development, and yet
is perhaps the best infrastructure we have for creating deterministic,
hermetic, reproducible builds. I've worked on one of the largest Nix systems
and it saves our entire dev team hours. Everything is only built once, on a
large set of specialized remote builders, then shared among all of our devs,
CI, and deployment infrastructure. Perhaps this is common in FAANG, but Nix
enables this even for small teams and individual developers.

If thats something you would like to learn more about but are having trouble
getting started, I'm happy to help. Email is in my bio. We could setup a call
or chat session or whatever.

~~~
takeda
This is what I'm personally looking for, are there some kind of tutorials how
to configure nix in an organization to do CI/CD best practices etc.

------
mehrdadn
I'm still confused. What _is_ Nix? Is it an OS, or a package manager? From the
looks of it it's a package manager that I should be able to use it on any
POSIX system, but I doubt that's the case?

~~~
tel
It's kind of a mess.

Nix is a collection of tools and systems that together form a highly
reproducible build system.

Nix is also a declarative, largely pure and lazy programming language that you
use to design and specify the different build outputs for the Nix build
system.

Nixpkgs is, more or less, the only project written using Nix (and a lot of
shell). It's a collection of many thousands of "derivations", many of the
things you'd expect to be able to fetch from brew or apt. Each derivation
encodes the steps to use Nix (the build system) to construct that output.

NixOS is a Linux distribution built atop Nix, Nix, and Nixpkgs. The basic
claim to fame here is "totally declarative system setup" where you write all
of the configuration for your system in Nix, using Nixpkgs and some other
NixOS specific tooling and libraries, and then "build" the entire system with
high repeatability.

Then there are a few other related projects such as Hydra (a CI server and
binary cache builder—most of the time you don't build with Nix, just download
the proper thing from the cache) and NixOps (an extension to NixOS which
provisions whole fleets of servers declaratively).

Finally, you don't need to run NixOS in order to benefit from Nix. Nix and
Nixpkgs are (largely) compatible with MacOS and Linux. That means you can
install Nix onto your existing MacOS or Linux system and use it a lot like
you'd use brew or apt. That said, the premiere Nix experience is always NixOS.

~~~
illumin8
I've had the (dis)pleasure of working with several projects that have been
built by developers that have religion around Nix. These projects were
contract work where the client paid a significant amount of money, and the
final product was really poor quality. One of them is a financial application
that has strict security requirements, so having a reproducible build system
and some of the other qualities of Nix sounds great, however, the auditor,
which is one of the top auditors in this industry had this to say in their
report:

> Overall, we found the dashboard code to be difficult to review and build. In
> particular, the manner in which the frontend JavaScript is compiled made it
> difficult to comprehensively evaluate. Given that this includes the driver
> code for Ledger devices and handling of user input, we believe this to be an
> area of concern and poses a significant risk. Building the dashboard took
> hours on an AWS EC2 VM (with a four-core CPU and 32 GB RAM) and while much
> of that build time is attributable to Nix's way of building dependencies,
> the code complexity adds unnecessary risk. We encourage a rework of this
> area of the project to follow more idiomatic web development practices and
> patterns. This would make the code more comprehensible and conducive to
> security evaluations, therefore reducing the risk of vulnerabilities that go
> unnoticed.

~~~
WatchDog
I haven't used Nix, but I would have thought that builds would be fast, due to
how cache-able the dependencies should be.

~~~
mzaccari
We've been using Nix for deploying a Rails app for an enterprise customer for
quite a few years now. One area where it shines for us is the ability to build
it on relatively recent version of Ubuntu and deploy to a (almost EOL) RHEL6
box. Bundling, assets and various other tasks take just a few minutes. We also
have ~20 Go services that are also deployed via Nix, and building takes
seconds.

However, it can be quite cumbersome to get a Nix expression to the point where
it builds reliably for something that takes multiple steps like a Rails app,
especially if you're building on macOS and deploying to Linux. It's come a
_long_ way in recent years, but with Enterprise customers now embracing
containerization we migrated everything to that and haven't looked back.

~~~
smichel17
I'm having a hard time parsing -- you migrated everything from nix to
containers (containers removed the need for nix) or to nix+containers
(containers solved the "having to build for multiple platforms" issue)?

~~~
mzaccari
Ah my apologies - We use Bazel to build our services, and the output artifacts
were then pulled into Nix and deployed as Nix packages. Bazel has _excellent_
support taking the same application code and creating Docker images from them
([https://github.com/bazelbuild/rules_docker#language-
rules](https://github.com/bazelbuild/rules_docker#language-rules)), and the
tools available for deploying containers is orders of magnitude more feature-
full and higher quality than what you get with Nix today. So we no longer have
Nix anywhere in our pipeline, and all of our artifacts are now deployed inside
containers.

------
tomberek
Nix is a powerful package manager. I can confidently compile and run multiple
incompatible versions of software simultaneously. I can build projects from
years ago. I can package large projects from different ecosystems (python 2/3,
c/c++, go, javascript) and be confident they will not interfere with each
other. I can try bleeding edge software with no risk to it interfering with my
system. It is faster and less hassle than juggling various Docker containers
and VMs. It protects me from dependency hell.

But overall: it makes me more productive. It is my secret weapon to manage the
complexity of software development.

~~~
downerending
As an example, what's minimally required to run two different versions of
program-x from the command line. Can I do something like this easily?

    
    
        cat-8.22 /etc/passwd | cat-8.3 -A

~~~
tomberek
Minimal example:

    
    
      export v824=$(nix-build 'channel:nixos-15.09-small' -A coreutils)
      export v830=$(nix-build 'channel:nixos-19.09-small' -A coreutils)
      $v824/bin/cat /etc/passwd | $v830/bin/cat -A
    
    

You can get better specificity by using a nixpkgs git repo/hash instead of
channel or adding `--no-out-link`, but this is minimal.

~~~
Shoue
Even more concise:

nix run -f channel:nixos-19.03 hello -c hello | nix run -f channel:nixos-20.03
ripgrep -c rg Hello

------
genr8
Stumbled upon NixOS yesterday and today its frontpage, 1st link. Same thing
happened with OpenBSD the day before. Whats tomorrow, Qubes? I wonder what the
chances of coincidence are if I investigate one new OS per day.
[https://www.foxypossibilities.com/2018/02/04/running-
matrix-...](https://www.foxypossibilities.com/2018/02/04/running-matrix-
synapse-on-nixos/)
[https://en.wikipedia.org/wiki/NixOS](https://en.wikipedia.org/wiki/NixOS)

~~~
Ericson2314
No tomorrow could be BSD and Nix
[https://github.com/NixOS/nixpkgs/pull/82131](https://github.com/NixOS/nixpkgs/pull/82131)

~~~
takeda
Oh nice, thanks for doing the work.

------
ninetax
We're doing a project right now to try to migrate to using nix for our python
code that runs on a raspberry pi. It's been great in many areas, but pretty
annoying when something doesn't work. You have to dig deep to fix errors.

Of course we're trying to get numpy to cross compile from x86 to armv7 which
involves cross compiling gfortran to get blas... so I guess a few bugs [1] are
expected.

Otherwise I've been really impressed.

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

~~~
tomberek
Cross-compiling is finicky in any ecosystem, things like numpy especially so.
When working on armv7 projects, I got a few TinkerBoards and ran the builds
native. The first one took a while, but i just kept my binary cache up to date
and normal CI/CD builds were fast. I'd also push core builds to
[https://arm.cachix.org](https://arm.cachix.org). I haven't updated it
recently, but I am considering doing that again.

------
yachtman
A company I worked at embraced nix. Beforehand I was a big docker fan and had
few issues with it (yes there were occasionally caching issues and damn it
docker figure out the issue with hyperkit on mac os, but largely its a
productive tool). From an outside perspective nix just felt like alot more
work, and nearly no one (except the people that set it up) could ever get it
to work. So basically the entire build process for the core of the system was
something that literally no one in the company wanted to touch. I'm sure if I
was an insider on the tool I would appreciate the added stability you get on
the backend, but at face value it seemed like it just made builds
unapproachable on the front end. I'm happily back to using docker and haven't
looked back.

~~~
takeda
Out of curiosity, any reason why you didn't want to understand it? You spent
time learning docker, why this was different?

------
whiddershins
I haven’t worked through the entire text but I absolutely love the manner of
explaining.

I often feel when I’m reading an explanation the author is reluctant to really
break something down to the essentials and ELI5 ... which ironically can be
conceptualized as the most intellectual way to understand something. Please
explain it from as close to first principles as possible. Assume as little as
possible.

Maybe it is because the author thinks it is an intrinsically hard concept (as
per the intro).

Or maybe this person is just kinda awesome at explaining stuff.

------
voppe
The only takeaway I get from this article is...

 _Why_ is Nix?

And from skimming along the comments, both on HN and on Disqus, there's a lot
of confused people trying to understand/describe the difference between Nix
and Docker, because although the article described how Nix works in a very
technical way, it didn't explain what it can be actually used for.

~~~
rcxdude
It's a package manager written in such a way as to properly solve the problems
with existing package managers which docker patches over. It uses
deterministic builds and careful isolation of dependencies to ensure that the
environment it creates is the same each time, and that you can have packages
which depend on conflicting versions of another package installed at the same
time.

The entire OS is _accurately_ described by a config file, and this can be
reproduced exactly using just that file.

In contrast to traditional package managers: handles conflicting dependencies,
state is tracked through editing the config file, not a serial of
install/uninstall commands which mutate the state of the system. Config files
of installed packages are also controlled through nix config.

In constrast to docker: properly reproducable (Docker will re-run the same
commands in the Dockerfile, but there's no guarantee you'll get the same
result. For example, basically any package installation from a traditional
package manager you run in the Dockerfile will not reproduce when run later
because newer versions of packages will be installed), also more efficient in
terms of space usage. However, AFAIK it does not namespace networking and so
on (nixOS has its own containers system which does do this however).

------
smabie
I have always wanted to try Nix, but not sure how installing software from
source outside the package system works. With Arch Linux, it's pretty easy to
create an AUR package if it doesn't exist, or simply install it outside the
package system. Is it easy to create Nix packages (based on the features of
Nix, I'm guessing no)? What about if you don't feel like creating a package?

~~~
roblabla
Creating nix packages is actually pretty easy once you get the hang of it.
Maybe a tiny bit more involved than AUR packages since it's a new language and
all, but it's not _that_ much more difficult. When I was using nixos on my
desktop machine, I made packages for my own personal tools, so it integrated
in the system.

It's also very easy to customize a package to suit your needs, and in fact
makes for a very nice system to hack on open source projects. You can mostly
setup an override in your $HOME to make a package's source come from your
local disk, and when you install the package it will compile locally instead
of getting a prebuilt binary.

If you don't go through their packaging system... It's really easy to end up
in a mess. There are ways to simulate a "normal" linux from within nixos,
essentially making a chroot in which the various libraries are in their normal
locations (achieved through an overlay filesystem). I believe that's what they
do to run the Steam client. I assume (though never tried) you could use this
to run other binaries without packaging. But then... what's the point?

------
dangoljames
Really it's kind of a minimalist linux distro with the capacity to coexist
harmonically and/or parasitically with another operating system. Don't try to
say 'oh it's like arch' or 'yeah it's a bit like Ubuntu', because no, it
isn't, and by design. It seems that as much as design meant to go a particular
way, there it went.

It does pretty well directly on the hardware, but seems to want to live (like
it is) in a container, though that might just be it's style ;) it certainly
seems to be _convenient_ for containers.

It has a certain otaku appeal and ninjatsu stealth. I'll probably like it a
lot some day soon but at the moment it just screams 'exotic' in my ears while
I'm asleep at night.

This probably isn't helping so I'll just stop now.

~~~
jchw
> It has a certain otaku appeal and ninjatsu stealth. I'll probably like it a
> lot some day soon but at the moment it just screams 'exotic' in my ears
> while I'm asleep at night.

I’m trying to refute this characterization, but I am sitting in front of my
desktop with an anime background in SwayWM on NixOS. Is there something I
don’t know about correlations between seemingly unrelated hobbies?

~~~
eeh
NixOS, Emacs, Haskell, tiling window managers.

They're a clique in the tech world. I think a unifying theme is to have a
small foundation that the user can develop within.

Going a bit further on my soapbox, you might also be into philosophy, anime,
election reform, baduk, and math. Is the underlying personality trait
systemizing/stubbornness, wanting to break everything down, and rebuild it
according to defined principles?

[http://dreamsongs.com/RiseOfWorseIsBetter.html](http://dreamsongs.com/RiseOfWorseIsBetter.html)
would call this approach the MIT style of design.

@nntaleb might suggest they overestimate their principles and their ability to
enact their principles, and call them IYIs. :)

(This comment itself is my admission of being an IYI.)

------
juskrey
For me nix(OS) began from much simpler upside: now I never forget that
handmade one line tweak somewhere out there - all Linux system goes in one
nice config.

------
dtrailin
This sounds similar to BuildXL[1] (originally called Domino) which Microsoft
uses to build Windows has been in use 6 years. It does this sandboxing using
Detours on Windows which intercepts system calls and allows you to described
packages in a language called DScript. I think you need something like this if
you don't use a system like Bazel that keeps build dependencies well isolated.
Even then the system you use can leak into the build.

1\.
[https://github.com/microsoft/BuildXL](https://github.com/microsoft/BuildXL)

------
LockAndLol
This article suffers from the same problem every nix article I read suffers
from: it dives in too deep from the get go. When you sit somebody down in
front of a computer for the first time in their life, you're not going to
explain what it is composed of, what happens in when your mouse button is
clicked and why Windows vs Mac vs Linux is a thing.

Please, first tell me what nix is, provide me with a few commands to get me
started, make a few comparisons to what the audience should reasonably know,
and then make this your second or even third article on the subject.

~~~
burke
That's kind of the approach I took in this playlist:
[https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...](https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs)

However, there is really an important and subtle set of concepts to grasp in
order to actually understand Nix, and not just mess around with a package
manager tool incidentally built with it. It's fine to not understand them, but
they are what this article tries to explain.

~~~
bradly
FWIW... I read this article as someone who doesn't know what Nix is. Like no
idea at all besides the name sounding familiar. After reading the first few
paragraphs I feel I'm not the target audience for the article, which it
totally fine, but based on the title of the post, I assumed I was.

~~~
burke
Yeah, it was a last-minute title change that I now regret.

~~~
bradly
Yeah, that's tough :(

On the bright side... sounds like the community (or at least me) would really
be into another article as a primer.

------
seddona
We use Nix for all our developer tooling at CircuitHub. It's not the easiest
thing to get into - but once you do - it solves so many problems! Great to see
a large company like Shopify get in on this.

------
magnusmorton
I feel someone should say something about guix here. I don’t have anything
worth saying about either though

~~~
rixed
Anecdote about the subjective difference between using both:

I've used nix and nixos on and off since the early versions, but it never
really clicked with me, and every time I want to write or just read nix
expressions I have to reread lots of documentation like I'm starting from
scratch again, whereas I would probably still be able to write a debian
package from memory alone despite many years of lack of practice. This leave
me with the impression that nix has to be a full time job.

In another hand, I gave guix a try recently and was really surprised by how
easily all the pieces fell together "naturally".

Also guix being a smaller community, it might counter intuitively be moving
faster (due to less care for not breaking things or less bureaucracy,
depending on your views). Indeed, another issue I have with nix is how jammed
their input queue of PRs is.

~~~
bb010g
I'd say the PR quite is less bureaucracy and more a high number of packages
with not enough hands to process them all.

------
phissenschaft
Wondering if folks would prefer spack ([https://spack.io/](https://spack.io/))
given its heavy adoption in the HPC community.

------
alphachloride
After reading the article, I am still asking the same question: What is Nix?

Edit: from their website [https://nixos.org/](https://nixos.org/):

> Nix is a powerful package manager for Linux and other Unix systems that
> makes package management reliable and reproducible. It provides atomic
> upgrades and rollbacks, side-by-side installation of multiple versions of a
> package, multi-user package management and easy setup of build environments.

------
siscia
Really looking forward for knowing how Shopify use nix and what problem the
find with it.

I was advocating for it in my organisation but eventually we decided for a
different technologies...

~~~
lmickh
Burke Libbey has a few talks that are available on YouTube including a
presentation at NixCon about the work he is doing at Shopify. I would highly
recommend checking them out if you are interested in Nix.

~~~
burke
Hi! Yes, and here's the link to my recent Nixology playlist:
[https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...](https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs)

~~~
elbear
Hey! At the end of your article you mentioned you're hiring. Are the positions
remote? If yes, how can I get in touch?

~~~
burke
Yes, we’re hiring! You may have seen the news today that we’re all in on
remote now. Send an email to burke.libbey@shopify.com, I’m as good a point of
contact as any for Nix stuff.

------
zelly
I like the idea of Nix. It's definitely the future of package management and
build systems. But it's solving a problem we knew how to solve in the 80s:
dependency hell is solved by statically linking everything. In fact in the
Windows world it's still like this. If you need OpenSSL, for example, it
should be in your source tree and compiled in the same build pipeline as your
application.

~~~
casept
Static linking is unfortunately broken for many projects though, primarily
because every C/C++ dependency has a slightly different incantation to make it
work. It also doesn't address the problem of languages which expect
dependencies to be files on the filesystem, like python or ruby.

------
sigrlami
Nix is a cool ecosystem but getting builds quite expensive on conventional
CI/CD system. One can reduce costs by running custom Hydra CI instance but I
would love it to be a bit better. Working with private stuff is a mess and
requires deep knowledge of the system, hard for newcomers to pick up. Also,
NixOps super cool extension to manage a fleet of instances.

------
Tomte
Is Nix only handling the build part (with configure flags etc.) or is it also
used to configure services, for example?

I'm not versed in devops/provisioning etc., but say, I had a NixOS system with
some server software (mail server, DNS server, whatever).

Would I still want to use Chef/Puppet/Ansible, or is that included in the Nix
ecosystem?

~~~
casept
NixOS exposes config options as variables you can set in your
configuration.nix file. Also, external config management tools generally
interact poorly with nixOS, because they assume a system which is managed
imperatively.

------
aabbcc1241
It looks similar to "npm with ipfs/docker (layer-fs)". My initial guess is it
may use more disk space like snap. Because it requires exact version of
dependency. Unlike in npm/pnpm that access wide range of dependency version as
long as it satisfy the server version.

------
1MachineElf
Nix seems wonderful, but I have one question: If nixos.org and github.com
disappeared tomorrow, are users sufficiently enabled to keep the project
going, or are those two single points of failure?

------
sandGorgon
is there still relevance for this way of building in the world of Docker -
especially with Packer and LinuxKit ?

Packer allows us to create highly repeatable OS builds with all the right
configuration and packaging. For example, this is AWS official Packer build
for their EKS AMIs - [https://github.com/awslabs/amazon-eks-
ami](https://github.com/awslabs/amazon-eks-ami)

~~~
casept
Docker kind of sucks for development though, because you need to reinstall all
your devtools into the container and have to wire up your IDE to support
docker. With nix, you just write a shell.nix, run nix-shell and can then use
your regular tools in that environment.

Also, nix builds are far more reproducible than packer builds. With nix, you
get an environment that is guaranteed to be identical down to the hash of
every single file as long as you use the same version of nixpkgs. Packer and
similar imperative tools typically install whatever version is the latest in
the distro repo, and building the image 2 months apart will grant you
different artifacts without investing a lot of effort into pinning everything.

------
ajb
I really wish nix was the solution, but I'm not sure it is. I currently don't
install anything on my base system, but do it via docker. Looking through my
dockerfiles, currently I have stuff installed via:

* apt

* apt preceded by apt-key add

* wget/curl

* pip & pip3

* git clone

* go get

* npm install

* snap

And that's even though I try to avoid esoteric package managers as much as
possible. (For example, there was some package recently where the recommended
method was brew for linux, and another that wanted to be installed via conda.

There's just so much stuff out there that insists on using some random
packaging system. docker, even though it's a bit flaky, abstracts that away.

~~~
myguidingstar
nix is the solution. It's totally different from any random packager you've
seen. It goes the reversed direction of abstracting dependencies away: it
makes dependencies explicit (and reproducible!)

~~~
ajb
I get it, but my point is that unless it can cope with packages that aren't in
the ecosystem, it will just add another variant rather than solving the
problem, as per [https://xkcd.com/927/](https://xkcd.com/927/)

It reminds me a lot of [http://www.vestasys.org/](http://www.vestasys.org/)

~~~
Ericson2314
Nix at this point is almost 20 years old, and we have 10,000s of packages.

If that meme wants you to blame something, it should be Docker.

(First of all, it's younger. There's big tons of effort with Docker and yet
nothing is reproducible, and DPKG, APT and all their ilk can't even be
deprecated but instead are used awkwardly within the Docker ecosystem.)

------
edbentley
Hearing about Nix couldn’t have come at a better time. Having just got a new
Mac, seems like the perfect time to try a fresh Nix-only setup.

~~~
myguidingstar
from now on every new machines will be easily replicated with configs from
older machines: copy the config file over, type one command and let nix does
the rest

------
squid_demon
"All software exists in a graph of dependencies."

And some of these graphs consist of a single node. Junk the jank!

~~~
Gaelan
I mean, if you count the compiler/interpreter (which nix does), realistically
that's a bare minimum of two.

~~~
takeda
Nix comes with its own glibc, so that's 3, although I guess while it is not
the default you could compile statically.

~~~
Gaelan
If you compile statically, you've got musl, which is still a (build-time)
dependency.

~~~
takeda
There's a confusion between build and runtime dependencies. From Nix point of
view. Even if you compile statically your code still depends on libc, it's
just that you include the libc in the resulting binary. With Nix all
dependencies are listed for your application. Because if no compiled version
is available in binary cache, Nix will get a compiler and build one. This is
actually awesome, imagine there's a program in nixpkgs that you want to use,
but you want to have it linked with different libraries.

For example pgbouncer[1] can be linked with different DNS resolvers, which
have their strengths and weaknesses (currently it is linked with c-ares which
probably is what most people want, but until version 1.10 that wasn't true)
you can override the derivation and use different dependency. Nix will build
on the fly the new version that does do what you want, and this is awesome.

[1]
[https://www.pgbouncer.org/install.html](https://www.pgbouncer.org/install.html)

------
diegobernardes
Too bad that Nix don't work with fish shell

~~~
Shoue
I'm using Nix and Fish and have been for a year or two now. I remember some
issues initially but NixOS and home-manager have boolean options to enable
Fish and it Just Works nowadays.

------
cerved
I don't understand what problem it solves

------
jariel
I loathe to be so critical, but I have no idea what this is.

I'm sorry to say but this is a bad article - either that - or nix itself is a
mishmash of things impossible to explain.

I just see red flags everywhere.

If it's 'A' \- then maybe take some time to do a high-level introduction and
some context.

\- 'Everything depends on something else' \- really? Most 'installed software'
doesn't depend on a whole lot else. Does the author really mean server
software? Development environment?

\- "The easiest place to start is the Nix Store. Once you've installed Nix,
you'll wind up with a directory at /nix/store,"

No! That's not easy, because what he&& is Nix, why and how would I install it,
and what is the 'nix store'? Starting to explain something by introducing a
whole bunch of other unknowns without description or context is going in the
wrong direction.

\- "This directory, /nix/store, is a kind of Graph Database. Each entry (each
file or directory directly under /nix/store) is a Node in that Graph Database,
and the relationships between them constitute Edges."

WHAT? We are now 3 layers deep in a rabbit hole of unexplained things.

\- " Nix guarantees that the contents of a Node doesn't change after it's been
created."

What is a Node?

If the issue is 'B' \- i.e. the inherent overlap of technologies that Nix
makes it hard to explain ... well maybe it could be broken up.

Take a minute to give some context for what Nix is, the kinds of people that
use it, what problems it solves, and then have some exceedingly basic
introductory examples so that people have a frame of reference for what you
are talking about.

Then you can step by step, go into the weeds.

~~~
yakshaving_jgt
> \- 'Everything depends on something else' \- really?

Yes. Really.

> Most 'installed software' doesn't depend on a whole lot else.

Yes it does. Your ignorance of this fact does not make this any less a fact.

> Does the author really mean server software? Development environment?

All of it.

~~~
jariel
I thought this was satire when I first read it.

But no, people around are really do have serious challenges with language
sometimes.

Here's some help:

The vast majority of software that users install on their computers depends
only on what the user would perceive as the 'OS' itself. For example, if one
were to install 'some app' that works for Mac OSX version X.X and later, there
wouldn't be any contemplation of 'dependencies', to the point wherein the vast
majority of users wouldn't even grasp the concept.

Granular package or system-level dependencies are something that only
developers are aware of.

Of course, the fact that nobody but developers would contemplate
'dependencies' should be obvious to anyone who interacts with regular people.

~~~
yakshaving_jgt
> the fact that nobody but developers would contemplate 'dependencies' should
> be obvious

Is it perhaps lost on you that the vast majority of people discussing this
technology are developers?

And you accuse _me_ of having serious challenges with language. Yikes.

> The vast majority of software that users install on their computers depends
> only on what the user would perceive as the 'OS' itself

Yes. And those dependencies are _implicit_. You know, _exactly_ as the article
describes.

> to anyone who interacts with regular people

This is a thinly-veiled ad-hominem argument. Does this approach of snootiness
and condescension normally work for you when interacting with “regular
people”?

------
starpilot
Talks to the Raccoon server, I believe.

------
johndoe42377
A messy pile of unnecessary, redundant abstractions which "solves" nonexistent
problem.

Stable interfaces (the main principle behind literally everything in nature)
and semantic versioning will do the job.

systemd-like cancer. And, of course, look, ma, I am so smart.

