Hacker News Reader

Comment by hendry | Hacker News Reader

Just some counter arguments to @jbergknoff's well put together page!

Docker is the best medium for distributing - A static file is far easier to share / distribute.

Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al

Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable

Version pinning - a binary can embed a version and you can stick with it

Reproducible - Everyone gets confused about Docker image checksums. `sha1sum static-binary` is far far simpler.

Minimizes global state - wouldn't be a problem is people built static binaries.

View on HN

What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. The simple reality is that, there is Docker and absolutely nothing else that comes close to working everywhere. Yes, it's not perfect but everything else is far less perfect. Static binaries are far too limited; most software requires lots of files spread all around the file system.

I did a project last year at a company that had dockerized their build, CI, and CD infrastructure. They had dozens of git projects with make files that triggered actions using docker. It was great. No need to install anything complicated; just works everywhere with just a minimum of scripts installed from a single internal repository. They did some nice hacks to work around some of the things mentioned in the article. Including using virtual box on macs to work around the filesystem limitations. This really becomes a show stopper for large complicated builds that are very io intensive.

ssh to an Archlinux or *BSD box?

> What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac.

Virtual Machines. VirtualBox in combination with vagrant works reasonably well cross-platform.

Doesn't solve the same problem. You can use that to run docker of course.

Care to elaborate on your point? How is that not the same problem?

What problem does Docker solve that using a VM cannot solve?

The infrastructure for creating and sharing e.g. virtual box images does not exist. With docker I can run just about any server product you can name with a single command line invocation. Those commands don't exist for vmware, virtual box or other common virtual machine. That infrastructure simply does not exist.

> The infrastructure for creating and sharing e.g. virtual box images does not exist.

vagrant [1] provides this feature based on my understanding.

[1] https://www.vagrantup.com/docs/cli/cloud

> Static binaries are far too limited; most software requires lots of files spread all around the file system.

In my experience that is entirely and ludicrously false. That is merely how a lot of unix software does things by convention, but there are a lot of ways to make even poorly-thought-out unix software behave as a self-contained entity.

Well, yes that's exactly what docker does.

In contrast, most linux package managers seem to make a big deal about doing all of this slightly different on just about every linux distribution and even between different versions of the same distributions. The fact package managers exist proves my point: deciding which files go where is a big deal and there seem to be an awful lot of opinionated package managers making different choices here. Whatever standards and conventions exist here seem to leave an awful lot of choice and wiggle room.

> The fact package managers exist proves my point: deciding which files go where is a big deal and there seem to be an awful lot of opinionated package managers making different choices here.

Consider that "package managers" only really existed in the UNIX world until relatively recently. Other OSs just didn't make everything so complicated to begin with.

"which files go where" just isn't really a problem if you don't make dependencies some third party's problem.

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together.

But if none of those are a requirement for your use case (or you have workarounds), I agree that statically linked binaries can be a nicer solution than Docker.

You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

> You can statically link whatever you like, you just can't distribute it as one work.

How do you distribute it then? Let's assume your statically linked binary contains both closed-source code and GPL/LGPL code.

> One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

I'm not a lawyer, but that's not my understanding.

A docker image is a glorified collection of files with some metadata, just as a tar file is. I think it's broadly agreed that you're allowed to distribute a tar file with unmodified LGPL dynamic libraries in it without having to open-source all of your code, and I think docker images are treated the same way?

> How do you distribute it then?

You distribute a script and whoever runs the potential violation assembles it themselves, like with zfs on Linux.

I don't really get the demarcations typically made since a proprietary media could conceivably be as hard to pull apart as using linking tools to break apart sections of a static binary again..

I get the general sense that people work around examples of what one interpretation says isn't allowed without getting many opinions on the work around.

The distinction is meant to depend not on the way of linking, but how intimately the pieces are joined together:

https://softwareengineering.stackexchange.com/a/167781

> If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.

To extend this to archives of independent programs, they would be loosely bound, and therefore not form a single program. A docker container that exists only to package up libraries some executable is using would be closer to a single program than a collection of independent components.

Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.

If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.

I think you can escape that with CGO_ENABLED=0

Doesn’t Go just make syscalls on Linux?

This is what we do. One binary output that has all native dependencies built-in. We also use SQLite so we don't have to waste time with administering hosted SQL instances.

Ramping new developers and environments is incredibly trivial with our stack, and we do not rely on any containerization tech. Just .NET Core, visual studio, Git[Hub] and SQLite.

> You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al

What is unstable about it? As far as I can tell, only the Linux kernel interface is needed, and keeping that stable is an explicit goal of the kernel.

I believe there was a period of about a year where it wasn't possible to run Docker on Fedora 31 or higher because the former did not support the cgroups v2 interface.

> A static file is far easier to share / distribute.

Does glibc work with static linking these days? My understanding was that even with statically linked glibc, things tend to break when the host system has a different libc / a sufficiently newer glibc.

Also, how do you do OpenGL/Vulkan/etc statically? x11docker handles them more-or-less fine, but I'm fairly certain the GPU gods send you to Tartarus if you start trying to statically link in various vendors' libGLs...

> Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable.

_Fully_ agree about jails, especially nice since they're persistent. Though, for an X11-using application, I think you're screwed any way it comes out, since afaik there's no permissions difference between being able to create a window, and being able to steal keystrokes + send keystrokes to a terminal. Maybe the Qubes people have something?

Qubes people do have this issue solved. Wayland too, you have to opt-in to have an application steal all the keystrokes.

As far as security on end user machines goes, there's no reason to use Docker over Podman, except for cases where one needs to run docker in docker, which is a farse in and of itself.

Reply on news.ycombinator.com