2026-09-01

20 篇热帖

1. Fastpotify (fastpotify.rocks)

Fastpotify 项目简介

Fastpotify 是一款适用于 Linux、macOS 和 Windows 的轻量级原生 Spotify 客户端,提供本地播放、媒体库访问以及 Spotify Connect 控制功能。

核心特性

  • 轻量与高性能:采用原生二进制文件构建,不依赖浏览器引擎。启动速度极快(不足 1 秒),内存占用通常维持在 100–250 MB 之间。
  • Spotify Connect 支持:支持本地无缝播放(音质最高可达 320 kbps),同时允许用户通过该客户端控制音箱、手机或电视等其他设备的播放状态。
  • 媒体库与搜索:用户可以浏览播放列表、喜欢的歌曲、专辑、艺术家和播客,并支持搜索音乐目录以及编辑个人播放列表。
  • 主题定制:提供亮色、暗色及跟随系统模式的多种主题。界面页面和播放栏的颜色可以根据当前专辑封面的色彩进行动态调整。
  • 桌面端控制:支持键盘快捷键;在 Linux 系统上支持 MPRIS 媒体控制;提供系统托盘选项,确保在关闭窗口后音乐仍能继续播放。
2. Google Has Removed MV2 Extensions from the Chrome Web Store, Including UBO (webiterate.dev)

Google 从 Chrome Web Store 下架所有 Manifest V2 扩展程序

Google 已完成浏览器扩展程序转型的最后阶段,正式从 Chrome Web Store 中移除了所有剩余的 Manifest V2 (MV2) 扩展程序。其中,备受推崇的内容拦截器 uBlock Origin 也包含在移除名单中。

核心影响

  • 更新与重新安装限制: 在 Chrome 138 或更早版本中已安装的 MV2 扩展程序仍可继续使用,但无法再接收任何更新。此外,一旦从商店移除,用户将无法再通过 Chrome Web Store 重新安装这些扩展。
  • 波及其他 Chromium 浏览器: 由于 Chrome Web Store 是包括 Brave 在内的众多 Chromium 内核浏览器的主要扩展获取渠道,此次移除的影响范围超出了 Google Chrome 本身。即使其他浏览器仍支持 MV2 标准,用户也无法再通过该商店发现或安装这些扩展。

Brave 浏览器的应对方案

为了保障用户体验,Brave 浏览器团队已决定通过其自有后端托管四款流行的 MV2 扩展程序,以便用户能够直接在浏览器中轻松启用,包括:

  • AdGuard
  • uBlock Origin
  • uMatrix
  • NoScript

Google 的转型理由

Google 表示,推动向 Manifest V3 (MV3) 平台迁移的主要目标是提升安全性、隐私保护和性能,并能实现对扩展程序权限更严格的控制,从而降低扩展程序访问用户浏览活动时可能带来的风险。

3. AnkiDroid: Google Play no longer allowing Open Collective donation link (github.com)

AnkiDroid 面临 Google Play 移除风险:关于 Open Collective 捐赠链接的政策争议

核心问题

开源闪卡应用 AnkiDroid 因其内置的 Open Collective 捐赠链接违反了 Google Play 的支付政策,目前面临被全球 Google Play 商店移除的风险。

争议焦点:免税身份认定

争议的核心在于 Google 对“免税组织”定义的理解与 AnkiDroid 财务托管方的法律地位之间的冲突:

  • Google 的政策要求:根据 Google Play 支付政策,应用可以引导用户通过非 Google Play 结算系统进行捐赠,但前提是捐赠对象必须是“经过验证的免税组织”(例如美国的 501(c)(3) 慈善机构)。
  • AnkiDroid 的情况:AnkiDroid 的捐赠通过其财务托管方 Open Source Collective 进行。该机构持有美国国税局(IRS)签发的 501(c)(6) 免税地位认定书。
  • 矛盾点:虽然 501(c)(6) 在法律上属于免税组织(尽管捐赠者不能获得税收抵免),但 Google 在审核了 AnkiDroid 提交的 IRS 认定书后,仍坚持认为该组织“不是免税组织”,并拒绝解释为何 501(c)(6) 状态不符合其政策要求。

时间线与后果

  • 风险期限:如果该问题在 2026 年 9 月 11 日 前未得到解决,AnkiDroid 将从全球 Google Play 商店下架(印度和俄罗斯地区除外)。
  • 当前状态:Google 已多次拒绝 AnkiDroid 的应用更新申请。
  • 应对措施:为了确保应用能继续通过 Play Store 分发给绝大多数用户,AnkiDroid 开发团队被迫在 2.24.X 版本中移除捐赠链接,并明确表示这是“在抗议下进行的被迫行为”。

开发团队诉求

  1. 寻求 Google 的澄清:明确 501(c)(6) 的认定是否符合 Google 政策中“免税捐赠”的标准。
  2. 呼吁扩散:请求读者转发此信息,特别是希望能够联系到 Google 相关决策人员的人士。
  3. 注意:开发团队明确要求读者不要直接联系 Google 客服,以免干扰现有的申诉流程。

关于 AnkiDroid

AnkiDroid 是一个由志愿者维护的开源 Android 闪卡应用,拥有超过 1000 万用户。该应用不售卖任何内容,Open Collective 是其维护和开发的唯一资金来源。

4. GPU World (www.gpuworld.org)

“GPU World” 故事征集活动概述

该内容旨在发起一场名为“GPU World”的故事征集活动,邀请参与者构思一个 AI 算力高度普及、分布均匀的未来世界。

核心背景:从“GPU 贫困”到算力普及

目前,由于计算能力的限制,顶尖的大语言模型(如 Fable 或 Sol)仅能服务于极少数用户,人类整体处于“GPU 贫困”状态。随着硬件制造和软件优化的提升,预计到 2040 年,全球算力可能实现质的飞跃,使每个地球人都能够拥有等同于当代“B300 GPU”性能的计算能力,并实现对前沿大模型的全天候访问。

