2025-10-20

42 篇热帖

1. Major AWS Outage Happening (old.reddit.com)

Well, looks like we have a dumpster fire on DynamoDB in us-east-1 again.

3. Servo v0.0.1 (github.com)

Servo v0.0.1 项目摘要

项目概述 Servo 是一个用 Rust 语言编写的原型网页浏览器引擎项目。其核心目标是实现并行化处理,以提升性能和安全性。

支持的开发平台 Servo 目前支持在以下 64 位操作系统上进行开发和构建:

  • macOS
  • Linux
  • Windows
  • OpenHarmony
  • Android

社区与协作 项目欢迎所有人参与贡献。开发协调通过以下方式进行:

  • 文档与资讯:参阅《Servo Book》了解文档,访问 servo.org 获取新闻和指南。
  • 问题与讨论:在 GitHub Issues 上进行任务协调,在 Servo Zulip 频道进行日常交流,以及通过在项目仓库中公告的视频会议进行沟通。

环境配置与构建指南 详细构建说明请查阅《Servo Book》。以下为各平台核心步骤:

  • macOS

    1. 安装 Xcode 和 Homebrew。
    2. 安装 uvrustup
    3. 重启终端。
    4. 运行 ./mach bootstrap 安装其他依赖。
    5. 运行 ./mach build 构建 servoshell
  • Linux

    1. 根据发行版安装 curl
    2. 安装 uvrustup
    3. 重启终端。
    4. 运行 ./mach bootstrap 安装其他依赖。
    5. 运行 ./mach build 构建 servoshell
  • Windows

    1. 下载并安装 uvchocorustup。在 Visual Studio 安装程序中需勾选“快速安装”。
    2. 确保在 Visual Studio Installer 中安装了以下组件:
      • Windows 10/11 SDK (版本 >= 10.0.19041.0)
      • MSVC v143 - VS 2022 C++ x64/x86 生成工具(最新版)
      • 适用于最新 v143 生成工具的 C++ ATL (x86 和 x64)
    3. 重启终端。
    4. 运行 .\mach bootstrap 安装其他依赖。
    5. 运行 .\mach build 构建 servoshell
  • Android

    1. 设置环境变量 ANDROID_SDK_ROOTANDROID_NDK_ROOT
    2. 安装最新的 Android 命令行工具至指定目录。
    3. 使用 sdkmanager 命令安装必要的组件(包括构建工具、模拟器、NDK 等)。
    4. 后续步骤需遵循所在主机平台(macOS/Linux/Windows)的构建说明。
  • OpenHarmony

    1. 首先按照主机平台的说明准备环境。
    2. 根据目标发行版(如 HarmonyOS NEXT 或纯 OpenHarmony)设置相应的环境变量,包括 DEVECO_SDK_HOMEOHOS_BASE_SDK_HOMEOHOS_SDK_NATIVE 以及应用签名配置文件路径 SERVO_OHOS_SIGNING_CONFIG
    3. 详细构建说明请参考项目中的《Building for OpenHarmony》文档。
    4. 可通过向 mach 命令传递 --flavor=<default|harmonyos> 参数来修改目标发行版。
4. DeepSeek OCR (github.com)

DeepSeek-OCR 是一个旨在探索视觉文本压缩边界的模型,专注于从大语言模型(LLM)中心视角研究视觉编码器的作用。

重要发布

  • 2026/01/27:发布了 DeepSeek-OCR2
  • 2025/10/23:DeepSeek-OCR 获得上游 vLLM 的官方支持。
  • 2025/10/20:首次发布 DeepSeek-OCR。

环境与安装

  • 环境要求:CUDA 11.8 + PyTorch 2.6.0。
  • 安装步骤:克隆仓库,使用 Conda 创建 Python 3.12.9 环境,然后安装 PyTorch、特定版本的 vLLM(v0.8.5)、项目依赖以及 flash-attn。

推理与使用 该模型支持两种主要的推理框架:

  1. vLLM 推理:支持图像和PDF文件处理,并提供批量评估脚本。已集成到上游 vLLM 中,可通过标准方式调用,并支持流式输出。
  2. Transformers 推理:通过加载模型和分词器进行推理,支持多种提示词(prompt)模式。

支持模式与提示示例 模型支持多种分辨率模式:

  • 原生分辨率:Tiny (512×512)、Small (640×640)、Base (1024×1024)、Large (1280×1280)。
  • 动态分辨率:Gundam 模式。 可根据不同任务使用不同提示词,例如:
  • 文档转Markdown:<image>\n<|grounding|>Convert the document to markdown.
  • 图像OCR:<image>\n<|grounding|>OCR this image.
  • 无布局OCR:<image>\nFree OCR.
  • 解析图表:<image>\nParse the figure.
  • 图像描述:<image>\nDescribe this image in detail.
  • 定位文本:<image>\nLocate <|ref|>目标文本<|/ref|> in the image.

致谢与引用 项目感谢了 Vary, GOT-OCR2.0, MinerU 等提供的模型和想法,并使用了 Fox, OminiDocBench 等基准。相关论文已发布于 arXiv。

5. AWS Multiple Services Down in us-east-1 (health.aws.amazon.com)

AWS Health Dashboard 是一个用于查看 AWS 服务整体状态和运行状况的工具。通过该仪表板,用户可以监控 AWS 各项服务的实时健康信息。

6. Doing well in your courses: Andrej's advice for success (2013) (cs.stanford.edu)

文章总结:安德烈·卡帕西的课程成功建议

本文是安德烈·卡帕西为本科学生提供的课程学习指南,核心在于高效学习、充分备考,并平衡学业与长远发展。

一、 通用原则

  • 睡眠优先:不建议熬夜。充足睡眠(作者建议约7.5小时)有助于记忆巩固。长期、分散的学习比考前突击更有效。
  • 参与辅导课:即使课程质量一般,其本身能促使你思考材料,就有价值。
  • 提前学习:为考试预留充足时间(如期中约3天,期末约6天),让大脑有时间消化。

二、 考试准备策略

  • 制定计划:明确所有需掌握的知识点并列出清单,合理分配时间,避免前期拖沓。
  • 研究过往试卷:在学习前先查看往届试题,了解出题风格和重点,指导学习方向。
  • 主动输出:阅读和理解不等于能复现。必须合上书本,尝试自己推导公式、证明,确保真正掌握。
  • 协作学习:初期独立学习,后期与他人讨论。与不同程度的同学交流,向他人讲解是最好的学习方式。
  • 联系教授:考前至少去一次教授的答疑时间,可能获得有价值的信息。
  • 强化练习:对于数学等科目,通过大量练习题巩固知识,比单纯阅读更有效。
  • 制作“小抄”:即使不允许带入考场,将课程精髓浓缩在一两页纸上,是极佳的复习总结。
  • 选择学习环境:在有他人学习的安静场所(如图书馆)学习,避免背景噪音干扰。

三、 考试当日

  • 饮食:建议在考试前约2小时摄入咖啡因和食物,避免考前立即摄入。
  • 利用短期记忆:考前最后30-45分钟应进行高强度复习,不要提前放松。

四、 考试中技巧

  • 用铅笔作答:便于修改。
  • 浏览全卷:开始前快速浏览所有题目,了解题量和难度。
  • 先易后难:跳过卡住的题目,完成其他部分后再回头,有时思路会更清晰。
  • 卷面整洁:工整的书写和清晰的格式有助于获得高分。
  • 明确标出答案:用方框或圆圈明确标出最终答案,方便阅卷。
  • 绝不提前交卷:利用所有时间检查错误、优化答案呈现(如擦除错误步骤、补充证明细节)。
  • 与阅卷者沟通:通过笔记展示你的解题思路,即使未能得出完整答案。
  • 注意分值分配:根据题目分值合理分配时间,避免在难题小分题上耗费过多精力。
  • 最后五分钟检查:停止攻克难题,转而确保所有题目均已作答,没有遗漏。

五、 超越课程的建议(核心观点)

  • 成绩非首要目标:除成绩过差外,无人过度关注你的分数。追求所有课程85分左右的合理高分即可,避免过度学习。
  • 时间宝贵,聚焦长远:将节省下来的时间投入更重要的事情:
    • 获取实际经验:参与真实项目、实习、研究或开源贡献。
    • 建立人际网络:让教授了解你,争取能写有力推荐信(强调你的主动性、激情和独立思考能力)的人。
    • 创造有形成果:完成并记录你的项目、撰写博客。这些经历比成绩更能决定未来的发展机会。
    • 切忌轻言放弃:参与研究或项目时,要持之以恒,半途而废会严重损害你的声誉。
7. Entire Linux Network stack diagram (2024) (zenodo.org)

Linux 网络栈完整架构图 (2024) 摘要

该图表由 Ericsson Nikola Tesla 发布(版本 v7),全面描绘了 Linux 网络栈的整体结构,涵盖从应用层到物理网卡的各个层次,并包含优化与统计提示。其主要内容如下:

  • 虚拟化与容器支持:包括操作系统级虚拟化(如容器)以及模拟和准虚拟化技术。
  • 网络套接字:应用程序与网络协议栈之间的接口。
  • 网络协议栈
    • 上层:实现如 TCP、UDP 等传输层协议。
    • 底层:包含用于提升性能的关键功能,如通用接收卸载 (GRO)、接收数据包转向 (RPS)、接收流转向 (RFS) 和通用分段卸载 (GSO)。
  • 网络调度器:负责管理数据包发送队列。
  • 网络过滤与流量控制:涉及 NetFilter 框架、以及如网桥 (Bridge)、绑定 (Bond) 和 TAP 等网络接口。
  • 设备驱动程序:包括网络队列、新 API (NAPI) 和中断请求 (IRQ) 处理程序。
  • 网卡硬件加速功能:罗列了由网卡承担的各类网络任务,例如校验和卸载、VLAN、VxLAN、GRE、TCP 分段卸载 (TSO)、大接收卸载 (LRO) 以及接收端调节 (RSS) 等。
  • 网络接口卡 (NIC):网络栈的最底层硬件。

该图表是《操作系统与计算机网络:Linux 应用》一书的一部分,为理解和优化 Linux 网络性能提供了直观的参考。

8. BERT is just a single text diffusion step (nathan.rs)

