10 ms·

> 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 ap

> 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.
        pferde 6y ago
        Do you have any documentation (or blogs) on a higher level that you would recommend? I too have been using Docker for a while, and recently also for certain programs on my desktop (mainly firefox, github cli, azure cli, aws cli, terraform). I like to think I am somewhat proficient in using Docker correctly by now, but I am still discovering new tidbits of practical knowledge, tips and good practices every few weeks. And I always want more. :)
  - 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.

> 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.
      - pferde 6y ago
        Do you have any documentation (or blogs) on a higher level that you would recommend? I too have been using Docker for a while, and recently also for certain programs on my desktop (mainly firefox, github cli, azure cli, aws cli, terraform). I like to think I am somewhat proficient in using Docker correctly by now, but I am still discovering new tidbits of practical knowledge, tips and good practices every few weeks. And I always want more. :)
- 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.