Earlier quoted context omitted.
A MacOS App is just what you need to run the app on MacOS. A Docker Image is essentially a mini operating system in a can. Most Docker images contain shells, the entire Python install, an init sequence... piles and piles of redundant stuff. If you are running a Docker image on MacOS or Windows, you first have to start docker which is itself a Linux Virtual machine. Docker is a great dev tool, but if you don't need it…
I think you are responding too literally to his comment, which is spot on. A macos app is running in a sandbox and runs in a conceptually similar way to docker. Go look in ~/Library/Containers also look at the filesystem under .app
Run More Stuff in Docker
211–220 of 293 posts
Re: Run More Stuff in Docker
#212Re: Run More Stuff in Docker
#213Earlier quoted context omitted.
> Docker is intimately tied to Linux. Linux and windows: https://hub.docker.com/_/microsoft-windows
Have you used a windows only container? I've not seen one in the wild, but I might be terribly biased.
Re: Run More Stuff in Docker
#214I wish there were real / usable Windows containers out there. I'd love to spin up a quick sandbox to run a MSVC / MSBuild, but the smallest "image" in Windows-land for that is 12Gb. Still use Docker alongside WSL2 for purely-Linux stuff like some node.js scripts or python things that don't need GPU.
Re: Run More Stuff in Docker
#215If you are running mainstream Linux(Debian-based/Arch-based, probably other), most of the Docker profits can be achieved with already installed and configured systemd and your distro's package manager.
Sandboxed? systemd.
Simple, uniform interface? Your distro has packages, and most likely services that can and should be sandboxed already run in systemd after installation, you can tune unit-file if you want, and systemd has security checker, that shows you what application in the sandbox can and can not do, without proxying things the Docker way.
Versions pinning? Pin version with your package manager. Want multiple versions? Check out DebianAlternatives system.
Reproducible? Fix your build/install configs, not the environment. If it builds on your machine, but not on the other, or run flawlessly on one, but not the other, it means you have implicit dependency on the environment, or wrong dependency versions constraints, which you likely don't know about. If you don't know your dependencies, you are definitely shooting blind.
Minimizes global state. Repo-based distros minimize global state by providing software that has most dependencies compatible, so you can have your minimal state and update your software too. Meanwhile with docker you need all dependencies and hope that they will match between images, so you can save on layers reusage. And if someone decides to update base image, and others dont... well, too bad, you have to have both versions of the base image.
Re: Run More Stuff in Docker
#216Just some counter arguments to @jbergknoff's well put together page! Docker is the best medium for distributing - A static file is far easier to share / distribute. Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they a…
What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. The simple reality is that, there is Docker and absolutely nothing else that comes close to working everywhere. Yes, it's not perfect but everything else is far less perfect. Static binaries are far too limited; most software requires lots of files spread all around the file system. I did a…
Re: Run More Stuff in Docker
#217Earlier quoted context omitted.
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…
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 u…
Oh yes, it would make me "happy", too.
Re: Run More Stuff in Docker
#218> Running a program in a container is a lot like running it normally, but the user doesn’t need to jump through hoops to configure the system, build and install. Docker is itself a complex build tool which requires a bunch of install steps. If you are going to ship software to end users there is almost always a better way to bundle and ship than send someone a Docker container . Docker is not a distribution tool, if…
> In no case is "Making it into a Docker Image" a simpler/ better distribution mechanic. For my home server setup, I have docker containers for: * PiHole * NextCloud * Home Assistant If I had to install each of those manually, I probably wouldn't have installed them. This is especially true of NextCloud, which almost certainly would have required me to learn how to run nginx on my own, install php or whatever applica…
I have a huge (personal) wiki page for installing and maintaining NextCloud from before they had a decent Docker image. Now I’m content to let it be a black box I don’t have to think about, so I run it in Docker. It saves a ton of time and hassle.
Docker adds a lot of value when devs ignore the best practice advice of putting everything in a separate container. That’s just a package manager with extra steps IMO. It’s the mini distro style containers like GitLab’s that can save you a masssive amount of time.
Re: Run More Stuff in Docker
#219Just some counter arguments to @jbergknoff's well put together page! Docker is the best medium for distributing - A static file is far easier to share / distribute. Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they a…
What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. The simple reality is that, there is Docker and absolutely nothing else that comes close to working everywhere. Yes, it's not perfect but everything else is far less perfect. Static binaries are far too limited; most software requires lots of files spread all around the file system. I did a…
Virtual Machines. VirtualBox in combination with vagrant works reasonably well cross-platform.
Re: Run More Stuff in Docker
#220Earlier quoted context omitted.
Serious question: Why do you believe that to be insane? The Dockerfile for a simple application such as black must be very short (probably 3-4 lines), the alias is probably quite short and the container overhead time is minimal for native docker (the story might be different for things like docker mac). On the other hand, you get some benefits from installing black through docker rather than through the system packag…
> you must reinstall it once for each project You can install it either in a venv outside of all projects or even "pip install --user black". > updating python to a new (major) version breaks your formatter Uninstalling the old version breaks the formatter. Installing a new one does not. Either way, with asdf, pyenv, and others you can keep all relevant version around. > you cannot move the env around Sure you can. U…
> But in that case black is not a great example. You probably want to have a specific version bound to the project so everyone uses it (including the ci platform).
That's what I do in my open source work, the CI will run the formatter and commit the result back in tree so it forces everyone on one version. At work this is handled by the developer tools' team.
> Uninstalling the old version breaks the formatter. Installing a new one does not. Either way, with asdf, pyenv, and others you can keep all relevant version around.
Yes but at some point you are basically making ad-hoc containers right? So why not use the generic one?