Hacker News Reader

Comment by wtetzner | Hacker News Reader

> Do you get anything when not using NixOS to manage everything?

Sure, I think the biggest benefit is being able to get a temporary environment for a project. You can have all of your dependencies pinned, even for languages that don't have package managers, and for mixed-language projects. You can get easily get a shell that contains the exact compiler versions, libraries, etc. from a single config file, and it's isolated from the rest of the system. I guess it's kind of like having a lighter-weight container.

View on HN

It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc.

With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store directory--the process you run is exactly the same as whatever you're running in docker.

One crucial difference is that nix does nothing for network isolation, you have to do all that on your own (if you need it).

Nix doesn't do network, PID or filesystem isolation.

That's a feature. I don't normally want any of those.

You don't have to use them, docker has flags to disable things like network isolation. If you want to go deeper systemd-nspawn doesn't isolate anything (network, pid, user, etc.). And if you are some anti-systemd zealot the plain old chroot command does what you want too (and has done so for decades).

Except none of those solutions are package managers, are they? The thing that's nice about nix is that you can just specify which packages you want by name, and easily get them in your path.

My thoughts exactly. Container-based development environments has a Cygwin-like clunkiness to it. But even clunkier because of the default lack of access to the host system, and the additional burden of having to manage multiple containers.

Just to be clear, Cygwin is a great project. But it's not something I'd actively choose over a native Linux system if I had the choice of operating systems.

It’s a lot lighter in terms of disk space. Yes, drives are cheap, but even so, bringing in a different version of debian-slim for every executable gets bloaty. I routinely reclaim 10s (sometimes 100s) of gigs with a podman system reset.

Also in RAM. You don’t want to runa whole-ass container for `ls`.

No a process running in docker or on your host is going to use the same amount of RAM. There is no RAM dedicated to a running container on Linux--it's just a process that's flagged with some metadata to tell the kernel that it should be isolated in certain ways, like with a unique root filesystem.

Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.

Your kernel is fine at managing the container root filesystem and paging in and out parts as necessary. It's not just loading gigabytes of root fs into memory and calling it good.

Files still take up space on disk.

Paging still has a cost.

By lighter-weight, I simply mean conceptually, not necessarily computationally.

The biggest advantage is the ability to reproduce your mutable environment‽ You get more advantages when the whole environment is reproducible.

Reply on news.ycombinator.com