6 ms·

Boycott Docker

105 points by Artemis2 10y ago

okket 10y ago
Every few hundred days... https://news.ycombinator.com/from?site=boycottdocker.org https://news.ycombinator.com/from?site=boycottdocker.org
- unethical_ban 10y ago
  As they say on reddit, "I haven't seen it yet!" - but reposts are a bit annoying. That said, only one of those accounts seems scammy at all, so it is a harmless repost.
codezero 10y ago
This would be a lot more compelling if it included testimonials from actual projects bitten by any of the arguments against docker. On its own it just looks like a thorough but not necessarily real world rant. Also it doesn't provide practical alternatives. The link to Guix at the end says not ready for production. I am having a hard time accepting the veracity of the contents if they recommend something that's not production ready.
- k__ 10y ago
  Isn't Nix(OS) ready for production? As far as I know it does the same as Guix, but without LISP.
  - codezero 10y ago
    Sounds like it, I don't know enough about Nix to know if it addresses the same scope of need that docker does, hopefully someone who is savvy can chime in :)
    - aseipp 10y ago
      It's "production ready" if you're willing to do a lot of work yourself. It has a lot of solid theoretical and practical advantages, if you're willing to do so -- as well as some downsides. Advantages include things like real reproducibility, a "unified language" that can describe everything from your packages to server networks, atomic upgrades and rollbacks. More minor advantages are things like powerful development environments, automatic support for distributed/remote builds for your software/deps, easily supports customized software (it's very easy to patch your kernel and have all kernel dependencies rebuilt automatically, stuff like that etc), and other stuff. It's probably one of the most forkable/customizable distros, just purely due to the way Nix works, and fact everything is in one git repo, making 'wide changes' as easy as a branch. Downsides include the fact that the security story is still ongoing on several fronts (userspace/kernel hardening, quickly shipping userspace vulnerability fixes) and that compiling everything -- when it happens -- can take some time. (I only list these two, but obviously these aren't small problems and IMO are two of the biggest ones). NixOS certainly isn't ready for "ordinary consumers" or anything, even among people who might use Linux regularly. It also just factually isn't going to be to everyone's exact taste, in terms of some design decisions (hence Guix exists, and Guix is great!) But for advanced users and operators, it can certainly be well worth it, and confer some unique and powerful advantages. Note that I'm specifically skirting the question of "does it address all the same things as Docker" (in fact, they aren't even fully competing projects, in many ways) -- because that's a fairly complex question given all the ways people use both projects, and it could fill a blog post (or several) in its own right.
      - codezero 10y ago
        Awesome, thanks, this is really helpful.
- user5994461 10y ago
  > This would be a lot more compelling if it included testimonials from actual projects bitten by any of the arguments against docker. Disclaimer: I am not affiliated with the author. I just experience endless issues with docker in production. Enough to write a book. (just testing future audience for the book) That, I can provide in a separate blog post! :D What selection of bugs would you be interested in? - Critical linux kernel bugs killing the host when running docker - Containers crashing and corrupting all data on the mounted directories [from the host drive] - Worldwide outage of docker.com killing all CI pipeline in the world for 7 hours straight - More critical linux kernel bugs destroying the docker host - Major breaking changes in docker and docker API (usually between all minor versions), breaking all existing stuff - Randomly dropping critical features, distribution and filesystem support (to the point where there is actually NO filesystem supported by Docker on some distribution. No kidding xD) - Various DNS fuckups (special issues on Ubuntu) - No build-in commands to free disk space of old containers/images (this one is major hassle)
  - codezero 10y ago
    Awesome, you _should_ write a blog post if you have time :) I'm particularly interested in what you did to get around all the bullet points. Are you still using Docker, with some bandaids, or did you move to something different?
    - user5994461 10y ago
      Hope you're still here. Comments and feedback welcome. https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.wordpress.com/2016/11/01/docker-in-product...
      - codezero 10y ago
        Thanks :)
