News for hackers. Stuff that matters.
Re:Run More Stuff in Docker by knowhy on Sunday December 27, 2020 @03:08AM (#25549626)
Docker has a layer file system. Meaning if you do it right, that Chrome container will share the same 500 MB base image layer with the Gimp container, or whatever, making it less bloated than it appears when looking only at the footprint of the first image.

I'm not stating that I believe it is a good idea to run desktop apps in Docker containers. It is not a good idea. But it is also not true that if someone would do it, it would necessary lead to a bloated filesystem.

Docker will use a lot of disk space when using multiple base images.

Re:Run More Stuff in Docker by michaelt on Sunday December 27, 2020 @06:34AM (#25550340)
> that Chrome container will share the same 500 MB base image layer with the Gimp container, or whatever

Only if they’ve all chosen the same base image.

And if application developers could all agree on a fixed base image with fixed versions of dependencies, that’d be a Linux distro and we wouldn’t need docker to begin with :)

Re:Run More Stuff in Docker by sverhagen on Sunday December 27, 2020 @04:20AM (#25549888)
I fully agree with the original premise (to run more stuff in Docker). But if I maintain two tools, both using Docker, let's say they're both built in Python, they'll both be in their own Git repository, and their build pipelines will come up with independent Docker images for whomever wants to use those tools, and it seems like frivolous maintenance, if not an anti-pattern, to make sure that these tools are always using the same base image. And yes, if bandwidth and disk space were constraint for me, I'd probably reconsider (even on the original premise), but they are not.

By the way, while I think you should run more stuff in Docker, I also think it is still totally reasonable to have your "main language stuff" installed "normally" (not in Docker). If I'm a Java developer, I'm "happy" to deal with Java's dependency b.s. on my normal system. Meanwhile, if I ever have to touch Ruby, I do not want to deal with Ruby's dependency b.s. on my normal system (rather run that in Docker). And vice versa, as I'm sure.

Re:Run More Stuff in Docker by solarengineer on Sunday December 27, 2020 @05:11PM (#25554720)
As a Ruby, Node or Python language user, you may want to try rbenv, nodenv or pyenv respectively.
Re:Run More Stuff in Docker by pdimitar on Tuesday December 29, 2020 @06:35AM (#25568839)
Or the ASDF version manager that covers all of them, and much more.
Re:Run More Stuff in Docker by Kwpolska on Sunday December 27, 2020 @01:09PM (#25552929)
Both of your Python projects will likely have `python:latest` (or such) as their base image. Sure, they will diverge after that (with further layers for dependencies and your code), but at least the base system will be shared.
Re:Run More Stuff in Docker by sverhagen on Sunday December 27, 2020 @10:26PM (#25556420)
Even if they used python:latest (as if that is the only flavor), they're only "latest" when I do my build. So, now I have to coordinate builds and releases. Unlikely to happen, and, again, an anti-pattern.
Re:Run More Stuff in Docker by LucasLarson on Sunday December 27, 2020 @09:29AM (#25551250)
> If I'm a Java developer, I'm "happy"

Oh yes, it would make me "happy", too.

Re:Run More Stuff in Docker by foepys on Sunday December 27, 2020 @06:21AM (#25550301)
We all know that his doesn't work in practice. Somebody will "urgently" need another dependency and build a new base image with this dependency inside. Or a security patch comes out and half of the developers update while the rest doesn't. Do this 4 or 5 times and you'll have the exact same fragmentation.
Re:Run More Stuff in Docker by dimitar on Sunday December 27, 2020 @04:31AM (#25549927)
That is if you are using one base base image. Most likely you will be using Alpine, Ubuntu, Debian, Centos, Red hat, Oracle Linux and who knows what else in different containers, unless of course you have the patience to repackage all then versions you need for your favorite base image.