Arch Linux Now Has a Bit-for-Bit Reproducible Docker Image

196

mmaxloh about 15 hours ago 72 commentsRead Article on antiz.fr

⚡ Community Insights

Discussion Sentiment

63% Positive

Analyzed from 1244 words in the discussion.

Discussion (72 Comments)Read Original on HackerNews

nickjj•about 5 hours ago

It is nice to have this confidence.

I ran Arch Linux for almost a year in WSL 2, it was really good.

Then I ran Arch natively for ~5 months, it's really good.

Now I still run Arch natively, but I also use the Arch Docker image to test my dotfiles[0] with a fresh file system.

Also, for when I want to run end to end tests for my dotfiles that set up a complete desktop environment I run Arch in a VM.

I have 99 problems but running Arch isn't one of them.

[0]: https://github.com/nickjj/dotfiles

MuffinFlavored•about 4 hours ago

Have you tried NixOS/flakes? What was your reaction?

nickjj•about 4 hours ago

I haven't tried it first hand.

I've written over ~10k lines of Ansible playbooks and roles to fully automate setting up servers to deploy Docker based web apps, so I do like the concept of declaring the state of a system in configuration and then having that become a reality. I know NixOS is not directly comparable to Ansible but in general I think IaC is a good idea.

It was important to me that my dotfiles work on a number of systems so I avoided NixOS. For example, the command line version works on Arch, Debian and Ubuntu based distros along with WSL 2 support and macOS too. The desktop version works on Arch and Arch based distros.

Beyond that, I also use my dotfiles on 2 different Linux systems so I wanted a way to differentiate certain configs for certain things. I also have a company issued laptop running macOS where I want everything to work, but it's a managed device so I can't go hog wild with full system level management.

Beyond that, since I make video courses I wanted to make it easy for anyone to replicate my set up if they wanted but also make it super easy for them to personalize any part of the set up without forking my repo (but they can still fork it if they want).

All of the above was achievable with shell scripts and symlinks. I might be wrong since I didn't research it in depth but I'm not sure NixOS can handle all of the above use cases in an easy to configure manner.

srik•about 4 hours ago

I have never been more stress-free than when I was running nixos as a daily driver. Had to return to macos as primary unfortunately but still use nix as much as possible.

red-iron-pine•about 3 hours ago

Presumably there is something you can plug into the CI/CD pipeline that informs everyone one you use Arch

(and, also presumably, that you do Crossfit, etc.)

juancn•about 2 hours ago

Here's a koan:

You meet a vegan crossfitter that uses Arch, what does it tell you about first?

sanufar•about 1 hour ago

Hmm, probably about the marathon they ran the other day

bloppe•about 1 hour ago

I never understood why someone would proud of the fact they're not on Slackware

kid64•37 minutes ago

I've been long fascinated by the rolling release model. But aren't you guys worried about supply chain attacks? Seems those on the bleeding edge serve as canaries in the coalmine for the rest of us.

StableAlkyne•12 minutes ago

That's the purpose of reproducible build initiatives like TFA. The idea is to ensure that identical source produces bit-for-bit identical builds on multiple machines when the packages are built.

Sure, if the source itself gets got, then it does nothing. But it at least puts up one more barrier against tampering with the artifacts.

They have a tracker for what percent of the distro is reproducible: https://reproducible.archlinux.org/

dev_l1x_be•about 9 hours ago

All docker containers should have been like that. apt-get update in a docker build step is an anti pattern.

bluGill•about 6 hours ago

You are screwed either way. If you don't update your container has a ton of known security issues, if you do the container is not reproducable. reproducable is neat with some useful security benefits, but it is something a non goal if the container is more than a month old - day might even be a better max age.

tosti•about 4 hours ago

Why is there a need for a package manager inside a container at all? Aren't they supposed to be minimal?

Build your container/vm image elsewhere and deploy updates as entirely new images or snapshots or whatever you want.

Personally I prefer buildroot and consider VM as another target for embedded o/s images.

dev_l1x_be•about 5 hours ago

I update my docker containers regularly but doing it in a reproducible, auditable, predictable way

tom1337•about 5 hours ago

Could you explain how you achieve this?

DuncanCoffee•about 9 hours ago

I know it's an anti-pattern, but what is the alternative if you need to install some software? Pulling its tagged source code, gcc and compile everything?

kandros•about 6 hours ago

Copying from another image is an under appreciated feature

FROM ubuntu:24.04

COPY --from=ghcr.io/owner/image:latest /usr/local/bin/somebinary /usr/local/bin/somebinary

CMD ["somebinary"]

Not as simple when you need shared dependencies

Filligree•about 5 hours ago

Run “nix flake update”. Commit the lockfile. Build a docker image from that; the software you need is almost certainly there, and there’s a handy docker helper.

