2025 06 28 HackerNews

2025-06-28 Hacker News Top Stories #

英国航空公司飞行员James Harding创建了交互式飞行图表和地球仪，展示他的飞行历史。

Gemma 3n是为移动和边缘设备设计的多模态模型，支持图像、音频、视频和文本输入输出，性能优化显著。

XSLT被提出为一种原生、零配置的网络构建系统，适用于静态网站生成，但存在功能和性能上的局限性。

“Alternative Layout System"提供了一系列脚本，用于创建独特的文本排版效果，如等宽字体和去除连字符。

美国经济第一季度收缩0.5%，主要原因是特朗普的进口关税政策导致商业活动受扰。

Rust编译器较慢的原因在于宏和泛型的复杂性，这些特性增加了代码量和编译时间。

提出在Web平台上增加声明式的DOM模板API，以提高开发效率、安全性和性能。

人工智能可能导致人类思维同质化，削弱创造力和批判性思维能力。

Matrix 1.15版本发布，改进了认证、房间摘要和富文本话题功能。

Starcloud公司声称通过单次发射建造太空数据中心的目标在技术和经济上存在重大问题。

Show HN: I’m an airline pilot – I built interactive graphs/globes of my flights #

https://jameshard.ing/pilot

James Harding 是一位自 2023 年起在英国航空公司担任空客 A350 飞机的副驾驶，他的工作基地位于伦敦希思罗机场。在此之前，他自 2016 年起驾驶空客 A320 系列飞机，基地分别在希思罗和盖特威克。他的职业生涯中有一个亮点是与他的父亲一起飞行，他的父亲是英国航空公司 A350 的机长。James Harding 通过 2014 年英国航空公司的学员计划加入，其中包括在西班牙安达卢西亚的 FTEJerez 完成的综合 ATPL 课程。他的飞行之旅始于加拿大，在那里他获得了滑翔机飞行员执照、教练评级以及通过加拿大空军学员奖学金获得的私人飞行员执照。

他使用 LogTen Pro 数字记录所有航班，这使他能够使用 SQL 查询并用信息图表格式展示。他最喜欢的是 GitHub 风格的飞行历史。他还构建了一些地球仪可视化，以 3D 形式展示他的飞行日志。外圈显示飞往每个国家的航班数量，每个环带显示从特定其他国家飞往一个国家的航班数量。由于定位/空驶航班，一些目的地的出发或到达航班数量并不相等。从葡萄牙到西班牙的单一航班是由于天气恶劣，从马德拉岛改飞特内里费岛。

他还制作了多个 3D 地球仪可视化，展示了他的飞行日志的各个方面：按国家、机场分类的航班等。他每年在飞机上的时间是多少？在航空业，我们从“刹车松开”到“刹车关闭”记录时间。一些缩写定义：P1/PIC：机长；P1US/PICUS：机长，监督下；P2：第二飞行员；Heavy：“额外”的飞行员在长途旅行中。在英国航空公司，P1 和 P2 航班通常由机长和副驾驶共享，而担任 P1 的人“运行”该航班。在整个航班中，机长始终是指挥官，但副驾驶被授权在监督下作为 PIC 做出决策并运行航班。英国航空公司的标准操作程序还规定，每次进近都作为监控进近飞行。在下降顶部，P2 将成为飞行飞行员，并在 1000 英尺 AGL 处飞行进近，P1 将重新控制着陆。

最后，James Harding 是一位空客 A350 飞行员和计算机工程师，他建造软件，环游世界，并偶尔记录他的其他爱好。

HN 热度 998 points | 评论 159 comments | 作者：jamesharding | 12 hours ago #

https://news.ycombinator.com/item?id=44396518

飞行员需要记录飞行日志，有人使用纸质日志，而作者数字化记录并创建了数据可视化和 3D 地球仪来展示飞行历史。
作者的数据存储在 SQLite 文件中，并且分享了如何从日志软件中提取数据的帖子链接。
有人提到了六边形网格文章，与作者的地球仪地图相似。
有人询问作者是否看过 Nathan Fielder 的《排练》第二季，该剧喜剧性地探讨了飞行员与副驾驶之间的沟通问题，并询问作者对剧中描绘的沟通摩擦的看法。
有人从软件设计和用户体验的角度赞扬了作者使用的日志软件，并提到软件是由热爱航空和用户体验的人开发的。
有人提到了使用 Uber 的 H3 库来处理六边形。
有人分享了一个视频链接，与作者的地球仪类似。
有人对作者详细的飞行日志表示赞赏，并从自己开发的方向和向量状态演化库的角度得到了灵感。
有人提到了 LLM 编写的代码库，并讨论了四元数在 3D 旋转操作中的一些优点。
有人表示对多个领域都有专业知识的人感到钦佩，并希望自己也能在业余时间做其他事情。
有人表达了对软件开发高薪酬的遗憾，因为对其他领域也感兴趣，但很难放弃高薪去全职从事其他领域。
有人提到，根据地区和职位，飞行员的薪酬可能并不如软件开发高。
有人建议即使不能成为飞行员，也可以尝试学习飞行，因为成本对于技术行业的人来说是可行的。
有人对飞行的热爱表示共鸣，并鼓励他人学习飞行。
有人提到了可以输入特定航班信息并告知总辐射暴露的网站，这对于飞行人员来说是一个有用的功能。
有人提到了 Nomadlist 网站，该网站也有辐射暴露的统计数据。

