2025-11-10

34 篇热帖

Marble Fountain

大理石喷泉:程序生成硬件驱动艺术作品

本文讲述了作者利用程序生成技术和3D打印制造“大理石喷泉”艺术作品的过程,并分享了其设计和实现中的挑战与思考。

项目背景与目标:

作者在Formlabs工作后,拥有了更高级别的3D打印机,并希望挑战大型算法结构项目。目标是创造一个复杂程度尽可能高的艺术作品,充分利用3D打印的几何设计自由度。

核心系统:轨道 (Tracks)

  • 初始设计: 最初的轨道系统通过在顶部和底部随机放置点,然后通过这些点绘制带有恒定斜率的样条曲线来实现。这种方法通过从实体支撑结构中减去管子来构建,但功能有限。
  • 路径求解器: 为了最大化运动量,作者开发了一个路径求解器,旨在将运动尽可能地填充到打印机的体积内。
  • 路径生成: 求解器通过生成一系列连接顶部和底部的线段作为初始猜测。不同的起始条件会显著影响最终结构形状。
  • 点位更新: 路径上的点会根据以下规则进行更新,以优化路径:
    • 保持在边界框内。
    • 均匀分布。
    • 拉向固定高度,以维持恒定斜率。
    • 强制最小和最大转弯半径。
    • 相互排斥,以及排斥自身轨道上的远端部分。
    • 平滑斜率变化,避免突变。
    • 防止斜率过度增加。
  • 速度控制: 速度控制是关键挑战。由于轨道角度变化会改变旋转轴,并可能导致旋转惯量耗散,因此简单地将大理石视为质点是不现实的。作者通过设置最小转弯半径和过度倾斜来解决这个问题,以持续消耗速度。
  • 升降机设计: 升降机巧妙地设计成类似于球螺纹,通过大理石的约束,使其无需顶部轴承即可运行。然而,这种设计也存在潜在的故障模式:如果螺纹仅在一侧受到大理石的约束,则会导致严重的摇晃,最终导致大理石从轨道上脱落。

支撑结构 (Supports)

  • 粒子系统: 支撑结构生成采用自上而下的迭代方法,将支撑柱视为粒子系统,实现简单且稳健。
  • 支撑规则: 每个支撑遵循以下规则:
    • 拉向其他支撑,权重取决于距离和相似性。
    • 相互排斥。
    • 保持在边界框内。
    • 拉向结构中心的固定半径。
  • 惯性: 支撑结构具有惯性,导致支撑柱呈现弧形。

技术细节与未来展望:

  • 模型导出: 完成的模型导出时间约为5-20分钟。
  • OpenSCAD局限性: 当前模型过于复杂,无法完全在OpenSCAD中优化。
  • 未来方向: 作者计划使用更适合有机几何的工具进行重写,例如SDF库。
  • 改进方向: 未来改进包括:
    • 实现更精确的速度估计,可能通过摄像头测量速度。
    • 建立更完善的加速度模型。
    • 探索表面滑动曲线,以确定最佳工作点。

项目回顾:

  • 项目时间: 该项目从2024年2月开始,持续到2024年9月,是作者投入最多的一次业余项目。
  • 展览: 作品被选入New Alliance Gallery展览,在展出前进行大量的调试和优化。
  • 问题与限制: 运行过程中,喷泉每小时会丢失2-3个大理石,且电机容易过热,限制了运行时间。
  • 致谢: 特别感谢朋友Alex的持续支持和帮助。

代码仓库: https://github.com/Will-Morr/MarbleFountain

XSLT RIP

XSLT.RIP 摘要

该网页标题为“XSLT.RIP”,内容表达了对XSLT(Extensible Stylesheet Language Transformations,可扩展样式表语言)被Google停止支持的惋惜和哀悼之情。

主要内容:

  • 网页暗示Google已停止对XSLT技术的支持。
  • 内容表达了对XSLT技术的逝去表示哀悼。

总结:

该网页简洁明了地表达了XSLT技术被Google放弃的现状,并表达了相应的惋惜之情。

LLMs are steroids for your Dunning-Kruger

大型语言模型:自信引擎而非知识引擎的崛起

本文探讨了大型语言模型 (LLM) 如 ChatGPT 的影响,尤其关注其对用户心理的影响。作者认为,LLM 的真正价值并非在于提供准确的知识,而在于增强用户的自信心,这可能带来潜在的风险。

核心观点:

  • 自信的陷阱: 借鉴了 Bertrand Russell 的观点,作者认为 LLM 容易让用户在错误信息中获得确定感。用户在使用 LLM 后常常会感到自己“知道很多”,但这些信息往往不准确,且难以摆脱这种虚假的确定感。
  • 思维放大器: LLM 就像一面镜子,能够“放大”用户的思维。它能将想法推向新的方向,有时能帮助改进想法,但同时也能强化错误的、自欺欺人的想法,并用流畅且权威的语言来表达这些错误信息。
  • 成瘾性: 作者承认 LLM 具有强大的实用性,但同时也强调了其成瘾性。用户很容易习惯与 LLM 互动,甚至在遇到问题时会本能地寻求 LLM 的帮助。
  • 技术层面: 作者认为 LLM 的技术本身相对简单,本质上是基于统计推断。 虽然规模训练和 RLHF 等技术有所创新,但其核心技术并非革命性突破。
  • 社会影响: 作者强调 LLM 的社会影响是其真正重要的方面。它们对教育、工作和社会都可能产生重大影响,因为语言是人类思维和身份认同的核心。LLM 能够以可信的方式进入语言领域,标志着一种转变,尽管具体性质尚不明确。
  • 重新定义 LLM: 作者认为,将 LLM 定义为“知识引擎”是不准确的。更合适的定义是“自信引擎”,更能反映它们在短期和中期内对用户的影响。

总结:

文章的核心论点是,虽然大型语言模型技术本身可能并不复杂,但它们对人类心理和社会的影响是深远的。LLM 能够增强用户的自信心,这既可以带来积极的成果,也可能导致用户在错误信息中获得确定感,并因此产生误判。作者呼吁人们以更审慎的态度看待 LLM,认识到它们并非知识的权威来源,而是一种能够放大现有想法并增强自信心的工具。

Time to start de-Appling

总结:苹果高级数据保护 (ADP) 在英国的终止及相关建议

这篇文章主要讨论了苹果公司因英国政府的调查权力法案 (Investigatory Powers Act) 下的临时通知 (TCN) 而在英国终止高级数据保护 (ADP) 功能的情况,以及对用户的影响和应对建议。

核心要点:

  • ADP 终止: 苹果将逐步停止为英国用户提供 ADP 功能,现有用户需要在苹果给出提示之前手动关闭该功能,否则将失去 iCloud 账户。
  • 法律背景: 文章避免详细解释法律细节,但指出苹果的这一行为是在地缘政治斗争中的一种应对方式。
  • 影响范围: 尽管 ADP 被终止,iCloud Keychain、Health 等默认端到端加密的数据类别以及 iMessage 和 FaceTime 等通信服务将继续受到保护。 但 iCloud Backup、iCloud Drive、Photos、Notes、Reminders、Safari Bookmarks、Siri Shortcuts、Voice Memos、Wallet Passes 和 Freeform 等 10 个 iCloud 数据类别将不再享受 ADP 的端到端加密保护,而是采用标准数据保护。
  • 行动建议:
    • 尽快备份数据: 建议用户尽快将上述 10 个数据类别的数据从 iCloud 备份到其他地方。
    • 选择合适的替代方案: 建议不要将数据迁移到其他大型科技公司或非端到端加密的服务。推荐使用 Proton 等端到端加密服务。
    • Notes 数据迁移: 推荐使用 Exporter 应用将 Notes 数据导出为 Markdown 格式,然后迁移到其他支持端到端加密的笔记服务,如 Standard Notes、Obsidian 或 Joplin。
  • 更广泛的担忧: 文章指出,英国政府的 TCN 不仅针对 ADP 保护的数据,还可能涉及对所有 iCloud 数据的访问,这使得用户需要重新评估对苹果生态系统的信任程度。
  • 英国以外的用户: ADP 在英国以外的地区仍然可用,建议未启用 ADP 的用户尽快启用。
  • 第二份 TCN: 英国政府发布了第二份 TCN,针对的是英国公民的数据,引发了对苹果将如何区分英国用户和英国公民的质疑。
  • 未来发展: 预计在 1 月份,Liberty/PI 对第一份 TCN 的挑战将提交给调查权力法庭 (Investigatory Powers Tribunal)。

总结:

这篇文章强调了英国政府对数据访问权的监管政策对苹果用户的影响,并建议用户采取积极措施保护自己的数据安全和隐私。 同时,文章也提醒用户对苹果生态系统的依赖进行重新评估,并考虑使用更安全的替代方案。

Honda: 2 years of ml vs 1 month of prompting - heres what we learned

汽车保修索赔分类:从SQL到大型语言模型

本文讲述了一个汽车制造商如何从传统的基于SQL的保修索赔分类系统转向使用大型语言模型(LLM)的经验。

背景:SQL分类的局限性

汽车制造商每年因召回而损失数百万美元。为了解决这个问题,公司建立了一个分析部门,负责将保修索赔分类为可执行的操作问题。长期以来,该团队依赖于SQL查询进行分类,但随着车辆和描述其语言的演变,SQL查询在处理语义、否定和上下文细微差别方面存在局限性。简单的SQL查询容易将不属于实际缺陷的索赔错误地标记为“泄漏”等问题,导致不必要的分析工作和新问题检测的延误。

