1. 我们应有权在自有硬件上运行任何代码；
2. 为何二战电报必须“严密转述”才能传达？；
3. 谷歌宣布：千元机安装应用需通过官方许可；
4. ADHD 管理策略与技巧；
5. 永恒之战；

以上是今天的前五条黑科技新闻标题。

总共25条，具体内容您往下读…

1. 我们应有权在自有硬件上运行任何代码

🔗 hugotunius.se: We should have the ability to run any code we want on hardware we own

文章讨论了围绕“侧载”的长期争议，核心论点是用户应能完全控制自有硬件。作者指出，Google和Apple等公司并非通过硬件，而是通过其操作系统进行限制。真正的关键并非批判现有系统的限制，而是应推动硬件制造商提供必要的技术文档与支持，使用户能够安装或开发替代操作系统，例如在iPhone上运行Android或在PS5上运行Linux，从而真正实现硬件所有权赋予的自由。

2. 为何二战电报必须“严密转述”才能传达？

🔗 history.stackexchange.com: “This telegram must be closely paraphrased before being communicated to anyone”

根据美国陆军1950年发布的《基础密码学技术手册》（TM 32-220），这一要求源于密码安全的核心原则：防止敌方通过对比相同明文与密文破解加密系统。手册明确规定，若信息需以加密和明文两种形式发送（例如一份加密后另一份公开），则明文版本必须进行“严密转述”——即彻底重写原文，最大限度改变措辞但保留原意。具体操作包括调整句子结构、替换同义词、删除冗余词汇，并避免直接重复专有名词或关键术语。

此举旨在消除密码分析中的“已知明文攻击”风险。二战期间，盟军曾利用德军在不同加密系统中重复发送相同内容的漏洞（例如恩尼格玛密码机），通过对比破解更复杂的密码。因此，“严密转述”不仅是措辞修改，更是一项关键的反情报措施，通过切断明文与密文的直接关联保护加密体系安全。

（注：该要求常见于美国军政高层通信，如罗斯福总统图书馆所藏1939-1941年电报。）

3. 谷歌宣布：千元机安装应用需通过官方许可

🔗 youtube.com: Google: ‘Your $1000 phone needs our permission to install apps now’ [video]

谷歌近期发布新规，要求所有运行Android系统的设备，包括千元机，在通过侧载等方式安装应用时，必须启用Google Play Protect的实时扫描功能以获取许可。此举旨在提升安全性，但引发了用户对隐私和谷歌控制力过强的担忧。该政策通过视频形式公布，强调了对用户安全的承诺。

4. ADHD 管理策略与技巧

🔗 borretti.me: Notes on Managing ADHD

本文核心观点是管理ADHD需采取化学优先原则，即药物治疗是基础，其他策略作为补充。文章强调内部改变（如药物、习惯）与外部改变（如待办清单、环境管理）需协同作用，如同交替上升的阶梯。作者将能量比作电压，建议将高耗能任务安排在精力充沛的早晨。文章还剖析了三种拖延类型，并为每种提供了应对思路，同时推荐使用待办清单作为认知辅助工具来增强记忆和习惯养成。

5. 永恒之战

🔗 yoavg.github.io: Eternal Struggle

本文探讨了在技术快速迭代的背景下，开发者与技术债务之间持续不断的斗争。文章强调了敏捷开发实践和持续重构对于维持项目长期健康的重要性，以避免系统最终陷入无法维护的境地。这是一场没有终点的战斗，但却是保证软件质量的关键。

6. 面向所有人的 Jujutsu 版本控制系统教程

🔗 jj-for-everyone.github.io: Jujutsu for everyone

这是一份专为初学者设计的 Jujutsu 版本控制系统教程，无需任何 Git 或其他版本控制系统的经验。教程采用分阶段学习法，分为六个等级，从最基本的个人使用到高级协作与问题解决技巧，旨在让用户逐步掌握技能。它强调与 Git 的完全兼容性，并承诺提供比 Git 更直观、更强大的用户体验。教程包含一个自动化脚本，可帮助用户随时重置学习进度至任一章节的初始状态。作者鼓励读者反馈以共同改进教程内容。

7. 为什么量子计算机还没能分解21？

🔗 algassert.com: Why haven’t quantum computers factored 21 yet?

尽管量子计算机早在2001年就成功分解了数字15，但直到2025年，分解21仍然是一个未实现的挑战。这并非因为量子计算技术停滞不前，其核心原因在于分解21的量子电路成本比分解15高出两个数量级。

具体而言，分解15的电路得益于三个关键优化：多数乘法运算乘以1（可跳过）、首个乘法近乎免费、剩余乘法可通过廉价的条件交换（CSWAP）实现。这使得其仅需21个纠缠门。