Introducing Gemma 3n #

https://developers.googleblog.com/en/introducing-gemma-3n-developer-guide/

这篇文章介绍了 Gemma 3n，这是 Gemma 模型的最新版本，专为移动设备和边缘设备设计的人工智能模型。以下是文章的详细中文摘要：

Gemma 3n 的发布标志着在设备 AI 的一个重大进步，它将强大的多模态能力带到边缘设备上，性能达到了去年基于云端的前沿模型的水平。Gemma 3n 的设计得到了开发者社区的支持，支持包括 Hugging Face Transformers、llama.cpp、Google AI Edge、Ollama、MLX 等多种工具，使得开发者可以轻松地为特定的设备应用进行微调和部署。

Gemma 3n 的新特性包括：

多模态设计：Gemma 3n 原生支持图像、音频、视频和文本输入以及文本输出。
设备优化：Gemma 3n 模型以效率为核心，提供两种大小的模型：E2B 和 E4B。虽然它们的原始参数量分别为 5B 和 8B，但通过架构创新，它们的内存占用与传统的 2B 和 4B 模型相当，分别只需要 2GB（E2B）和 3GB（E4B）的内存即可运行。
突破性架构：Gemma 3n 的核心是 MatFormer 架构，这是一种新颖的嵌套变换器，用于弹性推理。MatFormer 架构允许在一个更大的模型中包含更小的、完全功能的子模型，类似于俄罗斯套娃。这种设计不仅扩展了 Matryoshka 表示学习的概念，还涵盖了所有变换器组件。
质量提升：Gemma 3n 在多语言性（支持 140 种语言的文本和 35 种语言的多模态理解）、数学、编码和推理方面都有质量提升。E4B 版本在 LMArena 得分超过 1300，成为第一个达到此基准的 10 亿参数以下的模型。

文章还详细介绍了 MatFormer 架构，它允许开发者直接下载和使用 E4B 模型或独立的 E2B 子模型，或者使用 Mix-n-Match 方法创建介于 E2B 和 E4B 之间的自定义大小模型。此外，Gemma 3n 模型还采用了 Per-Layer Embeddings（PLE）技术，这使得模型在不增加设备加速器（GPU/TPU）所需的高速内存占用的情况下，显著提高模型质量。Gemma 3n 还引入了 KV Cache Sharing 功能，以加速流式响应应用的时间到第一个标记的处理。

最后，Gemma 3n 在音频理解方面也有所突破，使用基于通用语音模型（USM）的先进音频编码器，该编码器每 160 毫秒的音频生成一个标记，大约每秒 6 个标记，为语音转文本和翻译提供了支持。

HN 热度 386 points | 评论 183 comments | 作者：bundie | 1 day ago #

https://news.ycombinator.com/item?id=44389202

Gemma 3n 与之前的 gemma3 完全兼容，可以直接用于微调脚本
Gemma 3n 在单 GPU 上使用 Lora 时的显存占用比 gemma-4B 少
Gemma 3n 支持图像、音频、视频和文本输入以及文本输出，但无法生成图像和音频输出
Gemma 3n 与 Ollama 和 mlx-vlm 在不同量化大小下生成的 SVG 图像结果不同
Gemma 3n 作为一个文本模型，能够输出 SVG，挑战生成复杂图像的能力
Gemma 3n 的基准测试虽然起初是作为玩笑，但后来发现与模型性能有相关性
ASCII 艺术与 SVG 在编码视觉表示方面有相似之处，但 SVG 的结果更可预测
Gemma 3n 能够理解 SVG 规范，知道如何绘制复杂形状，但实际表现不佳
Gemma 3n 的性能可能受到训练数据中缺乏“如何在 SVG 中绘制复杂形状”的内容的影响
Gemma 3n 的基准测试可能很快会被新的 LLMs“更了解”
Gemma 3n 与 Gemini 在不需要网络访问方面相似，但 Gemini 需要通过 Google 批准的运行时进行交互
Gemma 3n 可以商业使用，而 Gemini Nano 的权重不能直接商业使用
语言模型权重的版权问题不明确，可能因司法管辖区而异，美国版权局的官方立场是模型权重可能不具备版权性
英国的版权标准较宽松，可能认为模型权重具有版权性，许多国家倾向于遵循英国而非美国的版权法

XSLT – Native, zero-config build system for the Web #

https://github.com/pacocoursey/xslt

这个网页是一个关于 XSLT（可扩展样式表语言转换）的博客文章，由作者 Paco 撰写。文章讨论了 XSLT 作为一种原生的、零配置的网络构建系统，特别是针对静态网站。作者提到，许多静态网站是通过数据（如.json、.md、.txt 文件）和构建系统（如 Hugo、Next.js、Astro 等）来创建的，最终输出为静态 HTML 页面。

作者表达了对现代构建系统的复杂性的不满，并希望能够去除框架，回归简单的 HTML 和 CSS，使用 HTTP、URI 和 HTML 等神圣的规范。但是，如果没有构建系统，就意味着需要手动编写大量的 HTML，尤其是当网站页面增多，需要在所有页面上重复使用相同的头部和尾部时，复制粘贴虽然简单，但并不适用于未来页面数量激增的情况。

