3 ms·

But how do you explain the need for a "whole system" just to run one application? "Back in the days", you installed one package, edited one config, started the

But how do you explain the need for a "whole system" just to run one application? "Back in the days", you installed one package, edited one config, started the service, and it "just worked". Now i need to install a docker, type some docker install command, that pulls who-knows how many files, puts them in some 'weird' location, including the config file (which belongs in /etc), so instead of having a 2mb service, I now have a 1gb docker image sitting on my system, with a config file hidden somewhere, and I, the user, don't see any benefits, compared to just 'apt-get install'-ing something. I mean, I understand, daling with dependencies are hard for some developers, but sometimes is just overkill.

teekert 6y ago
Did it just work? Were there never any dependency issues or unsolvable complexities? Or dependencies that were solved differently when run a second time leading to a different output of software? The "whole computer" analogy works because I can drag it anywhere, plug it in and it runs exactly as intended. I can even copy it and run in 1000 times in parallel. When people complain about overkill I start talking about shared layers.
- ajsnigrutin 6y ago
  To me, apt-get install always 'just worked'. Same for yum install, emerge etc. I understand it's easier to ship software as a "almost VM", but imagine everyone doing it... need a browser, download firefox docker image. Video player? docker image! Text editor? Docker image! If firefox can make it 'just work', and whole (eg.) lamp-stack can 'just work', why not others? Docker is a relatively new thing, and software worked for decades before that, without any real issues.
  - AnIdiotOnTheNet 6y ago
    > To me, apt-get install always 'just worked'. Same for yum install, emerge etc. Sure, as long as a third party did all the hard work of integrating the package into the system first. Have to install something outside the repo? Clear your schedule...
vbsteven 6y ago
I usually explain this one in terms of multiple projects: Project A uses postgres-11, Project B uses postgres-12, Project C uses porgres-11 with postgis and also redis. Having them all in containers and a docker-compose.yml file makes it easier to quickly start an environment for a specific project. Ofcourse like everything in life, it's a tradeoff, and in this case we're trading in diskspace and some overhead for ease of use and portability.
dividedbyzero 6y ago
> and it "just worked" For me, it frequently didn't. Sure, nginx will work out of the box, but I've had some difficult Apache installs, and less mature software? Often a dependency/configuration nightmare, and then, sometimes, it still would die with an opaque error message. And then something breaks and getting to a clean slate can be challenging. That's one of the huge upsides of Docker for me: Stuff finally "just works" on my machines, too! And it actually "just works" on others' machines as well, which it has all along as they tell me, but it even does so when I'm watching. Amazing, really. I think the config situation has improved as well – the most frequently used configuration options usually can be passed in as environment variables, so I don't have to pin things to non-default values just because the config file I copied and edited had that default value in its config at that particular version, only to break five versions later – neat. If I do need a config file, I keep it in git and bind-mount it in – the location is usually easy to find (e.g. in the docker run one-liner on the DockerHub page). Image sizes can be crazy, that part needs work, many people don't write space-efficient Dockerfiles. I try to use alpine or scratch images where possible, that makes the problem quite manageable; and, frankly, the amounts of network, storage and ram needed for the overhead of an alpine image are a very fair bargain for the time and headspace I gain by being able to treat applications as a way darker-gray box than otherwise.
AnIdiotOnTheNet 6y ago
> But how do you explain the need for a "whole system" just to run one application? Well you see, Linux culture doesn't really consider the concept of "system" and "application" to be independent. Everything has to be built to work together or the whole thing catches fire and explodes. Consequently, its easier to build entirely different systems for every single application and package them all up together than it is to try and get them to work on the same system. Weirdly, they seem to think this is a good thing.
- srtjstjsj 6y ago
  No one's made a working alternative, except maybe Nix which took 20 years to show up.
  - AnIdiotOnTheNet 6y ago
    Yeah, I mean, there never was RiscOS, MacOS (classic), or any other operating system... Nix is just another overengineered solution to the problem that doesn't really exist on other platforms that are actually, you know, platforms.
curryst 6y ago
You needn't (and shouldn't) edit the config file in the image. Going into /var/lib/docker/images and editing things is bound to end poorly. Most images have environments variables you can set that will control the config, or you can bind mount a config file from anywhere on your hard drive. > Now i need to install a docker, type some docker install command, that pulls who-knows how many files, puts them in some 'weird' location, including the config file (which belongs in /etc), so instead of having a 2mb service, I now have a 1gb docker image sitting on my system, with a config file hidden somewhere, and I, the user, don't see any benefits, compared to just 'apt-get install'-ing something. On the other hand, I can `docker-compose up -d` on practically any platform in existence. I don't have to worry about what package manager this host uses, or whether the version they have supports the config flags I'm using. It's the same everywhere. I don't have to deal with the pain that is 3rd party apt repositories, and handling pinning when they want to ship a newer version of a library than the main OS does (I believe Salt does this). That, perhaps, is worth less to you than to other people. I would _far_ rather handle setting up another couple Docker containers in Compose than I would handle figuring out which Apt repository they actually publish to, and handling the installation, and fixing the configs (because many services ship with broken configs, because they have no idea what your Postgres password is, for example. Not true of Docker, their docker-compose.yml typically includes setting the password). This is especially true of multi-component systems, or systems that I'm testing out or using in dev. If I want to enable the Jaeger built into an application, it's one command to run it. In apt, that would have to install 4 or 5 daemons that I would then need to configure. I also think complaining about disk space is rather disingenuous at this point. Yes, disk space costs money. No, you are unlikely to have Docker make a significant difference in the price to build your PC. 1GB is huge for a Docker image (but many people are bad at trimming them down, so I'll accept it). In 2017, storage cost roughly $0.03/GB on an HDD. You're paying 3 cents to store that Docker image. Probably less at this point, I saw an article about WD releasing $15/TB HDDs in the near future. The moderate performance impact seems more important to me.

teekert 6y ago

Did it just work? Were there never any dependency issues or unsolvable complexities? Or dependencies that were solved differently when run a second time leading to a different output of software? The "whole computer" analogy works because I can drag it anywhere, plug it in and it runs exactly as intended. I can even copy it and run in 1000 times in parallel. When people complain about overkill I start talking about shared layers.

ajsnigrutin 6y ago
To me, apt-get install always 'just worked'. Same for yum install, emerge etc. I understand it's easier to ship software as a "almost VM", but imagine everyone doing it... need a browser, download firefox docker image. Video player? docker image! Text editor? Docker image! If firefox can make it 'just work', and whole (eg.) lamp-stack can 'just work', why not others? Docker is a relatively new thing, and software worked for decades before that, without any real issues.
- AnIdiotOnTheNet 6y ago
  > To me, apt-get install always 'just worked'. Same for yum install, emerge etc. Sure, as long as a third party did all the hard work of integrating the package into the system first. Have to install something outside the repo? Clear your schedule...

vbsteven 6y ago

I usually explain this one in terms of multiple projects: Project A uses postgres-11, Project B uses postgres-12, Project C uses porgres-11 with postgis and also redis. Having them all in containers and a docker-compose.yml file makes it easier to quickly start an environment for a specific project. Ofcourse like everything in life, it's a tradeoff, and in this case we're trading in diskspace and some overhead for ease of use and portability.

dividedbyzero 6y ago

> and it "just worked" For me, it frequently didn't. Sure, nginx will work out of the box, but I've had some difficult Apache installs, and less mature software? Often a dependency/configuration nightmare, and then, sometimes, it still would die with an opaque error message. And then something breaks and getting to a clean slate can be challenging. That's one of the huge upsides of Docker for me: Stuff finally "just works" on my machines, too! And it actually "just works" on others' machines as well, which it has all along as they tell me, but it even does so when I'm watching. Amazing, really. I think the config situation has improved as well – the most frequently used configuration options usually can be passed in as environment variables, so I don't have to pin things to non-default values just because the config file I copied and edited had that default value in its config at that particular version, only to break five versions later – neat. If I do need a config file, I keep it in git and bind-mount it in – the location is usually easy to find (e.g. in the docker run one-liner on the DockerHub page). Image sizes can be crazy, that part needs work, many people don't write space-efficient Dockerfiles. I try to use alpine or scratch images where possible, that makes the problem quite manageable; and, frankly, the amounts of network, storage and ram needed for the overhead of an alpine image are a very fair bargain for the time and headspace I gain by being able to treat applications as a way darker-gray box than otherwise.

AnIdiotOnTheNet 6y ago

> But how do you explain the need for a "whole system" just to run one application? Well you see, Linux culture doesn't really consider the concept of "system" and "application" to be independent. Everything has to be built to work together or the whole thing catches fire and explodes. Consequently, its easier to build entirely different systems for every single application and package them all up together than it is to try and get them to work on the same system. Weirdly, they seem to think this is a good thing.

srtjstjsj 6y ago
No one's made a working alternative, except maybe Nix which took 20 years to show up.
- AnIdiotOnTheNet 6y ago
  Yeah, I mean, there never was RiscOS, MacOS (classic), or any other operating system... Nix is just another overengineered solution to the problem that doesn't really exist on other platforms that are actually, you know, platforms.

curryst 6y ago

You needn't (and shouldn't) edit the config file in the image. Going into /var/lib/docker/images and editing things is bound to end poorly. Most images have environments variables you can set that will control the config, or you can bind mount a config file from anywhere on your hard drive. > Now i need to install a docker, type some docker install command, that pulls who-knows how many files, puts them in some 'weird' location, including the config file (which belongs in /etc), so instead of having a 2mb service, I now have a 1gb docker image sitting on my system, with a config file hidden somewhere, and I, the user, don't see any benefits, compared to just 'apt-get install'-ing something. On the other hand, I can `docker-compose up -d` on practically any platform in existence. I don't have to worry about what package manager this host uses, or whether the version they have supports the config flags I'm using. It's the same everywhere. I don't have to deal with the pain that is 3rd party apt repositories, and handling pinning when they want to ship a newer version of a library than the main OS does (I believe Salt does this). That, perhaps, is worth less to you than to other people. I would _far_ rather handle setting up another couple Docker containers in Compose than I would handle figuring out which Apt repository they actually publish to, and handling the installation, and fixing the configs (because many services ship with broken configs, because they have no idea what your Postgres password is, for example. Not true of Docker, their docker-compose.yml typically includes setting the password). This is especially true of multi-component systems, or systems that I'm testing out or using in dev. If I want to enable the Jaeger built into an application, it's one command to run it. In apt, that would have to install 4 or 5 daemons that I would then need to configure. I also think complaining about disk space is rather disingenuous at this point. Yes, disk space costs money. No, you are unlikely to have Docker make a significant difference in the price to build your PC. 1GB is huge for a Docker image (but many people are bad at trimming them down, so I'll accept it). In 2017, storage cost roughly $0.03/GB on an HDD. You're paying 3 cents to store that Docker image. Probably less at this point, I saw an article about WD releasing $15/TB HDDs in the near future. The moderate performance impact seems more important to me.