8 ms·

Let's not. I don't want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that's 500 MB+ image. Imagine downloading every ap

• peteretep 6y ago
  > Imagine downloading every application as a docker container. WTF. Help me understand the WTF here, and also how that’s meaningfully different from an OS X app?
  • systemvoltage 6y ago
    Jumping from 73 MB -----> 500 MB or whatever. Have you been running Docker on your system? Have you tried running: `docker system prune -a`? It's gonna print something like Total reclaimed space: 31.2GB.
    • peteretep 6y ago
      wtf are you doing to create such large Docker containers? Are you installing each app on top of a fully-fledged Ubuntu? Are you leaving the build tools in the final container?
      • systemvoltage 6y ago
        That's what I am trying to ask myself too! I am sorry that I am a developer and I need to run a bunch of docker compose files.
      • fantod 6y ago
        I mean it could just be very many containers that add up. And in many cases you'll have loads of images close to 1GB unless you go to great lengths to try and shrink them (e.g. anything that uses Python).
        • peteretep 6y ago
          I can get an Alpine Linux container running Perl with a chunk of CPAN on it to 60MB by just stripping the build tools once I've installed everything I want. Is Python really a GB bigger, or are people not taking the most basic of steps?
          • fantod 6y ago
            So maybe I was quick to comment, but I glanced at the images I have sitting around and python:3.7 is 876MB. However, python:3.7-slim is 112MB (still nearly twice the size of the image you describe, though). But it's conceivable that many people running into limitations with the slim image would just opt for the full Python image instead. Maybe a better example is the Tensorflow image, which is close to 4GB for the GPU version. It's also the kind of thing that would be a pain to rebuild from scratch if you wanted to find a way to save space.
            • peteretep 6y ago
              Do you also understand that once you have any image built on top of python:3.7 then that 876MB doesn't need to be downloaded again for subsequent images? > the Tensorflow image is really big This is kind of meaningless without comparing it to how large Tensorflow is with related dependencies if you just install it centrally?
              • fantod 6y ago
                Yes, I understand that Docker caches layers. Like I said, if docker system prune is clearing a huge amount of space, it's like a large number of different images and containers that might not share layers. If you're build, running, starting, and stopping containers all day, you might not be terribly careful about exactly what you're doing each time. That's why system prune is so useful.
          • tomrod 6y ago
            Basic steps. Welcome to the long September of Docker. Whereas most folks who use it regularly know basic maintenance patterns, new users (myself included) must wade through inscrutable documentation or (worse) poorly written blogfarm posts in order to bootstrap up to a level of proficiency that passes interview smell tests.
      • manigandham 6y ago
        If you're building docker images FROM SCRATCH then there's no improvement over a zip file or statically-linked single binary (which is what packages and installers already use). Meanwhile Docker adds many more restrictions and limitations and is not a good fit for consumer-focused interactive GUI applications which are not the web and console apps that work best with Docker.
        • Too 6y ago
          One improvement is the container is sandboxed and dependencies to the host must be added explicitly, eg --volume, --env, --net. Sure you could do the same with chroot manually and there are many other tools that does the same thing, but somehow the docker way of representing these concepts are more graspable for average user, and much more widespread use.
    • josephg 6y ago
      Its worse than just the size jump. Every application would also need to run all its code inside a linux VM. So that means: - Dedicated RAM for all your docker apps (which you have to partition manually) - Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. - All syscalls run through the VM's emulation layer, which is way slower than native - No access to the system's native UI toolkits. (Docker apps can't dynamically link to cocoa for obvious reasons.) We can probably work around this by wasting a huge amount of developer time making a networked bridge or something silly but ?? - No easy way to load and save files (the VM doesn't have filesystem access) - All the other downsides of docker - like it gobbling up all your disk space with images that are no longer used - Lower battery life, because the host can't easily sleep the VM's scheduler. The CPU can't enter low power state when nothing's running. Please don't do this. We already have a special kind of container for "self contained program on disk". Its called a statically linked executable. They work great. They're fast, small, have access to everything the host system provides. You can SHA them if you want and you can easily host them yourself using a static web server. My computer's responsiveness is more important to me than your shiny docker shaped toy.
      • systemvoltage 6y ago
        That's absolutely terrifying. Thanks for the insight.
      • keyle 6y ago
        I am so glad I can read something like this in public. When I say stuff like this in job interviews, I get eye rolls and don't end up getting a job. The industry is so far up its ass lately, no one even dare stating the facts in public. /rant
        • pram 6y ago
          Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.
          • 6y ago
  • joshuanapoli 6y ago
    Loading a 1GB image to run a 50MB executable can be trouble. I used to work while commuting on a train on a daily basis. Unexpectedly needing a big download could ruin my morning.
    • peteretep 6y ago
      Why are you running such huge images for a 50MB executable?
      • cowsandmilk 6y ago
        We expect every app developer to suddenly become an expert in efficiently producing docker layers and not just lazily use an Ubuntu desktop image?
        • peteretep 6y ago
          I expect anyone distributing their app via Docker to learn how to use their tooling properly, yes?
          • fantod 6y ago
            Agreed, there are many things to get right about using Docker. But if you're just deploying an app to a somewhere, does it really matter if the image is a bit bloated (within reason)?
      • joshuanapoli 6y ago
        Probably because container authors learned from Docker's getting started video, which demonstrates a 1GB "hello world" image.
  • cowsandmilk 6y ago
    OS X apps share frameworks in the user space, while docker images don’t...and docker images have all the constraints everyone hates about sandbox, but only make it worse. E.g. the file open dialog in macOS will grant apps access to the file when the user chooses the file. In docker, I have to manually add a path whenever I want tools to have access.
    • peteretep 6y ago
      That doesn’t match my mental model of how that works. Can you give me an example of a shared 3rd party framework that a Mac app bundle will find on the file system rather than just include in the bundle?
      • josephg 6y ago
        Sharing dynamically linked 3rd party frameworks on macos is relatively rare. But all the system built-in frameworks are shared via dynamic linking in userspace. (Eg Cocoa, UIKit, Foundation, etc). Native macos apps feel native because they dynamically link to the system's standard set of UI libraries. (And more recently font sets like SF Symbols.) For many reasons, none of that is available via docker. The GP is also referencing the fact that even if you somehow had access to cocoa from your linux binary inside your docker VM, the docker image doesn't / shouldn't have access to your host (macos's) filesystem. So the save / load dialog wouldn't work properly anyway.
        • peteretep 6y ago
          > none of that is available via docker I'd expect someone building many tools like the author of the original piece is using the same shared image as the base for most of them?
          • josephg 6y ago
            The base shared image can't embed macos's system & UI libraries because: - They're proprietary. Copying them from macos onto docker hub violates the macos software license. - They change with each version of MacOS. You can't mix & match them. I guess you could mount them into docker's filesystem, but then whats the point of using docker? And even if you did that: - They're macos mach executable files. Linux (and therefore docker) doesn't know how to run mach executable files. - Even if you could somehow embed them and get them to run, the libraries wouldn't work because they expect to be making syscalls to Darwin. They can't do that from inside a linux virtual machine. You could probably make a weird RPC proxy involving a native macos process receiving network commands. But it should take a herculean effort to make it work at all, and even if you got it working it would probably be buggy (since everything would suddenly become async) and slow.
  • ogre_codes 6y ago
    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, it's a ton of bloat.
    • m463 6y ago
      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 <appname>.app
      • oefrha 6y ago
        Except Mac apps don’t each ship a libSystem.
        • AnIdiotOnTheNet 6y ago
          Because unlike Linux they don't have to, since MacOS actually defines the concept of a stable base system that can be targeted by applications. Docker exists in part because the Linux world has no such concept.
          • ogre_codes 6y ago
            Thats the point here. The two aren't similar at all. MacOS apps contain all the app. Mac Apps leverage all of the OS functionality they can. They are strongly tied to MacOS and rely on it for most functionality. When I upgraded to Big Sur, the Mac Apps that run on my computer adapt to the changed OS libraries and often present differently. Docker apps contain their own complete environment. They are deliberately engineered to disassociate from the base OS. Electron is a sort of middle ground largely ignoring many system libraries, but using others. The only thing Docker has in Common with Mac Apps is the fact that they keep associated files bundled together.