profmonocle 10y ago
There are some major factual errors in this post. A few of them: > Docker has lower memory footprint, because of forcing to run only single process per container Docker doesn't force you to use a single process per container - that's a design choice that some people espouse, but not a requirement. For instance, we run the official GitLab Docker image and it consists of many processes. > Docker won't be able to run even Postfix I'm running Postfix in a Docker container right now and it's working fine. > But we are talking about Docker: it does not support IPv6 at all. IPv6 support is incomplete, but not non-existent. I'm running IPv6 in my containers right now.
awinder 10y ago
"because of forcing to run only single process per container" Which isn't really true, because you can still fork processes / run an init system. A lot of people don't do that, for reasons I don't really want to get into, just to say that this is a factually-invalid point, there is no forcing going on here.
dspillett 10y ago
Anyone who cites not being able to run an FTP server as a reason for not using something else these days turns me off to the rest of their arguments regarding that something else, especially when their core argument is about what they consider the right/wrong tools for given jobs in a modern environment. FTP was a pain to work with back in the day when I wrote and sold client applications using it, when there wasn't an alternative for many use cases, but these days there are few (if any?) reasons to want to run an FTP server where there isn't a better alternative.
- easytiger 10y ago
  isn't the point that anything that fork()s can't run?
  - dspillett 10y ago
    With regard to forking it was specifically talking about tasks that fork in order to change their identity at runtime as is common in daemon processes that can act as or on behalf of many different users. Processes within docker can fork more generally otherwise how would a great many things (like bash at all) work? The second point where FTP was specifically mentioned is the use of dynamic port allocation. That is a bad point as that is an existing problem for many firewall & related solutions, generally and with regard to running in virtual architectures, so not specific to docker at all. Depending on what you might want FTP for there are many FTP daemon options that don't need to do this, and better protocols supported by services that don't need to do this either. Using FTP as a bad example here is silly. What compelling reason is there to want to run an FTPd for which there isn't a much better solution anyway? If you are wanting to run an FTPd then you either have a very specific requirement or you are stuck in the past.
draw_down 10y ago
"Everyone is a stupid noob chasing shiny things but me."
chrisfosterelli 10y ago
Oh boy, as someone who's been using Docker for a while there seems like a lot of misinformation here. > strict restrictions like single process per container This isn't a real restriction, you can run as many processes as you want under a container. However, in most cases they recommend against it because it usually means you're doing something wrong. > Software developers forced to vendor lock-in their software I've made Dockerfile's for quite a few different apps now, and I have never once had to actually change the application. The applications still work completely independent of Docker, so I'm not sure where the "vendor lock-in" comes in here. > Docker won't be able to run even Postfix (or FTP daemons) https://github.com/tomav/docker-mailserver https://github.com/tomav/docker-mailserver https://github.com/atmoz/sftp https://github.com/atmoz/sftp > Docker is designed with cloud computing providers in mind exclusively I would disagree, although this is a matter of opinion I suppose. Having used both VM's and Docker for deployment, Docker is ridiculously more developer-friendly than a standard VM architecture. > No way to escape dependency hell I don't worry about dependencies anymore. If I want to try a new app, I `docker run` it. No dependencies. My apps themselves comes with all of their dependencies so I don't have to screw around with dependencies on a host provider. Sure, it doesn't completely solve dependency problems (you still need to write a Dockerfile) but it makes my life a whole lot easier compared to without Docker. Docker isn't the right fit for everything, and there's a lot of ways that I can think of where it can be improved. It strikes me like this was written by a frustrated sysadmin who hasn't spent the time to learn the tools (which is understandable, the learning curve is high and most things are different from traditional sysadmin tools). In fact, in alot of cases Docker is needlessly complex and overkill. However, spreading FUD doesn't do anything to address these concerns and might scare away a lot of developers who could benefit from Docker.
- eganist 10y ago
  > However, in most cases they recommend against it because it usually means you're doing something wrong. Docker-novice question for you: What's the best practice for this? What assumptions are at play for said best practice? I can understand separating DB from App, but what about other cases where an app might naturally have to have multiple processes running? ••• Edit: I hate calling this out, but if you're going to downvote questions asking for elucidation of the reasons surrounding best practices for a platform (something I'm frankly having a hard time finding in the case of Docker), keep in mind that doing so does nobody any favors and only discourages productive discourse. You've got over 500 karma enabling your capacity to downvote. Be responsible with the practice of doing so. Nothing in this comment (except perhaps this edit) warrants one.
forgetsusername 10y ago
Why not simply choose not to use it if it doesn't fit your personal use-case? What is the purpose of inciting a boycott?
chrisper 10y ago
Okay. I will boycott Docker and use LXD instead if that makes you happy. ;) Anyways, I am so glad I converted all my VMs to LXD containers. If I want to test something, I can spin up a new container in seconds as opposed to have to install the OS in a VM (or do clones / snapshots etc.).
wje 10y ago
I am the former owner of boycottsystemd.org. I think I may have started something terrible.
- qwertyuiop924 10y ago
  No, you actually had a valid point.
