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

App Container and Docker

coreos.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: App Container and Docker

#21

Post by Goopplesoft »

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743...

Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker fork/binary instead of a public scene to try to force dockers hand. Lots of fragmentation to come, which sucks because the ecosystem is so important.

Re: App Container and Docker

#22

Post by akanet »

Goopplesoft wrote: post #21

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743... Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker…

Yeah, I think my biggest turn off from Rocket is just how PR-oriented all their moves seem to be. I'd be cooler with what they were doing if they appeared to be more open with their motives, but they couch so much of the self-interested stuff they do in terms of benefitting me and "openness". Trips my BS alarm, even if it's legit.

Re: App Container and Docker

#23

Post by [deleted] »

Goopplesoft wrote: post #21

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743... Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker…

[deleted]

Re: App Container and Docker

#24

Post by panarky »

Goopplesoft wrote: post #21

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743... Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker…

Shykes > Can someone explain to me how the user benefits from this?

As a user, it would be fantastic to run my App Container images on Docker hosts, and Docker images on Rocket hosts.

If only I could move my virtual machine images this easily and avoid high switching costs between platforms.

Shykes > just do it in your own project and let the best project win ... you have to choose one or the other

Bullshit. If it's open, let the best idea win. If this is a bad idea, then let the community examine it and it will lose on the merits.

Don't force me into a false dichotomy.

Re: App Container and Docker

#25

Post by conradk »

xnxn wrote: post #20
shykes wrote: post #16

Earlier quoted context omitted.

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace and simple hosting on object stores. If you "would like to see convergence", why didn't you join the effort to implement this along with the rest of the Docker community? The design discussion has been going on for a long time, the oldest trace I can find is a…

I've got a use case. ACI support would let me use containers without being coupled to Docker's registry. I really don't want to run that software, and I really, really don't want to rely on Docker Hub. ACI's use of existing standards for their "registry" implementation is a major draw for me.

Actually, I think you don't have to rely on Docker's registry:

- you can simply use Dockerfiles and build your own images,

- apparently, it seems like you can host your own registry [1]

- you can even use a service run by CoreOS, ie Quay, to host your Docker images [2]

I'm not sure I understand what you mean by "I really don't want to run that software". Does it mean you don't want to use Docker ?

[1] https://blog.docker.com/2013/07/how-to-use-your-own-registry...

[2] https://quay.io/

Re: App Container and Docker

#26

Post by panarky »

shykes wrote: post #16
philips wrote: post #14

Earlier quoted context omitted.

This initial discussion is just about the container image format and we would really like to see convergence on that front. As container runtimes Rocket and Docker have different design goals though. As one example, Rocket is designed to be a standalone tool that can run without a daemon and works with existing init systems like upstart, systemd and sysv. We needed this standalone property because on CoreOS container…

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace and simple hosting on object stores. If you "would like to see convergence", why didn't you join the effort to implement this along with the rest of the Docker community? The design discussion has been going on for a long time, the oldest trace I can find is a…

> How will it benefit Docker users to have to memorize a new command-line option

User here. I couldn't care less about a new command-line option, but it would be worth a lot if I could run any image on any platform.

If you claim this is "all about the user" then talk more about what the user gains or loses.

Is the biggest downside really just another command-line option? Docker already has a metric fuckton[1] of command-line options, what's one more?

Impugning the motives of your competitor is at best an irrelevant distraction, and at worst an indictment of your own motives.

[1] https://docs.docker.com/reference/commandline/cli/

Re: App Container and Docker

#27

Post by philips »

shykes wrote: post #16
philips wrote: post #14

Earlier quoted context omitted.

This initial discussion is just about the container image format and we would really like to see convergence on that front. As container runtimes Rocket and Docker have different design goals though. As one example, Rocket is designed to be a standalone tool that can run without a daemon and works with existing init systems like upstart, systemd and sysv. We needed this standalone property because on CoreOS container…

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace and simple hosting on object stores. If you "would like to see convergence", why didn't you join the effort to implement this along with the rest of the Docker community? The design discussion has been going on for a long time, the oldest trace I can find is a…

shykes, I will follow up to all of this on the proposal on GitHub.

Re: App Container and Docker

#28

Post by [deleted] »

Goopplesoft wrote: post #21

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743... Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker…

[deleted]

Re: App Container and Docker

#29

Post by nstott »

This is useful for us.

We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers.

Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.

Re: App Container and Docker

#30

Post by xnxn »

conradk wrote: post #25
xnxn wrote: post #20

Earlier quoted context omitted.

I've got a use case. ACI support would let me use containers without being coupled to Docker's registry. I really don't want to run that software, and I really, really don't want to rely on Docker Hub. ACI's use of existing standards for their "registry" implementation is a major draw for me.

Actually, I think you don't have to rely on Docker's registry: - you can simply use Dockerfiles and build your own images, - apparently, it seems like you can host your own registry [1] - you can even use a service run by CoreOS, ie Quay, to host your Docker images [2] I'm not sure I understand what you mean by "I really don't want to run that software". Does it mean you don't want to use Docker ? [1] https://blog.do…

To clarify, I don't want to run my own registry and I don't want to rely on any third party for image hosting. I just want to pull tarballs from a dumb file server. No need to run a registry for that, and no one company has a privileged position in the namespace.

It's maddening, because I love Docker-the-concept but not Docker-the-implementation nor Docker-the-ecosystem. I honestly do understand how many would find the UX of "Docker, Inc. at the center of things" to be a refreshing convenience, but to me that notion is frustrating and repellent, as much so as if Git remotes defaulted to GitHub.

Post reply on HN