本文探讨了BERT等掩码语言模型(MLM)与文本扩散模型之间的内在联系,并尝试通过微调RoBERTa模型来实现文本生成。

核心发现:掩码语言建模是文本扩散的特例 文章指出,离散语言扩散模型(如Google DeepMind的Gemini Diffusion)的本质,是将文本视为由逐步添加的“掩码噪声”所构成。其前向过程是按调度表随机将一部分词元替换为<MASK>,反向过程则训练模型在不同掩码率下预测被掩码的词元。作者认为,BERT的MLM目标(在固定掩码率下重建)实际上是文本扩散训练目标在单一掩码率下的特例。通过引入从0%到100%的变掩码率和对应的去噪步骤,可以将MLM转化为一个完整的生成过程。

实验:微调RoBERTa进行文本生成 作者基于此想法,使用RoBERTa模型进行了概念验证。

  1. 训练:在WikiText数据集上微调模型。每个训练批次随机采样一个掩码率(从10%到100%),并对序列中除前16个词元(作为固定上下文)外的部分进行掩码。模型的任务是预测被掩码的词元。
  2. 生成:生成过程从一个序列开始,该序列的前16个词元为提示(prompt),后续全部为<MASK>。然后按照预定的掩码率调度(例如100% -> 0%),在每一步让模型预测所有掩码位置,再根据概率采样,最后将部分词元重新掩码,进入下一步迭代。如此逐步降低掩码率,最终得到完整文本。

结果与结论

  • 实验输出表明,经过微调的RoBERTa模型能够生成连贯的文本。
  • 与GPT-2的生成质量相比,此方法生成的文本略逊一筹且速度较慢,但作为简单的概念验证项目,其结果令人惊喜。
  • 结论是,像BERT这样的掩码语言模型,通过将其训练目标重新解释为不同掩码率下的去噪任务,就可以被改造为文本生成模型。这验证了“BERT本质上是一个单步文本扩散模型”的观点。作者也指出,未来可通过改进架构、噪声类型和推理算法来提升该类模型的质量与速度。

补充说明

  • 作者后续发现已有相关研究(如DiffusionBERT、D3PM论文)提出了类似观点。
  • 实验中采用的生成算法较为简单,存在改进空间(例如基于置信度进行去掩码)。不同架构在计算特性上存在差异(如双向注意力无法使用KV缓存),其性能对比仍需进一步研究。
9. Alibaba Cloud says it cut Nvidia AI GPU use by 82% with new pooling system (www.tomshardware.com)

摘要

阿里巴巴云声称其新开发的Aegaeon pooling系统在多个月的Beta测试中,将服务大型语言模型所需的Nvidia GPU数量减少了82%。该测试在其Model Studio市场中进行,结果发表于2025年ACM操作系统研讨会(SOSP)的同行评审论文中。

Aegaeon是一个推理时调度器,旨在最大化GPU利用率,尤其适用于需求突发或不可预测的模型。与传统方式不同,该系统在令牌级别虚拟化GPU访问,允许多个模型共享同一GPU池。例如,一个Nvidia H20 GPU可同时服务多个不同模型,使系统范围内的**“goodput”(有效输出测量)比旧的无服务器系统提升高达9倍**。

测试在生产环境中持续数月,由北京大学和阿里巴巴基础设施部门的作者(包括CTO Jingren Zhou)共同完成。支持数十个不同LLM(参数高达720亿)所需的GPU数量从1,192个减少到213个。测试使用了Nvidia H20 GPU,这是在美国出口管制下中国买家仍可获得的少数加速器之一。

阿里巴巴将收益归因于两个核心技术:

  • 每个GPU上打包多个模型
  • 令牌级自动缩放器,动态分配计算资源(而非在请求级别保留资源)。

基准测试显示,Aegaeon的goodput比ServerlessLLM和MuxServe系统分别高出1.5倍至9倍

然而,论文未指定测试中使用的精确网络结构。阿里巴巴拥有自研的eRDMA弹性RDMA网络,并构建了高度集成的GPU服务栈,因此结果可能依赖于优化的垂直集成环境。尽管如此,该成果有望吸引其他超大规模云服务提供商关注,以在加速器供应受限和推理需求增长的背景下提升现有硬件效率。

10. Tell HN: AWS us-east-1 services are down

AWS us-east-1 服务中断事件摘要

事件概述:AWS的us-east-1(北弗吉尼亚)区域发生服务中断,影响了多个服务。

关键细节

  1. 用户报告:尽管AWS官方状态页面最初显示全部正常(全绿),但用户在Hacker News上报告称多个不同区域的云应用程序和Serverless框架应用已宕机。
  2. AWS官方更新:AWS后续更新了其状态页面,确认存在一个“操作问题”,影响us-east-1区域的“多个服务”。
  3. 社区反应:原帖获得大量关注(340点),相关讨论评论已转移至另一个独立的帖子页面。

总结:此事件凸显了云服务依赖的风险,即官方状态页面可能存在延迟,而用户社区的实时报告是察觉服务异常的早期关键渠道。

11. Production RAG: what I learned from processing 5M+ documents (blog.abdellatif.io)

这篇文章分享了作者在为处理超过500万份文档的生产环境构建RAG系统(检索增强生成)过程中,总结的经验教训。核心发现是,简单的原型方案在生产环境中效果不佳,需要针对性优化。

项目背景与初期挑战 作者团队分别为Usul AI(900万页)和一个法律AI企业(400万页)构建RAG系统。最初跟随教程使用Langchain和Llamaindex,快速在小数据集(100份文档)上取得了良好原型效果。但扩展到全量生产数据后,结果令人失望,随后花费数月时间重写系统才达到预期性能。

关键优化措施(按投资回报率排序)

  1. 查询生成:不依赖用户单一查询。使用LLM分析对话线程,生成多个语义和关键词查询,并行处理后交由重排序器。这扩大了信息检索的覆盖面,减少了对混合搜索计算分数的依赖。
  2. 重排序:被描述为“性价比最高的5行代码”。分块排名变化显著。理想配置是输入50个分块,重排序后输出15个,即使基础设置不佳,足够的输入分块加上重排序也能弥补。
  3. 分块策略:耗时最多的工作。需根据数据定制,确保分块:a) 不在单词或句子中间被切断;b) 每个分块是自包含的逻辑单元。
  4. 向LLM注入元数据:除了分块文本,同时输入相关元数据(如标题、作者)能显著提升上下文质量和答案准确性。
  5. 查询路由:识别无法通过RAG回答的问题(如“总结文章”、“作者是谁”),将这些请求路由至单独的API和LLM处理,避免启动完整的RAG流程。

技术栈选择

  • 向量数据库:从Azure迁移到Pinecone,最终使用Turbopuffer(成本低,原生支持关键词搜索)。
  • 文档提取:自定义。
  • 分块:默认使用Unstructured.io,企业项目中自定义(也提到Chonkie可能不错)。
  • 嵌入模型:使用text-embedding-3-large。
  • 重排序器:从无到Cohere 3.5,最终使用Zerank(效果不错)。
  • LLM:在GPT 4.1和GPT 5之间切换,最终稳定使用GPT 4.1(由Azure额度覆盖)。

开源贡献 作者将所学整合到一个开源项目 agentset-ai/agentset 中,采用MIT许可证。

12. AWS Outage: A Single Cloud Region Shouldn't Take Down the World. But It Did (faun.dev)

AWS 中断事件:单一云区域故障竟导致全球影响

事件概述

一次亚马逊网络服务(AWS)的重大中断事故,导致众多知名网站和服务陷入瘫痪,波及范围远超单一云区域,引发全球性连锁反应。

受影响的服务与行业

  • 互联网服务:亚马逊、Snapchat、Reddit、Roblox、Canva、Disney+ 等平台出现访问问题。
  • 金融与加密货币:Coinbase、Robinhood、苏格兰银行等交易所和银行服务受影响,导致交易延迟、卡片支付失败及网银无法访问。
  • 通信与生活服务:Zoom(Chime)、Instacart 等通信及配送服务受到干扰。
  • 游戏领域:多个云端游戏平台服务中断。
  • 政府与企业服务:政府网站及超过 2500 家企业业务受到冲击。

技术原因与恢复过程

  • 根本原因:此次中断由运营问题引发,具体与美国东部(US-EAST-1)区域的 DNS 解析故障有关。
  • 影响范围:超过 70 项 AWS 服务受到影响。
  • 恢复措施:AWS 团队通过多途径加速恢复,并在事故后不久观察到恢复迹象。
  • 持续影响:尽管大部分服务逐步恢复,但因请求积压,部分服务(如 Reddit)仍存在延迟和间歇性问题。

事件启示

该事件凸显了现代社会对少数大型云服务提供商的深度依赖。一旦关键云区域出现故障,可能通过数字生态系统的关联性产生广泛而剧烈的连锁反应,影响远超地理边界。

14. Postman which I thought worked locally on my computer, is down (status.postman.com)

根据提供的Postman平台状态监控页面内容,当前所有系统服务均显示为**“Operational”(正常运行)**。页面列出了以下组件及其状态:

核心平台与服务:

  • Postman Platform on Desktop(桌面端平台)
  • Postman Platform on Browser(浏览器端平台)
  • Postman Login(登录服务)
  • Postman Monitors(监控服务)
  • Postman Mocks(模拟服务)
  • Postman API Network / API Explore(API网络与探索)
  • Postman Search(搜索功能)
  • Public Collection Documentation(公共集合文档)
  • Postman Learning Center and Documentation(学习中心与文档)
  • Postman Support and Community Forum(支持与社区论坛)
  • Postman Integrations(集成服务)
  • Postman Interceptor(拦截器)
  • Marketing Website(营销网站)
  • Postman VS Code extension(VS Code扩展)
  • API Specifications(API规范)
  • Collection Runner(集合运行器)

历史事件记录: 从2026年5月18日至2026年6月1日,页面显示无任何事故报告,表明在此期间服务保持稳定。

结论: 页面状态表明Postman各项服务(包括本地桌面客户端、浏览器版及所有配套功能)均处于正常工作状态,无性能下降或服务中断记录。

15. Airliner hit by possible space debris (avbrief.com)

事件概述

