Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

161–170 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#161
post #33

Earlier quoted context omitted.

They raised $55 million [1], so you have to believe their ambitions are to extract as much rent from the container ecosystem as possible. That's not a bad thing, but it's behind a lot of their moves. [1] http://www.crunchbase.com/organization/docker

Docker's MO is to become "that thing that is on all servers" so that when they flip the switch and start monetizing off support and tertiary services, people will be more-or-less locked in. It has indeed surprised me how quickly a normally-slow-to-accept-new-things community has adopted Docker (even well before it was considered "stable").

Like mongodb hype?

Docker seems decent but I don't think I want them to do ochestration..

Re: CoreOS is building a container runtime, Rocket

#162
post #92
post #87

Hi, I created Docker. I have exactly 3 things to say: 1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing. 2) "disappointed" doesn't even begin to describe how I feel about…

I think you're reading too much - or too little - into this if you think they're "slinging mud". Any fork is going to list its reasons for the fork- if they didn't have issues with how Docker is heading, why would they be making the fork in the first place? If they just quietly gave an ambiguous non-disparaging statement like "we're forking because we're unhappy with the direction Docker is taking", it would seem fri…

I don't have a horse in this race, but from what I read this is the part that can be construed as "slinging mud". I've put some [read between the lines] comments in square brackets:

  "Unfortunately, a simple re-usable component is not how things are playing
   out. Docker [much to our dismay] now is building tools for launching cloud
   servers, systems for clustering, and a wide range of functions: building
   images, running images, uploading, downloading, and eventually even overlay
   networking, all compiled into one [big and nasty] monolithic binary running
   primarily as root [how insecure is that?] on your server. The standard
   container manifesto was removed [those flip-floppers!]. We should stop
   talking about Docker containers, and start talking about the Docker
   Platform [since we can focus attention on our efforts that way]. It is not
   becoming the simple composable building block we had envisioned [which puts
   our offerings at a disadvantage]."

  "We still believe in the original premise of containers that Docker
   introduced, so [unlike those silly Docker people] we are doing something
   about it."
Later on, they specifically say:

  "the Docker process model ... is fundamentally flawed"
  "We cannot in good faith continue to support Docker’s broken security model..."
All these may be valid criticisms, but even ignoring my potentially off-base annotations it's difficult to read their announcement as anything other than "Docker is broken and can't be fixed". It's reminiscent of political attack ads which focus on the shortcomings of your opponent rather than the strengths of your own platform.

Re: CoreOS is building a container runtime, Rocket

#163
post #88
post #83

I had just landed LXC container support in Velociraptor [1] when Docker was announced last year. It uses Supervisor to launch LXC containers and run your app inside. I thought long and hard about switching to Docker, but their decision to remove standalone mode [2] would have meant replacing all of Velociraptor's Supervisor integration with Docker integration instead. With Docker being such a moving target over that…

Yes, the app-container spec has the concept of dependent filesets. See: https://github.com/coreos/rocket/blob/master/app-container/S... https://github.com/coreos/rocket/blob/master/app-container/S... What do you think of the filesets concept?

Please no json file, use yaml or have an option for yaml T___T.

The curly braces and brackets can get ugly when nested.

edit:

It may seems stupid but when you're on the terminal with vim and the directory path is long in some nested object/array. Things is really hard to parse out with your eyes.

Re: CoreOS is building a container runtime, Rocket

#164
post #33

Earlier quoted context omitted.

Docker's MO is to become "that thing that is on all servers" so that when they flip the switch and start monetizing off support and tertiary services, people will be more-or-less locked in. It has indeed surprised me how quickly a normally-slow-to-accept-new-things community has adopted Docker (even well before it was considered "stable").

There is no switch to flip. You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git.

> You are not "locked in" by Docker Inc if you are using Docker just like you aren't locked in by Github if you are using git.

A much more accurate analogy would be you are not "locked in" by Oracle if you are using MySQL. It may be true today, but no guarantee that will always be the case.

Re: CoreOS is building a container runtime, Rocket

#165
post #87

Hi, I created Docker. I have exactly 3 things to say: 1) Competition is always good. Lxc brought competition to openvz and vserver. Docker brought competition to lxc. And now tools like lxd, rocket and nspawn are bringing competition to Docker. In response Docker is forced to up its game and earn its right to be the dominant tool. This is a good thing. 2) "disappointed" doesn't even begin to describe how I feel about…

If you were trying to make sure as many people as possible paid attention to Rocket as a serious alternative to Docker, which is the current de facto standard Linux containerization scheme, well done.

Re: CoreOS is building a container runtime, Rocket

#166
post #140
post #114

Earlier quoted context omitted.

My +1 goes to Kelsey Hightower. He posted on 7 Nov some worries which many Docker users and contributors, already had since the past year, when you dropped off LXC containers, instead of working together with https://linuxcontainers.org/ project to get a better code. That seems already a strategic business decision to decouple your "product value" from his mother and generator: LXC. IMO, Docker's 'new' direction comp…

> IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities. Kind of weird that this line from your comment is identical to a line in this comment from another user: https://news.ycombinator.com/item?id=8682864

Hacker plagiarism.

Re: CoreOS is building a container runtime, Rocket

#167

Earlier quoted context omitted.

I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration. The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.

Interestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial. I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools. Links? Nah just use ips/…

That sounds awesome. I'm learning docker and I might wait on this issues to resolve first.

I don't like the sound of locking into one vendor for everything.

Re: CoreOS is building a container runtime, Rocket

#169
post #148
post #142

Earlier quoted context omitted.

I'm just calling you a troll, and it's for implying that a cabal of Docker employees somehow manipulates and suppresses the public conversation about containers for the profit of their employers.

You came here with the explicit intent of disseminating your viewpoint that CoreOS is making a terrible decision and why your company and it's ideals are better. Your company already made an official PR response, leave it at that. (and you call me a troll?) For the first time in Docker's short history, it's future and mission are being directly challenged. This is your response? (it won't be the last time Docker is d…

> Imagine if Microsoft went around rattling the cage every time Apple released some product

You mean like this? https://www.youtube.com/watch?v=eywi0h_Y5_U FIVE HUNDRED DOLLARS FOR A PHONE?

In all seriousness, you made a few blaming statements early on in this thread which is the most likely reason got the reaction you did from Solomon. I'm not opposed to people making observations, but speaking for others really has no place here!

Specifically talking about the "PR machine" comment. Say what you mean!

Re: CoreOS is building a container runtime, Rocket

#170
post #90

Earlier quoted context omitted.

Interestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial. I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools. Links? Nah just use ips/…

The thing I like about the link model is that they hide your containers from other containers and only expose the connections you want (I think using iptables?) I'd like a tool that makes this linking easier outside of Docker, but for now this is one of the features I like about it (although holy moly do Docker links have a lot of baggage you have to bring along for the ride, like giving everything names).

Shameless self plug, but not sure if you saw my project that does something along these lines:

https://github.com/vishvananda/wormhole

Post reply on HN