search

subuser-security / subuser

Run programs on linux with selectively restricted permissions.
http://subuser.org
GNU Lesser General Public License v3.0
889 stars 65 forks source link

Docker isn't perfect #216

Open timthelion opened 9 years ago

timthelion commented 9 years ago

Docker is not a healthy community. The first and foremost issue that would need to be fixed with Docker, is that most releases break something for subuser:

This constant breakage can, in the pre-1.0 days, be explained. But It hasn't gotten any better as the project has "matured". It seems that docker has changed it's release cycle to one in which there are release candidates. However it seems that development doesn't stop so that people can focus on polishing the new release and there is so much noise in the community that there is no clear and effective way to cummunicate an issue with a release candidate. And comming to the next problem, one can have no confidence that Docker Inc would actually care about fixing issues if they were found.

That brings me to the last problem:

While Docker might seem like a vibrant community with 1066 contributors, the truth is, that Docker is a one company show. There WERE other companies who tried to get on board as well as independent developers such as myself. However, almost all of us have left. Docker has made it very clear that it does not need or want substantial outside help. To some extent, this is an understandable reaction on their part. A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged. Another thing they often said was along the lines of "systemd is THE ONE AND ONLY INIT SYSTEM so why do you care about writing code that might be portable?" Or "even though the universal method works with systemd now. A redesign has already been planned in systemd, so do it the new systemd way and don't be portable."(This is in response to the fact that Docker writes to cgroups, and systemd would like to be the "sole writter to cgroups" some time in the future.) I think everyone got fed up with those people, and Docker has rightly pushed them out. But at the same time, Docker Inc seems to have pushed everyone else out too, including me.

One difficulty for me in analyzing this though, is that the Docker community once seemed vibrant, but I think it never was. I think that it seemed vibrant because there were many people from different places working on it. However, lately many of those poeple have changed their github profiles to show that they work for Docker Inc. My understanding is that those people all worked for Docker from the start (not that Docker hired them) and that I was under the false impression of community diversity from the start.

My experience working on Docker was painful. Despite the fact that I wrote two code refactorings (fixing a previous version of the networking code and writting the current device code), which should have been of interest to most of the main devs, they hardly ever communicated with me. One exception was Micheal Crosby, who was indeed helpful, however he was the ONLY person working with people outside of Docker, and he was WAY OVERSTREACHED. So his communication, despite being kind and well meaning, wasn't very meaningfull. He just didn't have time to do a good job.

This lead to two problems with the device code that I wrote and submitted as a pull request:

docker run --device=/dev/snd:/dev/snd ...

Unfortunately /dev/snd is a DIRECTORY and not a device. If the person writting the release notes had simply shot me, the developer, a quick email I would have quickly seen the error and been able to fix it. Instead, the Docker folks experienced a stream of people posting issues asking why --device doesn't work, and eventually they changed --device to traverse directories searching for devices within them (which in itself is a bit wrong as the mounted devices using this method are static, they don't change after the container is created).

My poor experience as a Docker contributor: lack of recognition and communication, seems to have been the same for many other contributors. This poor contributor experience is causing the Docker comunity to become less diverse, and this jeprodizes Docker as an open source project. Continuing to write subuser when subuser relies on Docker therefore seems a risky prospect.

What other options does subuser have?

Subuser is rather strongly tied to Docker. It would be hard to transition and maintian any resemblence of compatibility. I would have to have a very good alternative.

Should subuser move to a new system?

Probably not. The grass is always greener, as they say.

peter1000 commented 9 years ago

Hi Long time not heard ;)

well I still postponed my eventual move to a more container based Operating System as other things came in the way - as always aren't they?

Just this week I needed skype and I tried 4 or 5 version from docker hub but none of them worked out of the box.

I still follow most of your issues and I thought I just say hello :)

https://github.com/coreos/rkt - I did read up on it a while ago and it was still unuseable but it seems that they did a bit of work on it. If I once move to a container OS I probably will look into it again. Seems that google invested into them: Google bets big on this little tech startup - not sure if that is good or bad ;)