美国国家运输安全委员会(NTSB)正在调查一起飞机事故,焦点集中在联合航空一架737 MAX飞机于科罗拉多州上空可能被气象气球的数据包击中的可能性。该事件导致飞行员受伤,并造成飞机挡风玻璃和机身损坏。

关键细节

  • 事件经过:飞机从丹佛飞往洛杉矶起飞后不久即被物体击中,照片显示飞行员手臂有多处割伤和划痕。飞机随后改道至盐湖城,约130名乘客转乘另一航班继续旅程。
  • 调查重点:初步报告曾怀疑是太空碎片,但调查现聚焦于气象气球载荷。因太空碎片若重返大气层,其速度可能造成更严重损坏,而此次仅单层挡风玻璃受损且未出现失压。
  • 应对措施:机组将飞行高度从36,000英尺降至26,000英尺,以减缓剩余挡风玻璃层的压力差。
  • 罕见性:此事件极为罕见,可能是首次有非故意发射的物体在该高度与飞机相撞。联合航空及美国联邦航空管理局(FAA)尚未置评。

结论

尽管具体原因仍在调查中,但此次事故凸显了高空飞行中意外撞击的罕见风险,目前无人员严重伤亡报告。

16. Docker Systems Status: Full Service Disruption (www.dockerstatus.com)

Docker 系统状态:全面服务中断

事件概述

2025年10月20日,Docker多项核心SaaS服务遭遇访问和使用中断,影响范围广泛,涉及多个产品组件。事件经过调查后,已最终得到解决。

受影响组件

  • Docker Hub 服务:包括 Docker Hub Registry、Web Services、Automated Builds、Security Scanning。
  • 认证与计费:Docker Authentication、Docker Billing。
  • 其他产品:Docker Scout、Docker Build Cloud、Testcontainers Cloud、Docker Cloud、Docker Hardened Images。

事件时间线与状态更新(按时间倒序)

  • 已解决(2025-10-20 10:05 UTC / 03:05 PDT)

    • 此次事件已宣告解决。
  • 监控中(2025-10-20 09:43 UTC / 02:43 PDT)

    • SaaS服务的错误率已开始恢复。团队正在处理积压请求并持续进行监控。
  • 问题已识别(2025-10-20 08:22 UTC / 01:22 PDT)

    • 根本原因已确定为某个云服务提供商出现问题。Docker团队正监控情况,并准备在服务提供商问题解决后全面恢复系统。
  • 调查中(2025-10-20 07:16 UTC / 00:16 PDT)

    • Docker团队确认多项产品服务出现访问和使用问题,随即开始调查。
17. Forth: The programming language that writes itself (ratfactor.com)

Forth:自我衍生的编程语言

起源与历史

Forth由查尔斯·H·摩尔于1950年代末创建,最初是为了解决大型科学计算中频繁重新编译程序的繁琐问题。他在IBM 704计算机上开发了一个简单的命令解释器,通过直接输入指令来调整程序,避免了耗时的重新编译。这种“编程程序”的思想逐渐演变成一个完整的系统。

1968年,摩尔在Mohasco Industries的IBM 1130小型机上将其命名为“Forth”(取“第四代系统”之意)。他反对专利和标准化,认为Forth应是一个可自由定制和扩展的工具箱。

核心技术特性

  • 后缀表示法(RPN):操作符位于操作数之后(如 3 4 +),表达式无需括号即可清晰嵌套。
  • 基于栈的计算:数据通过参数栈传递,操作隐式进行,减少了中间变量的命名需求,代码更简洁。
  • 可扩展性:Forth本身非常精简,核心由少量代码字(汇编实现的原语)构成。用户可以在此基础上用Forth定义新的冒号字(高级词),甚至重新定义控制结构(如 IF...THEN)和注释。
  • 词典系统:所有词(函数)存储在链表词典中,查找从最新词开始,允许重定义任何词而不破坏已有代码。
  • 自举与元编程:Forth可以用自身编写编译器、解释器乃至操作系统,形成一个高度自包含的开发环境。
  • 间接线程代码:一种高效的代码执行方式,通过存储地址列表并逐个跳转执行,兼顾了紧凑性和灵活性。

应用领域

Forth因其简洁、高效、可移植和实时交互特性,被广泛应用于:

  • 航天与深空探测:如NASA航天飞机载荷接口模块(SPAIM)、机器人臂模拟器、罗塞塔探测器及其菲莱着陆器(使用Harris RTX2010处理器)。
  • 嵌入式系统与工业控制:适用于资源受限的环境,如核电站、机器人和工业自动化。
  • 早期个人计算机:如Jupiter ACE(以Forth为操作系统)和Canon Cat。
  • 教育和创新:作为理解计算机底层和语言设计的优秀工具。

哲学与作者探索

文章作者通过移植和实现JonesForth(一个教育用的Forth),深入理解了其内部机制。他创建了实验性的Meow5(一个完全内联的Forth变体),进一步体验了Forth的设计哲学。作者强调:

  • 简单与容易的区别:Forth追求的是简单性(降低复杂度),而非容易性(降低学习难度)。
  • 路径依赖:许多Forth的设计选择(如RPN、栈、冒号定义)在实现复杂系统时被证明是阻力最小的路径。
  • 创作自由:Forth鼓励程序员根据具体硬件和问题需求,打造专属的语言扩展。

现代意义

在摩尔晚期的工作(如GreenArrays GA144多核芯片)中,Forth的理念延伸到低功耗、高并发计算领域。随着对能效和可持续计算的需求增长,Forth及其思想在物联网、嵌入式系统和未来计算模型中可能迎来新的复兴。其核心精神——通过最少抽象实现最大控制——仍然具有持久的价值。

19. Duke Nukem: Zero Hour N64 ROM Reverse-Engineering Project Hits 100% (github.com)

项目概述
这是一个针对N64游戏《Duke Nukem: Zero Hour》的逆向工程项目,已实现100%的反编译。使用此仓库前,用户必须拥有游戏合法副本。

系统依赖与安装

  • 推荐环境:Ubuntu 22.04(原生或WSL2)
  • 通过命令安装系统包:sudo apt install make git build-essential binutils-mips-linux-gnu cpp-mips-linux-gnu python3 python3-pip
  • Python工具需3.9+版本,通过pip安装依赖:pip3 install -U splat64[mips]pip3 install -r requirements.txt

构建步骤

  1. 克隆仓库(含子模块):git clone https://github.com/Gillou68310/DukeNukemZeroHour.git --recursive
  2. 将美国版ROM命名为baserom.us.z64放入仓库根目录,运行make提取ROM
  3. 再次执行make构建,成功将生成build/us/dukenukemzerohour.z64

其他版本支持

  • 法国版:将ROM命名为baserom.fr.z64,构建时添加VERSION=fr参数

Docker环境

  • 提供Docker镜像简化依赖管理,构建后通过绑定目录运行容器
  • Windows/macOS用户推荐安装Mutagen扩展以优化文件同步

调试功能

  • 仅限Windows,通过mupen64plus配合GDB调试
  • 添加MODERN=1参数编译以保留源码信息
  • 支持命令行工具及VSCode的Native Debug扩展调试

辅助工具

  • asm-differ:快速对比源码与目标汇编
  • decomp-permuter:自动调整代码并评分,解决寄存器分配问题
  • mips2c:将汇编转译为C代码
  • splat:ROM拆分工具(n64split继任者)
20. US Government Uptime Monitor (usa-status.com)

美国联邦政府正常运行时间监控器

本文以数据仪表板的形式展示了美国联邦政府自2013年以来的“正常运行”状态,核心数据是过去15年(截至信息列出时)的总体正常运行时间为 97.675146188%

主要监测事件:政府停摆 监控器重点记录了对政府正常运行造成中断的重大事件——政府停摆,具体包括:

  • 2013年10月:停摆16.0天。
  • 2018年1月:停摆2.83天。
  • 2018年12月至2019年1月:停摆34.5天(跨越年度记录)。
  • 2025年10月至11月:停摆正在进行中,持续时间已超过43天(43天1小时32分15秒)。

具体机构影响 监控器列出了多个联邦机构在停摆期间的状态及员工被迫休假的比例,显示影响程度不一:

  • 美国林务局:在历次停摆中均有高达80%或85%的员工被休假。
  • 国防部文职人员:休假比例在50%至95%之间浮动。
  • 环境保护署:在多次停摆中休假比例极高,达到95%或96%。
  • 其他机构:如国家科学基金会、史密森学会、交通部等,也记录了不同比例的员工休假情况。

重要说明 文末注明,该“美国政府正常运行时间监控器”并非美国政府的官方服务,其资金来源于“闲置的税款”。

21. AI-generated 'poverty porn' fake images being used by aid agencies (www.theguardian.com)

AI生成的“贫困色情”虚假图像被援助机构使用

全球卫生专业人士担忧,AI生成的极端贫困、儿童及性暴力幸存者的图片正涌入图库网站,并日益被主要的健康非政府组织使用,这标志着一个“贫困色情”新时代的来临。

现象与原因

  • 瑞士道德影像组织Fairpicture的诺亚·阿诺德指出,许多组织正在使用或尝试使用AI生成的图像。
  • 安特卫普热带医学研究所研究员阿谢尼·阿列尼切夫收集了超过100张被个人或非政府组织用于社交媒体活动的AI生成极端贫困图片。这些图片复制了贫困的视觉套路:如空盘子的孩子、干裂的土地等刻板场景,他称其为“贫困色情2.0”。
  • 使用量上升的原因包括对同意和成本的顾虑。AI图像成本低廉,且无需处理真人同意问题。此外,美国对非政府组织预算的削减加剧了这一趋势。

平台与图片内容

  • AI生成的贫困图像大量出现在Adobe Stock Photos和Freepik等热门图库网站,搜索“贫困”即可出现数十张结果,例如“难民营中逼真的孩子”、“亚洲儿童在充满垃圾的河中游泳”、“白人志愿者在非洲村庄为黑人儿童提供医疗咨询”等。这些图像常带有种族主义色彩,强化了对非洲或印度等地的最差刻板印象。
  • Freepik首席执行官华金·阿贝拉表示,极端图像的使用责任在于媒体消费者,而非平台。图像由平台全球用户社区生成,用户在被购买时可获得许可费。尽管平台曾尝试通过注入多样性和性别平衡来减少偏见,但阿贝拉承认作用有限:“这就像试图弄干海洋。我们做出努力,但如果全球客户想要特定风格的图像,任何人也无能为力。”