raesene6 10y ago
This page looks seriously out of date now, as a result its criticisms are inaccurate in a wide range of areas. To pick one in particular, Security. the claim that Docker doesn't know anything about AppArmor and/or SELinux just isn't correct. and the other security claim about having to trust docker hub is also now not correct, you can use signed builds to avoid that concern.
deleted 10y ago
[deleted]
altern8tif 10y ago
I'm new to Docker, but from what I know, it makes a microservices architecture extremely easy to set up. Right?
- jon-wood 10y ago
  It makes a microservices architecture less painful to set up. Nothing is going to make one easy to set up, and even less so easy to run.
qwertyuiop924 10y ago
Is this a joke? There is so much very inaccurate about this.
alex95 10y ago
"Respect yourself and write software as you wish to, not the cloud computing corporations are happy to." > boycott docker Right...
fasteo 10y ago
What a rant about Docker! Would love to hear the motivations for setting up this site. It seems that the owner of the domain [1] likes boycotting [2] a lot. Not that a disagree with him. [1] Registrant ID: XGX4VME-RU Registrant Name: Sergey Matveev Registrant Email: stargrave@stargrave.org [2] http://www.stargrave.org/Boycotting.html#Boycotting http://www.stargrave.org/Boycotting.html#Boycotting
djhworld 10y ago
I was hoping for some reasoned arguments from experience, but this just seems like a rant from someone who has read about Docker.
agentgt 10y ago
The vendor lock in thing has embarrassingly been a concern of mine as well. It seems presently you are either locked in with your cloud provider or your locked with docker (e.g. using Google container engine vs Google deployment manager). As a JVM shop I just can't see the value of using Docker when we can provision faster images using the cloud providers API (ala libcloud, jclouds, or directly using gcloud) and just build exectuable uber jars. That is in JVM land you only need to install Java (and for Go and Rust I suppose you have even less dependences). I understand the value in the OSS world of providing docker images but I'm not sure I can justify the complexity of switching over yet. Are there any major companies (especially JVM) that have fully dockerized (ie converted and not started off using docker)? I know Netflix started too but I'm not sure they every did fully.
- user5994461 10y ago
  Use packer for EVERYTHING https://www.packer.io/ https://www.packer.io/ => better tools + avoid locking As a benefit, you use ansible/chef/puppet for the installation and configuration (instead of Dockerfile). You can reuse your scripts. As a benefit, you generate any output DockerImage/AWS-AMI/VmWare/VirtualBox. You have more flexibility. (e.g. Make an AMI for auto scaling groups + make a docker image for test environment).
  - elsonrodriguez 10y ago
    I dig packer, but it's getting pretty hard to find a cloud provider or on-prem solution that doesn't take a Docker image as an artifact.
joepie91_ 10y ago
I don't like Docker, I feel that most people who claim it's "easy" don't really have sufficient experience with stacks that do not use Docker, and I think it's overall an overhyped piece of rubbish that shouldn't be recommended to people other than in some very specific usecases. That having been said, this site is terrible. It suggests a conspiracy without ever actually providing any evidence, and it's full of claims and assertions but very little to back it up. Docker has plenty of legitimate problems to address, and I don't really understand why somebody would half-ass their criticism like this.
mmgutz 10y ago
The minor gripe I have with Docker is how they're tying swarm into the docker tool. I can see a future where sysops will use the tools built into Docker because it's included just like how Windows made IE6 the default browser.
- profmonocle 10y ago
  > The minor gripe I have with Docker is how they're tying swarm into the docker tool. This is actually what I was expecting the article to be about when I read the title. Swarm integration has become a big controversy, and there's been serious discussion of forking Docker over it: http://thenewstack.io/docker-fork-talk-split-now-table/ http://thenewstack.io/docker-fork-talk-split-now-table/
chx 10y ago
> strict restrictions like single process per container Oh boy. Have you seen phusion/baseimage ? It supports boot time init scripts and then uses runit to let you add as many daemons as you want. It even has a "Wait, I thought Docker is about running a single process in a container?" brief chapter in the readme.
mohanmcgeek 10y ago
The author makes too many claims without actually supporting it. But I do agree with the author on that Docker these days doesn't seem to respect Unix philosophy. It wants to be everything. Case in point : integrating Swarm into docker.