Maybe it might be worthy to spend a day or two and look into it: I guess they might be also more open to input but who knows?

Cheers P

timthelion commented 9 years ago

EDIT-NOTE: Some of this post is harsher than I would like. However, I am leaving it how it is, because I don't want to simply sweep my own imperfections under the rug.

After having thought about this some, I think that the best approach is to continue to use Docker. While subuser has some reliance on Docker in the code, the reliance is not tied strongly to Docker itself. The only thing we need, is some kind of container software that uses the Layer paradigm. Moving to anything else that uses layers would be easy. So I don't feel that threatened that I am tying subuser to Docker.

I think that it is also good to see Docker as three things:

I think that the Docker standard with it's layers is reasonable. It is not perfect, but it is the best container standard out there.

I think that the Docker program is poorly written and designed. My experience with the source code (which has been quite intimate) has taught me that the code really is not well written. I think that the Docker software is both hard to maintain and slow. It is hard to maintain due to its divided architecture (server+client) and Solomon's obsession with plug-ins and extensibility. It is slow because of its data serialization methods.

I think that Docker Inc. is problematic. They have not been kind to the "community" and they have failed to live up to their promises of stability at all costs.

So the solution?

Re-write Docker.

A program written with a classical database+library+front-end architecture would, in my opinion, out-preform Docker significantly while being able to emulate Docker's behavior on almost any front. I think that it is realistic to think that such a Docker "clone" will be written in the future. Docker's performance is really terrible and Docker Inc. seems to have pissed off more than just myself.

ptman commented 9 years ago

I thought everyone was onboard to work together on https://www.opencontainers.org/ . Is that a suitable option?

timthelion commented 9 years ago

@ptman I am vaguely aware of that initiative. Perhaps it may become relavent in the future if such a standard ever actually exists, but I don't think it is good to give attention to any new technology untill it can be downloaded/bought and tried out in real life. The health section of the news paper has been filled with AIDs cures since AIDs was first discovered, and cancer cures as well. Most importantly, however, I'd like to point out to you that Open Containers has a github project and two of the three "people" in the project are Docker folks and the third is a mistery account with no prior history or link to personal website. Apparently, there is no way to find out who the actual maintainers of a github repo are, it does, howerver, look like there is at least a diverse set of people with commit access to the repo. I counted at least Docker + Redhat employes merging PRs there.

lightonflux commented 9 years ago

Just want to mention bocker as a simple Docker reimplementation.

https://github.com/p8952/bocker

timthelion commented 9 years ago

@lightonflux That is actually surprisingly complete, but not complete enough. It's totally insecure however. It seems it doesn't set up the devices cgroup at all.

utdemir commented 9 years ago

It's more of package management than virtualization, but I'll suggest Nix and NixOS.

Nix is a purely functional package manager which you can describe a packages dependencies and build process declaratively. NixOS extends this declarative package management to the whole system.

With the ability to describe a system declaratively, they have the ability to spawn a system with specified configuration via any number of backends, including containers, or other virtualization solutions like libvirt.

timthelion commented 9 years ago

@utdemir In many ways, subuser and nix have similar goals. They both aim to improve maintainability and portability of Desktop software. What subuser adds is an isolation based security model. Without containers, nix doesn't bring much in that line. Or have things changed?

chanezon commented 9 years ago

Regarding OCI (Open Container Initiative), it is an active project, and there is a reference implementation that is actively developed called runC. You can run it today. The list of maintainers can be found at https://github.com/opencontainers/runc/blob/master/MAINTAINERS

It includes Michael Crosby, as well as maintainers from Google and Red Hat.

runC is part of the libcontainer codebase that is at the heart of Docker, and Docker gave the libcontainer code to the opencontainer project. The plan is, once the spec is complete and runC is done, to refactor docker to use runC behind the scenes. So one option to solve your issue would be to use runC directly.

I hope this helps.

ibuildthecloud commented 9 years ago