• ithkuil 6y ago
  In many cases you don't need 500mb of base image. Minimal "distrofull" images are in the 50mb range. But often you don't really need a real distribution inside your docker image. See https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless. But distroless is not about one specific tool or base image, it's a paradigm that addresses precisely what you say (without throwing away the whale with the bathwater)
• knowhy 6y ago
  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.
  • sverhagen 6y ago
    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.
    • LucasLarson 6y ago
      > If I'm a Java developer, I'm "happy" Oh yes, it would make me "happy", too.
    • Kwpolska 6y ago
      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.
• m463 6y ago
  I disagree. I think the beauty of docker - and this should spread elsewhere - is that everything starts with one text file. The crufty part is all the crap that has to be added to the docker run commandline.
  • sverhagen 6y ago
    > one text file. That! It is codified. If people had their main machine codified, Docker would maybe be less of a benefit. And I'm sure a lot of people here have that. But a lot of my colleagues don't. So, I give them a Docker image... instead of explaining the same Java developer for the umptied time how to make a virtual environment for my Python program.
    • kaba0 6y ago
      Most package manager formats are simple text files as well. Also, docker doesn’t solve the DLL hell problem, just pushes it out of sight. The nix package manager is something that actually solves it and it should be promoted and leave docker to things it is good at - containerization.
