Didn't doubt your experience (I read and enjoy your comments all the time on HN), just pointed out that the feature set offered by single static binary (which arguably is not easy to build depending on what language you're using, etc) is not the same as what's offered by linux containerization in the current day.

Half the "static" binaries that used to float around weren't even fully static because of glibc, until building with musl (and getting bit by getaddrinfo) became widespread -- the situation is not as simple as you made it seem.

I agree with the glibc issue, but that is a problem of GCC specifically.

My point is that I see containers being overused nowadays, like "big data" that fits on a USB pen kind of scenario.

Agreed -- containers are certainly being overused these days, I find a big indicator of when people know what they're talking about is when they mention/realize that docker is containerd these days (docker is simply a shim over containerd which uses runc underneath), but it is absolutely still very buzzword-y.

I think we've basically stumbled into a very effective and widespread packaging paradigm though -- now you don't even have to pick the right language/toolset to get static binaries easily -- just throw a container over the wall and your filesystem requirements (mounts), network requirements, etc will be made pretty obvious to the person doing the deployment

Assuming that source and target hardware are the same, otherwise VMs enter into the picture, and stuff like Kata Containers add even more layers.

Then I remember Linus point of view about monolitic kernels and how they are supposed to beat micro-kernels, what for, when people put hundreds of virtualization layers on top.

Well as Docker even abstracts VMs (you can build and run a Linux/amd64 container from a MacOS/amd64 (soon MacOS/arm64 also)) the target OS and hardware become more and more just a deployment detail.

Docker doesn't abstract VMs, it rather needs one to package Linux along for the party.