105 points by Artemis2 10y ago

okket 10y ago

Every few hundred days... https://news.ycombinator.com/from?site=boycottdocker.org https://news.ycombinator.com/from?site=boycottdocker.org

unethical_ban 10y ago
As they say on reddit, "I haven't seen it yet!" - but reposts are a bit annoying. That said, only one of those accounts seems scammy at all, so it is a harmless repost.

codezero 10y ago

This would be a lot more compelling if it included testimonials from actual projects bitten by any of the arguments against docker. On its own it just looks like a thorough but not necessarily real world rant. Also it doesn't provide practical alternatives. The link to Guix at the end says not ready for production. I am having a hard time accepting the veracity of the contents if they recommend something that's not production ready.

k__ 10y ago
Isn't Nix(OS) ready for production? As far as I know it does the same as Guix, but without LISP.
- codezero 10y ago
  Sounds like it, I don't know enough about Nix to know if it addresses the same scope of need that docker does, hopefully someone who is savvy can chime in :)
  - aseipp 10y ago
    It's "production ready" if you're willing to do a lot of work yourself. It has a lot of solid theoretical and practical advantages, if you're willing to do so -- as well as some downsides. Advantages include things like real reproducibility, a "unified language" that can describe everything from your packages to server networks, atomic upgrades and rollbacks. More minor advantages are things like powerful development environments, automatic support for distributed/remote builds for your software/deps, easily supports customized software (it's very easy to patch your kernel and have all kernel dependencies rebuilt automatically, stuff like that etc), and other stuff. It's probably one of the most forkable/customizable distros, just purely due to the way Nix works, and fact everything is in one git repo, making 'wide changes' as easy as a branch. Downsides include the fact that the security story is still ongoing on several fronts (userspace/kernel hardening, quickly shipping userspace vulnerability fixes) and that compiling everything -- when it happens -- can take some time. (I only list these two, but obviously these aren't small problems and IMO are two of the biggest ones). NixOS certainly isn't ready for "ordinary consumers" or anything, even among people who might use Linux regularly. It also just factually isn't going to be to everyone's exact taste, in terms of some design decisions (hence Guix exists, and Guix is great!) But for advanced users and operators, it can certainly be well worth it, and confer some unique and powerful advantages. Note that I'm specifically skirting the question of "does it address all the same things as Docker" (in fact, they aren't even fully competing projects, in many ways) -- because that's a fairly complex question given all the ways people use both projects, and it could fill a blog post (or several) in its own right.
    - codezero 10y ago
      Awesome, thanks, this is really helpful.
user5994461 10y ago
> This would be a lot more compelling if it included testimonials from actual projects bitten by any of the arguments against docker. Disclaimer: I am not affiliated with the author. I just experience endless issues with docker in production. Enough to write a book. (just testing future audience for the book) That, I can provide in a separate blog post! :D What selection of bugs would you be interested in? - Critical linux kernel bugs killing the host when running docker - Containers crashing and corrupting all data on the mounted directories [from the host drive] - Worldwide outage of docker.com killing all CI pipeline in the world for 7 hours straight - More critical linux kernel bugs destroying the docker host - Major breaking changes in docker and docker API (usually between all minor versions), breaking all existing stuff - Randomly dropping critical features, distribution and filesystem support (to the point where there is actually NO filesystem supported by Docker on some distribution. No kidding xD) - Various DNS fuckups (special issues on Ubuntu) - No build-in commands to free disk space of old containers/images (this one is major hassle)
- codezero 10y ago
  Awesome, you _should_ write a blog post if you have time :) I'm particularly interested in what you did to get around all the bullet points. Are you still using Docker, with some bandaids, or did you move to something different?
  - user5994461 10y ago
    Hope you're still here. Comments and feedback welcome. https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.wordpress.com/2016/11/01/docker-in-product...
    - codezero 10y ago
      Thanks :)

profmonocle 10y ago

There are some major factual errors in this post. A few of them: > Docker has lower memory footprint, because of forcing to run only single process per container Docker doesn't force you to use a single process per container - that's a design choice that some people espouse, but not a requirement. For instance, we run the official GitLab Docker image and it consists of many processes. > Docker won't be able to run even Postfix I'm running Postfix in a Docker container right now and it's working fine. > But we are talking about Docker: it does not support IPv6 at all. IPv6 support is incomplete, but not non-existent. I'm running IPv6 in my containers right now.

