Live data from Hacker News

Gocker: Docker implemented in 1.3k lines of Go

unixism.net

41–50 of 89 posts

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

#41

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.

Yes, if you have constant inputs, it will produce mostly constant outputs (timestamps, etc).

But once you start getting time differential and caching, you run into... if not bugs, faults - your cached image came from a month ago, apt is now invalid. Sure, I should've used a private dpkg repository, but I want the side-effects from all of those.

A docker image I built today, is very likely to be ostensibly the same as the one I build in five minutes, but it doesn't guarantee that because its cache is at the image-level and the externalities (see: every possible step that isn't an ADD or COPY) is variadic.

It does a very valiant attempt at consistency to be clear, and I have my own gripes about it, but it's not like it creates a new planet from which technology can be built upon; It's more like creating a moon on which you can build a base, but you're still subject to the orbit of the earth.

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

#42

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.

> the tech itself is sound and does guarantee reproducibility

Does the tech guarantee reproducibility if you can use it to create un-reproducible artifacts? I don't think Docker claims anywhere to guarantee reproducible builds...

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

#44

Earlier quoted context omitted.

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

> the tech itself is sound and does guarantee reproducibility Does the tech guarantee reproducibility if you can use it to create un-reproducible artifacts? I don't think Docker claims anywhere to guarantee reproducible builds...

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?

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

#48

Earlier quoted context omitted.

> the tech itself is sound and does guarantee reproducibility Does the tech guarantee reproducibility if you can use it to create un-reproducible artifacts? I don't think Docker claims anywhere to guarantee reproducible builds...

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

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

#49
post #24

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.

While I tend to agree, I think LoC can give a sense of scale for large systems and at least a tiny bit of insight about its potential complexity. I recently worked with a client on an integration effort that had to touch many different points on a (massive, for me) codebase with tens of millions of LoC. For that, LoC was the only reasonable metric I could come up with to try and convey the scale and complexity of the…

I assume you probably can't share the client, but can you share the general domain of the software?

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

#50

Earlier quoted context omitted.

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

> the tech itself is sound and does guarantee reproducibility Does the tech guarantee reproducibility if you can use it to create un-reproducible artifacts? I don't think Docker claims anywhere to guarantee reproducible builds...

Docker guarantees run reproducibility. It does not guarantee build reproducibility although it does make it easier to achieve.
Post reply on HN