22 ms·

Will Nix Overtake Docker?

327 points by potentialstyx 5y ago

dimgl 5y ago
As someone who has never used Nix, from first glance the question I ask myself is... why?
- rgoulter 5y ago
  Nix is difficult, but there are advantages to it. A couple of comparisons are similar: with Terraform (or CloudFormation etc.), you put in a lot of effort up front in order to reduce maintenance effort later. You could manually go through and setup a VM instance or two; but with Terraform, you have a declaration in code of what the system should be. I think another comparison is: Vim or Emacs are more difficult to use compared to using VSCode. In terms of DX, there are advantages to Emacs over VSCode. If modal editing seems to make sense, it's probably worth looking at vim. But, if you just want to get the job done right now and not fuss about learning an unfamiliar tool, VSCode is surely a better choice.
- pxc 5y ago
  Nix - is fast (faster than Homebrew or Docker) - is multi-user (don't need root privileges to install software) - lets you try software without permanently installing it - gives you fast, reliable undo without requiring a special filesystem - lets you automatically (re)produce a setup that never drifts from its official definition - can safely perform upgrades and configuration changes without thinking about what has been done to the system or environment in the past - has tons and tons of software already packaged for it at this point, which you can just use without any special effort
edude03 5y ago
No, it definitely (but unfortunately) will not. Nix does everything docker does better than docker does, except most crucially, integrate with non nix tooling. Nix vs Docker is like Rust vs JavaScript - you can point out every reason js is terrible and rust is better, but for the common developer looking to get things done, they’ll often gravitate to the tool that gets them the biggest impact with the least upfront investment, even if that tool ends up causing major predicable headaches in the future.
- abathur 5y ago
  I like to compare Nix to ice-nine from Cat's Cradle, in that it tends towards restructuring whatever it comes into contact with.
  - doublepg23 5y ago
    Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...
    - rekado 5y ago
      This gets repeated a lot, but Guix really is not a fork of Nix. Not by any definition of "fork". Also not "a fork of sorts". The term "fork" only applies to one executable: "guix-daemon", which is a literal fork of "nix-daemon". They have, of course, diverged a lot, but this (and nothing else) is truly a fork. Aside from this one executable there is no relationship between the two projects. The daemon takes .drv files that list what preconditions a build has (= other .drv files), what build script to run (= a generated Guile script), and what outputs will exist when the .drv file has been processed. It processes these .drv files in an isolated environment (chroot + namespaces) where only the inputs mentioned in the .drv file are made available. The drv files are not shared among the projects; they are not generated in even superficially similar ways. Guix is not a fork of Nix. "guix-daemon" is a fork of "nix-daemon". Both are implementations of the same idea: functional package management.
      - ShamelessC 5y ago
        This fits my definition of a fork (of sorts). Thanks for the nuance though.
      - doublepg23 5y ago
        I love reading your blogs on Guix, I'll keep that in mind for future reference sorry for the libel ;)
snowytrees 5y ago
If your interested in digging deeper into building docker containers with nix this is my favorite post on the topic: https://thewagner.net/blog/2021/02/25/building-container-images-with-nix/ https://thewagner.net/blog/2021/02/25/building-container-ima.... Essentially you can use any nix package (including your own) to create the environment. And if you really want to understand it, Graham Christensen (the contributor of the buildLayeredImage function) wrote a really good blog post on how it works: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images.
bjtitus 5y ago
I've set up my new M1 MacBook Pro using Nix and it's been going relatively well. Home Manager manages global tooling like Neovim, random CLI tools, and config files while I've set up `default.nix` files to use with `nix-shell` per-project. The set up of each project can be a little tedious as I still find the language confusing but once everything is set up the reliable re-creation is excellent. I love the feeling of opening the nix shell and feeling like I have each tool I need for that project without worry of polluting my user space or conflicts between projects.
- linsomniac 5y ago
  My MBP left Shenzen early this morning and I'm super interested in details of how you did this. Are there any examples of doing this that you followed or recommend? Ansible is more my tooling of choice, though I'm fascinated by Nix, but I wasn't sure even how to get started with using Ansible to set up the Mac.
  - linsomniac 5y ago
    I just watched this Jeff Geerling video about setting up his M1 Macs using Ansible and his provided playbooks. That's probably the direction I'll end up going. https://www.youtube.com/watch?v=1VhPVu5EK5o https://www.youtube.com/watch?v=1VhPVu5EK5o
- lilyball 5y ago
  I recommend also using direnv, with nix-direnv (home-manager has a setting to trivially enable nix-direnv). This lets you integrate your shell.nix environment into your existing shell without having to run `nix-shell` or use bash.
  - bjtitus 5y ago
    Oh wow, this is fantastic! Thanks for the tip and I'd like to thank you for all of the work you do on nix + Darwin. I'm using your `nix-env.fish` package and it's made things much easier than when I tried this setup a few years ago.
salamander014 5y ago
I think people are missing the forest for the trees with this. In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds. It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge. Yes, Nix is 'better', but the fact is Docker is 'good enough' and also 'stupid simple' to get started. Also Docker-Compose, I don't know why people hate on YAML. But it takes that same KISS attitude to build complex systems that can also be used as sanity checks for migrating to things like kubernetes. Being able to spin up a complex full stack app with one command and a compose file that doesn't take any brain cells to read is worth it's weight in gold. This is like the 'general case tool' vs 'DSL' debate. If it's easy to use, people will use it.
- cbrewster 5y ago
  Author here. As with most things, its all about the trade-offs. Docker has certainly proved itself and that approach has worked on a massive scale. However, its not a silver bullet. For us at Replit, our Docker approach was causing issues: our base image was large and unmaintainable and we had almost no way of knowing what changed between subsequent builds of the base image. We've been able to utilize Nix to address both of those issues, and others who may be in a similar scenario might also find Nix to be valuable. Of course Nix comes with its own set of opinions and complexities but it has been a worthwhile trade-off for us.
  - AmericanBlarney 5y ago
    Those sound like issues with your Docker usage - there are options to keep base image quite streamlined (e.g. alpine or distroless images).
    - cbrewster 5y ago
      For context, I'm referencing our (legacy) base image for projects on Replit: Polygott (https://github.com/replit/polygott/ https://github.com/replit/polygott/). The image contains dependencies needed for 50+ languages. This means repls by default are packed with lots of commonly used tools. However, the image is massive, takes a long time to build, and is difficult to deploy. Unfortunately, slimming the image down is not really an option: people rely on all the tools we provide out of the box.
jonstewart 5y ago
I tried using Nix and NixOS early in the year, but documentation is an issue. Also, while I appreciate NixOS’s focus on reproducible configuration, I also have 25 years worth of mediocre Unix sysadmin experience, and it would be nice if the system found a way to accommodate Unix. My last straw was trying to get nix to schedule some task through systemd, when what I wanted was a simple crontab.
- Gigachad 5y ago
  Kind of a tangent, but from what I have seen, crontab doesn't actually exist on modern distros, I believe they have a tool that converts the crontab config in to systemd timers. As well as fstab.
  - jonstewart 5y ago
    Yes, so I was doubly frustrated in this instance. I know the BSD-style init script system that I learned with Slackware is not geared well towards modern hardware (i.e., laptops), but it was so much simpler to read and comprehend.
    - Gigachad 5y ago
      Systemd timers do have several advantages but they come with more complexity which is why a translation layer is usually applied on user focused distros. You can enable/disable timers, trigger them manually, see when they last triggered, see when they will next trigger. And probably a bunch of other stuff. They also have individual files so automation can easily add or remove timers. For a power user, systemd timers are much better. But if you just want to quickly add one thing, it probably isn’t worth the effort to learn
  - nightfly 5y ago
    Cron still exists on Ubuntu at least.
- l0b0 5y ago
  After having configured a bunch of crontabs, I found the Nix+systemd timers approach a massive improvement.
awinter-py 5y ago
IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud build costs. I guess this is what the article means by trouble 'sharing layers' docker buildkit (or moby buildx or wherever the branding has settled) is supposed to to improve caching, but creating a simple API for caching that plays nicely with system + language package managers would really move the needle here; reorderable package installs would be the v2
- jonstewart 5y ago
  You can use Nix to create a tarball that can then be launched as a Docker container. However, I haven’t figured out a way to make Nix play nicely with container image layering—you get a small container image for deployment, but you’ll have lots of such largely-duplicative tarballs in the CI pipeline and the latency for generating them is annoying.
  - clhodapp 5y ago
    Have you tried dockerTools.buildLayeredImage (https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerTools-buildLayeredImage https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...)? It applies some smart heuristics (https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images) to create images made of pretty reusable layers. This is subject to some false cache misses due to some laziness in the docker's cache implementation (https://github.com/moby/moby/issues/38446 https://github.com/moby/moby/issues/38446), but that is Docker's fault not nix's and it affects dockerfile builds too.
    - jonstewart 5y ago
      No, hadn’t seen that. Thanks!
  - 5y ago
cetra3 5y ago
One thing in the blog that is not true is that you can only inherit from a single layer. You can use multi-stage builds to grab & blend layers: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu.... It is not as powerful as nix, granted, but it is possible.
- flyinprogrammer 5y ago
  Except that multi-stage builds are deceptively not grabbing or blending layers - it's simply letting you copy files from a layer. And that is a big miss. Being able to describe "now append this layer and all, but only, its file changes from this previous layer" would be pretty epic.
- cbrewster 5y ago
  While you can copy files from different stages, I wouldn't consider this to be the same thing as composing two base images together. Like the example in the post, you can't take the Rust and NodeJS images and tell Docker to magically merge them. You can copy binaries & libraries from one to the other but that seems extremely tedious and error prone. Whereas Nix makes it rather trivial to compose together the packages you need (eg Rust, NodeJS) in your environment.
throwaway9870 5y ago
> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue. If "aggressive" means fully, then why doesn't that fix the issue?
- Volundr 5y ago
  A lot of package repositories prevent this now, but theoretically your package repository could allow a new version of the package to be uploaded with the same version number. Docker tags have this issue in fact, so even your base image could change underneath you.
  - throwaway9870 5y ago
    I can't imagine using a package system for building images that doesn't allow a full local cache of exactly the packages I want installed.
    - Volundr 5y ago
      I mean sure, you can absolutely retain your own docker repository, your own NPM repository, etc and then configure them in your Dockerfile before installing packages. Pretty much every technical problem has a technical solution, but it's more effort that "just" fully pinning your versions.
      - throwaway9870 5y ago
        If there are too many packages to pin, then I assume there are too many package to audit changes in for each image build you do? If that is true, how do you have any confidence that the image is going to function correct?
        Volundr 5y ago
        I think we're talking about two different things. I'm thinking of pinning packages as say, my npm.lock specifies I will use version 2.2.19 of tailwind css. Or my Dockerfile has redis:6.2.6 as it's base image. Both of those are fully pinned, but nothing stops Tailwind or Redis from uploading new versions of the package and reusing the version number (I believe NPM actually disallows this, Docker hub does not). So my build is not technically reproducible. I can solve this by maintaining my own Docker registry, and my own NPM registry, but that's more work that just fully specifying versions in a configuration file. As for auditing changes, well most people don't. They update their dependencies and run their tests and if the tests pass, ship it! Most companies don't have a team auditing every single dependency that's pulled in, much less every update after a dependency has been approved. They simply trust the authors of Redis not to screw them. It's great if you do, I'm certainly not arguing against it, but it's far from the norm.
zamadatix 5y ago
Somewhat not related and likely dumb question but I figure folks looking at this article can help steer me in the right direction: if I want containers to act like Linux VMs what's the best option? Like Docker minus the assumption that I only want a few specific directories to persist or the idea I'm interested in layering containers in a way that lets me reproduce building them. Like if I just want another separate full instance of Alpine with it's own network view and own filesystem view and own everything but sharing the host kernel instead of being fully virtualized.
- oddlama 5y ago
  You might want to have a look at systemd-nspawn [1], which is basically containerized chroot based on linux namespaces. [1] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
  - CameronNemo 5y ago
    I don't think you can easily use systemd-nspawn on Alpine.
  - zamadatix 5y ago
    This is exactly what I needed! Thank you!
- Hendrikto 5y ago
  That’s basically what systemd-nspawn does.
- CameronNemo 5y ago
  LXD is probably the most polished option. I believe it is packaged and up to date on Alpine.
- SkyMarshal 5y ago
  In addition to systemd-nspawn, Kata Containers might also work for you: https://katacontainers.io/ https://katacontainers.io/
exdsq 5y ago
Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get them in a Dockerfile. Build times in Haskell were bad enough but suddenly you had nix into the mix and I'd be wasting half a day as Nix built the entire world - solved with internal caching servers but have fun trying to work out how to push something to that correctly. There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. Nix seriously needs all three. It's the only technology I've ever vetoed at a startup because I've seen the hell hole it can become - perhaps not for the DevOps engineers who know it, but the team who have to suddenly work within the resulting environment.
- taeric 5y ago
  Funny, because I feel that simple tasks that would take minutes in my machine are now a dev adventure with docker. And I mean funny. I suspect it is different mindsets. And I personally like that both seem to be thriving.
  - goodpoint 5y ago
    It's well documented that Docker and especially docker hub had a terrible impact on security. Once you factor in the efforts required in the long term to mitigate a decade of bundling gigabytes of applications and libraries it's a huge "dev adventure"
    - oauea 5y ago
      Just build your own images like you would otherwise install the software on bare metal. Base those images on official images, not community images.
      - kryptk 5y ago
dreyfan 5y ago
What's the easiest way to deploy a docker container to a VM? Preferably without ten layers of cloud provider interconnected services or expensive and complex kubernetes layers? I just want to send a container and get back an IP address I can send some traffic to the exposed port(s).
- umvi 5y ago
  Docker save the container image to a zip file, ftp it over to the VM, then docker load it?
- reducesuffering 5y ago
  Dokku. I'm a DevOps noob, just recently picked up Docker, and had such an easy time with Dokku, I decided on it for my current deploy process. Once you setup a few Dokku commands on the server, you can git commit, git push to the dokku remote and it runs your docker container automagically.
snicker7 5y ago
Guix supports exporting to Docker containers. A guix.scm file then becomes a reproducible alternative to a Dockerfile. However, Guix has its own container implementation. And this is significantly lighter than Docker (instead of layers, links to /gnu/store) and is root-less. If Guix containers had a runc-compatability layer and better docs/tutorials, it would be hard to go back to Docker/podman.
- rekado 5y ago
  I have been using Guix-generated reproducible Docker images for years. I'll never go back to using Docker directly. Could you please elaborate what you mean by "runc-compatability layer"? And what about the docs requires clarification? (I wrote the original Docker export backend for "guix pack", so I have an interest in improving this feature where necessary.)
  - snicker7 5y ago
    I am referring to a hypothetical dockerless OCI compatability layer built on top of `guix shell --container` or `guix system container`. I sort of got this idea from runj [0], an attempt to create an OCI compatible runtime for FreeBSD jails. The main advantage is to use certain OCI-compatible tools (e.g. k8s) with Guix without needing to use Docker. [0] https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-for-freebsd-jails/ https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-...
justicezyx 5y ago
> This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. > One is a container deployment toolkit and the other is a package and configuration manager. My reading, based on the mapping from the arrangement of the 2 words Nix and Docker, is that Nix is a "container deployment toolkit" and docker "package and configuration manager". Of course, this interpretation is wrong. Further, even if applying container deployment toolkit as a description to docker, it still misses a core part of docker, I.e., docker is also a container image building tool kit. The building part and the deployment are for different steps with seemingly equal importance.
cglong 5y ago
Does Nix have an answer to Docker's support for Windows containers? The ability to mix legacy Windows applications with cloud-native ones is a huge boon for those interested in migrating to a modern stack.
- pxc 5y ago
  Nix doesn't have any Windows support, though there's intermittent developer interest that sometimes manifests as a demo before the bitrot sets in For now you can cross-compile to Windows using Nix and you can run Nix in WSL
paxys 5y ago
The article starts and ends with "they are very different tools for different use cases". What was even the point of writing the whole thing hypothesizing whether one will replace the other?
- cbrewster 5y ago
  Author here. It's titled this way because Docker seems to come up in a lot of discussions around Nix and is often compared with Nix. Partly because of their overlap in functionality but also because people may not understand the difference between the two. The goal here was to a) highlight the different use-cases between the two tools b) compare the tools in the areas that they overlap and c) show how both tools can be used together.
r3trohack3r 5y ago
I know the author calls this out - but Docker and Nix _are_ different. For immutable distribution they solve the same problem. But they solve it in fundamentally different ways. If you go back and read the last 20 years or so of LISA papers, it can be … humbling/frustrating. You can read two papers back to back, separated by 15 years, and they’ll be describing a new solution to the same exact problem that still hasn’t been properly solved. Dependency management has been horribly broken in our industry and we’ve never really managed to address it - until Nix. The Nix LISA paper [1] was a breath of fresh air, it really cut to the core of the problems with modern dependency management and addressed them head on. Docker declared bankruptcy on dependency management and just resorted to fs snapshots to guarantee bit perfect deployments. [1] https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
kristianpaul 5y ago
Hopefully Systemd eventually does.
AmericanBlarney 5y ago
No
InTheArena 5y ago
no
mac-chaffee 5y ago
One excellent crossover between Nix and Docker is https://nixery.dev/ https://nixery.dev/ If you ever need a container with a handful of well-known utils installed, just specify them in the image URL. Positively magical!
frogperson 5y ago
No, I don't think it will. A Dockerfile can be read in seconds and explained to a junior in a few minutes. Nix is way too complicated to see mainstream use.
solmag 5y ago
About to write "they aren't the same thing" as I remember Nix aliases the language, package manager and OS.
yewenjie 5y ago
I love Nix and NixOS, but sometimes it is extremely painful to get complex software which expects FHS to work. For example, I have spent a day trying to get Android Studio for React Native set up and failed.
qudat 5y ago
As far as I understand nix, the nix examples do not create a reproducible environment because it is not locking the versions down for each package, including nixpkgs. https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs https://nix.dev/tutorials/towards-reproducibility-pinning-ni...
- amarshall 5y ago
  Ass that article says, it’s possible but awkward. It gets better with Flakes https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
  - amarshall 5y ago
    *As (oops, mobile typing)
kortex 5y ago
As TFA itself answers, "no". But I can give a different reason: nix is too much of a barrier of entry, relative to Docker. Docker might not be simple; there's a lot of moving parts to manage, some hidden gotchas, and networks are a mess. But it's comparatively easy, and once you bake an image, it's pretty simple. Dockerfiles are basically just sh. Package managers are the usual suspects. Images are easy to distribute. It's very familiar. Nix is not easy. It's a new syntax to learn, it's a new way of building, it's an entirely new way of thinking about the problem. But in the end, it does simplify packaging in the Rich Hickey sense of the easy/simple dichotomy. No braiding of packages and shared libs. But using Nix is not so simple. There's all kinds of bindings and bodges and bespoke shims to make it all work. History tends to show that easy+non-simple things beat out simple+non-easy things (devs are lazy). Easy-kinda-simple vs non-easy-kinda-simple-but-long-term-gains? No contest in my opinion. I think Nix is a beautiful idea but it's an uphill battle.
- stevebmark 5y ago
  I agree, there’s a reason no one uses Nix. It has terrible DX
  - rch 5y ago
    Quite a few people use Nix.
  - kortex 5y ago
    Well "no one" is a bit absolute. But colloquially, I know what you mean. Relative to Docker, it's way less popular. But it has 5.2k stars on https://github.com/NixOS/nix https://github.com/NixOS/nix . But yeah. The DX "needs work". which is a nice way of saying, I find it downright painful to use.
  - jessaustin 5y ago
    Does it seem weird to anyone that Nix insists on installing its "/nix" directory on the root directory rather than somewhere sensible like "/usr" or even "/usr/local" ?
throwaway984393 5y ago
I only noticed recently that I have a tendency to search for reasons to use a tool. I literally googled "Do I need to learn Go?". You'd think it would work the other way around: I can't accomplish something with a language I use today, so I go searching for a language that solves my problem. Instead I'm literally looking for excuses to learn the most popular thing. It's absurd. (and really it's resume-driven development) In terms of Nix versus Docker, they're completely different levels of abstraction and solve completely different problems. Docker is (among other things... it does a lot of things) an abstraction for reproducing network services on arbitrary platforms. Nix is an abstraction for installing and setting up files.
whateveracct 5y ago
Who cares? I've spent years ignoring mainstream, "senior", etc devs' opinions on both Nix and Haskell. "Nobody uses it," "it's too complicated," "bet on mainstream X," "it's too hard to learn." Guess what? If has paid off in terms of personal efficiency - and I can make a good living doing it to boot with some effort. If you want to aim for the mountaintop, don't let the weight of cynical complainers hold you back. Remember: It takes guts to be amazing.
aitchnyu 5y ago
I used Docker Compose to, among other things, manage Postgres, which wants to listen to port 5432 and use a central dir to hold databases. Can a non Docker solution allow me to run multiple instances of Postgres?
- Bayart 5y ago
  Without going into stuff like Kubernetes, basically what you want is to run your postgres instances behind a load-balancer listening to 5432 and forwarding to whatever instance. The most common with postgres is probably HAProxy. If your problem is that you want to run unrelated instance of postgres... you don't really have a problem to begin with. Either use docker run to run your postgres image on different ports with different volumes, or just make a docker-compose YAML file with a bunch of postgres services. It's not like you have to have a single one.
- tempodox 5y ago
  Deploy them into different directories and have them listen on different ports. You can configure the deployment directory when building from source and then set the port numbers in the respective “postgresql.conf” files.
  - mst 5y ago
    Right, a bunch of apps I've worked on use p3rl.org/Test::Postgresql58 to spin up a temporary postgres instance per test file - clean state and parallelisation are wonderful things to have for fast and reliable testing cycles.
greatgib 5y ago
Along my life, i have worked with a lot of build systems, but I find Nix syntax and commands to be completely awful! I see that it could be useful, but it completely turns me down immediately.
- pxc 5y ago
  I don't get all the hate for the Nix language. It seems really simple and flexible to me. What do you dislike about the language?
  - greatgib 5y ago
    I can't really say, but when I see it, I have the feeling that it is made of the worst parts of perl, bash, javascript, ... all combined together.
- soraminazuki 5y ago
  The Nix syntax being complex is something that is taken for a given in online circles, but it's actually one of the most simple languages that I've learned. The Nix syntax is in essence just JSON with functions which consists of the following building blocks: * Primitive values (strings, numbers, paths, booleans, null) * Lists and sets * Variables * Functions * Conditionals * Assertions * Arithmetic operators And that's all there is. For people familiar with programming, it should only take around 10 minutes or so to grasp the syntax. It would take much, much longer for commonly used programming languages like C, C++, Javascript, Python, Ruby, Perl, ... you name it. The official docs does a decent job at explaining the syntax[1]. I didn't have any experience with functional languages prior, but I didn't have much problem grasping the syntax once I've read through the documentation. [1]: https://nixos.org/manual/nix/stable/#ch-expression-language https://nixos.org/manual/nix/stable/#ch-expression-language
  - greatgib 5y ago
    It is not necessary what it can do the problem, but how it does it. Looking at the page you link for example: https://nixos.org/manual/nix/stable/expressions/expression-syntax.html https://nixos.org/manual/nix/stable/expressions/expression-s... <<{ stdenv, fetchurl, perl }:>> << Nix functions generally have the form { x, y, ..., z }: e where x, y, etc. are the names of the expected arguments, and where e is the body of the function. >> Strange, but let's say ok. But then, in the example, where does the function end? Then, <<"So we have to build a package. Building something from other stuff is called a derivation in Nix (as opposed to sources, which are built by humans instead of computers). >> Looking at that, I say whaaaattt? "derivation" does not mean anything obvious to anyone used to build packages. And then, as the subtitle said, did they decide to use a weird name just to confuse everyone for the pleasure? Then: << A set is just a list of key/value pairs where each key is a string and each value is an arbitrary Nix expression. They take the general form { name1 = expr1; ... nameN = exprN; }. >> So, looking at the code, from far, function, sets, everything looks mixup ...
4ad 5y ago
I don't like nix[1], but I sure hope it will overtake docker. Any theoretical foundation is better than no foundation. [1] https://lobste.rs/s/sizjqf/migrating_from_docker_podman#c_oplins https://lobste.rs/s/sizjqf/migrating_from_docker_podman#c_op...
- pxc 5y ago
  It kinda sounds like your main gripe with Nix is that it's a source-based package manager with transparent binary caching rather than a binary package manager. I think that's a mistake, but it's true that Nixpkgs suffers in some places from missing or overlapping abstractions.
DeathArrow 5y ago
>Both tools can solve the age-old problem of "it works on my machine". But Docker does much more than that. People use it especially to isolate runing software and deploy microservices.
KingMachiavelli 5y ago
Eventually? It is possible. You could probably make a thin wrapper to convert basic Dockerfiles into a native Nix system configuration. But running Docker images on Nix is easy and making Docker images from Nix is pretty easy so there really isn't a need to get rid of the Dockerfile itself. Also given that a blog post posted today is already sort-of out of date [1] when it comes to Nix, it is going to take a while. (Not that it really matters for the context of this blog post). [1] Despite being an 'experimental' feature, the future of Nix is Flakes which are most simply a function definition (inputs & outputs) with the inputs pinned via hashes.
sph 5y ago
For containers? No way, Dockerfiles are much simpler than nix configuration. For workstations? ostree is the future, not nix, IMO. Check out Silverblue. Flatpak takes care of the desktop aspect. NixOS is an interesting attempt at solving the reproducibility problem, but it hasn't been adopted because it's just a stepping stone towards a better solution. It has far too many quirks to hit mainstream, it's too complex, under documented and it's still based upon package management, which is getting obsolete as the Linux world is moving fast towards containerising everything.
- viraptor 5y ago
  There's a third use case (and possibly more): For developers of a project, where you want to manage some software per-environment, rather than via flatpak. But also want closer integration in the system, not building a new system on a side (like containers).
- pxc 5y ago
  > it's still based upon package management, which is getting obsolete as the Linux world is moving fast towards containerising everything. Container images still rely on package management. There's no fully containerized future where everything is just `./configure && make && make install`'d all the way up from Linux From Scratch or whatever. Fedora Silverblue's ostree image is still managed by dnf and RPM underneath, too.
- megumax 5y ago
  >Dockerfiles are much simpler than nix configuration I highly doubt this, Dockerfiles are simpler for a hello world microservice, but they get worse and unmaintainable when you add them lots of them with docker-compose. >ostree is the future, not nix >flatpak takes care of the desktop aspect I really hate the approach this approach, it just moves the state from the root system to the user. The root directory is immutable, but you move the whole responsability to Flatpak, which is not even comparable to nix. Meanwhile, in case of Nix, the whole system is reproducible and settings are more and less immutable. >it's too complex My whole nix config (with specific configs for vscode, neovim, chromium, wireguard, rust, python, nodejs, c++, go) is less than 600 lines of code, and it's readable. Also I configure most of my open source projects via nix as well as it's pretty easy to share the environment with the other developers. Nix works everywhere, on every linux distro, macOS and even Windows via cygwin or wsl. >under documented That's a really good point, nix maintainers didn't care much about documentation, but usability. But it looks like that's changing, they moved docs to mdbook and a team is working specifically on improving the docs
qalmakka 5y ago
Would peaches replace bananas? The comparison makes IMHO very little sense. They are different tools that solve different issues in different ways. It's true that Docker is often abused in very creative ways to do what Nix does, but it still remains a different tool with a different goal in mind.
kohlerm 5y ago
Nix will not overtake Docker because 1. The overlap is not that big 2. Nix has usability issues That being said Nix even with its usability issues works better for reproducible development environments than anything else (including Docker) ATM. Therefore in my view either Nix or something very similar will be the solution for this and replace Docker (some people run builds using Docker containers) for this use case.
jillesvangurp 5y ago
I have some experience using docker/docker-compose, like world+dog. Mostly it's good. Docker is simple, or it can be if you don't over engineer things. Simple is why docker got popular. The other reason it is popular is because it decouples to process of provisioning software from deployment and infrastructure provisioning which these days are separate activities typically done by different people/teams/organizations. Splitting responsibilities for this is a big win. If you self host all of that might be internal to your org but it still allows you to split the responsibility across teams. I have no experience with Nix. But a couple of red flags jump out of this thread for me are that "it's complicated", Haskell is somehow involved, and it is vaguely suggested that this is somehow similar to Docker. Which is clearly not the case. When it comes to putting stuff in a docker container, I guess you could use Nix. But why would you? It makes about as much sense as using Ansible or Puppet for that. Nothing against Haskell, but it evokes an image that might be a bit harsh to some but probably rings true to many: the wrong people getting excited for the wrong kind of reasons. I'm talking over-engineering here. People getting overly excited and creating a mess of hard to understand code that becomes a burden for whomever has to train up to maintain that code. People wielding hammers looking for ever more nails to wack. I've unceremoniously ditched multiple configuration languages over the years. Usually it feels good getting rid of all the over engineered crap when you realize you don't need most of it anymore. Of course the flip side is that what you replace it with might end up being similar. Been there and done that. However, I seem to only need a few lines of Dockerfile to replace what used to be a convoluted mess of puppet or ansible scripts to provision a thing that runs our thing. No longer needed. No more obsessing on how to, for example, get NTP tell the time to a server and why that somehow requires wrapping your head around a 600 line puppet module that does god knows what. Not a thing anymore. Nix sounds more like that than like Docker. I used to know people that actually used puppet to setup their laptop. Nix might be a better product for that. But I'm looking to minimize the need for that entirely. Dockerized development environments are great for that. A laptop with a browser running vs code is all you need these days. People are using freaking ipads to do development even.
cortexio 5y ago
I like the idea, but it's implemented badly. Docs are not clear and syntax is just complex and odd. Nor do i know which packages i can install, i tried to click the "packages" link on their website, but those packages seem to be for something called "nixos" which is probably something different than just "nix". anyway. it's just confusing for no reason. That being said, the concept is alot better than docker. Docker is somewhat the worst idea ever and i find the people using it always have no understanding on how software works or computers in general. As for the article, as long as nix doesnt fixes their weirdness, docker will still be used. also docker is cross platform.
Hakashiro 5y ago
Short answer (without reading the link): no. Long answer: nooooooooooooooo.
skarlso 5y ago
[flagged]
beanjuiceII 5y ago
until nix works on windows natively i wouldn't give it a second thought, what is it like on osx?
deleted 5y ago
[deleted]

327 points by potentialstyx 5y ago

dimgl 5y ago

As someone who has never used Nix, from first glance the question I ask myself is... why?

rgoulter 5y ago
Nix is difficult, but there are advantages to it. A couple of comparisons are similar: with Terraform (or CloudFormation etc.), you put in a lot of effort up front in order to reduce maintenance effort later. You could manually go through and setup a VM instance or two; but with Terraform, you have a declaration in code of what the system should be. I think another comparison is: Vim or Emacs are more difficult to use compared to using VSCode. In terms of DX, there are advantages to Emacs over VSCode. If modal editing seems to make sense, it's probably worth looking at vim. But, if you just want to get the job done right now and not fuss about learning an unfamiliar tool, VSCode is surely a better choice.
pxc 5y ago
Nix - is fast (faster than Homebrew or Docker) - is multi-user (don't need root privileges to install software) - lets you try software without permanently installing it - gives you fast, reliable undo without requiring a special filesystem - lets you automatically (re)produce a setup that never drifts from its official definition - can safely perform upgrades and configuration changes without thinking about what has been done to the system or environment in the past - has tons and tons of software already packaged for it at this point, which you can just use without any special effort

edude03 5y ago

No, it definitely (but unfortunately) will not. Nix does everything docker does better than docker does, except most crucially, integrate with non nix tooling. Nix vs Docker is like Rust vs JavaScript - you can point out every reason js is terrible and rust is better, but for the common developer looking to get things done, they’ll often gravitate to the tool that gets them the biggest impact with the least upfront investment, even if that tool ends up causing major predicable headaches in the future.

abathur 5y ago
I like to compare Nix to ice-nine from Cat's Cradle, in that it tends towards restructuring whatever it comes into contact with.
- doublepg23 5y ago
  Funny you mention that. Guix which is a fork (of sorts) of Nix is written in Guile Scheme which uses ice-9 as it's namespace in a lot of places. https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00046.html https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00...
  - rekado 5y ago
    This gets repeated a lot, but Guix really is not a fork of Nix. Not by any definition of "fork". Also not "a fork of sorts". The term "fork" only applies to one executable: "guix-daemon", which is a literal fork of "nix-daemon". They have, of course, diverged a lot, but this (and nothing else) is truly a fork. Aside from this one executable there is no relationship between the two projects. The daemon takes .drv files that list what preconditions a build has (= other .drv files), what build script to run (= a generated Guile script), and what outputs will exist when the .drv file has been processed. It processes these .drv files in an isolated environment (chroot + namespaces) where only the inputs mentioned in the .drv file are made available. The drv files are not shared among the projects; they are not generated in even superficially similar ways. Guix is not a fork of Nix. "guix-daemon" is a fork of "nix-daemon". Both are implementations of the same idea: functional package management.
    - ShamelessC 5y ago
      This fits my definition of a fork (of sorts). Thanks for the nuance though.
    - doublepg23 5y ago
      I love reading your blogs on Guix, I'll keep that in mind for future reference sorry for the libel ;)

snowytrees 5y ago

If your interested in digging deeper into building docker containers with nix this is my favorite post on the topic: https://thewagner.net/blog/2021/02/25/building-container-images-with-nix/ https://thewagner.net/blog/2021/02/25/building-container-ima.... Essentially you can use any nix package (including your own) to create the environment. And if you really want to understand it, Graham Christensen (the contributor of the buildLayeredImage function) wrote a really good blog post on how it works: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images.

bjtitus 5y ago

I've set up my new M1 MacBook Pro using Nix and it's been going relatively well. Home Manager manages global tooling like Neovim, random CLI tools, and config files while I've set up `default.nix` files to use with `nix-shell` per-project. The set up of each project can be a little tedious as I still find the language confusing but once everything is set up the reliable re-creation is excellent. I love the feeling of opening the nix shell and feeling like I have each tool I need for that project without worry of polluting my user space or conflicts between projects.

linsomniac 5y ago
My MBP left Shenzen early this morning and I'm super interested in details of how you did this. Are there any examples of doing this that you followed or recommend? Ansible is more my tooling of choice, though I'm fascinated by Nix, but I wasn't sure even how to get started with using Ansible to set up the Mac.
- linsomniac 5y ago
  I just watched this Jeff Geerling video about setting up his M1 Macs using Ansible and his provided playbooks. That's probably the direction I'll end up going. https://www.youtube.com/watch?v=1VhPVu5EK5o https://www.youtube.com/watch?v=1VhPVu5EK5o
lilyball 5y ago
I recommend also using direnv, with nix-direnv (home-manager has a setting to trivially enable nix-direnv). This lets you integrate your shell.nix environment into your existing shell without having to run `nix-shell` or use bash.
- bjtitus 5y ago
  Oh wow, this is fantastic! Thanks for the tip and I'd like to thank you for all of the work you do on nix + Darwin. I'm using your `nix-env.fish` package and it's made things much easier than when I tried this setup a few years ago.

salamander014 5y ago

I think people are missing the forest for the trees with this. In my view, the reason Docker has all the hype is because I can look at a Dockerfile, and know what's up. In seconds. Sometimes in milliseconds. It's a user experience thing. Yes, Nix is better for 'technical people that spent the time learning the tool', but Dockerfiles rely almost entirely on existing System knowledge. Yes, Nix is 'better', but the fact is Docker is 'good enough' and also 'stupid simple' to get started. Also Docker-Compose, I don't know why people hate on YAML. But it takes that same KISS attitude to build complex systems that can also be used as sanity checks for migrating to things like kubernetes. Being able to spin up a complex full stack app with one command and a compose file that doesn't take any brain cells to read is worth it's weight in gold. This is like the 'general case tool' vs 'DSL' debate. If it's easy to use, people will use it.

cbrewster 5y ago
Author here. As with most things, its all about the trade-offs. Docker has certainly proved itself and that approach has worked on a massive scale. However, its not a silver bullet. For us at Replit, our Docker approach was causing issues: our base image was large and unmaintainable and we had almost no way of knowing what changed between subsequent builds of the base image. We've been able to utilize Nix to address both of those issues, and others who may be in a similar scenario might also find Nix to be valuable. Of course Nix comes with its own set of opinions and complexities but it has been a worthwhile trade-off for us.
- AmericanBlarney 5y ago
  Those sound like issues with your Docker usage - there are options to keep base image quite streamlined (e.g. alpine or distroless images).
  - cbrewster 5y ago
    For context, I'm referencing our (legacy) base image for projects on Replit: Polygott (https://github.com/replit/polygott/ https://github.com/replit/polygott/). The image contains dependencies needed for 50+ languages. This means repls by default are packed with lots of commonly used tools. However, the image is massive, takes a long time to build, and is difficult to deploy. Unfortunately, slimming the image down is not really an option: people rely on all the tools we provide out of the box.

jonstewart 5y ago

I tried using Nix and NixOS early in the year, but documentation is an issue. Also, while I appreciate NixOS’s focus on reproducible configuration, I also have 25 years worth of mediocre Unix sysadmin experience, and it would be nice if the system found a way to accommodate Unix. My last straw was trying to get nix to schedule some task through systemd, when what I wanted was a simple crontab.

Gigachad 5y ago
Kind of a tangent, but from what I have seen, crontab doesn't actually exist on modern distros, I believe they have a tool that converts the crontab config in to systemd timers. As well as fstab.
- jonstewart 5y ago
  Yes, so I was doubly frustrated in this instance. I know the BSD-style init script system that I learned with Slackware is not geared well towards modern hardware (i.e., laptops), but it was so much simpler to read and comprehend.
  - Gigachad 5y ago
    Systemd timers do have several advantages but they come with more complexity which is why a translation layer is usually applied on user focused distros. You can enable/disable timers, trigger them manually, see when they last triggered, see when they will next trigger. And probably a bunch of other stuff. They also have individual files so automation can easily add or remove timers. For a power user, systemd timers are much better. But if you just want to quickly add one thing, it probably isn’t worth the effort to learn
- nightfly 5y ago
  Cron still exists on Ubuntu at least.
l0b0 5y ago
After having configured a bunch of crontabs, I found the Nix+systemd timers approach a massive improvement.

awinter-py 5y ago

IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud build costs. I guess this is what the article means by trouble 'sharing layers' docker buildkit (or moby buildx or wherever the branding has settled) is supposed to to improve caching, but creating a simple API for caching that plays nicely with system + language package managers would really move the needle here; reorderable package installs would be the v2

jonstewart 5y ago
You can use Nix to create a tarball that can then be launched as a Docker container. However, I haven’t figured out a way to make Nix play nicely with container image layering—you get a small container image for deployment, but you’ll have lots of such largely-duplicative tarballs in the CI pipeline and the latency for generating them is annoying.
- clhodapp 5y ago
  Have you tried dockerTools.buildLayeredImage (https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerTools-buildLayeredImage https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...)? It applies some smart heuristics (https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images) to create images made of pretty reusable layers. This is subject to some false cache misses due to some laziness in the docker's cache implementation (https://github.com/moby/moby/issues/38446 https://github.com/moby/moby/issues/38446), but that is Docker's fault not nix's and it affects dockerfile builds too.
  - jonstewart 5y ago
    No, hadn’t seen that. Thanks!
- 5y ago

cetra3 5y ago

One thing in the blog that is not true is that you can only inherit from a single layer. You can use multi-stage builds to grab & blend layers: https://docs.docker.com/develop/develop-images/multistage-build/ https://docs.docker.com/develop/develop-images/multistage-bu.... It is not as powerful as nix, granted, but it is possible.

flyinprogrammer 5y ago
Except that multi-stage builds are deceptively not grabbing or blending layers - it's simply letting you copy files from a layer. And that is a big miss. Being able to describe "now append this layer and all, but only, its file changes from this previous layer" would be pretty epic.
cbrewster 5y ago
While you can copy files from different stages, I wouldn't consider this to be the same thing as composing two base images together. Like the example in the post, you can't take the Rust and NodeJS images and tell Docker to magically merge them. You can copy binaries & libraries from one to the other but that seems extremely tedious and error prone. Whereas Nix makes it rather trivial to compose together the packages you need (eg Rust, NodeJS) in your environment.

throwaway9870 5y ago

> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue. If "aggressive" means fully, then why doesn't that fix the issue?

Volundr 5y ago
A lot of package repositories prevent this now, but theoretically your package repository could allow a new version of the package to be uploaded with the same version number. Docker tags have this issue in fact, so even your base image could change underneath you.
- throwaway9870 5y ago
  I can't imagine using a package system for building images that doesn't allow a full local cache of exactly the packages I want installed.
  - Volundr 5y ago
    I mean sure, you can absolutely retain your own docker repository, your own NPM repository, etc and then configure them in your Dockerfile before installing packages. Pretty much every technical problem has a technical solution, but it's more effort that "just" fully pinning your versions.
    - throwaway9870 5y ago
      If there are too many packages to pin, then I assume there are too many package to audit changes in for each image build you do? If that is true, how do you have any confidence that the image is going to function correct?
      - Volundr 5y ago
        I think we're talking about two different things. I'm thinking of pinning packages as say, my npm.lock specifies I will use version 2.2.19 of tailwind css. Or my Dockerfile has redis:6.2.6 as it's base image. Both of those are fully pinned, but nothing stops Tailwind or Redis from uploading new versions of the package and reusing the version number (I believe NPM actually disallows this, Docker hub does not). So my build is not technically reproducible. I can solve this by maintaining my own Docker registry, and my own NPM registry, but that's more work that just fully specifying versions in a configuration file. As for auditing changes, well most people don't. They update their dependencies and run their tests and if the tests pass, ship it! Most companies don't have a team auditing every single dependency that's pulled in, much less every update after a dependency has been approved. They simply trust the authors of Redis not to screw them. It's great if you do, I'm certainly not arguing against it, but it's far from the norm.

zamadatix 5y ago

Somewhat not related and likely dumb question but I figure folks looking at this article can help steer me in the right direction: if I want containers to act like Linux VMs what's the best option? Like Docker minus the assumption that I only want a few specific directories to persist or the idea I'm interested in layering containers in a way that lets me reproduce building them. Like if I just want another separate full instance of Alpine with it's own network view and own filesystem view and own everything but sharing the host kernel instead of being fully virtualized.

oddlama 5y ago
You might want to have a look at systemd-nspawn [1], which is basically containerized chroot based on linux namespaces. [1] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
- CameronNemo 5y ago
  I don't think you can easily use systemd-nspawn on Alpine.
- zamadatix 5y ago
  This is exactly what I needed! Thank you!
Hendrikto 5y ago
That’s basically what systemd-nspawn does.
CameronNemo 5y ago
LXD is probably the most polished option. I believe it is packaged and up to date on Alpine.
SkyMarshal 5y ago
In addition to systemd-nspawn, Kata Containers might also work for you: https://katacontainers.io/ https://katacontainers.io/

exdsq 5y ago

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get them in a Dockerfile. Build times in Haskell were bad enough but suddenly you had nix into the mix and I'd be wasting half a day as Nix built the entire world - solved with internal caching servers but have fun trying to work out how to push something to that correctly. There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. Nix seriously needs all three. It's the only technology I've ever vetoed at a startup because I've seen the hell hole it can become - perhaps not for the DevOps engineers who know it, but the team who have to suddenly work within the resulting environment.

taeric 5y ago
Funny, because I feel that simple tasks that would take minutes in my machine are now a dev adventure with docker. And I mean funny. I suspect it is different mindsets. And I personally like that both seem to be thriving.
- goodpoint 5y ago
  It's well documented that Docker and especially docker hub had a terrible impact on security. Once you factor in the efforts required in the long term to mitigate a decade of bundling gigabytes of applications and libraries it's a huge "dev adventure"
  - oauea 5y ago
    Just build your own images like you would otherwise install the software on bare metal. Base those images on official images, not community images.
    - kryptk 5y ago

dreyfan 5y ago

What's the easiest way to deploy a docker container to a VM? Preferably without ten layers of cloud provider interconnected services or expensive and complex kubernetes layers? I just want to send a container and get back an IP address I can send some traffic to the exposed port(s).

umvi 5y ago
Docker save the container image to a zip file, ftp it over to the VM, then docker load it?
reducesuffering 5y ago
Dokku. I'm a DevOps noob, just recently picked up Docker, and had such an easy time with Dokku, I decided on it for my current deploy process. Once you setup a few Dokku commands on the server, you can git commit, git push to the dokku remote and it runs your docker container automagically.

snicker7 5y ago

Guix supports exporting to Docker containers. A guix.scm file then becomes a reproducible alternative to a Dockerfile. However, Guix has its own container implementation. And this is significantly lighter than Docker (instead of layers, links to /gnu/store) and is root-less. If Guix containers had a runc-compatability layer and better docs/tutorials, it would be hard to go back to Docker/podman.

rekado 5y ago
I have been using Guix-generated reproducible Docker images for years. I'll never go back to using Docker directly. Could you please elaborate what you mean by "runc-compatability layer"? And what about the docs requires clarification? (I wrote the original Docker export backend for "guix pack", so I have an interest in improving this feature where necessary.)
- snicker7 5y ago
  I am referring to a hypothetical dockerless OCI compatability layer built on top of `guix shell --container` or `guix system container`. I sort of got this idea from runj [0], an attempt to create an OCI compatible runtime for FreeBSD jails. The main advantage is to use certain OCI-compatible tools (e.g. k8s) with Guix without needing to use Docker. [0] https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-for-freebsd-jails/ https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-...

justicezyx 5y ago

> This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. > One is a container deployment toolkit and the other is a package and configuration manager. My reading, based on the mapping from the arrangement of the 2 words Nix and Docker, is that Nix is a "container deployment toolkit" and docker "package and configuration manager". Of course, this interpretation is wrong. Further, even if applying container deployment toolkit as a description to docker, it still misses a core part of docker, I.e., docker is also a container image building tool kit. The building part and the deployment are for different steps with seemingly equal importance.

cglong 5y ago

Does Nix have an answer to Docker's support for Windows containers? The ability to mix legacy Windows applications with cloud-native ones is a huge boon for those interested in migrating to a modern stack.

pxc 5y ago
Nix doesn't have any Windows support, though there's intermittent developer interest that sometimes manifests as a demo before the bitrot sets in For now you can cross-compile to Windows using Nix and you can run Nix in WSL

paxys 5y ago

The article starts and ends with "they are very different tools for different use cases". What was even the point of writing the whole thing hypothesizing whether one will replace the other?

cbrewster 5y ago
Author here. It's titled this way because Docker seems to come up in a lot of discussions around Nix and is often compared with Nix. Partly because of their overlap in functionality but also because people may not understand the difference between the two. The goal here was to a) highlight the different use-cases between the two tools b) compare the tools in the areas that they overlap and c) show how both tools can be used together.

r3trohack3r 5y ago

I know the author calls this out - but Docker and Nix _are_ different. For immutable distribution they solve the same problem. But they solve it in fundamentally different ways. If you go back and read the last 20 years or so of LISA papers, it can be … humbling/frustrating. You can read two papers back to back, separated by 15 years, and they’ll be describing a new solution to the same exact problem that still hasn’t been properly solved. Dependency management has been horribly broken in our industry and we’ve never really managed to address it - until Nix. The Nix LISA paper [1] was a breath of fresh air, it really cut to the core of the problems with modern dependency management and addressed them head on. Docker declared bankruptcy on dependency management and just resorted to fs snapshots to guarantee bit perfect deployments. [1] https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

kristianpaul 5y ago

Hopefully Systemd eventually does.

AmericanBlarney 5y ago

InTheArena 5y ago

mac-chaffee 5y ago

One excellent crossover between Nix and Docker is https://nixery.dev/ https://nixery.dev/ If you ever need a container with a handful of well-known utils installed, just specify them in the image URL. Positively magical!

frogperson 5y ago

No, I don't think it will. A Dockerfile can be read in seconds and explained to a junior in a few minutes. Nix is way too complicated to see mainstream use.

solmag 5y ago

About to write "they aren't the same thing" as I remember Nix aliases the language, package manager and OS.

yewenjie 5y ago

I love Nix and NixOS, but sometimes it is extremely painful to get complex software which expects FHS to work. For example, I have spent a day trying to get Android Studio for React Native set up and failed.

qudat 5y ago

As far as I understand nix, the nix examples do not create a reproducible environment because it is not locking the versions down for each package, including nixpkgs. https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs https://nix.dev/tutorials/towards-reproducibility-pinning-ni...

amarshall 5y ago
Ass that article says, it’s possible but awkward. It gets better with Flakes https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
- amarshall 5y ago
  *As (oops, mobile typing)

kortex 5y ago

As TFA itself answers, "no". But I can give a different reason: nix is too much of a barrier of entry, relative to Docker. Docker might not be simple; there's a lot of moving parts to manage, some hidden gotchas, and networks are a mess. But it's comparatively easy, and once you bake an image, it's pretty simple. Dockerfiles are basically just sh. Package managers are the usual suspects. Images are easy to distribute. It's very familiar. Nix is not easy. It's a new syntax to learn, it's a new way of building, it's an entirely new way of thinking about the problem. But in the end, it does simplify packaging in the Rich Hickey sense of the easy/simple dichotomy. No braiding of packages and shared libs. But using Nix is not so simple. There's all kinds of bindings and bodges and bespoke shims to make it all work. History tends to show that easy+non-simple things beat out simple+non-easy things (devs are lazy). Easy-kinda-simple vs non-easy-kinda-simple-but-long-term-gains? No contest in my opinion. I think Nix is a beautiful idea but it's an uphill battle.

stevebmark 5y ago
I agree, there’s a reason no one uses Nix. It has terrible DX
- rch 5y ago
  Quite a few people use Nix.
- kortex 5y ago
  Well "no one" is a bit absolute. But colloquially, I know what you mean. Relative to Docker, it's way less popular. But it has 5.2k stars on https://github.com/NixOS/nix https://github.com/NixOS/nix . But yeah. The DX "needs work". which is a nice way of saying, I find it downright painful to use.
- jessaustin 5y ago
  Does it seem weird to anyone that Nix insists on installing its "/nix" directory on the root directory rather than somewhere sensible like "/usr" or even "/usr/local" ?

throwaway984393 5y ago

I only noticed recently that I have a tendency to search for reasons to use a tool. I literally googled "Do I need to learn Go?". You'd think it would work the other way around: I can't accomplish something with a language I use today, so I go searching for a language that solves my problem. Instead I'm literally looking for excuses to learn the most popular thing. It's absurd. (and really it's resume-driven development) In terms of Nix versus Docker, they're completely different levels of abstraction and solve completely different problems. Docker is (among other things... it does a lot of things) an abstraction for reproducing network services on arbitrary platforms. Nix is an abstraction for installing and setting up files.

whateveracct 5y ago

Who cares? I've spent years ignoring mainstream, "senior", etc devs' opinions on both Nix and Haskell. "Nobody uses it," "it's too complicated," "bet on mainstream X," "it's too hard to learn." Guess what? If has paid off in terms of personal efficiency - and I can make a good living doing it to boot with some effort. If you want to aim for the mountaintop, don't let the weight of cynical complainers hold you back. Remember: It takes guts to be amazing.

aitchnyu 5y ago

I used Docker Compose to, among other things, manage Postgres, which wants to listen to port 5432 and use a central dir to hold databases. Can a non Docker solution allow me to run multiple instances of Postgres?

Bayart 5y ago
Without going into stuff like Kubernetes, basically what you want is to run your postgres instances behind a load-balancer listening to 5432 and forwarding to whatever instance. The most common with postgres is probably HAProxy. If your problem is that you want to run unrelated instance of postgres... you don't really have a problem to begin with. Either use docker run to run your postgres image on different ports with different volumes, or just make a docker-compose YAML file with a bunch of postgres services. It's not like you have to have a single one.
tempodox 5y ago
Deploy them into different directories and have them listen on different ports. You can configure the deployment directory when building from source and then set the port numbers in the respective “postgresql.conf” files.
- mst 5y ago
  Right, a bunch of apps I've worked on use p3rl.org/Test::Postgresql58 to spin up a temporary postgres instance per test file - clean state and parallelisation are wonderful things to have for fast and reliable testing cycles.

greatgib 5y ago

Along my life, i have worked with a lot of build systems, but I find Nix syntax and commands to be completely awful! I see that it could be useful, but it completely turns me down immediately.

pxc 5y ago
I don't get all the hate for the Nix language. It seems really simple and flexible to me. What do you dislike about the language?
- greatgib 5y ago
  I can't really say, but when I see it, I have the feeling that it is made of the worst parts of perl, bash, javascript, ... all combined together.
soraminazuki 5y ago
The Nix syntax being complex is something that is taken for a given in online circles, but it's actually one of the most simple languages that I've learned. The Nix syntax is in essence just JSON with functions which consists of the following building blocks: * Primitive values (strings, numbers, paths, booleans, null) * Lists and sets * Variables * Functions * Conditionals * Assertions * Arithmetic operators And that's all there is. For people familiar with programming, it should only take around 10 minutes or so to grasp the syntax. It would take much, much longer for commonly used programming languages like C, C++, Javascript, Python, Ruby, Perl, ... you name it. The official docs does a decent job at explaining the syntax[1]. I didn't have any experience with functional languages prior, but I didn't have much problem grasping the syntax once I've read through the documentation. [1]: https://nixos.org/manual/nix/stable/#ch-expression-language https://nixos.org/manual/nix/stable/#ch-expression-language
- greatgib 5y ago
  It is not necessary what it can do the problem, but how it does it. Looking at the page you link for example: https://nixos.org/manual/nix/stable/expressions/expression-syntax.html https://nixos.org/manual/nix/stable/expressions/expression-s... <<{ stdenv, fetchurl, perl }:>> << Nix functions generally have the form { x, y, ..., z }: e where x, y, etc. are the names of the expected arguments, and where e is the body of the function. >> Strange, but let's say ok. But then, in the example, where does the function end? Then, <<"So we have to build a package. Building something from other stuff is called a derivation in Nix (as opposed to sources, which are built by humans instead of computers). >> Looking at that, I say whaaaattt? "derivation" does not mean anything obvious to anyone used to build packages. And then, as the subtitle said, did they decide to use a weird name just to confuse everyone for the pleasure? Then: << A set is just a list of key/value pairs where each key is a string and each value is an arbitrary Nix expression. They take the general form { name1 = expr1; ... nameN = exprN; }. >> So, looking at the code, from far, function, sets, everything looks mixup ...

4ad 5y ago

I don't like nix[1], but I sure hope it will overtake docker. Any theoretical foundation is better than no foundation. [1] https://lobste.rs/s/sizjqf/migrating_from_docker_podman#c_oplins https://lobste.rs/s/sizjqf/migrating_from_docker_podman#c_op...

pxc 5y ago
It kinda sounds like your main gripe with Nix is that it's a source-based package manager with transparent binary caching rather than a binary package manager. I think that's a mistake, but it's true that Nixpkgs suffers in some places from missing or overlapping abstractions.

DeathArrow 5y ago

>Both tools can solve the age-old problem of "it works on my machine". But Docker does much more than that. People use it especially to isolate runing software and deploy microservices.

KingMachiavelli 5y ago

Eventually? It is possible. You could probably make a thin wrapper to convert basic Dockerfiles into a native Nix system configuration. But running Docker images on Nix is easy and making Docker images from Nix is pretty easy so there really isn't a need to get rid of the Dockerfile itself. Also given that a blog post posted today is already sort-of out of date [1] when it comes to Nix, it is going to take a while. (Not that it really matters for the context of this blog post). [1] Despite being an 'experimental' feature, the future of Nix is Flakes which are most simply a function definition (inputs & outputs) with the inputs pinned via hashes.

sph 5y ago

For containers? No way, Dockerfiles are much simpler than nix configuration. For workstations? ostree is the future, not nix, IMO. Check out Silverblue. Flatpak takes care of the desktop aspect. NixOS is an interesting attempt at solving the reproducibility problem, but it hasn't been adopted because it's just a stepping stone towards a better solution. It has far too many quirks to hit mainstream, it's too complex, under documented and it's still based upon package management, which is getting obsolete as the Linux world is moving fast towards containerising everything.

viraptor 5y ago
There's a third use case (and possibly more): For developers of a project, where you want to manage some software per-environment, rather than via flatpak. But also want closer integration in the system, not building a new system on a side (like containers).
pxc 5y ago
> it's still based upon package management, which is getting obsolete as the Linux world is moving fast towards containerising everything. Container images still rely on package management. There's no fully containerized future where everything is just `./configure && make && make install`'d all the way up from Linux From Scratch or whatever. Fedora Silverblue's ostree image is still managed by dnf and RPM underneath, too.
megumax 5y ago
>Dockerfiles are much simpler than nix configuration I highly doubt this, Dockerfiles are simpler for a hello world microservice, but they get worse and unmaintainable when you add them lots of them with docker-compose. >ostree is the future, not nix >flatpak takes care of the desktop aspect I really hate the approach this approach, it just moves the state from the root system to the user. The root directory is immutable, but you move the whole responsability to Flatpak, which is not even comparable to nix. Meanwhile, in case of Nix, the whole system is reproducible and settings are more and less immutable. >it's too complex My whole nix config (with specific configs for vscode, neovim, chromium, wireguard, rust, python, nodejs, c++, go) is less than 600 lines of code, and it's readable. Also I configure most of my open source projects via nix as well as it's pretty easy to share the environment with the other developers. Nix works everywhere, on every linux distro, macOS and even Windows via cygwin or wsl. >under documented That's a really good point, nix maintainers didn't care much about documentation, but usability. But it looks like that's changing, they moved docs to mdbook and a team is working specifically on improving the docs

qalmakka 5y ago

Would peaches replace bananas? The comparison makes IMHO very little sense. They are different tools that solve different issues in different ways. It's true that Docker is often abused in very creative ways to do what Nix does, but it still remains a different tool with a different goal in mind.

kohlerm 5y ago

Nix will not overtake Docker because 1. The overlap is not that big 2. Nix has usability issues That being said Nix even with its usability issues works better for reproducible development environments than anything else (including Docker) ATM. Therefore in my view either Nix or something very similar will be the solution for this and replace Docker (some people run builds using Docker containers) for this use case.

jillesvangurp 5y ago

I have some experience using docker/docker-compose, like world+dog. Mostly it's good. Docker is simple, or it can be if you don't over engineer things. Simple is why docker got popular. The other reason it is popular is because it decouples to process of provisioning software from deployment and infrastructure provisioning which these days are separate activities typically done by different people/teams/organizations. Splitting responsibilities for this is a big win. If you self host all of that might be internal to your org but it still allows you to split the responsibility across teams. I have no experience with Nix. But a couple of red flags jump out of this thread for me are that "it's complicated", Haskell is somehow involved, and it is vaguely suggested that this is somehow similar to Docker. Which is clearly not the case. When it comes to putting stuff in a docker container, I guess you could use Nix. But why would you? It makes about as much sense as using Ansible or Puppet for that. Nothing against Haskell, but it evokes an image that might be a bit harsh to some but probably rings true to many: the wrong people getting excited for the wrong kind of reasons. I'm talking over-engineering here. People getting overly excited and creating a mess of hard to understand code that becomes a burden for whomever has to train up to maintain that code. People wielding hammers looking for ever more nails to wack. I've unceremoniously ditched multiple configuration languages over the years. Usually it feels good getting rid of all the over engineered crap when you realize you don't need most of it anymore. Of course the flip side is that what you replace it with might end up being similar. Been there and done that. However, I seem to only need a few lines of Dockerfile to replace what used to be a convoluted mess of puppet or ansible scripts to provision a thing that runs our thing. No longer needed. No more obsessing on how to, for example, get NTP tell the time to a server and why that somehow requires wrapping your head around a 600 line puppet module that does god knows what. Not a thing anymore. Nix sounds more like that than like Docker. I used to know people that actually used puppet to setup their laptop. Nix might be a better product for that. But I'm looking to minimize the need for that entirely. Dockerized development environments are great for that. A laptop with a browser running vs code is all you need these days. People are using freaking ipads to do development even.

cortexio 5y ago

I like the idea, but it's implemented badly. Docs are not clear and syntax is just complex and odd. Nor do i know which packages i can install, i tried to click the "packages" link on their website, but those packages seem to be for something called "nixos" which is probably something different than just "nix". anyway. it's just confusing for no reason. That being said, the concept is alot better than docker. Docker is somewhat the worst idea ever and i find the people using it always have no understanding on how software works or computers in general. As for the article, as long as nix doesnt fixes their weirdness, docker will still be used. also docker is cross platform.

Hakashiro 5y ago

Short answer (without reading the link): no. Long answer: nooooooooooooooo.

skarlso 5y ago

[flagged]

beanjuiceII 5y ago

until nix works on windows natively i wouldn't give it a second thought, what is it like on osx?

deleted 5y ago

[deleted]