alexanderniki

There is something I still can't get about #Docker. It's the trend to distribute even small simple scripts or apps as containers.

There are definitely some cases when we have to distribute, deploy and run large complex software. And those cases are completely understandable and Docker (or any other containerisation) is good for it.

But when I see, let's say, a simple #Python tool distributed as a container, I see the same problem as with #Electron but even worse. Instead of running a browser, here we have to run almost whole operating system in a sandbox wich is almost like a virtual machine.

To me it looks like an insane overkill and overengineering.

Jun 7 at 10:12amWeb
Show threadMatthew Martin3d ago

@alexanderniki Imho, the motivating reason is to deal with popular pypi packages getting highjacked and replaced with credential stealers that can run without any more user interaction than the initial install.

If the concern is transitive dependencies, then venvs are enough. If the concern is malice, there are no other good lightweight containers other than docker.

There are a lot of creative efforts to create lightweight sandboxes (bash fork that can't write to file system, port to wasm, etc

Show threadMatthew Martin3d ago

Whalebrew turns all brew installs into containers. https://github.com/whalebrew/whalebrew

my version for python is still pretty alpha https://github.com/matthewdeanmartin/safe_whale

GitHub - whalebrew/whalebrew: Homebrew, but with Docker images

Homebrew, but with Docker images. Contribute to whalebrew/whalebrew development by creating an account on GitHub.

GitHub
Show threadC.3d ago

@alexanderniki

A lot of the time, it's not over-engineering - the opposite, in a way. I have seen it used far too often to just take an engineer's development environment and ship it as the final product.

You know, avoid all that extra work of developing an installer, documenting the requirements / dependencies / etc.

Show threadGlyph2d ago
@alexanderniki a docker container is a unit that can be meaningfully tested for end-user consumption. A python script is not. The script has no way of locking down the exact Python interpreter that it has actually been tested with. It cannot ensure that your OpenSSL was built such that it’s not going to have an obscure import/link-time error. And sure, this stuff *doesn’t usually* happen, but at a scale of “public internet”, “doesn’t usually”==“at least often enough to cause a support headache”
Show threadGlyph2d ago
@alexanderniki *in theory* you could also have some precise kernel-level dependency which causes incompatibility, but in that case the kernel’s very serious “don’t break userspace” policy is actually strong enough that it empirically matters. No distro has anything remotely guaranteed like that, and certainly no user-provisioned Python environment ever could
Show threadkeithzg2d ago
@alexanderniki Developers looked at the problem of shipping code that is robust and documented enough to run broadly or at least point users to how to get it to run, and decided to just ship their development environments :P

"Works on my machine" coming to its natural conclusion.