然而，分解21的电路则无此幸运。它必须为所有乘法付费，且乘法本身（如乘以4模21）需要昂贵的Toffoli门（总计2405个纠缠门），成本骤增约115倍。此外，若考虑量子纠错带来的额外开销，实际成本差距可能高达万倍。

因此，21尚未被分解的主因是算法层面的“硬件不友好”，而非硬件本身毫无进展。目前声称分解21的论文多被指使用了等同于预先知道因数的取巧优化，并非真正的量子分解演示。

8. FDA高官要求下架其本人质疑疫苗言论视频

🔗 theguardian.com: FDA official demands removal of YouTube videos of himself criticizing vaccines

一名FDA高级疫苗官员Vinay Prasad博士，要求YouTube删除其本人此前质疑新冠疫苗的言论视频。这些视频由一位批评特朗普政府公共卫生政策的医生Jonathan Howard收集并上传，旨在“保存”这些有影响力的医生在疫情期间的公开言论。YouTube以版权侵权为由删除了整个包含350个视频的频道。Howard指责Prasad此举是针对批评者而非反疫苗影响者的选择性打压。Prasad本人曾是疫苗政策的批评者，如今作为FDA生物制品评估与研究中心主任，其角色转变和过往言论引发了对其公信力的质疑。

9. 我没有 Spotify

🔗 idonthavespotify.sjdonado.com: I Don’t Have Spotify

该内容介绍了一项搜索服务，用户即使没有 Spotify 账户，也可以通过粘贴来自 Spotify、YouTube Music、Apple Music、Deezer 或 SoundCloud 的音乐链接来搜索和查找相应的歌曲。这为用户提供了一个便捷的途径来访问和探索音乐内容，而无需依赖特定的音乐流媒体平台订阅。

10. 大英帝国最后的日落时刻

🔗 oikofuge.com: When the sun will literally set on what’s left of the British Empire

本文探讨了英国海外领土如何确保其领土上总有阳光照耀。关键领土是皮特凯恩群岛和英属印度洋领地（BIOT），它们的地理位置使得太阳在英国本土落下时，仍能照亮这些地方。然而，英国政府计划将BIOT的主权移交给毛里求斯，此举将使BIOT不复存在。届时，位于塞浦路斯的英属主权基地区（SBAs）将成为最东端的英国领土。文章通过日照图表分析指出，若失去BIOT，在皮特凯恩日落之后，阳光将不再照耀任何英国领土，象征着“日不落帝国”时代的终结。移交过程还因美国军事基地的存在和特朗普政府的态度而变得复杂。

11. 使用单台大型服务器

🔗 specbranch.com: Use One Big Server (2022)

本文探讨了在“单体架构 vs. 微服务”的争论背后，真正的核心问题是分布式系统的开发和运维成本是否值得。作者指出，现代单台服务器的性能已极其强大，足以处理绝大多数应用的负载，例如每秒处理50万次nginx请求或承载1TB内存。与在云端租用大量小型虚拟机或采用无服务器计算（Serverless）相比，购买或租赁少量大型服务器通常成本效益更高，因为云服务存在显著的溢价（可能高达5-30倍）。

然而，单服务器架构的主要缺点是可用性风险。为此，建议采用主备服务器部署在不同数据中心，或采用2x2配置来规避单点故障。最终结论是，对于非突发性、稳定的工作负载，应优先选择少数大型服务器；而对于高度突发性的任务，云架构可能更合适。关键在于根据实际需求权衡，避免为不必要的“云原生”复杂度支付高昂费用。

12. F-Droid 网站 SSL 证书过期导致访问错误

🔗 gitlab.com: F-Droid site certificate expired

用户在使用 Edge 和 Chrome 浏览器访问 f-droid.org 时，出现 “您的连接不是私密连接” 的错误提示。该问题是由于网站的 SSL 证书 已过期所致。此外，内容中还提及了上传设计需启用 LFS 和管理员启用哈希存储的相关要求，但这与证书错误是分开的事项。

13. 调查：三分之一资深开发者过半代码由AI生成

🔗 fastly.com: Survey: a third of senior developers say over half their code is AI-generated

根据Fastly平台的一项调查，资深开发者（拥有十年以上经验）使用AI编程工具（如Copilot、Claude、Gemini）的比例远高于初级开发者。约三分之一资深开发者表示，其过半成品代码由AI生成，而初级开发者中这一比例仅为13%。专家分析，这并非因为资深开发者懈怠，而是因其工作重心已从单纯编码转向设计和原型验证，AI工具能助其快速实现想法并获得“多巴胺刺激”。此外，资深开发者更善于审查AI代码并发现缺陷，且更关注代码的环境影响。总体而言，超70%的开发者认为AI使工作更愉快。

14. 无点击，无内容：AI搜索的不可持续未来

🔗 bradt.ca: No clicks, no content: The unsustainable future of AI search

