IIRC you could always overcommit in Mesos using DRF weights and accepting resource offers in your application. I could be wrong.
The larger point is that Mesos introduced a new, exciting way to do truly distributed allocation (where the cluster manager (i.e., Mesos) and various applications coordinated and cooperated in how they use computing resources). In contrast, Kubernetes is centralized, pretty vanilla, and I would love to know what new ideas it has introduced (from an algorithmic and architecture perspective).
Mesos made a ton of new contributions to distributed resource management. Resource offers and application integration can allow high cluster utilization and efficiency. Giving applications the opportunity to take part in resource allocation and scheduling was similar to the Exokernel design, and led to many interesting middleware architectures.
Mesos also introduced Dominant Resource Fairness for allocating resources to competing applications, which has become an important concept in CS and specifically computational economics in its own right.
Mesos achieved the rare combination of using CS research towards a widely deployed operational system. Its C++ code is simple enough to understand and hack, and seemed like one of those projects that you can/want to reimplement on your own "in a few days".
In almost all cases, the support of these giant corporations is towards feature-sets that are inherently self-serving. In many cases, they wield too much power and hijack the direction of the opensource projects. For example, there's plenty of optimizations for server-side CPU performance on Linux, often to the detriment of desktop interactive performance (see Con Kolivas' scheduler and his 10+ year long struggle).
You can apply this logic for any wasteful activity. Lets boil the ocean with coal-fired plants, because something something production vs. consumption.
Sorry, why is this downvoted? There is a serious argument to be had about the source of income for surveillance and tracking driven websites. If the oft-used line of "users being products" is true, then where's our profit?
I have always wondered what common usecases such systems address. How large are the graphs typically? Are graphs really that big that they dont fit in a single machine?
OK I had missed the kata containers blurb in the FAQ, thanks for pointing it out. In fact the tweets make my point: we are all so blinded by new shiny releases that we forget their highly incremental nature.
Clear containers (now called kata containers) did this more than three years ago, with similar performance numbers (sub 200 ms boot times). It is frustrating, but not surprising, to see the same regurgitated solution receive this much excitement. The firecracker documentation also does not mention the similarity with prior work, oh well.
[Not affiliated with Intel in any way---just a long-time proponent of the clear containers approach.]
MPTCP's bandwdith aggregation properties are cool---you can effectively use all your network interfaces for (MP)TCP connections.
Has anyone deployed it in data-center/cloud environments? I know that both Apple and Android support it for the mobile devices to use WiFi and LTE at the same time.
I've always wanted to switch from python's matplotlib to ggplot, but never found sufficient advantages to make the switch. Especially considering that I use python for doing data analysis, and pandas+ipython-notebook can be tightly integrated with matplotlib.
Plus I've found it easier to create compact figures necessary for academic publishing with matplotlib. ggplot's defaults create graphs that take up too much space!