Same, I don't even see how that would work since you see the full thinking traces in Kimi but are hidden with Claude.

And the Deepseek one sounds even more dubious as Deepseek is one of the cheapest model around, why relay anything to a more expensive model? I'm sure even the gray market Claude prices are still higher than Deepseek.

I'm skeptical too, but there's a parallel market where people re-sell accounts and access tokens. This would make tokens much cheaper.

There's also an argument to be made that paying the token full price may be cheaper than going through your one RLHF or whatever other techniques that costs money.

That's true, however, if you are too far from the top models, you still are in danger of not being in the race anymore.

And with half the score of the top models, that's where Mistral is at.

As it is now, no tech company in the EU will use it, if they were just 80% from the top, that would be more feasible.

I've never seen an SPA which scales properly and doesn't become a bloated mess, maybe that's possible but it's definitely harder to make it work than using traditional server side template rendering

Plenty of app usecases don’t need to “scale” - immediately or ever!

That's a good point but you never know that from the start, "this app won't scale well" is a hard sell for a new project in my opinion

Especially today, single-user stuff, especially in categories of things like health,

especially when you’re writing your own stuff,

that’s when you know from the start that scaling doesn’t matter! =]

Related, and more powerful than my comments in this thread are going to be:

https://www.robinsloan.com/notes/home-cooked-app/

I don't only mean "scale" in terms of users but also scale in terms of features.

So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.

And guaranteeing that it will stay low features is much harder than low users I think.

In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?

Or you have to distribute your code in such a fashion, and structure your business model in such a way, that “scale” doesn’t require you doing things that have nothing to do with providing the feature set (most SaaS).

I'm currently working on a SaaS at my company and we have a lot of issues because of the SPA, I estimate we spend around 5% at least, maybe 10% of the workforce just on SPA complexity.

It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else

What’s the stack? Is it being used even sort-of in the right place / way?

Feels like a glaring omission =]

The stack is Rails / React SPA for the frontend.

> Is it being used even sort-of in the right place / way?

It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside.

I think these are the full requirements I would put for a good SPA experience:

- low users

- low number of features / or a single main feature reused in different ways

- low number of employees

- it's an app and not a website

- you don't have any users living in remote places / poor internet connection

- users are all using modern browsers and can be asked to switch to another one if needed

And I think in my company we only have one of this list, making it painful.

If anyone wants to show up and talk non-React anything,

at any point,

I’ll be checking back around later!

Until then: just talk smack about React!

None of these things you listed are critiques of single-page apps (SPA).

I don't have a final opinion on the subject, it's just the results I witnessed after a long time in the industry. The ones I've seen with Angular suffered from the same issues.

I'm sure counter examples of well managed SPAs do exist somewhere, it's just that it seems much easier to do the wrong thing compared to a traditional stack. This is why I'd not advise for it unless you have a very good reason.

The good stacks should make the good choices the natural way to do things, again my opinion.

> Some of the tools and dictionaries used for Viet-English are wonky

There's basically no real complete English/Viet dictionary anyways, the best ones are 90% there.

LLMs here are the best experience

LLMs are also a mixed bag. The core issue is limited Viet-English corpora aside from what can be found in local government documents in the US and Canada given the huge Viet Kieu community requiring local governments to create Vietnamese language collateral.

I love/hate how Google translate assumes "Anh" means "brother" or "em" means "girl".

This confusion has resulted in Vietnamese people unintentionally describing incest or gay relationships.

[0] - What she actually meant was "brother" in the sense that he is a family friend and neighbor.

Yes that's also one of the historical struggles of Google Translate, the pronouns are context based and so are the words, you need experience to know when they start and end.

It's a miserable experience for translation software.

You got downvoted but I know what you are talking about, but there were other ways to write that sentence.

Basically what OP is saying is interpersonal relations can be confused when using the Vietnamese and English definitions of both words.

Anh and Em essentially means masculine and feminine, but is also often used in romantic, non-romantic, casual, and sometimes formal usecases and this is heavily dependent on the verbs and adjectives that follow.

Viet-English NMT is very flawed at the moment.

It's going to be the same as PRISM, people will be outraged and business will go back as usual.

(And they totally won't do it again they swear, the contract says so)

Things are really bad already on Android. Most bootloaders are locked, Google prevents you to use the very few unlocked ones through the (legally questionable) Play Integrity. AOSP is basically dead (it doesn't even include a functional keyboard nor a functional call manager nowadays, can it still be called a phone?) and now they are further locking direct installs

> Things are really bad already on Android. Most bootloaders are locked, Google prevents you to use the very few unlocked ones through the (legally questionable) Play Integrity. AOSP is basically dead

This feels like complaining about the color of the bikeshed, me saying you should save your complaints for when things get really bad, and you replying "things are really bad already, there is a rotten carcass in there and the roof leaks."

Okay, so let's keep complaining about the color then.

What would be "really bad" for you? Non-google Android is dead outside of China and you can't realistically distribute software either without a Google stamp.

I don't see much difference between Android and iOS in terms of openness nowadays personally.

> What would be "really bad" for you?

"Block[ing] every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID. Every app and every device, worldwide, with no opt-out"

...would be "really bad" in my view.

Which is probably exactly why they worded it that way, despite knowing fully well they are (rather blatantly) lying. They literally explained how to avoid it themselves further down below, after you've already been angered.

> "Block[ing] every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID. Every app and every device, worldwide, with no opt-out"

Personally for me, a fake convoluted opt-out is the same as no opt out so we're already there.

Even Fortnite failed to distribute outside the Play Store, if they can't despite being famous, well you can't.

> Personally for me, a fake convoluted opt-out is the same as no opt out so we're already there.

Convoluted, yes, but fake? Aren't you just repeating the same lie? That means it looks like it bypasses the verification but doesn't actually do so. What are you basing that off of?

I'm talking about it as an app distribution method from the perspective of a developer and an app distribution method you can only ask a few people on Github to perform definitely isn't a valid one to me.

I do prefer Firefox devtools to Chrome, that's one of the reasons I use it at work.

I think both are kind of equivalent nowadays but I find that the Firefox one has a better design and looks more polished

Will you upstream it?

Possibly, but in order to be safe for everyone, reviewers may want me to remove features that allow the driver to achieve the non-standard performance. There's a lot of hoops to jump through :)

How did they react to it being vibe coded? Were they pragmatic about it, as Linus recently suggested

I have like 4 drivers to upstream myself, plus a couple of patches here and there. Quality is good and they're tested, and while I understand the code and how things work low level, I wouldn't be able to write them myself.

I've never tried it, I am put off by the amount of work for a few weekends on what I considered a personal project, plus I don't understand the code base well enough (problem domain is ok, I grew up with 8 and 16 Bit machines, and pushing graphics driver boundaries in Amiga and VGA monitor era machines). This is why my readme asks for help with issues :)

The dev on this driver used a combination of local Qwen 3.6 and 3.8 27B for admin and basic work, and extensive Codex 5.6 Sol Max to catch the issues I found and do last stage optimisations / isolate the bugs.

I'll freely admit I relied heavily on AI, my expertise and day job is in other software stacks.

I stand on the back of giants :)

For bots, usually a monopoly just paints a bigger target on your back than custom low scale prevention methods.

And Cloudflare is no exception, the "hello world" of bots is Cloudflare bypass.

They aren't, most emission statistics are counting imported emissions.

China's figure aren't that great on their own, with exportation deducted.

EDGAR assigns emissions geographically to the country where the emitting activity occurs. (so in this case no)