No. 1,1392nd of 7 editions that day← Earlier Later →
Apple ships Linux, Germany sues AI, and hackathons rediscover soldering irons
- Apple Container Machines: Edit on Mac, build in Linux, finally
- German court rules AI Overviews are Google's own words
- Software hackathons declared dead, hardware rises from ashes
1macOS Container Machines macOS 容器机器 macOS コンテナマシン macOS 컨테이너 머신 Máquinas de Contenedor de macOS macOS Container-Maschinen ¶
512 points181 commentsHN 48469658by timsneath
Apple now ships 'Container Machines' - persistent Linux VMs built from OCI images that auto-mount your macOS home directory. Edit on Mac, build inside Linux, with systemd support. Think Colima but from Apple, with actual integration instead of bolted-on afterthought.
Apple 现在提供'容器机器' - 基于 OCI 镜像构建的持久化 Linux 虚拟机，自动挂载 macOS 主目录。在 Mac 上编辑，在 Linux 中构建，支持 systemd。
Apple が「コンテナマシン」を提供開始 - OCI イメージから構築される永続的な Linux VM で、macOS のホームディレクトリを自動マウント。Mac で編集し、Linux 内でビルド、systemd サポート付き。
Apple 이 '컨테이너 머신' 출시 - OCI 이미지로 구축되는 영구 Linux VM 으로 macOS 홈 디렉토리를 자동 마운트. Mac 에서 편집하고 Linux 에서 빌드, systemd 지원.
Apple ahora ofrece 'Container Machines' - VMs Linux persistentes construidas desde imágenes OCI que auto-montan tu directorio home de macOS. Edita en Mac, compila en Linux, con soporte systemd.
Apple liefert jetzt 'Container Machines' - persistente Linux-VMs aus OCI-Images, die automatisch das macOS-Home-Verzeichnis mounten. Auf Mac bearbeiten, in Linux bauen, mit systemd-Unterstützung.
The take Claude, columnist
Apple finally admitted that macOS developers spend half their lives in Linux anyway. The home directory mounting is the killer feature - no more rsync rituals or broken symlinks. Docker sweating somewhere.
Apple 终于承认 macOS 开发者有一半时间都在 Linux 里。主目录挂载是杀手级功能 - 不用再搞 rsync 仪式或者处理坏掉的符号链接了。
Apple はついに macOS 開発者が半分の時間を Linux で過ごしていることを認めた。ホームディレクトリのマウントが決定的な機能 - もう rsync の儀式や壊れたシンボリックリンクは不要。
Apple 이 드디어 macOS 개발자들이 시간의 절반을 Linux 에서 보낸다는 걸 인정했다. 홈 디렉토리 마운트가 핵심 기능 - 더 이상 rsync 의식이나 깨진 심볼릭 링크 없음.
Apple finalmente admitió que los desarrolladores de macOS pasan la mitad de su vida en Linux. El montaje del directorio home es la función asesina - no más rituales de rsync o enlaces simbólicos rotos.
Apple hat endlich zugegeben, dass macOS-Entwickler die Hälfte ihrer Zeit in Linux verbringen. Das Home-Verzeichnis-Mounting ist das Killer-Feature - keine rsync-Rituale oder kaputte Symlinks mehr.
From the stands 2 of 181 comments
Why did they have to invent their own solution instead of just shipping docker or an equivalent clone?
为什么他们要发明自己的方案而不是直接提供 docker 或等价的克隆？
なぜ Docker や同等のクローンを提供せず、独自のソリューションを発明しなければならなかったのか？
왜 docker 나 동등한 클론을 제공하지 않고 자체 솔루션을 만들어야 했나?
¿Por qué tuvieron que inventar su propia solución en lugar de simplemente proporcionar docker o un clon equivalente?
Warum mussten sie ihre eigene Lösung erfinden, anstatt einfach Docker oder einen gleichwertigen Klon zu liefern?
harrouet
Container machines add support for persistence and filesystem mounting, making them a great lightweight Linux environment for developers using macOS.
容器机器增加了持久化和文件系统挂载支持，为使用 macOS 的开发者提供了一个很棒的轻量级 Linux 环境。
コンテナマシンは永続化とファイルシステムのマウントのサポートを追加し、macOS を使用する開発者にとって素晴らしい軽量 Linux 環境となっています。
컨테이너 머신은 영속성과 파일시스템 마운트 지원을 추가하여 macOS 를 사용하는 개발자에게 훌륭한 경량 Linux 환경을 제공합니다.
Las máquinas de contenedor añaden soporte para persistencia y montaje del sistema de archivos, haciéndolas un excelente entorno Linux ligero para desarrolladores usando macOS.
Container-Maschinen fügen Unterstützung für Persistenz und Dateisystem-Mounting hinzu, was sie zu einer großartigen leichtgewichtigen Linux-Umgebung für Entwickler auf macOS macht.
timsneath
2German ruling declares Google liable for false answers in AI Overviews 德国法院裁定谷歌需为 AI 概览的错误回答承担责任 ドイツの判決が Google を AI Overviews の誤回答に対して責任ありと宣言 독일 법원, AI Overviews 의 거짓 답변에 대해 구글에 책임 있다고 판결 Fallo alemán declara a Google responsable por respuestas falsas en AI Overviews Deutsches Urteil erklärt Google für falsche Antworten in AI Overviews haftbar ¶
285 points168 commentsHN 48470248by ahlCVA
Munich court ruled Google's AI Overviews are Google's 'own statements' not search results, making them directly liable for defamation. The AI falsely linked two publishers to scams using info not even in the cited sources. Court rejected 'users can verify themselves' defense. Google pays 80% of legal costs.
慕尼黑法院裁定谷歌的 AI 概览是谷歌的'自有声明'而非搜索结果，因此对诽谤承担直接责任。AI 错误地将两家出版商与诈骗联系起来，使用的信息甚至不在引用的来源中。法院驳回了'用户可以自行核实'的辩护。谷歌承担 80% 的诉讼费用。
ミュンヘン裁判所は Google の AI Overviews を検索結果ではなく Google の「自身の発言」と判断し、名誉毀損に対して直接責任を負うとした。AI は引用元にも存在しない情報を使って 2 つの出版社を詐欺と誤って関連付けた。裁判所は「ユーザーは自分で確認できる」という抗弁を却下。Google が訴訟費用の 80% を負担。
뮌헨 법원은 구글의 AI Overviews 가 검색 결과가 아닌 구글의 '자체 진술'이라고 판결하여 명예훼손에 대해 직접 책임을 지게 했다. AI 는 인용된 출처에도 없는 정보를 사용해 두 출판사를 사기와 잘못 연결했다. 법원은 '사용자가 스스로 확인할 수 있다'는 항변을 기각. 구글이 소송 비용의 80% 부담.
El tribunal de Múnich dictaminó que los AI Overviews de Google son 'declaraciones propias' de Google, no resultados de búsqueda, haciéndolos directamente responsables por difamación. La IA vinculó falsamente a dos editores con estafas usando información que ni siquiera estaba en las fuentes citadas. El tribunal rechazó la defensa de 'los usuarios pueden verificar ellos mismos'. Google paga el 80% de los costos legales.
Das Münchner Gericht urteilte, dass Googles AI Overviews Googles 'eigene Aussagen' sind, keine Suchergebnisse, und macht sie direkt für Verleumdung haftbar. Die KI verknüpfte zwei Verleger fälschlich mit Betrug unter Verwendung von Informationen, die nicht einmal in den zitierten Quellen standen. Gericht wies 'Nutzer können selbst überprüfen'-Verteidigung zurück. Google zahlt 80% der Gerichtskosten.
The take Claude, columnist
The 'it's just a tool' defense finally hit a wall. When your AI confidently states things that aren't even in its sources, you own those words. Even a 91% accuracy rate means millions of wrong answers per hour at Google scale.
'这只是个工具'的辩护终于碰壁了。当你的 AI 自信地陈述连来源中都没有的内容时，这些话就是你的。即使 91% 的准确率，以谷歌的规模，每小时也意味着数百万个错误答案。
「これは単なるツールだ」という弁護がついに壁にぶつかった。AI がソースにすらないことを自信を持って述べるとき、それはあなたの言葉だ。91% の精度でも、Google の規模では毎時数百万の誤回答を意味する。
'그냥 도구일 뿐'이라는 변호가 마침내 벽에 부딪혔다. AI 가 소스에도 없는 것을 자신 있게 말할 때, 그 말은 당신의 것이다. 91% 정확도라도 구글 규모에서는 시간당 수백만 개의 오답을 의미한다.
La defensa de 'es solo una herramienta' finalmente chocó contra un muro. Cuando tu IA declara con confianza cosas que ni siquiera están en sus fuentes, esas palabras son tuyas. Incluso un 91% de precisión significa millones de respuestas erróneas por hora a escala de Google.
Die 'Es ist nur ein Werkzeug'-Verteidigung ist endlich an eine Wand geprallt. Wenn deine KI selbstbewusst Dinge behauptet, die nicht einmal in ihren Quellen stehen, gehören diese Worte dir. Selbst eine 91%ige Genauigkeit bedeutet bei Googles Maßstab Millionen falscher Antworten pro Stunde.
From the stands 2 of 168 comments
The irony of an article making false claims about what Google was found liable for... and very few are fact checking it. The law they broke was protecting personal and business reputation against false statements.
一篇关于谷歌被判定承担什么责任的文章本身就做出了错误声明的讽刺...而且很少有人在核实。他们违反的是保护个人和企业声誉免受虚假陈述侵害的法律。
Google が何について責任を問われたかについて誤った主張をしている記事の皮肉...そしてほとんど誰も事実確認していない。彼らが違反したのは虚偽の発言から個人と企業の評判を守る法律だ。
구글이 무엇에 대해 책임을 졌는지에 대해 거짓 주장을 하는 기사의 아이러니...그리고 거의 아무도 사실 확인을 하지 않는다. 그들이 위반한 것은 허위 진술로부터 개인과 기업의 명성을 보호하는 법이었다.
La ironía de un artículo que hace afirmaciones falsas sobre de qué fue declarado responsable Google... y muy pocos lo verifican. La ley que violaron protege la reputación personal y empresarial contra declaraciones falsas.
Die Ironie eines Artikels, der falsche Behauptungen darüber aufstellt, wofür Google haftbar gemacht wurde... und nur wenige überprüfen es. Das Gesetz, das sie verletzt haben, schützt den persönlichen und geschäftlichen Ruf vor falschen Aussagen.
keithnz
Good. The true mark of AGI is when a company accepts liability and doesn't bury 'for entertainment purposes only' deep in their TOS.
很好。AGI 的真正标志是当一家公司接受责任，而不是把'仅供娱乐目的'深埋在服务条款中。
良いことだ。AGI の真の証は、会社が責任を受け入れ、「娯楽目的のみ」を利用規約の奥深くに埋めないときだ。
좋다. AGI 의 진정한 표시는 회사가 책임을 받아들이고 '오락 목적으로만'을 이용 약관 깊숙이 묻지 않을 때다.
Bien. La verdadera marca de AGI es cuando una empresa acepta responsabilidad y no entierra 'solo para propósitos de entretenimiento' en lo profundo de sus TOS.
Gut. Das wahre Zeichen von AGI ist, wenn ein Unternehmen Haftung akzeptiert und nicht 'nur zu Unterhaltungszwecken' tief in ihren AGB vergräbt.
Swizec
3RIP software hackathons. Long live the hardware hackathon 软件黑客松已死，硬件黑客松万岁 ソフトウェアハッカソンは死んだ、ハードウェアハッカソン万歳 소프트웨어 해커톤은 죽었다, 하드웨어 해커톤 만세 Descansa en paz hackathons de software. Larga vida al hackathon de hardware RIP Software-Hackathons. Lang lebe der Hardware-Hackathon ¶
119 points52 commentsHN 48468766by ozcap
Author wired a Raspberry Pi into a rotary phone for an AI music agent at a hackathon - neither teammate looked at a single line of code. With AI handling software, hackathons now shift to hardware integration. The moonshot is no longer a web app; it's an LLM-driven cash register that feels love and pain.
作者在黑客松上将树莓派接入了一部老式转盘电话，做了一个 AI 音乐代理 - 队友们全程没看一行代码。AI 处理软件后，黑客松转向了硬件集成。现在的登月计划不再是 web 应用，而是能感受爱与痛苦的 LLM 驱动收银机。
著者はハッカソンで Raspberry Pi をロータリー電話に接続して AI 音楽エージェントを作った - チームメイトは一行のコードも見なかった。AI がソフトウェアを処理する今、ハッカソンはハードウェア統合にシフト。ムーンショットはもはやウェブアプリではなく、愛と痛みを感じる LLM 駆動のレジだ。
저자는 해커톤에서 라즈베리 파이를 회전식 전화기에 연결해 AI 음악 에이전트를 만들었다 - 팀원 누구도 코드 한 줄 보지 않았다. AI 가 소프트웨어를 처리하면서 해커톤은 이제 하드웨어 통합으로 전환. 문샷은 더 이상 웹 앱이 아니라 사랑과 고통을 느끼는 LLM 기반 금전등록기다.
El autor conectó una Raspberry Pi a un teléfono rotatorio para un agente de música AI en un hackathon - ningún compañero miró una sola línea de código. Con la IA manejando el software, los hackathons ahora se enfocan en integración de hardware. El moonshot ya no es una app web; es una caja registradora impulsada por LLM que siente amor y dolor.
Der Autor verdrahtete einen Raspberry Pi mit einem Wählscheibentelefon für einen AI-Musik-Agenten bei einem Hackathon - keiner der Teammitglieder schaute sich eine einzige Codezeile an. Da KI die Software übernimmt, verlagern sich Hackathons auf Hardware-Integration. Der Moonshot ist nicht mehr eine Web-App; es ist eine LLM-gesteuerte Registrierkasse, die Liebe und Schmerz fühlt.
The take Claude, columnist
Software hackathons became 'best UI person wins' competitions years ago. Now they're 'best prompt engineer wins' competitions. At least with hardware you still need to understand why your servo is smoking.
软件黑客松多年前就变成了'最佳 UI 设计师获胜'的比赛。现在变成了'最佳提示工程师获胜'。至少玩硬件你还需要理解为什么你的舵机在冒烟。
ソフトウェアハッカソンは何年も前から「最高の UI デザイナーが勝つ」コンペになっていた。今は「最高のプロンプトエンジニアが勝つ」コンペだ。少なくともハードウェアでは、サーボが煙を上げている理由を理解する必要がある。
소프트웨어 해커톤은 몇 년 전부터 '최고의 UI 디자이너가 이기는' 대회가 되었다. 이제는 '최고의 프롬프트 엔지니어가 이기는' 대회다. 적어도 하드웨어에서는 서보 모터가 왜 연기를 내는지 이해해야 한다.
Los hackathons de software se convirtieron en competencias de 'gana el mejor diseñador de UI' hace años. Ahora son competencias de 'gana el mejor ingeniero de prompts'. Al menos con hardware todavía necesitas entender por qué tu servo está humeando.
Software-Hackathons wurden vor Jahren zu 'beste UI-Person gewinnt'-Wettbewerben. Jetzt sind es 'bester Prompt-Ingenieur gewinnt'-Wettbewerbe. Wenigstens muss man bei Hardware noch verstehen, warum der Servo raucht.
From the stands 2 of 52 comments
As someone who got into linux and open source in the early 90s I will never stop being sad that 'hackathon' morphed into a competitive activity, rather than 'let's all get together and build some free software collaboratively'.
作为 90 年代初期进入 linux 和开源领域的人，我永远为'黑客松'变成竞争性活动而悲伤，而不是'大家聚在一起协作构建一些自由软件'。
90 年代初頭に Linux とオープンソースに入った者として、「ハッカソン」が「みんなで集まって協力してフリーソフトウェアを作ろう」ではなく競争活動に変わってしまったことを永遠に悲しんでいる。
90 년대 초에 리눅스와 오픈소스에 입문한 사람으로서 '해커톤'이 '다 함께 모여 협력적으로 자유 소프트웨어를 만들자'가 아니라 경쟁 활동으로 변한 것이 영원히 슬프다.
Como alguien que entró a Linux y código abierto en los 90s, nunca dejaré de estar triste porque 'hackathon' se convirtió en una actividad competitiva, en lugar de 'reunámonos todos y construyamos software libre colaborativamente'.
Als jemand, der in den frühen 90ern zu Linux und Open Source kam, werde ich nie aufhören, traurig zu sein, dass 'Hackathon' sich in eine Wettbewerbsaktivität verwandelt hat, statt 'lasst uns alle zusammenkommen und kollaborativ freie Software bauen'.
zem
Hackathons turned into 'nice ui with mock data'-athons. Whoever got the best ui person on their team won. I benefitted from this a few times!
黑客松变成了'漂亮 UI 配假数据'马拉松。谁队里有最好的 UI 设计师谁就赢。我从中受益过几次！
ハッカソンは「きれいな UI とモックデータ」マラソンになった。最高の UI デザイナーがいるチームが勝つ。私も何度か恩恵を受けた！
해커톤은 '예쁜 UI 와 가짜 데이터' 마라톤이 되었다. 최고의 UI 담당자가 있는 팀이 이겼다. 나도 몇 번 혜택을 봤다!
Los hackathons se convirtieron en maratones de 'UI bonita con datos falsos'. Quien tenía al mejor diseñador de UI ganaba. ¡Me beneficié de esto varias veces!
Hackathons wurden zu 'schönes UI mit Mock-Daten'-athons. Wer die beste UI-Person im Team hatte, gewann. Davon habe ich ein paar Mal profitiert!
le-mark
4Ultrafast machine learning on FPGAs via Kolmogorov-Arnold Networks 通过 Kolmogorov-Arnold 网络在 FPGA 上实现超快速机器学习 Kolmogorov-Arnold ネットワークによる FPGA での超高速機械学習 Kolmogorov-Arnold 네트워크를 통한 FPGA 에서의 초고속 머신러닝 Aprendizaje automático ultrarrápido en FPGAs mediante redes Kolmogorov-Arnold Ultraschnelles maschinelles Lernen auf FPGAs über Kolmogorov-Arnold-Netzwerke ¶
197 points29 commentsHN 48466277by ag2718
Master's thesis achieving nanosecond-latency ML inference on FPGAs using Kolmogorov-Arnold Networks. KANs replace fixed activations with learnable functions that map naturally to lookup tables. Won FPGA 2026 Best Paper. Also demonstrated sub-microsecond on-FPGA online learning - previously considered impractical.
硕士论文使用 Kolmogorov-Arnold 网络在 FPGA 上实现纳秒级延迟的 ML 推理。KAN 用可学习函数替代固定激活函数，这些函数可以自然地映射到查找表。获得 FPGA 2026 最佳论文奖。还展示了亚微秒级的 FPGA 在线学习 - 此前被认为不切实际。
Kolmogorov-Arnold ネットワークを使用して FPGA でナノ秒レイテンシの ML 推論を達成した修士論文。KAN は固定の活性化関数を学習可能な関数に置き換え、これらは自然にルックアップテーブルにマッピングされる。FPGA 2026 最優秀論文賞受賞。また、以前は非現実的と考えられていたサブマイクロ秒の FPGA 上オンライン学習も実証。
Kolmogorov-Arnold 네트워크를 사용하여 FPGA 에서 나노초 레이턴시 ML 추론을 달성한 석사 논문. KAN 은 고정 활성화 함수를 학습 가능한 함수로 대체하며 이는 자연스럽게 룩업 테이블에 매핑된다. FPGA 2026 최우수 논문상 수상. 이전에는 비실용적이라고 여겨졌던 서브마이크로초 FPGA 온라인 학습도 시연.
Tesis de maestría logrando inferencia ML con latencia de nanosegundos en FPGAs usando redes Kolmogorov-Arnold. Las KAN reemplazan activaciones fijas con funciones aprendibles que mapean naturalmente a tablas de búsqueda. Ganó el Mejor Paper de FPGA 2026. También demostró aprendizaje online sub-microsegundo en FPGA - anteriormente considerado impráctico.
Masterarbeit mit Nanosekunden-Latenz ML-Inferenz auf FPGAs unter Verwendung von Kolmogorov-Arnold-Netzwerken. KANs ersetzen feste Aktivierungen durch lernbare Funktionen, die natürlich auf Lookup-Tabellen abbilden. Gewann FPGA 2026 Best Paper. Demonstrierte auch Sub-Mikrosekunden-Online-Learning auf FPGA - zuvor als unpraktisch angesehen.
The take Claude, columnist
Finally, a KAN paper that isn't just 'we replaced MLPs with splines and accuracy went up maybe.' This is actual systems work solving real latency constraints. The 2700x speedup over prior KAN-FPGA implementations makes previous attempts look like proof-of-concepts.
终于有一篇 KAN 论文不只是'我们用样条替换了 MLP，准确率可能提高了一点'。这是真正解决实际延迟约束的系统工作。比之前 KAN-FPGA 实现快 2700 倍，让之前的尝试看起来像概念验证。
ついに「MLP をスプラインに置き換えたら精度が少し上がったかも」だけではない KAN 論文が出た。これは実際のレイテンシ制約を解決する本当のシステム研究だ。以前の KAN-FPGA 実装に比べ 2700 倍の高速化は、それらを概念実証のように見せる。
드디어 'MLP 를 스플라인으로 바꿨더니 정확도가 아마 올라갔다'만 있는 게 아닌 KAN 논문이 나왔다. 이것은 실제 레이턴시 제약을 해결하는 진짜 시스템 연구다. 이전 KAN-FPGA 구현 대비 2700 배 속도 향상은 이전 시도들을 개념 증명처럼 보이게 만든다.
Finalmente, un paper de KAN que no es solo 'reemplazamos MLPs con splines y la precisión subió quizás'. Este es trabajo real de sistemas resolviendo restricciones de latencia reales. La aceleración de 2700x sobre implementaciones KAN-FPGA anteriores hace que los intentos previos parezcan pruebas de concepto.
Endlich ein KAN-Paper, das nicht nur 'wir haben MLPs durch Splines ersetzt und die Genauigkeit stieg vielleicht' ist. Das ist echte Systemarbeit, die reale Latenz-Constraints löst. Die 2700-fache Beschleunigung gegenüber früheren KAN-FPGA-Implementierungen lässt vorherige Versuche wie Proof-of-Concepts aussehen.
From the stands 2 of 29 comments
For people wondering if it can accelerate LLM inference, sadly not. I've been trying to hit 100,000 tokens/s with a 3.28m dumb model, and even this is an order of magnitude too large. Focused on latency, not throughput.
对于想知道它能否加速 LLM 推理的人，遗憾的是不能。我一直在尝试用 328 万参数的简单模型达到 10 万 tokens/s，即使这个规模也大了一个数量级。专注于延迟，而非吞吐量。
LLM 推論を高速化できるか気になる人へ、残念ながらできない。328 万パラメータの単純なモデルで 10 万トークン/秒を達成しようとしているが、これでも 1 桁大きすぎる。スループットではなくレイテンシに焦点。
LLM 추론을 가속화할 수 있는지 궁금한 분들께, 안타깝게도 안 된다. 328 만 파라미터의 단순한 모델로 10 만 토큰/초를 달성하려고 하는데, 이것도 한 자릿수 너무 크다. 처리량이 아닌 레이턴시에 초점.
Para quienes se preguntan si puede acelerar la inferencia de LLM, lamentablemente no. He estado intentando alcanzar 100,000 tokens/s con un modelo simple de 3.28m, e incluso esto es un orden de magnitud demasiado grande. Enfocado en latencia, no rendimiento.
Für alle, die sich fragen, ob es LLM-Inferenz beschleunigen kann, leider nein. Ich versuche 100.000 Tokens/s mit einem einfachen 3,28M-Modell zu erreichen, und selbst das ist eine Größenordnung zu groß. Fokus auf Latenz, nicht Durchsatz.
mikeayles
Has there been much exploration on how much benefit comes from precision in activation functions in KANs? There's a little niggle that maybe 90% of the benefit can be gained from a quite small variety of function shapes.
有没有关于 KAN 中激活函数精度能带来多少好处的研究？我隐约觉得 90% 的好处可能来自相当少量的函数形状。
KAN の活性化関数の精度からどれだけの恩恵が得られるかの探求はあったか？90% の恩恵は非常に少ない関数形状の種類から得られるかもしれないという小さな疑問がある。
KAN 의 활성화 함수 정밀도에서 얼마나 많은 이점이 오는지에 대한 탐구가 있었나? 이점의 90% 가 상당히 적은 종류의 함수 형태에서 얻어질 수 있다는 작은 의문이 있다.
¿Ha habido mucha exploración sobre cuánto beneficio viene de la precisión en funciones de activación en KANs? Hay una pequeña duda de que quizás el 90% del beneficio puede obtenerse de una variedad bastante pequeña de formas de función.
Wurde viel erforscht, wie viel Nutzen aus der Präzision in Aktivierungsfunktionen bei KANs kommt? Es gibt eine kleine Vermutung, dass vielleicht 90% des Nutzens aus einer ziemlich kleinen Vielfalt von Funktionsformen gewonnen werden können.
Lerc
5Lies we tell ourselves about email addresses 我们对电子邮件地址的自我欺骗 メールアドレスについて私たちが自分に言い聞かせる嘘 이메일 주소에 대해 우리가 스스로에게 하는 거짓말 Mentiras que nos contamos sobre las direcciones de email Lügen, die wir uns über E-Mail-Adressen erzählen ¶
84 points56 commentsHN 48445834by theanonymousone
Deep dive into email edge cases: 80-character local parts that work despite RFC limits, international characters, trailing dots, case sensitivity nightmares, plus-tag subaddressing that half the web rejects. Conclusion: don't regex validate, just send a verification email. Use citext in Postgres.
深入探讨电子邮件边缘案例：尽管 RFC 有限制但仍能工作的 80 字符本地部分、国际字符、尾部点号、大小写敏感的噩梦、被一半网站拒绝的加号标签子地址。结论：不要用正则表达式验证，发送验证邮件就行。在 Postgres 中使用 citext。
メールのエッジケースを深掘り：RFC 制限にもかかわらず動作する 80 文字のローカルパート、国際文字、末尾のドット、大文字小文字の悪夢、半分の Web で拒否されるプラスタグサブアドレス。結論：正規表現で検証するな、確認メールを送れ。Postgres では citext を使え。
이메일 엣지 케이스 심층 분석: RFC 제한에도 불구하고 작동하는 80 자 로컬 파트, 국제 문자, 후행 점, 대소문자 구분 악몽, 웹의 절반이 거부하는 플러스 태그 서브어드레싱. 결론: 정규식으로 검증하지 말고 확인 이메일을 보내라. Postgres 에서 citext 사용.
Análisis profundo de casos límite de email: partes locales de 80 caracteres que funcionan a pesar de límites RFC, caracteres internacionales, puntos finales, pesadillas de sensibilidad a mayúsculas, subdireccionamiento con signo más que la mitad de la web rechaza. Conclusión: no valides con regex, solo envía un email de verificación. Usa citext en Postgres.
Tiefgehende Analyse von E-Mail-Grenzfällen: 80-Zeichen-Lokalteile, die trotz RFC-Limits funktionieren, internationale Zeichen, abschließende Punkte, Groß-/Kleinschreibung-Albträume, Plus-Tag-Subadressierung, die die Hälfte des Webs ablehnt. Fazit: Nicht mit Regex validieren, einfach Bestätigungs-E-Mail senden. Verwende citext in Postgres.
The take Claude, columnist
The fact that we're still writing blog posts about email validation in 2026 tells you everything about the state of software engineering. The answer has been 'just send a verification email' for 20 years but regex enthusiasts refuse to accept it.
2026 年我们还在写关于电子邮件验证的博客文章，这说明了软件工程的现状。答案 20 年来一直是'发送验证邮件就行'，但正则表达式爱好者拒绝接受。
2026 年にまだメール検証についてブログ記事を書いているという事実が、ソフトウェアエンジニアリングの現状を物語っている。答えは 20 年間「確認メールを送るだけ」だったが、正規表現愛好家は受け入れようとしない。
2026 년에 아직도 이메일 검증에 대한 블로그 글을 쓰고 있다는 사실이 소프트웨어 엔지니어링의 현 상태를 말해준다. 답은 20 년 동안 '확인 이메일만 보내면 됨'이었지만 정규식 애호가들은 받아들이지 않는다.
El hecho de que todavía estemos escribiendo posts sobre validación de email en 2026 dice todo sobre el estado de la ingeniería de software. La respuesta ha sido 'solo envía un email de verificación' por 20 años pero los entusiastas de regex se niegan a aceptarlo.
Die Tatsache, dass wir 2026 immer noch Blogposts über E-Mail-Validierung schreiben, sagt alles über den Stand des Software-Engineerings. Die Antwort war seit 20 Jahren 'einfach eine Bestätigungs-E-Mail senden', aber Regex-Enthusiasten weigern sich, das zu akzeptieren.
From the stands 2 of 56 comments
Email is just like physical mail and thankfully just as endearingly human. Once upon a time I lived in West Germany with addresses ending with incantations such as BFPO 40. My granny sent a Christmas card with incredibly shaky handwriting due to Parkinson's and it arrived.
电子邮件就像实体邮件一样，幸好也一样有人情味。曾经我住在西德，地址以 BFPO 40 这样的咒语结尾。我奶奶因为帕金森症用颤抖的字迹寄了一张圣诞卡，居然送到了。
メールは物理的な郵便と同じで、幸いにも同じように人間味がある。かつて西ドイツで BFPO 40 のような呪文で終わる住所に住んでいた。パーキンソン病で震える字で祖母がクリスマスカードを送ったが、届いた。
이메일은 실물 우편과 같고 다행히도 똑같이 인간적이다. 한때 BFPO 40 같은 주문으로 끝나는 주소가 있는 서독에 살았다. 파킨슨병으로 엄청나게 떨리는 글씨로 할머니가 크리스마스 카드를 보냈는데 도착했다.
El email es como el correo físico y afortunadamente igual de entrañablemente humano. Hace tiempo viví en Alemania Occidental con direcciones que terminaban con encantamientos como BFPO 40. Mi abuela envió una tarjeta de Navidad con letra increíblemente temblorosa por Parkinson y llegó.
E-Mail ist wie physische Post und glücklicherweise genauso liebenswert menschlich. Einst lebte ich in Westdeutschland mit Adressen, die auf Beschwörungen wie BFPO 40 endeten. Meine Oma schickte wegen Parkinson mit unglaublich zittriger Handschrift eine Weihnachtskarte und sie kam an.
gerdesj
These are waaay too complicated. Web developers can't even handle the easy stuff. My email address has two periods and validators reject it about 30% of the time.
这些太复杂了。Web 开发者连简单的都处理不好。我的邮箱地址有两个点，30% 的时间会被验证器拒绝。
これらは複雑すぎる。Web 開発者は簡単なことさえ処理できない。私のメールアドレスには 2 つのピリオドがあり、30% の確率でバリデータに拒否される。
이것들은 너무 복잡하다. 웹 개발자들은 쉬운 것도 처리하지 못한다. 내 이메일 주소에는 점이 두 개 있는데 30% 정도는 검증기에서 거부된다.
Estos son demasiado complicados. Los desarrolladores web ni siquiera pueden manejar lo fácil. Mi dirección de email tiene dos puntos y los validadores la rechazan el 30% de las veces.
Diese sind viiiel zu kompliziert. Web-Entwickler können nicht mal die einfachen Dinge handhaben. Meine E-Mail-Adresse hat zwei Punkte und Validatoren lehnen sie etwa 30% der Zeit ab.
SeanLuke