探讨的主题与影响

活动鼓励参与者思考当 AI 成为像电力或互联网一样普遍的工具时,社会将发生怎样的变革,包括但不限于以下领域:

  • 教育: 是否会出现无限耐心且个性化的 AI 导师?
  • 医疗: 是否会带来世界级的 AI 医生和个性化药物?
  • 社会监控: 是否会演变成一个无孔不入的 AI 监控系统(全景监狱)?
  • 社交媒体: 现有的社交媒体形态是否会彻底消失?
  • 全球发展: 在长期被忽视的发展中国家,这种普及将带来怎样的改变?

设定前提(Premise)

为了让构思更具针对性,活动设定了一个特定的技术背景约束:

  1. 智能水平停滞: 假设 AI 的前沿智能水平在 2026 年 9 月 1 日停止飞跃。AI 不会进化为“超人类”智能,也不会发生“奇点”。
  2. 效率与成本优化: 虽然智能不再突破,但 AI 的运行速度会更快,成本会更低。
  3. 硬件持续扩张: 随着 GPU 制造技术的进步,到 2040 年,全球将拥有约 80 亿个等效 GPU,确保每个人都能获得前沿模型的服务。

参与者需要描绘的不是一个充满神迹的奇幻世界,而是一个 AI 技术已高度成熟、平民化且融入日常生活的“平凡”未来。

5. Restroom Archive (restroomarchive.com)

Restroom Archive 摘要

这份名为“Restroom Archive”(洗手间档案)的文档是一个按时间顺序排列的记录列表,记录了从 2023 年 3 月至 2026 年 9 月期间,在世界各地不同地点访问过的洗手间信息。

核心内容

每个条目通常包含以下三个关键信息:

  • 日期
  • 场所名称
  • 地理位置(城市、州或国家)

场所类型