早期尝试:监督模型

2023年,公司启动了一个使用监督模型自动分类保修索赔的重大项目。该项目经历了以下几个阶段:

  1. 数据收集: 建立“真实情况”标准是首要挑战。团队成员对索赔分类方式存在不同的理解,经过数月的讨论终于达成一致,确定了核心的“症状”类别。随后是耗时的手动标注过程,需要领域专家标注数千个复杂的索赔。
  2. **预处理:**原始保修文本包含缩写、错误代码和多语言输入,需要经过9个阶段的预处理,包括文本清理、连接、分词、缩略词扩展、停用词删除、拼写检查、服务公报提取、诊断代码解析和翻译。 令人惊讶的是,先将法语和西班牙语索赔翻译成德语,反而提高了技术准确性。
  3. 建模: 经过多次尝试,TF-IDF与1-gram特征结合XGBoost模型表现最佳。

大型语言模型的引入

起初,公司尝试使用GPT-3.5进行少样本提示,但结果令人失望。 随着LLM技术的进步,公司开始评估现代LLM在保修索赔分类中的潜力。

基准测试与 Nova Lite

对6种前沿模型进行了基准测试,并使用5个标记数据集进行了评估。虽然XGBoost模型在平均水平上仍领先约15%,尤其是在困难任务中,LLM在更广泛的类别中展现出潜力。 考虑到成本效益,Nova Lite 成为最佳选择,其PR AUC得分仅次于最佳模型,但成本最低。

提示工程与性能提升

公司通过 6 轮提示工程迭代,结合评估与推理,对 Nova Lite 进行了优化。 通过分析提示失败的原因,并利用更大的LLM生成改进建议,Nova Lite 在4个症状类别(切屑、变形错位、泄漏和噪声)中匹配或略胜 XGBoost 模型。在“切屑”类别中,性能提升了 35 个点。

结论与未来展望

公司成功地用LLM匹配了多年构建的监督模型。 这表明,在数据可用性、标注周期或需求快速变化的情况下,LLM 可以将不可能的积压工作转化为一个提示迭代循环, 从而取代了传统的流程。 尽管如此,当拥有稳定的目标和数百万个标记样本时,监督模型仍然有效。

DNS Provider Quad9 Sees Piracy Blocking Orders as "Existential Threat"

Quad9 警告:版权保护诉讼对互联网基础设施构成生存威胁

主要内容:

Quad9,一个非营利性 DNS 解析服务提供商,警告称,日益增多的版权保护诉讼对其服务构成“生存威胁”。由于缺乏足够的资金,Quad9 已经选择不再在法国的法院中代表自己,应对针对盗版网站的封锁请求。

背景:

  • 法国法院的封锁令: 2024年5月,巴黎司法法院命令 Google、Cloudflare 和 Cisco 屏蔽多个盗版体育直播网站。此后,更多版权所有者(如 DAZN 和 beIN)加入了诉讼,并将 Quad9 和 Vercel 等 DNS 提供商也列为目标。
  • 大型科技公司 vs. 小型非营利组织: 这种局面使得资金雄厚的科技巨头(如 Google 和 Cloudflare)与资金有限的非营利组织(如 Quad9)在法庭上对抗。

Quad9 的担忧:

  • 存在性危机: 对于 Google 和 Cloudflare 来说,应对这些法律挑战只是运营成本的一部分,但对于 Quad9 这样的非营利组织来说,这些诉讼成本可能导致其无法生存。
  • 互联网基础设施的威胁: Quad9 认为,版权所有者正在试图将中立的中间商(包括 ISP、VPN 和 DNS 提供商)追究责任,而不仅仅是直接打击侵权者。
  • 影响范围: 这些封锁令不仅影响了 DNS 提供商,还直接影响了关键的互联网基础设施。Quad9 无法仅在法国范围内实施封锁,而是不得不全球范围内执行。
  • 潜在的负面影响: Quad9 担心,这种趋势可能导致一个更加中心化、缺乏隐私和开放性的互联网,将互联网基础设施的控制权交给少数能够承担法律费用的公司。

Quad9 提出的问题:

Quad9 提出了几个关键问题,以引发对互联网运作方式的更广泛讨论:

  • 中立的技术基础设施是否应该为他人的行为负责?
  • 法院的管辖权应该延伸到多远,以对全球网络施加国内法律?
  • 小型非营利组织如何在为全球公司设计的法律义务下生存?
  • 当只有少数公司能够负担得起合规成本时,会发生什么?
  • 在什么情况下,法律合规会变成事实上的审查?

后续影响:

由于法国的封锁措施,Cisco 已经选择离开法国。Quad9 强调,这些法律诉讼可能导致互联网的未来更加黯淡。

Beets: The music geek’s media organizer

Beets 音乐管理工具概要

Beets 是一款旨在整理和优化音乐收藏的工具,其核心目标是确保音乐库的准确性。它通过利用MusicBrainz数据库自动改进音乐文件的元数据信息。

主要功能:

  • 元数据管理: Beets 能够自动获取或计算各种元数据,包括专辑封面、歌词、流派、节拍速度 (tempo)、ReplayGain 水平以及声学指纹 (acoustic fingerprints)。
  • 数据来源: Beets 可以从多个来源获取元数据,例如 MusicBrainz、Discogs 和 Beatport,或者根据文件名或声学指纹进行猜测。
  • 音频转换: 支持将音频文件转换为各种格式。
  • 库管理: 能够检测并处理音乐库中的重复歌曲和专辑,以及缺少曲目的专辑。
  • 可视化浏览和播放: 通过网页浏览器提供图形化的音乐库浏览功能,并在支持 HTML5 Audio 的浏览器中播放音乐。
  • 插件扩展性: Beets 采用插件架构,允许用户通过插件扩展其功能。 插件可以实现各种功能,例如获取专辑封面、歌词、流派、节拍速度、ReplayGain 水平或声学指纹等。

技术特点:

  • 基于库的设计: Beets 被设计为库,这意味着它可以进行各种音乐库管理操作。
  • Python 插件: 即使对 Python 编程有一定了解,也可以轻松编写自定义插件来满足特定需求。

安装与使用:

  • 安装: 使用 pip install beets 命令进行安装。
  • 入门: 建议阅读“入门指南”(Getting Started guide)以开始使用。
  • 更新: 可以关注 @beets 在 Fosstodon 上的更新。

总而言之,Beets 是一款功能强大且灵活的音乐管理工具,它通过自动化元数据管理、音频转换和库管理等功能,帮助用户整理和优化他们的音乐收藏。

Vibe Code Warning – A personal casestudy

好的,这是对 pico2-swd-riscv 项目内容的中文摘要,字数控制在800字以内:

pico2-swd-riscv 项目摘要

pico2-swd-riscv 是一个状态化的 SWD 协议实现,用于调试 Raspberry Pi Pico2 (目标板) 上 RP2350 RISC-V 核心 (Hazard3),利用另一块 Pico 作为调试探针。

项目特点:

  • 基于 GPIO 的 SWD 调试: 通过 GPIO 实现 SWD 协议,无需额外的硬件接口。
  • 状态化协议: 实现了完整的 SWD 协议栈,支持各种调试操作。
  • 高度抽象: 提供多层抽象,简化了 RISC-V 调试过程。
  • 硬件支持: 针对 RP2350 进行了优化,包括特定的 DP_SELECT 编码和启动序列。

代码结构与关键组件:

  • 应用层: 用户代码,调用调试库的 API。
  • 调试模块层 (rp2350.c): 实现了 RISC-V 调试规范,包括心跳控制、寄存器访问、系统总线访问 (SBA) 和程序缓冲区 (PROGBUF) 执行。
  • 调试访问端口层 (dap.c): 处理 DP/AP 寄存器事务,实现了 RP2350 特有的 DP_SELECT 编码和银行缓存。
  • 串行线调试层 (swd*.c): 实现了 2 线双向协议,利用 RP2040/RP2350 的 PIO 模块进行精确的时序控制。

RISC-V 调试架构:

  • Hart 状态机: 定义了 Hart 的三种状态:运行 (RUNNING)、停止 (HALTED) 和恢复 (RESUMING)。
  • 调试模块 (DM): 独立控制器,可以观察 Hart 状态、控制 Hart 状态转换、访问 Hart 寄存器和系统内存。
  • 抽象命令: DM 提供的硬件实现函数调用接口,用于访问寄存器。
  • 程序缓冲区 (PROGBUF): 允许在调试模式下执行自定义 RISC-V 代码,实现高级调试功能。
  • 系统总线访问 (SBA): 提供了一种非侵入式访问系统内存的方式,允许在 Hart 执行过程中读取/写入内存。

协议细节:

  • SWD 协议: 使用 2 线协议,包含请求、确认和数据三个阶段。
  • PIO 模块: 利用 RP2040/RP2350 的 PIO 模块实现精确的时序控制,提高调试效率。
  • Dormant 状态: 用于解决 JTAG 和 SWD 协议共享引脚的问题,需要执行特定的激活序列。

项目开发过程:

该项目是作者尝试使用 AI (Claude) 辅助开发复杂项目的案例研究。虽然代码量很大 (近 10000 行),但作者对代码的理解有限,并且对代码质量存在疑虑。作者认为,使用 AI 辅助文档阅读和脚本编写非常有效,但 AI 生成的代码缺乏“品味”和可理解性,难以维护。

当前限制:

  • 不支持硬件断点 (触发模块)。
  • 不支持多目标 SWD。
  • 不支持压缩指令 (RVC) 扩展。
  • 缺乏性能分析功能。
  • 缺少闪存编程功能。

总结:

pico2-swd-riscv 是一个功能强大的 RISC-V 调试库,基于 RP2040/RP2350 硬件,实现了完整的 SWD 协议栈。该项目展示了 AI 辅助开发的可能性,但也突出了 AI 生成代码的潜在问题。

Sued by Nintendo

Okay, please provide the content you want me to summarize. I'm ready when you are. I will follow your instructions to produce a concise, accurate summary in markdown format and Chinese language, keeping it under 800 words and avoiding personal opinions. I will also note the provided link.

Asus Ascent GX10

ASUS Ascent GX10:超小型AI超级计算机总结

以下是对ASUS Ascent GX10数据表内容的总结,重点突出主要特点和功能,字数控制在800字以内。

# 概述 (Summary)

ASUS Ascent GX10是一款基于NVIDIA GB10 Grace Blackwell Superchip和NVIDIA AI软件平台的超小型AI超级计算机,旨在为AI开发和部署提供完整的解决方案。其紧凑的设计便于集成和部署,为追求卓越的创新者提供强大的AI性能。它集成了先进的AI工具和NVIDIA® ConnectX®-7,提升了AI能力,并支持独特的解决方案。

# 设计 (Design)

GX10采用创新设计,将 petaflop 级别的AI计算能力带到开发者、AI研究员和数据科学家的桌面上,实现本地AI开发。其核心优势在于:

  • 紧凑尺寸: 150 x 150 x 51mm
  • 强大的AI性能: 最高可达1 petaFLOP (FP4精度)
  • 128GB LPDDR5x 统一系统内存: 满足模型开发、实验和推断的需求
  • 采用 NVIDIA GB10 Grace Blackwell Superchip: 包含强大的Blackwell GPU和第五代Tensor Cores,支持FP4。
  • 20核Arm CPU: 加速数据预处理和编排,提升模型调优和实时推断。
  • NVLink™-C2C技术: 提供CPU+GPU协同内存模型,带宽是 PCIe 5.0 的五倍。

# 性能 (Performance)

GX10能够支持高达2000亿参数的AI模型,便于原型设计、微调和推理。通过集成NVIDIA® ConnectX®-7网络技术,可以将两台GX10系统连接起来,处理更大的模型,例如4050亿参数的Llama 3.1。

# AI 网络 (AI Networking)

NVIDIA® ConnectX-7提供超高速网络,实现快速的数据传输和低延迟的通信,特别适合大规模分布式AI工作负载。内置硬件加速TLS、IPsec和MACsec,确保加密数据传输而不占用CPU资源。IEEE 1588v2 PTP支持,实现微秒级的时同步,适用于对时间敏感的AI和边缘计算应用。

# AI 体验 (AI Experience)

GX10预装了NVIDIA DGX OS (基于Ubuntu Linux),提供优化的AI环境。集成了 NVIDIA AI 软件栈,包括CUDA、PyTorch、TensorFlow、Jupyter等框架。支持NVIDIA NIMs & Blueprints,提供预构建的AI工作流和微服务。支持DeepSeek R1、Llama 3.1等流行的AI模型。

# 散热 (Thermal)

GX10采用先进的双风扇设计,具有7级控制,提供精确的散热效果。相比同等尺寸的系统,散热效率提升1.6倍,确保系统在重负载下保持凉爽和稳定运行。

# 可扩展性 (Scalable)

GX10具有高效的散热设计,支持高密度AI计算,且体积紧凑,方便部署。

# 连接性 (Connectivity)

GX10 提供丰富的I/O接口:

  • Kensington锁孔
  • 1 x USB 3.2 Gen 2x2 Type-C (20Gbps, DisplayPort 2.1, 180W EPR PD3.1)
  • 3 x USB 3.2 Gen 2x2 Type-C (20Gbps, DisplayPort 2.1)
  • HDMI 2.1b 端口
  • 10 GbE LAN 端口
  • NVIDIA ConnectX®-7 NIC

# 应用 (Application)

GX10适用于:

  • 本地开发: 方便快速的原型设计和调试。
  • 可扩展部署: 可以无缝迁移到DGX Cloud或其他加速云平台。
  • 成本效益的实验平台: 释放集群资源,用于训练和部署生产模型。
  • 数据科学: 支持各种数据分析和模型构建任务。

# 联系我们 (Contac Us)

可以订阅邮件,获取关于ASUS Ascent产品的最新信息。

# 常见问题 (FAQ)

解答了关于内存带宽、软件工具、可集群性、与 NVIDIA DGX Spark 的区别、支持的AI应用、以及在教育和企业环境中的使用等问题。

Python Software Foundation gets a donor surge after rejecting federal grant

The New Stack Newsletter Subscription and PSF Grant Rejection Summary (中文)

本文总结了 The New Stack 的邮件订阅流程以及 Python Software Foundation (PSF) 因拒绝一项联邦资助而引发的社区支持事件。

一、The New Stack 邮件订阅

  • 社区加入: The New Stack 邀请软件工程领导者和有抱负的开发者加入其社区,获取最新的新闻和独家内容。
  • 订阅流程: 用户需要提供姓名、公司名称、国家、邮编和 LinkedIn 个人资料 URL 等信息以完成订阅。如果用户之前已取消订阅,需要重新订阅。
  • 隐私承诺: The New Stack 承诺不会出售或与非关联的第三方共享用户信息。
  • 后续行动: 订阅成功后,用户将收到确认邮件,可以调整偏好设置并加入其他群组。建议在社交媒体上关注 The New Stack。
  • JavaScript 调查: The New Stack 正在调查 JavaScript 开发者最常用的非 React 工具,提供 Angular、Astro、Svelte、Vue.js 等选项,并允许用户选择“其他”或“仅使用 React”。订阅邮件可获取最终结果。

二、PSF 拒绝资助及社区支持

  • 事件起因: PSF 拒绝了一项价值 150 万美元的美国国家科学基金会 (NSF) 资助,原因是新的联邦条款和条件要求停止任何推广多元、公平和包容 (DEI) 的项目。
  • 社区反应: 拒绝资助后,PSF 获得了社区的强烈支持,包括大量捐款和积极的社交媒体互动。
  • 关键人物支持: Python 创始人 Guido van Rossum 以及其他董事会成员,包括 Simon Willison,公开表达了对 PSF 的支持。
  • 捐款涌入: 在宣布拒绝资助后的第一天,PSF 收到约 300 份捐款,随后捐款数量持续增加。截至发布本文时,PSF 已收到超过 15.7 万美元的捐款,包括 295 名新年度 99 美元会员。
  • 媒体报道: 事件引发了包括 Ars Technica、BleepingComputer、LWN.net、CyberScoop 和 TechRadar 等媒体的广泛报道。
  • 未来展望: PSF 正在积极寻找其他资金来源,并计划继续致力于安全项目,例如改进 Python Package Index (PyPI) 的安全措施。尽管短期内资金缺口较大,但 PSF 仍在探索欧洲资助、企业赞助和个人捐赠等多种渠道。

总而言之,PSF 拒绝资助事件突显了开源社区的团结和对价值观的坚守,并获得了社区的积极响应和有力支持。

LLM policy?

runc 项目关于 LLM 生成内容的处理方案讨论总结

该讨论主要围绕 runc 项目如何处理由大型语言模型 (LLM) 生成的拉取请求 (Pull Requests) 和问题 (Issues)。由于近期 LLM 生成的贡献数量有所增加,需要制定明确的策略并记录在 CONTRIBUTING.md 文件中。

