karlkfi
Joined 13 years ago
Karma
9
Submissions
23
Member since
Jun 5
Recent submissions
Comment · 5 years ago
Comment · 8 years ago
> Connected cars are already on the road, using lidar & radar, not the phone network. Xu points out, “even today we have the technology that can support autonomous driving”.
This point is silly.
Lidar and radar don't replace high bandwidth internet on a self-driving car. The beefy super computer in the trunk is trying to replace the cloud compute processing that is inaccessible because there's not enough low latency, reliable bandwidth available to stream a dozen camera, lidar, radar, and IR feeds over the internet for remote processing.
Self driving right now requires either precision 3D mapping and local processing of a huge amount of data from multiple sources OR highway-only limitations where there are fewer objects to track that all move in predictable ways. Both of these would be easier and produce better results with more bandwidth and lower latency.
5G may not be mature enough to make a difference today, but that doesn't mean connected and self-driving cars aren't a legitimate use case for the technology and its stated goals.
Comment · 9 years ago
Comment · 9 years ago
Comment · 10 years ago
DC/OS (A Mesos distribution) can be used on your laptop with dcos-vagrant or dcos-docker:
- https://github.com/dcos/dcos-vagrant
- https://github.com/dcos/dcos-docker
However, your point is somewhat valid in that Mesos requires you to allocate resources to everything you run, while resource allocation/enforcement is optional in Kubernetes. So you can easily run too many things and freeze your computer with Kubernetes, while Mesos is more conservative.
Comment · 10 years ago
Agreed. Autoscroll breaks the mobile experience horribly. Small text... No pinch to zoom... Half the text is always off the screen in landscape...
Comment · 11 years ago
It's worth noting that Kubernetes can also run on top of Mesos (https://github.com/GoogleCloudPlatform/kubernetes/tree/maste...) and DCOS (https://mesosphere.com/learn/).
So if you invest in Kubernetes and later want to take advantage of Mesos you can lift up k8s and put Mesos underneath.
Mesos is definitely more mature, and you can use Marathon for container orchestration, which is a little more mature than Kubernetes, but it's also a bit simpler. Marathon doesn't have the service, secrets, or pod abstractions, for example.
DCOS adds some additional benefits on top of Mesos, like the dcos-ui and dcos-cli. One of the more compelling features is one-step cluster package installation (ex: dcos package install kubernetes). Currently, the community edition is available on AWS (https://mesosphere.com/amazon/).
I do agree that the kube-up scripts in k8s are a bit of a mess. There's really hard to read and reverse engineer, and each provider has their own divergent deployment methods. That's one of the things DCOS is trying to standardize, to have a consistent deployment pattern for Mesos frameworks that deploys their core components inside Marathon, giving them a more battle-tested platform to live within, and granting automatic resurrection in case of failure.
Comment · 11 years ago
YARN (Myriad), Spark, Kubernetes, Marathon, Swarm, and Aurora already run on Mesos, with varying degrees of maturity.
As you say, the primary benefit is that you can provision a single Mesos cluster and share its resources across various frameworks.
Comment · 11 years ago
IME, it's immature. It's usable, but not awesome, and not as feature-full as Jenkins.
It's one killer feature is pipelines, but the hierarchy is fixed depth and hard to learn. Every other level is exclusively either parallel or sequential. Just like Jenkins & Teamcity, it's best to run every step in a container, but this is something you have to manage yourself.
Another major drawback is that the config is all one giant xml file. The GUI makes it a little easier to use, if you can figure out how to navigte it, but when things get hard you end up editing the global xml by hand with the possibility of accidentally breaking the config for the entire cluster.
The only CI I've seen with native container isolation AND pipelines is http://concourse.ci/ But it's a one man show at this point, even more immature than GoCD.
Travis is poor man's CI. It doesn't scale well, even if you pay for it. And it's not customization enough to use for anything except unit tests and maybe integration tests if they're small and fast.
Never used Hudson.
TeamCity seems about on par with Jenkins.
In fact, if you pin them to something concrete, you lose the ability to adjust the point value to account for less-concrete variability.
They're almost always "pointless" in the beginning, no better than a Super Wild Ass Guess (SWAG). But if you use them relatively consistently over time, have relatively consistent work, and account for team size changes, they can become valuable tools for predicting completion time of complex/complicated tasks/project.