Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

91–100 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#91
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?

I'm still digesting the Go-like syntax for vanity URLs and how that works here. If a fileset manifest lets you specify the URLs where the layers can be fetched from, then I like it.

Does Rocket just 'cp' files on top of each other to implement layering? It'd be nice to not require a bunch of copies of the same files. I thought that the hard link implementation in Docker's new overlayfs support was a smart idea.

Re: CoreOS is building a container runtime, Rocket

#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 frivolous and ill-considered, and nobody would know on what points the fork would be aiming to distinguish itself.

This statement needs to be made, the way it was made, for the same reasons any project announcement is made: it needs to announce that it exists, and why it exists. It's the same as Docker's "debut" blog post(s).

Every schism needs its 95 Theses, and the odds favor the ones who can read them, understand them, and take them into consideration.

---

Disclaimer (re https://twitter.com/kenperkins/status/539528757711622145): I make edits to my comments after posting, usually posting a line or two then fleshing them out over time. If I make a change that conflicts with a statement in an earlier revision, I'll note it: otherwise I'm pretty much just composing live.

Re: CoreOS is building a container runtime, Rocket

#93

Earlier quoted context omitted.

> I have been concerned that Docker's scope was expanding too far for a while now What features were recently introduced that it increased Docker's scope?

Talk of Docker cluster, which might include a network overlay layer a la weave

All of which will be fully pluggable with a "batteries included but removable" design, just like we did with sandboxing and storage.

Re: CoreOS is building a container runtime, Rocket

#94
post #91
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?

I'm still digesting the Go-like syntax for vanity URLs and how that works here. If a fileset manifest lets you specify the URLs where the layers can be fetched from, then I like it. Does Rocket just 'cp' files on top of each other to implement layering? It'd be nice to not require a bunch of copies of the same files. I thought that the hard link implementation in Docker's new overlayfs support was a smart idea.

Yes, all of this was designed with overlayfs in mind. I am waiting anxiously for Linux Kernel 3.18 to land, this is a huge step forward for Linux and years in the making.

Re: CoreOS is building a container runtime, Rocket

#95
post #22
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.

Fragments? Certainly. Dies? Linux has been fragmented from its inception. If you include the world's Android phones, Linux probably runs on more computers than any other kernel or OS. Rocket will not kill Linux, containers, or docker. In the worst case, it will kill CoreOS, and even that's unlikely.

Likely not even close. Just about every single washing machine, refrigerator, microwave, digital stove, etc, runs a variant of an open source operating system called Tron, or the more common ITron variant.

http://en.wikipedia.org/wiki/TRON_project

Tron has been around since the mid 80s I believe and Linux was first released in the early 90s.

Re: CoreOS is building a container runtime, Rocket

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

[deleted]

Re: CoreOS is building a container runtime, Rocket

#97
post #93

Earlier quoted context omitted.

Talk of Docker cluster, which might include a network overlay layer a la weave

All of which will be fully pluggable with a "batteries included but removable" design, just like we did with sandboxing and storage.

You may need to make that clearer to some of the people that are due to be building your plugins: reading http://weaveblog.com/2014/11/13/life-and-docker-networking/, I get the feeling that they're not thrilled about it.

Re: CoreOS is building a container runtime, Rocket

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

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 lot)

2. On Twitter you suggested things should be 'composable to the extreme' ..... using plugins and drivers. https://www.youtube.com/watch?v=G2y8Sx4B2Sk

Re: CoreOS is building a container runtime, Rocket

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

[deleted]
Post reply on HN