awinder 10y ago

"because of forcing to run only single process per container" Which isn't really true, because you can still fork processes / run an init system. A lot of people don't do that, for reasons I don't really want to get into, just to say that this is a factually-invalid point, there is no forcing going on here.

dspillett 10y ago

Anyone who cites not being able to run an FTP server as a reason for not using something else these days turns me off to the rest of their arguments regarding that something else, especially when their core argument is about what they consider the right/wrong tools for given jobs in a modern environment. FTP was a pain to work with back in the day when I wrote and sold client applications using it, when there wasn't an alternative for many use cases, but these days there are few (if any?) reasons to want to run an FTP server where there isn't a better alternative.

easytiger 10y ago
isn't the point that anything that fork()s can't run?
- dspillett 10y ago
  With regard to forking it was specifically talking about tasks that fork in order to change their identity at runtime as is common in daemon processes that can act as or on behalf of many different users. Processes within docker can fork more generally otherwise how would a great many things (like bash at all) work? The second point where FTP was specifically mentioned is the use of dynamic port allocation. That is a bad point as that is an existing problem for many firewall & related solutions, generally and with regard to running in virtual architectures, so not specific to docker at all. Depending on what you might want FTP for there are many FTP daemon options that don't need to do this, and better protocols supported by services that don't need to do this either. Using FTP as a bad example here is silly. What compelling reason is there to want to run an FTPd for which there isn't a much better solution anyway? If you are wanting to run an FTPd then you either have a very specific requirement or you are stuck in the past.

draw_down 10y ago

"Everyone is a stupid noob chasing shiny things but me."

chrisfosterelli 10y ago

Oh boy, as someone who's been using Docker for a while there seems like a lot of misinformation here. > strict restrictions like single process per container This isn't a real restriction, you can run as many processes as you want under a container. However, in most cases they recommend against it because it usually means you're doing something wrong. > Software developers forced to vendor lock-in their software I've made Dockerfile's for quite a few different apps now, and I have never once had to actually change the application. The applications still work completely independent of Docker, so I'm not sure where the "vendor lock-in" comes in here. > Docker won't be able to run even Postfix (or FTP daemons) https://github.com/tomav/docker-mailserver https://github.com/tomav/docker-mailserver https://github.com/atmoz/sftp https://github.com/atmoz/sftp > Docker is designed with cloud computing providers in mind exclusively I would disagree, although this is a matter of opinion I suppose. Having used both VM's and Docker for deployment, Docker is ridiculously more developer-friendly than a standard VM architecture. > No way to escape dependency hell I don't worry about dependencies anymore. If I want to try a new app, I `docker run` it. No dependencies. My apps themselves comes with all of their dependencies so I don't have to screw around with dependencies on a host provider. Sure, it doesn't completely solve dependency problems (you still need to write a Dockerfile) but it makes my life a whole lot easier compared to without Docker. Docker isn't the right fit for everything, and there's a lot of ways that I can think of where it can be improved. It strikes me like this was written by a frustrated sysadmin who hasn't spent the time to learn the tools (which is understandable, the learning curve is high and most things are different from traditional sysadmin tools). In fact, in alot of cases Docker is needlessly complex and overkill. However, spreading FUD doesn't do anything to address these concerns and might scare away a lot of developers who could benefit from Docker.

eganist 10y ago
> However, in most cases they recommend against it because it usually means you're doing something wrong. Docker-novice question for you: What's the best practice for this? What assumptions are at play for said best practice? I can understand separating DB from App, but what about other cases where an app might naturally have to have multiple processes running? ••• Edit: I hate calling this out, but if you're going to downvote questions asking for elucidation of the reasons surrounding best practices for a platform (something I'm frankly having a hard time finding in the case of Docker), keep in mind that doing so does nobody any favors and only discourages productive discourse. You've got over 500 karma enabling your capacity to downvote. Be responsible with the practice of doing so. Nothing in this comment (except perhaps this edit) warrants one.

forgetsusername 10y ago

Why not simply choose not to use it if it doesn't fit your personal use-case? What is the purpose of inciting a boycott?

chrisper 10y ago

Okay. I will boycott Docker and use LXD instead if that makes you happy. ;) Anyways, I am so glad I converted all my VMs to LXD containers. If I want to test something, I can spin up a new container in seconds as opposed to have to install the OS in a VM (or do clones / snapshots etc.).

