sysexit

The technology behind this is really cool. It's based on a DAG instead of a blockchain, which should make this a lot more scalable (no block size limits to deal with) and efficient (no miners, no electricity wasted on PoW).

I believe this is exactly what's needed..

I called it here, right at the initial announcement:

https://news.ycombinator.com/item?id=11816951

This is just too hard of a problem to solve frivolously. Kudos to CoreOS for trying, and coming to the inevitable conclusion sooner rather than later.

My day job is not related to containers, but yes, working in the industry has of course biased me (but my opinions are still my own).

So 4B for a selling stickers business model?

> Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms.

That's quite inaccurate. It's is like saying that OpenStack started out as an extension to KVM. Both had very different (original) scopes.

> Whether the Kubernetes community continues to build primarily on Docker, or switches to containerd

Kubernetes has 3 container runtimes at the moment: Docker, Rocket, and the new remote runtime which allows you to plug in a separate server using a protobuf interface. There is a lot of focus on the remote runtime now. The CRI-O project for example is implementing a remote runtime that allows any OCI conformant runtime to be plugged into Kubernetes.

> What is the motivation and benefit for running containers without docker?

I believe that Docker bet the company on the wrong business model. Therefore knowing that you can run containers without Docker can be desirable, as it gives you options in case Docker turns out to be not viable.

Docker made it easy to build and run containers from the command line. This technology was released at the right time and in the right place. And it got huge traction. Docker used this traction to get a very large amount of VC capital. Therefore they now need to show a very large return.

How do you go about achieving that large return? A common way to do this is to use one piece of technology that is popular as an anchor to lock customers into an entire stack. And then you monetize the stack, which is easier as it has higher value. The technology in this case is the container runtime, and the stack would be an full enterprise grade container orchestration system.

This strategy worked for others. Microsoft was a master in this. VMware as well, and so is Oracle. The reason I believe it will not work for Docker is:

1. The anchor technology is open source. Microsoft managed their lock-in via Windows, VMware via ESX, Oracle via their DB. It worked because those are proprietary. In the open source world you can just take Docker.

2. Even though the technology is open source, you can still try the ecosystem approach where you exploit certain network effects attached to your distribution of the code that protect you (e.g. vendor certifications). This is what worked for Red Hat. In my view it is unlikely to work for Docker. I don't think certifications are required as most container apps today are not vendor apps. And I would not know what else they could use.

3. For orchestration solution they are engineering against Google's Kubernetes. With all respect for Docker, this is going to be very hard as Google has a huge amount of experience in this area.

4. Due to Docker's need to protect their business model, there is no true community in the sense that there is an open exchange of ideas. The docker agenda prevails over technical decision making (like: should you have a docker daemon? Should Swarm be part of the Docker Engine?). Contrast that with Kubernetes which run in a very open manner by Google. This is why OpenStack got the traction, and why Eucalyptus and CloudStack died off. OpenStack had the most open community.

All of this can lead, IMHO, to a situation where Docker will not succeed in delivering Swarm as they see it. Kubernetes will become the default container orchestration system, and Docker is relegated to a small place in the stack. This situation would make it hard for Docker to justify their valuation.

> Does every mention of an Open Source library or project morally require attribution to the original authors or something?

No. But in my view had this been written by an independent journalist, they would describe it as "TensorFlow by Google". The project is virtually completely driven by Google, so "By Google" is a more distinguishing classification than "Open Source". We can speculate but strong impression is that Amazon doesn't want to give kudus to Google.

Pretty classless how Jeff describes TensorFlow as an "Open Source library," without atributing it to Google.

> Also, the fact that it's a hard problem is what makes it a compelling product offering. You can't make much money solving easy problems.

If they can solve the hard problem, yes. Which I believe is unlikely.

I love CoreOS and they've done some super impressive engineering. But really, a new storage system? Rewriting in Go and using etcd for central state management makes things easier, but this is still a hard problem.

Some things that need to be solved sooner or later: data replication so that N faults of X entities are protected against (X can be disks, enclosures, racks, data centers, regions, ..), recovery from failed disks, scrubbing, data management, backups, some kind of storage orchestration and centralized management.

If you look at Ceph which IMHO represents the state of the art in software defined storage, it took many years to get it to a point that it was usable. I hate to be cynical but in this case I would be surprised if CoreOS can pull this of. I wish them all the best though and would be happy for them if I am wrong.

Cheap shot by a company doing backup/DR.

Zerto, you have great technology, but chasing ambulances is a poor marketing strategy.

Docker on Docker is way cool.

The use case we're trying to solve here is a tad different though: it's to provide virtual infrastructure for the "first level" i.e. in the case of Docker the outer container host. For Docker the answer could be EC2, since Docker itself doesn't need VT. However that precludes you from using KVM in any layer below, which in turn means Linux only and fairly simple networking (no multicasting even in VPC, and hence no VXLAN for example)

We very much wanted to create something to assist OpenStack developers in developing OpenStack itself. It should be especially useful for projects such as Nova, Neutron and Ironic.

Well, from a customer point of view it's just a regular hypervisor / guest setup.

The levels below are required to make an IaaS cloud look more like the datacenter. The underlying assumption is that the bigger flexibility you have in datacenter deployments is beneficial, especially when we talk about any application not specifically designed for the cloud.

I guess you're being sarcastic.

What you describe is accurate. In fact, there's one level more because the Linux instance you run is already running as a nested guest. So in your scenario there's 3 hypervisors involved (Amazon Xen, Ravello HVX, KVM) and then your Docker host.

More seriously, I am very bullish on Docker myself. But I see it as a supplement rather than a replacement for virtualization.

Fortunately Rust has unsafe { ... }

A release that seems somewhat rushed, and a Red Hat media event tomorrow. I wonder if the two are related.

Agreed with some of the other posters that this isn't a bug. It would be pretty hard for a browser to make this not work. To make it not work, the browser would have to check whether there's data available in the local socket buffer before issuing an HTTP request. On Unix, you could e.g. put the socket in non-blocking mode, issue a read() to read 1 byte, and then see if you're getting an EWOULDBLOCK. If you get data instead of EWOULDBLOCK, then (supposedly) you're in violation of the RFC and therefore the browser might decide to close the connection (what should it do otherwise?)

It just doesn't make a lot of sense doing the above. Especially because there's a fundamental race condition here: there is no way to distinguish between data that's in-flight but not received prior to the browser issuing the request, and data that was generated after the remote peer read the browser's request.