作者考虑过使用 HTML 导入和 Web 组件，但这些方法要么不存在，要么需要 JavaScript 引擎。在长时间的思考和对其他项目的工作后，作者想到了使用网络浏览器作为构建系统的可能性。网络浏览器已经能够理解许多格式，如 text/html、text/markdown 和 application/xml。作者通过学习网络浏览器的工作原理，如何构建好的 URL，以及电子邮件的工作原理，最终发现了 XSLT，这是一种用于使 XML 文档更美观的技术。

文章中，作者展示了一个 XML 博客帖子的例子，并解释了如何通过添加一个样式表引用来将其转换为 HTML。XSLT 允许作者使用循环、变量和导入等构建系统所需的功能，并且可以直接从父 XML 文档中获取动态数据。作者通过在 XML 文件中打开博客.xml 并使用 Safari 浏览器，展示了如何将 XML 转换为 HTML 输出。

最后，作者认为，虽然 XSLT 不是完美的解决方案，也不是所有事情的替代品，但它是网络开发者工具箱中的另一个工具。作者感谢旧思想、规范和网络浏览器，作为一切的中心。文章还提到了资源链接和关于原生网络构建系统（XML+XSLT）的更多信息。

HN 热度 376 points | 评论 309 comments | 作者：_kush | 20 hours ago #

https://news.ycombinator.com/item?id=44393817

XSLT 1.0 仍然是主流，但功能有限且与新标准相比显得奇怪
XSLT 模板的性能问题难以解决，因为 XSLT 是图灵完备的函数式语言，性能抽象化严重
尽管有新的 XSLT 标准，但 XSLT 1.0 的学习曲线陡峭但优雅，而新标准失去了这种优雅
新的 XSLT 和 XPath 标准没有得到广泛的采用，因为它们失去了旧版本的优雅，保留了丑陋的语法
很多人更愿意使用 XPath 库和其他通用编程语言来解决问题，而不是 XSLT
XSLT 作为 Web 原生系统具有普遍支持的价值，但缺乏像 JavaScript 那样的良好浏览器调试功能
有人提出将 XSLT 作为更友好语言的编译目标，以改善其可用性
有人提到了 libslax，这是一种更友好的 XSLT 替代语法
XML 作为数据结构需要非 XML 序列化，类似于语义网的 Owl 有多种序列化方式
有人提到 XQuery 接近于“具有合理语法的 XSLT”
浏览器对 XSLT 的支持仍然停留在 1.0 版本，尽管 XSLT 3.0 已经存在 8 年了
有人寻找非 Saxon 的 XSLT 处理器，希望有开源选项
有人提到了 libxslt，但它只支持 XSLT 1.0 和部分 EXSLT，并不推荐使用

Alternative Layout System #

https://alternativelayoutsystem.com/scripts/#same-sizer

这个网页介绍了一个名为“Alternative Layout System”的脚本集合，这些脚本用于创造独特的文本排版效果。以下是各个脚本的中文摘要：

Same Sizer：这个脚本应用了等宽字体的原则，即每个字符占据相等的水平空间，扩展到整个单词。无论单词的长度或字母数量如何，每个单词都会占据相同的水平空间，从而创造出结构化和对齐的外观。
Wiggle Out：遵循阿什肯纳兹希伯来手稿和某些古兰经文本的传统，这个脚本将过大而无法适应文本块的单词旋转到页边距中。形成的曲线可以调整为更加或不那么明显。它还提供了一个直线端结束的版本。
Fill the Space：这个脚本模仿了某些手稿中使用的方法，即用各种元素（如简单的或波浪形的笔划、重复最后一个字母、标点符号、装饰性的斜线、句号等）填充行尾单词与文本块末端之间的空间。它允许你用一个或多个你选择的字形填充这个空间，或者通过重复行尾的最后一个字母。
Hyphen Out：为了消除连字符，“Hyphen Out"脚本（重新）合并了连字符分隔的单词，并将第二部分放置在文本框架之外。可以调整结果部分的大小（百分比）和对齐方式。
Hyphenator： “Hyphenator” InDesign 脚本通过避免单词断行来增强文本流动和可读性。它减小了行尾最后一个单词的最后一个字母的大小，确保它们能够适应可用空间。
Last is First：这个脚本提供了下一行将出现的单词的预览，这是一些希伯来手稿中看到的现象。
Ext. Word & Letter：这个脚本经常用于希伯来手稿中，特别是用于抄写圣经文本，它扩展了行尾的最后一个字母或最后一个单词。为了对抗 InDesign 规定的 1000% 最大放大限制，建议选择矢量化选项，以便框架的右侧完美对齐。
Variable Gradient： “Variable Gradient"脚本通过计算在所选轴上的两个极端之间的中间值，在文本块中创建渐变效果。结果可以逐字或逐字形应用。

网页还提供了这些脚本的下载链接，以便用户可以下载并使用这些脚本来创造独特的排版效果。

HN 热度 358 points | 评论 60 comments | 作者：smartmic | 1 day ago #

https://news.ycombinator.com/item?id=44390501