非政府组织使用案例

  • 国际计划组织荷兰分部于2023年发布了一段反对童婚的视频活动,其中包含AI生成的带伤女孩、老年男子和怀孕少女的图像。该组织发言人表示,现已采纳指南,建议避免使用AI描绘单个儿童,并称此前使用AI图像是为了“保护真实女孩的隐私和尊严”。
  • 联合国去年在YouTube发布了一段包含AI生成的冲突中性暴力“重现场景”的视频,其中包括布隆迪女性被强奸的AI生成证词。该视频在被联系评论后已被下架。联合国维和部发言人表示,视频展示了“对AI的不当使用”,可能带来信息完整性风险。

专家担忧与影响

  • 阿列尼切夫指出,这些图像极度种族化,应被禁止发布。他担心,在全球卫生传播中使用偏见图像可能使问题恶化,因为这些图像会流入更广泛的互联网并被用于训练下一代AI模型,从而放大偏见
  • 非政府组织通讯顾问凯特·卡多尔对这些图像感到恐惧,并表示“对贫困人群进行更道德代表的斗争现已延伸到虚拟领域,这令人悲伤”。
  • 该现象引发了关于伦理影像和贫困与暴力故事尊严化讲述的长期辩论。阿诺德认为,使用现成的AI视觉图像看似更简单,因为它无需真人同意。
22. How much Anthropic and Cursor spend on Amazon Web Services (www.wheresyoured.at)

Anthropic与Cursor在Amazon Web Services上的巨额支出分析

核心数据

  • Anthropic 2024年AWS总支出:13.59亿美元(估计收入4-6亿美元),AWS支出超过收入的226%
  • Anthropic 2025年1-9月AWS支出:26.6亿美元(同期估计收入25.5亿美元),AWS支出占收入的104%
  • Cursor 2025年1-9月AWS支出:6999万美元,其中2025年6月支出(1267万美元)较5月(619万美元)环比增长104%

Anthropic成本与收入关系

  • 2024年:AWS月支出从1月的5290万美元增至12月的1.761亿美元,全年支出远高于收入
  • 2025年趋势:月度AWS支出持续攀升,9月达5.189亿美元。尽管收入增长,AWS成本仍与收入呈近似线性关系,消耗了绝大部分收入。
  • 隐含总成本:Anthropic在2024年总现金消耗约56亿美元,2025年预计为30亿美元。AWS仅占其一部分,其Google Cloud支出可能达AWS支出的50%或更多,加上其他运营费用,导致巨额亏损。

关键事件与影响

  1. “优先服务层”的推出(2025年5月):Anthropic引入分级定价,要求客户承诺最低使用量以获得优先访问,实质是对缓存写入(对AI编码工具至关重要)提高收费
  2. 对Cursor的直接冲击
    • Cursor作为Anthropic最大客户,其AWS支出在6月(引入服务层当月)翻倍以上
    • 随后Cursor被迫调整产品定价(如推出200美元/月的“Ultra”计划),将成本转嫁给用户
  3. 竞争产品时机:Anthropic提高价格的同时,推出了直接与Cursor竞争的产品“Claude Code”。

商业模式困境

  • 成本失控:Anthropic的推理/服务成本随用户和收入增长而线性甚至加速增长,当前定价模式无法盈利。
  • “次级AI危机”:AI模型提供商在前期补贴吸引用户后,开始大幅提价,导致下游AI创业公司成本飙升、被迫改变商业模式或面临淘汰
  • 可持续性存疑:在已融资375亿美元(截至2025年9月估值1830亿美元)的情况下,Anthropic仍持续寻求巨额新融资,暗示其资金消耗速度极快。

结论

文章指出,Anthropic的运营成本(尤其是云计算)远超其收入,且成本随业务扩张同步增长,缺乏有效的成本控制。通过“优先服务层”等手段向客户(如Cursor)转嫁成本,引发了行业内的“次级AI危机”。这暴露了当前基于大型语言模型的AI服务在经济上的不可持续性,最终可能导致消费者和企业面临价格上涨或服务价值缩水。

23. Major AWS outage takes down Fortnite, Alexa, Snapchat, and more (www.theverge.com)

AWS 重大宕机事件概述

事件概况

周一早晨,亚马逊网络服务(AWS)发生重大宕机,导致多项在线服务中断数小时,涉及亚马逊、Alexa、Snapchat、《堡垒之夜》、ChatGPT、Epic游戏商城及Epic在线服务等众多平台。

时间线与原因

  • 问题报告:美东时间凌晨3:11,AWS仪表盘首次报告影响美东1区(US-EAST-1)的问题。
  • 根本原因:亚马逊将宕机归因于域名系统(DNS)的解析问题,该系统将网站域名转换为机器可读的IP地址。问题源于EC2内部网络。
  • 解决过程:美东时间上午6:35,亚马逊宣布根本问题“已完全缓解”,但全天持续修复所有受影响系统。最终在下午6:01恢复所有AWS服务正常运行。

受影响服务

宕机影响了运行在AWS云网络上的众多平台和服务,包括:

  • 消费者应用:Alexa(语音助手无法响应)、Ring安全摄像头(录像中断)、亚马逊主站、Snapchat、麦当劳应用。
  • 游戏与平台:《堡垒之夜》、Epic游戏商城、Epic在线服务、ChatGPT。
  • 其他工具:Perplexity、Airtable、Canva、Zapier。

部分平台(如《堡垒之夜》、Epic游戏商城、Perplexity)在亚马逊报告宕机约四小时后宣布恢复上线。

历史背景

广泛使用的美东1区此前在2020年、2021年和2023年均曾发生宕机事件,导致众多主要服务中断,直至常规服务恢复。

(文章更新于10月20日及21日,补充了亚马逊的状态更新和解决情况。)

24. Show HN: Playwright Skill for Claude Code – Less context than playwright-MCP (github.com)

Playwright Skill for Claude Code 工具摘要

这是一个为 Claude Code 设计的 Playwright 浏览器自动化技能工具,其核心特点是相比 playwright-MCP 方案需要更少的上下文信息。它能让 Claude 自主编写并执行从简单页面测试到复杂多步骤流程的任意 Playwright 自动化脚本。

核心特性

  • 通用自动化任务:Claude 可为用户的具体需求编写定制化代码,不局限于预设脚本。
  • 默认可见浏览器:自动化过程默认以非无头模式运行,可实时观察。
  • 零模块解析错误:通过通用执行器确保正确的模块访问。
  • 渐进式披露:仅在需要时加载精简的 SKILL.md 说明和完整的 API 参考文档,节省上下文。
  • 安全清理:智能管理临时文件,避免竞争条件。
  • 辅助功能:提供可选的实用函数用于常见任务。

安装方式

该仓库以 Claude Code 插件 的形式结构化,包含一个嵌套的技能文件夹。

  1. 插件安装(推荐):通过 Claude Code 插件系统安装,支持自动更新和团队分发。

    /plugin marketplace add lackeyjb/playwright-skill
    /plugin install playwright-skill@playwright-skill
    cd ~/.claude/plugins/marketplaces/playwright-skill/skills/playwright-skill
    npm run setup
    
  2. 独立技能安装:手动将技能文件夹复制到 Claude Code 技能目录。

    • 全局安装:克隆仓库后,仅将 skills/playwright-skill 文件夹复制到 ~/.claude/skills/,然后运行 npm run setup
    • 项目安装:将技能文件夹复制到项目的 .claude/skills/ 目录下。
  3. 下载发布包:从 GitHub Releases 下载,提取 skills/playwright-skill 文件夹到指定位置后运行 npm run setup

安装后,可通过 /help 命令验证技能是否加载成功。

使用方法

安装后,只需用自然语言向 Claude 描述需要测试或自动化的浏览器任务,例如:

  • 页面测试:“测试首页”、“检查联系表单是否工作”。
  • 视觉测试:“为仪表盘截图,包括移动端和桌面端”。
  • 交互测试:“填写注册表单并提交”。
  • 验证任务:“检查是否有损坏的链接”。

Claude 会自动生成并执行定制的 Playwright 代码,并返回包含截图和控制台输出的结果。

工作原理

  1. 用户描述任务。
  2. Claude 编写对应的 Playwright 自动化代码。
  3. 通用执行器 (run.js) 运行代码,处理模块解析。
  4. 浏览器(默认可见)执行操作。
  5. 结果以控制台输出和截图形式返回。

项目结构

playwright-skill/
├── .claude-plugin/           # 插件元数据
└── skills/
    └── playwright-skill/     # 技能核心
        ├── SKILL.md          # Claude 读取的技能说明
        ├── run.js            # 通用执行器
        ├── package.json      # 依赖与设置脚本
        └── lib/helpers.js    # 可选辅助函数

其他要点

  • 依赖项:需要 Node.js、Playwright 和 Chromium(通过 npm run setup 安装)。
  • 高级用法:Claude 会在需要时自动加载详细的 API_REFERENCE.md
  • 许可:项目采用 MIT 许可证。
  • 目标:实现了开放的 Agent Skills 规范,兼容不同智能体平台,旨在提升 Claude 进行浏览器相关任务时的准确性和效率。
25. Gleam OTP – Fault Tolerant Multicore Programs with Actors (github.com)

Gleam OTP:基于 Actor 的容错多核程序

本文介绍了 Gleam 语言在 BEAM 虚拟机上如何利用 Erlang 的 OTP(Open Telecom Platform)框架构建容错、多核应用程序。Gleam OTP 包提供了对 OTP 核心概念的类型安全绑定,旨在实现强大的容错能力。

核心目标

该包的设计遵循几个主要目标:

  • 完全类型安全:确保 actor 和消息的类型安全。
  • 兼容性:与 Erlang 的 OTP actor 框架兼容。
  • 容错与自愈:通过监控器(Supervisor)实现进程崩溃后的自动重启和自愈。
  • 高性能:提供与 Erlang OTP 相当的性能。

核心概念与组件