@timthelion You might want to look in depth at runc. I'm guessing it will match your use case of subuser better. The biggest problem you will have is that you will need to come up with a solution around pulling and staging images, but I believe at this point a lot of code in that area is in https://github.com/docker/distribution and you can probably interact with the Docker Registries and stage your own rootfs with out not too much hassle.

timthelion commented 9 years ago

@ibuildthecloud I think that my best bet for now is to wait and see how things come together. In the past day, nearly 7 thousand people have seen this issue and no one has come out with a perfect replacement for Docker yet.

I think that runC will be a good choice for subuser in the future, but not today. I think that the existance of libcontainer/runc and the storage libs and the networking libs make things much less claustrophobic for those of use who rely on Docker. The libraries themselves are fine. The spaghetti is in the core of Docker where the Docker API is. So "rewrite" Docker in the end becomes "replace this small bit of code that wires some libs together" which isn't that unrealistic in the end. I also think that these libraries are re-assuring on the "Docker is a one company show" front. For the most part, it doesn't matter if a company controls a statically linked library. The "one company show" part becomes scary when you think about Docker's preference for the Docker hub, or the difficulty of getting a pull request through that effect necessary functionality. Statically linked libraries also don't have the trouble with breakage. It doesn't matter if a statically linked library is broken in some versions, because I the developer can choose when and if to upgrade. It is also a lot easier to add functionality on top when using a library than when using a not quite HTTP api.

timthelion commented 9 years ago

@erichonkanen I closed it because I don't think this issue is actionable at the moment. I don't think that subuser can or needs to move away from Docker right now.

shykes commented 9 years ago

@erichonkanen it's difficult to answer subjective statements.

Velocity of the project is easy to verify: just check the Pulse. This month we merged 360 pull requests from 168 people. That is a lot of activity and is a LOT of work for the maintainers, who do an amazing job and are very responsive. Along the way they get criticized in a thousand ways and still continue to reply politely and take the time to provide thoughtful answers. Most people have no idea the level of abuse the maintainers of a high-activity open-source project have to endure. To dismiss all that work with general statements like "not nice to the community" is not very nice itself. I'm pretty sure the silent majority agrees that the Docker maintainers are awesome and work hard to make the project great (to be clear I'm not including myself in that group).

I agree that parts of Docker deserves a cleanup. Every very popular project does. You have to find a balance between quality, the features users are asking for, and the features outside contributors want to add. It can be a difficult balance at our "firehose" level if activity (imagine being pinged 200 times a day about 200 different pull requests). A lot of the cleanup is going on already. For example in 1.9 the network stack is rewritten from scratch. Yes, sometimes pull requests don't get reviewed as fast as they could, or we close pull requests because we disagree on design. We try hard to be open-minded, but it's impossible to make eveyone happy. For example my "obsession" with pluggability comes from the fact that the community asks us for pluggability with a very loud voice :)

In this example @timthelion was in the unusual situation of being strongly tied to the legacy lxc flags that could be passed to the lxc driver (but only that driver), and we deprecated those flags. Why? Quality. It was a necessary tradeoff, because being too tied to the lxc driver made it very hard to add improvements, fix bugs etc. The lxc driver was too hacky, because it required wrapping another command utility (lxc) which wasn't designed to be wrapped. Those hacks became the bottleneck for fixing quality, and contributed to the spagghetti code that @timthelion is also complaining about. Once we deprecated those flags it became much easier to improve Docker with libcontainer and we were able to vastly improve quality and reduce spagghetti, as you requested @timthelion :). It was a necessary tradeoff and I think it was the right decision. It just wasn't realistic to maintain full compatibility with the UI of a tool outside of our control which most of our users don't use or care about.

Beyond that, I would also recommend taking a look at runC. Once we refactor Docker to exec out to runC (which unlike lxc is designed to be wrapped), that should also help with overall quality and cleanness.

I would definitely recommend taking a look at alternatives. It will help put things in perspective. As the title of the issue says, Docker is not perfect! Maybe there is another tool out there for you that better suits your needs.

timthelion commented 9 years ago

