Live data from Hacker News

Gocker: Docker implemented in 1.3k lines of Go

unixism.net

51–60 of 89 posts

Re: Gocker: Docker implemented in 1.3k lines of Go

#54

Honestly, I don't like lines of code as a metric for anything over the novelty amount of 1. And even then, that's usually some demonic Python list comprehension code. That being said, the code here is pretty approachable and they weren't noticeably trying to cram it into fewer lines. Like the library, not this marketing.

LoC makes a good bandpass filter. Too few and the code is usually hard to understand, too many and the code is unnecessarily bloated. Once you've been coding in a language for a while you get a sense of what's 'just right' for a complex feature (assuming you understand the feature properly).

What really bugs me about LoC as a metric though is when people don't count libraries. "I made a 3D engine in 10 lines" is just a flat out lie if one of those lines is '#include "Unreal/Engine'.

Re: Gocker: Docker implemented in 1.3k lines of Go

#57

Earlier quoted context omitted.

I can answer this one. Sometimes you have lines like this: FROM ubuntu:focal RUN apt-get -y install libssl-dev Since libssl-dev gets periodically updated (security updates and whatnot) if you build this now and build it again in 1 year you're very probably not going to get the same OpenSSL version. So it MIGHT be reproducible, but can easily give you different results depending on updates to the packages and the way…

So it's wrong (or rather uninformed) usage of Docker that leads to this, the tech itself is sound and does guarantee reproducibility.

Docked doesn’t guarantee reproducibility anymore than a tar file in that context.

Re: Gocker: Docker implemented in 1.3k lines of Go

#58
post #48

Earlier quoted context omitted.

It does an implicit guarantee though. You can match the image digests and it does verify that the image is exactly the same as you intended it to be. Docker also has trust signing now to make additional guarantees. Are you trying to claim that it's possible to have same image digests but the content of images is different?

You could say it guarantees initial reproducity -- the docker image itself stays constant -- not that it guarantees complete reproducity. I would imagine nix is the solution for that goal, though I don't know nix well enough to be confident. But an app built in a docker container is not guaranteed to have reproducible builds, because docker doesn't say anything about what happens beyond loading the initial image

NixOS does the same thing. If you tell it to load python3 it will load the latest 3.7.7. You need to explicitly tell it which version of Python3 you want, just like in Dockerfile.

Re: Gocker: Docker implemented in 1.3k lines of Go

#60
post #48

Earlier quoted context omitted.

You could say it guarantees initial reproducity -- the docker image itself stays constant -- not that it guarantees complete reproducity. I would imagine nix is the solution for that goal, though I don't know nix well enough to be confident. But an app built in a docker container is not guaranteed to have reproducible builds, because docker doesn't say anything about what happens beyond loading the initial image

NixOS does the same thing. If you tell it to load python3 it will load the latest 3.7.7. You need to explicitly tell it which version of Python3 you want, just like in Dockerfile.

That's if you're installing from a channel, because channels get updated.

If you use a local clone/submodule of nixpkgs (the git repository with the definition of all nixos packages) at a specific commit, then you will always install the exact same software, because definitions in nixpkgs all specify the exact version and the hash of all the inputs.

Post reply on HN