Gleam OTP 包提供了多种 actor 类型作为构建块:

  1. 进程(Process):OTP 最底层的构建块,其他 actor 类型都基于进程构建。Gleam 的 process 模块定义在 gleam_erlang 库中。
  2. Actor:最常用的进程类型,类似于 Erlang 的 gen_server。它自动处理 OTP 系统消息以支持调试和跟踪功能。
  3. 监控器(Supervisor):负责启动和监督其他进程的进程。当被监督的进程崩溃时,它可以将其重启。监控器可以形成层级结构,称为监控树,为应用程序提供容错和监控能力。具体类型包括 gleam/otp/static_supervisorgleam/otp/factory_supervisor

使用示例

以下是一个简单的 Gleam actor 示例,展示了如何创建 actor、发送消息以及进行同步调用:

// 启动一个初始状态为 0 的 actor
let assert Ok(actor) =
  actor.new(0)
  |> actor.on_message(handle_message)
  |> actor.start

// 发送消息
actor.send(actor.data, Add(5))
actor.send(actor.data, Add(3))

// 发送消息并获取回复(同步调用)
assert actor.call(actor.data, waiting: 10, sending: Get) == 8

限制与已知问题

  • 功能不完全:并非所有 Erlang/OTP 功能都被包含。一些无法以类型安全方式实现的功能被排除;其他功能(如更多进程监控策略)仍在开发中。
  • 系统消息支持不全:actor 尚不支持所有 OTP 系统消息,因此某些 OTP 调试 API 可能无法完全工作。不支持的消息会被静默丢弃。
  • 文档依赖:该包对 OTP 本身的文档有限。不事先学习 OTP 框架直接使用,可能导致困惑和次优代码。

总结

Gleam OTP 包为在 BEAM 上运行的 Gleam 程序提供了通往 Erlang/OTP 世界的类型安全桥梁。它通过 actor 模型和监控器机制,使开发者能够构建出具备容错、可伸缩和高性能特性的并发系统。然而,使用者仍需对 OTP 的核心原理有所了解以充分利用其能力。

26. Ask HN: What are people doing to get off of VMware?

VMware 迁移趋势:用户分享替代方案与经验

一、 迁移的核心驱动力:成本激增

  • VMware 被博通收购后,授权费用大幅上涨是主要驱动力。多个案例表明价格出现数倍至数十倍的增长(例如,一份高校的5年企业授权协议从150万美元飙升至1200万美元)。
  • 价格上涨具有不确定性,最小核心数等新条款增加了成本压力,尤其对中小型企业和大型机构的预算构成严峻挑战。

二、 主流替代方案选择

  1. 微软 Hyper-V / Azure

    • 主要选择:许多组织(包括高校、银行、大型企业)正大规模迁移到 Hyper-V 或 Azure。
    • 原因:对于已有 Windows Server 授权的企业,Hyper-V 通常已包含在现有协议中,迁移成本相对较低。Azure 则为云迁移提供了明确路径。
    • 挑战:部分用户指出微软的支持服务虽承诺24/7但响应质量参差不齐;存在潜在的供应商锁定。
  2. 开源及第三方虚拟化平台

    • Proxmox VE
      • 优势:被广泛认为是功能丰富、成本更低的开源替代品,尤其适合中小型企业和服务提供商。用户赞赏其灵活性、备份解决方案(PBS)和内置的Ceph存储支持。
      • 主要顾虑:缺乏企业级24/7支持服务是阻碍其被大型企业采纳的关键。虽然部分认证合作伙伴可提供此类支持,但信息不够透明。其企业形象常被视为偏向家庭实验室和中小型企业。
    • Nutanix
      • 优势:被视为企业级替代方案,超融合基础设施(HCI)受到欢迎,尤其适用于VDI、Citrix或三层应用环境。
      • 考虑:成本可能与VMware相近,并非廉价选择,且存在新的供应商锁定风险。
    • XCP-ng
      • 优势:作为Citrix XenServer的分支,提供免费且功能强大的解决方案,拥有独立的技术发展。
      • 定位:主要面向寻求避免高额授权费的欧洲企业。
    • 基于KVM的云管理平台
      • 包括 Apache CloudStackOpenNebulaOpenStack 等。这些平台提供了更多选择和灵活性,尤其适合需要大规模和复杂编排的环境。OpenStack被认为在电信领域仍有重要地位。
  3. 容器化与云原生路径

    • Kubernetes/KubeVirtRed Hat OpenShift(结合KubeVirt)和 Harvester 等方案试图融合容器与虚拟机管理,但并非所有传统工作负载都适合容器化。
    • 策略性迁移:部分组织正加速将应用容器化,或利用 Talos Linux 等专用Kubernetes操作系统来运行传统虚拟机工作负载,以减少对特定云或虚拟化平台的依赖。

三、 关键讨论点与挑战

  • 企业支持是关键:对于大型企业,缺乏可靠的24/7企业级支持服务是阻碍许多开源方案(如Proxmox)被采纳的主要障碍。企业需要明确的SLA和问责制。
  • 迁移复杂性与风险:迁移过程漫长、复杂且存在风险,特别是对于遗留应用。许多组织采取分阶段迁移的策略。
  • 文化与组织障碍:内部政策(如网络安全策略)、对未知技术的保守态度以及既有采购流程,常常成为技术迁移的实际阻碍。
  • 混合策略:没有“一刀切”的解决方案。组织根据工作负载特性(虚拟机 vs. 容器)、现有技能栈、供应商合同和财务规划,采取混合迁移策略。

四、 总结趋势 VMware的高价策略正迫使整个行业重新评估其虚拟化基础设施。迁移浪潮呈现出 多路径并行 的特点:向主流云平台(Azure/AWS)迁移、转向成熟的商业替代品(Hyper-V、Nutanix)、或拥抱更灵活的开源及KVM生态(Proxmox、XCP-ng、CloudStack)。企业级支持能力总拥有成本是决策中的核心权衡因素。这次迁移不仅是一次技术替换,也正在推动许多组织思考更广泛的基础架构现代化,包括容器化和混合云战略。

27. Thieves steal crown jewels in 4 minutes from Louvre Museum (apnews.com)

事件概述

2025年10月19日周日,巴黎卢浮宫在开放后约30分钟内发生重大盗窃案。一伙专业盗贼利用篮式升降机从博物馆临塞纳河的外墙破窗而入,在四分钟内闯入阿波罗展厅,砸碎展柜,盗走8件拿破仑时期珍贵的王室珠宝后骑摩托车逃离。事件无人受伤,但失窃物品价值无法估量。

盗窃经过与失窃物品

  • 作案手法:盗贼于上午9点30分左右,使用自带的篮式升降机抵达外墙,用切割工具破坏窗户,直奔陈列“皇冠钻石”的阿波罗展厅。
  • 失窃珠宝:包括与19世纪法国王后玛丽-阿梅莉和霍滕丝相关的蓝宝石头饰、项链和耳环;拿破仑二世皇后玛丽-路易丝的祖母绿项链和耳环;一枚圣物匣胸针;以及欧仁妮皇后的头饰和大型胸花蝴蝶结胸针——共8件珍品。
  • 部分追回:欧仁妮皇后那顶镶嵌超过1300颗钻石的祖母绿皇冠,后来在博物馆外被发现,但已损坏。

暴露的安全与运营问题

  • 安保漏洞:事件突显了明显的安全弱点,即大型升降机能被带至博物馆外墙而未被察觉。尽管卢浮宫近年已升级监控和安防系统,但批评者认为措施来得太晚。
  • 运营压力:卢浮宫长期面临游客过多和人手短缺的紧张压力,员工曾因此罢工。工会指出,大众旅游导致安保人员在庞大空间中监控不足,尤其在施工区、货运通道和游客流汇集处形成风险点。
  • 历史对比:此次在开放时段、有游客在场时发生的盗窃,是近年来欧洲最大胆的博物馆抢劫案之一,堪比2019年德累斯顿绿穹珍宝馆失窃案。

后续反应与调查

  • 现场处置:案发后卢浮宫立即闭馆,警方封锁周边街道、清理庭院并展开法证调查。
  • 政治影响:极右翼领袖乔丹·巴尔代拉借此攻击马克龙政府,称其为“国家的不可容忍的羞辱”,质疑国家治理的衰败。而马克龙政府正在推动耗资约7亿欧元的“卢浮宫新文艺复兴”十年现代化计划。
  • 调查进展:调查人员正在检查案发现场、审查监控录像、检验作案升降机,并询问工作人员。据法媒报道,可能有四名嫌疑人,其中两人伪装成建筑工人。关键问题包括是否有人内应,以及失窃珠宝能否追回。
  • 追回难度:专业人士指出,失窃珠宝极有可能被拆解或重新切割以消除痕迹,因此很难再被找回。
28. Valetudo: Cloud replacement for vacuum robots enabling local-only operation (valetudo.cloud)

Valetudo:实现扫地机器人本地化操作的云端替代方案

概述

Valetudo 是一款旨在让扫地机器人摆脱云服务依赖、实现完全本地化操作的开源软件解决方案。自2018年启动以来,该项目已发展成一个稳定可靠的“部署后无需操心”的解决方案,被安装在数千台机器人上。该项目由 Sören Beye 创建和维护,并得到了 Dennis Giese 等人的贡献支持。

核心理念与目标

  1. 摆脱云端:其核心目标是解放用户的扫地机器人,使其不再依赖厂商的云服务,从而增强用户对设备的控制权和隐私保护。
  2. 真正的设备所有权:项目强调通过开源和本地操作,让用户获得对智能设备真正的所有权。
  3. 开源与许可证:软件采用 Apache-2.0 许可证发布。作者认为,只有能够查看和修改代码,才能确保用户真正了解和控制自己的设备。作者信任用户不会利用此宽松许可证将 Valetudo 作为自己的作品进行商业销售。

项目性质与维护者立场

