Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

181–190 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#181

Earlier quoted context omitted.

I attended Docker Global Hack Day #2 on Oct 30 from Austin. A talk was given on an active Docker project for host clustering and container management, which was non-pluggable, and made no reference to and used none of the code from CoreOS's etcd/fleet/flannel projects. This was where I first started worrying about CoreOS and Docker divergence.

I saw that same presentation at the same event, but came away with a very different impression: the container management they showed was implemented completely outside of docker itself, with no patches to the docker codebase needed. Also, IIRC it actually did use significant code from etcd for coordination.

Are we talking about the same thing?: https://github.com/docker/docker/pull/8859 ???

It had no etcd in it and the POC was implemented as part of the Docker API/CLI, as best I recall. There were significant questions in the discussion about etcd not being there.

Re: CoreOS is building a container runtime, Rocket

#182
post #92

Earlier quoted context omitted.

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…

It's really bugging me people are using the word "fork". This is not a fork, it's a competing container format, there isn't any docker code in Rocket AFAIK. Even @shykes called it a fork in a comment, it's not somebody taking your code and doing something different with it, they are doing their own implementation. Ideas aren't "forked", code is. As to everything else, I manage CoreOS clusters with docker for now, and…

IMO rewriting something from scratch is like forking but worse because it's impossible to merge later. And Rocket is definitely forking the Docker community.

Re: CoreOS is building a container runtime, Rocket

#183
post #88

Earlier quoted context omitted.

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.

I think using JSON is a solid choice. You can easily make yaml to JSON translators for this purpose.

Re: CoreOS is building a container runtime, Rocket

#184
I've excited for competition but unfortunately the post seems a bit confused in its message.

On one hand it talks about the original Docker manifesto and later says it was removed, with the removal being a "bad" thing. However, it refers to Docker not being simple as there are plans to add more and more features to it.

Including, "wide range of functions: building images, running images, uploading, downloading, and eventually even overlay networking, all compiled into one monolithic binary running primarily as root on your server". However, in the original manifesto (that was removed), Docker announced/claimed those features would/should exist: https://github.com/docker/docker/commit/0db56e6c519b19ec16c6....

Competition is good but this was a bit weak in its first appearance.

Re: CoreOS is building a container runtime, Rocket

#185
post #12

This is how Linux fragments, and ultimately dies as the Linux we know. I'm not really making a value judgement, just an observation.

I dunno if linux fragments is causing linux to die... BSD have many fragments and they're doing fine.

I think competition is good, this will give us an option that's not monolithic.

I didn't realize docker direction was to encompass orchestration until this thread. This isn't something I want to use docker for and also I'm glad the competition is address the security issue where there is a need for more security.

And with a rival option I'm happy to choose rocket as an option when it's stablized and there aren't any other options out there.

Re: CoreOS is building a container runtime, Rocket

#186
post #172

Earlier quoted context omitted.

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.

An article spreading fud on Docker's philosophy is at the top of HN. I added a comment describing the actual Docker philosophy.

Your comments on this post have done more to damage my faith in Docker's philosophy than the Rocket announcement did.

Somebody highlighted concerns they have with the direction of your product. You may not agree with their opinions, but that doesn't make them FUD. They have every right to ship a product that adheres to their vision, just as you do.

Re: CoreOS is building a container runtime, Rocket

#187

Earlier quoted context omitted.

Two thoughts: 1. Competition? How can open source software be in competition with anything? It's free, its source code is there; if people want it they'll use it, if not they won't. Why would anyone care what other projects are doing or saying? Just build your tools how you want and go on with life. (Unless you're building your tools specifically to make money, in which case I guess PR and 'competition' does matter a…

> How can open source software be in competition with anything? Market share is power. Popular open-source projects can, and do, shape the industry. If you believe your trajectory is the right one for the industry, competition matters a lot. As an example, Mozilla's Firefox was created to compete with Internet Explorer. It succeeded, and now Mozilla is working to defend the open web, so market share is still crucial…

I'm sorry but you're incorrect. Mozilla's Firefox was originally called Phoenix, and it was created because Mozilla the browser was a dog-slow encumbered monstrosity of Netscape's attempt to create an all-in-one solution for the web. Firefox was essentially competing with Mozilla Suite, but it wasn't so much "competing" as filling a necessary role: a browser that didn't suck.

Mozilla Suite was also not created to compete with Internet Explorer. In fact, Internet Explorer was created to compete with Netscape, which was the dominant browser for years until IE finally knocked it off its catbird seat. It never recovered because IE offered a simple, fast browsing experience, even if it sucked dick at actually rendering content.

In this vein, Phoenix was created in the model of Internet Explorer. So in a way you could say it competed, but in actual fact it was competing against its own progenitor.

Reflecting more on 'competition': the browser wars nearly destroyed the web as we know it as each browser introduced incompatible proprietary extensions which were then picked up (badly) by each other over time. The lack of standards, or good implementations of standards, severely hampered the adoption of more advanced technology. Firefox continues that tradition today by pushing more and more features that IE can't support; we're just lucky that Firefox is the dominant browser now, and that people are now used to upgrading their browser virtually every week.

Re: CoreOS is building a container runtime, Rocket

#188
post #172

Earlier quoted context omitted.

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.

An article spreading fud on Docker's philosophy is at the top of HN. I added a comment describing the actual Docker philosophy.

You have to realize that commenting here, in this thread in particular is not helping things... Instead of keeping your head down, letting the buzz blow over, you just made the PR that much stronger for the CoreOS POV. You should have thought about posting an article in a few days/weeks that, while not directly refuting the CoreOS post, put the Docker vision front and center and made it seem like you were the leader of the market, not just a company that was blindly reacting.

I think it's safe to say that while your comments here made you feel better, they didn't help your position at all, regardless of how valid your points are.

Re: CoreOS is building a container runtime, Rocket

#189
post #140

Earlier quoted context omitted.

> 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.

@jsprogrammer yes,

cutting & pasting (hacking :) is faster, if you're not mother tongue but believe me, in Italian it won't sound so gentle & polite.

Moreover, ... we all hope that like a "plagiarism" it won't became a a common feeling, a meme.

So what about the other 75% of my worry? That's not a cut & past, is my worry, what do you think about:

> ... Kelsey Hightower ... 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.

Re: CoreOS is building a container runtime, Rocket

#190
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…

Hey Solomon; honest question - skipping the tête-à-tête for a moment, the first tenant you outline:

> 1) interface to the app and developer should be standardized, and enforced ruthlessly to prevent fragmentation

Is one I've been pondering and asking myself about a bit - what does this mean?

Is the interface the API? The docker CLI? Interfaces to libcontainer?

Where does the line "enforced ruthlessly" fall exactly?

Does this mean wrapping the CLI or API in another convenience layer is a no-no if it doesn't expose the docker API directly?

I think the rest of the 13 make perfect sense, and I actually don't think the CoreOS guys we're going against any of those in practice or philosophy; more they wanted something small that did one thing very well.

Anyway, I love you guys and the coreos guys, so I'm only in it for the swag.

Post reply on HN