AI公司正导致内容枯竭，最终将使其自身陷入困境。AI搜索（如ChatGPT和Google的AI模式）直接提供答案，大幅减少用户点击访问源网站的流量，破坏了出版商和依赖内容营销的企业与搜索引擎之间长达25年的共生关系。这削弱了企业持续生产高质量内容的动力，而AI本身却依赖这些内容进行训练。长期来看，这将危及AI回答的质量和可靠性。尽管监管和诉讼被提出作为解决方案，但当前法律似乎站在AI公司一边。文章最终指出，这是一种不可持续的“淘金热”心态，整个模式可能面临经济泡沫破裂的风险。

15. 我们需要认真思考如何处理C++模块

🔗 nibblestew.blogspot.com: What to do with C++ modules?

本文作者认为，若C++模块无法在多个现有开源代码库中实现5倍（最好10倍）的编译速度提升，则应将其从标准中移除。作者指出，模块最初的核心目标是解决C++开发中最大的痛点——缓慢的编译速度，但近年来重点却转向了“构建隔离”（如防止宏泄漏等问题），而这些问题对大多数开发者而言并不常见。

模块的实施面临巨大挑战：编译器与构建系统需要紧密集成，但标准未涉及文件命名、组织等实际细节，导致各编译器团队各自为政。作者批评模块设计缺乏实践验证，是“史上最超前的宏大设计”，没有原型和测试便仓促标准化。理想的实施应通过迭代验证，而非直接投入生产。

目前import std（标准库模块化）被视为可行路径，但其性能提升可能与预编译头文件类似（约10-20%），远未达到预期。作者通过实验证明，自定义标准库可实现4倍编译加速，因此5倍是合理目标。

采用模块需付出代码重写、可移植性丧失、构建复杂度增加等代价，但普通开发者几乎无法获得实际收益。文章呼吁重新评估模块的价值，避免陷入沉没成本陷阱。

16. 刘易斯与克拉克的“泻药之路”

🔗 offbeatoregon.com: Lewis and Clark marked their trail with laxatives

刘易斯与克拉克探险队在远征途中，因长期食用低纤维的肉类而普遍饱受便秘困扰。他们大量使用了一种名为“雷声丸”的强效泻药，其核心成分是甘汞（氯化亚汞）。这种汞盐在人体内难以分解，会随排泄物进入土壤并稳定存在数百年。如今，考古学家通过探测古营地厕所土壤中异常高的汞含量，就能精确定位探险队的扎营地点，从而勾勒出他们的行进路线。这种由“英雄疗法”药物无意中留下的化学标记，成为了研究其历史足迹的关键线索。

17. Ultrassembler：极速RISC-V汇编器的实现奥秘

🔗 jghuff.com: How is Ultrassembler so fast?

本文深入探讨了Ultrassembler这一超高速RISC-V汇编器库的实现原理。它被设计为嵌入式系统中Chat项目的组件，旨在避免调用外部命令行工具带来的性能开销和复杂性。

其核心性能优势源于三大关键设计：首先，采用零开销异常处理机制，在正确无误的正常情况下无性能损耗，仅在出错时（由人为错误导致）才承担异常处理的成本。其次，使用高度优化的紧凑数据结构来存储指令和寄存器信息，完全避免字符串操作，并将所有指令数据压缩至约20KB，使其能完全载入CPU缓存。最后，通过预分配内存池技术，为所有容器提供自定义内存分配器，彻底避免了动态内存分配的系统调用和缓存污染。

最终，Ultrassembler的性能达到了惊人的水平，处理每条RISC-V指令仅需约1000条CPU指令，速度比GNU as快10倍，比llvm-mc快20倍。

18. 代码即债务

🔗 tornikeo.com: Code Is Debt

作者通过一个比喻阐述观点：两家营收和产品相似的公司，代码量更少（10万行）的一方更具优势，因其能更快理解和修改代码。由此提出核心概念——代码是一种债务。使用AI生成代码就如同借贷，其结果可能促进发展也可能导致项目崩溃。关键在于负责任地管理这种“债务”，并谨慎使用代码生成工具。

19. TPDE-LLVM：比标准编译器快10-20倍的全新后端（2020）

🔗 discourse.llvm.org: 10-20x Faster LLVM -O0 Back-End (2020)

开源项目 TPDE-LLVM 是一个极速的 LLVM 后端，其编译速度比标准的 LLVM -O0 后端快 10 到 20 倍，同时能保持相似的运行时性能，但代码体积会增大 10-30%。它支持 x86-64 和 AArch64 架构，并处理典型的 LLVM-IR 子集。项目通过简化的三遍式流程（IR 清理、分析及代码生成）实现高速编译。目前，其未来计划包括支持 DWARF 调试信息和改进寄存器分配。尽管不支持所有 IR 特性（如某些非法向量类型和多字整数），但它为需要快速编译的场景提供了一个极具吸引力的解决方案。

