That's a huge misrepresentation of fair source licenses. They prevent competing with the original vendor, but still try to retain Right to Repair as much as possible, for example:

> The Fair Core License, or FCL, is a mostly-permissive non-compete Fair Source license that eventually transitions to Open Source after 2 years.

Well no, there is no need to develop domestic capability. Put laws in effect which disable foreign capabilities and which reward domestic ones, and they will be developed. No endeavor from government needed (which is a good thing, since governments are not really great at doing such stuff).

Well yes, just because you think it's a public good worth competing over doesn't mean there's anyone who thinks it's a viable business model.

I see where (both of you) are coming from, and I'm very privacy conscious (=paranoid) myself, but in this case, as a user, I wouldn't actually mind. It seems to me you would be tracking flows instead of users, which is fine in my book. Now, including Google fonts on every page, using their tag manager, analytics, captcha... That gives me the creeps. Waaay too much information about each and every user. But generic origin query params? Yeah, ok. :shrug:

This. For privacy, it is much better to avoid Google Play services (which are the only supported solution for push notifications in GrapheneOS).

> Presumably they don’t much consider legality.

Or the operation is not even illegal where they come from?

Well yeah, and there is KDE 3 which was awesome. But for most of the projects their point stands.

> The key: proxy_ssl_verify off — the new server’s SSL cert is valid for the domain, not for the IP address. Disabling verification here is fine because we control both ends.

Yeah - no, it's not. They made the MitM attack possible with this change. The exposure was limited to those 5 minutes, but it should have been a known risk.

Also not certain how they could check the apps on the new server with the read-only database, while it was a replica?

Still, nice to hear it succeeded, the reasons sound very familiar.

By continuously testing competitors and local LLMs? The reason for rising prices is that they (Anthropic) probably realized that they have reached a ceiling of what LLMs are capable of, and while it's a lot, it is still not a big moat and it's definitely not intelligence.

Anything but the simplest tooling is not transferable between model generations, let alone completely different families.

> Anything but the simplest tooling is not transferable between model generations, let alone completely different families.

It is transferable-yes, you will get issues if you take prompts and workflows tuned for one model and send them to another unchanged. But, most of the time, fixing it is just tinkering with some prompt templates

People port solutions between models all the time. It takes some work, but the amount of work involved is tractable

Plus: this is absolutely the kind of task a coding agent can accelerate

The biggest risk is if your solution is at the frontier of capability, and a competing model (even another frontier model) just can’t do it. But a lot of use cases, that isn’t the case. And even if that is the case today, decent odds in a few more months it won’t be

Yep. My approach has been, if I can’t reliably get something to 90+% with a flash / nano / haiku, then it’s not viable for any accuracy critical work. (I don’t know of or have the luck of having any other work.) Starting out with the pro / opus for any production classification work has always been a trick.

Ha. Sounds a lot like the one 10x vs. predictable mediocre guys with a scaffolding of processes. Aim high and hit or miss or try to grind predictably and continuously. Same with humans and depends on the loss you can afford.

If you're talking about APIs and SDKs, whether direct API calls or driving tools like Claude code or codex with human out of the loop, I think that's actually fairly straightforward to switch between the various tools.

If you're talking about output quality, then yeah, that's not as easy. But for product outputs (building a customer service agent or something like that), having a well-designed eval harness and doing testing and iteration can get you some degree of convergence between the models of similar generations. Coding is similar (iterate, measure), but less easy to eval.

For most tasks, at some future date, isn't there going to be some ambient baseline of capabilities you can get per $/tok, starting at ~0 for OSS models, such that eventually all tooling gets trivially transferable?

It's not that hard to make it generic. It does take a little work, but really it boils down to figuring out how to make things work with the "dumbest" model in your set.

Note that it is very likely this market can't sustain this level of competition for long. We are all still chasing the carrot of AGI, while hardware costs skyrocket.

Is there a way one can do DTP using LLMs? InDesign only integrates image generating, if I'm not mistaken. .

LLMs still seem to really struggle with layout. These design tools seem to work well for designs that flow naturally like webpages.

But try and design say an “An A4 poster with a hero image, main text saying this, details next to the image and fine print at bottom” and you end up with pretty poor results.

Or use mc (midnight commander).