核心观点:

  • Issues (问题): 建议将所有 LLM 生成的 Issues 视为垃圾信息并关闭。即使描述的问题真实存在,LLM 生成的描述通常包含大量冗余且可能不准确的信息。 最好让用户直接提供他们使用的 LLM Prompt 作为 Issue 内容。更重要的是,在处理 Bug 时,需要假设用户描述的问题确实发生过,而 LLM 生成的 Issue 无法保证描述的真实性。 讨论中引用了 #4982#4972 作为 LLM 生成 Bug 报告的例子。
  • Code (代码): 对于 LLM 生成的代码,最低要求是提交者需要能够用自己的话回答代码评审请求,即他们必须理解其补丁的功能并能够独立编写代码。 引用了 #4940#4939 作为最近的例子,并对提交者的理解程度表示怀疑。
  • 法律风险 (Legal Risks): 个人观点认为,LLM 生成的代码可能无法满足开发者行为声明 (DCO) 的要求,并且其版权状况尚不明确,因此不应接受,但这种观点可能属于少数。
  • 参考案例 (Reference Case): Incus 项目今年早些时候在其 CONTRIBUTING.md 文件中添加了一条说明,禁止所有 LLM 的使用 (https://github.com/lxc/incus/commit/54c3f05ee438b962e8ac459262d509cfb8bcdf30)。

总结: runc 项目正考虑采取更严格的策略来处理 LLM 生成的贡献,重点在于验证贡献者的理解能力和确保代码的版权合规性。

Europe to decide if 6 GHz is shared between Wi-Fi and cellular networks

欧洲6 GHz频谱争端:Wi-Fi与移动网络之间的博弈

本文报道了欧洲针对6 GHz无线频谱分配的争议,主要围绕是否将其授权给蜂窝网络或保留给Wi-Fi使用展开。

核心问题:

  • 6 GHz频谱(特别是6425到7125 MHz的上限频段)是Wi-Fi 6E和Wi-Fi 7等新标准的关键,它们利用该频段提供更高性能。
  • 移动运营商也希望利用该频段进行5G和6G网络服务。

各方立场:

  • Wi-Fi联盟和动态频谱联盟 (DSA): 通过公开信表达担忧,认为德国可能倾向于将上限频段完全分配给移动网络,这可能影响欧洲数字发展,并限制Wi-Fi的进步。他们强调Wi-Fi是消费者访问互联网的主要方式,且Wi-Fi对上限频段的需求远大于移动网络。DSA的成员主要由亚马逊、苹果、Meta、微软、Broadcom和思科等美国科技巨头组成。
  • 移动运营商 (如沃达丰、诺基亚和Telia): 认为该频段应授权给移动网络,以增强欧洲的数字主权,并提升蜂窝容量。他们通过测试和试点项目展示了利用该频段实现高达5 Gbps的下载速度以及在城市和乡村地区提供高吞吐量的能力。
  • 德国政府: 联邦数字与交通部表示,考虑到未来6G应用的需求,移动网络运营商对上限频段的需求更大。
  • 国际电信联盟 (ITU): 在2023年的世界无线电会议 (WRC) 上,将上限6 GHz频段划归蜂窝服务使用。

欧盟的应对:

  • 欧洲委员会的无线电频谱政策小组 (RSPG) 正在探索在Wi-Fi等免许可技术和移动网络之间共享上限6 GHz频段的方法。
  • 欧洲委员会已委托欧洲邮政和电信管理局 (CEPT) 开发欧盟协调的技术条件,并在2027年7月提交最终报告。

当前进展:

  • 英国电信监管机构Ofcom已采取类似政策,在2023年咨询后决定。
  • RSPG将于11月12日举行下一次全体会议,届时将决定是否做出任何决策。

总结:

欧洲的6 GHz频谱分配问题涉及Wi-Fi技术发展、移动网络容量提升以及数字主权等多个方面。各方观点不一,欧盟正在寻求一种平衡的解决方案,以确保频谱资源的有效利用和欧洲数字经济的持续发展。

Writing your own BEAM

BEAM 虚拟机玩具实现探索

本文介绍了作者在探索 BEAM 虚拟机(Erlang, Elixir, Gleam 等语言的虚拟机)原理时,编写的一个玩具 MVP 实现的过程。该实现并非追求真实性、实用性或性能,而是基于作者对 BEAM 的理解,从底层原理出发进行探索。

核心概念与实现:

  • AST 表示: 作者使用延续传递风格 (CPS) 来表示程序,避免了环境、作用域等复杂管理,简化了实现。
  • 指令: 实现了 End (结束), Work (执行), Spawn (生成进程), Send (发送消息), Receive (接收消息), Crash (崩溃), Link (链接) 等核心指令。
  • Scheduler (调度器): Scheduler 是整个虚拟机的核心,负责管理进程和执行指令。它维护了一个进程字典 (processes),一个未使用的 PID 计数器 (nextUnusedPid),以及一个就绪队列 (readyQueue)。step 函数是调度器的核心循环,从就绪队列中选择进程并执行其指令。
  • 进程: 进程包含一个程序 (program) 和一个邮箱 (mailbox),用于接收消息。
  • Reduction Budget (减少预算): 为了模拟 BEAM 的预选调度,引入了 Reduction Budget。Work 指令不再一次性执行,而是根据预算分批执行。
  • 链接: 实现了进程之间的链接,当一个进程崩溃时,会向其链接的进程发送系统消息。

关键技术点:

  • 延续传递风格 (CPS): 简化了程序表示,避免了环境和作用域管理。
  • 进程管理: 使用字典和队列来管理进程和调度器。
  • Reduction Budget: 模拟预选调度,提高并发效率。
  • 消息传递: 通过邮箱实现进程间的消息传递。

代码实现语言:

  • Elm (纯函数式语言,单线程,无并发原语)

总结:

作者通过编写一个玩具 BEAM 实现,深入理解了 BEAM 虚拟机的核心原理,包括进程管理、消息传递、Reduction Budget 和链接等关键特性。 该实现并非旨在提供一个完整的虚拟机,而是为了探索 BEAM 的底层机制,并展示这些机制如何协同工作,从而赋予 BEAM 语言其独特的魅力。虽然该实现与真实 BEAM 虚拟机存在差异,但它提供了一个理解 BEAM 设计思想的良好视角。

Work after work: Notes from an unemployed new grad watching the job market break

总结:自动化、劳动力市场变革与“分布外人类” (Zǒngjié: Zìdònghuà, Láodònglì Shìchǎng Biàngé yǔ “Fēnbù Wài Rénlèi”)

本文作者分享了作为计算机科学新毕业生在就业市场中面临的困境,并探讨了自动化对白领职业的影响。文章的核心观点是,尽管官方数据显示失业率仍然较低,但实际情况是,尤其对于新毕业生而言,就业市场已经变得“破碎”,机会密度显著下降。

以下是文章的主要内容:

1. 个人经历与就业困境 (Gèrén Jīnglì yǔ Jiùyè Kùnjìng):

  • 作者完成了大学学业,实习,并尝试过创业,拥有标准的简历和技能,但仍然面临求职困难。
  • 许多计算机科学专业的毕业生都面临着相似的困境,感受到就业市场竞争激烈,入门级职位逐渐消失。

2. 自动化与劳动力市场 (Zìdònghuà yǔ Láodònglì Shìchǎng):

  • 文章回顾了十年前关于自动化可能取代一半美国工作的预测,并指出后续研究表明风险并未如最初预测般巨大。
  • 然而,自动化带来的“缓慢压力”确实存在,导致重复性、可编码任务的岗位减少,工资下降,而需要社交技能或实际操作的岗位更具优势。
  • 亚马逊的案例表明,企业正在重新评估劳动力需求,倾向于使用机器人和软件来减少人力投入,并鼓励股东和银行也这样做。
  • “远程操作”的出现进一步加剧了这种趋势,例如菲律宾工人通过VR头显远程操控日本便利店的货架机器人。

3. “分布外人类” (Fēnbù Wài Rénlèi):

  • 远程操作的另一个关键点是,许多此类工作不仅用于完成任务,还用于收集数据,以训练未来的自动化系统。这使得工人不仅要完成工作,还要成为训练数据的来源,本质上是为自己的替代品做准备。
  • 文章提出“分布外人类”的概念,指的是那些从事需要创新性、不依赖大量历史数据的、或者在复杂物理环境中工作的个体。
  • 目前,大多数人仍然试图进入劳动力市场的中心区域,而自动化正在逐渐侵蚀这一区域。

4. 历史背景与未来趋势 (Lìshǐ Bèijǐng yǔ Wèilái Qūshì):

  • 过去,社会普遍认为工作是社会组织的核心,并赋予劳动以尊严。
  • 然而,随着自动化技术的发展,这一观念正在发生改变。
  • 文章引用了韩国、日本、德国和中国的例子,这些国家在自动化方面投入巨大,但同时也面临着青年失业率上升等问题。
  • 文章认为,需要重新思考工作在社会中的角色,并为可能出现的劳动力规模缩减做好准备。

总结 (Zǒngjié):

文章对自动化对劳动力市场的影响进行了深刻的剖析,指出自动化不仅会取代部分工作,还会改变工作的性质和要求。作者呼吁人们关注“分布外人类”的价值,并重新思考工作在社会中的地位,以适应未来的劳动力市场变革。文章的最后,暗示了未来可能出现“人机共生”或者“人作为训练数据”的新型工作模式。

Metabolic and cellular differences between sedentary and active individuals

运动不足的代谢隐患:一项研究揭示了早期功能障碍

本文总结了一项由San Millán及其同事发表的研究,该研究强调了即使在没有诊断疾病和正常实验室检测结果的情况下,运动不足也可能导致代谢功能障碍。

核心观点:

  • 代谢疾病的潜伏期: 大多数代谢性疾病(如2型糖尿病、胰岛素抵抗、脂肪肝等)通常在常规体检和血液检测结果异常之前就已经存在十年之久。问题的关键在于“时间累积效应”,即代谢功能逐渐恶化。
  • 研究发现: 该研究对比了久坐不动但身体健康的个体与年龄和BMI相似但适度运动的人群。结果显示,即使没有高血糖或高胆固醇,久坐人群的肌肉代谢已经出现衰退。
  • 肌肉代谢功能下降: 肌肉活检显示久坐人群在以下方面存在显著下降:
    • 线粒体呼吸 (Complex I下降36%,总ETC容量下降34%)
    • 脂肪氧化 (CPT1活性下降51%)
    • 丙酮酸氧化 (下降37%),尽管GLUT4水平相同。
  • 代谢能力指标: 与活跃人群相比,久坐人群还表现出:
    • 更低的VO₂ max和最大功率输出
    • 更差的脂肪氧化能力
    • 显著更差的乳酸清除能力(代谢灵活性的关键指标)
  • 健康风险: 这些发现预示着可能导致寿命缩短和现代医疗负担加重的疾病,例如2型糖尿病、心血管疾病和痴呆症。
  • 运动不足并非中性状态: 久坐不动并不是一个正常的基线状态,而是一种早期功能障碍。身体的细胞机制开始悄然衰退。
  • 可逆性: 这些代谢变化并非不可逆转,可以通过规律运动、力量训练和坚持不懈来恢复身体的代谢功能。
  • 健身的本质: 健身不仅仅是外在形象,更是细胞功能的体现。

总结:

这项研究表明,即使感觉良好且实验室结果正常,久坐不动的生活方式也可能导致代谢功能的早期损害。 运动是恢复和维持健康代谢的关键干预措施。 强调了规律运动的重要性,认为“如果你不运动,你就是生病了,只是你还没意识到而已。”

Show HN: Tiny Diffusion – A character-level text diffusion model from scratch

tiny-diffusion 项目摘要

tiny-diffusion 是一个基于字符级的语言扩散模型,用于文本生成。该模型是对 nanochat gpt 实现的修改版本,并在 Tiny Shakespeare 数据集上进行训练。其参数量仅为 1070 万,因此可以在本地进行尝试。

核心特点:

  • 模型类型: 字符级语言扩散模型
  • 参数量: 10.7 百万
  • 训练数据: Tiny Shakespeare
  • 基础模型: 基于 nanochat gpt

安装:

  1. 克隆仓库: git clone <repository-url>
  2. 进入仓库目录: cd tiny-diffusion
  3. 安装依赖 (Python 3.10+): uv sync

快速开始:

  • training.py 将权重保存到 weights/diffusion_model.ptsample.py 和动画文件会从该文件加载模型。

训练模型 (可选):

  • 从头开始在 Shakespeare 数据集上训练: uv run training.py。 训练会将检查点保存到 weights/diffusion_model.pt。 训练大约需要半小时,在 4xA100 GPU 上进行 20,000 步训练。

文本生成:

  • 使用预训练模型生成文本: uv run sample.py。 输出流的长度当前为 30 个上下文长度。

可视化扩散过程:

  • 观看去噪过程的逐步动画: uv run animations/diffusion-process.py
  • 查看受生命游戏启发的采样 (有趣的实验): uv run animations/game-of-life.py

默认配置:

  • 参数: 10.7 百万
  • 层数: 6
  • 注意力头数: 6
  • 嵌入维度: 384
  • 序列长度: 256 个字符
  • 扩散步数: 128

文件结构:

  • model.py: 核心扩散变换器
  • training.py: 训练脚本
  • sample.py: 文本生成
  • data/tiny_shakespeare.txt: 训练数据
  • weights/diffusion_model.pt: 预训练权重
  • animations/diffusion-process.py: 去噪过程可视化
  • animations/game-of-life.py: 生命游戏采样

许可证:

MIT 许可证。

The Principles of Diffusion Models

扩散模型核心原理综述

这篇单篇论文阐述了指导扩散模型发展的核心原理,追溯了其起源,并展示了多样化表述如何源于共享的数学思想。 扩散模型的核心在于定义一个正向过程,该过程逐渐将数据腐蚀成噪声,通过一系列中间分布将数据分布与一个简单的先验分布联系起来。 目标是学习一个逆向过程,将噪声转化为数据,并恢复相同的中间状态。

论文提出了三种互补的视角:

  • 变分视角 (Variational View): 灵感来自变分自编码器 (VAE),将扩散视为逐步去除噪声的过程。
  • 得分视角 (Score-based View): 根植于能量模型,学习演化数据分布的梯度,指示如何将样本推向更可能的区域。
  • 流视角 (Flow-based View): 与归一化流相关,将生成视为沿着学习到的速度场从噪声移动到数据的平滑路径。

这三种视角都共享一个共同的基础:一个随时间变化的“速度场”,该速度场将简单的先验分布输送至数据分布。 采样过程相当于求解一个微分方程,沿着连续轨迹将噪声演化为数据。

基于此基础,论文讨论了可控生成、高效数值求解器以及受扩散模型启发的流图模型,这些模型学习任意时间之间的直接映射。

总而言之,这篇论文为具有基本深度学习知识的读者提供了扩散模型的概念和数学基础理解。

关键词: 扩散模型, 变分自编码器, 能量模型, 归一化流, 速度场, 生成模型, 数值求解, 可控生成。

Reminder to passengers ahead of move to 100% digital boarding passes

瑞安航空将全面转向100%数字登机牌

瑞安航空(Ryanair),欧洲最大的航空公司,今日(11月6日,星期四)提醒乘客,从11月12日(星期三)起,将全面转向100%数字登机牌。这意味着从11月12日起,乘客将无法下载和打印纸质登机牌,必须在办理登机手续时使用“myRyanair”应用程序生成的数字登机牌才能登机。

这项转变已经有近80%的2.07亿多名瑞安航空年度乘客采用。全面转向数字登机牌旨在提供更快速、更智能、更环保的旅行体验,并让乘客更容易访问一系列创新的应用程序功能,包括:

  • 点餐至座位 (Order to Seat): 通过手机点餐并优先获得服务。
  • 实时航班信息 (Live Flight Information): 实时更新登机、登机口和延误状态。
  • 直接更新 (Direct Updates): 在出现运营中断时,从瑞安航空运营中心获取即时通知。
  • 替代航班选项 (Alternative Flight Options): 在出现运营中断时,提供实时的替代航班选项。
  • 旅行文件 (Travel Documents): 所有旅行文件集中在一个方便的位置。

瑞安航空首席营销官 Dara Brady 表示: “我们距离全面转向数字登机牌仅剩不到一周的时间,从11月12日星期三起,乘客将不再能够下载和打印纸质登机牌,而是需要使用在“myRyanair”应用程序中生成的数字登机牌登机。 虽然超过80%的乘客已经在使用数字登机牌,因此此项变革对他们影响不大,但我们提醒仍然打印登机牌的少数乘客,在11月12日全面转向数字登机牌之前,下载“myRyanair”应用程序。”

Brady 补充说:“全面转向数字登机牌意味着为乘客提供更快速、更智能、更环保的体验,同时也能更轻松地访问一系列创新的应用程序功能,包括‘点餐至座位’、实时航班信息和运营中断时的直接更新。我们期待通过我们一流的“myRyanair”应用程序,为100%的客户提供更出色的旅行体验。”

When Tesla's FSD works well, it gets credit. When it doesn't, you get blamed

特斯拉自动驾驶系统争议与未来责任归属 (Tesla Autopilot Controversy and Future Liability)

本文主要探讨了特斯拉自动驾驶(Autopilot 和 FSD)系统发展历程、安全数据争议以及未来责任归属变化的可能性。

1. 系统发展与定义演变:

  • 特斯拉自 2013 年起推广 Autopilot 和 FSD 系统。
  • 最初 Autopilot 仅在高速公路上使用,类似“智能巡航控制”。
  • FSD 承诺实现完全自动驾驶,但目前尚未实现。
  • Autopilot 逐渐成为标配,FSD 则作为额外付费功能,价格最高可达 15,000 美元。
  • Autopilot 旨在作为驾驶辅助工具,而 FSD 目标是完全自动驾驶。

2. 自动驾驶等级分类:

  • Autopilot 和 FSD 均属于“Level 2”自动驾驶系统,根据 SAE 标准,驾驶员始终负责车辆的操控。
  • Level 3 系统在特定情况下可将责任转移给车辆,Level 4 和 5 系统则完全由车辆负责。
  • 目前美国市场上 Mercedes DRIVE PILOT 是 Level 3 系统,而 Waymo 的无人出租车则属于 Level 4 系统。
  • 特斯拉的目标是 Level 5 自动驾驶,即无需人为干预即可跨国行驶。

3. 安全数据争议:

  • 特斯拉经常宣称 FSD 系统比人类驾驶更安全,并发布数据表明 FSD 系统每事故里程数低于人类驾驶。
  • 然而,这些数据存在“ cherry-picking” (选择性呈现)问题,缺乏对外部变量的控制,且与第三方数据存在差异。
  • 第三方数据表明,特斯拉的“每事故里程数”相对较低,理想的自动驾驶系统应能行驶数万公里而不需人工干预。
  • 特斯拉提供的安全数据始终依赖于 FSD 与人类驾驶员的协同,而非单独的 FSD 系统。

4. 责任归属争议:

  • 特斯拉通常将事故责任归咎于驾驶员,强调驾驶员在使用 Autopilot 和 FSD 系统时需要保持警惕。
  • 佛罗里达州一起致命事故中,特斯拉辩称驾驶员疏忽导致事故,但法院最终判决特斯拉承担 33% 的责任,赔偿 2.43 亿美元。
  • 特斯拉曾试图阻止法院考虑 CEO 马斯克关于 Autopilot 和 FSD 能力的声明,但未能成功。
  • 特斯拉此前曾选择在类似案件中庭外和解,但此次佛罗里达州案件未和解,可能是一项战略失误。

5. 未来责任归属变化的可能性:

  • 特斯拉计划允许驾驶员在车辆行驶过程中发送短信,降低对驾驶员注意力的要求。
  • 这一举动可能导致未来法院更容易判定特斯拉对其自动驾驶系统的安全责任进行追究。
  • 此前,特斯拉曾考虑利用车载摄像头监控驾驶员行为,但法律顾问反对。
  • 如果特斯拉鼓励驾驶员分心驾驶,并允许自动驾驶系统在驾驶员不注意的情况下运行,那么特斯拉可能更难继续将责任归咎于驾驶员。

总而言之,特斯拉在自动驾驶技术发展过程中,既夸大其技术能力,又倾向于将事故责任推给驾驶员。未来,特斯拉的政策转变可能会改变这种局面,使其在自动驾驶事故中承担更大的责任。

Realtime BART Arrival Display

BART 平台显示器项目总结 (BART Platform Display Project Summary)

本文描述了一个作者自制的迷你 BART 平台显示器项目,旨在复刻 BART 车站平台指示牌的复古风格,方便用户查看实时列车到达信息。

项目概述:

作者对 BART 系统既爱又恨,希望通过自制显示器,在获得实时列车信息的同时,也能拥有类似 BART 车站指示牌的视觉体验。

硬件组成:

  • 微控制器: Seeed Studio XIAO ESP32C6
  • 显示屏: BuyDisplay 红色 20x4 字符 OLED 显示模块
  • 逻辑电平转换器: SparkFun Logic Level Converter
  • 其他:使用万孔板和插针将所有组件连接,形成类似卡槽的模块,直接插入显示屏。

软件 (固件):

  • BART API 使用 GTFS Realtime 协议。
  • 由于 ESP32 资源有限,作者构建了一个中间服务 (bart-proxy, 代码在 GitHub 上可用:https://github.com/filbot/bart-proxy),专门负责从 BART API 获取数据、提取所需信息并提供简化 API 给 ESP32 调用。

制作过程:

  • 作者设计并打印了显示器的外壳。
  • 对 3D 打印件进行后期处理,包括打磨和喷漆。
  • 使用了 Brother 标签打印机制作了与真实 BART 平台指示牌类似的品牌和平台信息标签。
  • 最终将显示器安装在桌面金属架上。

项目成果:

该项目成功地制作出一个迷你 BART 平台显示器,能够实时显示列车到达信息、时间以及 BART 平台的安全提示信息(如“请勿越过黄色线”)。作者认为,虽然可以通过在线方式获取信息,但拥有一个迷你版的平台显示器更加有趣。3D 文件可在 Makerworld 上下载:https://makerworld.com/en/models/1979236-mini-bart-platform-display

How the UK lost its shipbuilding industry

英国造船业的兴衰:从全球霸主到衰落 (Zhōngguó zàochuán yè de xīngshuāi: cóng quánqiú bàzhǔ dào shuāilù)

本文回顾了英国造船业的兴衰历程,从19世纪末的全球主导地位到2023年完全退出商业船只建造市场。

辉煌时期 (Huīhuáng shíqí):

  • 19世纪末至20世纪50年代: 英国是世界上最大的造船国,在19世纪90年代曾占据全球运输能力的80%。即使在第一次世界大战前,英国也仍然占据全球市场份额的60%。
  • 二战后短暂的繁荣: 二战后,英国造船业迎来短暂的繁荣,由于其他国家的造船业遭受破坏,英国一度建造了全球超过一半的船只。
  • 低成本生产模式: 英国造船业的成功源于其独特的生产模式:高度依赖熟练劳动力,而非昂贵的设备和管理。这种模式在初期使其能够以更低的成本和更高的效率建造船只。

衰落的根源 (Shuāilù de gēnyuán):

  • 无法适应变化: 随着市场和船只技术的改变,英国造船业未能及时调整。
  • 竞争压力: 美国等国家采用了新型造船方法,使得英国的低成本优势逐渐丧失。
  • 僵化的生产模式: 英国造船业对技术创新持谨慎态度,未能及时采用焊接和预制等先进技术。
  • 劳工关系: 严格的工会制度和劳工分工阻碍了生产效率的提升和技术改进。
  • 外部因素:
    • 华盛顿海军条约和伦敦海军条约: 限制了英国海军的扩张,降低了对军用船只的需求。
    • 全球经济衰退: 1920年代的经济衰退和1930年代的全球贸易下降对英国造船业造成严重打击。
    • 新兴市场: 德国、瑞典和日本等国家的造船业迅速崛起,并提供了更具竞争力的价格和更快的交货时间。
    • 技术变革: 大型船只和柴油动力船的兴起,以及预制技术的进步,改变了造船行业的需求,而英国造船业未能及时适应。

政府介入与最终的失败 (Zhèngfǔ jièrù yǔ zuìzhōng de shībài):

  • 政府的努力: 英国政府在二战后采取了多项措施,例如成立国家造船安全公司(National Shipbuilders Security)和英国造船业公司(British Shipbuilders),试图振兴该行业。
  • 无效的改革: 尽管政府投入了大量资金和政策支持,但英国造船业的竞争力并未提升。
  • 最终的退出: 随着全球市场竞争的加剧,英国造船业最终走向衰落,并在2023年完全退出商业船只建造市场。

总结 (Zǒngjié):

英国造船业的兴衰教训深刻。它表明,即使在初期拥有竞争优势,也必须不断创新和适应变化才能保持领先地位。僵化的生产模式、劳工关系以及未能及时采用新技术,最终导致英国造船业的衰落。英国的案例也说明,政府的干预虽然重要,但如果行业自身缺乏改革的动力和能力,也难以扭转颓势。

Drilling down on Uncle Sam's proposed TP-Link ban

The U.S. government is reportedly preparing to ban the sale of wireless routers and other networking gear from TP-Link Systems, a tech company that currently enjoys an estimated 50% market share among home users and small businesses. Experts say while…

Installing and using HP-UX 9

HP-UX 9 安装与使用总结

发布日期: 2025-11-08

背景: 作者获得了一台免费的 HP 9000/300 系列 (Model 340) 工作站,并意外地获得了其他几台老式计算机,包括 HP 9000 Model 715 (PA-RISC), DEC microVAX 3100, IBM RS/6000, 以及多台 Sun SPARCstation。本文主要讲述作者安装和使用 HP-UX 9 在 Model 340 上的经历。

HP 9000 Model 340 硬件规格:

  • CPU:Motorola 68030 @ 16.7 MHz
  • FPU:Motorola 68882
  • 内存:16 MiB
  • 显卡:高分辨率彩色显卡 (1280x1024, 256 色, 75 Hz)
  • 接口:HP-IB (磁盘驱动器和外设), HIL (键盘和鼠标), 10base2 Ethernet

HP-UX 9 for Series 700 (PA-RISC):

  • 作者介绍了在 HP-UX 9 中设置集群的步骤,HP-UX 9 是支持 68K 和 PA-RISC 混合集群的最后一个版本。
  • 安装过程包括使用 BlueSCSI 启动安装 CD,格式化硬盘,并选择要安装的文件集。
  • 通过 SAM 工具配置集群服务器,需要先将系统置于单用户模式。

An Absolute Cluster... Server & HP-UX 9 for Series 300 (68K):

  • Model 340 没有磁盘驱动器,需要通过网络启动或使用 HP-IB 磁盘驱动器。
  • 作者使用 HPDrive 模拟器进行网络启动,并使用 HP-IB 卡和 Windows XP PC 进行测试。
  • 为了实现集群功能,作者在 Model 705 上安装了 HP-UX 9 for Series 700,并将其作为集群主机。
  • 有趣的是,作者在 Model 705 上安装了 HP-UX 9.10 for Series 300,覆盖了现有的系统,并实现了 68K 和 PA-RISC 混合集群。
  • HP-UX 9 使用了 Context Dependent Filesystem (CDF),即文件系统内容根据机器架构而不同。

Context Dependent Filesystems:

  • CDF 允许文件系统根据上下文(例如机器架构)提供不同的文件内容。
  • 文件系统中的文件可能同时存在多个版本的副本,每个版本对应一个不同的上下文。
  • 作者通过 makecdf 命令创建 CDF。

Fixing X11R5:

  • 作者发现 Model 340 运行 VUE 桌面时,X11 服务器启动失败,原因是缺少 libSXR5.sl 库。
  • 通过手动创建 CDF 并重新执行安装,解决了该问题。

总结:

  • 作者成功地在 HP 9000 Model 340 上安装和运行了 HP-UX 9,并实现了 68K 和 PA-RISC 混合集群。
  • 作者强调了 Context Dependent Filesystem 的特殊性,以及它带来的挑战和可能性。
  • 作者计划在 Retro Computer Festival 上展示这些老式计算机。
  • Bitsavers 网站提供了关于 HP-UX 的相关文档,值得参考。
Microsoft's lack of quality control is out of control

微软质量控制的现状:从“传奇”到质疑

本文主要探讨了微软近年来产品质量控制方面的问题,并质疑其过往的“传奇质量控制”的说法。

核心观点:

  • 质量下降: 微软近年来产品质量明显下降,频繁出现因配置错误导致的 Azure 服务中断、Windows 更新问题等。
  • 人员削减与流程转变: 2014 年,微软裁减了大量测试人员,并从传统的“瀑布模型”转向“敏捷开发”,这被认为是导致质量问题的关键因素之一。
  • Windows 10 更新事件: “Windows 10 October 2018 Update” 事件(也被称为 “Windows 10 更新的诅咒”)因删除用户文件而臭名昭著,虽然微软之后放缓了发布节奏,但质量问题依然频发。
  • Azure 服务中断: 即使 Azure 服务规模巨大,微软仍然反复出现因配置更改导致服务瘫痪的情况,这不仅反映了质量控制的失败,更引发了对其专业能力的质疑。
  • 用户反馈与现状: 文章引用了一些新闻报道,例如 Windows 10 仍然占据大量设备份额、用户对 Windows 功能的需求与微软提供的功能不匹配、以及 Windows 11 持续增加深色模式等,反映了用户对微软产品质量和功能的反馈。
  • “传奇”一词的质疑: 文章指出,与其继续使用“传奇质量控制”的说法,不如寻找更符合当前情况的描述,并邀请读者分享他们对微软产品质量的看法。

总结:

本文认为,微软在质量控制方面存在严重问题,其频繁出现的错误和中断服务,已经难以用“传奇”来形容。人员削减和流程变更可能是导致问题的重要原因。文章呼吁微软改进其质量控制流程,并听取用户反馈。

Bull markets make you feel smarter than you are

市场波动与投资者的心态:总结

本文探讨了市场波动对投资者心理的影响,并以历史案例警示投资者不要被市场成功蒙蔽。

核心观点:

  • 市场周期性: 市场会周期性地经历牛市和熊市。牛市容易让人产生“自己很聪明”的错觉,而熊市则容易让人感到“自己很愚蠢”。这是人类的普遍心理现象。
  • 本杰明·格雷厄姆的经验: 投资大师本杰明·格雷厄姆在20年代的牛市中取得了显著的成功,将40万美元的资金翻倍至250万美元。然而,他在大萧条时期未能预料到股市崩盘,多次试图抄底均以失败告终,甚至因此损失了个人大部分资金,资金缩水至375万美元。他曾经因早期成功而沾沾自喜,认为自己掌握了投资的秘诀,最终意识到自己中了“傲慢”的坏脾气。
  • 成功与失败的循环: 投资者的成功往往是导致失败的铺垫。 成功容易让人产生心理扭曲,认为自己是特殊的,可以不受规则约束。
  • 警惕过度自信: 许多投资者在当前的牛市中获得了巨额财富,这是一个值得庆祝的事情。 但要避免因成功而过度自信,市场不会永远上涨,赚钱也不会永远如此容易。 投资者终将再次感受到市场的“愚蠢”,即使这并非事实。
  • 借鉴经验: 推荐阅读布雷ндан·莫伊尼汉的《我从输掉一百万美元中学到的东西》,书中讲述了吉姆·保罗从白手起家到百万富翁再到破产的故事,强调了成功与失败之间的循环关系。

总结:

本文告诫投资者,在市场中要保持谦逊和谨慎,不要被短暂的成功所迷惑。 市场波动是常态,投资者应该做好应对熊市的准备,避免因过度自信而做出错误的投资决策。 历史案例和个人经历都证明,即使是最成功的投资者也可能在市场中犯错,重要的是从错误中吸取教训,并不断学习和改进。

The Linux Kernel Looks to “Bite the Bullet” in Enabling Microsoft C Extensions

Linux 内核即将启用 Microsoft C 扩展

本文报道了 Linux 内核构建系统(kbuild-next)中两个补丁的进展,这两个补丁旨在在 Linux 内核编译过程中启用 -fms-extensions 编译器选项。 这意味着 GCC 和 LLVM/Clang 将能够使用 Microsoft C 扩展。

主要内容:

  • -fms-extensions 选项的作用: 该选项允许编译器使用 Microsoft Visual C/C++ 编译器支持的非标准 C/C++ 构造,例如允许将带有标签的结构体或联合体匿名包含在另一个结构体/联合体中。
  • 历史背景: 过去曾有类似补丁被提出,但未能通过 Linux 内核邮件列表。
  • 当前进展: 这两个补丁已进入 kbuild-next,预计将在 Linux 6.19 内核合并窗口中提交。 Linus Torvalds 目前似乎对启用此选项持开放态度。
  • 优点:
    • 代码美观: Rasmus Villemoes 认为启用此选项可以产生“更漂亮的”代码。
    • 节省栈空间: 过去曾有人指出,启用此选项可能有助于节省栈空间。
    • 灵活性: 即使当前没有明显的用例,启用此选项也能在未来方便地利用 Microsoft C 的特性,而无需为每个用例单独启用。
  • 补丁细节:
    • 第一个补丁允许在内核代码中启用 -fms-extensions。
    • 第二个补丁确保 -fms-extensions 选项被传递给依赖于其自身的 CFLAGS 的 CPU 架构。
  • 潜在争议: 虽然大多数人都支持,但也有人认为在 Linux 内核中使用 Microsoft C 行为可能不太合适。

总而言之,启用 -fms-extensions 选项将为 Linux 内核开发带来一些潜在的好处,并可能简化代码,节省资源,并提高灵活性。 该补丁有望在 Linux 6.19 内核中被合并。

Bumble Berry Pi – A Cheap DIY Raspberry Pi Handheld Cyberdeck

蜂鸟树脂Pi (Bumble Berry Pi) 项目摘要 (Chinese)

本文档描述了一个名为“蜂鸟树脂Pi (Bumble Berry Pi)”的项目,该项目旨在构建一个廉价、易于组装的、基于树莓派的手持式网络设备 (Cyberdeck)。

主要特点:

  • 目标: 构建一个自给自足的、易于携带的树莓派手持设备,方便编写程序和运行脚本。
  • 关键特性:
    • 4.3英寸触摸屏显示器
    • QWERTY 迷你键盘
    • 37瓦时电池 (使用树莓派3b+时可提供全天续航)
    • 仅需3D打印两部分
    • 可以使用现有的树莓派型号
    • 组装快速简便 (不包括3D打印时间)
  • 成本: 大约60美元 (不包括树莓派、螺栓和凯夫拉胶带)。

硬件清单:

  • 树莓派 (推荐3b+,用于低成本和低功耗)
  • SD卡
  • 4.3英寸触摸屏显示器
  • 迷你蓝牙键盘
  • 37瓦时USB电源
  • USB-C转Micro-USB适配器
  • USB-C 90度适配器
  • M3x10mm Countersunk Head Bolt
  • M2.5x8mm Socket Head Bolt
  • M3 Threaded Inserts
  • 2" 凯夫拉胶带
  • 3D打印的部件: bumble-berry-pi-enclosure-A-v3.STL 和 bumble-berry-pi-enclosure-B-v3.STL (使用PLA打印)

工具需求:

  • 小十字螺丝刀
  • M2.5mm 六角扳手
  • 烙铁 (用于安装螺纹内螺纹)
  • 剪刀

组装步骤:

  1. 在正面外壳 (A部分) 中安装螺纹内螺纹。
  2. 使用螺丝将屏幕连接到A部分。
  3. 连接USB-C电源线和适配器。
  4. 将键盘固定在外壳中。
  5. 将电源组放置在外壳中。
  6. 将B部分外壳与A部分外壳连接。

设置步骤:

  1. 使用Raspberry Pi Imager将Raspberry Pi OS安装到SD卡。
  2. 将SD卡插入树莓派并启动。
  3. 将蓝牙键盘与树莓派配对。
  4. 连接到Wi-Fi网络。
  5. 在Raspberry Pi配置中设置启动到命令行。

设计说明:

作者使用Solidworks设计了3D打印部件,并表示如果需要,可以提供Solidworks文件。

该项目提供了一个详细的指南,用于构建一个紧凑且功能强大的树莓派手持设备,适合那些希望拥有一个便携式编程和脚本执行平台的人。

Zig and the design choices within

Zig 语言设计观点的探讨 (摘要)

本文作者(一位对编程语言设计有深入思考的人)对 Zig 语言的设计进行了评论,主要观点如下:

核心问题:缺乏内存安全

作者认为 Zig 最大的问题是缺乏内存安全机制。虽然 Zig 可以在运行时捕获部分问题,但相比现代安全语言(如 Rust),其努力程度不足。作者强调,现代编程语言应致力于约束用户,减少内存安全问题的发生,因为统计数据显示,高达 70% 的安全漏洞都源于内存安全问题。Zig 在 Rust、Node/v8 和 Deno 运行时崩溃和分段错误的统计数据上表现不佳,Bun 运行时更突出地体现了这个问题。

设计理念 (Philosophy)

作者对 Zig 的“禅宗”设计理念持有保留意见,认为其未能很好地体现。

实用性问题 (Practical)

  • Comptime: Zig 的 comptime 功能过于强大且复杂,导致泛型代码风格不统一,可读性降低。作者认为,更简洁的宏系统可能更合适。
  • 类型转换 (Casting): Zig 的类型转换语法较为繁琐,缺乏简洁性。
  • 结果位置语义 (Result Location Semantics - RLS): RLS 的某些选择存在反直觉之处,例如在结构体成员交换时,类型名称的不同会导致行为差异。
  • 指针引用优化 (Pointer Reference Optimization - PRO): 早期版本的 PRO 存在问题,已被移除。作者对此感到惋惜,认为 Zig 缺乏控制别名信息的能力,无法实现 PRO。

语义问题 (Semantics)

  • Result Location Semantics (RLS): 详细阐述了对 RLS 设计中一些反直觉选择的看法。
  • Pointer Reference Optimization: 讨论了 PRO 的移除及其对 Zig 的影响。

改进空间 (Misc. Improvable things)

  • 性能 (Speed): Zig 编译器速度较慢,尤其是在 LLVM 后端。作者希望未来能看到性能改进。
  • 工具链 (Tooling):
    • 构建系统: Zig 的构建系统文档不足,使用起来比较复杂。
    • 语言服务器: Zig 缺乏完善的语言服务器支持,影响开发体验。
    • 调试模式: Zig 无法检测某些内存安全问题,例如 use-after-realloc
  • 其他问题: 作者还指出了 Zig 在处理 undefined、tabs、迭代以及警告等方面存在改进空间。

社区问题 (My only note on the community)

作者对 Zig 社区的互动体验不佳,认为部分讨论缺乏建设性,倾向于否定其他语言的解决方案。

总结 (Summary)

作者认为 Zig 的设计理念存在缺陷,缺乏现代编程语言应有的内存安全保障。 虽然 Zig 旨在成为一种现代化的 C 语言替代品,但作者认为,在缺乏内存安全机制的情况下,其目标难以实现。

The Sega Master System

赛嘉Master System:世代分级、硬件对比与开发实践

本文概述了赛嘉Master System在游戏机世代划分、硬件特性、与其他同代机型对比以及开发实践方面的特点。

世代分级与Master System的定位

游戏机世代划分传统上根据发布年份和技术进步来划分,但实际情况颇为复杂。Master System的世代定位就体现了这一点。尽管SG-1000于1983年发布,并被认为是第三代游戏机,但其硬件与1982年发布的ColecoVision十分接近,后者被归为第二代。Master System于1985年发布,基于1985年的Mark III主机,在1983年Famicom(NES)技术基础上进行了改进。Master System与其他同代机型竞争,体现了其在世代划分中的实际意义。

硬件对比

Master System与SG-1000和Famicom(NES)在硬件上存在差异:

  • CPU内存: SG-1000和ColecoVision均为1KB,Famicom为2KB,Master System为8KB。Famicom后期通过Famicom Disk System(FDS)扩展至32KB。
  • 视频内存: SG-1000和ColecoVision均为16KB,Master System同样为16KB,并增加了一个32字节的调色板内存。Famicom只有2KB的普通视频内存,但通过将8KB的ROM映射为VRAM,有效空间提升至10KB。
  • ROM容量: SG-1000限制在32KB,Master System扩展至48KB,并通过银行切换机制支持高达512KB的ROM容量。Famicom也支持类似功能,但依赖于制造商定制的硬件。
  • 分辨率: SG-1000和Master System均为256x192,Famicom为256x240。
  • 色彩深度: SG-1000为1位/像素,Famicom为2位/像素,Master System为4位/像素,允许15种非透明颜色。
  • 精灵: SG-1000提供32个8x8或16x16单色精灵,Master System和Famicom提供64个精灵,可选择8x8或8x16尺寸。
  • 背景和滚动: SG-1000背景滚动功能有限,Master System支持32x28图形显示,允许任意方向滚动。Famicom支持双背景,但对斜向滚动有一定限制。
  • 寄存器访问: Master System和SG-1000通过控制端口和数据端口访问VRAM,而Famicom则将许多寄存器映射到CPU地址空间。

开发实践

作者成功地将SG-1000的BIOS支持库移植到Master System,仅需少量修改即可实现。Master System的硬件设计与SG-1000高度兼容,这使得移植工作相对容易。作者计划首先移植早期的Genesis项目,然后探索Master System的更多显示效果。

总结

Master System在技术上是SG-1000的升级,并与Famicom(NES)竞争。尽管硬件规格不如Famicom,但其设计理念更注重“开箱即用”的特性,编程体验更为流畅。通过充分利用硬件资源,可以开发出令人印象深刻的游戏。

Run Nix Based Environments in Kubernetes

Flox: 声明式环境,告别镜像构建

Flox 是一种旨在消除镜像构建和推送流程的工具,它允许开发者在本地开发、CI 和生产 Kubernetes 集群中使用相同的声明式环境。它基于 Nix 的理念,将容器镜像的快照替换为环境的配方,从而实现更快的部署、内置的安全性和原子回滚。

核心优势:

  • 无需注册表交互: Flox 在运行时从节点上拉取所需的哈希固定包,避免了多 GB 的镜像拉取。
  • 可预测的启动: 基于节点本地的、哈希寻址的缓存,实现快速且可预测的启动。
  • 可重现性: 在开发、CI 和生产集群中运行相同的加密哈希环境,消除漂移并支持原子回滚。
  • 内置安全: 缩小攻击面,默认提供 SBOM (软件物料清单) 和溯源信息。
  • 操作简易: 保留熟悉的原生 Kubernetes 组件,使用 Flox 维护的 containerd shim 和 RuntimeClass,将 Pod 运行在更贴近底层的环境中。

关键特性:

  • 支持 x86 和 ARM 架构: 在不同的硬件架构上使用相同的环境定义。
  • SBOMs-by-default: 自动生成 SBOM,方便漏洞管理和安全审计。
  • 原子回滚: 能够安全地回滚到之前的环境版本。
  • 无镜像重建: 避免了构建、推送和拉取镜像的循环。
  • 与现有工具兼容: 可以与 Argo、Helm、Tekton 和 GitHub Actions 等 CI/CD 工具集成。

工作原理:

  1. 定义和发布环境: 使用 Flox 定义环境,包含依赖项、变量、构建配方等。
  2. 在 Kubernetes 配置文件中引用: 在 Kubernetes 配置文件中引用 Flox 环境。
  3. 快速部署: 无需镜像,直接从节点本地缓存拉取所需的包。

适用场景:

  • AI/ML 团队: 定义哈希固定、声明式环境,实现零拷贝模型服务和热模型交换。
  • 数据科学: 支持 Jupyter-first 的数据科学工作流,在 Jupyter、批处理作业和模型服务之间共享环境。
  • 平台工程/SRE: 消除镜像重建和注册表拉取,实现更快的部署和原子回滚。
  • 安全工程: 缩小攻击面,默认提供 SBOM,支持原子回滚。
  • 软件工程: 在笔记本电脑、CI 和生产集群中使用相同的环境,实现快速迭代和本地测试。
  • 数据工程: 实现可重现的管道,支持 Spark、dbt 和 CLI 栈。

技术细节:

  • Flox 使用 CRI (容器运行时接口) 级别的 containerd shim。
  • 它将依赖项解析为哈希寻址的包,存储在不可变的节点本地存储中。
  • 组织可以运行自己的私有、签名二进制缓存,生成 SBOM 和证明,并指向安全扫描器。
  • 开发者可以在本地工作,直接访问所有资源,并使用 Git PR 更新代码和运行时环境。

总而言之,Flox 通过使用声明式环境代替容器镜像,显著简化了软件交付流程,提高了安全性和可重现性。

参考链接:

Head in the Zed Cloud

Zed Cloud 基础设施重建总结

本文档总结了 Zed 团队过去五个月对 Zed 的云基础设施进行重建的工作,新基础设施被命名为 Zed Cloud。

目标与技术选型:

Zed Cloud 的主要目标是减少维护托管服务的运营负担,以便团队能更专注于 Zed 本身的发展。 为了实现这一目标,Zed 团队选择了 Cloudflare Workers 作为基础设施平台,并使用 Rust 语言构建 Zed Cloud,最终编译成 WebAssembly (Wasm) 运行。

Cloudflare Workers 的优势:

  • 易于扩展: Cloudflare Workers 能够轻松扩展以满足需求。
  • 丰富的托管服务: Cloudflare 提供一系列托管服务,涵盖生产 Web 服务所需的各种功能,包括:
    • Hyperdrive (Postgres 数据库交互)
    • Workers KV (临时存储)
    • Cloudflare Queues (异步任务处理)

平台架构:

Zed Cloud 的核心是一个平台框架,构建在 Cloudflare Workers 运行时 API 之上。该框架定义了一个 Platform trait,允许以平台无关的方式编写代码,同时利用 Cloudflare Workers 的所有功能。

  • Platform Trait: 定义了平台相关的抽象类型,例如缓存、时钟、KV 存储、DurableObject 相关接口、速率限制器、SQL 存储等。
  • CloudflarePlatform: Platform trait 的一个具体实现,基于 Cloudflare Workers 运行时,用于生产环境和本地开发(使用 Wrangler)。它充当了 Workers JS 运行时绑定和 Rust 平台的桥梁。
  • SimulatedPlatform: 用于测试的平台实现,可以模拟系统中的各个部分,方便进行单元测试和集成测试。

测试框架:

Zed Cloud 采用了 SimulatedPlatform 进行测试,并使用内部的 scheduler 异步运行时,该运行时也用于 Zed 的 UI 框架 GPUI。 这种共享的调度器允许编写跨客户端和服务器的测试,可以模拟完整的端到端流程,例如接收和验证 webhook 事件,将事件放入队列,以及后端处理事件后对 Zed 状态的断言。

代码规模:

Zed Cloud 的代码库目前包含 70,000 行 Rust 代码和 5,700 行 TypeScript 代码。

未来展望:

Zed Cloud 的基础设施建设旨在为未来的协作编码功能,特别是与 DeltaDB 的集成,打下基础。 Zed 团队正在招聘后端工程师参与 Zed Cloud 的建设工作。