Hacker News Reader

Comment by palmfacehn | Hacker News Reader

When I encounter a README/INSTALL that advises Docker, I start to suspect that the package is a mess. I'm sure there are legitimate usages within enterprise-y scenarios, but it has commonly become a way to paper over other issues.

View on HN

Yep, people here hate the organically built Lisp save and die images, but many open source and in company repositories with docker are very similar: they got it working on their computer inside docker through manually changing, rearranging and writing scripts, many of which reverse things from other scripts, update packages installed higher up in the same script etc etc and then just published it as it works. So trying 'make' or whatever outside the container simply errors out as it wont work anywhere else but in the very specific confines of the linux inside the container. The difference is pretty clear: if the readme starts with how to run the project without docker but also has a docker, the setup is clean, if it starts with docker and then, maybe, points to a separate docs dir with random 'notes' how to run locally, you know it will be a mess you probably never want to try (outside running docker).

This is definitely true. You see it constantly in deep learning applications, where eg NVIDIA’s fancy fp8 stuff needs C++11 ABI, so they need to compile torch from source, which means everything with C++ dependencies on torch needs to be recompiled, and eventually it’s much easier to ship a container image. It can be done with an Ansible playbook, sure, if you don’t have to ever do anything else with your machine.

One of the best things about docker that is not mentioned often enough is how it keeps your host machine clean.

Isn't it also true that not every library needs to be deployed system-wide?

I find that many of these poorly maintained build systems have very little to do with native code. Often it is a node.js server + frontend or in the case of AI, python. Some of this seems related to the current norms in those ecosystems.

When I encounter a README/INSTALL that doesn’t provide docker instructions, I move right along. I’m not (1) using my precious time to figure out how to get your instructions for your machine to work on my custom configured environment (docker solves this), and (2) I’m not polluting my host machine with your crap (docker solves this too).

Docker is not about enterprise. It is about having a standard format for relaying configuration and install instructions to produce a reproducible dev or production environment on any hardware or OS.

If you don’t take the time to do that with your open source project… yeah I ain’t touching it with a 10ft pole.

I think one big issue is fundamental build differences between Linux and macOS. So many things build beautifully for one platform and not another, and it’s really frustrating to just want to use some piece of software that is not tested on another platform because the devs just don’t have a Mac.

I agree that it papers over underlying portability issues, but I personally don’t want to deal with some generous maintainer who built a good piece of working software but with no MacOS support.

"We paid zero attention to the absolute hell of dependencies we were creating for ourselves, and eventually decided to just ship a docker image of the smart intern's laptop "

Reply on news.ycombinator.com