> Docker. People like to hate a winner, and they've gone the paid route, and they did just take already-available kernel features and wrap them up... But man, they did it well and they revolutionised software development and deployment.

They made design decisions that prevent simple things like "installing a .deb package from the host filesystem without keeping the package in an image layer", then fixed some of these with that weird buildkit thing that you need to enable in the settings.

It's very useful for sure, but I wouldn't call its CLI interface well-design.

Nothing is perfect and it definitely presented problems, but what other technology made cgroups that easy back then? Your choice was: VMs. And they were a pain to build and haul around.

You don't need buildkit for that; you can use multi-stage builds without buildkit to exclude your deb file from the final image.

I don’t find it satisfying: I can copy files from one stage to another, but I can’t install a .deb (or any other package for that matter).

Copying a list of paths will break if the package changes, and it can’t easily do anything done by pre-install and post-install scripts (like changing a file, registering a GPG key, etc.)

The official excuse from Docker is that “multi-stage builds cover that use”, but that’s not true if you need to install local packages. I think the buildkit feature that lets you mount folder in the build container is a hidden admission that this is wrong, but it’s annoying that the build process will then only work on machines where a non-standard option is set.

I think I understand your use case, although I don't follow the part about mounting a host dir in the build (how it would help).

I do not really consider this limitation a design flaw of Dockerfiles; this is more of a mismatch between Dockerfile functionality and what you want to do. Dockerfiles are not designed to execute general-purpose programs, so there is an assumption in the design of Dockerfiles that you know (more or less) which files you want to COPY ahead of time. It sounds like you want a mechanism for COPYing all filesystem changes resulting from a RUN instruction without having to know what those changes are ahead of time.

In the future, maybe a buildkit HLB language will provide a macro system that makes this sort of thing straightforward to implement.

> this is more of a mismatch between Dockerfile functionality and what you want to do. Dockerfiles are not designed to execute general-purpose programs, so there is an assumption in the design of Dockerfiles that you know (more or less) which files you want to COPY ahead of time.

I don't follow that. In a Dockerfile, I want to install software, and software is usually distributed in packages like .deb. Why can I `RUN apt-get install libabc` and have a clean, automatic install of libabc, but not do the same with a libabc.deb file on my host filesystem?

> It sounds like you want a mechanism for COPYing all filesystem changes resulting from a RUN instruction without having to know what those changes are ahead of time.

That's one way of doing it, but it's more complex than the obvious solution:

> I don't follow the part about mounting a host dir in the build (how it would help)

It simply lets me give the build container access to libabc.deb, so I can `RUN apt-get install /mnt/host_folder/libabc.deb`, which will install libabc without putting `libabc.deb` itself in an image layer.

It would have been trivial to add this, but the Docker devs rejected it because "multi-stage builds can do this" (wrong), and it would lead to "non-reproducible builds" (because downloading packages from the network is somehow more reproducible?).

They finally added it as a non-standard option, which means a build process that relies on it won't work with a Docker install that uses the default config. It's the devs making it needlessly hard to use Docker for a perfectly valid use case.

If you're wondering why I want to install that locally-built software via a .deb, it's because we want to distribute it to all our systems, and we want to have only one packaging method to maintain.

Just seconding Under Armour underwear - especially the mesh version. So comfortable and never sweaty!

My only complaint about the Swiss Army knife is the plastic plates on the handle didn't survive in a dishwasher – they've got warped. Still usable though.

What's your experience with Tailscale? Have you compared it to alternatives (ZeroTier, Nebula, OpenVPN...)?

What I like about tailscale is that it's a no-brainer to set up and use. I have no technical difficulty seeting up a VPN, but I really don't want the hassle of "doing work" at home. But the main reason is that my wife doesn't want me to over-complicate things. I've found myself looking only at simple solutions that work for both of us.

Gore-tex isnt that great these days, there are better options now.

It requires dwr to function, as soon as the dwr fails (pretty fast depending on your usage levels) its ability to breath ceases to function, at that point you're wearing a heavy, expensive, water proof coat that doesn't breath so it rains on the inside instead.

It's saving grace is that it's durable in heavy brush.

For a better alternative take a look at Columbia outdry, it doesn't require dwr so its breathability lasts for the life of the garment instead of requiring retreatments of dwr.

Frogg toggs are another option, way less durable but as far as breathable rain proof it doesn't get better.

Both outdry and frogg toggs are also way lighter than goretext. Though look around for the outdry they have heavy duty and light versions.