Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will Nix Overtake Docker?

blog.replit.com

Post reply on HN
Print view View original

21–30 of 259 posts

Re: Will Nix Overtake Docker?

#21

Post by nightfly »

Gigachad wrote: post #12
jonstewart wrote: post #10

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.

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.

Cron still exists on Ubuntu at least.

Re: Will Nix Overtake Docker?

#22

Post by lilyball »

bjtitus wrote: post #4

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…

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.

Re: Will Nix Overtake Docker?

#23

Post by throwaway9870 »

Volundr wrote: post #16
throwaway9870 wrote: post #15

> 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?

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.

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.

Re: Will Nix Overtake Docker?

#24

Post by flyinprogrammer »

cetra3 wrote: post #14

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-bu... . It is not as powerful as nix, granted, but it is possible.

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.

Re: Will Nix Overtake Docker?

#25

Post by throwaway9870 »

lilyball wrote: post #19
throwaway9870 wrote: post #15

> 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?

Probably because of non-deterministic builds. Especially if the dependency pulls info from the network at build time.

I guess that would not fit my definition of "fully".

Do people really build images this way? It sounds completely insane to pull packages like that randomly from the Internet.

Re: Will Nix Overtake Docker?

#26

Post by cbrewster »

salamander014 wrote: post #9

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…

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.

Re: Will Nix Overtake Docker?

#27

Post by zamadatix »

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.

Re: Will Nix Overtake Docker?

#28

Post by cbrewster »

throwaway9870 wrote: post #15

> 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?

Author here. In our case, we had a large base Docker image called Polygott (https://github.com/replit/polygott) it pulls in dependencies for 50+ different languages from various repositories. We would pin things where possible, but its still very difficult to ensure reproducible builds.

Additionally, docker builds have free access to the network to do anything it would like. Nix goes to great lengths to sandbox builds and limit network access. Anything accessed from a network requires a pinned sha 256 hash to ensure the remote data hasn't changed. (https://nixos.wiki/wiki/Nix#Sandboxing)

Re: Will Nix Overtake Docker?

#29

Post by exdsq »

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.

Re: Will Nix Overtake Docker?

#30

Post by Volundr »

throwaway9870 wrote: post #23
Volundr wrote: post #16

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN