4 ms·

> Unlike most package systems, most people that develop in docker containers are writing the equivalent of a package manifest (Dockerfile) Dockerfile is a set

by dozzie 9y ago

> Unlike most package systems, most people that develop in docker containers are writing the equivalent of a package manifest (Dockerfile) Dockerfile is a set of build rules. You need to have build rules for RPMs and DEBs (unless you use FPM that you somewhat praised later, in which case there's no good place to put the rules and you get terrible packages with missing metadata). Unlike most package systems, Docker was designed by programmers for programmers, so you don't need to learn those yucky tools for sysadmins and you can stay oblivious to how the OS actually works (despite that you should actually know the OS you're dealing with, so it's a dumb idea on its own). > and they're [writing Dockerfiles] for things that weren't previously packaged. Which is only a progress because programmers are putting the code into packages. Exactly the same could be achieved with RPMs and DEBs, even if you needed something that was already shipped by the distribution (you'd just put your things on the side, just as you are doing now with virtualenv or gems or whatever). > While there are plenty of exceptions, the standard for deployment of webapps has long been piecemeal deployments; not RPMs or whatnot. Docker's convenience features changed that. But Docker didn't change that because it allowed anything that was previously impossible or even difficult. Quite the contrary, it was easy, it just required to actually know how the OS works, which is not a common knowledge among web programmers. OS packages were ignored by programmers solely because they were sysadmins' tools, and as such they were boring. I see no other reason, given that Docker gives virtually no technical benefit beside heavy brittle magic on network configuration, so all your packaged daemons can listen on the very same address 0.0.0.0:8888 and still communicate with each other. > the big advantage of docker is that it integrates those technologies in a way that provides a simple mental model for reasoning about containers This mental model, it is what exactly? Because there's virtually no mental model with the packages. A tarball with necessary files, that's all.

zbentley 9y ago
> You need to have build rules for RPMs and DEBs. Yes, but as you said just after that, those in a Dockerfile are much more popular with a wide range of programmers. That might be because the dockerfile abstractions/API is better and simpler, or because the programmers like writing shell scripts but not RPM build rules, or for some other reason. > you should actually know the OS you're dealing with, so it's a dumb idea on its own ... it was easy, it just required to actually know how the OS works, which is not a common knowledge among web programmers. I'm really tired of this attitude. Of course you should know the OS you're dealing with. What you need to know about it depends on what you're doing with it. If I want to do kernel work, I don't need to know the best design principles for an ES7 web framework. If I want to make a website, I don't need to know how to write Apache 2 from first principles, and nor do I need to know how to manually chroot/install quotas/set up namespaces and capabilities to build a container system from scratch. > This mental model, it is what exactly? Because there's virtually no mental model with the packages. A tarball with necessary files, that's all. If it was just a tarball, it would be less powerful--it's the whole bunch of technically-unrelated things (resource management, networking, capabilities, namespaces, tarball-ish features, layering, dockerfile API, nice CLI with pluggable backends, standardized container interface) all unified under the abstraction of "this is a single unit, just like an RPM package". That concept is powerful exactly because it hides the fundamentals of the specific component technologies from people who don't need to know them--at least not at first. Saying Docker is just "package maintenance for stupid people who only play with Duplo legos", you're being ignorant of the real needs of people at best, and deliberately elitist at worst. It's like saying "Dropbox is just for people who don't want to learn how file syncing over the network works--real programmers will just use curlftps and SVN".
- dozzie 9y ago
  > I'm really tired of this attitude. [...] What you need to know about [the OS] depends on what you're doing with it. You want your system deployed, so you should know how to deploy. If you don't know how most of the things are deployed, you're likely to create a monstrosity that doesn't fit in any way to what the OS can do sensibly. It's like arguing that a web programmer doesn't need to understand HTTP protocol, because he only works with it through half a dozen layers of abstractions (how currently it's done). > If I want to make a website, I don't need to know how to write Apache 2 from first principles, and nor do I need to know how to manually chroot/install quotas/set up namespaces and capabilities to build a container system from scratch. Of course, because that's what sysadmins do. But you should know how to configure the said Apache. Docker hides that away behind a heavy magic, which is bound to break apart for non-trivial requirements.

by dozzie 9y ago

zbentley 9y ago

> You need to have build rules for RPMs and DEBs. Yes, but as you said just after that, those in a Dockerfile are much more popular with a wide range of programmers. That might be because the dockerfile abstractions/API is better and simpler, or because the programmers like writing shell scripts but not RPM build rules, or for some other reason. > you should actually know the OS you're dealing with, so it's a dumb idea on its own ... it was easy, it just required to actually know how the OS works, which is not a common knowledge among web programmers. I'm really tired of this attitude. Of course you should know the OS you're dealing with. What you need to know about it depends on what you're doing with it. If I want to do kernel work, I don't need to know the best design principles for an ES7 web framework. If I want to make a website, I don't need to know how to write Apache 2 from first principles, and nor do I need to know how to manually chroot/install quotas/set up namespaces and capabilities to build a container system from scratch. > This mental model, it is what exactly? Because there's virtually no mental model with the packages. A tarball with necessary files, that's all. If it was just a tarball, it would be less powerful--it's the whole bunch of technically-unrelated things (resource management, networking, capabilities, namespaces, tarball-ish features, layering, dockerfile API, nice CLI with pluggable backends, standardized container interface) all unified under the abstraction of "this is a single unit, just like an RPM package". That concept is powerful exactly because it hides the fundamentals of the specific component technologies from people who don't need to know them--at least not at first. Saying Docker is just "package maintenance for stupid people who only play with Duplo legos", you're being ignorant of the real needs of people at best, and deliberately elitist at worst. It's like saying "Dropbox is just for people who don't want to learn how file syncing over the network works--real programmers will just use curlftps and SVN".

dozzie 9y ago
> I'm really tired of this attitude. [...] What you need to know about [the OS] depends on what you're doing with it. You want your system deployed, so you should know how to deploy. If you don't know how most of the things are deployed, you're likely to create a monstrosity that doesn't fit in any way to what the OS can do sensibly. It's like arguing that a web programmer doesn't need to understand HTTP protocol, because he only works with it through half a dozen layers of abstractions (how currently it's done). > If I want to make a website, I don't need to know how to write Apache 2 from first principles, and nor do I need to know how to manually chroot/install quotas/set up namespaces and capabilities to build a container system from scratch. Of course, because that's what sysadmins do. But you should know how to configure the said Apache. Docker hides that away behind a heavy magic, which is bound to break apart for non-trivial requirements.