@shykes While your argument for moving to libcontainer is compelling, the fact is, that the LXC backend still exists in the code base, it is merely dissabled by default. I am sure you will agree that maintaining two backends has in no way improved quality or maintainability.

As for velocity, I am sure that the velocity is quite high, but I have the impression that the velocity is dominated by Docker Inc. and power over the future of the product is in the hands of one company. The question is, whether this is a good/bad thing for subuser, subuser being a free software project with no comercial affiliation.

Finally, I would like to point out, that these breakages have been an issue for the subuser project. Beaking changes are hard for client side software, because I have no control over the computers that run subuser. I just get emails saying that subuser's broken. People doing server side stuff don't have it so bad. When they start up their container in the staging environment and Docker tells them that the r option for volumes is invalid, they look at the docs and change the r to an ro. It takes 30 seconds and nothing breaks. So this kind of mistake is not the end of the world for most Docker users, but for subuser it is.

I will be looking into runC and considering my other options. For now, subuser will remain tied to Docker. It does seem that most people are indeed satisfied with Docker. This issue got a few upvotes, but hardly a revolution.

shykes commented 9 years ago

@timthelion I forgot to address another question you ask.

the Docker community once seemed vibrant, but I think it never was. I think that it seemed vibrant because there were many people from different places working on it. However, lately many of those poeple have changed their github profiles to show that they work for Docker Inc. My understanding is that those people all worked for Docker from the start (not that Docker hired them) and that I was under the false impression of community diversity from the start.

Following Occam's razor, wouldn't a more likely explanation be that we've actually been hiring contributors to work on Docker full time, because it's a very efficient way to contribute to the success of the project?

I agree the balance between Docker inc contributors and outside contributors is an important topic, and finding the right balance is a lot of work. But it's something we really care about. The reality is that Docker would not be possible without either of these groups. It's been a rule from the very start that you contributions should evaluated the same way no matter where you work. Implementing that rule in practice is sometimes difficult - but we are still applying it, and if you have ideas for making it better, I am interested!

shykes commented 9 years ago

@timthelion I would disagree that the velocity of the project is "dominated by Docker inc". The breakdown is roughly 50% PRs from the outside, which is a lot. More importantly, the features contributed by employees are completely separated from commercial goals. We just want to build the best possible product, and give it away for free. The more people use Docker, the more people we can sell our cloud services and support to. It's really that simple. There is no incentive to "sneak" unnatural commercial features into the product, and in 2 years we have never done that.

timthelion commented 9 years ago

@shykes The way I see it, with Docker Inc. dominating development is the following: Yes there are many contributors who come from the outside with an issue that they want fixed. They send a PR and they leave. Micheal Crosby once complained that they "dump code" and "expect us to maintain it" (I don't mean to insult him by saying this. He has a point! ) . Then there are a few people who stick around for a longer period of time and form the "identity" of the project. Eight out of the top ten contributors are Docker employees (and one of the two non-Docker employees is no longer active). So while there are a lot of one/two off contributions from various people, of the people who could consider themselves to be "Docker developers", it is mainly employees of Docker Inc.

I don't think that there is anything really evil and nefarious about any of the code you have been contributing. I more see Docker Inc's maintenence of the code to be a carrot to keep Docker Inc in control of Docker. Given that there are so many employees working on Docker now, it would be basically impossible to fork the project. One would have to find and feed a team of 20-30 developers just to keep up. I think that this idea that you guys have "control over the future of the project" is mostly philosophically challenging. As an example, many people complain that Google has controll over internet search, but few people complain that they cannot find things with google. So is google evil because it works well and is therefore successful?

I don't think that the idea of you "sneeking" comerial features into Docker makes much sense given it's open source nature. However, there is one feature that is directly defined by Docker Inc's controll of Docker:

FROM <image>

The <image> part is directly tied to your cloud services. It's like if git used github names and repository names to refer to repositories rather than URLs:

$ git clone subuser-security/subuser

Rather than

$ git clone https://github.com/subuser-security/subuser

That would be simpler, but would you still feel that git was free software?

shykes commented 9 years ago

@timthelion all legitimate questions with no easy answers.

On the topic of "FROM ". It's tricky because on the one hand users want flexibility in where they download images (same request you're making with your "git pull" example). On the other hand users also request a high-quality and secure "standard library" of images which they can track down to a trusted source no matter where Docker is installed.