“Same Sizer"的设计因为字符被机械拉伸导致每行宽度不同而显得难看，理想情况下应该保持每行宽度一致，只拉伸位置。
越南书法中拉丁字母与类似中文的书写风格结合，提供了一个更好的“所有单词大小相同”原则的应用实例。
即使能读懂中文，也无法将图片中的拉丁字母识别为拉丁文字，因为每个字母都被转换成了中文字符的组成部分。
页面上的“Summary”部分提供了一个正常字体的版本，从“Tân niên”开始，并且有趣地提供了中文版本。
“hoa"被风格化为类似の口亽的样式。
“square”写作方法中，“Hangulatin”字体是最有趣的例子，它结合了韩文和拉丁字母的特点。
类似书法的书写方式给人留下了深刻印象。
链接失效，无法查看示例。
在 Firefox 浏览器中浏览页面几乎导致 CPU 过载，尽管视觉效果很好。
在 Mac M1 上，即使打开了很多标签页和其他应用程序，浏览页面也没有问题。
偶尔遇到一些看似愚蠢但实际上非常天才的事物，让人感到快乐。
朗读时声音立刻变得机械化。
在非拼音语言中，尤其是英语，这些方法很痛苦，尤其是"Last is First”。
“i.e.“代表“即”，而"e.g.“代表“例如”，两者不能互换使用。
阅读更像是模式识别而不是逐字解析。
通过切换阅读模式，可以提高阅读速度而不损失理解。
英语是拼音文字，尽管书写系统不规律，但字母仍然代表声音。
“Last Is First"对于抄写文本的人来说可能像是一种校验和，以防止他们失去位置。
想要“Hyphenator”布局，但希望不仅仅是一个单词。

US economy shrank 0.5% in the first quarter, worse than earlier estimates #

https://apnews.com/article/economy-tariffs-trump-gdp-shrink-86d1f15e66c646ac4ce88ffc0a956942

根据美国商务部的报告，2025 年第一季度美国经济以年化速度收缩了 0.5%，这一数据比之前的估计（下降 0.2%）更为糟糕。这一经济萎缩主要是由于唐纳德・特朗普总统实施的进口关税政策暂时扰乱了商业活动。

在 2024 年最后三个月经济增长为 2.4% 后，第一季度的 GDP 下降标志着经济三年来首次收缩。进口在这一季度大幅增长，达到 37.9%，是自 2020 年以来的最快增速，这一增长几乎使 GDP 下降了 4.7 个百分点。与此同时，消费者支出也显著放缓，仅增长 0.5%，而在去年第四季度增长了 4%。消费者对经济前景的担忧加剧，预计关税将直接影响他们的财务状况。

根据消费者信心指数的报告，6 月份美国人的经济看法恶化，消费者信心指数降至 93，较上月下降 5.4 点，显示出人们对未来收入、商业状况和就业市场的短期预期变得更加悲观。前美联储经济学家克劳迪亚・萨姆表示，消费者支出的下调可能是一个潜在的警示信号。

此外，反映经济基本强度的一个类别在第一季度的年增长率为 1.9%，虽为正增长，但比去年第四季度的 2.9% 有所下降，也低于之前估计的 2.5%。这一类别包含消费者支出和私人投资，但排除了出口、库存和政府支出等波动性因素。同时，联邦政府支出以 4.6% 的年化速度下降，创下自 2022 年以来的最大降幅。

特朗普的贸易政策导致贸易赤字增加，而贸易赤字在计算 GDP 时会减少国内生产的总值。这意味着进口被视为消费者支出或商业投资，必须从 GDP 中扣除，以免人为地提高国内生产的数字。

预计第一季度的进口激增在第二季度不会重演，因此不会对 GDP 造成负担。经济学家们预测，第二季度的经济增长将反弹至 3%。关于 2025 年 4 月至 6 月的 GDP 增长的初步数据将于 7 月 30 日公布。

HN 热度 354 points | 评论 159 comments | 作者：Aloisius | 1 day ago #

https://news.ycombinator.com/item?id=44390454

GDP 下降部分原因是由于进口增长导致，而之前对 GDP 的估计没有充分考虑到这一点
GDP 计算公式为 GDP = C + I + G + (X - M)，其中 C 是消费支出，I 是商业投资，G 是政府支出，(X - M)是净出口
美国对中国提高关税导致进口减少，降低了 GDP，而降低关税后进口激增，GDP 受影响
政府可能会操纵经济指标作为政治工具，导致数据失真
失业率和消费者支出/GDP 等经济指标被用来衡量政治成功，但可能被操纵
在 COVID 期间，全因死亡率是比 COVID 归因死亡更好的指标，因为任何归因于 COVID 的死亡都代表了公共卫生政策的失败
存在一些不受政治干预的、提供详细经济和社会数据的资源，如 FRED
尽管存在详细的数据，但媒体的叙事可能会扭曲公众对经济指标的理解
人们对经济指标的信任度下降，希望有反映现实且不易被操纵的指标
即使数据容易获取，但公众对数据的理解和信任度受到媒体叙事和政治家解释的影响

Why is the Rust compiler so slow? #

https://sharnoff.io/blog/why-rust-compiler-slow

这篇文章讨论了作者在尝试使用 Docker 部署 Rust 网站时遇到的编译速度慢的问题。以下是文章的中文摘要：

作者的网站主要由一个 Rust 二进制文件提供服务。长期以来，每次想要更改网站，作者都需要构建一个新的静态链接二进制文件，然后将其复制到服务器并重启网站，这个过程并不理想。因此，作者希望转向使用容器（无论是 Docker、Kubernetes 还是其他）来部署网站，以匹配过去十年中大多数软件的部署方式。但问题是，使用 Docker 进行快速 Rust 构建并不简单。

