augusteo

The "learning through making" approach is really good. When I've explained LLMs to non-technical people, the breakthrough moment is usually when they see temperature in action. High temperature = creative but chaotic, low temperature = predictable but boring. You can't just describe that.

What I'd add: the lesson about hallucinations should come early, not just in the RAG module. Kids (and adults) need to internalize "confident-sounding doesn't mean correct" before they get too comfortable. The gap between fluency and accuracy is the thing that trips everyone up.

Growing up in Indonesia, we had "Kuku kaki kakekku kayak kuku kaki kakakku" (my grandfather's toenails look like my older sibling's toenails). The repetitive k-sounds are brutal.

What's interesting is how tongue twisters reveal what's phonetically tricky in each language. English struggles with s/sh transitions ("she sells seashells"). Indonesian targets the k-cluster combinations.

Curious if there's research on whether practicing tongue twisters in a second language actually helps with accent reduction, or if it's just party tricks.

> "So DuckDB was developed to allow queries for bigish data finally without the need for a cluster to simplify data analysis... and we now put it to a cluster?"

This is a fair point, but I think there's a middle ground. DuckDB handles surprisingly large datasets on a single machine, but "surprisingly large" still has limits. If you're querying 10TB of parquet files across S3, even DuckDB needs help.

The question is whether Ray is the right distributed layer for this. Curious what the alternative would be—Spark feels like overkill, but rolling your own coordination is painful.

The Unicode approach seems backwards in hindsight, but I wonder if it was the only practical path forward at the time. Getting Apple, Google, Samsung, and Microsoft to agree on exact pixel-level designs would've been a nightmare. Code points at least let everyone participate without vendor lock-in.

What's interesting is how the market solved it anyway—everyone just converged on Apple's designs because that's what users expected. Not through spec, but through sheer gravity.

The trajectory export feature is smart. Evaluation and training data collection in the same tool.

I'm curious how the benchmarks handle non-determinism. Real GUIs have loading states, animations, popups that appear sometimes but not always. Does cuabench control for that, or is variance just part of the measurement?

Also interested in what "Windows Arena" tests specifically. Windows has so many edge cases - UAC prompts, driver install dialogs, random update notifications. Those feel like the hard mode for computer-use agents.

The shift from "click and hope" to explicit post-conditions is the right framing.

We've been building agent-based automation and the reliability problem is brutal. An agent can be 95% accurate on each step, but chain ten steps together and you're at 60% success rate. That's not usable.

Curious about the failure modes though. What happens when the verification itself is wrong? Like, the cart shows updated on screen but the verification layer checks a stale element?

I love projects like this. Taking something trivially simple and asking "but what if we really optimized it?"

The material science discussion in these comments is fascinating. Never thought about how the contact point geometry matters so much. Diamond tip makes intuitive sense for hardness, but then you need something it can spin on without scratching...

The Chrome Extensions support is the interesting part here. That's often the dealbreaker for using mobile devices as computer replacements.

Google's had this weird situation where Android and ChromeOS overlap more every year. At some point maintaining two operating systems with converging feature sets seems wasteful.

My guess: ChromeOS probably survives for the education market where manageability matters more than capabilities. But for consumers? Android on a big screen with keyboard and mouse might just be good enough.

Nice work on getting this running in the browser. The fact that it works at all with WebGL/camera APIs is impressive. I always expect browser-based video stuff to be janky, but the demos look smooth.

Really wanna use this for GMeet or Zoom!

simonw replied to me! Achievement unlocked! Big fan!

And yes there's definitely still a lot to do. Security is def a big one.

Very exciting time to be alive.

I work in AI and wrote code with AI everyday. The robots haven't replaced me yet, but I'll let you know :)

Nice writeup. The Exists subquery approach is definitely the cleanest.

One thing worth mentioning: if you're hitting this problem frequently, it might be worth reconsidering the query patterns themselves. We had a similar issue at work where we kept adding `.distinct()` everywhere, and eventually realized we were doing the filtering wrong upstream.

The PostgreSQL-specific `distinct(*fields)` with the ORDER BY restriction is one of those things that trips people up. The error message isn't great either. "SELECT DISTINCT ON expressions must match initial ORDER BY expressions" is technically correct but doesn't explain why or what to do about it.

Good call recommending Exists as the default approach. It's more explicit about intent too.

The timing is interesting. TikTok settles right as jury selection begins, Snap settled last week. Meta and YouTube are the ones staying in.

I wonder if the settlement amounts will ever become public. The Big Tobacco comparison keeps coming up, but those settlements were massive and included ongoing payments. Hard to imagine social media companies agreeing to anything similar without admitting some level of harm.

As a parent of two kids (8 and 6), I think about this constantly. We limit screen time pretty aggressively, but it's getting harder as they get older. The "attention-grabbing design" part isn't some conspiracy theory. These apps are explicitly optimized for engagement. The question is whether that optimization crosses a legal line.

Curious how the trial plays out with Zuckerberg on the stand.

> I don't see the point of JSX, seems to decrease type safety

JSX compiles to typed function calls. The type safety is in the component definitions, not the syntax.

The real question is whether video composition is actually hierarchical enough to benefit from JSX. For simple clips, probably overkill. But once you're layering talking heads, captions, b-roll, and transitions, the tree structure starts making sense.

The hardest part isn't the generation. It's the orchestration. Caching, retry logic, stitching outputs from multiple providers. A declarative layer that handles that automatically is genuinely useful.