Not to mention language communities with constant supply chain attacks because its standard library story is poor, and everyone keeps reinventing new, often half-baked solutions?

Or even that, the very same ecosystem congratulates themselves on the typing system but still relies on linters because the language and runtime themselves allow whole categories of dumb ideas to be written?

In my twenties, I came across an idea from one of Ken Wilbur’s books that helped settle a conundrum for me. What happens when one wants to honor all life? Are they all equal?

He made a distinction between intrinsic value and extrinsic value. Plankton is not as complex of a lifeform as whales, yet whales cannot live without plankton. One has more intrinsic value and the other has more extrinsic value. There is an interrelationship that does not have to flatten value for everything and everyone.

LLMs are trained from the language corpus of our collective consciousness. It reflects our collective, all the wonderful, beautiful, and horrific things we can dream of and put into words.

What people are finding now when building agenic AI orchestrators is that they are reinventing some of the ideas behind BEAM and OTP. The big one being queues (mailboxes), but also fault isolation.

Async runtimes can’t really do preemptive scheduling so those end up using other methods that, while getting low latency, may not improve reliability or reduce variance in latency.

Orchestrating tasks across a number of different services that are not in your control becomes a distributed system where not everything is reliable.

How are resource management distinct from scheduling in Mesos?

Mesos handles resource reservation like a broker. Frameworks like Marathon or applications like Apache Spark make requests to Mesos for resources and then ask Nesos to launch specific processes on those resources. You can have multiple frameworks on a given Mesos cluster.

Is it fair to say that Mesos is more top-down while Kubernetes is more bottom-up in scheduling approach?

I think people are putting together pi clusters for their homelab these days.

Not all clusters are elastic. Cloud infrastructure can be, but HPC setups before the cloud were not.

Even in a physical hardware, on-premise scenario, it's still easier to scale horizontally than vertically in almost all cases, for all the reasons I mentioned. That's a big reason why Kubernetes was adopted at an unprecedented pace at medium to large organizations - because it helps manage that approach.

They could have chosen Mesos instead. Kubernetes had other characteristics that allowed it to be adopted far and wide besides the ability to scale horizontally.

I said a big reason, not the only reason.

Besides, Mesos wasn't a good alternative for most companies, so saying "they could have chosen it instead" is a bit theoretical. Mesos was ambitious, but that made it less suitable for a plug & play system that fit easily into existing corporate systems, which had already adopted containers heavily.[] Another reason for Kubernetes' popularity is it didn't try to be a big leap forward the way Mesos did.

[]The Marathon container support for Mesos was released about a year after Kubernetes, but if you were going to set up a system for distributed orchestration of containers, it didn't make much sense to bring Mesos along for the ride. There's a reason Mesos is in Apache heaven now (the Attic.)

That is not very insightful. Your thesis started with the idea of elastic horizontal scaling.

Mesos was designed from ideas with HPC and catered to that. Large hardware capex, which is not elastic. Containers did not make sense in that world when it was architected, and it was retrofited into Mesos's architectural foundation.

Kubernetes was designed for a wide variety of workloads, and designed to be composable, versatile, and extensible. It has a far more decentralized approach, an antithesis to Mesos's Data Center as an OS approach. It isn't that Kubernetes did not try to do too much. It's that they laid a much more flexible foundation.

It turns out, Kubernetes was a better fit for a many more use-cases, even beyond large and medium sized enterprises. Kubernetes works pretty well at the edge and locally as well, and it runs many ML workloads on the other end of scale.

This is not theoretical.

Your version of the story is fine, but the point remains, Mesos was not a good fit for most medium to large organizations at the time they began adopting Kubernetes. As such, those organizations rationally did not "choose Mesos instead."

that's..kind of not true. they weren't elastic in the sense that you never had to think about how big they were. but you had say 64k nodes, and people would launch jobs with 1000 of them, or 10000, or if if they could clear the decks all of them. or if they were just debugging, maybe 5 of them.

so I guess idk what you mean by 'elastic' here.

Scale isn’t the only reason. Sometimes you want resource isolation and self-healing, something that is useful if you want a personal swarm of AI agents.

I get how running in a container or vm would help with that, but why would you want to cluster multiple of them? Are you isolating the agents from one another?

I am not sure I understand this argument. Kubernetes typically runs on Linux. I use an Apple laptop, work mostly with headless Linux VMs and Kubernetes. What is a “poor man’s Linux”?

Does your apple laptop run Linux or MacOS? Do you run Kubernetes locally or only when network permits? What was the reason for targeting Linux rather than MacOS? And what in this context is the value add of using Kubernetes for your development?

I build production Kubernetes and cloud infra for work. When I run Kubernetes locally, it is because I am developing operators or manifests for application workloads. Kubernetes is not the “value add” for my dev workflow, it is literally what I am developing.

I have run Linux laptops before. After running it for five years, I came to the conclusion that it did not make a good laptop for my use-case. Poor suspend-resume support, poor wireless networking support means I can not just pick and go. (And no one has yet to replicate Apple’s trackpad experience). So yes, I run Apple laptop with MacOS and use my TUI tools, sometimes with Linux running in an VM, sometime remotely to a full headless VM with my full dev suite via mosh because I use cli and TUI for dev.

Your turn. You still have not defined “poor man’s Linux”.

A local model that can do better than Siri or Alexa as a personal or home assistant is, in my eyes, very useful. Being able to run on a phone or watch or glasses translates to me, low-powered AI, and not necessarily that I want my phone, or watch, or glasses to run things for me.

My Siri use has narrowed down to just setting timers. And even then, I still have my phone call people in the middle of the night. Siri is pretty dumb and does not do what I want it. I’d rather be able to customize an assistant to myself.

I am also thinking of automation in my day to day workflow for work.

OK.. but what would you have all this "automation" actually do? What is Siri failing to do that you want it to do? How would customizing an assistant (for whatever definition) help?