The way we have balanced these 2 requirements Is by combining 2 features

So, I believe our current system is not perfect but it strikes a good balance between a consistent source of quality content for all Docker users, and the ability to control where you host your content and who you trust. With Notary and hopefully the ecosystem of RunC-compatible tools and hooks, there should be even more opportunities to fine-tune your Docker installation.

timthelion commented 9 years ago

I'm not sure if I understand the format for FROM precicely. Its without an http:// right? That means that images cannot have the . symbol in their tags? I'll send along a PR for the docs here, https://docs.docker.com/reference/builder/#from which don't document the syntax you just mentioned, if no one beets me to it that is.

Perhaps I am judging you too harshly. Just because some rich people gave you a wad of cash doesn't mean that deep down inside you are not a human being with close relatives who truely beleive that you are a nice little boy and whom you still desperately wish to impress. (That's the basis for human morality, right?)

If anyone comares the Docker FROM command to git clone again. Like I did. Just tell them: "Well, in Debian, apt-get install takes a package name and not a URL. Debian is still free software."

maxnordlund commented 8 years ago

Somewhere in the beginning of this thread, rkt from CoreOS was mentioned. But why it exists was not, and is something at least I find very interesting to the tying Docker Inc to docker the program.

It basically boils down to feature creep, when docker-machine / docker-compose and friends showed up. They are not necessary for running containers, but makes it easier to get some of the common things done. I don't deny the convenience of running docker-compose up, but it did threaten/alienate a fair amount of the players in the wider docker ecosystem.

Then the open container project and open container initiative happened to try to remedy this. But the fact remains that the docker tool(s) really tries hard to lock you in. Maybe this is a good thing, but it doesn't feel very unixy for a single tool to have more then a single responsibility (and one could argue that their are a set of docker-* tools, not just one).

This wasn't the most uplifting of comments, and open source maintainers deserves much better treatment, not abuse like this. I'm sure you all meant well so, please take this more as a critique to Docker Inc, then to docker the program.

timthelion commented 8 years ago

I was just reminded of this issue today, and I have to say that I regret saying that Docker is poorly written. It was quickly written, and there were quality control issues, but I shouldn't have lowered myself to the level of saying "poor". No one deserves to be told that their code is "poor"... It is this kind of vague critique which causes stress and unhappiness but does not improve quality.

vbatts commented 8 years ago

<3

On Fri, Jan 29, 2016, 15:24 Timothy Hobbs notifications@github.com wrote:

I was just reminded of this issue today, and I have to say that I regret saying that Docker is poorly written. It was quickly written, and there were quality control issues, but I shouldn't have lowered myself to the level of saying "poor". No one deserves to be told that their code is "poor"...

— Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/216#issuecomment-176780103 .

shaaati commented 8 years ago

Did you have a look at the aforementioned rkt lately? It looks like they have made great progress and the blog post about their 1.0 release from a few days ago makes me really want to try it out. https://coreos.com/blog/rkt-hits-1.0.html

shykes commented 8 years ago

I'm perpetually amazed at the power of self-persuasion. Once a person believes a story, they can incorporate almost any fact in a way that reinforces that story...

In this case, the story is "evil VC-backed company tries to lock you in with bloated software, but the rebellion fight to protect your freedom". Ask yourself: what would need to happen for you to stop believing this wonderful story? What facts would convince you that your this story is incorrect? For example:

