Wow, I did not expect anyone to be offering a SIX HUNDRED THOUSAND mile warranty on their batteries. That's some serious confidence. I didn't see anything about it transferring, though. That would be smart on their end - the resale value for electric sports cars at least, is about 50% in the first year, then it levels off hard after that. This would encourage buying new, but not aftermarket. I'll have to look into this.

Still, while this removes a primary concern of mine, there's still one major hurdle that cannot be bypassed as far as I can tell (yet): If you have shared parking, there's essentially no way to charge your car. Maybe if it's an outdoor parking lot you can rely on solar power somewhat, assuming you're in a good situation for that?

Still, my point is that my parking space isn't actually mine, so I can't modify anything in the garage. Assuming superconductors aren't figured out any time soon, this appears to be an impossible solve, which cuts their consumer market significantly.

Also, not exactly the same thing, but they could remove those warranties and instead get some nice replaceable battery cells in there. Let me turn a thing to unlock it, pull out that one cell, and replace it. But maybe I'm a little more wrench-y than their customers want to be?

I agree MCP has these flaws, idk why we need MCP servers when LLMs can just connect to the existing API endpoint

Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut...

even connects to MCP servers

if you take a look, would love your thoughts

How is this different than just giving the LLM an OpenAI spec in the prompt? Does it somehow get around the huge amount of input tokens that would require?

I have a silly theory that I only half joke about that docker/containers wouldn't've ever taken off as fast as it did if it didn't solve the horrible python dependency hell so well. You know something is bad when fancy chrooting is the only ergonomic way of shipping something that works.

My first taste of Python was as a sysadmin, back in 2012 or so, installing a service written in Python on a server. The dependency hell, the stupid venv commands, all this absolute pain just to get a goddamn webserver running, good lord. It turned me off of Python for over a decade. Almost any time I saw it I just turned and walked away, not interested, no thanks. The times I didn't, I walked right back into that pile of bullshit and remembered why I normally avoided it. The way `brew` handles it on macOS is also immensely frustrating, breaking basic pip install commands, installing libraries as commands but in ways that make them not available to other python scripts, what a goddamn disaster.

And no, I really have no clue what I'm talking about, because as someone starting out this has been so utterly stupid and bewildering that I just move on to more productive, pleasant work with a mental note of "maybe when Python gets their shit together I'll revisit it".

However, uv has, at least for my beginner and cynical eyes, swept away most of the bullshit for me. At least superficially, in the little toy projects I am starting to do in Python (precisely because its such a nicer experience), it sweeps away most of the horrid bullshit. `uv init`, `uv add`, `uv run`. And it just works*.

When did Python go out of fashion? This is the second article I've seen talking about it as if it's some kind abomination.

I get that it's not the shiny new thing, but I don't understand people hating on it. Is this just junior devs who never learned it, or is there some new language out that I missed? (And please don't tell me Javascript....)

I don't trust an open source solution by a major player unless it's published with other major players. Otherwise, the perverse incentives are too great.