Nix at Scale | Hacker News Reader

Nix at Scale

lwn.net

66 pointstitaniumtown18 comments

If you want minimal deterministic containers with low complexity and high supply chain integrity, check out stagex, which is a distro purpose built for this problem: https://codeberg.org/stagex/stagex

Some of the ways it compares to nix/guix is included as a table in the readme.

Hi, I’m the author of the talk on module contracts. Thank you so much Daroc Alden for the great write-up! Happy to answer any questions.

Video available anywhere?

https://youtu.be/G2uN7cw-PaU?t=4333 Apparently the Scale people don't know how to do chapter marks on youtube.

That video should be cut at some point and split into individual ones. True though chapter marks would be an easy solution.

Mods, can we expand SCALE to Southern California Linux Expo in the title so people can tell what this is about?

I personally was very disappointed to read nothing about how awesome Nix is at scale, but did learn a few things about how awesome Nix is at SCALE.

I typed "Nix at SCALE" as the title. Seems HN decided SCALE wasn't an acronym.

Nix has been a great boon for my workstation. I can effectively stage changes before going through with them, and rollback is quite simple too. It is great to have an immutable environment with which to test changes upon.

> Iaso explained that layer ordering is "an illusion" that doesn't actually impact the functionality of the image (unless one layer overwrites a file provided by another layer), and that Nix picks an arbitrary order.

Wat?

Occasionally this is the entire purpose of a layer.. is it true it's unreliable? Or only non-deterministic under Nix? I thought deterministic builds are a huge selling point with Nix (admittedly, I haven't tried it yet, because intimidated and my existing tools don't irk me enough to bite the bullet.. yet).

I didn't attend the talk, but Nix's dockerTools doesn't need to worry about layer ordering because there is no chance of a layer overwriting another (most layers just write to their respective /nix/store/hash-pkgname directories, which is guaranteed to be unique by Nix).

You're right! All layers except the topmost layer consist of non-overlapping store paths. It's not one-path-per-layer as there's a hard limit on number of layers, so we smush the packages "deeper" in the dependency tree together within a single layer. There was some work recently where you could specify which paths should correspond to which layers but I can't recall the exact function.

You do have the ability to add a "customisation" layer on top of your image in case you want to create some directories or run arbitrary modifications which does end up as an extra layer which _can_ override the previous layers hence it's always the topmost. But you usually don't need it.

Source: I did a large-ish refactor to the `buildLayeredImage` functions a couple of years ago. My contribution was adding a `streamLayeredImage` function where you can "stream" a derivation to a Docker image on-the-fly without copying any files/layers in the disk.

Nix puts images together in a way that there shouldn't be any overwriting, only additions. If your layers are all additions without any overwriting then the order would be unimportant.

There could be some edge cases I'm not aware of, but from what I know, it should be all additions.

Arbitrary can still be deterministic

s/Scale/SCALE/g

I originally copied the title "Nix at SCALE", seems HN auto capitalized SCALE as a word.

Apparently, Scale here is not what people commonly mean. Clickbait!

The original headline makes it clear with its all-caps SCALE, that we aren't talking about the usual meaning of the word.

Reply on news.ycombinator.com