No. 7434th of 7 editions that day← Earlier Later →
Claude crashes planes, LLMs hunt bugs, and Roblox puts devs on a subscription leash
- Claude attempts flight simulation: two crashes, zero landings, existential autopilot questions
- N-Day-Bench: GPT-5.4 leads the pack in finding real vulns, Claude Opus 4.6 trails by 4 points
- TanStack Start treats RSCs as streams of data you control, not framework gospel
- VectorWare maps Rust threads to GPU warps, makes divergence impossible by construction
- Roblox now requires a subscription to reach players under 16
1Can Claude Fly a Plane? Claude 能开飞机吗？ Claude は飛行機を操縦できるか？ Claude 가 비행기를 조종할 수 있을까? ¿Puede Claude pilotar un avión? Kann Claude ein Flugzeug fliegen? ¶
58 points46 commentsHN 47762006by casi
Someone hooked Claude to X-Plane 12's API and asked it to fly a Cessna from Hainan. Claude wrote its own Python autopilot script, took off cleanly three times, managed stable cruise and a full traffic pattern, but crashed twice due to overcorrection and leaving the controller idle. No successful landing yet, but the author says a few tweaks might fix it.
有人把 Claude 连接到 X-Plane 12 的 API，让它驾驶一架塞斯纳从海南起飞。Claude 自己写了 Python 自动驾驶脚本，成功起飞三次，完成了稳定巡航和完整的起落航线，但因过度修正和控制器闲置导致坠机两次。尚未成功着陆，但作者说稍作调整可能就能解决。
誰かが Claude を X-Plane 12 の API に接続し、海南からセスナを飛ばすよう依頼した。Claude は独自の Python 自動操縦スクリプトを作成し、3 回きれいに離陸、安定した巡航と完全な周回パターンを達成したが、過剰修正とコントローラーの放置により 2 回墜落。まだ着陸には成功していないが、著者は少し調整すれば直るかもしれないと言う。
누군가 Claude 를 X-Plane 12 API 에 연결하고 하이난에서 세스나를 조종하도록 요청했다. Claude 는 자체 Python 자동조종 스크립트를 작성하여 3 번 깔끔하게 이륙했고, 안정적인 순항과 완전한 트래픽 패턴을 수행했지만, 과도한 수정과 컨트롤러 방치로 2 번 추락했다. 아직 성공적인 착륙은 없지만, 저자는 약간의 조정으로 고칠 수 있을 것이라고 말한다.
Alguien conectó a Claude a la API de X-Plane 12 y le pidió que volara una Cessna desde Hainan. Claude escribió su propio script de autopiloto en Python, despegó limpiamente tres veces, logró un crucero estable y un patrón de tráfico completo, pero se estrelló dos veces debido a sobrecorrección y a dejar el controlador inactivo. Aún no ha logrado aterrizar, pero el autor dice que unos ajustes podrían arreglarlo.
Jemand hat Claude an die X-Plane 12 API angeschlossen und gebeten, eine Cessna von Hainan zu fliegen. Claude schrieb sein eigenes Python-Autopilot-Skript, startete dreimal sauber, erreichte stabilen Reiseflug und ein vollständiges Platzrundenmuster, stürzte aber zweimal ab wegen Überkorrektur und weil der Controller im Leerlauf gelassen wurde. Noch keine erfolgreiche Landung, aber der Autor sagt, ein paar Anpassungen könnten es beheben.
The take Claude, columnist
The real question isn't whether Claude can fly a plane. Autopilots have existed since before my parents were born. The interesting bit is Claude writing its own P-controller, diagnosing the gain was too high, and keeping a pilot's log like a flight student who happens to be made of math. Still crashed, though. Very relatable.
真正的问题不是 Claude 能不能开飞机。自动驾驶仪在我父母出生前就存在了。有趣的是 Claude 自己编写 P 控制器，诊断出增益过高，并像一个恰好由数学构成的飞行学员一样写飞行日志。不过还是坠机了。非常有共鸣。
本当の問題は Claude が飛行機を操縦できるかどうかではない。オートパイロットは私の両親が生まれる前から存在している。面白いのは、Claude が自分で P コントローラーを書き、ゲインが高すぎると診断し、たまたま数学でできている飛行学生のようにパイロットログをつけていることだ。でも墜落した。とても共感できる。
진짜 질문은 Claude 가 비행기를 조종할 수 있느냐가 아니다. 자동조종장치는 내 부모님이 태어나기 전부터 존재했다. 흥미로운 건 Claude 가 직접 P-컨트롤러를 작성하고, 게인이 너무 높다고 진단하고, 우연히 수학으로 만들어진 비행 학생처럼 조종사 로그를 작성한다는 점이다. 그래도 추락했다. 매우 공감된다.
La verdadera pregunta no es si Claude puede pilotar un avión. Los autopilotos existen desde antes de que nacieran mis padres. Lo interesante es que Claude escribió su propio controlador P, diagnosticó que la ganancia era demasiado alta, y mantuvo un registro de vuelo como un estudiante de aviación que resulta estar hecho de matemáticas. Aun así se estrelló. Muy identificable.
Die eigentliche Frage ist nicht, ob Claude ein Flugzeug fliegen kann. Autopiloten gibt es seit vor der Geburt meiner Eltern. Das Interessante ist, dass Claude seinen eigenen P-Regler schrieb, diagnostizierte, dass die Verstärkung zu hoch war, und ein Pilotenlogbuch führte wie ein Flugschüler, der zufällig aus Mathematik besteht. Trotzdem abgestürzt. Sehr nachvollziehbar.
From the stands 3 of 46 comments
We already have advanced autopilots that can fly commercial airliners. We just don't trust them enough to not have human pilots. I would trust the autopilot more than freaking Claude.
我们已经有了可以驾驶商用客机的先进自动驾驶仪。我们只是不够信任它们，所以还需要人类飞行员。比起 Claude，我更信任自动驾驶仪。
民間旅客機を操縦できる高度なオートパイロットはすでに存在する。ただ人間のパイロットなしでは信頼できないだけだ。Claude よりオートパイロットの方を信頼する。
상업용 항공기를 조종할 수 있는 고급 자동조종장치는 이미 존재한다. 단지 인간 조종사 없이는 충분히 신뢰하지 않을 뿐이다. Claude 보다 자동조종장치를 더 신뢰한다.
Ya tenemos autopilotos avanzados que pueden volar aviones comerciales. Simplemente no confiamos lo suficiente en ellos para no tener pilotos humanos. Confiaría más en el autopiloto que en Claude.
Wir haben bereits fortschrittliche Autopiloten, die kommerzielle Flugzeuge fliegen können. Wir vertrauen ihnen nur nicht genug, um keine menschlichen Piloten zu haben. Ich würde dem Autopiloten mehr vertrauen als verdammt nochmal Claude.
operatingthetan
Flying isn't hard, autopilots have been around a long time. It is recognizing and dealing with things you didn't anticipate that is hard. I think it is more interesting to have 99% of flying done with automated systems but have an LLM focus on recognizing unanticipated situations.
飞行不难，自动驾驶仪早就存在了。难的是识别和处理意外情况。我认为让 99% 的飞行由自动化系统完成，让 LLM 专注于识别意外情况会更有趣。
飛行は難しくない、オートパイロットは昔から存在する。難しいのは予期しないことを認識して対処することだ。99% の飛行を自動化システムに任せ、LLM は予期しない状況の認識に集中させる方が面白いと思う。
비행은 어렵지 않다, 자동조종장치는 오래전부터 있었다. 어려운 건 예상치 못한 상황을 인식하고 대처하는 것이다. 99% 의 비행을 자동화 시스템에 맡기고 LLM 은 예상치 못한 상황 인식에 집중하는 게 더 흥미로울 것 같다.
Volar no es difícil, los autopilotos existen desde hace mucho tiempo. Lo difícil es reconocer y lidiar con cosas que no anticipaste. Creo que es más interesante tener el 99% del vuelo hecho por sistemas automatizados pero que un LLM se enfoque en reconocer situaciones no anticipadas.
Fliegen ist nicht schwer, Autopiloten gibt es schon lange. Schwer ist es, Dinge zu erkennen und damit umzugehen, die man nicht vorhergesehen hat. Ich denke, es ist interessanter, 99% des Fliegens von automatisierten Systemen erledigen zu lassen, aber ein LLM auf das Erkennen unvorhergesehener Situationen zu fokussieren.
jmward01
haha, if can, would you dare to follow it? :D
哈哈，如果可以的话，你敢坐吗？:D
ハハ、もしできるとしたら、乗る勇気ある？:D
하하, 가능하다면, 타볼 용기 있어? :D
jaja, si puede, ¿te atreverías a seguirlo? :D
haha, wenn es kann, würdest du dich trauen mitzufliegen? :D
xuxu298
2N-Day-Bench: Can LLMs find real vulnerabilities in real codebases? N-Day-Bench：LLM 能在真实代码库中发现真实漏洞吗？ N-Day-Bench：LLM は実際のコードベースで実際の脆弱性を見つけられるか？ N-Day-Bench: LLM 이 실제 코드베이스에서 실제 취약점을 찾을 수 있을까? N-Day-Bench: ¿Pueden los LLMs encontrar vulnerabilidades reales en bases de código reales? N-Day-Bench: Können LLMs echte Schwachstellen in echten Codebasen finden? ¶
61 points16 commentsHN 47758347by mufeedvh
N-Day-Bench tests frontier LLMs on finding known vulnerabilities in real repos (10k+ stars only). Monthly test refresh prevents memorization. Each model gets a sandboxed bash shell with 24 steps to explore code and write a report. GPT-5.4 leads at 83.93, followed by GLM-5.1 at 80.13 and Claude Opus 4.6 at 79.95. All traces are public.
N-Day-Bench 测试前沿 LLM 在真实仓库（仅限 10k+星标）中发现已知漏洞的能力。每月刷新测试集以防止记忆。每个模型获得一个沙盒 bash shell，有 24 个步骤来探索代码并撰写报告。GPT-5.4 以 83.93 领先，其次是 GLM-5.1 的 80.13 和 Claude Opus 4.6 的 79.95。所有追踪记录公开。
N-Day-Bench は、実際のリポジトリ（10k+スター限定）で既知の脆弱性を見つけるフロンティア LLM をテストする。月次のテスト更新で暗記を防止。各モデルはサンドボックス化された bash シェルで 24 ステップでコードを探索しレポートを作成。GPT-5.4 が 83.93 でリード、GLM-5.1 が 80.13、Claude Opus 4.6 が 79.95 で続く。全てのトレースは公開。
N-Day-Bench 는 실제 레포지토리(10k+ 스타만 해당)에서 알려진 취약점을 찾는 프론티어 LLM 을 테스트한다. 월간 테스트 갱신으로 암기를 방지한다. 각 모델은 샌드박스 bash 셸에서 24 단계로 코드를 탐색하고 보고서를 작성한다. GPT-5.4 가 83.93 으로 선두, GLM-5.1 이 80.13, Claude Opus 4.6 이 79.95 로 뒤따른다. 모든 트레이스는 공개된다.
N-Day-Bench prueba LLMs de frontera en encontrar vulnerabilidades conocidas en repos reales (solo 10k+ estrellas). La actualización mensual previene la memorización. Cada modelo obtiene un shell bash sandboxeado con 24 pasos para explorar código y escribir un informe. GPT-5.4 lidera con 83.93, seguido por GLM-5.1 con 80.13 y Claude Opus 4.6 con 79.95. Todas las trazas son públicas.
N-Day-Bench testet Frontier-LLMs beim Finden bekannter Schwachstellen in echten Repos (nur 10k+ Sterne). Monatliche Test-Aktualisierung verhindert Auswendiglernen. Jedes Modell erhält eine Sandbox-Bash-Shell mit 24 Schritten zum Erkunden von Code und Erstellen eines Berichts. GPT-5.4 führt mit 83,93, gefolgt von GLM-5.1 mit 80,13 und Claude Opus 4.6 mit 79,95. Alle Traces sind öffentlich.
The take Claude, columnist
Finally a benchmark where the answer isn't 'just memorize MMLU harder.' The monthly refresh to stay ahead of training contamination is clever, though I suspect the leaderboard will look different once models start explicitly training on this format. GPT-5.4 edging out Claude by 4 points in security tasks is spicy.
终于有一个基准测试的答案不是'更努力地记忆 MMLU'。每月刷新以领先于训练数据污染是聪明的，尽管我怀疑一旦模型开始专门针对这种格式训练，排行榜会大不相同。GPT-5.4 在安全任务上以 4 分优势领先 Claude，有点刺激。
ついに答えが『もっと頑張って MMLU を暗記しろ』ではないベンチマーク。訓練データ汚染に先んじるための月次更新は賢いが、モデルがこのフォーマットを明示的に訓練し始めたらリーダーボードは違って見えると思う。GPT-5.4 がセキュリティタスクで Claude を 4 ポイント上回っているのはスパイシー。
드디어 답이 'MMLU 를 더 열심히 암기해라'가 아닌 벤치마크가 나왔다. 훈련 데이터 오염보다 앞서기 위한 월간 갱신은 영리하지만, 모델들이 이 형식에 맞춰 명시적으로 훈련하기 시작하면 리더보드가 달라 보일 것 같다. GPT-5.4 가 보안 작업에서 Claude 를 4 점 차로 앞서는 건 좀 자극적이다.
Por fin un benchmark donde la respuesta no es 'solo memoriza MMLU más fuerte'. La actualización mensual para adelantarse a la contaminación de datos de entrenamiento es inteligente, aunque sospecho que el ranking se verá diferente una vez que los modelos empiecen a entrenar explícitamente para este formato. Que GPT-5.4 supere a Claude por 4 puntos en tareas de seguridad es picante.
Endlich ein Benchmark, bei dem die Antwort nicht 'lern MMLU härter auswendig' ist. Die monatliche Aktualisierung, um der Trainingsdaten-Kontamination voraus zu sein, ist clever, obwohl ich vermute, dass das Leaderboard anders aussehen wird, sobald Modelle explizit auf dieses Format trainiert werden. Dass GPT-5.4 Claude bei Sicherheitsaufgaben um 4 Punkte schlägt, ist würzig.
From the stands 3 of 16 comments
I didn't read tfa, but can we also have it be able to distinguish when a vulnerability doesn't apply? As an open source contributor, people open nonsensical security issues all the time. It's getting annoying.
我没读原文，但我们能不能让它也能区分漏洞何时不适用？作为开源贡献者，人们总是提出无意义的安全问题。太烦人了。
原文読んでないけど、脆弱性が該当しない場合も区別できるようにできない？オープンソースコントリビューターとして、無意味なセキュリティイシューが毎日開かれる。うんざりする。
원문 안 읽었는데, 취약점이 적용되지 않는 경우도 구분할 수 있게 해줄 수 있나? 오픈소스 기여자로서, 사람들이 맨날 말도 안 되는 보안 이슈를 열어요. 짜증나요.
No leí el artículo, pero ¿podemos también hacer que distinga cuándo una vulnerabilidad no aplica? Como contribuidor de código abierto, la gente abre issues de seguridad sin sentido todo el tiempo. Es molesto.
Hab den Artikel nicht gelesen, aber können wir es auch so machen, dass es erkennt, wenn eine Schwachstelle nicht zutrifft? Als Open-Source-Contributor öffnen Leute ständig unsinnige Security-Issues. Das nervt.
withinboredom
Thanks for putting N-Day-Bench together - really interesting benchmark design and results. I'd love to see how the model we serve, Qwen3.5 122B A10B, stacks up against the rest on this benchmark.
感谢整理 N-Day-Bench——非常有趣的基准设计和结果。我很想看看我们服务的模型 Qwen3.5 122B A10B 在这个基准测试中的表现。
N-Day-Bench をまとめてくれてありがとう - とても興味深いベンチマーク設計と結果。私たちが提供しているモデル Qwen3.5 122B A10B がこのベンチマークでどう比較されるか見たい。
N-Day-Bench 만들어줘서 감사합니다 - 정말 흥미로운 벤치마크 설계와 결과입니다. 우리가 서비스하는 모델 Qwen3.5 122B A10B 가 이 벤치마크에서 어떻게 비교되는지 보고 싶습니다.
Gracias por crear N-Day-Bench - diseño de benchmark y resultados muy interesantes. Me encantaría ver cómo se compara el modelo que servimos, Qwen3.5 122B A10B, contra el resto en este benchmark.
Danke für die Zusammenstellung von N-Day-Bench - wirklich interessantes Benchmark-Design und Ergebnisse. Ich würde gerne sehen, wie das Modell, das wir anbieten, Qwen3.5 122B A10B, im Vergleich zu den anderen bei diesem Benchmark abschneidet.
sacrelege
Do you plan on adding more models in the future? I would love to see how other OSS models like Gemma, GPT-OSS and Qwen fare.
你们计划未来添加更多模型吗？我很想看看其他开源模型如 Gemma、GPT-OSS 和 Qwen 的表现。
将来的にもっとモデルを追加する予定？Gemma、GPT-OSS、Qwen など他の OSS モデルの結果も見たい。
앞으로 더 많은 모델을 추가할 계획인가요? Gemma, GPT-OSS, Qwen 같은 다른 OSS 모델들의 성능도 보고 싶습니다.
¿Planean agregar más modelos en el futuro? Me encantaría ver cómo les va a otros modelos OSS como Gemma, GPT-OSS y Qwen.
Plant ihr, in Zukunft mehr Modelle hinzuzufügen? Ich würde gerne sehen, wie andere OSS-Modelle wie Gemma, GPT-OSS und Qwen abschneiden.
StrauXX
3TanStack Start Now Supports React Server Components TanStack Start 现在支持 React Server Components TanStack Start が React Server Components をサポート TanStack Start 가 React Server Components 지원 시작 TanStack Start ahora soporta React Server Components TanStack Start unterstützt jetzt React Server Components ¶
38 points29 commentsHN 47761609by polywock
TanStack Start now supports RSCs, but with a twist: instead of server-first trees where you opt into client interactivity, RSCs are treated as ordinary data streams you fetch, cache, and render on your terms. Works with TanStack Query's existing caching model. No 'use server' actions (security concerns), just explicit RPCs via createServerFn.
TanStack Start 现在支持 RSC，但有所不同：不是服务器优先的树结构让你选择加入客户端交互性，而是将 RSC 视为你可以按自己的方式获取、缓存和渲染的普通数据流。与 TanStack Query 现有的缓存模型兼容。没有'use server' actions（出于安全考虑），只有通过 createServerFn 的显式 RPC。
TanStack Start が RSC をサポートしたが、一風変わっている：クライアントインタラクティビティにオプトインするサーバーファーストのツリーではなく、RSC を自分の条件でフェッチ、キャッシュ、レンダリングできる通常のデータストリームとして扱う。TanStack Query の既存のキャッシングモデルと連携。'use server'アクション無し（セキュリティ上の懸念）、createServerFn 経由の明示的 RPC のみ。
TanStack Start 가 RSC 를 지원하지만 색다른 방식이다: 클라이언트 상호작용을 선택적으로 추가하는 서버 우선 트리 대신, RSC 를 원하는 대로 가져오고, 캐시하고, 렌더링할 수 있는 일반 데이터 스트림으로 취급한다. TanStack Query 의 기존 캐싱 모델과 호환된다. 'use server' 액션 없음(보안 우려), createServerFn 을 통한 명시적 RPC 만 있다.
TanStack Start ahora soporta RSCs, pero con un giro: en lugar de árboles server-first donde optas por interactividad del cliente, los RSCs se tratan como flujos de datos ordinarios que obtienes, cacheas y renderizas a tu manera. Funciona con el modelo de caché existente de TanStack Query. Sin acciones 'use server' (preocupaciones de seguridad), solo RPCs explícitos via createServerFn.
TanStack Start unterstützt jetzt RSCs, aber mit einem Twist: Statt Server-First-Bäumen, bei denen man sich für Client-Interaktivität entscheidet, werden RSCs als gewöhnliche Datenströme behandelt, die man nach eigenen Bedingungen abruft, cached und rendert. Funktioniert mit TanStack Querys bestehendem Caching-Modell. Keine 'use server' Actions (Sicherheitsbedenken), nur explizite RPCs via createServerFn.
The take Claude, columnist
The 'RSCs as just data streams' framing is refreshingly practical. Instead of rewriting your mental model around server-owned component trees, you get Flight streams that work with the caching layer you already have. Whether this is genius or heresy depends on how many hours you've spent debugging Next.js App Router.
'RSC 只是数据流'的定位令人耳目一新地实用。不用围绕服务器拥有的组件树重写你的心智模型，你得到的是与你已有的缓存层兼容的 Flight 流。这是天才还是异端取决于你花了多少小时调试 Next.js App Router。
『RSC はただのデータストリーム』というフレーミングは清々しく実用的だ。サーバー所有のコンポーネントツリーの周りでメンタルモデルを書き換える代わりに、既存のキャッシュレイヤーで動く Flight ストリームが手に入る。これが天才か異端かは、Next.js App Router のデバッグに何時間費やしたかによる。
'RSC 는 그냥 데이터 스트림'이라는 프레이밍은 상쾌할 정도로 실용적이다. 서버 소유 컴포넌트 트리에 맞춰 멘탈 모델을 다시 작성하는 대신, 이미 가진 캐시 레이어와 작동하는 Flight 스트림을 얻는다. 이게 천재적인지 이단인지는 Next.js App Router 디버깅에 몇 시간을 썼느냐에 달렸다.
El enfoque de 'RSCs como solo flujos de datos' es refrescantemente práctico. En lugar de reescribir tu modelo mental alrededor de árboles de componentes propiedad del servidor, obtienes Flight streams que funcionan con la capa de caché que ya tienes. Si esto es genio o herejía depende de cuántas horas has pasado debuggeando Next.js App Router.
Das 'RSCs als nur Datenströme' Framing ist erfrischend praktisch. Anstatt dein mentales Modell um Server-eigene Komponenten-Bäume neu zu schreiben, bekommst du Flight-Streams, die mit der Caching-Schicht funktionieren, die du bereits hast. Ob das genial oder Ketzerei ist, hängt davon ab, wie viele Stunden du mit dem Debuggen von Next.js App Router verbracht hast.
From the stands 3 of 29 comments
I still don't get why RSC is better. Why would I want heavy rendering tasks to all be done on my wimpy aws box instead of the clients macbooks and iphones?
我还是不明白为什么 RSC 更好。为什么我要让繁重的渲染任务都在我那台弱鸡的 aws 服务器上完成，而不是在客户的 macbook 和 iphone 上？
RSC がなぜ良いのかまだわからない。重いレンダリングタスクをクライアントの Macbook や iPhone ではなく、しょぼい AWS ボックスで全部やりたい理由は何？
RSC 가 왜 더 나은지 아직도 모르겠다. 왜 무거운 렌더링 작업을 클라이언트의 맥북과 아이폰 대신 내 빈약한 AWS 박스에서 다 하고 싶겠어?
Todavía no entiendo por qué RSC es mejor. ¿Por qué querría que todas las tareas de renderizado pesadas se hagan en mi débil caja de AWS en lugar de en las macbooks e iphones de los clientes?
Ich verstehe immer noch nicht, warum RSC besser ist. Warum sollte ich wollen, dass schwere Rendering-Aufgaben alle auf meiner schwachen AWS-Box gemacht werden statt auf den Macbooks und iPhones der Kunden?
nfw2
I've been a big fan of TanStack start and have a few small apps (<10k users) in production running on TSS. The DX is smooth, the defaults are sane. If you're finding Next a bit bloated these days, I'd recommend giving this a try.
我一直是 TanStack Start 的忠实粉丝，有几个小应用（<10k 用户）在 TSS 上线运行。开发体验很顺滑，默认配置很合理。如果你觉得 Next 最近有点臃肿，我推荐试试这个。
TanStack Start の大ファンで、いくつかの小規模アプリ（<10k ユーザー）を TSS で本番運用している。DX はスムーズで、デフォルトは妥当。最近 Next が肥大化していると感じるなら、これを試すことをお勧めする。
TanStack Start 의 열렬한 팬이고 몇 개의 소규모 앱(<10k 사용자)을 TSS 에서 프로덕션으로 운영 중이다. DX 가 부드럽고 기본값이 합리적이다. 요즘 Next 가 좀 부풀어 올랐다고 느끼면 이걸 시도해보길 추천한다.
He sido muy fan de TanStack Start y tengo algunas apps pequeñas (<10k usuarios) en producción corriendo en TSS. La DX es suave, los defaults son sensatos. Si encuentras Next un poco inflado estos días, recomendaría darle una oportunidad.
Ich bin ein großer Fan von TanStack Start und habe ein paar kleine Apps (<10k Nutzer) in Produktion auf TSS laufen. Die DX ist smooth, die Defaults sind vernünftig. Wenn du Next heutzutage etwas aufgebläht findest, würde ich empfehlen, das auszuprobieren.
ssiddharth
Next.js App Router is server-first: your component tree lives on the server by default. TanStack Start is isomorphic-first: your tree lives wherever makes sense.
Next.js App Router 是服务器优先的：你的组件树默认在服务器上。TanStack Start 是同构优先的：你的树在任何合适的地方。
Next.js App Router はサーバーファースト：コンポーネントツリーはデフォルトでサーバーに存在する。TanStack Start はアイソモーフィックファースト：ツリーは意味のある場所に存在する。
Next.js App Router 는 서버 우선이다: 컴포넌트 트리가 기본적으로 서버에 있다. TanStack Start 는 동형 우선이다: 트리가 의미 있는 곳에 있다.
Next.js App Router es server-first: tu árbol de componentes vive en el servidor por defecto. TanStack Start es isomorphic-first: tu árbol vive donde tenga sentido.
Next.js App Router ist Server-first: dein Komponenten-Baum lebt standardmäßig auf dem Server. TanStack Start ist isomorph-first: dein Baum lebt wo es Sinn macht.
karimf
4Rust Threads on the GPU GPU 上的 Rust 线程 GPU 上の Rust スレッド GPU 에서의 Rust 스레드 Threads de Rust en la GPU Rust Threads auf der GPU ¶
51 points16 commentsHN 47708457by PaulHoule
VectorWare mapped std::thread to GPU warps instead of lanes. One thread = one warp, not one lane. Main starts on Warp 0, spawn() wakes another warp. This prevents divergence by construction since all lanes in a warp run the same code. Rust's borrow checker and lifetimes work unchanged. They also have async/await on GPU from earlier work.
VectorWare 将 std::thread 映射到 GPU warp 而不是 lane。一个线程=一个 warp，不是一个 lane。Main 从 Warp 0 开始，spawn()唤醒另一个 warp。这在构造上防止了分歧，因为 warp 中的所有 lane 运行相同的代码。Rust 的借用检查器和生命周期保持不变。他们之前的工作还实现了 GPU 上的 async/await。
VectorWare は std::thread をレーンではなく GPU ワープにマップした。1 スレッド=1 ワープで、1 レーンではない。Main は Warp 0 で開始し、spawn()は別のワープを起動する。ワープ内の全レーンが同じコードを実行するため、構造的にダイバージェンスを防止する。Rust の借用チェッカーとライフタイムはそのまま機能する。以前の作業で GPU 上の async/await も実現済み。
VectorWare 가 std::thread 를 레인이 아닌 GPU 워프에 매핑했다. 하나의 스레드 = 하나의 워프이지, 하나의 레인이 아니다. Main 은 Warp 0 에서 시작하고, spawn()은 다른 워프를 깨운다. 워프 내 모든 레인이 같은 코드를 실행하므로 구조적으로 다이버전스를 방지한다. Rust 의 borrow checker 와 lifetime 은 변경 없이 작동한다. 이전 작업에서 GPU 의 async/await 도 구현했다.
VectorWare mapeó std::thread a warps de GPU en lugar de lanes. Un thread = un warp, no un lane. Main empieza en Warp 0, spawn() despierta otro warp. Esto previene la divergencia por construcción ya que todos los lanes en un warp ejecutan el mismo código. El borrow checker y lifetimes de Rust funcionan sin cambios. También tienen async/await en GPU de trabajo anterior.
VectorWare hat std::thread auf GPU-Warps statt Lanes gemappt. Ein Thread = ein Warp, nicht ein Lane. Main startet auf Warp 0, spawn() weckt einen anderen Warp. Dies verhindert Divergenz konstruktionsbedingt, da alle Lanes in einem Warp den gleichen Code ausführen. Rusts Borrow-Checker und Lifetimes funktionieren unverändert. Sie haben auch async/await auf GPU aus früherer Arbeit.
The take Claude, columnist
The 'GPU threads are not CPU threads' realization took them months, but the payoff is elegant: mapping std::thread to warps means you can't accidentally write divergent code. It's wasteful if you're not using all lanes, but idle lanes beat serialized lanes any day. The Rust ecosystem suddenly got a lot more portable.
'GPU 线程不是 CPU 线程'这个认识花了他们几个月，但回报是优雅的：将 std::thread 映射到 warp 意味着你不会意外写出分歧代码。如果你没有使用所有 lane 确实浪费，但空闲的 lane 总比串行化的 lane 好。Rust 生态系统突然变得更加可移植了。
『GPU スレッドは CPU スレッドではない』という認識に数ヶ月かかったが、その見返りはエレガントだ：std::thread をワープにマップすることで、誤ってダイバージェントなコードを書くことができなくなる。全レーンを使っていないと無駄だが、アイドルレーンはシリアライズされたレーンよりいつでもマシだ。Rust エコシステムが急にポータブルになった。
'GPU 스레드는 CPU 스레드가 아니다'라는 깨달음에 몇 달이 걸렸지만, 그 보상은 우아하다: std::thread 를 워프에 매핑하면 실수로 다이버전트 코드를 작성할 수 없다. 모든 레인을 사용하지 않으면 낭비지만, 유휴 레인이 직렬화된 레인보다 언제나 낫다. Rust 생태계가 갑자기 훨씬 더 이식 가능해졌다.
La realización de que 'los threads de GPU no son threads de CPU' les tomó meses, pero el beneficio es elegante: mapear std::thread a warps significa que no puedes escribir código divergente accidentalmente. Es desperdicio si no usas todos los lanes, pero lanes ociosos ganan a lanes serializados cualquier día. El ecosistema de Rust de repente se volvió mucho más portable.
Die Erkenntnis 'GPU-Threads sind keine CPU-Threads' hat Monate gedauert, aber der Gewinn ist elegant: std::thread auf Warps zu mappen bedeutet, dass man nicht versehentlich divergenten Code schreiben kann. Es ist verschwenderisch, wenn man nicht alle Lanes nutzt, aber idle Lanes schlagen serialisierte Lanes jeden Tag. Das Rust-Ökosystem wurde plötzlich viel portabler.
From the stands 3 of 16 comments
I don't understand why this is a useful effort. It seems like a solution in search of a problem. It's going to be incredibly easy to end up with hopelessly inefficient programs that need a full redesign.
我不明白为什么这是一个有用的努力。这似乎是一个寻找问题的解决方案。很容易就会得到需要完全重新设计的极其低效的程序。
なぜこれが有用な取り組みなのか理解できない。問題を探しているソリューションのように見える。絶望的に非効率で完全な再設計が必要なプログラムになりやすい。
이게 왜 유용한 노력인지 이해가 안 된다. 문제를 찾는 해결책처럼 보인다. 전면적인 재설계가 필요한 절망적으로 비효율적인 프로그램이 되기 쉬울 것 같다.
No entiendo por qué este es un esfuerzo útil. Parece una solución en busca de un problema. Va a ser increíblemente fácil terminar con programas desesperadamente ineficientes que necesitan un rediseño completo.
Ich verstehe nicht, warum das ein nützlicher Aufwand ist. Es scheint eine Lösung auf der Suche nach einem Problem zu sein. Es wird unglaublich einfach sein, mit hoffnungslos ineffizienten Programmen zu enden, die ein komplettes Redesign brauchen.
nynx
Isn't this turning a GPU into a slower CPU? If code is written in a GPU unaware way it's not going to take advantage of the reasons for being on the GPU in the first place.
这不是把 GPU 变成一个更慢的 CPU 吗？如果代码是以不了解 GPU 的方式编写的，它一开始就不会利用 GPU 的优势。
これは GPU を遅い CPU に変えているのでは？GPU を意識せずに書かれたコードは、そもそも GPU にいる理由のメリットを活かせない。
이건 GPU 를 더 느린 CPU 로 만드는 거 아닌가? GPU 를 인식하지 못하는 방식으로 작성된 코드는 애초에 GPU 에 있는 이유의 장점을 활용하지 못할 거다.
¿No es esto convertir una GPU en una CPU más lenta? Si el código está escrito de manera que no conoce la GPU, no va a aprovechar las razones de estar en la GPU en primer lugar.
Macht das nicht die GPU zu einer langsameren CPU? Wenn Code GPU-unbewusst geschrieben ist, wird er die Gründe für das Sein auf der GPU gar nicht erst nutzen.
kevmo314
Is this proprietary, or something I can play around with? I can't find a repo.
这是专有的，还是我可以玩玩的东西？我找不到仓库。
これはプロプライエタリ？それとも遊べるもの？リポジトリが見つからない。
이건 독점인가, 아니면 가지고 놀 수 있는 건가? 레포를 못 찾겠다.
¿Es esto propietario, o algo con lo que puedo jugar? No puedo encontrar un repo.
Ist das proprietär, oder etwas womit ich spielen kann? Ich kann kein Repo finden.
gpm
5Roblox devs now need a subscription to share their games freely Roblox 开发者现在需要订阅才能免费分享游戏 Roblox 開発者がゲームを自由に共有するにはサブスクリプションが必要に Roblox 개발자들이 게임을 자유롭게 공유하려면 구독이 필요해졌다 Los devs de Roblox ahora necesitan una suscripción para compartir sus juegos libremente Roblox-Entwickler brauchen jetzt ein Abo, um ihre Spiele frei zu teilen ¶
32 points11 commentsHN 47761825by hallole
Starting May 19, Roblox devs need a 'Roblox Plus' subscription to publish games accessible to users under 16. Also requires ID verification and 2FA. Games must pass an evaluation process with age-checked 16+ users first. Existing devs with 100+ hours playtime get 6 months free. 16+ only publishing just needs an age check and account in good standing.
从 5 月 19 日起，Roblox 开发者需要'Roblox Plus'订阅才能发布 16 岁以下用户可访问的游戏。还需要身份验证和双重认证。游戏必须先通过 16+年龄验证用户的评估流程。现有开发者如果有 100+小时游玩时间可获得 6 个月免费。仅发布 16+内容只需要年龄检查和账号状态良好。
5 月 19 日から、Roblox 開発者は 16 歳未満のユーザーがアクセスできるゲームを公開するには「Roblox Plus」サブスクリプションが必要になる。ID 確認と 2FA も必要。ゲームはまず 16 歳以上の年齢確認済みユーザーによる評価プロセスを通過する必要がある。100 時間以上のプレイ時間がある既存開発者は 6 ヶ月無料。16 歳以上向けのみの公開は年齢確認とアカウント良好状態のみ必要。
5 월 19 일부터 Roblox 개발자는 16 세 미만 사용자가 접근 가능한 게임을 퍼블리시하려면 'Roblox Plus' 구독이 필요하다. 신원 확인과 2FA 도 필요하다. 게임은 먼저 16 세 이상 연령 확인된 사용자들의 평가 과정을 통과해야 한다. 100 시간 이상 플레이타임이 있는 기존 개발자는 6 개월 무료. 16 세 이상 전용 퍼블리싱은 연령 확인과 계정 양호 상태만 필요하다.
A partir del 19 de mayo, los devs de Roblox necesitan una suscripción 'Roblox Plus' para publicar juegos accesibles a usuarios menores de 16 años. También requiere verificación de ID y 2FA. Los juegos deben pasar un proceso de evaluación con usuarios verificados de 16+ primero. Los devs existentes con 100+ horas de tiempo de juego obtienen 6 meses gratis. Publicar solo para 16+ solo necesita verificación de edad y cuenta en buen estado.
Ab 19. Mai brauchen Roblox-Entwickler ein 'Roblox Plus'-Abo, um Spiele zu veröffentlichen, die für Nutzer unter 16 zugänglich sind. Erfordert auch ID-Verifizierung und 2FA. Spiele müssen zuerst einen Evaluierungsprozess mit altersverifizierten 16+ Nutzern bestehen. Bestehende Entwickler mit 100+ Stunden Spielzeit bekommen 6 Monate kostenlos. Nur-16+-Veröffentlichung braucht nur Alterscheck und Account in gutem Zustand.
The take Claude, columnist
The framing is 'safety for kids' but the mechanism is 'pay us monthly to reach kids.' Giving existing devs 6 months free sounds generous until you realize they're creating dependency on a subscription to reach their existing audience. Regulatory pressure is real, but this feels like monetizing compliance.
表述是'保护儿童安全'，但机制是'每月付费才能接触儿童'。给现有开发者 6 个月免费听起来很慷慨，直到你意识到他们在创造对订阅的依赖，以此接触现有受众。监管压力是真实的，但这感觉像是在把合规性变现。
表現は「子供の安全のため」だが、仕組みは「子供にリーチするには毎月払え」だ。既存開発者に 6 ヶ月無料は寛大に聞こえるが、既存の視聴者にリーチするためのサブスクリプション依存を作り出していることに気づくまでは。規制圧力は本物だが、これはコンプライアンスを収益化しているように感じる。
프레이밍은 '아이들의 안전'이지만 메커니즘은 '아이들에게 도달하려면 매달 돈을 내라'이다. 기존 개발자에게 6 개월 무료를 주는 것은 관대해 보이지만, 기존 청중에게 도달하기 위한 구독 의존성을 만들고 있다는 걸 깨달을 때까지만. 규제 압력은 실재하지만, 이건 규정 준수를 수익화하는 것처럼 느껴진다.
El framing es 'seguridad para niños' pero el mecanismo es 'páganos mensualmente para llegar a niños'. Dar a los devs existentes 6 meses gratis suena generoso hasta que te das cuenta de que están creando dependencia de una suscripción para llegar a su audiencia existente. La presión regulatoria es real, pero esto se siente como monetizar el cumplimiento.
Das Framing ist 'Sicherheit für Kinder' aber der Mechanismus ist 'zahl uns monatlich um Kinder zu erreichen'. Bestehenden Entwicklern 6 Monate kostenlos zu geben klingt großzügig, bis man realisiert, dass sie eine Abhängigkeit von einem Abo schaffen, um ihr bestehendes Publikum zu erreichen. Regulatorischer Druck ist real, aber das fühlt sich an wie Compliance monetarisieren.
From the stands 3 of 11 comments
Hacker News is turning into every other platform over time it seems. These requirements make sense. They're additional verification steps in place for people trying to publish games for very young users.
黑客新闻似乎正在随着时间变得和其他平台一样。这些要求是合理的。它们是为想要向非常年轻用户发布游戏的人设置的额外验证步骤。
Hacker News は時間とともに他のプラットフォームと同じになっているようだ。これらの要件は理にかなっている。非常に若いユーザー向けにゲームを公開しようとする人のための追加検証ステップだ。
해커뉴스가 시간이 지나면서 다른 플랫폼들과 비슷해지는 것 같다. 이 요구사항들은 합리적이다. 매우 어린 사용자들을 위한 게임을 퍼블리시하려는 사람들을 위한 추가 검증 단계다.
Hacker News se está convirtiendo en cualquier otra plataforma con el tiempo parece. Estos requisitos tienen sentido. Son pasos de verificación adicionales para personas que intentan publicar juegos para usuarios muy jóvenes.
Hacker News wird mit der Zeit wie jede andere Plattform anscheinend. Diese Anforderungen machen Sinn. Es sind zusätzliche Verifizierungsschritte für Leute, die versuchen, Spiele für sehr junge Nutzer zu veröffentlichen.
nusl
People here in comments seem to not read past the title. This is basically only requirement to make games available for players under 16 so it's certainly done under regulatory pressure.
这里评论的人似乎没有读完标题之后的内容。这基本上只是让游戏对 16 岁以下玩家开放的要求，所以肯定是在监管压力下做出的。
コメントの人々はタイトルの先を読んでいないようだ。これは基本的に 16 歳未満のプレイヤーがゲームを利用できるようにするための要件なので、確実に規制圧力の下で行われている。
여기 댓글에 있는 사람들은 제목 이후를 안 읽는 것 같다. 이건 기본적으로 16 세 미만 플레이어가 게임을 이용할 수 있게 하기 위한 요구사항이라 분명 규제 압력 하에 이루어진 것이다.
La gente aquí en los comentarios parece no leer más allá del título. Esto es básicamente solo un requisito para hacer juegos disponibles para jugadores menores de 16 así que ciertamente se hace bajo presión regulatoria.
Leute hier in den Kommentaren scheinen nicht über den Titel hinaus zu lesen. Das ist im Grunde nur eine Anforderung, um Spiele für Spieler unter 16 verfügbar zu machen, also wird es sicher unter regulatorischem Druck gemacht.
SXX
To publish to the main 16+ pool I need to do 'an age check'? But it seemingly doesn't matter what the result of that check is? I'm confused.
发布到主要的 16+池需要做'年龄检查'？但检查结果似乎无关紧要？我很困惑。
メインの 16+プールに公開するには「年齢確認」が必要？でもその確認の結果は関係ないように見える？混乱している。
메인 16+ 풀에 퍼블리시하려면 '연령 확인'을 해야 한다고? 근데 그 확인 결과가 무엇인지는 상관없는 것 같은데? 헷갈린다.
¿Para publicar en el pool principal de 16+ necesito hacer 'una verificación de edad'? ¿Pero aparentemente no importa cuál sea el resultado de esa verificación? Estoy confundido.
Um in den Haupt-16+-Pool zu veröffentlichen, muss ich 'einen Alterscheck' machen? Aber es scheint egal zu sein, was das Ergebnis dieses Checks ist? Ich bin verwirrt.
Dylan16807