文章更新提到，作者首次在 Bluesky 上发布这篇文章后，收到了一些有益的讨论和建议，特别是来自 Piotr Osiewicz 和 Wesley Moore 的建议，这些建议节省了大量的时间。

文章详细介绍了在 Docker 中使用 Rust 的基本方法，包括如何将 Rust 程序放入容器中。通常情况下，这涉及到从一个包含 Rust 环境的 Docker 镜像开始构建，然后添加依赖项，复制代码，构建项目，并将最终的二进制文件包含在最终的镜像中。但这种方法会在每次有变化时从头开始重建一切，导致构建时间长达 4 分钟。

为了解决这个问题，作者使用了 Luca Palmieri 的 cargo-chef 工具，它可以预构建所有依赖项作为一个单独的 Docker 构建缓存层，这样只有代码库的变化才会触发代码库的重新编译，而不是依赖项。这个工具通过创建一个简化的“食谱”文件来实现，该文件可以从当前工作区生成，并可以“烹饪”以缓存依赖项，而不会因为工作区的变化而失效。

尽管使用了 cargo-chef，但构建速度的提升并不如预期，大部分时间仍然花在最终的二进制文件构建上。作者通过 cargo –timings 命令和 rustc 的自分析功能（通过 -Zself-profile 标志）来进一步分析和诊断问题，以便找出编译过程中的瓶颈所在。

文章最后，作者通过一些容器操作技巧，将 cargo 构建的时间报告和 rustc 自分析的输出文件从构建容器中提取出来，以便进一步分析。作者发现，尽管 cargo build –timings 提供了每个 crate 编译所需的时间信息，但在这里，他们只关心最终 crate 的编译时间。通过这些分析，作者希望能够找到提高 Rust 编译速度的方法。

HN 热度 272 points | 评论 376 comments | 作者：Bogdanp | 1 day ago #

https://news.ycombinator.com/item?id=44390488

Rust 项目的依赖关系并不直接反映在感知到的项目大小上
宏和泛型是导致 Rust 编译慢的原因之一，它们可以迅速增加代码量
Rust 的这些特性使得代码更简洁，但可能导致生态系统显得慢
在小型程序中，Rust 的编译时间与 C 相比如何，存在不同观点
Rust 编译器性能与类型深度呈指数关系，GraphQL 等技术加剧了这一问题
TypeScript 适合 GraphQL，因为它可以减少编译器性能问题
编译器在构建时做的工作越多，构建时间就越长
静态链接并不慢，而是生成的代码量多导致编译慢
动态链接的历史原因和现代问题，如 Docker 的普及，影响了对静态链接的看法

The time is right for a DOM templating API #

https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/

这篇文章由 Justin Fagnani 于 2025 年 6 月 26 日发表，主题是关于在 Web 平台上增加一个声明式的模板 API 的提议。文章首先强调了 Web 平台的成功，尤其是 DOM API 的重要性，它使得 Web 从一个静态文档查看器转变为一个高度动态和富有表现力的运行时环境。尽管 DOM 有时受到批评，但它无疑是一个强大的 API，这一点从众多复杂和动态的 Web 应用程序中就可以看出，例如 Photoshop 这样的复杂应用也可以作为 Web 应用存在，并且其整个用户界面都是用 Web 组件构建的。

文章指出，尽管 DOM 很强大，但它缺少现代 Web 开发中最重要和最受欢迎的特性之一：模板。目前，标准 DOM API 中没有一种符合人体工程学的方式来从数据创建 DOM 节点块，添加事件监听器，设置元素属性，并且安全地防止 XSS 攻击；然后使用新数据高效地更新该块。

文章接着讨论了声明式模板的流行和基础原因，包括它们比命令式 DOM API 有更好的人体工程学，更容易防止 XSS 攻击，性能可能比手写代码更快，静态分析更容易，并且可以进行高效的服务器端渲染。

然后，文章提出了当前情况的问题，即 Web 平台没有满足几乎所有 Web 应用程序的一个核心需求。作者认为 Web 平台应该适应并满足这些明显展示的开发人员需求，但在模板方面还没有做到。缺乏模板对所有人都有实际后果：用户可能会遭受更长的应用下载时间、渲染开销或不安全的应用；开发者需要依赖库来完成许多基本操作；框架更难构建，因为它们需要实现模板；平台在与对几 kB 不敏感的原生平台竞争时也受到了影响。

文章认为现在是添加模板 API 的好时机，因为框架已经为我们铺平了道路，我们对用户模板语法和反应性模型的理解比 13 年前要好得多。此外，还有许多“纯”开发者和 Web 组件社区对符合人体工程学的 DOM 操作和反应性 API 的需求。

文章最后指出，我们知道模板的好语法是什么样子，流行的客户端模板系统在语法上都有根本的相似之处，即使是基于 HTML 的（如 Vue、Angular、Svelte）和基于 JavaScript 的（如 React、Lit、Solid）系统也是如此。这些系统在语义上也非常相似，大多数系统都返回一个 DOM 描述，然后使用单独的渲染函数调用来应用这个描述。文章还提到，我们可以使用内置的 JavaScript 特性来嵌入 DLS，如 HTML：标记模板文字，因此我们可以在不添加新特性的情况下描述 DOM 模板。

HN 热度 200 points | 评论 205 comments | 作者：mdhb | 1 day ago #

