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.

I used to think this. Then I noticed how often "preparation" became its own infinite loop.

At work we built something from a 2-page spec in 4 months. The competing team spent 8 months on architecture docs before writing code. We shipped. They pivoted three times and eventually disbanded.

Planning has diminishing returns. The first 20% of planning catches 80% of the problems. Everything after that is usually anxiety dressed up as rigor.

The article's right about one thing: doing it badly still counts. Most of what I know came from shipping something embarrassing, then fixing it.

Spent a few minutes just watching worlds unfold. There's something meditative about it.

Curious about the performance issues Meegul mentioned. These simulations can be surprisingly compute-intensive once you add physics interactions between many entities. Would love to see the code if you ever open-source it.

Nice work.

The limiting factor at work isn't writing code anymore. It's deciding what to build and catching when things go sideways.

We've been running agent workflows for a while now. The pattern that works: treat agents like junior team members. Clear scope, explicit success criteria, checkpoints to review output. The skills that matter are the same ones that make someone a good manager of people.

pglevy is right that many managers aren't good at this. But that's always been true. The difference now is that the feedback loop is faster. Bad delegation to an agent fails in minutes, not weeks. You learn quickly whether your instructions were clear.

The uncomfortable part: if your value was being the person who could grind through tedious work, that's no longer a moat. Orchestration and judgment are what's left.

The irony of a site about AI opt-outs getting hammered by AI scrapers is almost too on the nose.

trollbridge's point about scrapers using residential IPs and targeting authentication endpoints matches what we've seen. The scrapers have gotten sophisticated. They're not just crawling, they're probing.

The economics are broken. Running a small site used to cost almost nothing. Now you need to either pay for CDN/protection or spend time playing whack-a-mole with bad actors.

ronsor hosting a front-page HN project on 32MB RAM is impressive and also highlights how much bloat we've normalized. The scraper problem is real, but so is the software efficiency problem.

The mobility discussion is interesting to me as someone who navigated US immigration.

Moving countries is hard. Not just paperwork hard, but restarting-your-life hard. Credit history, professional networks, understanding how things actually work versus how they officially work.

If the mobility framework makes it meaningfully easier for skilled workers to move between India and Europe, that's significant. Not because of labor economics, but because talented people having more options is generally good for everyone.

The H1B system in the US has created a lot of anxiety and frustration. Competition for that talent pool seems healthy.

Technical blogs from infrastructure companies used to serve two purposes: demonstrate expertise and build trust. When the posts start overpromising, you lose both.

I don't know enough about this specific implementation to say whether "implemented Matrix" is accurate or marketing stretch. But the pattern of "we did X" blog posts that turn out to be "we did a demo of part of X" is getting tiresome across the industry.

The fix is boring: just be precise about what you built. "We prototyped a Matrix homeserver on Workers with these limitations" is less exciting but doesn't erode trust.

The "1000 people in India watching cameras" reveal was the moment the magic died. Once you know the wizard is just a guy behind a curtain, you can't unsee it.

The interesting question isn't whether the tech was ready. It wasn't. The question is whether Amazon learned anything useful from the attempt.

Computer vision for retail checkout is a legitimate hard problem. Occlusion, similar-looking products, people changing their minds. I've worked on CV pipelines and the gap between "works in the demo" and "works at scale" is brutal.

My guess: they collected a ton of training data from those human reviewers. Whether they'll use it for a v2 or just write it off, who knows.

bm3719's observation about Stoicism as a defense mechanism resonates with me. I've found it genuinely useful, not as self-help packaged for tech bros, but as practical mental infrastructure.

The core idea is simple. You separate what you can control from what you can't. Then you stop burning energy on the second category. Easier said than done, but the framework helps.

I keep coming back to "How to Think Like a Roman Emperor" as a practical companion to the original texts. It's Marcus Aurelius filtered through modern psychology, with concrete exercises instead of just principles.

The danger is treating Stoicism as emotional suppression. It's not. It's about choosing where to direct your attention and energy. That's genuinely useful when you're surrounded by systems designed to capture both.

The Star Wars ASCII animation was how I learned telnet existed. Felt like discovering a secret passage in the internet.

There's something pure about text-based interfaces. No loading spinners, no JavaScript frameworks, no cookie banners. Just text.

This maps to what we've seen building AI at work.

When we started building a voice agent for inbound calls, the models were close but not quite there. We spent months compensating for gaps: latency, barge-in handling, understanding messy phone audio. A lot of that was engineering around model limitations.

Then the models got better. Fast. Latency dropped. Understanding improved. Suddenly the human-in-the-loop wasn't compensating, it was enhancing.

The shift was noticeable. We went from "how do we work around this limitation" to "how do we build the best experience on top of this capability." That's MMF in practice.

The timing question is real though. We started building before MMF fully existed for our use case. Some of that early work was throwaway. Some of it became the foundation. Hard to know in advance which is which.

Wow I didn't know that. That's impressive.

Curious about the failure modes here. What specifically causes the silent data loss?

The "serialize to localStorage on blur" approach onion2k mentions seems like it would catch most cases. But I've definitely lost form data in ways I couldn't explain. Mobile Safari is particularly bad about this.

One of those topics I know almost nothing about but find fascinating. Ancient engineers building a 100+ meter tower that lasted 1,500 years.

yeah exactly. even OpenAI/Gemini are really cheap too

I don't work in hardware, but projects like this are inspiring. Taking something expensive and specialized and making it accessible with open designs.

The WHO recognition for low-resource settings is the kind of impact that matters.

Bookmarking this. Clear explanations of graphics algorithms are surprisingly rare.