He posted his not very impressive apology as images not text that is easily indexed. I do think that was purposeful and manipulative and very much makes me question his motivation. If I'm missing the original posting in text I'd sure like to know so I can correct this perception.
That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.
I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).
Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.
Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?
I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield).
An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to be more "agent compatible".
Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.
You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.
But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.
That's easily solved by wrapping it in a skill. And every time it fails, once you are done you ask it to update the skill with what it learned. A couple iterations later and it will be solid.
Could you expand on this some more? I'm not quite following.
I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do.
But I don't fully understand the Streamable HTTP point.
I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes.
People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.
CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.
That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.
I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.
Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now.
I'm good, yet my coworkers keep having problems using the Atlassian MCP.
"Stop asking me to apply the plan. I will tell you when I'm ready."
That alone drives me batty. I can easily spend a couple hours and multiple revisions iterating on a plan. Asking me me every single time if I want to apply it is obnoxious.
I tried to use podman desktop for a bit but I ran into some screwy compatibility issues. It just wasn't as smooth as docker.
I really really want an alternative to docker desktop. I don't like the path they're going down. I don't like the AI crap in the UI. The licensing is crazy. It just doesn't feel right.
So I've been lately using rancher by SuSE. Surprisingly, it's been all right. So far it just works. I'm using this on Mac OS.
If anybody's looking for an alternative that's one worth considering.
I'm still confused by why anyone wants to use either Docker or Podman desktops. The the docker/Podman CLIs seem like a much better way to interact with containers/images. Maybe it's just my usecase.
I can't speak to docker, but the Podman desktop UI on MacOS doesn't really offer any functionality that the CLI doesn't. It's more like a status dashboard than anything else. I personally never look at it. I don't see how you can get very far managing containers, images, etc using _just_ the UI in any case.
Agreed. To be honest I feel the same way about k8s. A bunch of people on my team get grumpy if we don't have k9s available or some other interface, but I prefer to just use kubectl
I personally use Docker Desktop because it was the easiest way to install Docker on my Mac. I launch Docker Desktop, close the window but keep the app running in the background, then use the docker tool on the command line :)
OrbStack is a very compelling alternative on macOS. The GUI launches instantly due to being a Swift app and not Electron. Container filesystems are visible in Finder. You can spin up full-blown VMs with it (only Linux ones though). Storage is managed dynamically, so you don't have to reserve or resize the virtual disk. Free for personal use, with zero nags or upsells.
Does anyone know if the company is still active. Haven't seen any updates for a while now. I like the product a lot, but products like this need security updates at the very least.
Last release was November 2025 which isn't that terribly long ago. https://docs.orbstack.dev/release-notes. They do look to have stopped blogging on orbstack.dev for more than a year now. They have a discord channel, but I'm not up for dealing with discord to check on it.
I use good old `docker compose`. It's 100% compatible, since it uses the same moby engine underneath. I've also run k3d on it, so I'm pretty sure it'll handle anything you throw at it.
What sort of compatibility issues were you encountering? (disclaimer: I'm on the Podman Desktop team)
If it was compose + docker compatibility issues, that's on the roadmap for improvement :). Compose support is flakey at times (it's essentially a wrapper around the open source binary https://github.com/docker/compose)
The most common one I run into is with volumes, when the full path doesn't already exist. Docker will just make the path, Podman throws an error. It's been called a "bug" in docker but the fact is everyone just expects the paths to be created. I want it to just work, not make everyone in the industry redo their dockerfiles to be "correct."
It looks like there was some work done to resolve this in 2023 and 2024 but I know this was still happening for me in mid 2025. Podman is technically correct here but functionally broken in a way that keeps pushing me away because I don't have time to deal with that :(
Also, there’s Podman’s decision to drop CNI support. Sure, I get that they want to support the full stack, but netavark is really not especially capable, and CNI allows all kinds of interesting (and frequently overcomplicated) things.
I had issues with performance/power management, and had to abandon Podman Desktop on Windows. Have not checked out recently, but my issues may possibly be solved by
Basically I had a 5 second periodic CPU spike after some update. Also I had some compose issues, and some issue with Fedora based WSL. These together were blockers for me at that point, but I'm using podman on my pet Fedora server, and it works (using quadlets there) perfectly there, and will retry it on Windows also when I get the time.
If you're open to questions, I'm switching my teams from Docker to Podman on macOS. I'm hitting blockers for multi-user setups i.e. each developer has a non-admin account on the machine, whereas brew runs in its own account with admin permissions.
I would love a way to have Podman installable in userspace meaning in a non-admin account, or installable without brew, or with a dependency list such as QEMU or whatever else needs to be installed by an admin ahead of time, or with a sudousers config list, etc.
I know this is an atypical setup. Any advice from anyone here is much appreciated about multi-user non-admin macOS container setup for Podman or Docker or equivalent.
It's been a couple months so I don't remember the details. I am however a heavy compose user to this so promising. I don't any ill will towards the project, just waiting for it to fit my needs.
I put off podman for a while because of claims of compatibility issues, which is unfortunate because I've had an excellent experience since switching over. Can you point as specific issues you've had (not doubting, just curious)?
I also have heard a lot of recommendations for OrbStack, but I haven't had problems with speed either. And I could never stomach using a proprietary system for such a core part of my workflow.
For context I use containers for practically everything and I run some decently complex workflows on them: fullstack node codebases, networking, persistent volumes, mounting, watch mode, etc. Red Hat knocked it out of the park with podman!
I've had a ton of issues trying to use Podman instead of Docker on Fedora. SELinux keeps blocking Podman from doing stuff it needs to, while Docker just works.
I've also experienced Podman "getting stuck" sometimes: it's just running a build, but ctrl+c somehow doesn't stop the build system and instead freezes Podman. Doesn't really happen with Docker.
Docker Engine (the "CLI") only works on Linux. "Desktop" is supposed to offer a unified experience across platforms, it offers a GUI, ships Docker Engine inside a virtual machine so that it works on Windows and MacOS, and tries to make the VM as transparent/invisible as possible (with varying success) with filesystem mounts and network configuration.
Because several developers that work with docker also deploy to Kubernetes. So docker-desktop is a one-click method to get both on your workstation and deploy locally.
Another alternative (although Mac OS-only) is [0] OrbStack. Some devs in my team are running it as a more performant alternative to Docker Desktop for Mac and they are very happy so far.
The term for China's manufacturing advantage is agglomeration. The US is never going to be successful with these manufacturing initiatives until the US government gets its act together and starts rebuilding all the infrastructure that has been destroyed over the last 50 years. That requires more than just tariffs. It requires actual investment. Investment in infrastructure, people education, power, everything. It's actually why silicon valley is so successful because it is an agglomeration of the tech industry. We need the same for manufacturing if we ever expect to do it again.
Some of us will do this, and it will be great for us for a period of time. That is, until others build another giant ball of shit 10,000x bigger than the npm/nodejs/javascript/java/cobol/c++/whatever else garbage pile we have today.
Hmm. I think you misread my comment. I never said anything about businesses caring about quality. I meant strong engineers will care about quality but we'll eventually be drowned out by those (individuals and businesses) who don't. Actually think we agree on this.
It's nonsensical rage/click baiting garbage. You are the product, not the user.
Anybody who hasn't used FB in a long time almost certainly has 100s if not 1000s of posts from friends and family that they missed. Instead of this garbage it should be "Hey, we haven't seen you in awhile! Here's all the fun and important stuff you missed out on."
That might actually get me to engage with the platform because that would be putting my needs first and foremost. But that's not what FB does and not what FB ever did. Zuck never had our best interests in mind, so why would it put our interests first?
reply