记录中的场所类型极其多样,反映了广泛的活动轨迹,包括:

  • 文化与艺术机构: 如毕尔巴鄂古根海姆博物馆、大都会艺术博物馆修道院分馆、佩斯画廊等。
  • 餐饮场所: 大量记录涉及餐厅、咖啡馆、披萨店、酒吧及小吃店(例如 Lucali, Cafe Mogador, Paulie Gee's Slice Shop 等)。
  • 交通枢纽: 包括巴黎戴高乐机场、特里城市区域机场等。
  • 零售与商业场所: 如古董店、电子市场、超市、精品店及书店。
  • 公共与自然空间: 包括国家公园(如黄石国家公园)、公园、博物馆及自动公共厕所。
  • 其他: 涵盖了夜总会、船舶及各类各类服务设施。

地理分布

记录显示了跨国界的足迹,主要分布在:

  • 美国: 记录密度最高的区域包括纽约州(尤其是布鲁克林和曼哈顿)、犹他州(盐湖城、普罗沃等)、加利福尼亚州、科罗拉多州、内华达州、爱达荷州、怀俄明州、田纳西州和亚利桑那州。
  • 国际地区: 包括西班牙(毕尔巴鄂)、中国(上海)、法国(巴黎)和德国(施魏希)。
6. A walkable ASCII cyberpunk city in one HTML file [video] (www.youtube.com)

内容摘要

该内容由一个视频标题及一段 YouTube 平台的标准页脚信息组成:

  • 视频主题:标题为“A walkable ASCII cyberpunk city in one HTML file [video]”,表明该视频展示了一个使用 ASCII 字符构建的、可在单个 HTML 文件中运行的、具有可步行体验的赛博朋克风格城市。
  • 正文内容:提供的正文部分不包含视频的具体技术细节或描述,而是包含了 YouTube 平台的常规导航链接与法律声明,主要包括:
    • 平台功能与信息:关于 YouTube、新闻稿、联系方式、创作者中心、广告投放、开发者平台以及如何使用 YouTube 的说明。
    • 法律与政策:版权信息、服务条款、隐私权政策以及政策与安全说明。
    • 其他链接:测试新功能以及 NFL Sunday Ticket 的相关链接。
    • 版权所有:© 2026 Google LLC。
7. 44% on ARC-AGI-1 in 67 cents (mvakde.github.io)

摘要:实现 44% ARC-AGI-1 准确率的轻量化 Transformer 研究

该研究展示了一种高度样本高效的轻量化 Transformer 模型,能够在单张 NVIDIA 5090 GPU 上通过 1.5 小时的训练,以仅 67 美分(涵盖训练与推理总成本)的代价,在 ARC-AGI-1 测试集上达到 44% 的准确率,并在 ARC-2 上达到 7%。其性能优于许多大型语言模型(LLM),并与 TRM/HRM 等模型表现相当。

核心方法论

该方法的核心在于测试时训练(Test-Time Training, TTT)。具体实现如下:

  • 序列化表示:将每个输入-输出对转换为 token 序列,并在测试时针对每个谜题从头开始在训练集和评估集(隐藏标签)上进行自回归训练。
  • 特征表示:为了实现跨任务学习,每个谜题被赋予一个独立的学习加性嵌入(additive embedding);位置信息则通过 3D RoPE(旋转位置嵌入)进行编码。
  • 数据增强:在推理过程中对测试输入进行颜色和二面角(dihedral)置换,并在输出时应用逆变换,取最常见的两种输出结果。
  • 监督学习转向:与之前的非监督风格不同,新模型仅针对输出 token 计算损失函数(监督学习模式),这使准确率从 40% 提升至 44%。

技术升级与性能优化

相比前作,该模型在架构和效率上进行了显著改进:

  • 架构优化:采用了更现代的设计,包括 SwiGLU 激活函数、RMSNorm 以及将层数从 4 层增加到 8 层。
  • 优化器与调度:使用 NorMuon 优化器代替 AdamW,并采用 WSD(Warmup-Stable-Decay) 学习率调度方案。
  • 计算效率:引入了 Flash Attention(支持变长训练)和 Flex Attention 核函数,并减少了数据增强的使用,从而提高了样本效率。
  • 数据扩充:小心地引入了 ARC-2 中的非重叠任务作为训练数据,并严格防止了数据泄漏。

消融实验结论

实验证明,良好的表示能力是模型成功的关键:

  • 关键组件:3D RoPE 和每任务嵌入(per-task embedding)对性能至关重要。若移除其中任何一项,准确率会从 44% 骤降至约 25%。
  • 对比实验:相比于单独在每个任务上进行无监督训练(CompressARC 风格,准确率约 18%),当前的混合表示法表现显著更好。

对研究争议与现状的讨论

  • 关于“作弊”的澄清:作者反驳了“在评估集上训练属于作弊”的观点。由于 ARC 是一个元学习(Meta-learning)基准,测试时利用评估集的输入进行转导推理(Transductive reasoning)是符合逻辑且被鼓励的,模型从未接触过测试集的隐藏标签。
  • 对 LLM 的观察:作者认为 LLM 在 ARC 上的进步主要受合成数据和后训练(Post-training)驱动,而非真正的通用抽象推理或样本效率的提升。ARC-2 的表现进一步证明,即便经过强力的后训练,模型在面对新分布任务时依然缺乏泛化能力。
  • 未来方向:作者认为通过改进位置编码(如使用 PoPE)和进一步现代化架构,在该 Transformer 框架内达到 65% 的准确率是可行的。同时,通过手工编写 GPU 代码,计算成本仍有 10 倍左右的下降空间。
8. RavynOS: Pre-alpha open-source OS based on Darwin, FreeBSD, Apple open-source (ravynos.com)

RavynOS 项目概述

RavynOS 是一款处于 Pre-alpha(预发布) 阶段的开源操作系统。

技术基础与目标

该项目基于 Darwin、FreeBSD 以及 Apple 开源代码 构建,旨在实现以下核心目标:

  • 应用兼容性:力求兼容 macOS 应用程序。
  • 打破硬件限制:消除 macOS 生态中存在的硬件封闭性,提供更广泛的硬件支持。
  • 结合优势:试图将 macOS 的精致用户体验与开源软件的自由度相结合。

当前状态

目前,RavynOS 处于开发者预览阶段,主要面向系统构建者。由于系统尚处于早期开发阶段,目前仍不完善、不完整,暂不适合普通终端用户使用。

9. Run macOS Software on Linux (www.darlinghq.org)

Darling 项目概述

Darling 是一个允许在 Linux 系统上运行 macOS 软件的转换层(Translation Layer)。其工作原理类似于 Linux 上运行 Windows 软件的 Wine,但目标针对的是 macOS 生态。

核心特性

  • 高性能:Darling 直接运行 macOS 软件,无需通过硬件模拟器,从而保证了运行速度。
  • 开源免费:项目在 GitHub 上开源,遵循 GNU GPL v3 协议。
  • 高度兼容:它实现了完整的 Darwin 环境,包括 Mach、dyld 和 launchd 等核心组件。
  • 原生体验:旨在将 macOS 应用与 Linux 桌面进行深度集成,使其在外观、感觉和行为上趋近于原生 Linux 应用。
  • GUI 支持:目前已实现对简单图形化应用程序的基础性实验性支持。

技术细节与实现

  • 技术基础:Darling 主要基于 Apple 公开的 Darwin 开源源代码进行开发。在实现 Cocoa 框架时,使用了 The Cocotron 作为基础,并结合了 Apportable Foundation 和 GNUstep 等项目。
  • 法律合规性:Darling 仅使用 Apple 发布的完全自由软件部分的 Darwin 组件,因此不违反 Apple 的 EULA(最终用户许可协议)。
  • 平台支持:除了原生 Linux,用户还可以通过 Windows 的 WSL 2 环境运行 Darling。
  • 名称含义:名称“Darling”是 “Darwin”(macOS/iOS 的核心操作系统)与 “Linux” 的组合。

未来规划与贡献

  • iOS 支持:项目的长期目标是在 ARM 设备(如 Android 手机)上运行 iOS 应用。实现这一目标的关键挑战在于需要编写自己的 UIKit 实现。
  • 参与方式:开发者可以通过阅读官方文档和博客了解 Darling 的内部原理,并在 GitHub 上通过提交代码进行贡献。项目欢迎具有 macOS 或 iOS 开发经验的人士,但也接受其他背景的开发者。
10. I turned my security cameras into an automatic bird identification system (jasontucker.blog)

将安防摄像头转换为自动鸟类识别系统

本文介绍了一种利用 BirdNet-Go 软件将现有的安防摄像头转化为 24/7 全天候自动野生动物(主要是鸟类)识别系统的实现方案。

核心技术与功能

  • 实时音频检测:系统能够持续监听环境音,实时分析并识别鸟类、蝙蝠及青蛙的鸣叫声,无需人工干预或手动录制。
  • 本地 AI 推理引擎:整个系统通过 Docker 部署在本地硬件(如服务器或树莓派)上。由于采用本地 AI 模型(如可识别 14,795 个物种的 Google Perch v2),该方案具备高速度、高隐私性,且无需支付云端 API 费用。
  • RTSP 流支持:系统利用现有 IP 摄像头的 RTSP 流获取音频,无需购买专门的麦克风硬件,实现了安防设备的“一物多用”。
  • 物种多样性追踪:系统具备物种新颖性追踪功能,能够记录并标记新出现的物种,帮助用户观察庭院生物多样性的变化。
  • 音频可视化分析:提供实时音频通道能量水平分析,用户可以通过视觉反馈优化摄像头位置,或排除风噪、空调噪音等干扰。

集成与生态系统

  • 智能家居集成:支持通过 MQTT 协议接入 Home Assistant,实现数据的可视化展示与自动化联动。
  • 自定义警报规则:用户可以针对特定物种设置触发规则,并通过 Discord 等平台接收即时通知。
  • 数据共享:支持与 BirdWeather 社区平台集成,方便用户将观测数据贡献给全球科研人员和鸟类爱好者。
  • 丰富的展示方案:
    • 移动端:可通过 iOS 应用 "BirdNet-Go Companion" 在手机上查看检测详情。
    • 美化界面:可以使用名为 Saezuri 的自托管前端,将检测到的物种以美观的木块拼贴风格进行视觉化呈现。

总结

该方案通过将开源 AI 技术与现有安防基础设施相结合,构建了一个完全自主掌控(Self-hosted)、无云端依赖的自然观测系统。在实际应用中,该系统展现了极高的实用价值,能够在保护隐私的同时,为用户提供详尽的生态数据记录。

11. Tmp.0ut Volume 5 (tmpout.sh)

《Tmp.0ut Volume 5》内容摘要

《Tmp.0ut Volume 5》是一份技术文献集(发布日期为 2026 年 8 月 23 日),其内容主要围绕 Linux 底层系统安全、二进制逆向工程、内核机制以及 ELF 文件格式的深度操纵展开。

该卷包含 21 个章节,其核心技术主题可归纳为以下几个方面:

1. ELF 文件结构与高级操纵

大量内容专注于 x86-64 Linux ELF 文件的极端情况与变形技术:

  • 极小规模与变形: 研究 57 字节的极小 ELF 文件,以及 440 字节的变形(Metamorphic)ELF-64 病毒。
  • 文件加载与恢复: 探讨在 ELF 头部丢失的情况下如何加载文件(halfshelf 技术),以及如何将分块后的内容重新打包回单个 ELF 文件(phork 工具)。
  • 多语言与反取证: 研究用于趣味性及反取证目的的多语言(Polyglot)ELF 文件。
  • 加载器开发: 介绍了名为 halfexec 的 Assembly x64 ELF Linux 加载器。

2. Linux 内核与系统安全

研究深入到操作系统内核层面及其防御机制:

  • 内核机制: 深入探讨 Linux 内核如何加载可执行文件,以及静态内核补丁(Static Kernel Patching)技术。
  • 防御与检测: 包括针对 x86_64 Linux 的细粒度加载时 ASLR(地址空间布局随机化)技术,以及利用侧信道(Side-channels)检测系统调用(Syscall)钩子的方法。

3. 恶意软件与代码执行技术

涵盖了多种复杂的执行与隐藏手段:

  • 病毒研究: 涉及 RDOFF 病毒及变形病毒的研究。
  • 执行控制: 讨论了代码虚拟化(Code Virtualization)的概述、利用可达性(Reachability)进行自我提取的技术,以及将 Brainfuck 作为 ROP(面向返回编程)编译器的奇特应用。
  • 控制流: 研究“无状态”下的控制流实现。

4. 其他技术主题

此外,文档还包含了对 Doug McIlroy 的访谈、关于 Perl 语言的内容、BGGP6 回顾以及一份技术“混音带”(Mixtape)。

12. Konrad Zuse Museum shutting down due to lack of funding (www.heise.de)

资金短缺导致康拉德·楚泽计算机博物馆 (ZCOM) 面临关闭风险

位于 Hoyerswerda 的 Zuse 计算机博物馆 (ZCOM) 可能于今年年底关闭。目前,该博物馆正面临严重的财务危机。

财务危机背景

ZCOM 的生存现状受到资金支持撤回的影响。原先提供场地的市政住房公司已停止了每年 11 万欧元的补贴。目前,Hoyerswerda 市议会已将“Konrad Zuse City”的财政支持问题列入议程。如果市议会决定撤回补贴,除非能找到新的资助方(即“白骑士”),否则 ZCOM 基金会将不得不停止运营。

此外,博物馆的游客数量也未达到预期目标。目前的年度付费游客约为 1 万人,而原计划的目标是每年 2 万至 2.5 万人。

博物馆概况与历史

ZCOM 的前身成立于 1995 年,当时是为了纪念康拉德·楚泽(Konrad Zuse)被授予 Hoyerswerda 市荣誉市民身份。该馆曾于 2013 年关闭,并在 2017 年在市政住房公司的支持下,于更宽敞的场地重新开放。

主要展品与内容

博物馆展示了丰富的计算机技术历史,包括:

  • Zuse 系列计算机:包括 Z11、Z22、Z22r、Z23 和 Z25。
  • 东德(GDR)技术:展示了用于 Hoyerswerda 露天采矿业的 Robotron 计算技术展品。
  • 先驱人物:提供有关出生于卢萨蒂亚(Lusatia)的计算机先驱 Nikolaus Joachim Lehmann 的相关信息。
13. EFF to Courts: Don't Rewrite Copyright over AI Hype (www.eff.org)

摘要:EFF 呼吁法院勿因 AI 炒作而重写版权法

电子前哨基金会(EFF)近日向法院发出警告,呼吁法官在面对生成式人工智能(AI)引发的法律争议时,应保持警惕,避免因版权所有者的过度炒作而改写版权法。

历史教训与技术恐慌

EFF 指出,技术变革引发的“版权恐慌”并非首次。从 20 世纪 80 年代的录像带(VTR)到自动钢琴、留声机以及照相机,版权持有者都曾预言新技术将摧毁创意产业。然而,历史证明这些技术并未取代人类创作,反而催生了如新闻摄影等新领域。最高法院在处理 VTR 相关案例时曾明确指出,应当避免因新技术而重写版权法,因为新技术同样具备多种非侵权的用途。

“市场稀释”理论的法律风险

在当前的法律诉讼中,版权所有者提出了一种“市场稀释”(market dilution)理论。他们主张,由于生成式 AI 工具可能导致大量竞争性作品的涌现,因此开发这些工具本身不能被视为“合理使用”(fair use)。

EFF 认为这一理论背离了版权法的本质,并提出了以下反驳:

  • 混淆竞争与侵权:版权法的宪法宗旨是促进公众表达,而非通过限制竞争来锁定现有利益集团的利润。版权法旨在惩罚“侵权行为”,而非“市场竞争”。
  • 扼杀创作自由:若接受该理论,版权方将对艺术中的流派、风格和主题获得事实上的“否决权”,这将破坏“合理使用”原则,导致创作者无法在现有作品基础上进行自由构建,从而抑制未来的创新。

AI 的实际影响与功能

EFF 在论证中提出了两点关于 AI 现状的关键观察:

  1. 技术层面的低侵权性:相关研究表明,由于生成式 AI 模型依赖极其庞大的训练数据集,单个训练样本对特定输出的影响微乎其微,因此模型产生直接侵权作品的可能性较低。
  2. 作为增强工具而非替代品:AI 正在被广泛用于增强人类的创造力。EFF 列举了多位艺术家的案例,涵盖了非裔未来主义艺术、建筑设计、社会运动表达以及实验性音乐创作等领域,证明 AI 是艺术家探索新边界的工具。

结论

EFF 强调,生成式 AI 模型属于通用型工具,其用途远超单一领域。法院不应在技术影响尚未完全显现时,就预判性地判定这些工具是否促进“人类创造力”。面对技术带来的颠覆性变革,通过扭曲版权法来应对并非正确的路径。

14. Tim Cook Sold Out Steve Jobs (2025) (www.anildash.com)

文章摘要:Tim Cook 背叛了 Steve Jobs 的精神

本文是一篇评论文章,批评苹果公司现任 CEO Tim Cook 的领导风格背离了创始人 Steve Jobs 的核心价值观和企业精神。作者认为,苹果当前的政治姿态是对 Jobs 所代表的反建制、反权威精神的背叛。

核心观点

  1. Jobs 的精神遗产与背景: 作者强调 Steve Jobs 的成长背景(移民之子、60-70年代反文化运动的参与者)塑造了他蔑视权威、对抗“体制”的性格。苹果早期的品牌精神(如 Macintosh 的广告)本质上是反抗“老大哥”式监控和大型垄断机构(如 IBM)的。

  2. 对 Tim Cook 近期行为的批判: 作者严厉批评 Cook 最近在白宫向特朗普展示“金质奖杯”的行为。作者将其描述为一种极度卑躬屈膝、令人尴尬的“投诚”,认为这种通过讨好政治权力的行为完全违背了 Jobs 那种敢于对权力说“不”的特质。

  3. 反驳“被迫妥协论”: 针对“为了应对关税和政府合同压力,苹果不得不向政府低头”的观点,作者认为这是愚蠢的。他指出,即便苹果选择妥协,面临的经济压力(如关税)依然会存在,但这种做法会让苹果失去尊严,并向政府传达出可以进一步通过施压来索取利益的信号。

  4. 苹果应采取的替代策略: 作者认为苹果拥有巨大的技术和文化影响力,本可以采取更有力的立场:

    • 利用用户渠道:苹果可以利用其庞大的用户基础和通信渠道(如 iPhone 或 Wallet 消息推送),鼓励用户向民意代表表达对自由市场和法治的支持,而非进行政治献礼。
    • 理性的专业抗争:效仿 Jobs 过去处理技术争议(如对 Flash 的看法)的方式,通过逻辑严密、基于原则的公开声明来捍卫创新的自由环境。

结论

作者警告称,如果苹果继续走这种唯唯诺诺、通过政治投机来寻求生存的道路,将会失去员工的信任和消费者的忠诚,最终导致品牌走向平庸和无关紧要。他呼吁苹果找回 Jobs 式的勇气,在面临政治压力时站稳脚跟,捍卫其创新精神。

15. RotaryCell: Making an unmodified rotary phone work over LTE with an ESP32-S3 (github.com)

RotaryCell 项目概述

RotaryCell 是一个工程开发项目,旨在将传统的机械拨号电话转换为无需修改原机结构的、可携带的、由电池供电的 LTE 蜂窝电话。该设计能够保留原有的手柄、拨号盘、摘机开关、机械铃声装置及现有插孔,所有新增电子元件均可可逆地安装在电话壳体内。

系统架构与硬件组成

目前该项目处于工程存档阶段,包含已验证的手工布线原型以及正在验证的 PCB 版本。其核心硬件构成如下:

  • 主控制器与调制解调器:使用 LilyGO T-A7670G-S3 开发板,集成了 ESP32-S3 控制器、A7670 蜂窝调制解调器、电池充电管理及蜂窝音频接口。
  • 用户线路接口:采用 Silvertel AG1171 芯片,负责模拟电话线路电路、感应摘机开关状态并驱动机械铃声。
  • 音频与复位模块:Audio and Reset A4 PCB 提供可调节的收发音频调节功能,并具备硬件电源循环电路,用于在软件重置无效时进行硬件复位。
  • 电源管理:使用单个受保护的 21700 锂电池 直接为 AG1171 供电。原有的 RJ11 线路插孔被重新定义,仅用于输入受监管的 5V 电压进行充电,不再作为电话线路接口。

核心功能

RotaryCell 目前已实现以下功能:

  • 通话控制:支持拨号脉冲拨号、摘机检测、进出蜂窝通话以及物理铃声响铃。
  • 音频与音调:支持双向手柄音频(音量可调),并能发出北美标准的拨号音、重拨音及摘机警告音。
  • 监控与诊断:具备电池电量监控、USB 诊断功能、基于 Web 的维护 Wi-Fi 面板、浏览器/USB AT 指令终端以及事件日志。
  • 系统维护:支持通过蜂窝网络进行时钟同步及应用程序的 OTA(空中下载)更新。

重要注意事项与状态

  • 开发阶段:本项目是一个工程存档,并非最终的成品或消费级产品。部分 PCB 文件(2026 年 8 月版本)尚未经过生产测试。
  • 安全警告:
    • 严禁将原型机的 Tip/Ring 接线或改装后的充电插孔连接到公共电话网络或带电的住宅电话线路。
    • 锂离子电池的使用必须严格遵守保护、充电、熔断和绝缘的安全规范。
    • 维护 Wi-Fi 的默认密码为 rotarycell,使用时应及时更改。
  • 仓库结构:代码库按功能划分为固件(current/prebuilt/archive)、硬件(音频复位/AG1171/原型/实验/旧版)、文档及网站草稿等目录。

许可协议

本项目代码及原始文档基于 MIT License 开源。

16. 2004 RuneScape fit a multiplayer RPG into 56k dial-up (jkm.dev)

2004年 RuneScape 如何在 56k 拨号网络下实现多人在线 RPG

本文通过分析 2004 年《RuneScape 2》的解密客户端代码,揭示了该游戏如何在极低带宽(约 5 KB/s)和受限的 Java Applet 环境下,实现流畅的多人交互。其核心逻辑在于通过极致的字节优化,将客户端与服务器视为一个“共享知识”的统一系统。

核心约束

  • 带宽限制:用户多使用 56k 拨号上网,上传速度更低。
  • 技术环境:运行在浏览器中的 Java Applet 只能通过单一 TCP 连接通信,无法使用 UDP。
  • 服务器周期:服务器以约 600 毫秒(Tick)为周期进行逻辑处理。

加密机制

为了防止第三方解析数据包,游戏使用了一种名为 ISAAC 的流加密算法。为了节省资源,它仅加密“操作码”(Opcode),即告知如何读取后续数据包的那个字节。一旦操作码被解密,后续的包体便以明文传输。这种方式以极低的成本实现了基础的安全防御。

数据传输优化实例

1. 从客户端发送移动请求(Walk Request)

当玩家点击地图时,客户端在本地完成路径规划,并发送包含以下内容的包:

  • 操作码与长度:标识包类型及后续数据长度。
  • 路径优化:仅发送路径的拐点而非每一个方格。
  • 坐标优化:首先发送第一个路点的绝对坐标(2字节),后续路点仅发送相对于首个路点的增量(Delta)(1字节),这比发送绝对坐标节省了 50% 的空间。
  • 状态位:通过 1 字节记录是否按下了 Ctrl 键。
  • 结果:单步移动的请求包仅需 7 字节。

2. 从服务器发送玩家更新(Player Updates)

服务器每 600ms 向客户端发送一个复合包,用于同步视野内所有玩家的状态。该过程分为四个阶段,采用了**位打包(Bit-packing)**技术:

  • 第一阶段:本地玩家 如果玩家没有移动或状态变化,仅需发送 1 个比特(bit)。即使发生移动,通过位打包(如方向、移动类型等),仅需不到 1 字节即可完成。
  • 第二阶段:已知玩家 服务器为每个已在视野内的玩家分配 1 个比特来表示其是否有状态变化。若一群玩家都处于静止状态,仅需极少的字节即可确认整个场景是静止的。
  • 第三阶段:新进入视野的玩家 使用 11 比特玩家 ID 和相对坐标。由于玩家间距离较近,使用 5 比特(范围 -16 到 +15)来表示相对位置,远比 16 比特的绝对坐标更高效。
  • 第四阶段:详细状态更新(字节对齐) 处理动画、装备、聊天等复杂信息。此阶段放弃位打包,转而使用字节对齐。这是因为这些信息本身较大,位打包带来的字节节省微乎其微,反而会增加 CPU 的处理负担。

总结:设计哲学

RuneScape 协议的高效并非仅仅依靠压缩,而是源于客户端与服务器之间高度的“共享知识”:

  1. 共享地图:双方运行相同的路径算法,客户端只需发送拐点,服务器即可验证。
  2. 共享默认值:双方约定“无变化”即为默认状态,因此“无变化”的成本仅为 1 比特。
  3. 共享空间尺度:双方约定视野范围内的坐标空间,从而使用极短的位长表示位置。

这种设计将网络视为单一应用程序的实现细节,而非两个独立系统的边界。虽然现代 Web 开发倾向于使用 JSON 等自描述、解耦的格式以换取开发速度,但 RuneScape 的设计展示了在极端资源限制下,通过紧密耦合的协议实现高性能通信的工程极限。

17. Evidence of Fraud in an Influential Study About Procrastination (datacolada.org)

关于拖延症影响力研究存在造假证据的分析报告

背景概述

2002年,Ariely与Wertenbroch在《心理科学》(Psychological Science)上发表了一篇关于“拖延、截止日期与表现”的影响力论文。该研究指出,相比于自主设定截止日期或单一的最后期限,设置均匀分布的外部截止日期能显著提升任务表现。该研究被广泛引用(Google Scholar引用量超过2100次),并成为经济学和心理学课程的必读文献。

然而,近期Hyndman与Bisin进行的重复实验未能复制该研究的“实验2”结果。随后,研究团队对原始数据文件进行了深度分析,发现该研究的实验数据存在严重篡改或造假的嫌疑。

数据造假的四大疑点(Red Flags)

分析人员通过对比原始数据与重复实验数据,发现了四个极不寻常的异常现象:

1. 效应值(Effect Size)异常巨大

原始研究报告的效应值极其夸张。例如,在校对任务中,均匀截止日期组的平均纠错数为136.1,而最后期限组仅为71.1。其Cohen’s $d$值高达2.5。在心理学研究中,如此巨大的效应值极罕见,甚至超过了性别对身高的影响($d \approx 1.8$)等显而易见的生物学差异。对于校对这种具有高噪声和高个体差异的任务,这种结果在现实中几乎是不可能发生的。

2. 存在重复的观测值

在“最后期限”实验条件下,20名参与者中有18名出现了“数据双胞胎”现象——即这些参与者在三项独立的校对任务中的纠错数量完全相同。此外,这些“双胞胎”的编号特征呈现规律性(如ID相差10位),这与真实随机采集的数据逻辑严重不符。

3. 缺乏应有的相关性

在正常的心理学数据中,相关的变量应表现出统计相关性。但在原始数据中:

  • 主观评价不相关:参与者对任务的“喜爱程度”与“趣味性”等五个维度的主观评价之间几乎没有任何正相关性,这与重复实验中表现出的高度相关($r$在0.63至0.92之间)形成鲜明对比。
  • 表现与时间不相关:参与者在不同任务间的表现、以及各任务间的用时估计,在原始数据中也均未表现出合理的统计相关性。

4. 自我报告数据未进行取整

在要求参与者估计任务用时(分钟)时,人类通常会倾向于给出整数(如20分钟而非17分钟)。在重复实验中,85%的参与者使用了取整数字;但在原始数据中,仅有11.7%的数字是整数,这更符合随机分配数字而非人类真实感知的特征。

相关方回应与现状

  • Klaus Wertenbroch(原作者之一):表示其从未接触过任何版本的原始数据,并指出虽然“预承诺”的需求在重复实验中得到了证实,但该研究特定的实验有效性并未得到复现。他已请求期刊撤回论文。
  • Dan Ariely(原作者之一):承认原始数据存在“严重异常”,并表示由于时间久远记忆不足,无法对数据问题做出定论,但承诺将配合期刊进行撤稿流程。
  • Hyndman与Bisin(重复实验作者):强调其独立重复实验基于新数据,结论是可靠的,并表示原始文件的完整性问题应由相关责任方处理。
  • 《心理科学》期刊:表示正在根据出版伦理委员会(COPE)的指南,对该论文的下一步处理措施进行评估。
18. The safest job from AI may be writing (muratbuffalo.blogspot.com)

为什么写作可能是受 AI 威胁最小的职业

本文探讨了为何在人工智能(AI)正迅速重塑编程领域并挑战程序员职业地位时,写作却表现出了惊人的韧性。作者认为,尽管 AI 在生成代码方面表现出色,但在创作具有深度和灵魂的散文方面仍面临巨大挑战。

其核心观点基于以下四个维度:

1. 散文能力的平台期 (The Plateau on Prose)

尽管 AI 实验室致力于提升文本创作能力,但文本模型在表达力、深度和真实性方面似乎已遭遇瓶颈。相比于图像、语音和视频模型通过增加参数和算力实现的飞速进步,文本模型在捕捉人类情感和深刻见解方面进步缓慢,容易产生机械化、陈词滥调且缺乏灵魂的“文字废料”。

2. 写作是“棘手问题” (Writing as a Wicked Problem)

在系统理论中,“棘手问题”是指缺乏明确定义、没有明确停止规则且没有客观正确解的问题。作者通过维度对比解释了 AI 的能力边界:

  • 确定性领域(数学、代码、法律、金融): 这些领域具有明确的规范、逻辑边界或自动化验证机制(如编译器、单元测试或监管框架)。AI 可以通过闭环反馈快速迭代并验证结果。
  • 写作领域: 写作处于光谱的极端,它没有预设的规范,也没有客观的真理或验证标准。写作成功的最终衡量标准是能否在人类读者心中产生共鸣,这种主观性使得 AI 难以取得实质性突破。

3. AI 难以解决的“心智理论”问题 (AI-complete Problem)

编程通常是与确定性编译器的单向交互,而写作是一个受“心智理论”(Theory of Mind)驱动的“双向思维”问题。

  • 写作需求: 优秀的写作需要作者实时模拟读者的心理状态,管理读者的认知负荷,并预测论点产生的效果。
  • AI 局限: LLM 仅仅是基于庞大数据集进行下一个词的统计概率优化,它们缺乏人类的生命经验,无法产生真正的共情,也无法建立起对特定读者的动态心理模型。

4. 比较优势与“昂贵信号” (Comparative Advantage & Costly Signals)

从经济学角度来看:

  • 比较优势: 即使 AI 在打字速度和内容生成量上具有绝对优势,人类的价值将转向 AI 无法胜任的领域——即处理“棘手问题”和进行创造性思考。
  • 昂贵信号: 在生物学和社会学中,“昂贵信号”(如孔雀的尾巴)因其生产成本高且难以伪造而具有价值。随着 AI 生成的平庸内容充斥网络,人类真实、独特且带有个人印记的声音将成为一种稀缺的“昂贵信号”,其经济价值将随之提升。

总结: 程序员必须不断调整工作流以应对 AI 带来的生产力变革,而优秀的作家无需改变其核心工作方式,因为他们一直都在应对沟通本质中的复杂性。在 AI 时代,人类真实的表达能力反而将成为一种核心竞争力。

19. AI Can Make You Suck Faster Too (www.hermit-tech.com)

AI 也会让你变得更差:效率提升背后的质量危机

本文探讨了生成式 AI(GenAI)在软件开发领域引发的误区,指出尽管 AI 承诺了 10 倍的开发速度提升,但它并未如预期般催生出更多革命性的科技公司,反而可能加速低质量产出的堆积。

核心观点总结

1. 效率与实际产出的错位

根据数学逻辑,如果 AI 真的解决了开发速度的瓶颈,那么在过去几年中,我们应该已经见证了更多类似 Airbnb、Stripe 或 Dropbox 规模的伟大公司诞生。然而,现实情况是,目前的 GenAI 浪潮更多地是在制造低质量的电子邮件、社交媒体垃圾信息以及退化的搜索引擎体验。

2. 对技术瓶颈的误解

文章指出,许多创业者和领导者陷入了一个认知盲区:认为 LLM(大语言模型)解决了产品交付的所有技术问题。

  • 代码编写并非核心: 编写代码行只是软件开发的一部分,真正的挑战在于架构设计、系统稳定性、安全防护以及应对复杂业务逻辑的能力。
  • “氛围编程”(Vibe Coding)的危险性: 许多非技术背景的创始人认为有了 AI 就不再需要 CTO,这种倾向被作者比作非专业人士尝试进行电气布线或外科手术——看似简单,实则极其危险。

3. 智力依赖与信息质量的退化

AI 的普及正在改变人类寻找答案的方式,但也带来了风险:

  • 权威性的丧失: AI 往往从非专家的观点(如 Reddit 讨论)中提取信息,而非来自权威、经过验证的专业渠道。这导致了“智力依赖”,人们不再进行批判性思考,而是盲目接受 AI 生成的可能存在幻觉(Hallucination)的内容。
  • 错误的代价: 在软件领域,由于缺乏专业知识而依赖 AI 导致的错误(如不安全的数据库设计)可能引发数据泄露、隐私丧失或巨大的经济损失。

4. 结论:AI 是能力的放大器

作者强调,AI 本质上是一个放大器。如果使用者本身具备深厚的专业知识,AI 可以成为强大的辅助工具;但如果使用者缺乏基础逻辑和专业技能,AI 只会让你以更快的速度、更高效地生产出“垃圾”和不安全的产品。

总结一句话:AI 会让你在搬运垃圾时变得更快,但它无法教会你如何建造坚固的建筑。

20. Develop Cross-Platform CLI and GUI Tools with Tcl/Tk (cgicoffee.com)

Tcl/Tk 技术概述:开发跨平台 CLI 与 GUI 工具

本文详细介绍了 Tcl(工具命令语言)及其图形用户界面工具包 Tk 的特性、架构、应用场景以及最新版本 Tcl 9.0 的改进。Tcl/Tk 是一种拥有近 40 年历史、高度稳定且广泛应用于工业级领域的开源技术栈。

1. 核心特性与设计哲学

Tcl/Tk 的核心定位是“架构粘合剂”(Architectural Glue),旨在连接高性能编译代码与灵活的用户逻辑层。

  • 跨平台性:支持 Windows、Linux、macOS 及 Android,能够提供接近原生的 GUI 体验。
  • 轻量级:其运行时环境占用空间极小(包含常见包约 100MB),且能生成紧凑的单文件应用。
  • 命令驱动架构:Tcl 采用“一切皆命令”的逻辑,每行代码的第一个单词始终是命令,后续为参数。
  • 同构性 (Homoiconicity):代码与数据在 Tcl 中都表现为字符串,这赋予了语言极高的灵活性,但也对开发者的语法控制能力提出了要求。
  • “一切皆字符串” (EiaS):虽然 Tcl 在内部使用高效的二进制、整数或列表格式存储数据(通过 Tcl_Obj 的双端口机制),但用户始终通过字符串进行交互。这种设计通过“闪烁”(Shimmering)机制在不同数据类型间进行转换。

2. 技术组件与数据结构

2.1 解释器与工具包

  • tclsh:纯命令行解释器,用于 CLI 工具和自动化脚本。
  • wish:集成了 Tk 工具包的解释器,用于开发 GUI 应用。
  • Tk:事件驱动的 GUI 工具包,通过“小部件”(Widgets)提供跨平台界面。

2.2 数据组织

  • 命名空间 (Namespaces):用于隔离变量和命令,防止全局作用域污染。
  • 字典 (Dictionaries):支持嵌套键值对,具备自动初始化(Auto-vivification)能力。
  • 数组 (Arrays):作为一种扁平的哈希表,提供比字典更严格的类型锁定,常用于管理状态。
  • TclOO:内置的对象导向编程扩展,基于命名空间和命令路由实现封装、继承和多态。

3. 高级并发模型

Tcl 提供了两种强大的并发处理机制:

  • 堆栈式协程 (Stackful Coroutines):不同于 Python 或 JS 的无栈协程,Tcl 的协程可以暂停整个调用栈。这使得开发者无需使用 async/await 关键字,即可在单线程内实现非阻塞的异步操作。
  • 线程模型 (Threading):采用“无共享”(Shared-Nothing)模型。每个线程拥有独立的解释器,避免了竞态条件(Race Conditions)。线程间通过消息传递(Message Passing)或线程共享变量(TSV)进行通信。

4. Tcl 9.0 的重大演进

Tcl 9.0 是一个里程碑式的版本,解决了长期的技术债务并引入了现代特性:

  • 完全 64 位支持:提升了处理大规模数据的能力。
  • ZipFS 虚拟文件系统:原生支持将 ZIP 文件挂载为文件系统,简化了单文件应用的构建。
  • 高 DPI 支持:显著改善了在 4K 等高分辨率屏幕上的 UI 缩放表现。
  • 严格的数据处理:引入编码配置文件(Encoding Profiles),对无效字节序列采取“严格”模式,确保数据的准确性与可靠性。

5. 应用场景与部署方式

5.1 应用领域

  • 工业与基础设施:广泛用于 Git 的 GUI 工具、FPGA 设计工具、网络设备(如 Cisco 路由器)以及航空航天领域。
  • 嵌入式与移动端:通过 Androwish 等项目在 Android 上运行 GUI。
  • Web 应用:利用 Wapp 框架可以构建轻量级、安全且单文件的 Web 服务。

5.2 部署方案

  • Zipkits:结合 Tcl 9 的 ZipFS 技术,可将解释器、脚本、库和资源打包成单个可执行文件。
  • 侧边栏模式 (Thin-Client UI):利用 Tcl/Tk 构建轻量级 UI 层,通过管道(Pipe)与高性能后端(如 C# 或 Python)进行异步通信,实现“UI 负责交互,后端负责计算”的高效架构。

6. 局限性与挑战

  • 语法复杂度:由于高度依赖大括号 {}、引号 "" 和方括号 [] 的嵌套,开发者需谨慎处理替换规则,以防安全漏洞(如命令注入)。
  • 内存管理:TclOO 对象不具备自动垃圾回收机制,开发者必须手动调用 destroy 来释放命令和命名空间。
  • 生态系统分散:缺乏像 npm 或 pip 这样中心化的包管理器,通常依赖于 Magicsplat 或 BAWT 等预集成的“全电池”(Batteries Included)发行版。
  • 性能差异:虽然在逻辑编排和 I/O 上表现卓越,但在纯数学计算(如矩阵运算)方面由于字符串处理的开销,效率远低于原生编译语言。