Hacker News Reader

Comment by qbasic_forever | Hacker News Reader

Colima is all you need now, it's basically a drop in replacement for docker desktop. There are actually very few container runtime engines (containerd and runc are the big ones) and all the tools you read about just wrap that lower level container runtime. They're all the same when you get down to it and just have different opinions about config, networking and storage.

View on HN

Every tool says its the same but they aren't. You'll eventually run into some issue that wouldn't have happened on Docker, and as soon as a dev spends two hours on it you've paid more than you would have paid for a Docker Desktop license for that dev for the year.

To be fair, you'll run into issues with Docker Desktop too though. I've found Rancher Desktop to be as reliable or better than Docker for my needs.

Why not using Nix? No container needed, so it's much simpler, and the software selection for aarch64 (i.e. M1) is enormous.

Doesn't NixOS require reboot after each software install? I don't remember the last time I restarted my Mac or even PC.

I believe NixOS does not (there's a "nixos-rebuild switch" command that sounds vaguely like it requires a reboot, and NixOS does aim for declarative confgs, but it knows how to restart services etc. without rebooting your whole machine - see chapter 3 of the NixOS manual: https://nixos.org/manual/nixos/stable/index.html#sec-changin...)

But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.

Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.

Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.

nixos-rebuild switch does not require a reboot. In fact, you'd typically use nixos-rebuild boot if you don't want immediate changes.

For very complicated reconfigurations, it might be advisable to reboot if that involves changes to services that are only started during boot time. But that's the case for nearly any OS...

I mean Nix on a Mac, as a package manager, not full NixOS. Linux is still not totally ready on M1 machines.

And of course it does not require a reboot.

`containerd` invokes `runc` (and `docker` can also invoke `containerd` via its API, which then invokes `runc`). The "lower level container runtime" is cgroups and various kernel namespaces (primarily process and network, but some others are included). There's no magic there.

They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".

The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.

I recently switched from Docker Desktop to Rancher and it seems to not slow down my Mac so much.

Does Colima work with Docker Compose?

Compose is a layer on top of the Docker client/API, so the container runtime provider shouldn't matter, I guess as long as there's a real dockerd under the hood, and modulo any bugs.

Rancher lets you choose between dockerd and moby. Does that mean Colima also uses dockerd?

Reply on news.ycombinator.com