https://news.ycombinator.com/item?id=44390452

有人对“我们知道模板的好语法是什么样的”表示怀疑，认为好的模板更多是视觉而非符号的。
有人认为 Dreamweaver 和 Photoshop 之所以成功，是因为它们更符合设计师的视觉需求。
有人觉得尝试重新创造 XSLT 是徒劳的，因为总会有人想要模板化不规范但可以组合成规范的内容。
有人希望有更少的尝试去适应标准文档布局的模板，因为人们会不遗余力地重现绝对定位的效果。
有人对 XSLT 表示赞赏，认为它是 XML 生态系统中的一个杀手级特性，尽管 XML 在某些领域表现不佳。
有人认为 XSLT 之所以失败是因为它是一个真正的领域特定语言（DSL），而且是一个声明式的、纯函数式的 DSL。
有人指出 XSLT 的弱点是其优势的延伸，它是第一个被广泛采用的同构、纯函数式语言。
有人提出 XSLT 的语法问题，因为 XSLT 就是 XML，如果使用 S 表达式，语法可能会稍微好一些。
有人觉得 XSLT 和 CSS、HTML 之间存在双重关系，它们的不同外观避免了混淆。
有人提到 XSLT 的同构性可能会带来麻烦，CSS 和 HTML 的外观完全不同，因此不会有混淆的问题。
有人提到 XSLT 的模式匹配类似于传统的 FP 类型系统中的编译器管理的模式匹配，但 XSLT 的模式匹配是简单的：给出一个模式，在输入中查找它并处理每个匹配项。

A.I. Is Homogenizing Our Thoughts #

https://www.newyorker.com/culture/infinite-scroll/ai-is-homogenizing-our-thoughts

这篇文章讨论了人工智能，特别是大型语言模型（L.L.M.）如 ChatGPT 对我们思维方式和创造力的影响。文章开头提到了麻省理工学院进行的一项实验，该实验将 50 多名波士顿地区的大学生分为三组，要求他们根据广泛的提示写 SAT 风格的论文。一组只依靠自己的大脑，第二组可以使用谷歌搜索查找相关信息，第三组可以使用 ChatGPT。实验中，所有学生都戴着嵌入电极的头戴设备，以测量他们的大脑活动。结果显示，使用 ChatGPT 的学生比其他两组显示出更少的大脑活动，他们的大脑不同部分之间的连接更少，与创造力相关的 α 连接和与工作记忆相关的 θ 连接也更少。一些使用 L.L.M.的学生对他们所写的论文没有任何所有权感，80% 的学生无法引用他们所谓的写作内容。

文章进一步指出，L.L.M.用户产生的文本倾向于使用共同的词汇和想法，这导致人工智能的使用产生了同质化效果。SAT 提示旨在引发多种回应，但人工智能的使用却使得输出变得非常相似。对于“什么让我们真正快乐”的问题，L.L.M.用户比其他组更可能使用与职业和个人成功相关的短语。在关于慈善的问题上，ChatGPT 组一致支持，而其他组的论文则包含了对慈善的批评。Kosmyna 表示，使用 L.L.M.时，不会生成不同的观点，而是产生了一种平均化的现象。

文章最后指出，人工智能是一种平均技术：大型语言模型被训练以在大量数据中发现模式；它们产生的答案是趋于共识的，无论是在写作质量上（常常充满陈词滥调和平庸）还是在思想水平上。当然，其他更旧的技术也帮助并可能削弱了作家——可以说，SparkNotes 或计算机键盘也是如此。但随着人工智能的出现，我们能够如此彻底地外包我们的思考，使我们变得更加平均。文章暗示，任何使用 ChatGPT 来撰写婚礼祝酒词、起草合同或写大学论文的人，就像麻省理工学院的实验一样，正在经历一种认知成本。

HN 热度 194 points | 评论 68 comments | 作者：thoughtpeddler | 1 day ago #

https://news.ycombinator.com/item?id=44391247

一些人认为，人工智能可能导致那些在最近几年之前没有发展出批判性思维能力的人变得愚蠢。
有人认为，即使在高技能领域工作的人，也往往在理解复杂概念方面表现不佳。
有人担心，过度依赖人工智能会让自己变得更笨，特别是在创作和词汇方面。
有人认为，人工智能并没有让人们变笨，而是暴露了现有的愚蠢。
有人指出，社交媒体已经极大地同化了我们的思想，使得我们很难在没有他人启发的情况下形成自己的意见。
有人提出，创建线下俱乐部可能是对抗这种同质化的解决方案。
有人担忧，人工智能的同质化是由营利实体策划的，这可能对它们的商业模式有利，但对现实构成威胁。
有人质疑，亿万富翁资本家也生活在这个世界中，他们的行为虽然可能造成伤害，但这种伤害通常是可预测的，而人工智能行为可能导致用户做出疯狂的事情，这种伤害的形式和程度都是不可预测的。

Matrix v1.15 #

https://matrix.org/blog/2025/06/26/matrix-v1.15-release/

Matrix 1.15 版本发布

Matrix 1.15 版本于 2025 年 6 月 26 日发布，带来了对认证、房间摘要和富文本话题的改进。新一代的认证 MSCs（由 MSC3861 领导）在几个月前开始进入最终评论期，并在今天的发布中合并，这要归功于 Kévin Commaille 的慷慨贡献。

