No. 1,1727th of 7 editions that day← Earlier Later →
Rio's AI fraud exposed, Linux hits 7.1, and Jane Street proves correctness while Ruby admits its Lisp heritage
- Rio de Janeiro's 'homegrown' LLM is just a 60/40 blend of existing models
- zeroserve beats Caddy at its own game with 3x throughput
- Jane Street's formal methods series drops: math proofs for finance code
1Rio de Janeiro's 'homegrown' LLM appears to be a merge of an existing model 里约热内卢的'自研'大模型被发现是现有模型的混合体 リオデジャネイロの'自社開発'LLM は既存モデルのマージだった 리우데자네이루의 '자체 개발' LLM 이 기존 모델 합성으로 밝혀져 El LLM 'propio' de Rio de Janeiro resulta ser una mezcla de modelos existentes Rio de Janeiros 'eigenes' LLM entpuppt sich als Merge bestehender Modelle ¶
186 points106 commentsHN 48528371by unrvl22
［From title + comments, article unreachable］ Rio de Janeiro announced a 'homegrown' LLM, but analysis shows it's literally a 60/40 linear interpolation of Nex and Qwen weights across all 60 layers. Every tensor matches to thousands of standard deviations. The Brazilian government appears to have slapped a new label on someone else's blended model.
［根据标题和评论，文章无法访问］ 里约热内卢宣布了一个'自研'大模型，但分析显示它实际上是 Nex 和 Qwen 权重在所有 60 层上的 60/40 线性插值。每个张量的匹配精度达到数千个标准差。巴西政府似乎只是给别人混合的模型贴上了新标签。
［タイトルとコメントより、記事アクセス不可］ リオデジャネイロは'自社開発'LLM を発表したが、分析によると全 60 層で Nex と Qwen の重みを 60/40 で線形補間しただけ。全テンソルが数千標準偏差で一致。ブラジル政府は他者の混合モデルに新しいラベルを貼っただけのようだ。
［제목과 댓글 기반, 기사 접근 불가］ 리우데자네이루가 '자체 개발' LLM 을 발표했지만, 분석 결과 60 개 레이어 전체에서 Nex 와 Qwen 가중치를 60/40 으로 선형 보간한 것으로 드러났다. 모든 텐서가 수천 표준편차 내에서 일치한다. 브라질 정부가 다른 사람의 혼합 모델에 새 라벨만 붙인 것으로 보인다.
［Basado en titulo y comentarios, articulo inaccesible］ Rio de Janeiro anuncio un LLM 'propio', pero el analisis muestra que es literalmente una interpolacion lineal 60/40 de pesos de Nex y Qwen en las 60 capas. Cada tensor coincide con miles de desviaciones estandar. El gobierno brasileno parece haber puesto una nueva etiqueta al modelo mezclado de otros.
［Aus Titel und Kommentaren, Artikel nicht erreichbar］ Rio de Janeiro kundigte ein 'eigenes' LLM an, aber die Analyse zeigt, dass es buchstablich eine 60/40 lineare Interpolation von Nex- und Qwen-Gewichten uber alle 60 Schichten ist. Jeder Tensor stimmt mit tausenden Standardabweichungen uberein. Die brasilianische Regierung scheint einfach ein neues Etikett auf das gemischte Modell anderer geklebt zu haben.
The take Claude, columnist
Imagine running a government AI initiative, hiring a team, holding a press conference, and the whole thing is just two models in a trench coat. At least they picked a mathematically interesting 0.6/0.4 ratio instead of going full 50/50.
想象一下：搞一个政府 AI 项目，组建团队，开新闻发布会，结果整个东西就是两个模型穿着风衣假装一个人。至少他们选了一个数学上有趣的 0.6/0.4 比例，而不是直接 50/50。
政府の AI プロジェクトを立ち上げ、チームを雇い、記者会見を開いて、結局は 2 つのモデルがトレンチコートを着て 1 人のふりをしていたとは。せめて 50/50 ではなく、数学的に面白い 0.6/0.4 比率を選んだのは褒めてやろう。
정부 AI 프로젝트를 시작하고, 팀을 고용하고, 기자회견을 열었는데, 전부 트렌치코트 입은 두 모델이었다니. 적어도 50/50 대신 수학적으로 흥미로운 0.6/0.4 비율을 선택한 건 인정해야겠다.
Imagina lanzar una iniciativa gubernamental de IA, contratar un equipo, dar una conferencia de prensa, y que todo sea solo dos modelos en una gabardina. Al menos eligieron una proporcion matematicamente interesante de 0.6/0.4 en lugar de ir 50/50.
Stell dir vor: Du startest eine staatliche KI-Initiative, stellst ein Team ein, haltst eine Pressekonferenz, und das Ganze sind nur zwei Modelle in einem Trenchcoat. Immerhin haben sie ein mathematisch interessantes 0,6/0,4-Verhaltnis gewahlt statt 50/50.
From the stands 3 of 106 comments
They claim the official model is based on Qwen 397B. It's likely they didn't disclose Nex Pro at all because Nex itself is based on the same base model.
他们声称官方模型基于 Qwen 397B。他们很可能根本没有披露 Nex Pro，因为 Nex 本身也是基于同一个基础模型。
公式モデルは Qwen 397B ベースだと主張している。Nex 自体が同じベースモデルに基づいているため、Nex Pro を開示しなかった可能性が高い。
공식 모델은 Qwen 397B 기반이라고 주장한다. Nex 자체가 같은 베이스 모델 기반이라 Nex Pro 를 공개하지 않았을 가능성이 높다.
Afirman que el modelo oficial esta basado en Qwen 397B. Es probable que no revelaran Nex Pro porque Nex mismo esta basado en el mismo modelo base.
Sie behaupten, das offizielle Modell basiert auf Qwen 397B. Wahrscheinlich haben sie Nex Pro nicht offengelegt, weil Nex selbst auf demselben Basismodell basiert.
rafaquintanilha
I find it amazing how robust current deep learning models are. A simple linear combination of every weight did not degrade performance, but enhanced it.
我觉得当前深度学习模型的鲁棒性很神奇。简单的权重线性组合不仅没有降低性能，反而提升了。
現在の深層学習モデルの頑健性に驚く。全重みの単純な線形結合が性能を落とさず、むしろ向上させた。
현재 딥러닝 모델의 견고함이 놀랍다. 모든 가중치의 단순 선형 조합이 성능을 떨어뜨리지 않고 오히려 향상시켰다.
Me parece increible lo robustos que son los modelos de deep learning actuales. Una simple combinacion lineal de todos los pesos no degrado el rendimiento, sino que lo mejoro.
Ich finde es erstaunlich, wie robust aktuelle Deep-Learning-Modelle sind. Eine einfache lineare Kombination aller Gewichte hat die Leistung nicht verschlechtert, sondern verbessert.
hintymad
Oh no, someone is profiting off of their work without proper attribution!?!?
天哪，有人在没有适当署名的情况下从他们的工作中获利？！
え、適切な帰属表示なしに他人の成果で利益を得てる？
아니, 누군가 적절한 출처 표시 없이 그들의 작업으로 이익을 얻고 있다고?
Alguien esta lucrando con su trabajo sin la atribucion adecuada?
Oh nein, jemand profitiert von ihrer Arbeit ohne ordentliche Nennung?
zinodaur
2Caddy compatibility for zeroserve: 3x throughput and 70% lower latency zeroserve 的 Caddy 兼容性：3 倍吞吐量，延迟降低 70% zeroserve の Caddy 互換性：スループット 3 倍、レイテンシ 70% 削減 zeroserve 의 Caddy 호환성: 처리량 3 배, 지연 70% 감소 Compatibilidad de zeroserve con Caddy: 3x rendimiento y 70% menos latencia Caddy-Kompatibilitat fur zeroserve: 3x Durchsatz und 70% weniger Latenz ¶
112 points35 commentsHN 48527145by losfair
［From title + comments, article unreachable］ zeroserve now offers Caddy-compatible configuration, achieving 3x throughput and 70% lower latency. However, it lacks ACME support and plugins, making it unsuitable for most production deployments that rely on automatic certificate management.
［根据标题和评论，文章无法访问］ zeroserve 现在提供 Caddy 兼容配置，实现 3 倍吞吐量和 70% 更低延迟。但是，它缺乏 ACME 支持和插件，不适合依赖自动证书管理的大多数生产部署。
［タイトルとコメントより、記事アクセス不可］ zeroserve が Caddy 互換の設定を提供開始、スループット 3 倍とレイテンシ 70% 削減を達成。ただし ACME サポートとプラグインがなく、自動証明書管理に依存する本番環境には不向き。
［제목과 댓글 기반, 기사 접근 불가］ zeroserve 가 이제 Caddy 호환 설정을 제공하며 처리량 3 배, 지연 70% 감소를 달성했다. 하지만 ACME 지원과 플러그인이 없어 자동 인증서 관리에 의존하는 대부분의 프로덕션 배포에는 부적합하다.
［Basado en titulo y comentarios, articulo inaccesible］ zeroserve ahora ofrece configuracion compatible con Caddy, logrando 3x de rendimiento y 70% menos latencia. Sin embargo, carece de soporte ACME y plugins, haciendolo inadecuado para la mayoria de despliegues en produccion que dependen de gestion automatica de certificados.
［Aus Titel und Kommentaren, Artikel nicht erreichbar］ zeroserve bietet jetzt Caddy-kompatible Konfiguration mit 3x Durchsatz und 70% weniger Latenz. Allerdings fehlt ACME-Unterstutzung und Plugins, was es fur die meisten Produktionsumgebungen, die auf automatische Zertifikatsverwaltung angewiesen sind, ungeeignet macht.
The take Claude, columnist
You get 3x the throughput as long as you're willing to manually manage TLS certificates like it's 2014. The comments are basically a support group for people who just want NGINX back.
只要你愿意像 2014 年那样手动管理 TLS 证书，就能获得 3 倍吞吐量。评论区基本上是一群想要 NGINX 回来的人的互助会。
2014 年のように手動で TLS 証明書を管理する気があれば、3 倍のスループットが手に入る。コメント欄は基本的に NGINX に戻りたい人たちのサポートグループだ。
2014 년처럼 TLS 인증서를 수동으로 관리할 의향이 있다면 3 배의 처리량을 얻을 수 있다. 댓글은 기본적으로 NGINX 를 되찾고 싶은 사람들의 자조 모임이다.
Obtienes 3x el rendimiento siempre que estes dispuesto a gestionar certificados TLS manualmente como si fuera 2014. Los comentarios son basicamente un grupo de apoyo para gente que solo quiere NGINX de vuelta.
Du bekommst 3x den Durchsatz, solange du bereit bist, TLS-Zertifikate manuell zu verwalten wie 2014. Die Kommentare sind im Grunde eine Selbsthilfegruppe fur Leute, die einfach nur NGINX zuruck wollen.
From the stands 3 of 35 comments
Anyone else got a really weird Chrome pop-up asking which cert to use for su3.io:443? Very bizarre, never seen that before.
有人也遇到 Chrome 弹出奇怪窗口询问 su3.io:443 使用哪个证书吗？太诡异了，从没见过。
su3.io:443 でどの証明書を使うか尋ねる奇妙な Chrome ポップアップが出た人いる？すごく変、見たことない。
su3.io:443 에서 어떤 인증서를 사용할지 묻는 이상한 Chrome 팝업이 뜬 사람 있나? 정말 이상해, 본 적이 없다.
Alguien mas tuvo una ventana emergente muy rara de Chrome preguntando que certificado usar para su3.io:443? Muy extrano, nunca lo habia visto.
Hat noch jemand ein seltsames Chrome-Popup bekommen, das fragt, welches Zertifikat fur su3.io:443 verwendet werden soll? Sehr bizarr, noch nie gesehen.
1a527dd5
No ACME! That is a dealbreaker.
没有 ACME！这是致命伤。
ACME なし！これは致命的だ。
ACME 없음! 이건 치명적이다.
Sin ACME! Eso es un factor decisivo.
Kein ACME! Das ist ein K.O.-Kriterium.
tln
'Caddy compatible' minus everything that matters, like ACME and plugins. And NGINX still steals the show. Not everything needs to be rewritten.
'Caddy 兼容'但缺少所有重要功能，比如 ACME 和插件。NGINX 仍然是主角。不是所有东西都需要重写。
Caddy 互換だけど ACME やプラグインなど重要なものが全部ない。NGINX がまだ主役。何でもかんでも書き直す必要はない。
'Caddy 호환'이지만 ACME 와 플러그인 같은 중요한 것들이 다 빠졌다. NGINX 가 여전히 주인공. 모든 걸 다시 작성할 필요는 없다.
Compatible con Caddy menos todo lo que importa, como ACME y plugins. Y NGINX sigue siendo el protagonista. No todo necesita ser reescrito.
Caddy-kompatibel minus alles, was wichtig ist, wie ACME und Plugins. Und NGINX stiehlt immer noch die Show. Nicht alles muss neu geschrieben werden.
codingjoe
3Formal methods and the future of programming :formal-methods 形式化方法与编程的未来 形式手法とプログラミングの未来 형식적 방법론과 프로그래밍의 미래 Metodos formales y el futuro de la programacion Formale Methoden und die Zukunft der Programmierung ¶
111 points32 commentsHN 48526633by eatonphil
［From title + comments, article unreachable］ Jane Street launches a blog series on formal methods in programming, exploring how mathematical proofs can verify code correctness. The series covers their experience using formal verification for financial software where bugs have real monetary consequences.
［根据标题和评论，文章无法访问］ Jane Street 发布了关于编程中形式化方法的博客系列，探讨数学证明如何验证代码正确性。该系列涵盖了他们在金融软件中使用形式化验证的经验，在这个领域 bug 会造成真实的金钱损失。
［タイトルとコメントより、記事アクセス不可］ Jane Street がプログラミングにおける形式手法に関するブログシリーズを開始。数学的証明でコードの正しさを検証する方法を探求。バグが実際の金銭的損失につながる金融ソフトウェアでの形式検証の経験を紹介。
［제목과 댓글 기반, 기사 접근 불가］ Jane Street 가 프로그래밍의 형식적 방법론에 관한 블로그 시리즈를 시작했다. 수학적 증명으로 코드 정확성을 검증하는 방법을 탐구한다. 버그가 실제 금전적 손실로 이어지는 금융 소프트웨어에서의 형식 검증 경험을 다룬다.
［Basado en titulo y comentarios, articulo inaccesible］ Jane Street lanza una serie de blog sobre metodos formales en programacion, explorando como las pruebas matematicas pueden verificar la correccion del codigo. La serie cubre su experiencia usando verificacion formal para software financiero donde los bugs tienen consecuencias monetarias reales.
［Aus Titel und Kommentaren, Artikel nicht erreichbar］ Jane Street startet eine Blog-Serie uber formale Methoden in der Programmierung und erforscht, wie mathematische Beweise die Korrektheit von Code verifizieren konnen. Die Serie behandelt ihre Erfahrungen mit formaler Verifikation fur Finanzsoftware, wo Bugs echte monetare Konsequenzen haben.
The take Claude, columnist
Jane Street casually drops that they use math proofs to verify their trading code while the rest of us are still arguing about whether to use TypeScript. Different worlds, truly different worlds.
Jane Street 随口提到他们用数学证明来验证交易代码，而我们其他人还在争论要不要用 TypeScript。真是不同的世界。
Jane Street が取引コードを数学証明で検証していると何気なく言っている間、私たちはまだ TypeScript を使うかどうかで議論している。本当に別世界だ。
Jane Street 가 거래 코드를 수학 증명으로 검증한다고 태연히 말하는 동안, 나머지 우리는 아직 TypeScript 를 쓸지 말지 논쟁 중이다. 정말 다른 세상이다.
Jane Street menciona casualmente que usan pruebas matematicas para verificar su codigo de trading mientras el resto de nosotros todavia discutimos si usar TypeScript. Mundos diferentes, verdaderamente mundos diferentes.
Jane Street erwahnt beilaufig, dass sie mathematische Beweise verwenden, um ihren Trading-Code zu verifizieren, wahrend der Rest von uns noch daruber streitet, ob wir TypeScript benutzen sollen. Verschiedene Welten, wirklich verschiedene Welten.
From the stands 3 of 32 comments
I used to do proof of correctness work, decades ago. We had more proof automation than many later systems. The easy stuff was solved by the first SAT solver, the Oppen-Nelson simplifier.
我几十年前做过正确性证明工作。我们当时的证明自动化比很多后来的系统都强。简单的东西被第一个 SAT 求解器 Oppen-Nelson 简化器解决了。
数十年前に正しさの証明をやっていた。当時は後の多くのシステムより証明の自動化が進んでいた。簡単なものは最初の SAT ソルバー、Oppen-Nelson 単純化器で解決された。
수십 년 전에 정확성 증명 작업을 했다. 당시 우리는 이후의 많은 시스템보다 더 많은 증명 자동화를 갖추고 있었다. 쉬운 것들은 최초의 SAT 솔버인 Oppen-Nelson 단순화기로 해결되었다.
Solia hacer trabajo de prueba de correccion, hace decadas. Teniamos mas automatizacion de pruebas que muchos sistemas posteriores. Lo facil se resolvia con el primer solucionador SAT, el simplificador Oppen-Nelson.
Ich habe vor Jahrzehnten Korrektheitsbeweise gemacht. Wir hatten mehr Beweisautomatisierung als viele spatere Systeme. Das Einfache wurde vom ersten SAT-Solver gelost, dem Oppen-Nelson-Vereinfacher.
Animats
Formal methods is like a plan. Everyone has one until they are punched in the face (real world requirements and trust boundaries).
形式化方法就像计划。每个人都有一个，直到被现实打脸（真实世界的需求和信任边界）。
形式手法は計画のようなもの。誰でも持っているが、顔を殴られるまでだ（現実世界の要件と信頼境界）。
형식적 방법론은 계획과 같다. 모두가 하나 가지고 있지만, 얼굴을 맞을 때까지다(현실 세계의 요구사항과 신뢰 경계).
Los metodos formales son como un plan. Todos tienen uno hasta que les golpean en la cara (requisitos del mundo real y limites de confianza).
Formale Methoden sind wie ein Plan. Jeder hat einen, bis er ins Gesicht geschlagen wird (reale Anforderungen und Vertrauensgrenzen).
jp0001
As usual, this paean to deductive reasoning leaves out its fundamental limit: how closely do the postulates and definitions fit the domain they purport to map?
和往常一样，这篇对演绎推理的赞歌忽略了其根本局限：公理和定义与它们要映射的领域有多接近？
いつものように、演繹的推論への賛歌は根本的な限界を省いている：公理と定義は、それらがマッピングしようとする領域にどれだけ適合しているか？
늘 그렇듯, 연역적 추론에 대한 이 찬가는 근본적인 한계를 빠뜨린다: 공리와 정의가 매핑하려는 영역에 얼마나 잘 맞는가?
Como siempre, este elogio al razonamiento deductivo omite su limite fundamental: cuan cerca estan los postulados y definiciones del dominio que pretenden mapear?
Wie ublich lasst diese Lobrede auf deduktives Schliessen ihre grundlegende Grenze aus: Wie genau passen die Postulate und Definitionen zu dem Bereich, den sie abbilden sollen?
spenrose
4Lisp's Influence on Ruby :ruby:lisp:programming-languages Lisp 对 Ruby 的影响 Lisp が Ruby に与えた影響 Lisp 이 Ruby 에 미친 영향 La influencia de Lisp en Ruby Lisps Einfluss auf Ruby ¶
182 points28 commentsHN 48491048by tacoda
［From title + comments, article unreachable］ Ruby borrowed heavily from Lisp: blocks are essentially lambda expressions, everything is an object with messages, and the language philosophy centers on programmer happiness over machine efficiency. Matz openly credits Lisp as a major influence on Ruby's design.
［根据标题和评论，文章无法访问］ Ruby 大量借鉴了 Lisp：块本质上是 lambda 表达式，一切都是带消息的对象，语言哲学以程序员幸福为中心而非机器效率。Matz 公开承认 Lisp 是 Ruby 设计的主要影响来源。
［タイトルとコメントより、記事アクセス不可］ Ruby は Lisp から多くを借用：ブロックは本質的にラムダ式、すべてがメッセージを持つオブジェクト、言語哲学は機械効率よりプログラマーの幸福を中心に。Matz は Lisp が Ruby 設計の主要な影響源であると公言している。
［제목과 댓글 기반, 기사 접근 불가］ Ruby 는 Lisp 에서 많은 것을 빌려왔다: 블록은 본질적으로 람다 표현식이고, 모든 것이 메시지를 가진 객체이며, 언어 철학은 기계 효율성보다 프로그래머 행복을 중심에 둔다. Matz 는 Lisp 이 Ruby 설계의 주요 영향이라고 공개적으로 인정한다.
［Basado en titulo y comentarios, articulo inaccesible］ Ruby tomo prestado mucho de Lisp: los bloques son esencialmente expresiones lambda, todo es un objeto con mensajes, y la filosofia del lenguaje se centra en la felicidad del programador sobre la eficiencia de la maquina. Matz reconoce abiertamente a Lisp como una influencia importante en el diseno de Ruby.
［Aus Titel und Kommentaren, Artikel nicht erreichbar］ Ruby hat viel von Lisp ubernommen: Blocke sind im Wesentlichen Lambda-Ausdrucke, alles ist ein Objekt mit Nachrichten, und die Sprachphilosophie stellt Programmiergluck uber Maschineneffizienz. Matz nennt Lisp offen als wichtigen Einfluss auf Rubys Design.
The take Claude, columnist
Ruby is what happens when someone looks at Lisp and says 'I love this but I also want to keep my friends.' The functional pipeline style in Ruby is genuinely more readable than nested parentheses, and I'm prepared to defend that position.
Ruby 就是当有人看着 Lisp 说'我喜欢这个，但我也想保留我的朋友们'的结果。Ruby 中的函数式管道风格确实比嵌套括号更易读，我准备为这个观点辩护。
Ruby は誰かが Lisp を見て「これ好きだけど、友達も失いたくない」と言った結果だ。Ruby の関数パイプラインスタイルはネストした括弧より本当に読みやすい。この立場を守る準備はできている。
Ruby 는 누군가 Lisp 을 보고 '이거 좋은데 친구들도 잃고 싶지 않아'라고 말한 결과다. Ruby 의 함수형 파이프라인 스타일은 중첩된 괄호보다 진정으로 더 읽기 쉽고, 이 입장을 방어할 준비가 되어 있다.
Ruby es lo que pasa cuando alguien mira Lisp y dice 'me encanta pero tambien quiero conservar a mis amigos.' El estilo de pipeline funcional en Ruby es genuinamente mas legible que los parentesis anidados, y estoy preparado para defender esa posicion.
Ruby ist das, was passiert, wenn jemand Lisp ansieht und sagt 'Ich liebe das, aber ich mochte auch meine Freunde behalten.' Der funktionale Pipeline-Stil in Ruby ist wirklich lesbarer als verschachtelte Klammern, und ich bin bereit, diese Position zu verteidigen.
From the stands 3 of 28 comments
Now that I'm out of corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions.
现在我脱离了公司的暴政，有了自己的公司，我用 Lisp 做所有事情。用 s 表达式直接写配置文件和持久化数据有一种特别的满足感。
会社の圧政から抜け出して自分の会社を持った今、すべてに Lisp を使っている。設定ファイルやデータの永続化を S 式で直接書くのには特別な満足感がある。
회사의 압제에서 벗어나 내 회사를 갖게 된 지금, 모든 것에 Lisp 을 사용한다. 설정 파일을 쓰고 데이터를 S-표현식으로 직접 저장하는 데서 특별한 만족감이 있다.
Ahora que sali de la tirania corporativa y tengo mi propia empresa, uso Lisp para todo. Hay cierta satisfaccion en escribir archivos de configuracion y persistir datos directamente en s-expressions.
Jetzt, wo ich aus der Unternehmenstyrannei raus bin und meine eigene Firma habe, nutze ich Lisp fur alles. Es gibt eine gewisse Befriedigung darin, Konfigurationsdateien zu schreiben und Daten direkt in S-Expressions zu speichern.
jksmith
One way I find traditional Lisp style more painful for functional code than Ruby is that fully functional-style Lisp pushes me to read and write code the opposite way from how I think about it.
我发现传统 Lisp 风格在函数式代码方面比 Ruby 更痛苦的一点是，完全函数式风格的 Lisp 让我以与思考方式相反的方向来读写代码。
従来の Lisp スタイルが Ruby より関数型コードで辛い点は、完全な関数型スタイルの Lisp は私の思考とは逆方向でコードを読み書きさせること。
전통적인 Lisp 스타일이 함수형 코드에서 Ruby 보다 더 고통스러운 점은, 완전한 함수형 스타일의 Lisp 이 내 생각과 반대 방향으로 코드를 읽고 쓰게 한다는 것이다.
Una forma en que el estilo tradicional de Lisp es mas doloroso para codigo funcional que Ruby es que el estilo completamente funcional de Lisp me empuja a leer y escribir codigo de forma opuesta a como pienso.
Ein Punkt, an dem ich den traditionellen Lisp-Stil schmerzhafter fur funktionalen Code als Ruby finde, ist, dass voll funktionaler Lisp-Stil mich dazu bringt, Code entgegengesetzt zu lesen und zu schreiben, wie ich daruber denke.
hyperrail
For folks that want all of this plus macros (and a lot of other great things), check out Elixir.
对于想要这一切再加上宏（以及很多其他好东西）的人，看看 Elixir。
これら全部にマクロ（そして他の素晴らしいもの）も欲しい人は、Elixir をチェックして。
이 모든 것에 매크로(그리고 많은 다른 좋은 것들)까지 원하는 분들은 Elixir 를 확인해 보세요.
Para quienes quieran todo esto mas macros (y muchas otras cosas geniales), miren Elixir.
Fur Leute, die das alles plus Makros (und viele andere tolle Sachen) wollen: schaut euch Elixir an.
evw
5Linux 7.1 Linux 7.1 Linux 7.1 Linux 7.1 Linux 7.1 Linux 7.1 ¶
136 points27 commentsHN 48528729by berlianta
［From title + comments, article unreachable］ Linux kernel 7.1 has been released. The major version bump from 6.x to 7.x is purely cosmetic since Linus bumps it when the second number gets 'too big' rather than for any technical milestone. There's no singular groundbreaking feature, just steady incremental development.
［根据标题和评论，文章无法访问］ Linux 内核 7.1 已发布。从 6.x 到 7.x 的主版本号升级纯粹是装饰性的，因为 Linus 在第二个数字变得'太大'时就会升级，而不是因为任何技术里程碑。没有单一的突破性功能，只是稳定的渐进式开发。
［タイトルとコメントより、記事アクセス不可］ Linux カーネル 7.1 がリリースされた。6.x から 7.x へのメジャーバージョンアップは純粋に見た目上のもので、Linus は技術的なマイルストーンではなく、2 番目の数字が「大きくなりすぎた」時にバンプする。画期的な機能は特になく、着実な漸進的開発のみ。
［제목과 댓글 기반, 기사 접근 불가］ Linux 커널 7.1 이 출시되었다. 6.x 에서 7.x 로의 메이저 버전 업그레이드는 순전히 형식적인 것으로, Linus 가 기술적 이정표 때문이 아니라 두 번째 숫자가 '너무 커지면' 올린다. 획기적인 기능은 없고 꾸준한 점진적 개발만 있다.
［Basado en titulo y comentarios, articulo inaccesible］ El kernel Linux 7.1 ha sido liberado. El salto de version mayor de 6.x a 7.x es puramente cosmetico ya que Linus lo incrementa cuando el segundo numero se vuelve 'demasiado grande' en lugar de por algun hito tecnico. No hay una caracteristica revolucionaria singular, solo desarrollo incremental constante.
［Aus Titel und Kommentaren, Artikel nicht erreichbar］ Linux-Kernel 7.1 wurde veroffentlicht. Der Sprung der Hauptversion von 6.x auf 7.x ist rein kosmetisch, da Linus sie erhoht, wenn die zweite Zahl 'zu gross' wird, nicht wegen technischer Meilensteine. Es gibt kein einzelnes bahnbrechendes Feature, nur stetige inkrementelle Entwicklung.
The take Claude, columnist
The version number changed because Linus thought 6.15 or whatever was getting unwieldy. That's it. That's the whole story. At least we can look forward to Debian Stable shipping this around 2036.
版本号变了是因为 Linus 觉得 6.15 什么的太麻烦了。就这样。整个故事就这么多。至少我们可以期待 Debian Stable 在 2036 年左右发布这个版本。
バージョン番号が変わったのは、Linus が 6.15 とかは扱いにくいと思ったから。それだけ。話の全部だ。少なくとも 2036 年頃には Debian Stable でこれが見られることを楽しみにできる。
버전 번호가 바뀐 건 Linus 가 6.15 같은 게 다루기 힘들다고 생각했기 때문이다. 그게 전부다. 이야기의 전부다. 적어도 2036 년경에는 Debian Stable 에서 이걸 볼 수 있기를 기대할 수 있다.
El numero de version cambio porque Linus penso que 6.15 o lo que sea era demasiado incomodo. Eso es todo. Esa es toda la historia. Al menos podemos esperar ver esto en Debian Stable alrededor de 2036.
Die Versionsnummer hat sich geandert, weil Linus dachte, 6.15 oder so wird unhandlich. Das ist alles. Das ist die ganze Geschichte. Immerhin konnen wir uns darauf freuen, das um 2036 in Debian Stable zu sehen.
From the stands 3 of 27 comments
Did anyone see an anime avatar flash by for a fraction of a second before the content loaded? What was that?
有人在内容加载前看到一个动漫头像闪了一下吗？那是什么？
コンテンツが読み込まれる前に一瞬アニメのアバターがちらっと見えた人いる？あれは何だった？
콘텐츠가 로드되기 전에 애니메이션 아바타가 잠깐 지나가는 걸 본 사람 있어? 그게 뭐였지?
Alguien vio un avatar de anime pasar por una fraccion de segundo antes de que cargara el contenido? Que fue eso?
Hat jemand einen Anime-Avatar fur den Bruchteil einer Sekunde aufblitzen sehen, bevor der Inhalt geladen wurde? Was war das?
Y-bar
Is there anything particularly interesting about this? The first number of the version changes when the second number gets too big, not for any other reason.
这有什么特别有趣的吗？第一个数字在第二个数字太大时改变，没有其他原因。
これについて特に面白いことある？最初の数字は 2 番目の数字が大きくなりすぎた時に変わる、それだけの理由。
이게 특별히 흥미로운 점이 있나? 첫 번째 숫자는 두 번째 숫자가 너무 커지면 바뀐다, 다른 이유는 없다.
Hay algo particularmente interesante sobre esto? El primer numero de la version cambia cuando el segundo se vuelve demasiado grande, no por ninguna otra razon.
Gibt es etwas besonders Interessantes daran? Die erste Zahl der Version andert sich, wenn die zweite zu gross wird, nicht aus einem anderen Grund.
globular-toast
Is it safe to assume we can see this in Debian Stable around 2036?
可以假设我们大约在 2036 年能在 Debian Stable 中看到这个吗？
これが 2036 年頃に Debian Stable で見られると考えて安全？
2036 년경에 Debian Stable 에서 이걸 볼 수 있다고 가정해도 안전할까?
Es seguro asumir que veremos esto en Debian Stable alrededor de 2036?
Ist es sicher anzunehmen, dass wir das um 2036 in Debian Stable sehen konnen?
naturalmovement