All of these things have happened. So, what would it take for you to change your mind? I'll tell you my opinion, and the opinion of everyone working at Docker: nothing we can do will ever convince you, because your belief is immune to facts. You have chosen to believe a beautiful story about the evil empire and a rebellion. That story fits your beliefs, it "feels right", and you ate it up without fact-checking. You are being scammed. I personally know the people telling you the story. They are experts at marketing, they are professionals. They know how to play on your fears and stereotypes, they know how to give the press what they love most: dramatic tension. "inferior Docker clone launches 2 years too late" is a lame headline. But "container wars"? Front page! Finally some action! They know how to craft soundbites that you will repeat without checking them. They have figured out that with this kind of audience, marketing by negativity actually works...

...which makes me incredible sad, because if there's one thing that Docker has NEVER done and will NEVER do, it's say negative things (and even worse, provably incorrect things) about a competing product to try and advertise ours. It's scummy, it's classless, and we will never do it.

I challenge you to find a single blog post or article by Docker that mentions a competing product in a negative way.

Now, I challenge you to find a single blog post about rkt that doesn't make vague, unsupported claims about the quality and security of Docker.

Honestly I feel bad for any company which has to resort to such negativity to sell their product. Really, is your product so unexciting that you have to resort to tactics worthy of Fox News? I love everything about working in Silicon Valley, except the fact that companies like this exist. They are an embarrassment to the tech community.

Anyway - that's my rant. I'm sure I'll get in trouble for it in some way, since I don't have the same gift for demagogy. It just drives me crazy to see to what incredible degree you can lie to a group of gullible engineers, and get away with it.

ryneeverett commented 8 years ago

From coreos's website:

At the time of writing, the Docker Engine daemon downloads container images, launches container processes, exposes a remote API, and acts as a log collection daemon, all in a centralized process running as root. While such a centralized architecture is convenient for deployment, it does not follow best practices for Unix process and privilege separation; further, it makes Docker difficult to properly integrate with Linux init systems such as upstart and systemd. Since running a Docker container from the command line (i.e. using docker run) just talks to the Docker daemon API, which is in turn responsible for creating the container, init systems are unable to directly track the life of the actual container process.

rkt has no centralized “init” daemon, instead launching containers directly from client commands, making it compatible with init systems such as systemd, upstart, and others.

@shykes This is the heart of the argument that "docker is not unixy". Is it inaccurate?

timthelion commented 8 years ago

@shykes I am also a bit appauled by the fact that those who distrust Docker Inc. are so willing to trust CoreOS. My distrust of Docker comes directly from the fact that the software is so tightly tied to a single for profit company. That seems to be the general reason for other's distrust too (well, there are also some people who just hate success, "might makes wrong and all that"). However, CoreOS is, if anything, even more of a one company show than Docker is.