20. 百元打造家庭合法LTE网络

🔗 lantian.pub: Run a legal LTE network at home for $100

本文详细介绍了如何在美国通过CBRS频段（公民宽带无线电服务）以约100美元成本搭建合法的家庭LTE网络。核心步骤包括：购买二手支持CBRS的室内基站（如Sercomm SCE4255W），通过TR-069协议解锁基站管理界面；选购可编程SIM卡并配置网络信息；使用开源核心网络软件Magma构建认证和流量管理系统；最后将基站接入SAS（频谱接入系统）获得合法传输授权。整个过程无需申请昂贵频谱许可，但需确保设备符合FCC对CBRS频段的使用规定。

21. 在ARM单板计算机上安装UEFI固件的实践与挑战

🔗 interfacinglinux.com: Installing UEFI Firmware on ARM SBCs

本文详细介绍了作者在Radxa ROCK 5 ITX+ 单板计算机上安装基于EDK2的UEFI固件 的过程。由于该板的microSD卡槽设计在侧面，频繁更换操作系统极为不便，作者决定通过刷写SPI闪存来安装EDK2-RK3588固件，以实现从USB设备直接启动和安装通用ARM Linux镜像的目标。

整个过程包括：先使用Armbian系统启动设备，下载并刷写UEFI固件；随后进入UEFI设置界面调整启动参数（如ACPI/设备树模式）。作者测试了Fedora Rawhide和Ubuntu 25.10等最新Linux发行版，发现它们基本能运行，但存在显示、声音等驱动问题，且需要内核版本6.15+才能获得完整硬件加速支持。

最终，作者认为UEFI固件在RK3588平台上尚未完全成熟，但已接近可用状态，尤其适合无头服务器场景；而对于需要桌面环境的用户，仍需等待内核和驱动的进一步优化。

22. 软件有时就该“完工”：我为何放弃Hugo

🔗 commaok.xyz: Sometimes Software Is Done, or Why Hugo Why (2024)

作者最初喜爱Hugo的快速、简单和稳定，认为它已经“完工”。但持续更新导致软件变得臃肿复杂，频繁出现向后不兼容的破坏性变更。每次写博客前，作者都需耗费大量时间解决构建失败和版本升级问题，而非专注创作。最终决定放弃Hugo，并强调向后兼容性的重要性，认为软件发展到一定阶段应保持稳定。

23. 用数据库替代缓存服务：可行性与挑战

🔗 avi.im: Replacing a cache service with a database

本文探讨了是否能用数据库完全取代缓存服务。作者认为，虽然使用数据库的读副本可以模拟缓存的部分功能（如低延迟读取、弱一致性），并带来运维简化和避免缓存失效问题等好处，但目前两者因工作负载差异巨大而难以完全融合。缓存的核心优势在于：资源消耗少、能存储预计算数据（如复杂连接结果）、并提供精细的缓存驱逐策略（如TTL）。要缩小差距，未来数据库需支持部分数据同步、增量视图维护（IVM）等高级功能。然而，目前这仍是一个未实现的愿景。

24. 扎克伯格重金挖角AI人才，Meta内部却动荡不安

🔗 arstechnica.com: Zuckerberg’s AI hires disrupt Meta with swift exits and threats to leave

Meta首席执行官马克·扎克伯格为重金聘请的AI顶尖人才提供了九位数的签约奖金和巨大计算资源，以期在人工智能竞争中追赶对手。然而，新团队融入过程充满挑战，包括OpenAI联合创始人Shengjia Zhao在内的多名关键人物曾威胁离职或已迅速离职。公司内部经历了频繁重组，新成立的Meta超级智能实验室（MSL） 在六个月内已是第四次调整。新领导层与公司原有文化产生摩擦，部分员工对官僚作风和资源竞争感到失望。与此同时，一些资深老将也选择离开，公司现已暂停该实验室大部分岗位的招聘。

25. eBPF 内核编程入门指南

🔗 journal.hexmos.com: eBPF 101: Your First Step into Kernel Programming

eBPF 是一项革命性的 Linux 内核技术，它允许在受控的沙箱环境中安全地运行程序，从而无需修改内核源码即可扩展其功能。本文通过一个构建简易防火墙的实践案例，详细介绍了如何利用 eBPF 实现数据包计数和拦截特定 IP（如 8.8.8.8）的流量。开发过程涉及两个核心文件：用 C 语言编写的内核态程序（probe.c）负责处理数据包，而用 Python 编写的用户态脚本（runner.py）则用于加载、管理 eBPF 程序并监控其活动。eBPF 因其高性能和安全性，已被 Netflix、Cloudflare 等科技公司广泛应用于网络、可观测性和安全领域。