wje 10y ago

I am the former owner of boycottsystemd.org. I think I may have started something terrible.

qwertyuiop924 10y ago
No, you actually had a valid point.

raesene6 10y ago

This page looks seriously out of date now, as a result its criticisms are inaccurate in a wide range of areas. To pick one in particular, Security. the claim that Docker doesn't know anything about AppArmor and/or SELinux just isn't correct. and the other security claim about having to trust docker hub is also now not correct, you can use signed builds to avoid that concern.

deleted 10y ago

[deleted]

altern8tif 10y ago

I'm new to Docker, but from what I know, it makes a microservices architecture extremely easy to set up. Right?

jon-wood 10y ago
It makes a microservices architecture less painful to set up. Nothing is going to make one easy to set up, and even less so easy to run.

qwertyuiop924 10y ago

Is this a joke? There is so much very inaccurate about this.

alex95 10y ago

"Respect yourself and write software as you wish to, not the cloud computing corporations are happy to." > boycott docker Right...

fasteo 10y ago

What a rant about Docker! Would love to hear the motivations for setting up this site. It seems that the owner of the domain [1] likes boycotting [2] a lot. Not that a disagree with him. [1] Registrant ID: XGX4VME-RU Registrant Name: Sergey Matveev Registrant Email: stargrave@stargrave.org [2] http://www.stargrave.org/Boycotting.html#Boycotting http://www.stargrave.org/Boycotting.html#Boycotting

djhworld 10y ago

I was hoping for some reasoned arguments from experience, but this just seems like a rant from someone who has read about Docker.

agentgt 10y ago

The vendor lock in thing has embarrassingly been a concern of mine as well. It seems presently you are either locked in with your cloud provider or your locked with docker (e.g. using Google container engine vs Google deployment manager). As a JVM shop I just can't see the value of using Docker when we can provision faster images using the cloud providers API (ala libcloud, jclouds, or directly using gcloud) and just build exectuable uber jars. That is in JVM land you only need to install Java (and for Go and Rust I suppose you have even less dependences). I understand the value in the OSS world of providing docker images but I'm not sure I can justify the complexity of switching over yet. Are there any major companies (especially JVM) that have fully dockerized (ie converted and not started off using docker)? I know Netflix started too but I'm not sure they every did fully.

user5994461 10y ago
Use packer for EVERYTHING https://www.packer.io/ https://www.packer.io/ => better tools + avoid locking As a benefit, you use ansible/chef/puppet for the installation and configuration (instead of Dockerfile). You can reuse your scripts. As a benefit, you generate any output DockerImage/AWS-AMI/VmWare/VirtualBox. You have more flexibility. (e.g. Make an AMI for auto scaling groups + make a docker image for test environment).
- elsonrodriguez 10y ago
  I dig packer, but it's getting pretty hard to find a cloud provider or on-prem solution that doesn't take a Docker image as an artifact.

joepie91_ 10y ago

I don't like Docker, I feel that most people who claim it's "easy" don't really have sufficient experience with stacks that do not use Docker, and I think it's overall an overhyped piece of rubbish that shouldn't be recommended to people other than in some very specific usecases. That having been said, this site is terrible. It suggests a conspiracy without ever actually providing any evidence, and it's full of claims and assertions but very little to back it up. Docker has plenty of legitimate problems to address, and I don't really understand why somebody would half-ass their criticism like this.

mmgutz 10y ago

The minor gripe I have with Docker is how they're tying swarm into the docker tool. I can see a future where sysops will use the tools built into Docker because it's included just like how Windows made IE6 the default browser.

profmonocle 10y ago
> The minor gripe I have with Docker is how they're tying swarm into the docker tool. This is actually what I was expecting the article to be about when I read the title. Swarm integration has become a big controversy, and there's been serious discussion of forking Docker over it: http://thenewstack.io/docker-fork-talk-split-now-table/ http://thenewstack.io/docker-fork-talk-split-now-table/

chx 10y ago

> strict restrictions like single process per container Oh boy. Have you seen phusion/baseimage ? It supports boot time init scripts and then uses runit to let you add as many daemons as you want. It even has a "Wait, I thought Docker is about running a single process in a container?" brief chapter in the readme.

mohanmcgeek 10y ago

The author makes too many claims without actually supporting it. But I do agree with the author on that Docker these days doesn't seem to respect Unix philosophy. It wants to be everything. Case in point : integrating Swarm into docker.