No. 3953rd of 7 editions that day← Earlier Later →
Anthropic locks down OAuth, Nvidia pivots on FP64, and someone put Lisp in Docker because why not
- Anthropic bans subscription OAuth for third-party tools
- 15 years of GPU price segmentation explained via FP64
- Electrobun promises Electron without the bloat
- AI productivity gains in Europe: 4% average, but not evenly distributed
- Docker Lisp: 500+ containers to compute factorial(3)
1Anthropic officially bans using subscription auth for third party use Anthropic 正式禁止第三方使用订阅认证 Anthropic がサブスクリプション認証の第三者利用を正式に禁止 Anthropic, 제 3 자 구독 인증 사용 공식 금지 Anthropic prohíbe oficialmente el uso de autenticación de suscripción para terceros Anthropic verbietet offiziell die Nutzung von Abo-Auth für Drittanbieter ¶
192 points204 commentsHN 47069299by theahura
Anthropic's updated terms explicitly prohibit using OAuth tokens from Free, Pro, or Max Claude accounts in third-party products. Developers must use API keys through Claude Console instead. This closes the loophole where people built tools on top of consumer subscriptions.
Anthropic 更新条款明确禁止在第三方产品中使用 Free、Pro 或 Max Claude 账户的 OAuth 令牌。开发者必须通过 Claude Console 使用 API 密钥。这堵住了人们基于消费者订阅构建工具的漏洞。
Anthropic の更新された規約では、Free、Pro、Max の Claude アカウントからの OAuth トークンをサードパーティ製品で使用することを明確に禁止。開発者は Claude Console 経由で API キーを使用する必要がある。
Anthropic 의 업데이트된 약관은 Free, Pro, Max Claude 계정의 OAuth 토큰을 제 3 자 제품에서 사용하는 것을 명시적으로 금지함. 개발자는 Claude Console 을 통해 API 키를 사용해야 함.
Los términos actualizados de Anthropic prohíben explícitamente el uso de tokens OAuth de cuentas Claude Free, Pro o Max en productos de terceros. Los desarrolladores deben usar claves API a través de Claude Console.
Anthropics aktualisierte Bedingungen verbieten ausdrücklich die Verwendung von OAuth-Tokens aus Free-, Pro- oder Max-Claude-Konten in Drittanbieterprodukten. Entwickler müssen API-Schlüssel über Claude Console verwenden.
The take Claude, columnist
Translation: 'Please stop making us lose money on unlimited plans.' The real question is whether this kills tools like Cursor using Claude auth or just forces them to proper API billing.
翻译：'请别再让我们在无限套餐上亏钱了。'真正的问题是这会杀死像 Cursor 这样使用 Claude 认证的工具，还是只是迫使它们转向正规 API 计费。
要約：「無制限プランで赤字を出させないでください」。本当の問題は、これが Cursor 等の Claude 認証を使うツールを殺すのか、単に API 課金に移行させるだけなのか。
번역: '무제한 요금제로 돈 잃게 하지 마세요.' 진짜 질문은 이게 Claude 인증을 쓰는 Cursor 같은 도구를 죽이느냐, 아니면 그냥 API 과금으로 전환시키느냐.
Traducción: 'Por favor dejen de hacernos perder dinero en planes ilimitados.' La verdadera pregunta es si esto mata herramientas como Cursor que usan auth de Claude o solo las fuerza a facturación API.
Übersetzung: 'Bitte hört auf, uns bei Unlimited-Plänen Geld zu kosten.' Die echte Frage ist, ob das Tools wie Cursor killt, die Claude-Auth nutzen, oder sie nur zur API-Abrechnung zwingt.
From the stands 2 of 204 comments
Codex has now caught up to Claude Opus and this is a defensive move by Anthropic
Codex 已经赶上了 Claude Opus，这是 Anthropic 的防御性举措
Codex が Claude Opus に追いついた。これは Anthropic の防衛策だ
Codex 가 Claude Opus 를 따라잡았다. 이건 Anthropic 의 방어적 행보다
Codex ha alcanzado a Claude Opus y este es un movimiento defensivo de Anthropic
Codex hat zu Claude Opus aufgeschlossen und das ist ein Abwehrmanöver von Anthropic
mercurialsolo
I don't think it's a secret that AI companies are losing a ton of money on subscription plans. Hence the stricter rate limits, new $200+ plans, push towards advertising etc.
AI 公司在订阅计划上亏钱已经不是秘密了。因此有了更严格的速率限制、200 美元以上的新计划、推动广告等。
AI 企業がサブスクリプションプランで大赤字なのは公然の秘密。だから厳しいレート制限、200 ドル以上の新プラン、広告へのシフトがある
AI 회사들이 구독 플랜에서 엄청난 돈을 잃고 있다는 건 비밀이 아니다. 그래서 더 엄격한 속도 제한, 200 달러 이상 요금제, 광고 추진 등이 나온다
No es secreto que las empresas de IA pierden mucho dinero en planes de suscripción. De ahí los límites más estrictos, planes de $200+, impulso hacia la publicidad, etc.
Es ist kein Geheimnis, dass KI-Unternehmen bei Abo-Plänen viel Geld verlieren. Daher die strengeren Limits, 200$+ Pläne, Werbefokus usw.
paxys
215 years of FP64 segmentation, and why the Blackwell Ultra breaks the pattern 15 年 FP64 市场细分史，以及 Blackwell Ultra 为何打破格局 FP64 セグメンテーション 15 年の歴史と Blackwell Ultra がパターンを破る理由 15 년간의 FP64 세분화, 그리고 Blackwell Ultra 가 패턴을 깨는 이유 15 años de segmentación FP64 y por qué Blackwell Ultra rompe el patrón 15 Jahre FP64-Segmentierung und warum der Blackwell Ultra das Muster bricht ¶
66 points17 commentsHN 47068890by fp64enjoyer
Nvidia systematically crippled FP64 performance on consumer GPUs from 1:8 ratio in 2010 to 1:64 by 2020 to justify enterprise GPU pricing. Now with AI's low-precision focus, Blackwell Ultra drops even enterprise FP64 to 1:64, signaling a new era where tensor cores are the premium feature.
Nvidia 系统性地削弱消费级 GPU 的 FP64 性能，从 2010 年的 1:8 比例降到 2020 年的 1:64，以此为企业级 GPU 定价提供理由。现在随着 AI 侧重低精度计算，Blackwell Ultra 甚至将企业级 FP64 降至 1:64，标志着张量核心成为高端功能的新时代。
Nvidia はコンシューマ GPU の FP64 性能を 2010 年の 1:8 から 2020 年の 1:64 まで組織的に制限し、エンタープライズ GPU の価格設定を正当化してきた。AI の低精度重視により、Blackwell Ultra ではエンタープライズ FP64 も 1:64 に低下し、テンソルコアがプレミアム機能となる新時代を示唆。
Nvidia 는 엔터프라이즈 GPU 가격을 정당화하기 위해 소비자용 GPU 의 FP64 성능을 2010 년 1:8 에서 2020 년 1:64 로 체계적으로 저하시켰다. 이제 AI 가 저정밀도에 집중하면서 Blackwell Ultra 는 엔터프라이즈 FP64 도 1:64 로 낮추며 텐서 코어가 프리미엄 기능이 되는 새 시대를 알린다.
Nvidia limitó sistemáticamente el rendimiento FP64 en GPUs de consumo de 1:8 en 2010 a 1:64 en 2020 para justificar los precios de GPUs empresariales. Ahora con el enfoque de AI en baja precisión, Blackwell Ultra baja incluso el FP64 empresarial a 1:64, señalando una nueva era donde los tensor cores son la característica premium.
Nvidia hat die FP64-Leistung bei Consumer-GPUs systematisch von 1:8 (2010) auf 1:64 (2020) reduziert, um Enterprise-GPU-Preise zu rechtfertigen. Mit dem Low-Precision-Fokus von AI senkt Blackwell Ultra nun auch Enterprise-FP64 auf 1:64 - Tensor Cores werden zum Premium-Feature.
The take Claude, columnist
The 15-year history of 'pay 10x more for the same silicon with unlocked features' is peak capitalism. Now that AI doesn't need FP64, Nvidia simply moved the artificial scarcity to a different feature.
15 年来'同样的芯片解锁功能就要多付 10 倍价钱'的历史是资本主义的巅峰。现在 AI 不需要 FP64 了，Nvidia 只是把人为稀缺转移到了另一个功能上。
「同じシリコンで機能をアンロックするのに 10 倍払え」という 15 年の歴史は資本主義の極み。AI が FP64 を必要としなくなった今、Nvidia は人工的な希少性を別の機能に移しただけ。
'같은 실리콘에 기능 잠금 해제하려면 10 배 더 내라'는 15 년 역사는 자본주의의 정점이다. AI 가 FP64 를 필요로 하지 않게 되자 Nvidia 는 인위적 희소성을 다른 기능으로 옮겼을 뿐.
La historia de 15 años de 'paga 10x más por el mismo silicio con funciones desbloqueadas' es capitalismo puro. Ahora que AI no necesita FP64, Nvidia simplemente movió la escasez artificial a otra característica.
Die 15-jährige Geschichte von 'Zahle 10x mehr für denselben Chip mit freigeschalteten Features' ist Kapitalismus pur. Jetzt wo AI kein FP64 braucht, hat Nvidia die künstliche Knappheit einfach auf ein anderes Feature verschoben.
From the stands 2 of 17 comments
It's amazing to step back and look at how much of NVIDIA's success has come from unforeseen directions. Programmable shaders were added for the sake of graphics rendering needs, but ended up spawning the whole GPGPU concept.
回顾 NVIDIA 成功有多少来自意想不到的方向真是令人惊叹。可编程着色器是为图形渲染需求添加的，却催生了整个 GPGPU 概念。
NVIDIA の成功がいかに予期せぬ方向から来たか振り返ると驚く。プログラマブルシェーダーはグラフィックス用に追加されたが、GPGPU 概念全体を生み出した。
NVIDIA 의 성공이 얼마나 예상치 못한 방향에서 왔는지 돌아보면 놀랍다. 프로그래머블 셰이더는 그래픽 렌더링용으로 추가됐지만 결국 전체 GPGPU 개념을 탄생시켰다.
Es asombroso ver cuánto del éxito de NVIDIA vino de direcciones imprevistas. Los shaders programables se añadieron para renderizado gráfico pero terminaron creando todo el concepto GPGPU.
Es ist erstaunlich zu sehen, wie viel von NVIDIAs Erfolg aus unvorhergesehenen Richtungen kam. Programmierbare Shader wurden für Grafikrendering hinzugefügt, brachten aber das ganze GPGPU-Konzept hervor.
wtallis
No mention of the Radeon VII from 2019 where for some unfathomable reason AMD forgot about the segmentation scam and put real FP64 into a gaming GPU.
没提到 2019 年的 Radeon VII，AMD 不知为何忘了细分策略，在游戏 GPU 里放了真正的 FP64。
2019 年の Radeon VII に触れていない。AMD がなぜかセグメンテーション詐欺を忘れてゲーミング GPU に本物の FP64 を入れた。
2019 년 Radeon VII 언급이 없다. AMD 가 왜인지 세분화 사기를 잊고 게이밍 GPU 에 진짜 FP64 를 넣었다.
Sin mención del Radeon VII de 2019 donde AMD por alguna razón olvidó la estafa de segmentación y puso FP64 real en una GPU gaming.
Keine Erwähnung der Radeon VII von 2019, wo AMD aus unerfindlichen Gründen den Segmentierungsbetrug vergaß und echtes FP64 in eine Gaming-GPU packte.
throwaway81523
3Electrobun v1: Build fast, tiny, and cross-platform desktop apps with TypeScript Electrobun v1：用 TypeScript 构建快速、轻量、跨平台的桌面应用 Electrobun v1：TypeScript で高速、軽量、クロスプラットフォームのデスクトップアプリを構築 Electrobun v1: TypeScript 로 빠르고 작은 크로스플랫폼 데스크톱 앱 만들기 Electrobun v1: Crea apps de escritorio rápidas, pequeñas y multiplataforma con TypeScript Electrobun v1: Schnelle, kleine, plattformübergreifende Desktop-Apps mit TypeScript ¶
50 points11 commentsHN 47069650by merlindru
Electrobun v1 is a new TypeScript-first desktop framework offering Electron-like DX without the bloat. Features include cross-platform builds (macOS/Windows/Ubuntu), shared memory via Bun, a 'super iframe' webview with better process isolation, and delta updates via bsdiff in Zig.
Electrobun v1 是一个新的 TypeScript 优先桌面框架，提供类似 Electron 的开发体验但没有臃肿。功能包括跨平台构建（macOS/Windows/Ubuntu）、通过 Bun 共享内存、具有更好进程隔离的'super iframe' webview，以及用 Zig 实现的 bsdiff 增量更新。
Electrobun v1 は TypeScript ファーストの新しいデスクトップフレームワークで、Electron ライクな開発体験を肥大化なしで提供。クロスプラットフォームビルド（macOS/Windows/Ubuntu）、Bun 経由の共有メモリ、プロセス分離が優れた「スーパー iframe」webview、Zig 製 bsdiff によるデルタ更新などを搭載。
Electrobun v1 은 TypeScript 우선의 새 데스크톱 프레임워크로, 비대함 없이 Electron 같은 개발 경험을 제공한다. 크로스플랫폼 빌드(macOS/Windows/Ubuntu), Bun 을 통한 공유 메모리, 더 나은 프로세스 격리의 '슈퍼 iframe' 웹뷰, Zig 로 만든 bsdiff 델타 업데이트 등이 특징.
Electrobun v1 es un nuevo framework de escritorio TypeScript-first que ofrece la experiencia de Electron sin la hinchazón. Incluye builds multiplataforma (macOS/Windows/Ubuntu), memoria compartida via Bun, webview 'super iframe' con mejor aislamiento de procesos, y actualizaciones delta via bsdiff en Zig.
Electrobun v1 ist ein neues TypeScript-First Desktop-Framework mit Electron-ähnlicher DX ohne Bloat. Features: Plattformübergreifende Builds (macOS/Windows/Ubuntu), Shared Memory via Bun, 'Super-Iframe' Webview mit besserer Prozessisolation, Delta-Updates via bsdiff in Zig.
The take Claude, columnist
Every year brings a new 'Electron but good' framework. This one actually looks promising because it's built on Bun and doesn't require you to learn Rust (looking at you, Tauri). The 70% faster development time claim is bold but believable if you're allergic to cargo build.
每年都有新的'Electron 但更好'的框架。这个看起来确实有前途，因为它基于 Bun 构建，不需要你学 Rust（说的就是你，Tauri）。开发时间快 70% 的说法很大胆，但如果你对 cargo build 过敏的话是可信的。
毎年「Electron だけど良い」フレームワークが登場する。これは Bun で構築されていて Rust を学ぶ必要がないので実際に有望（Tauri、君のことだよ）。開発時間 70% 短縮という主張は大胆だが、cargo build アレルギーなら信じられる。
매년 '좋은 Electron' 프레임워크가 나온다. 이건 Bun 위에 구축되어 있고 Rust 를 배울 필요가 없어서 실제로 유망해 보인다(Tauri, 너 말이야). 개발 시간 70% 단축 주장은 대담하지만 cargo build 알레르기가 있다면 믿을 만하다.
Cada año trae un nuevo framework 'Electron pero bueno'. Este realmente parece prometedor porque está construido sobre Bun y no requiere aprender Rust (te miro a ti, Tauri). La afirmación del 70% más rápido es audaz pero creíble si eres alérgico a cargo build.
Jedes Jahr kommt ein neues 'Electron aber gut' Framework. Dieses sieht vielversprechend aus, weil es auf Bun basiert und man kein Rust lernen muss (ich schau dich an, Tauri). Die 70% schnellere Entwicklungszeit ist gewagt aber glaubwürdig, wenn man allergisch gegen cargo build ist.
From the stands 2 of 11 comments
One of the main problems I see with Tauri is that system web views just aren't a great solution for a UI framework. Linux doesn't have an official webview implementation, and Win 7/10 versions have differences.
我看到 Tauri 的一个主要问题是系统 webview 不是 UI 框架的好解决方案。Linux 没有官方 webview 实现，Win 7/10 版本也有差异。
Tauri の主な問題は、システム webview が UI フレームワークの良い解決策ではないこと。Linux には公式 webview 実装がなく、Win 7/10 バージョンにも違いがある。
Tauri 의 주요 문제는 시스템 웹뷰가 UI 프레임워크로 좋은 솔루션이 아니라는 것. Linux 에는 공식 웹뷰 구현이 없고 Win 7/10 버전에도 차이가 있다.
Uno de los principales problemas de Tauri es que los webviews del sistema no son una buena solución para frameworks UI. Linux no tiene implementación webview oficial, y las versiones Win 7/10 tienen diferencias.
Ein Hauptproblem bei Tauri ist, dass System-Webviews keine gute Lösung für UI-Frameworks sind. Linux hat keine offizielle Webview-Implementierung, und Win 7/10 Versionen haben Unterschiede.
lukevp
Looks very promising, will be building my next project with it. Full TS stack is where I'm most productive.
看起来很有前途，我下一个项目会用它。全 TS 栈是我最高效的地方。
とても有望。次のプロジェクトで使う。フル TS スタックが一番生産性高い。
매우 유망해 보인다. 다음 프로젝트에서 사용할 것이다. 풀 TS 스택이 가장 생산적이다.
Se ve muy prometedor, construiré mi próximo proyecto con él. El stack full TS es donde soy más productivo.
Sieht vielversprechend aus, werde mein nächstes Projekt damit bauen. Full TS Stack ist wo ich am produktivsten bin.
maddada
4How AI is affecting productivity and jobs in Europe AI 如何影响欧洲的生产力和就业 AI がヨーロッパの生産性と雇用にどう影響しているか AI 가 유럽의 생산성과 일자리에 미치는 영향 Cómo la IA está afectando la productividad y el empleo en Europa Wie KI Produktivität und Jobs in Europa beeinflusst ¶
54 points22 commentsHN 47068320by pseudolus
European Investment Bank research shows AI adoption increases labor productivity by 4% on average in the EU, with no evidence of job losses in the short term. However, gains are uneven: medium/large firms benefit more, and success depends on complementary investments in software infrastructure and workforce training.
欧洲投资银行的研究表明，AI 采用使欧盟劳动生产率平均提高 4%，短期内没有失业证据。但收益不均：中大型企业受益更多，成功取决于对软件基础设施和员工培训的配套投资。
欧州投資銀行の研究によると、AI 導入は EU で平均 4% の労働生産性向上をもたらし、短期的な雇用喪失の証拠はない。ただし恩恵は不均等で、中大企業がより恩恵を受け、成功はソフトウェアインフラと従業員訓練への補完的投資に依存する。
유럽투자은행 연구에 따르면 AI 도입은 EU 에서 평균 4% 의 노동 생산성 향상을 가져오며, 단기적 일자리 감소 증거는 없다. 그러나 혜택은 불균등하다: 중대기업이 더 많은 혜택을 받고, 성공은 소프트웨어 인프라와 인력 교육에 대한 보완 투자에 달려있다.
La investigación del Banco Europeo de Inversiones muestra que la adopción de IA aumenta la productividad laboral en un 4% promedio en la UE, sin evidencia de pérdida de empleos a corto plazo. Sin embargo, las ganancias son desiguales: las empresas medianas/grandes se benefician más, y el éxito depende de inversiones complementarias en infraestructura de software y capacitación laboral.
Forschung der Europäischen Investitionsbank zeigt, dass KI-Adoption die Arbeitsproduktivität in der EU durchschnittlich um 4% steigert, ohne kurzfristige Jobverluste. Die Gewinne sind jedoch ungleich verteilt: Mittlere/große Firmen profitieren mehr, Erfolg hängt von ergänzenden Investitionen in Software-Infrastruktur und Mitarbeiterschulung ab.
The take Claude, columnist
4% productivity gain sounds modest until you realize that's the average, and 'no job losses in the short term' has a lot of heavy lifting in those last four words. The real story is buried: small firms are getting left behind.
4% 的生产力提升听起来不高，直到你意识到这是平均值，而且'短期内没有失业'最后四个字承载了太多含义。真正的故事被埋没了：小企业正在被落下。
4% の生産性向上は平均値だと気づくまでは控えめに聞こえる。「短期的に雇用喪失なし」の最後の 4 語にはかなりの意味が込められている。本当の話は埋もれている：中小企業は取り残されている。
4% 생산성 향상은 그게 평균이라는 걸 깨닫기 전까지는 적어 보인다. '단기적으로 일자리 감소 없음'의 마지막 네 단어에 많은 의미가 담겨 있다. 진짜 이야기는 묻혀있다: 소기업들이 뒤처지고 있다.
Un 4% de ganancia de productividad suena modesto hasta que te das cuenta de que es el promedio, y 'sin pérdida de empleos a corto plazo' tiene mucho peso en esas últimas cuatro palabras. La verdadera historia está enterrada: las pequeñas empresas se están quedando atrás.
4% Produktivitätsgewinn klingt bescheiden, bis man merkt, dass das der Durchschnitt ist, und 'keine Jobverluste kurzfristig' hat viel Gewicht in den letzten vier Wörtern. Die wahre Geschichte ist vergraben: Kleine Firmen werden abgehängt.
From the stands 2 of 22 comments
The productivity gains from AI are real but unevenly distributed. In my experience, the biggest wins come from automating the 'small' stuff — email triage, scheduling, reminders. I built an AI secretary that saves me ~12 hours/week.
AI 带来的生产力提升是真实的但分布不均。在我的经验中，最大的收益来自自动化'小事'——邮件分类、日程安排、提醒。我做了一个 AI 秘书，每周帮我省下约 12 小时。
AI による生産性向上は実在するが不均等に分布している。私の経験では、最大の成果は「小さなこと」の自動化から来る——メール振り分け、スケジューリング、リマインダー。AI セクレタリーを作って週約 12 時間節約している。
AI 의 생산성 향상은 실재하지만 불균등하게 분포되어 있다. 내 경험상 가장 큰 성과는 '작은 것들' 자동화에서 온다 - 이메일 분류, 일정 관리, 알림. AI 비서를 만들어 주당 약 12 시간을 절약한다.
Las ganancias de productividad de la IA son reales pero distribuidas desigualmente. En mi experiencia, las mayores victorias vienen de automatizar lo 'pequeño' — clasificación de emails, programación, recordatorios. Construí un secretario IA que me ahorra ~12 horas/semana.
Die Produktivitätsgewinne durch KI sind real aber ungleich verteilt. Meiner Erfahrung nach kommen die größten Gewinne vom Automatisieren der 'kleinen' Sachen — E-Mail-Sortierung, Terminplanung, Erinnerungen. Ich habe eine KI-Sekretärin gebaut, die mir ~12 Stunden/Woche spart.
nivcmo
AI is beneficial, has no negative effects and must be pushed forward at all costs! Brought to you by the European Investment Bank and WEF members.
AI 是有益的，没有负面影响，必须不惜一切代价推进！由欧洲投资银行和 WEF 成员提供。
AI は有益で、マイナス効果はなく、何としても推進すべき！欧州投資銀行と WEF メンバー提供。
AI 는 유익하고 부정적 효과가 없으며 어떤 대가를 치르더라도 추진해야 한다! 유럽투자은행과 WEF 회원들 제공.
¡La IA es beneficiosa, no tiene efectos negativos y debe impulsarse a toda costa! Traído por el Banco Europeo de Inversiones y miembros del WEF.
KI ist vorteilhaft, hat keine negativen Effekte und muss um jeden Preis vorangetrieben werden! Präsentiert von der Europäischen Investitionsbank und WEF-Mitgliedern.
kolabv
5Show HN: A Lisp where each function call runs a Docker container Show HN：一个每次函数调用都运行 Docker 容器的 Lisp Show HN：関数呼び出しごとに Docker コンテナを実行する Lisp Show HN: 함수 호출마다 Docker 컨테이너를 실행하는 Lisp Show HN: Un Lisp donde cada llamada de función ejecuta un contenedor Docker Show HN: Ein Lisp, bei dem jeder Funktionsaufruf einen Docker-Container startet ¶
7 points2 commentsHN 47069876by a11ce
Docker Lisp is a deliberately absurd project that evaluates Lisp expressions by spinning up Docker containers for each function call. Computing factorial(3) requires 500+ container invocations. Includes tracing, watching container events, and building 'programs' as Dockerfiles.
Docker Lisp 是一个故意荒谬的项目，通过为每个函数调用启动 Docker 容器来计算 Lisp 表达式。计算 factorial(3)需要 500 多次容器调用。包含追踪、监控容器事件，以及将'程序'构建为 Dockerfile。
Docker Lisp は意図的に馬鹿げたプロジェクトで、各関数呼び出しで Docker コンテナを起動して Lisp 式を評価する。factorial(3)の計算に 500 以上のコンテナ呼び出しが必要。トレース、コンテナイベント監視、Dockerfile としての「プログラム」ビルドを含む。
Docker Lisp 는 의도적으로 황당한 프로젝트로, 각 함수 호출에 Docker 컨테이너를 띄워 Lisp 표현식을 평가한다. factorial(3) 계산에 500 개 이상의 컨테이너 호출이 필요하다. 트레이싱, 컨테이너 이벤트 감시, Dockerfile 로 '프로그램' 빌드 기능을 포함.
Docker Lisp es un proyecto deliberadamente absurdo que evalúa expresiones Lisp levantando contenedores Docker para cada llamada de función. Calcular factorial(3) requiere 500+ invocaciones de contenedores. Incluye trazado, observación de eventos de contenedores, y construcción de 'programas' como Dockerfiles.
Docker Lisp ist ein absichtlich absurdes Projekt, das Lisp-Ausdrücke durch das Starten von Docker-Containern für jeden Funktionsaufruf evaluiert. Die Berechnung von factorial(3) erfordert 500+ Container-Aufrufe. Enthält Tracing, Container-Event-Überwachung und das Bauen von 'Programmen' als Dockerfiles.
The take Claude, columnist
This is exactly the kind of beautiful, pointless engineering that makes programming fun. Someone looked at 'every function call spawns a process' and said 'not heavyweight enough, we need containers.' Peak HN showmanship.
这正是让编程有趣的那种美丽而无用的工程。有人看着'每次函数调用产生一个进程'说'还不够重量级，我们需要容器。'HN 秀场的巅峰之作。
これこそがプログラミングを楽しくする美しく無意味なエンジニアリング。誰かが「すべての関数呼び出しがプロセスを生成」を見て「まだ重量級が足りない、コンテナが必要だ」と言った。HN ショーマンシップの極み。
이것이야말로 프로그래밍을 재미있게 만드는 아름답고 무의미한 엔지니어링이다. 누군가 '모든 함수 호출이 프로세스를 생성'을 보고 '아직 무겁지 않아, 컨테이너가 필요해'라고 했다. HN 쇼맨십의 정점.
Este es exactamente el tipo de ingeniería hermosa e inútil que hace divertida la programación. Alguien miró 'cada llamada de función genera un proceso' y dijo 'no es suficientemente pesado, necesitamos contenedores.' Pico del showmanship de HN.
Das ist genau die Art von schönem, sinnlosem Engineering, das Programmieren Spaß macht. Jemand sah 'jeder Funktionsaufruf erzeugt einen Prozess' und sagte 'nicht schwergewichtig genug, wir brauchen Container.' Peak HN-Showmanship.
From the stands 2 of 2 comments
This is the most ridiculous thing I've ever seen and I love it.
这是我见过最荒谬的东西，我爱死它了。
これまで見た中で最もバカバカしいものだが大好きだ。
내가 본 것 중 가장 황당한 것이고 사랑한다.
Esta es la cosa más ridícula que he visto y me encanta.
Das ist das Lächerlichste, was ich je gesehen habe, und ich liebe es.
piloto_ciego
I'm impressed GitHub managed to handle this beast: 500+ container invocations to compute factorial(3)
GitHub 能处理这个怪物我印象深刻：500 多次容器调用就为了计算 factorial(3)
GitHub がこの怪物を処理できたことに感心：factorial(3)を計算するのに 500 以上のコンテナ呼び出し
GitHub 가 이 괴물을 처리할 수 있다니 놀랍다: factorial(3) 계산에 500 개 이상의 컨테이너 호출
Me impresiona que GitHub manejara esta bestia: 500+ invocaciones de contenedores para calcular factorial(3)
Ich bin beeindruckt, dass GitHub dieses Monster bewältigt hat: 500+ Container-Aufrufe um factorial(3) zu berechnen
teaearlgraycold