作者明确将 Valetudo 定义为个人业余项目,并无商业化或扩大用户群的意图。他使用了一个生动的比喻:将该项目比作一个私人拥有的公共花园

  • 免费与开放:用户可以免费参观和使用这个花园,并可以邀请朋友前来。
  • 尊重与无权:但用户必须理解,这仍是一份赠礼和私有财产,用户无权要求改变花园的结构或内容。
  • 自行选择:如果用户不喜欢花园的风格,可以选择离开,因为互联网上存在无限的空间供任何人创建自己的“花园”(即开发类似项目)。 这一比喻旨在设定对项目发展的预期:维护者拥有项目的最终决定权,其开发方向基于个人愿景而非市场需求。

相关资源与支持

  1. 文档:项目提供了详细的文档(Valetudo Docs),旨在解构物联网和自由开源软件(FOSS)的某些方面。新手指南是一个推荐的起点。
  2. 信息查找
    • 想了解使用原因或不推荐使用的理由,可分别查阅“Why Valetudo?”和“Why not Valetudo?”页面。
    • 购买支持型号的指南位于“Buying supported robots”部分。
  3. 社区与支持
    • 唯一的官方联系渠道是Valetudo Telegram 群组
    • 存在一个名为“dust_announce”的极低频更新公告频道。
    • 文章强调,其他如 IRC、Matrix 或 Reddit 等平台均为非官方渠道,信息可能不正确或过时。
    • 提到了一个“Valetudo Premium Support System”(VPSS)及其电话号码,并建议出于隐私考虑可使用呼叫方号码隐藏功能。
  4. 媒体与内容创作:针对希望基于该项目创作内容的创作者,提供了“Media & Content Creators”指南。
  5. 替代方案:文章提到了另一个实现类似目标的项目——由 Luke Lashley 开发的 Roborock Local Server,作为较少个人化主张的选项。
29. Windows 11 25H2 October Update Bug Renders Recovery Environment Unusable (www.techpowerup.com)

微软在Windows 11 25H2十月更新(KB5066835)中确认了一个重大缺陷:该更新导致Windows恢复环境(WinRE)内的鼠标和键盘功能失效,使其完全无法使用。WinRE是Windows内置的故障排除工具包,用于在计算机遇到启动问题或系统故障时提供协助,通常会在系统崩溃或无法正常启动时自动激活,也可由用户手动访问以使用各类修复工具。

由于输入设备无法响应,WinRE功能实质上陷入瘫痪状态。微软澄清称,USB键盘和鼠标在Windows操作系统本身内仍正常工作,并表示“正在努力在未来几天内发布解决方案”,届时将提供更多信息。此事件是近期Windows 11更新引发的又一问题,此前更新曾导致本地主机功能故障。微软维护的Windows 11 25H2已知问题和通知网站已收录此问题并会提供状态更新。

更新于10月21日16:05 UTC:微软已发布紧急修复补丁。该公司称,此带外更新包含质量改进,是累积性更新,并整合了来自2025年10月14日安全更新(KB5066835)的安全修复与改进。

此前,微软还曾意外破坏了Windows媒体创建工具(MCT),恰在Windows 10终止支持前一天;此外,微软开始要求Windows 11安装必须使用在线账户,使绕过该要求变得更加困难。除本次WinRE问题及本地主机功能故障外,此前报告的其他问题均已得到处理或解决。当前,由于输入失效,用户无法启动任何恢复流程来解决操作系统问题。在微软发布修补程序之前,用户只能期待系统保持稳定无需干预。

30. Commodore 64 Ultimate (www.commodore.net)

Commodore 64 Ultimate 总结

Commodore 64 Ultimate 是一款对经典家用电脑 Commodore 64 的现代复兴产品,旨在提供怀旧体验与当代技术相结合的全新设备。

核心产品与设计

该产品系列包含两款主要型号:

  1. '面包箱'(Breadbin)Commodore 64 Ultimate:采用经典的“面包箱”外形设计。
  2. '纤薄版'(Slimline)Commodore 64C Ultimate:外形更纤薄,其外壳直接使用了1986年原厂注塑模具制造,以确保与原版的高度一致性和收藏价值。

两款型号在内部规格上完全相同,均提供经典的“BASIC Beige”米色版本。

主要特性与功能

  • 非模拟,而是FPGA硬件复刻:搭载 AMD Xilinx Artix-7 FPGA 主板,实现接近100%的硬件级兼容,而非软件模拟。
  • 强大的兼容性:声称与超过10,000款复古游戏和外设兼容,兼容率超过99.9%。支持原始端口,包括数据磁带机、磁盘驱动器、鼠标和调制解调器。
  • 现代化接口:配备 HDMI(1080p)、USB(USB-A与USB-C)、Wi-Fi以太网,并内置 CommoServe™ 在线仓库功能,可直接在设备内下载游戏和软件。
  • 丰富的预装内容:设备内置超过100款软件,包括经典游戏、自制游戏、演示程序、音乐集以及图形操作系统套件。
  • 经典功能复现
    • GEOS图形系统:提供文字处理、桌面出版和绘图功能。
    • 音乐制作:内置传奇的SID声音芯片(双芯片插槽),并支持FPGA模拟8个SID以实现24通道播放。
    • BASIC编程:鼓励用户学习BASIC语言进行创作。
    • BBS公告板系统:可连接复古风格的BBS进行交流。
  • 硬件细节
    • 键盘:采用66键机械键盘,布局与原版一致,使用Gateron Pro 3.0轴体。
    • 存储:附带一个USB“数据磁带”(128MB),内含100多个预装标题。
    • 视频输出:支持HDMI(低延迟)和模拟视频输出。
    • 扩展性:配备游戏卡带端口、数据磁带机接口、摇杆/鼠标端口等。

发售信息

  • 两款型号均已开放预购
  • '面包箱'版:预计2026年5月8-11日从工厂发货,标准运输预计发货后56-73天到达。
  • '纤薄版':预计2026年9月2-15日发货,提供加急(10-15天)和标准(56-73天)运输选项。

产品理念

Commodore 64 Ultimate 不是对过去的单纯复制品,而是利用原厂模具和现代技术,在保留经典 Commodore 64 核心体验的同时,融入当代便利性的设备。它强调“复古并非错误,而是我们做对的事情”,旨在让用户无需互联网时代的纷扰,重新体验计算机的本质乐趣。

31. Show HN: I created a cross-platform GUI for the JJ VCS (Git compatible) (judojj.com)
  • 内容为赌博网站宣传通知,主要包括:
    • 用户赢得大额奖金,例如Anto_JP在Gates of Olympus游戏中赢得Rp 45,200,000,Siska99在Wild Bandito游戏中赢得Rp 12,800,000。
    • 强调存款便利性:支持QRIS自动存款,24小时服务。
    • 提供游戏高回报率信息:如Mahjong Ways 2的RTP(玩家回报率)为99.1%。
    • 承诺快速提现过程:WD(提现)仅需2分钟。
  • 消息重复出现,以突出宣传重点。
32. Nvidia has produced the first Blackwell wafer on US soil (www.xda-developers.com)

Nvidia 与台积电合作,在美国本土生产了首款 Blackwell 芯片晶圆,这一里程碑事件在美国半导体制造业具有重要意义。

  • 核心事件:Nvidia 宣布与台积电合作,在 台积电亚利桑那州工厂 成功制造出首款在美国本土生产的 Blackwell 芯片晶圆。
  • 政策背景:此举正值特朗普政府时期,其政策重点是通过关税等手段推动制造业回流美国。企业将生产迁回美国本土的趋势正在形成。
  • 高层表态
    • Nvidia 首席执行官黄仁勋称这是历史性时刻,是“近期美国历史上最重要的芯片”首次在美国由最先进的工厂(台积电)制造,并指出这实现了特朗普总统关于再工业化、创造就业以及巩固美国在关键技术产业领导地位的愿景。
    • 台积电亚利桑那州首席执行官表示,从抵达亚利桑那州到交付首片美国制造的 Nvidia Blackwell 芯片,展现了台积电的最佳水准,并强调了与 Nvidia 三十年的合作伙伴关系。
  • 战略意义:Nvidia 认为,将芯片生产迁回美国“为美国在人工智能领域的持续领导地位铺平了道路”。这不仅可能创造本地就业,也有助于将美国打造成为软硬件兼备的 AI 中心

这一事件标志着高端芯片制造开始向美国回流,是应对供应链变化和地缘政治因素的重要一步。

33. Matrix Conference 2025 Highlights (element.io)

Matrix Conference 2025 会议亮点

Matrix Conference 2025 取得巨大成功,会议氛围充满活力与热情。Element作为主要赞助商,感谢所有组织者、演讲者、赞助商及与会者。会议的核心主题是Matrix技术展现出的巨大发展势头,众多政府机构分享了其基于Matrix的举措,表明Matrix正成为政府及跨政府通信的未来。

主要演讲与内容

  • Matrix全景概览:Matthew Hodgson全面介绍了Matrix生态系统的现状。
  • 政府与公共部门采用:Amandine Le Pape阐述了Matrix如何成为公共部门的通信标准。
  • Element主题演讲:Neil Johnson回顾了Element过去一年的工作,重点介绍了ESS Community(免费用于小规模评估,支持最多约100用户)可快速安装,并能无缝升级至功能更强大的ESS Pro(提供可扩展性、企业功能及SLA支持)。
  • Element产品介绍
    • ESS(Element服务器套件):涵盖Community、Pro及TI-Messenger版本。
    • Element Pro:专为工作场所设计的新应用,支持应用内颜色主题和白标移动应用创建,无需维护分支。
    • 其他亮点包括Element X Web和Element Call的相关介绍。

政府与公共部门部署案例(会议焦点) 众多政府及公共部门组织的实践展示了Matrix的实际价值,是会议的“真正明星”。相关演讲案例包括:

  • 欧洲委员会:试行Matrix以实现韧性和主权通信。
  • 法国(DINUM):在政府内部部署Matrix并安全开放私有联邦。
  • 德国(FITKO):致力于基于Matrix的联合架构以整合行政通信。
  • 瑞典:公共部门转型实践。
  • 卢森堡政府:Luxchat(4gov) 项目。
  • 医疗应用:包括在模拟月球行走中通过Matrix(含延迟)进行医疗护理,以及Matrix在德国医疗体系中的作用。
  • 德国(Gematik):面向7400万法定保险公民的全国性即时通讯(TI-M)推出。
  • 联合国国际计算中心(UNICC):利用Matrix协议实现安全通信。
  • 北约(NATO ACT):支持TF-X的最佳实践与经验教训。
  • 德国联邦信使跨境工作空间通信(ZenDiS)等。