klodolph•about 5 hours ago

Recently I’ve been noticing that Nix software has been falling behind. So “the software you need is almost certainly there” is less true these days. Recently = April 2026.

PunchyHamster•about 5 hours ago

oh, great, adding more dependency, and one that just had serious security problem

bennofs•about 7 hours ago

Both Debian and Ubuntu provide snapshot mirrors where you can specify a date to get the package lists as they looked at that time.

bluGill•about 6 hours ago

Which is only useful for historical invesigation - the old snapshot has security holes attackers know how to exploit.

liveoneggs•about 6 hours ago

pretend you don't do it and add your extra software to the layer above

rowanG077•about 8 hours ago

With a binary cache that is not so bad, see for example what nix does.

Pay08•about 8 hours ago

I don't really see how that's different from a normal binary install of a reproducible package. Especially with the lacking quality of a lot of Nix packages.

dev_l1x_be•about 5 hours ago

base image

software component image

both should be version pinned for auditing

rascul•about 4 hours ago

I disagree with that as a hard rule and with the opinion that it's an anti-pattern. Reproducible containers are fine, but not always necessary. There's enough times when I do want to run apt-get in a container and don't care about reproducibility.

bandrami•about 6 hours ago

This has been a solved problem for over two decades now with Nix but people can't be asked

dev_l1x_be•about 5 hours ago

It has been solved even without Nix for a long time, just laziness is probably why we are not doing it

malikolivier•about 8 hours ago

This is to solve such issues that I am using and running StableBuild.

It is a managed service that keeps a cached copy of your dependencies at a specific time. You can pin your dependencies within a Dockerfile and have reproducible docker images.

schonfinkel•about 7 hours ago

I don't wanna be that guy but...

NIX FIXES THIS.

dijit•about 7 hours ago

So does Bazel. :p

kippinsula•about 9 hours ago

reproducible images are one of those features where the payoff is mostly emotional until the day it isn't. we had an incident where two supposedly identical images on two machines had a three byte delta in a timestamp and it cost us an afternoon to bisect from the wrong end. boring win, but a real one.

loloquwowndueo•about 6 hours ago

How did a differing timestamp cause an incident in the first place? Curious.

bluGill•about 6 hours ago

My guess is it was the only obvious evidence of an attack.

pabs3•about 4 hours ago

More info about Reproducible Builds here:

https://reproducible-builds.org/

Closely related is the Boostrappable Builds community:

https://bootstrappable.org/

vbezhenar•about 3 hours ago

Nitpick, but I'd suggest to use "OCI Image" terminology. It runs with podman just fine.

azangru•about 7 hours ago

A totally unrelated comment; but — there is an animation on that page that moves practically everything on the page about 20 pixels down over the course of 1 second.

I thought that would completely trash the Cumulative Layout Shift core web vital. Because, hey! the layout is shifting in front of my very eyes. But no, the CLS on the page is 0.

Is CLS a misleading metric then?

chrisweekly•about 6 hours ago

It's happening as a result of a deliberate animation. The CLS metric relates to initial render. So yes, there is layout shift, but it's not CLS per se.

azangru•about 5 hours ago

> The CLS metric relates to initial render.

The CLS measures the total sum of layout shifts over the entire lifespan of a page, not just during initial render.

epolanski•about 6 hours ago

The layout isn't shifting, so it's not a layout shift.

And it's not unexpected, because it comes from a css transition.

azangru•about 6 hours ago

Sure.

It's just that the spirit of Google's core web vitals has been to measure the properties of a web page that have the most impact on users. How quickly content appears on a page, how visually stable the content is, and how long it takes the page to respond to an interaction.

In the case of this page, I don't think it can be considered visually stable at all in the first second after it's loaded.

And yet, core web vitals cannot demonstrate this.

aa-jv•about 9 hours ago

This is a really interesting accomplishment - I am also working heavily on reproducible builds for my firmware projects, and .. lo and behold .. the package manager key administrivia is the final bone to be broken.

I wonder if Arch leading the way on this will prompt other distro's to attempt the same feat. Reproducible builds are important for certification, security and safety-critical applications .. it'd be great to see Linux distros become more conformant to this method.

Pay08•about 8 hours ago

Debian already has an ongoing project for this: https://wiki.debian.org/ReproducibleBuilds.

pabs3•about 4 hours ago

And spawned a cross-distro community working on this stuff:

https://reproducible-builds.org/

cmxch•about 4 hours ago

Now reproduce it without the privacy violating age verification technology.

fragmede•about 9 hours ago

and they said compilers are deterministic...

This is a huge accomplishment! But it wouldn't be so huge if compilers were trivially deterministic. It took 5 decades of development for compilers to get here. I'm sure ChatGPT in 2073 is going to be more deterministic than it was in 2023.