I personally, am not falling over myself to get behind rkt, I see the project as having the same core flaw as Docker Inc. does. However, if there was a project like Linux (multi company show), emacs (not a company show at all), or ffmpeg (which at least used to be maintained by a private individual who was merely providing consulting work, but couldn't have been said to be directed by any comercial motives), I would certainly get behind that project if technical aspects were satisfied.

It seems unlikely that there will ever be truely non-comercial enterprise software. That's almost an oxymoron. But containers do not HAVE to be enterprise, as subuser shows.

I don't think that there is much you can do to get people to trust Docker Inc. People are naturally distrustful of for profit companies. If you look at the history of abuses commited by for profit companies, especially when those companies which started out acting charitably, you will find that this distrust is justified. But the trust people have for startups, is certainly unjustified, because startups are even less trustworthy than established companies. As for me, I was really relieved when I saw that you started charging for private repos on Docker hub. I always go by the saying: "Never trust any company if you don't know where it gets it's money." It is the capitalists equivalent to Mr. Weasley's "Never trust anything that can think for itself if you can't see where it keeps its brain?”

In terms of companies giving things away look no farther than:

In order for people to respect you, as a for profit company, it's not enough to simply give things away, you have to make it clear that you are giving it away out of the goodness of your heart, and not out of some sinister and unseen motive. Personally, I don't think that there is a sinister motive behind Docker, and that you really do hope to "grow the ecosystem while maintaining control in order to expand your consulting business". But in my mind, as a true free software developer, even just the "while maintaing control" part makes me somewhat slightly woried. And the knowledge that subuser is of no comercial importance to Docker Inc. also makes me woried. I feel, that if I cannot promise you money in return for your attention, then you have no reason to give me attention. And sometimes downstream needs upstreams attention. And since for profit companies are purely selfish, then if I have a severe enough issue, I might be screwed by relying on such software.

Does that make any sense?

On 02/12/16 05:06, Solomon Hykes wrote:

I'm perpetually amazed at the power of self-persuasion. Once a person believes a story, they can incorporate almost any fact in a way that reinforces that story...

In this case, the story is "evil VC-backed company tries to lock you in with bloated software, but the rebellion fight to protect your freedom". Ask yourself: what would need to happen for you to stop believing this wonderful story? What facts would convince you that your this story is incorrect? For example:

  • Should Docker launch all new functionalities as separate, optional tools which can be installed separately?
  • Should Docker implement seccomp, user namespaces, cap drop, selinux, and every other security feature available on Linux?
  • Should Docker break out its core runtime as a separate binary and donate the spec to an open governance body?
  • Should Docker implement cryptographic signature and verification of images to improve security, and along the way contribute a complete open-source implementation of TUF for everyone to re-use in their own products?
  • Should Docker make it super easy for anyone to run their own registry, either privately or as a commercial service, even if it means supporting its own competitors out of commitment to the open-source model?
  • Should Docker make it super easy for developers to pull images from any registry, not just Docker Hub, simply by specifying the URL in their Dockerfile?
  • Should Docker fully document all its APIs and formats, and make its reference implementations available as nicely componentized libraries to make alternate implementations easier?
  • Should Docker place the quality bar high enough on its source code to earn an A+ rating in tools like this: https://goreportcard.com/report/github.com/docker/docker

So, what would it take for you to change your mind? I'll tell you my opinion, and the opinion of everyone working at Docker: nothing we can do will ever convince you, because your belief is immune to facts. You have chosen to believe a beautiful story about the evil empire and a rebellion. That story fits your beliefs, it "feels right", and you ate it up without fact-checking. You are being scammed. I personally know the people telling you the story. They are experts at marketing, they are professionals. They know how to play on your fears and stereotypes, they know how to give the press what they love most: dramatic tension. "inferior Docker clone launches 2 years too late" is a lame headline. But "container wars"? Front page! Finally some action! They know how to craft soundbites that you will repeat without checking them. They have figured out that with this kind of audience, marketing by negativity actually works...

...which makes me incredible sad, because if there's one thing that Docker has NEVER done and will NEVER do, it's say negative things (and even worse, /provably incorrect things/) about a competing product to try and advertise ours. It's scummy, it's classless, and we will never do it.

I challenge you to find a single blog post or article by Docker that mentions a competing product in a negative way.

Now, I challenge you to find a single blog post about rkt that /doesn't/ make vague, unsupported claims about the quality and security of Docker.

Honestly I feel bad for any company which has to resort to such negativity to sell their product. Really, is your product so unexciting that you have to resort to tactics worthy of Fox News? I love everything about working in Silicon Valley, except the fact that companies like this exist. They are an embarrassment to the tech community.

Anyway - that's my rant. I'm sure I'll get in trouble for it in some way, since I don't have the same gift for demagogy. It just drives me crazy to see to what incredible degree you can lie to a group of gullible engineers, and get away with it.

— Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/216#issuecomment-183172071.

purpleidea commented 8 years ago

It seems unlikely that there will ever be truely non-comercial enterprise software.

You might be conflating proprietary with commercial, but it wasn't clear. In case you were, please realize that they are different distinct comments.

I don't think that there is much you can do to get people to trust Docker Inc. People are naturally distrustful of for profit companies.

It's very easy to do things if you want to instil more trust. Releasing your software with some sort of copyleft, and having outside contributors is a legal guarantee that you're less able to screw them over and go full opencore or proprietary. While I like the ALv2 license that Docker is released under, it doesn't protect it's users from this kind of abuse.

shykes commented 8 years ago

@timthelion yes you are making sense. Sorry if I came across as too harsh earlier. Trust in general is a hard topic.

If it helps, almost 50% of activity on Docker comes from non-employee maintainers. And 100% of pull requests are reviewed based on their technical merit, not commercial interest (our commercial interest is for our software to be as good as possible so that more people use it).

I agree that one should not blindly trust other people's software, especially when building something important with it. I'm afraid there's no easy answer.

Keep up the good work with subuser, I think there's a lot of cool things that can be done with containers on the desktop, the current tools are still not seamless enough (including docker).

maxnordlund commented 8 years ago

While I do agree with most of the above, there are a few things that are in rkt/CoreOS favor. They have integrated with a number of other companies, Intels Clear Cotainers (which I believe will also come to Docker), CNI (also in Docker?) and the Appc spec.

There are plenty other alternatives to CoreOS and Docker like Rancher OS, Kubernetes, the various tools from HashiCorp, Project Calico just to name a few. So it's not like there are no other option, but they aren't promoted by Docker (why would they), which makes it harder for new users to make an informed choice.

I think the culprit here is the perceived, if not the genuine, culture of the different companies. This may be to marketing, or the genuine thing, but at least from the outside, CoreOS being a third-party seams nicer. Docker feels more inclined to "lock" you in, by reimplementing already existing tools to do the higher level container orchestration. Again the UX is really nice, but the centralization/one-app-to-rule-them-all is still very much present.

NodeGuy commented 7 years ago

I am also a bit appauled by the fact that those who distrust Docker Inc. are so willing to trust CoreOS. My distrust of Docker comes directly from the fact that the software is so tightly tied to a single for profit company. That seems to be the general reason for other's distrust too (well, there are also some people who just hate success, "might makes wrong and all that"). However, CoreOS is, if anything, even more of a one company show than Docker is.

I personally, am not falling over myself to get behind rkt, I see the project as having the same core flaw as Docker Inc. does.

I appreciate and value your opinions and criticism and definitely the inspiring work you've done on Subuser (thank you!). I don't know much about rkt but it looks promising to me and I wonder if it would be worthwhile for us to evaluate and criticize it based on its technical merits in addition to the culture that produced it.

timthelion commented 7 years ago

One truly interesting approach that I see is that of appimage http://appimage.org/ which solves the image serialization format and the sandboxing as separate problems for separate programs. Unixy. I like it. I think that there is some bleed-through, for example, with a COW you can limit the disk space available to the application which is a security feature and not a serialization problem. Also with mounting the subuser's filesystem, there are many security concerns. But still, I find the idea very intriguing.

I will also take another look at rkt, as you have suggested.

On 12/09/2016 07:38 PM, David Braun wrote:

I am also a bit appauled by the fact that those who distrust
Docker Inc. are so willing to trust CoreOS. My distrust of Docker
comes
directly from the fact that the software is so tightly tied to a
single
for profit company. That seems to be the general reason for other's
distrust too (well, there are also some people who just hate success,
"might makes wrong and all that"). However, CoreOS is, if
anything, even
more of a one company show than Docker is.

I personally, am not falling over myself to get behind rkt, I see the
project as having the same core flaw as Docker Inc. does.

I appreciate and value your opinions and criticism and definitely the inspiring work you've done on Subuser (thank you!). I don't know much about |rkt| but it looks promising to me and I wonder if it would be worthwhile for us to evaluate and criticize it based on its technical merits in addition to the culture that produced it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/issues/216#issuecomment-266088128, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-Dc9VmXp2pJC4fyOD5VOZ-ZvXlrxks5rGaARgaJpZM4Fxpvf.

NodeGuy commented 7 years ago

Firejail supports AppImage.

timthelion commented 7 years ago

Add to the concerns above, that debian will restart docker when docker is updated, thus causing all subusers to shutdown...

Jipok commented 4 years ago

It's hard for me to say how relevant this is. But what do you say about this project: https://github.com/containers/bubblewrap