Earlier quoted context omitted.
Kubernetes benefits all parties. AWS can move customers away from GCE using Kubernetes, too. As a customer, you get more freedom and flexibility.
I'm surprised we still haven't seen a K8s solution from AWS yet. Their container engine looks OK, but K8s handles setting up internal LBs and has minikube for local development. The AWS app LB seems far behind. I'm looking forward to them accepting defeat on this one and just natively supporting K8s like Google.
A new upstream project to break up Docker into independent components
311–320 of 321 posts
Re: A new upstream project to break up Docker into independent components
#312Earlier quoted context omitted.
And then there's mongo, gimp and git. I've just always assumed "docker" was in the same vein. Now they have to deal with the even more obvious connotations of "moby". Out of the frying pan and into the fire! Well, at least "docker" isn't transitioning to "scissorer".
What does mongo mean? I just assumed the meaning from skating / surfing.
Re: A new upstream project to break up Docker into independent components
#313Earlier quoted context omitted.
Thanks, this seemed to be quite unusual decision to be made by the Kubernetes dev community, that's why I've asked.
Hi, I'm from sig-node. We just don't have enough time/people to cover all log management in 1.6, this is just a temp workaronud so we can ship CRI in time. Log mgmt, together with some other missing parts will be definitely picked up after CRI fully released.
The ideas of decoupling logs from lifetimes of the the things being logged, desynchronized log-watcher services that ship logs to central off-machine log stores, logging chains, shims for things that talk to syslog over AF_LOCAL or UDP sockets, shims for things that talk to the systemd journal using its idiosyncratic logging protocol, compartmentalized logging services that are protected by the operating system from compromises to the logged services, and persistent log pipes that do not lose log data; have all been designed and implemented.
* http://jdebp.eu./FGA/daemontools-family.html#Logging
* http://jdebp.eu./FGA/do-not-use-logrotate.html
* http://jdebp.eu./Softwares/nosh/guide/logging.html
* http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie
Re: A new upstream project to break up Docker into independent components
#314Earlier quoted context omitted.
Also from that thread: Moby = open source development Docker CE = free product release based on Moby Docker EE = commercial product release based on Docker CE. Nothing is dead; and everything that was open-source remains open-source. In fact we are open-sourcing new things.
So essentially the difference between Chromium and Chrome?
Re: A new upstream project to break up Docker into independent components
#315More information can be found there: https://github.com/moby/moby/pull/32691 > Docker is transitioning all of its open source collaborations to the Moby project going forward. Should I understand that the core team wants to keep the brand "Docker" but use it in a commercial way, while Moby will be the underlying open source code? Is it Docker/Moby = RHEL/Fedora ? or Docker/Moby = Mongodb.com/Mongodb.org?
Terrible timing for Docker to do this. It may not be much of an underlying change, but the simple fact that https://github.com/docker/docker redirects to https://github.com/moby/moby is a product-destroying move, as Docker is now just managing to spread to a wider audience. This move is going to confuse many users, and could entirely derail their growth. What the hell were they thinking, to execute this decision at s…
Re: A new upstream project to break up Docker into independent components
#316Earlier quoted context omitted.
Why would you lead with a legitimate question and then finish with an outright insult?
How can software be insulted? Software doesn't have feelings.
Re: A new upstream project to break up Docker into independent components
#317Earlier quoted context omitted.
How can software be insulted? Software doesn't have feelings.
You're not talking to software. You're talking to human beings about their software. You can criticize Docker's security track record in a more constructive way. There's nothing to be gained by being an asshole.
Re: A new upstream project to break up Docker into independent components
#318Earlier quoted context omitted.
You're not talking to software. You're talking to human beings about their software. You can criticize Docker's security track record in a more constructive way. There's nothing to be gained by being an asshole.
Someone suggests that Docker's reputation for security is terrible (which it is), and your response is to call someone else in the conversation an asshole, and suggest they should be more constructive?
Re: A new upstream project to break up Docker into independent components
#319Earlier quoted context omitted.
Someone suggests that Docker's reputation for security is terrible (which it is), and your response is to call someone else in the conversation an asshole, and suggest they should be more constructive?
Yes, and I called out his post for being assholish (which it is). If we're calling a spade a spade then it goes both ways.
So, do as you say, not as you do, eh?
Also, how on earth is suggesting a piece of software has a terrible security reputation, "assholish".
Re: A new upstream project to break up Docker into independent components
#320Earlier quoted context omitted.
Yes, and I called out his post for being assholish (which it is). If we're calling a spade a spade then it goes both ways.
You're the one claiming we shouldn't call a spade a spade. So, do as you say, not as you do, eh? Also, how on earth is suggesting a piece of software has a terrible security reputation, "assholish".
Exactly.