文章概述了发布带来的 10 个 MSCs 的亮点，并在文末附上完整的变更日志。

新一代认证

过去几年，Matrix 在设计、实施和部署行业标准的 OIDC 认证方面投入了大量努力。尽管 MSCs 最初在 2022 年开放，但在 2023 年成为焦点，概述了系统的预期工作方式，为今年 110 million matrix.org 用户在短短 30 分钟内迁移奠定了基础。随着 MSCs 成为规范的一部分，Matrix 2.0 的发布又迈进了一步。Matrix 2.0 的其余部分仍需一段时间才能完全纳入规范，但在此期间也在取得进展。MSC 爱好者还应关注一些对下一代认证系统的增强提案，这些提案将在未来一段时间内逐步纳入规范。

房间摘要

MSC3266 以各种形式存在了很长时间（包括短暂地在生产中使用，哎呀 🙈），最终被纳入规范。客户端可以使用新端点获取关于他们尚未完全参与的房间的更丰富信息，为用户在邀请、敲门和 matrix.to 链接上提供更好的体验。大多数客户端已经实现了支持，但如果你的客户端在未加入房间的上下文方面需要更好的支持，这可能是他们需要的缺失部分。

感谢 Nico 多年来的耐心等待和最终推动规范本身。

富文本话题

得益于 MSC3765 的规范落地，房间现在可以大胆使用列表，尽情发挥。一些房间已经利用这一点为用户提供友好的话题链接，现在所有房间都可以使用稳定的标识符以最丰富的方式代表他们的房间。在底层，该功能使用可扩展事件，但由于健康的回退支持，避免了对新房间版本的需求——客户端被鼓励在可扩展事件（慢慢）向规范发布之前尝试不同的渲染方法。

感谢 Johannes 在规范中实现了这个高度请求的功能。

完整的变更日志

Matrix 1.15 的完整变更日志包括：

客户端-服务器 API

新端点：根据 MSC3266 添加 GET /_matrix/client/v1/room_summary/{roomIdOrAlias}。（#2125）
新端点：根据 MSC2965 添加 GET /_matrix/client/v1/auth_metadata。（#2147）
向后兼容的变更：根据 MSC3765 添加 m.topic 内容块，以在 m.room.topic 事件中启用富文本。（#2095）
根据 MSC4147 将设备密钥与 Olm 加密事件一起包含。（#2122）
根据 MSC3266 扩展/_matrix/client/v1/room_summary/{roomIdOrAlias}，并扩展/_matrix/client/v1/rooms/{roomId}/hierarchy，添加新的可选属性 allowed_room_ids、encryption 和 room_version。（#2125, #2158）
添加基于 OAuth 2.0 的认证 API，根据 MSC3861 及其子提案。（#2141, #2148, #2149, #2150, #2151, #2159, #2164）
规范澄清：当 m.room.topic 事件的 topic key 缺失、为空或 null 时的行为。（#2068）
修正 GET /sync 端点示例和多个地方使用的 m.room.member 示例。（#2077）
澄清第三方邀请的格式，包括身份服务器公钥可以使用标准或 URL 安全 base64 编码的事实。（#2083）

服务器-服务器 API

向后兼容的变更：根据 MSC3765 添加 m.topic 内容块，以在 m.room.topic 事件中启用富文本。（#2095）
根据 MSC3266 扩展/_matrix/federation/v1/hierarchy/{roomId}，并添加新的可选属性 encryption 和 room_version。（#2125）
规范澄清：邀请端点的说明，如果主服务器已经在房间中，本地用户的邀请可能会通过联合接收两次。（#2067）

应用服务 API

规范澄清：在应用服务注册模式中澄清 url: null 的行为。（#2130）

身份服务 API

规范澄清：公钥可以使用标准或 URL 安全 base64 编码。（#2083）

推送网关 API

无重大变更。

房间版本

无重大变更。

附录

无重大变更。

内部变更/工具

规范澄清：调整渲染端点的边距。（#2081）
替换 OpenAPI 输出中的 Hugo 短代码。（#2088）
向规范添加已知资金募集清单 URL，以授权 https://matrix.org/funding.json。由 @HarHarLinks 贡献。（#2115）
修复生成历史规范时的历史信息框。（#2123）
更新带有现代 matrix.org 链接的头部导航菜单。由 @HarHarLinks 贡献。（#2137）

Matrix.org 基金会需要你

Matrix.org 基金会是一个非营利组织，仅依赖捐赠运作。其核心使命是维护 Matrix 规范，但它所做的远不止这些。它维护 matrix.org 主服务器，并免费托管多个桥接服务。它为我们的数字隐私和尊严的集体权利而战。

HN 热度 188 points | 评论 113 comments | 作者：todsacerdoti | 1 day ago #

https://news.ycombinator.com/item?id=44390740

Matrix 在 5 年内不断改进，用户对其持续发展持乐观态度
Hacker News 社区倾向于负面评论，解决问题比发现问题困难
有人认为 Matrix 和 Signal 解决不同的问题，两者不应相互比较
有人认为人们基于自己的选择形成观点而非基于信息做出决策
Element Web 的一些功能被移除或限制，如通知中心和房间搜索
Element Web 的性能问题被用户诟病，如高内存消耗和加载缓慢
Element X Web（Aurora）的推出有望改善性能问题
用户对 Matrix 作为 IRC 跳板的功能被移除表示失望
用户对 Matrix 的端到端加密群组通话功能表示认可
用户对 Matrix 和 Element 的持续工作表示感谢，并期待其未来的发展
用户对 Element X 平台上的加密通话实现表示疑惑，询问是否已在非 Element X 平台上实施
用户质疑在用户依赖某个功能后移除该功能是否明智
用户对 Matrix 协议改进对客户端用户体验提升的必要性表示认可，但也关心这是否是吸引用户最快的方式