采用Matrix的关键驱动因素 作为基于开源软件的开放标准,Matrix满足了政府通信转型的核心需求:

  1. 数字主权:终端用户组织对其技术栈拥有完全自主权,避免供应商锁定。众多竞争供应商赞助并参会,也体现了Matrix生态系统的健康。
  2. 互操作性:Matrix开放标准实现了跨组织的大型联邦通信,既支持数字主权,也确保不同组织间的便捷沟通。
  3. 韧性:去中心化网络架构比集中式网络更稳健,对政府通信至关重要(会议期间集中式服务如Signal、Slack等因依赖AWS而出现故障即为例证)。
  4. 安全性:端到端加密是基础要求。

欧洲多国政府正积极采用Matrix作为实时通信的基础。会议上有包括欧洲委员会、法国、德国、北约、联合国等在内的众多机构分享部署经验,同时也有许多其他政府机构参会学习,为未来的Matrix项目做准备。这预示着一个基于Matrix的未来,将深刻改变跨境协作,助力构建一个团结、数字主权的欧洲。

34. Doctor Who archive expert shares positive update on missing episode (www.radiotimes.com)

《神秘博士》(Doctor Who)档案专家近日分享了关于寻找该剧遗失剧集的积极进展,暗示未来的官方公告将为粉丝带来巨大惊喜。

遗失背景

由于BBC在20世纪60至70年代为节省存储空间和成本而擦除或重复使用磁带,该剧前六年的253集中有97集遗失,导致26个故事不完整。尽管部分遗失剧集近年通过幸存的音频录音被制作成动画,但业界一直推测仍有原版胶片存于私人收藏中,这一推测现已得到证实。

确认存在于私人收藏

致力于保护英国脆弱电影收藏的慈善信托基金“Film is Fabulous!”的代表John Franklin证实,目前有多位私人收藏家和前业内人士手中掌握着多集遗失的《神秘博士》。该团队正与这些收藏家积极洽谈,计划完整接收、编目并管理他们的整个电影收藏,而非仅抽取《神秘博士》等单一稀有物品。

关键案例与法律推进

Franklin透露,自2023年起,团队一直在追踪一个包含数千部电影的庞大私人收藏,其中已确认至少包含一集遗失的《神秘博士》,且可能还有更多。由于该收藏家近期不幸离世,原本达成的接收协议面临法律变更。目前,“Film is Fabulous!”正向法院提出申请,以合法推进此前的协议,确保将该收藏及遗失剧集安全归还给版权方。

工作原则与未来展望

Franklin强调,信托基金坚持合法、合规地处理整个收藏,单独剥离单件物品是“非法且不道德的”。他呼吁粉丝给予团队空间以完成当前的法律与接收工作,并承诺最终的公告会让大家“非常高兴”。

此前,该团队的其他专家也曾表示,确信仍有遗失剧集存在于私人收藏中,并已掌握部分潜在线索。他们期望在时机成熟时,能成功将遗失剧集正式归还给BBC并举行交接仪式。

35. Introduction to reverse-engineering vintage synth firmware (ajxs.me)

本文介绍如何逆向工程雅马哈DX7合成器的固件,主要面向具有技术背景但刚接触逆向工程或8位架构的读者。

核心方法:地址解码 在反汇编固件前,必须先理解CPU的内存映射。DX7的CPU通过地址解码电路将外围设备(如固件ROM、RAM、LCD屏幕)映射到特定的内存地址。通过分析电路图中的逻辑门(如AND、NOT)和解码器(如74LS138),可以确定每个设备的地址范围。例如:

  • 固件ROM(IC14):映射到 0xC000 - 0xFFFF
  • 外部RAM(IC19-21):映射到 0x1000 - 0x2800
  • LCD控制器:通过Intel 8255 PPI芯片连接,数据寄存器映射到 0x2800,控制寄存器映射到 0x2801

固件反汇编与分析 使用Ghidra反汇编工具加载ROM文件,并根据已确定的地址设置内存映射。

  1. 重置函数分析:CPU上电后从重置向量(0xFFFE)开始执行。重置函数负责初始化CPU端口、变量,并设置定时器中断。
  2. 中断机制:定时器中断是实时功能(如处理MIDI、更新声音)的核心,其处理程序位于中断向量表指定的地址。
  3. LCD接口逆向:从LCD的内存映射地址(0x2800)出发,反向追踪代码,发现了用于初始化LCD、等待LCD就绪和写入指令/数据的函数。最终识别出完整的LCD打印函数,它处理字符串缓冲、设置显示位置、逐字符写入,并检查屏幕行列边界。

为何选择DX7作为示例 DX7具有多个适合入门逆向工程的特点:其架构(单ROM、无复杂的bank switching)、存在LCD文本界面便于分析、相关文档(电路图、手册)齐全,并且可使用免费的Ghidra工具进行反汇编。

总结 逆向工程复古合成器固件的关键在于先通过硬件文档(电路图、数据手册)理解内存映射,再利用反汇编工具分析代码流。虽然具体架构和指令集各异,但这些基本方法(地址解码、跟踪重置/中断处理程序、分析外围设备驱动)适用于不同嵌入式系统的逆向工程。

36. Bible and Quran apps flagged NSFW by F-Droid (forum.f-droid.org)

Bible and Quran apps被F-Droid标记为NSFW

事件概述

Bible and Quran相关的应用程序在F-Droid应用仓库中被错误地标记为NSFW(不适合在工作场合浏览)。这一标记引发了用户关注和讨论。

具体案例

用户dizzib在F-Droid上发布了其应用Bible Feed的v1.6.0版本。该应用基于Professor Grant Horner阅读计划跟踪器,用于阅读上帝的圣经。发布后,应用被自动标记为NSFW,并且元数据中新增了AntiFeatures部分,显示NSFW标记,描述部分内容为“Promote ■■■■ and vio…”(部分内容被模糊处理)。

元数据变化

  • AntiFeatures:添加了NSFW条目。
  • 描述:部分内容被遮挡,可能涉及推广不适当内容。
  • 图像:提供了相关截图链接,展示标记问题。
  • 应用链接:Bible Feed在F-Droid上的页面。

相关信息

  • Mastodon链接:指向F-Droid官方账户。
  • JSON数据:结构化显示问题详情,包括提问者信息、投票数和发布时间。

问题影响

此错误标记可能影响应用的正常访问和用户信任,引发了对F-Droid审核机制准确性的质疑。

38. The FTC Is Disappearing Blog Posts About AI Published During Lina Khan's Tenure (www.wired.com)

美国FTC移除林娜·卡恩任期内的AI相关博客文章

2024年7月底,时任美国联邦贸易委员会(FTC)主席的林娜·卡恩在创业孵化器Y Combinator主办的活动上发表讲话,将自己定位为开源人工智能的支持者。当时加州立法者正考虑一项名为SB 1047的里程碑式法案,该法案将对人工智能公司施加新的测试和安全要求。卡恩呼吁采取限制较少的方式,并表示有了开放模型,“小玩家可以将他们的想法推向市场”。

博客文章被移除

  1. “On Open-Weights Foundation Models”:2024年7月10日发布的博客强调了类似观点,并建议使用“开放权重”一词来指代那些公开发布训练权重、允许任何人检查、修改或重新使用的AI模型。互联网档案馆的Wayback Machine显示,该博客于今年9月1日被重定向至FTC技术办公室的登录页面。
  2. “Consumers Are Voicing Concerns About AI”:这篇2023年10月由FTC两名技术人员撰写的博客,现在同样被重定向至技术办公室页面。根据Wayback Machine记录,重定向发生在今年8月下旬。
  3. “AI and the Risk of Consumer Harm”:这篇由卡恩的员工于2025年1月3日发布的博客,目前导致“页面未找到”的错误屏幕。截至8月12日该文章仍在线,但到8月15日已被移除。文章原内容指出,FTC“日益关注人工智能可能带来的现实危害——从助长商业监视到实施欺诈和冒名,再到延续非法歧视”。

背景与反应

  • 移除原因不明,FTC发言人未回应置评请求,卡恩通过发言人拒绝评论。
  • 前FTC公共事务主任道格拉斯·法拉对“开放权重”博客的移除感到特别震惊,并认为新任FTC主席安德鲁·弗格森领导下的机构“与特朗普白宫在此市场信号上的表态严重不符”。
  • 特朗普政府2025年7月的“人工智能行动计划”主张“确保美国拥有基于美国价值观的领先开放模型”,并“为开放模型创造支持性环境”。目前不清楚博客删除是否代表政策转变。
  • 特朗普政府的一些技术顾问,如白宫人工智能和加密货币特别顾问戴维·萨克斯、白宫人工智能高级政策顾问斯里拉姆·克里希南,也支持开源AI,将其视为美国保持技术主导地位的关键手段。
  • 此外,自特朗普重返白宫以来,FTC已移除了卡恩任期内发布的数百篇面向科技行业的博客和商业指南。
39. Could the XZ backdoor been detected with better Git/Deb packaging practices? (optimizedbyotto.com)

本文探讨了2024年XZ Utils后门事件,并详细介绍了如何通过改进的Debian软件包审计实践来检测此类威胁。作者作为Debian开发者,分享了一套审计Debian软件包的方法论,并讨论了其对Debian软件供应链安全的启示。

XZ后门事件概述

XZ Utils 5.6.0/5.6.1版本中被植入后门,短暂进入Debian、Fedora等主流发行版,但因Andres Freund发现SSH性能下降并及时报告而迅速被移除。此事件引发了关于Linux发行版打包者为何未察觉异常、当前供应链是否易于审计以及是否可能潜伏其他未被发现的后门等问题。

审计Debian软件包的方法论

