> Alpro costs like 2.80€/L while common dairy milk is less than a euro per liter

Sure if we are cherry picking the "premium" brand this comparison works. Store brand soy or oat milk are 0,95€[0] and 0,90€[1] per liter respectively, so about what cow milk costs. For milk and milk alternatives there hasn't been a financial differentiator between them for about 5 years now.

With meat replacement patties there is still a significant price difference, though there Beyond Meat is also one of the more expensive ones (which is bold, as they've also been lapped by the competition in taste and variety of products).

[0]: https://www.rewe.de/shop/p/rewe-bio-vegan-soja-drink-1l/5852... - Links may not work depending on what postcode you enter. Should work with 10115

[1]: https://www.rewe.de/shop/p/rewe-bio-vegan-hafer-drink-ohne-z...

Sorry, but what are you talking about? This is a 120B-A6B model, which isn't runnable on any laptop except the most beefed up Macbooks, and then will certainly drain its battery and cook your legs.

You can easily run a quant of this on a DGX Spark though. Seems like a small investment if it meaningful improves Lean productivity.

Is it though?

Most people I know that use agents for building software and tried to switch to local development, every single time they switch back to Claude/codex.

It's just not worth it. The models are that much better and continue to get released / improve.

And it's much cheaper unless you're doing like 24/7 stuff.

Even on the $200/m plan, that's cheaper than buying a $3k dgx or $5k m4 max with enough ram.

Not to mention you can no longer use your laptop as a laptop as the power draw drains it - you'd need to host separately and connect

A single DGX Spark can service a whole department of mathematicians (or programmers), and you can cluster up to 4 of them them to fit very large models like GLM-5 and quants of Kimi K2.5. This is nearing frontier-level model size.

I understand the value proposition of the frontier cloud models, but we're not as far off from self-hosting as you think, and it's becoming more viable for domain-specific models.

Monopoly isn't the only thing that allows you to charge large margins.

API inference access is naturally a lot more costly to provide compared to Chat UI and Claude Code, as there is a lot more load to handle with less latency. In the products they can just smooth over load curves by handling some of the requests slower (which the majority of users in a background Code session won't even notice).

> you can go all the way back to Office 2007 (with the compatibility pack) and open modern documents

Great, I can open proprietary document formats with proprietary software. I think you are missing the point of this "performative exercise".

You can also open all of those documents with LibreOffice. My point is the support LibreOffice has for Office documents is fine and not at all a problem, because Office formats have not meaningfully changed over time and they have been supported in LibreOffice for all of that time.

The comission has themselves made the commitment to reduce the reliance on exactly such standards. You are arguing for a position that they themselves aren't even arguing for as they recognize the importance of the problem.

By your logic, it would have been fine for Apple to stick with the Lightning port for charging because USB->Lightning charging ports are widely available so "it's not a problem at all".

No, because Lightning is not an open standard. OOXML has been an open standard for nearly two decades.

And a big issue for me is this blog post hurts LibreOffice because the largest reason enterprises won't touch it is that it is perceived as incompatible even when that compatibility works just fine.

If success and good marketing was the focus, LibreOffice would happily promote that it will take any file format they get because they have robust interoperable software that doesn't actually mind handling XLSX!

I think you overestimate how niche it really is. In the browser it's an essential part for many creative/productivity tools, e.g. Figma or Miro. On the backend it's used quite regularly as sandboxing mechanism or plugin system, e.g. Istio, Helm or OPA (so generally a high prominence in the CNCF ecosystem).

There are a lot more niche web standards that have a lot less usage that stuck around for a log time (e.g. the recent debate around removal of XSLT)

It is also lagging behind in terms of Python releases. They are currently on 3.11, which was released 3.5 years ago for mainline Python.

> It is also lagging behind in terms of Python releases.

Which it has always been, especially since Python 3, as anyone who's followed the pypy project in the last decade years is well aware.

The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.

Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

> The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.

Which is a concern for those libraries, I've not seen one thread criticising (or even discussing) numpy's decision.

> Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

But it's not, and either way that has nothing to do with uv, it has to do with people who use pypy and the libraries they want to use.

3.11 still has 2 years of active security patches, and has most of the modern python ecosystem on tap. That is a whole different ballgame than stuff stuck in the pre-split 2.x world

Yes they did, but the social bump that was there shortly after release has significantly calmed down already.

It did rekindle my love for the game, but most outposts are empty, even in the international districts, so I think it's hard to get hooked on it for new joiners.

EDIT (as I can't edit the orginal comment anymore): The America - English disticts are very lively and it seem like everyone in Europe is also now using those.

> Tech companies are in the business of nurturing teams knowledgeable in things

It pains the anti-capitalist fibers in my body to say this, but no they are not. At the maximum the value is in organizational knowledge and existing assets (= source code, documentation), so that people with the least knowledge possible can make changes. In software companies in general, technical excellence and knowledge is not strongly correlated with economic success as long as you clear a certain bar (that's not that high). In comparison, in hardware/engineering companies, that's a lot more correlated.

In the concrete example of a legacy codebase we have here, there is even less value in trying to build up knowledge in the company, as it has already been decided that the system is to be discarded anyways.

> you would learn how things work and then write the code

In a legacy codebase this may require learning a lot of things about how things work just to make small changes, which may be much less efficient.

I might still be naive about the industry, but if you don't know how the legacy codebase works, you might either delegate the change to someone else in the company who does, or, if there is no one left, use this opportunity to become the person who knows at least something about it.

In the Azure Foundry, they list GPT 5.2 retirement as "No earlier than 2027-05-12" (it might leave OpenAIs normal API earlier than that). I'm pretty certain that Gemini 3, which isn't even in GA yet will be retired earlier than that.