• cmckn 6y ago
  Totally agree that Docker is made for deploying to servers. But the disk space critique doesn’t hit for me. Even very nice SSD’s are cheap enough that 500 MB is negligible. My internet connection also makes downloading a large docker image no bigger of a deal than downloading Chrome, YMMV. I think the necessity of a VM when using Docker on Mac and Windows is the primary reason that running your “normal” apps in a container isn’t the right move.
  • RedShift1 6y ago
    The problem isn't 500 MB disk footprint, it's all the RAM memory going to waste when loading in redundant libraries. Chrome already is a memory hog on its own, imagine all applications suddenly bringing in their versions of their libraries.
    • tomxor 6y ago
      Also the network requirements to install and update such large containers is a problem, a lot of people don't appreciate how slow the internet is in most of the world compared to those with access to any kind of fiber end point.. this extends to similar concepts like snap packages.
    • cmckn 6y ago
      RAM is the same situation as disk for me — I have plenty to waste. Again, not advocating Chrome in a container, I don’t even run Chrome outside of a container. I just think it’s odd to get hung up on these sorts of resource requirements given the state of computing.
      • RedShift1 6y ago
        You may have plenty of resources but there are many that have to "make due" with 8 GB, 4 GB or even less RAM.
        • cmckn 6y ago
          Totally fair, but I think the Venn diagram of folks that use Docker and folks that have 4GB of RAM is pretty slim. If the resources are that limited, Docker might not be the best choice for running anything. Related: Chrome on 4GB of RAM sounds painful. Thoughts and prayers to those folks.
• alibarber 6y ago
  My disdain for docker is not so much disk usage (I consider that battle lost in modern Software Engineering) but all the other crud that it does - such as re-implement an entire network device and routing and all. I’ve seen this cause teams countless hours of downtime with things like IP address collisions with VPCs etc, and I’ve never really been given a satisfactory answer as to why this is useful. So now we’ve solved dependency hell and have to faff around with networking and all. Great. Also the engine runs as root and takes commands from normal users which I always thought was a no-no but I guess docker is ‘special’ - and should be able to do whatever it likes. Containerisation is a fine idea and concept - but I think there are still big caveats. I’ve been using podman a lot and I hope it becomes more commonplace. I hear that there’s a lot of SV politics and drama going around surrounding the various companies and backers which I have exactly 0 interest in though...