审计重点应放在源代码包而非二进制文件上,并假设构建主机可信。主要步骤包括:

  1. 获取源代码包:使用 debsnap 工具从Debian存档下载特定软件包(如xz-utils)的多个历史版本。这些包包含上游源代码(.orig.tar.xz)、上游签名(.asc)、Debian打包源码(.debian.tar.xz)和Debian源码控制文件(.dsc)。
  2. 验证签名
    • 验证Debian维护者的签名:使用 gpg --verify 验证 .dsc 文件,需注意需单独验证密钥本身的可信度(如通过Debian密钥环)。
    • 验证上游源码签名:对 .orig.tar.xz.asc 文件进行类似验证。
  3. 通过校验和验证上游源码真实性:如果上游未提供签名,则需从上游网站下载源码,并与Debian所用的源码进行SHA256校验和比对。可使用 uscan 工具辅助,但需注意经Debian重新打包的源码(因 Files-Excluded 等设置)可能无法直接比对。
  4. 使用diffoscope审查差异:该工具可生成详细的差异报告(HTML或Markdown格式),用于比较不同版本之间的源代码包。其Markdown输出甚至可作为输入提供给LLM以辅助分析可疑变更。
  5. 审查版本控制历史
    • 目前仅93%的Debian软件包在Salsa(Debian的GitLab)上使用Git托管,且政策未强制要求使用Git。
    • 对于已托管于Salsa的包,可克隆仓库并使用 git loggit blamegit verify-tag 等工具查看详细的提交历史、代码溯源和验证上游提交签名。
    • 重要警示:Debian打包Git仓库的内容不保证与实际上传至Debian存档的包完全一致。tag2upload 项目正在改善此问题,但目前仍不普遍。
  6. 比较存档包与Git内容:可通过 diff 命令直接比较通过 debsnap 下载的包与Git仓库中的 debian/ 目录内容,以发现不一致(如时间戳差异)。
  7. 合成Git仓库:若无Git仓库或其落后于存档,可使用 gbp import-dscgbp import-dscs 根据存档包创建合成的Git历史,确保内容与存档一致。dgit 也能创建合成历史,但功能侧重不同。
  8. 比较上游源码包与上游Git内容:上游发布的tarball可能因移除测试数据、添加生成文件等而与Git仓库内容不同。在使用 git-buildpackage 时,导入提交(如 upstream/v5.8)会明确展示这些差异,可用 git difftool(如Meld)进行可视化比较。

XZ后门能否通过上述方法检测?

结论是:否,以合理努力无法检测。

  • 后门构成:包括伪装成测试文件的二进制恶意代码,以及构建脚本 m4/build-to-host.m4 中用于提取和植入恶意代码的修改。
  • 难以检测的原因
    • 恶意测试文件引入的提交信息粗略、不原子,但此类情况在开源项目中并非罕见,难以单独作为异常标志。
    • 新的Autotools文件(m4/build-to-host.m4)出现属正常现象。其复杂的m4/shell脚本语法及对反引号、eval 的使用是Autotools的常规特征。
    • 唯一细微可疑点可能是文件头部的版本号(serial 30)异常高,但检查此点需要大量额外工作,且不切实际。作者甚至建议开源项目应逐渐淘汰Autotools。
  • 此次后门极其隐蔽,若非引起SSH微小性能下降,很可能长期潜伏。

对Debian软件供应链安全的见解与建议

  1. 当前审计难度大:Git使用不统一、工作流多样、政策允许绕过Git的上传(“bypass git”),使得区分“正常偏差”与“恶意篡改”极为困难。可能存在更多未被发现的类似后门。
  2. 缺乏专用检测工具:Debian的QA和安全基础设施目前没有系统性地验证存档中的上游源码包是否确实来自上游。存在维护者手动创建tarball或软件包类型配置错误(如应为 3.0 (quilt) 却配置为 1.0 (native))的情况。
  3. 政策与实践建议
    • 倡导共享工作流:从“任何事情都可以自由做”的心态,转向重视更多共享的工作流程,以降低审计噪音。
    • 加强代码评审文化:推动更多地使用合并请求(Merge Requests),如作者提议的DEP-18,以促进协作并减少仅基于个人理解的流程偏差。
    • 改进工具与扫描:扩展QA工具以扫描源码包不匹配、配置错误等问题。
  4. 对开源软件的信任:作者认为只能信任开源软件,因为闭源软件无法审计,用户只能完全依赖厂商承诺,且历史上厂商很少为安全漏洞承担赔偿责任。开源允许个人或组织投资并验证安全改进。

最后,作者呼吁对Debian感兴趣的组织支持其改进工作。

40. Compare Single Board Computers (sbc.compare)

单板计算机比较平台

该平台是一个用于发现、比较和选择单板计算机的综合性工具,以真实基准测试和详细规格数据为核心,帮助用户做出明智决策。

核心功能与特点

  1. 真实硬件测试:所有性能数据均来自实际硬件测试,使用业界标准基准测试套件(如Geekbench、7-Zip)及自定义功耗测试。
  2. 全面数据库:收录数百款来自主要制造商的SBC,提供详细的规格、价格和供应信息。
  3. 免费开放:所有数据和基准测试结果均免费访问,无需付费墙或注册。

使用流程

用户可通过三个简单步骤找到合适的SBC:

  1. 浏览与筛选:利用强大的搜索和筛选工具,根据CPU、内存、连接性等需求查找板卡。
  2. 选择对比:选择最多3款板卡并排比较,查看各自的详细规格和基准测试结果。
  3. 比较决策:通过性能图表、规格表等综合对比,做出明智的购买决定。

分类浏览

平台提供快速分类链接,帮助用户根据特定需求快速找到匹配的板卡。

41. Dosbian: Boot to DOSBox on Raspberry Pi (cmaiolino.wordpress.com)

Dosbian:树莓派启动进入DOSBox的发行版

版本更新

  • Dosbian 4.0(2025年12月24日发布)适用于树莓派3/4/400/5/500/500+型号。
  • 主要更新
    • 操作系统更新至Raspbian Trixie。
    • Dosbox Staging集成最新11月提交版本。
    • ScummVM更新至最新11月提交版本。
    • 重新引入Dosbox-X支持。
  • 性能显著提升,尤其在树莓派5/500/500+上,提供即插即用或精细调校的复古PC体验。

系统概述

Dosbian是专为DOS环境设计的发行版,完全基于新版Trixie系统重写。启动后直接进入DOSBox界面,用户可自行安装系统或软件,构建理想的复古PC环境。适用于DOS游戏爱好者或旧版DOS软件用户,无需复杂配置,开机即可获得命令行操作界面。

功能列表

  • 运行复古PC软件(DOS / Windows 3.1 / Windows 95 / Windows 98)。
  • 运行多数90年代复古游戏。
  • 支持通过LaunchBox前端启动游戏。
  • 运行ScummVM游戏。
  • 创建指定容量的软盘镜像(320KB、720KB、1.44MB)。
  • 创建硬盘镜像(256MB、512MB、1GB、2GB及以上,需使用Dosbox-X)。
  • 通过图形界面工具挂载软盘、光驱或硬盘。

重要说明

  • Dosbian不包含任何受版权保护的材料,用户需自行安装游戏、软件或操作系统。
  • 开发者提醒:部分网络卖家非法预装软件并销售此发行版,用户应仅从官方博客下载安全免费的镜像。
  • 文章中的演示图片仅展示系统运行能力,发行版不包含第三方软件。

兼容设备

支持树莓派3B、3B+、3A+、4B、400、5、500、500+型号。

使用与社区

  • 作为捐赠软件项目,用户可自由修改系统用于个人用途。
  • 提供官方Facebook群组供用户交流、分享游戏设置和问题解决方案。
  • 用户可通过捐赠支持项目发展。
  • 安装方法:使用7zip解压镜像,并通过Win32DiskImager或Balena Etcher写入存储设备。

附加推荐

开发团队还提供了Combian64发行版,可启动进入经典Commodore机器(64、128、Vic 20、PET等)环境。

42. Bat v0.26.0 (github.com)

Bat v0.26.0 版本更新摘要

新增功能

  • 平台支持:新增 Windows/ARM64 构建版本。
  • 交互改进--list-themes 命令支持分页显示。
  • 行范围选择
    • 支持负数相对行范围,例如 bat -r :-10bat -r='-10:'
    • 支持行上下文,例如 bat -r 30::5bat -r 30:40:5
  • 内置分页器:新增内置 minus 分页器,可通过 bat --pager=builtin 使用。

错误修复

  • 修复语法检测时未正确剥离 UTF-8 BOM 标记的问题。
  • 修复环境变量 BAT_THEME_DARKBAT_THEME_LIGHT 被忽略的问题。
  • 修复在管道模式下,--list-themes 会输出默认主题信息到标准输出的问题。
  • 修复多字节字符在文件路径中可能导致崩溃的问题。
  • 将所有 bat 错误信息默认输出到标准错误(stderr)。
  • 修复 --map-syntax 的目标匹配未与 --language 保持大小写不敏感一致的问题。
  • 修复 --style=changes 在文件未修改时会输出两空格缩进的问题。
  • 修复在管道输出时行号(-n)和样式组件不显示的问题。
  • 修复即使存在无效配置或参数,也能执行帮助、版本等诊断命令的问题。
  • 补充了多个 shell 自动补全脚本。
  • 修复了其他多个细微问题。

语法高亮支持更新

  • 新增语法:支持了 Idris 2、GDScript、VHDL、Typst、Lean 4、Go Modules (go.mod, go.sum) 等编程语言。
  • 新增/改进映射:为 paru 配置文件、nix flake.lock、debsources、certbot 配置、.flatpakref/.flatpakrepo.kshrcdmesg 日志等添加或改进了语法映射。
  • 改进现有语法:增强了 CSV/TSV(支持自动检测分隔符)、Syslog、hosts 文件的语法高亮。
  • 其他:为 Markdown 文件中的 TypeScript 代码块添加了语法高亮。

主题更新

  • 新增主题:添加了 Catppuccin 主题。
  • 更新主题:更新了 Catppuccin、gruvbox、GitHub 主题,并改进了 ANSI 主题以区分 JSON 对象键和值的高亮。

其他改进

  • 依赖更新:更新了 terminal-colorsaurusconsoleonig_syssyntect 等依赖库。
  • 构建优化:增加了 vendored-libgit2 Cargo 特性,允许使用内置的 libgit2;优化了构建脚本和 CI/CD 配置。
  • 内部改进:改进了部分参数的测试覆盖率,优化了多核下的线程策略,修复了若干拼写错误。