Hacker News Reader

Comment by me551ah | Hacker News Reader

The whole point of docker was to have reproducible builds. What runs on the dev machine also runs on the server. But M1 macs change that in a major way. There might be bugs or available features in ARM versions of popular software, so what works on a dev machine might not work on the server and vice-versa.

View on HN

Containers don't have anything to do with reproducible builds, docker advocates just happened to misuse it for that purpose.

Do they? Having a stable starting point for the “machine” you’re building on contributes to having reproducible builds does it not?

Maybe kinda, but really you'd want reproducible cross-compilation too, so a reproducible build should produce the same binary regardless of which machine it is run on.

"Identical binaries" is not the same thing as "reproducible builds". It's maybe one aspect of one type of CI/CD, but I would say not even the majority.

I meant "reproducible builds" in the sense of: https://reproducible-builds.org/docs/definition/

> A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

Only the scenario where development and target machine match 1:1 in hardware and underlying software stack.

Just changing the kernel under which the container runs can break havoc on the "reproducible" build.

I disagree on the importance you’re putting on what I think are edge cases for most development. When I’m building a binary, the biggest issue I tend to run into is the “machine” I’m building it on. Docker allows that “machine” to have reproducibly equivalent dependencies. Same version of Node, .NET, Java, etc. I don’t see how the kernel really matters that much here. I’ve never once cared what Linux kernel I’m on, but I can’t count the number of times I’ve had to figure which exact version of Cordova I need with Ionic or whatever mess of dependencies I need.

well, docker containers have an md5 sum. I think that's pretty reproducible.

(although yes, the base filesystem might be different)

I get what you're saying since it's a different architecture entirely, but it's not as if you run EXACTLY the same hardware as your server (e.g ECC RAM, number of physical processors, things like AVX-512, etc).

For that use case, you should continue to run x86 images. Unless there is a bug in underlying virtualization frameworks, you’re extremely unlikely to ever see that kind of issue.

That has come up already. The M1 does thread local storage in a different way than other aarch64 CPUs.

http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon....

It’s not the M1 chip by itself, but rather is macOS/iOS.

I think it's both. Mimalloc had to use a different register: https://github.com/microsoft/mimalloc/issues/343

It’s the macOS/iOS ABI solely. It isn’t related in any way to the hardware itself.

What if your server is also running an ARM CPU though? For example with AWS Graviton

Or Raspberry Pi? (Only mildly /s).

Reply on news.ycombinator.com