Starcloud can’t put a data centre in space at $8.2M in one Starship #

https://angadh.com/space-data-centers-1

这篇文章是一篇关于 Starcloud 公司提出的太空数据中心（SDC）项目的技术分析文章。文章首先指出，Starcloud 声称通过单次 100 吨的 Starship 发射，可以以 820 万美元的成本建立一个 40 兆瓦的太空数据中心（SDC）。然而，作者的分析发现，这在单次发射中是不可行的，实际上需要多达 22 次发射。

Starcloud 公司声称可以通过单次 100 吨的 Starship 发射，以 820 万美元的成本建立一个 40 兆瓦的太空数据中心（SDC）。作者通过技术分析发现，这一目标在单次发射中无法实现，实际上需要多达 22 次发射。SDC 的太阳能板需要 4 次发射，这是基于国际空间站（ISS）上现有太阳能板的分析得出的。同样，根据 ISS 的散热器基准，SDC 的热管理系统需要 13 次发射。服务器架需要额外的 5 次发射。作者没有分析微流星体/辐射屏蔽和轨道组装对发射次数的影响，因为这些需要未公开的规格和任务架构，可能尚未完全开发。关于发射成本，白皮书错误地假设发射成本为每公斤 30 美元。这使得他们与地面数据中心的经济比较脱离现实。一些专家推测，每公斤 1000 美元可能是一个乐观的发射成本，这意味着每次发射成本为 1 亿美元，总成本为 1.032 亿美元。即使成本降至每公斤 500 美元，单次发射的总成本也将达到 5320 万美元，而不是声称的 820 万美元。如果需要第二次发射，最坏情况下的成本将达到 2 亿美元，这比他们报告的地面数据中心运行成本还要高。

文章讨论了在地球上运行的数据中心依赖现有电网，这些电网主要使用化石燃料或地面太阳能。最近，技术人员和企业家提出将数据中心放置在太空中，以解决地面数据中心的三个问题：能源需求巨大、废热产生和房地产瓶颈。Sam Altman 也提出了核能作为解决方案，但从能源和气候角度来看，这可能是一个更理想的解决方案，但需要解决监管障碍。从监管角度来看，太空可能是一个更快的答案，但交付千兆瓦级的 SDC 需要在公里级别上工程太阳能板，这并不容易。即使是 Starcloud 用来与地面数据中心（TDC）基准的 40 兆瓦系统，也需要一个边长为 357 米的正方形，这将远远超过有史以来建造的最大空间结构——国际空间站（ISS）最长尺寸约为 100 米。

作者在空间领域有一定的专业知识，特别是在设计用于空间组装的大型空间望远镜任务和分析方面。

文章讨论了在空间组装大型结构的挑战，包括房地产、冷却（热管理）和碳足迹问题。Starcloud 的目标是实现一个 5 吉瓦的集群，太阳能板跨度为 4 公里乘 4 公里，这将成为空间中最大的结构，需要在空间中组装。在地球上，数据中心使用空气（对流）和水冷却（传导），但在太空中，热管理需要辐射，这效率较低——在真空中不可能进行对流，而水可以提取中心的热量，但随后冷却加热的水将面临另一个问题。

文章分析了 Starcloud 的商业案例，他们提出了一个表格，显示在地球上运行一个 40 兆瓦数据中心集群十年的总成本为 1.67 亿美元，而在太空中为 820 万美元；发射是 Starcloud 总成本中最大的贡献者，他们假设一次发射就足够了，但作者对此表示怀疑。文章还指出，白皮书中关于发射成本的计算是错误的，他们声称的每公斤 30 美元的成本实际上是每公斤 50 美元，这意味着他们的发射成本增加了 300 万至 500 万美元。

这篇文章提供了对 Starcloud 太空数据中心项目的深入技术分析，并对该项目的经济可行性提出了质疑。

HN 热度 185 points | 评论 312 comments | 作者：angadh | 1 day ago #

https://news.ycombinator.com/item?id=44390781

太空数据中心的维护成本高昂，需要考虑自主对接、机器人系统、能量供应、通信和冷却系统等。
太空数据中心需要定期发射包含替换硬件的火箭和持续的地面支持人员来处理故障。
硬件故障率遵循浴缸曲线，长时间内故障率低，可以通过增加冗余而不是更换部件来降低成本。
通过在发射前进行硬件老化测试，可以减少太空中的故障率。
太空数据中心的热管理是一个挑战，需要大量的热管将热量从芯片传递到散热器。
太空数据中心的冗余问题比地球上更为复杂，需要更多的备份系统。
可以考虑使用一群更便宜、更简单的独立服务器卫星或机架卫星，通过无线电或微波通信网连接。
将数据中心放在一个封闭的压力容器中，保持 1 大气压，像在地球上一样循环空气，可以简化热管理问题。
增加小型卫星的数量会增加冷却的表面积，但也增加了太空垃圾撞击的风险。