Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoreOS is building a container runtime, Rocket

coreos.com

Post reply on HN
Print view View original

241–250 of 295 posts

Re: CoreOS is building a container runtime, Rocket

#241

Post by stephenr »

23david wrote: post #179
shykes wrote: 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…

Ops (particularly in Enterprise) doesn't want batteries included by default. Principle #3 and #5 are incompatible IMO. Do one thing and do it well... Seems to me that post-Docker 1.2, the Docker team has taken Ops concerns much less seriously and is focused almost exclusively on iterating Dev-friendly features. Hope things change.

This is all too common in my opinion.

It feels to me like a lot of startups, and even smaller tech companies focus completely on developers. I seriously think some people think "DevOps" literally means Developers doing what Operations/Infrastructure people/teams do (or should do).

Re: CoreOS is building a container runtime, Rocket

#242

Post by nor0101 »

ash wrote: post #197
ecnahc515 wrote: post #183

Earlier quoted context omitted.

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

JSON is okay, but I hope TOML will gain traction soon. Because comments. And trailing commas. Rust Crate is already using TOML for package metadata. https://github.com/toml-lang/toml http://doc.crates.io/manifest.html

+1 for TOML, started playing with Rust a couple of weeks ago.

Re: CoreOS is building a container runtime, Rocket

#243

Post by darren0 »

cbsmith wrote: post #229
darren0 wrote: post #219

Earlier quoted context omitted.

The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.

You may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.

And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.

Re: CoreOS is building a container runtime, Rocket

#244

Post by cbsmith »

darren0 wrote: post #243
cbsmith wrote: post #229

Earlier quoted context omitted.

You may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.

And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because…

With capabilities there is no need to have privileges beyond port binding and (possibly) userid assignment, no?

Re: CoreOS is building a container runtime, Rocket

#245

Post by jsprogrammer »

mbreese wrote: post #188
shykes wrote: post #172

Earlier quoted context omitted.

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…

This is a pretty cynical point of view.

Why can't we all work something out here?

Re: CoreOS is building a container runtime, Rocket

#246

Post by 72deluxe »

losnggenration wrote: post #192
pquerna wrote: post #111

Earlier quoted context omitted.

personally, I think the long term value of Rocket is not about Rocket -- its about the ACI specification for the formats of containers. Right now I'm already taking a Dockerfile, exporting it to a tar, and then running systemd-nspawn -- I love Dockerfiles, I love being able to grab a postgres server and get it up quickly from Docker Hub, but I didn't need or want the rest of docker. If both Docker and Rocket support…

I think it's called OVF[1]. It's just not as widely supported as it probably should be. [1] - http://en.wikipedia.org/wiki/Open_Virtualization_Format

Yes, it is always massively disappointing with every release of Parallels Desktop for Mac that OVFs and OVAs are not supported; they blindly continue to support just their own disk format whilst pushing their "enterprise" solution - surely OVF and OVA deployments are essential in that environment???

Sigh!

This'll be the last version of Parallels that I buy (thanks Yosemite)

Re: CoreOS is building a container runtime, Rocket

#247

Post by hobofan »

frostmatthew wrote: post #220
mikerichards wrote: post #216

Earlier quoted context omitted.

Despite the attempt of some to move goal posts, you're still guaranteed that you won't be locked in by Oracle even tomorrow. You still have the source code for the version you're running right?

Sure...as long as I don't care about security patches, bug fixes, performance improvements, or new features.

If people think the software moves in the wrong direction it will be forked (see MariaDB). Nothing world changing will happen.

Docker Inc. seems to make a lot of effort to ensure Docker is a truely open project. I get the feeling that people think that handing your project to Apache is the only way to prevent vendor lock in these days.

Re: CoreOS is building a container runtime, Rocket

#248

Post by 72deluxe »

peterwwillis wrote: post #187
nsmartt wrote: post #123

Earlier quoted context omitted.

> 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 com…

It always makes me chuckle that Firefox adds more and more features and becomes more and more like the suite they replaced; I still miss the Composer for web pages!

I remember using it when it was called Firebird.

Re: CoreOS is building a container runtime, Rocket

#250

Post by perlpimp »

Great now people who were suppose to be living and working together are going to be at odds with one another casualty being the end user. Also windows is taking this platforming thing under their consideration too. Given their reach and funding I think it would be smart to band together so it would not turn out like it did in July 1993
Post reply on HN