Thanks a lot for the effort you've been putting into your comments! It's not often you come across someone on the internet who wants to have a honest conversation and at the same time has empathy with the real-world people at the other end of the cable. Keep it up!
> I’m not even Christian, and it’s plain to me that there’s massive variation even within one denomination’s congregants, let alone a Baptist vs a Lutheran
That's a fair point I agree with. Still, I've met many people who seemingly put all "flavors" of Christian faith in the same negative bucket (implicitly negating the diversity among Christians you call out in your comment). In light of that, my intention was to contribue to the conversation with the very same point you are making, backed by a data point from my own experience: that there are many Christian communities in which faith is practiced in a way that enriches your life, rather than shackling you to a cult.
> It seems like you extrapolated far beyond what he said.
Was it Andrew's intention to talk about Christianity in general? Now you mention it, he might indeed have been focusing only on people "raised by conservative Christian parents".
I liked the talk and was about to post a link to it in the $dayjob slack, but this threw me off as well. Still watched it to the end, and I still recommended it to a friend (along with the Youtube channel of the "Software should work" conf), but I'm saddened that the talk paints Christianity as something that is inflicted upon you and that you should strive to get rid of.
It's clear that he had a bad experience, and I'm nobody to tell him what to put on the slides and what to leave out, but my impression is that there are lots of believers out there who do cherish their faith, experience it as a very positive force in their lives, and draw from it the power to make the world a better place around them. Speaking for myself, I'd say faith has been a net positive so far in my life.
Fun fact: some older articles were originally written using the term man-in-the-middle, but at some point were updated... except that the diagrams still use man-in-the-middle because search-and-replace doesn't work on images.
Controlling both the builder and the registry is super nice btw, because they can work together. If the builder knows some of the layers already exist in the registry, it merely has to create and push the remaining ones (without downloading any of the other layers, not even those from the base image). That gives you near-instant builds once the biggest layers are cached in the registry!
Since builds usually happen in CI, and pulls happen elsewhere (e.g., a kubernetes node), in the end layers are only downloaded when the resulting container image is actually used.
I can't comment on BuildKit, unfortunately, since I haven't used it. My experience comes from building bespoke systems (an image builder and a custom registry) fully from scratch, because we needed to have full control in order to achieve the performance we were aiming at.
I'd say the limitations are relative to your use case: `docker build` works well enough in most cases, but sometimes it's not the right tool for the job (e.g., you cannot use `docker build` inside an AWS Lambda, you can get way better performance from specialized tools in some cases [1], etc)
The idea is that, in many cases, you can create a layer "by hand" without running actual Linux programs. Layers don't need to be pre-existing, the only requirement is that they can be built programmatically (inside the browser, in this case). The demo actually does that: it "manually" creates a layer from the user-specified entrypoint script, then creates an image from the pre-existing base image's layers and the new entrypoint layer.
In a more real scenario, you can e.g., turn pip wheels into layers without actually using docker's RUN command. All it takes is to massage the data from one archive format into another, programmatically. This unlocks lots of potential (e.g., it becomes embarrassingly parallel to build a container image comprised of pip wheels). Combine that with a good layer caching strategy and a registry that takes advantage of it, and you can have near-instant container builds for arbitrary sets of pip dependencies.
I sometimes wonder why there aren't more bespoke container tools (like yours). Would people be willing to pay for stuff like what you have built, if someone took the time to "productionize" it? Or is there no market?
There are many ways to achieve this. If you are just copying artifacts, and not using RUN, then there is in principle no need to download the base image at all. Feel free to message me if you'd like to chat (email is in my profile).
Out of curiosity, is there a build setup you have seen in the past that you think could be a good replacement for this complex GitHub CI setup? Asking for a friend ;)
Update: now I've finished reading the article, my impression is that complexity is mostly inherent to this problem space. I'd be glad to be proven wrong, though!
Thanks! It's always scary when container technology fiddles with your network... I wonder how they can be at peace with such defaults. Another reason to stick with good old containerd units, I guess.