Hacker News Reader

Comment by petercooper | Hacker News Reader

There are many reasons, but the simple idea of "containing" is a big part of it. You could run several versions of Python, database systems, etc. on a single machine, but it rapidly becomes confusing in most cases with dependency clashes, losing track of where everything is, etc. Anyone who worked on multiple projects ~20 years ago and didn't use VMs might remember how it felt.

It's like if you have a workshop and you diligently organize all of the different parts into different trays in different units so it's easier to do all the types of work you need to do. You could just have a giant box in the corner where you chuck absolutely everything.. far less complex, but it'd make your day to day work a nightmare.

View on HN

I'd argue that running all of those things inside docker containers also rapidly becomes confusing. The confusion is inherent to the complexity of the things you are running.

I don't hate docker, but I find that it's just not that useful until you reach a certain scale. I stopped using it for personal projects and am much happier for it.

What do you use for your personal projects now out of curiosity?

Nothing fancy. systemd for process management, Python for automation, and a whole bunch of shell scripts. IOW the way that I did things before Docker came along.

I still believe in containers in a multi-developer environment, but in my experience the disadvantages outweigh the advantages when your only coworker is future-you.

the computer i would run the container on. I just run my software on that. If it's complex to configure, it'll still be complex to configure in docker. But then I also need to configure docker.

Executable files (and OS processes) used to be that. Then came shared libraries, configuration files, multi-executable applications, and whatnot. It would have been nicer to extend the executable formats and OS process sandboxing, IMO.

Next thing we’ll define a new format and runtime to package and run a collection of docker images with associated configuration.

I chuckled reading this, as we're trying to do exactly what you described at my current startup, https://github.com/kurtosis-tech/kurtosis ! More seriously, I've been mulling over the idea that humanity is going through a continual process of modularization and unification:

First came machines, to perform simple "computation" tasks.

Then came the computer with instructions to represent the generalized notion of computational work.

Then we wanted a way to DRY instructions so we got functions.

Then we wanted a way to package collections of functions so we got libraries.

Then we wanted a way to manage collections of libraries so we got package managers.

Then we wanted a way to distribute collections of packages so we got containers.

Now we're in a world where instantiating and configuring a collection of containers is error-prone, burdensome, and rarely portable.

Each level adds something (containers have the benefit of being language-agnostic), but the price is complexity.

> we're trying to do exactly what you described

I was secretly assuming that something like that is already being done. ;)

Recursion is fine and useful. What’s detrimental is if each layer defines conceptually same things in slightly different ways and with different terminology. Make a recursive format (like a file system) and be done with it (and/or extend it so that all levels can profit from the extension).

Yep, I agree. I've been chatting with a friend about Nix (I'm a novice) and it sounds like it has the capacity to treat many things as Just Files connected in a dependency web, which is cool.

Docker containers (in practice) can be considered to be an extreme form of distributing static binaries (snaps, flat-packs, nix, fat go binaries, pyinstaller, etc).

It is less about security and more about having several applications on the same hardware without full blown VMs.

I know people who use Nix for this... May or may not be another level of confusing though. Also, I heard it's a bad choice for JS ecosystem.

It’s a great choice for the JS ecosystem for the same reason it’s a terrible choice for the JS ecosystem: JS dependencies are a lot, and they sometimes want to do strange things at install-time that Nix frowns upon. There’s definitely an upfront cost, and a maintenance burden as well. But the flexibility and the control over what code you’re actually running could still be worth it.

The world should frown on the strange things JS and other languages do at install time and not accept it.

Reply on news.ycombinator.com