Shoutout to Rancher Desktop
A decade of Docker containers
241–250 of 275 posts
Re: A decade of Docker containers
#242I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…
> But the Dockerfile has continued because of its flexibility. The flip side is that the world still hasn’t settled on a language-neutral build tool that works for all languages. Therefore we resort to running arbitrary commands to invoke language-specific package managers. In an alternate timeline where everyone uses Nix or Bazel or some such, docker build would be laughed out of the window.
This calls for https://xkcd.com/927/.
Re: A decade of Docker containers
#243I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up t…
What's a good alternative if I want to self host and convenience? I have some hobby sites I host on a VM and currently I use docker-compose mainly because it's so "easy" to just ssh into the machine and run something like "git pull && docker-compose up" and I can have whatever services + reverse proxy running. If I were to sum up the requirements it would be to run one command, either it succeeds or fails in it's ent…
I don't know, that set of requirements sounds like containers are a good fit. I don't have an alternative for you. I would just ssh into the server and run the commands needed to update/start the services; it wouldn't be one command and it is not impossible to mess up.
I will say that consuming other people's services that I don't intend to develop on is easier with containers. I use podman for my jellyfin and Minecraft servers based on someone else's configs. My only issue with them is the complexity during development.
Re: A decade of Docker containers
#244I always wanted to use docker. Installed it and every time there was a feature i needed not included. Perhaps its because tried to use a technologie not commonly used
What kind of features?
Re: A decade of Docker containers
#245Earlier quoted context omitted.
> This nuance is something that only the nix model started to capture at all. Unpopular opinion, loosely held: the whole attempt to share any dependencies at all is the source of evil. If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data? Which could plausible be deduped at the filesys…
> If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data? Honestly, I've seen projects that do this. In fact, a lot of projects that do this, at the compilation level. It feels like a lot of the projects that I would want to use from git pull in their own dependencies via submodules when…
Maybe the RAM crunch will get people optimizing for dedup again.
Re: A decade of Docker containers
#246Re: A decade of Docker containers
#247Re: A decade of Docker containers
#248Earlier quoted context omitted.
Great point about coding agents! Back then, Docker gave us 'it works on my machine, let's ship the machine'. Now, AI agents are giving us 'I have no idea how this works, let's ship the prompt'. The early Docker community spirit really was legendary though—before every hyperscaler wrapped it in 7 layers of proprietary managed services. Thanks for the memories and the write-up!
It seems that your entire profile is LLM generated comments, would appreciate it if you'd stop. Thanks.
I think you're too concerned with how others speak to believe that someone can actually write good, well-written comments. Obviously, in the age of LLMs, we might use one or two things to produce a better response. But that doesn't mean I don't think about what I wrote. Especially since English isn't my native language. Anyway, don't worry about me!
Re: A decade of Docker containers
#249Earlier quoted context omitted.
It's not materially any different from maintaining lines in a Dockerfile.
It is mateirially different compared to "maintaining" the line 'RUN apt-get -y install foobar'
Is it though? If the way that I’m going to edit those files is by typing the same natural language command into Claude code, and the edit operation to maintain it takes 20 seconds instead of 10, to me that seems pretty materially the same
Re: A decade of Docker containers
#250A full decade since we took the 'it works on my machine' excuse and turned it into the industry standard architecture ('then we'll just ship your machine to production').
I think it was all about efficient large-scale server machine reproducibility and not about making local development workflows easier. If it were i'm sure Docker would look much more friendly for that case but it still advanced to an industry-standard even for small software departments because everyone used it.