3 ms·

I hope Docker is not the final answer to reproducible and isolated processes because it’s a bit too complex and slow on anything other than Linux, IMO. Linux v

I hope Docker is not the final answer to reproducible and isolated processes because it’s a bit too complex and slow on anything other than Linux, IMO. Linux virtualization almost became a mandatory feature of a modern OS because of it. I wish there was something that would run on any POSIX, but that’s probably not enough ground to cover complete reproduction.

armchairhacker 4y ago
My hope is that a lot of the difficulty in getting reproducible builds is caused by outdated libraries and techniques. For example, assuming that your code is in /usr/bin or /usr/lib, so any package manager has to emulate that. My hope is that eventually, you can just run `cargo build --reproducible` or `meson build --reproducible` or `make --reproducible`, and if your architecture is the same, the dependencies will be the same and the output will run exactly the same. Even going as far as to install an older cargo or meson or CMake if that's what's needed for backwards compatibility. And if you want to be safe, you can create a sandbox or "jail" and libraries will know how to deal with it instead of just crashing when they try to access something outside.
- 3836293648 4y ago
  cargo build --locked There is a lockfile, even if it's not respected by default. Doesn't help with build.rs being able to do whatever it wants but it's better than default
- IshKebab 4y ago
  I don't think that will ever really work reliably for something like cargo or meson. They don't really go to any effort to ensure clean build environments, enforce dependencies, sandbox builds etc. You need something like Bazel for that really.
jitl 4y ago
“Docker but it’s just a chroot”?
- tambourine_man 4y ago
  Yeah, you kid, but you know, it would solve a lot of the most common problems. Like a parent mentioned, most of the time you're just not linking to the right libraries. That’s it. Do we need to ship a whole kernel, have terrible IO and jump through a lot of hoops just for that?
  - jitl 4y ago
    I’m not kidding! I hacked together a bunch of env vars, carefully ordered tar unpacking, and some chrooting for dev envs at Airbnb years ago. It’s effective.
    - tambourine_man 4y ago
      Sorry, sarcasm is hard on the web. I think you were/are into something. I though about it but never managed to build it.
    - schaefer 4y ago
      Before docker was invented, I worked on chroot based dev environments at work too (linux host), and I loved it. But I’ve never really touched Mac OS. Does Mac OS natively support this style of development? Do you know of anyone that’s blogging about it?
      - tambourine_man 4y ago
        It doesn’t. My hope was if Apple and Microsoft provided this feature, we could build a common foundation on top.
        tambourine_man 4y ago
        I'm wrong, turns out, chroot works on the Mac after all. Nice, that's a first step. I'll try to play with the idea
        4y ago
jrockway 4y ago
I don't think Docker is particularly reproducible. It has less understanding of dependencies than a Makefile. Not only does the cache rarely save build time, it is also very unlikely that two developers running the same Dockerfile end up with the same bytes in their generated image. (The classic example is "FROM ubuntu:latest; RUN apt-get update && apt upgrade". No clue what's going to be in that image, it's different every time. You can pick a particular well-known build of the Linux base, but there is no lockfile that controls what apt upgrade is going to do. Even if you avoid that, esoterica like build tools that put the current time into binaries will bite you. Other build systems have a sandbox that lets you fake those tools out, so if your control file says the build time is 10 PM on Friday, then the next time you build it it's also 10 PM on Friday.) Docker also conflates too many concepts; layer generation, image distribution based on layers, registries and tags (mutable! wtf?), cgroups, PID namespaces, network namespaces, storage namespaces, etc. I'm sure it was a godsend for a certain type of workflow (one that depends heavily on the OS base; shelling out to utilities, using programming languages with poor dependency management systems, etc.) but for the average modern codebase, it seems like a detriment to me. I see people doing full builds of their app every time they want to test a change (often downloading 100s of packages from the Internet), simply because that's how Docker does things, and that honestly isn't right. They're throwing their time away for no good reason.

armchairhacker 4y ago

My hope is that a lot of the difficulty in getting reproducible builds is caused by outdated libraries and techniques. For example, assuming that your code is in /usr/bin or /usr/lib, so any package manager has to emulate that. My hope is that eventually, you can just run `cargo build --reproducible` or `meson build --reproducible` or `make --reproducible`, and if your architecture is the same, the dependencies will be the same and the output will run exactly the same. Even going as far as to install an older cargo or meson or CMake if that's what's needed for backwards compatibility. And if you want to be safe, you can create a sandbox or "jail" and libraries will know how to deal with it instead of just crashing when they try to access something outside.

3836293648 4y ago
cargo build --locked There is a lockfile, even if it's not respected by default. Doesn't help with build.rs being able to do whatever it wants but it's better than default
IshKebab 4y ago
I don't think that will ever really work reliably for something like cargo or meson. They don't really go to any effort to ensure clean build environments, enforce dependencies, sandbox builds etc. You need something like Bazel for that really.

jitl 4y ago

“Docker but it’s just a chroot”?

tambourine_man 4y ago
Yeah, you kid, but you know, it would solve a lot of the most common problems. Like a parent mentioned, most of the time you're just not linking to the right libraries. That’s it. Do we need to ship a whole kernel, have terrible IO and jump through a lot of hoops just for that?
- jitl 4y ago
  I’m not kidding! I hacked together a bunch of env vars, carefully ordered tar unpacking, and some chrooting for dev envs at Airbnb years ago. It’s effective.
  - tambourine_man 4y ago
    Sorry, sarcasm is hard on the web. I think you were/are into something. I though about it but never managed to build it.
  - schaefer 4y ago
    Before docker was invented, I worked on chroot based dev environments at work too (linux host), and I loved it. But I’ve never really touched Mac OS. Does Mac OS natively support this style of development? Do you know of anyone that’s blogging about it?
    - tambourine_man 4y ago
      It doesn’t. My hope was if Apple and Microsoft provided this feature, we could build a common foundation on top.
      - tambourine_man 4y ago
        I'm wrong, turns out, chroot works on the Mac after all. Nice, that's a first step. I'll try to play with the idea
        4y ago

jrockway 4y ago

I don't think Docker is particularly reproducible. It has less understanding of dependencies than a Makefile. Not only does the cache rarely save build time, it is also very unlikely that two developers running the same Dockerfile end up with the same bytes in their generated image. (The classic example is "FROM ubuntu:latest; RUN apt-get update && apt upgrade". No clue what's going to be in that image, it's different every time. You can pick a particular well-known build of the Linux base, but there is no lockfile that controls what apt upgrade is going to do. Even if you avoid that, esoterica like build tools that put the current time into binaries will bite you. Other build systems have a sandbox that lets you fake those tools out, so if your control file says the build time is 10 PM on Friday, then the next time you build it it's also 10 PM on Friday.) Docker also conflates too many concepts; layer generation, image distribution based on layers, registries and tags (mutable! wtf?), cgroups, PID namespaces, network namespaces, storage namespaces, etc. I'm sure it was a godsend for a certain type of workflow (one that depends heavily on the OS base; shelling out to utilities, using programming languages with poor dependency management systems, etc.) but for the average modern codebase, it seems like a detriment to me. I see people doing full builds of their app every time they want to test a change (often downloading 100s of packages from the Internet), simply because that's how Docker does things, and that honestly isn't right. They're throwing their time away for no good reason.