运维123 - 技术新闻
type: channel
link: https://www.sddts.cn/index.php/tag/%E6%8A%80%E6%9C%AF%E6%96%B0%E9%97%BB/
items: 比特币面临量子计算威胁分析
items: printervention：Web 技术让旧打印机复活
items: Google TurboQuant：通过更优数学而非更多内存解决 AI 内存瓶颈
items: 拉瓜迪亚机场严重事故：加航飞机与消防车相撞致两名飞行员死亡
items: Manyana：基于 CRDT 的版本控制系统展望
items: GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息
items: GitHub Actions 新增定时任务时区支持
items: 维基百科再度拉黑 Archive.today，删除 69.5 万条存档链接
items: 本田取消电动车项目及其未来竞争力危机
items: 每一层审查让你慢 10 倍

比特币面临量子计算威胁分析
type: item
date: 2026-04-17T05:23:24+00:00
description: 比特币面临量子计算威胁分析一、新闻概述1. 标题比特币与量子计算：密码学相关的量子计算机带来的生存威胁2. 发布时间2026 年 4 月 3 日3. 来源Neha Narula 的个人博客（MIT 数字货币倡议负责人）二、核心内容1. 事件摘要A. 主要内容Neha Narula 发表文章深入分析了加密相关量子计算机（CRQC）对比特币构成的生存威胁。文章指出，如果 CRQC 明天出现，比特币的签名机制将被彻底破解，需要进行代码升级和钱包迁移才能确保安全。B. 核心亮点比特币在 CRQC 面前存在生存威胁，需要升级到后量子密码学威胁概率 = CRQC 出现概率 × 比特币未能成功升级的概率Google 量子计算论文作者认为 2030 年前有 10% 的 CRQC 出现概率比特币升级面临技术和协调双重挑战2. 关键信息A. 技术背景比特币当前使用的 ECDSA 和 Schnorr 签名算法在量子计算面前脆弱需要通过软分叉引入后量子签名方案用户需要将币迁移到新类型的地址B. 时间线数据Google 计划在 2029 年迁移到后量子密码学Google 研究人员估计 2030 年前有 10% 的 CRQC 出现概率上一次比特币软分叉（Taproot）耗时 3 年 10 个月钱包和交易所支持新功能往往需要更长时间C. 风险评估示例如果 CRQC 出现概率为 10%（A=0.1），比特币未能成功升级概率为 50%（B=0.5），则 2030 年比特币因 CRQC 而失效的概率为 5%（0.1×0.5=0.05）3. 背景介绍A. 相关技术量子计算利用量子力学原理进行计算，Shor 算法可以在理论上高效分解大整数和求解离散对数问题，这正是当前公钥密码学的基础。B. 比特币现状比特币采用椭圆曲线数字签名算法（ECDSA）和 Schnorr 签名，这些算法在经典计算机下安全，但在量子计算机面前可被破解。三、详细报道1. 威胁分析A. 比特币的脆弱性比特币当前使用的签名机制依赖于公钥密码学的数学难题。量子计算机的 Shor 算法能够高效解决这些难题，使得签名算法变得不再安全。graph LR A[经典计算机] -->|ECDSA/Schnorr| B[安全] C[量子计算机 CRQC] -->|Shor算法| D[破解签名] D --> E[盗取比特币]B. 威胁概率模型文章提出了一个简洁的风险评估模型：存在性威胁概率 = A × B其中：A = CRQC 在特定时间点之前出现的概率B = 比特币在该时间点前未能成功升级的概率C. 实际数据支撑根据 Google 近期发布的量子计算论文和相关时间线：Google 计划在 2029 年迁移到后量子密码学标准论文作者之一 Craig Gidney 表示，他不会押注反对 2030 年前出现 CRQC 的可能性（暗示约 10% 的概率）比特币升级历史数据：Taproot 软分叉从提案到激活耗时 3 年 10 个月钱包和交易所支持往往滞后数月甚至数年2. 技术挑战A. 签名方案选择问题目前仍存在多个未解决的技术问题：哪个签名方案？后量子签名方案存在但会产生更大的签名验证时间更长选择不当可能导致节点运行成本增加可能限制比特币的交易吞吐量graph TD A[后量子签名方案] --> B{方案选择} B --> C[Lamport 签名] B --> D[基于哈希的签名] B --> E[基于格的签名] C --> F[签名大小增加] D --> F E --> F F --> G[区块空间压力增大] F --> H[验证时间延长] G --> I[节点成本上升] H --> IB. 共识机制设计问题未升级的 UTXO 如何处理？大量旧地址中的币可能永远不会移动包括中本聪的早期币设计不当可能违反比特币的核心原则可能损害比特币的主权和稀缺性叙事C. 升级路径和时间线具体步骤和时机不明确过早升级可能选择非最优的加密原语过晚升级可能导致比特币被破解或匆忙应对需要在技术成熟度和风险之间找到平衡D. 生态系统协调问题钱包和交易所升级比特币网络升级只是第一步整个生态系统需要同步升级钱包软件需要支持新的签名类型交易所需要集成新的地址格式用户需要实际将币迁移到新地址类型sequenceDiagram participant N as 比特币网络 participant W as 钱包开发者 participant E as 交易所 participant U as 用户 N->>N: 软分叉激活 PQ 签名 W->>W: 开发新钱包功能 E->>E: 集成新地址格式 W->>U: 发布新版本 E->>U: 支持新地址 U->>N: 迁移币到新地址3. 不同视角的分析A. 投资者视角价格影响CRQC 风险是比特币价值归零概率的下…

printervention：Web 技术让旧打印机复活
type: item
date: 2026-04-17T03:03:53+00:00
description: printervention：Web 技术让旧打印机复活一、新闻概述1. 标题printervention：Web 技术让旧打印机复活2. 发布时间2026 年 4 月3. 来源printervention.app 官方博客二、核心内容1. 事件摘要A. 主要内容开发者 George MacKerron 发布了一项创新技术项目 printervention，通过 WebUSB 和浏览器虚拟机技术，让已被现代操作系统淘汰的老式照片打印机重新焕发生机。B. 核心亮点无需安装，通过浏览器即可使用旧打印机完整模拟 Linux 打印环境，支持 CUPS 和 Gutenprint 驱动实现双向通信，可获取打印机状态支持 HEIC 格式照片自动转换跨平台兼容，可在任何支持 WebUSB 的浏览器中运行2. 关键信息A. 技术栈v86：x86 CPU 和整机模拟器WebUSB：浏览器 USB 设备访问 APIUSB/IP：Linux USB 设备网络转发协议tcpip.js：JavaScript TCP/IP 协议栈实现CUPS：通用 Unix 打印系统Gutenprint：高质量打印机驱动B. 应用场景Canon SELPHY 等老式照片打印机其他 Gutenprint 支持的打印机型号未来扩展支持扫描仪设备C. 创新价值环保：拯救数百万即将进入垃圾填埋场的旧打印机低成本：无需购买昂贵的替换设备便捷：无需安装驱动或专用软件3. 背景介绍A. 问题起源作者意外获得一台 Canon SELPHY 照片打印机，发现现代 macOS 和 Windows 已不再支持这些老设备。虽然 Linux 系统仍可通过 CUPS 和 Gutenprint 驱动使用，但非技术用户难以部署。B. 最初的解决方案作者使用 Manjaro Linux 机器配合 CUPS 和 Avahi，通过 AirPrint 共享打印机。但这需要额外的硬件和 Linux 技能，不适合普通用户。C. 演进方向探索纯软件解决方案，让任何人都能够通过浏览器使用旧打印机。三、详细报道1. 主要内容A. 技术演进项目经历了三个主要版本的迭代：第一代：自定义 CUPS 后端使用 shell script 接收打印数据通过 v86 TTY 逐字节传输到浏览器浏览器通过 WebUSB transferOut 发送数据问题：TTY 对控制字符的处理导致打印数据损坏第二代：9p 文件系统传输使用 v86 的 9p 文件系统传输大块数据效率更高，但存在同步问题教训：在 JavaScript 读取前必须先 sync 文件第三代：USB/IP 双向桥接Linux 端使用 USB/IP 协议JavaScript 端使用 tcpip.js 实现 TCP/IP 栈实现完整的双向通信B. 技术细节核心架构printervention 的技术架构包含三个核心层次：graph TB subgraph 浏览器层 A[用户界面] B[WebUSB API] C[tcpip.js] D[HEIC 转换] E[PDF 生成] end subgraph 虚拟机层 F[v86 x86 模拟器] G[Alpine Linux] H[CUPS 打印系统] I[Gutenprint 驱动] J[USB/IP 协议] end subgraph 硬件层 K[USB 打印机] end A -->|上传文件| D D --> E E --> F B <-->|USB 数据| C C <-->|以太网帧| F F --> J J <-->|TCP/IP| C J <-->|虚拟 USB| H H --> I H -->|打印命令| J B <-->|USB 连接| K工作流程sequenceDiagram participant U as 用户 participant B as 浏览器 participant V as v86 虚拟机 participant C as CUPS participant P as 打印机 U->>B: 上传照片 B->>B: HEIC 转 JPEG B->>B: 生成匹配尺寸 PDF B->>V: 上传文件到 VM V->>C: lp 打印命令 C->>C: Gutenprint 处理 C->>V: USB/IP 协议封装 V->>B: 以太网帧传输 B->>B: tcpip.js 解析 B->>P: WebUSB transferOut P->>B: 状态响应 B->>V: tcpip.js 封装 V->>C: USB/IP 解包 C->>U: 打印状态更新关键技术点v86 模拟器：在浏览器中完整模拟 x86 计算机，将机器代码编译为 WebAssembly 模块运行WebUSB API：允许网页直接连接 USB 设…

Google TurboQuant：通过更优数学而非更多内存解决 AI 内存瓶颈
type: item
date: 2026-03-31T06:12:46+00:00
description: Google TurboQuant：通过更优数学而非更多内存解决 AI 内存瓶颈一、新闻概述1. 标题Google TurboQuant：通过更优数学而非更多内存解决 AI 内存瓶颈2. 发布时间2026 年 3 月 29 日3. 来源adlrocha.substack.com二、核心内容1. 事件摘要A. 主要内容Google 发布 TurboQuant 算法，通过创新的向量压缩技术，实现了 KV Cache 6倍内存压缩，在保持精度的前提下将推理性能提升 8 倍。B. 核心亮点6倍 KV Cache 内存压缩，无精度损失H100 GPU 上 8倍性能提升无需训练或校准，可直接部署数据无关算法，基于信息论第一性原理2. 关键信息A. 版本号/发布内容TurboQuant 算法（论文：arxiv.org/abs/2504.19874）B. 重要数据3.5 bit 每通道，绝对质量中性6倍 KV Cache 内存减少8倍推理性能提升（H100 GPU，4-bit TurboQuant vs 32-bit）2.5 bit 压缩下精度仅轻微下降C. 涉及产品/技术Google TurboQuantPolarQuant（极坐标量化）QJL（量化 Johnson-Lindenstrauss 变换）Gemma、Mistral、Llama-3.1-8B-Instruct 模型3. 背景介绍A. 前置版本/历史上周作者撰文分析了 AI 内存问题的硬件侧：HBM 密度惩罚、EUV 瓶颈、DRAM 价格上涨压力。TurboQuant 从软件/算法角度解决同一问题。B. 相关上下文LLM 推理的核心瓶颈之一是 KV Cache 内存占用。随着上下文长度增加，KV Cache 可以超过模型权重本身的内存占用。三、详细报道1. 主要内容A. 功能更新TurboQuant 是一个两阶段算法：第一阶段：PolarQuant将向量从笛卡尔坐标转换为极坐标（半径 + 角度）高维 transformer 键空间中的角度分布高度集中且可预测无需数据特定调优或校准第二阶段：QJL（量化 Johnson-Lindenstrauss）对 PolarQuant 引入的误差进行校正应用 Johnson-Lindenstrauss 变换到残差将每个分量减少到单个符号位（+1 或 -1）零额外内存开销B. 技术改进无需校准数据集无需针对特定模型进行微调可直接应用于任何模型的向量达到信息论理论下界附近C. 政策变化开源代码已发布，QJL 和 PolarQuant 组件均可获取。2. 技术细节A. 架构变化Transformer 推理中的 KV Cache 问题：graph TB A[输入序列] --> B[Transformer 层] B --> C[计算 Q/K/V] C --> D[Attention 计算] D --> E[生成下一个 Token] C --> F[KV Cache 存储] F -->|缓存复用| D F -->|内存占用增长| G[问题：Cache 随序列增长] G --> H[长上下文内存瓶颈]B. 性能指标指标传统方法TurboQuant提升KV Cache 内存100%16.7%6倍压缩H100 推理性能基准8倍8倍提升位宽32-bit3.5-bit9倍压缩精度损失-无绝对中性C. 兼容性说明已在 Gemma、Mistral、Llama-3.1-8B-Instruct 上验证测试基准：LongBench、Needle In A Haystack、ZeroSCROLLS、RULER、L-Eval3. 数据与事实A. 性能对比向量搜索任务上：索引时间降至"接近零"超越乘积量化和 RabbiQGloVe 向量召回率基准测试表现优异B. 市场数据Google 公告后，内存制造商股价暴跌：Micron 股价下跌SanDisk 股价下跌C. 用户数据无需额外数据，算法完全数据无关。四、影响分析1. 行业影响A. 竞争格局任何依赖内存需求与 AI 上下文使用线性增长的论点都需要重新评估内存需求可能不再是 AI 推理的主要瓶颈边缘设备上的本地 LLM 推理变得更具经济性B. 技术趋势从"堆硬件"转向"优化算法"向量表示方法的改进可带来数量级的性能提升类似傅里叶变换对信号处理的影响2. 用户影响A. 现有用户可直接部署到现有模型，无需重新训练显著降低推理成本B. 潜在用户边缘设备推理：手机等设备可支持更长上下文向量数据库：RAG 管道受益于相同压缩技术C. 迁移成本极低，代码已开源，可直接应用。3. 技术趋势A. 技术方向各大 AI 实验室可能已在研究类似问题压缩算法将成为 AI 推理优化的重点方向B. 生态影响向量数据库、推荐引擎、欺诈检测、药物发现等领域可继承该技…

拉瓜迪亚机场严重事故：加航飞机与消防车相撞致两名飞行员死亡
type: item
date: 2026-03-24T00:15:03+00:00
description: 拉瓜迪亚机场严重事故：加航飞机与消防车相撞致两名飞行员死亡一、新闻概述1. 标题拉瓜迪亚机场严重事故：加航飞机与消防车相撞致两名飞行员死亡2. 发布时间2026 年 3 月 23 日3. 来源BBC News二、核心内容1. 事件摘要A. 主要内容美国纽约拉瓜迪亚机场发生严重事故，一架刚从蒙特利尔抵达的加航飞机与一辆正在响应其他紧急情况的消防车在跑道上相撞，造成两名飞行员死亡。B. 核心亮点两名飞行员在事故中不幸身亡41 人被送往医院，多人伤势严重机场连夜关闭，数百航班取消或延误美国国家运输安全委员会已介入调查2. 关键信息A. 航班信息航班号：Air Canada Flight 8646机型：CRJ 900（由 Jazz Aviation 运营）载客：72 名乘客和 4 名机组人员B. 重要数据死亡人数：2 人（飞行员）送医人数：41 人受影响航班：数百架次C. 涉及产品Air Canada Express（CRJ 900 飞机）Port Authority 消防车拉瓜迪亚机场跑道系统3. 背景介绍A. 机场背景拉瓜迪亚机场是纽约市三大主要机场之一，位于皇后区，主要处理国内航班。该机场以跑道较短而闻名，对飞行员操作要求较高。B. 相关上下文事故发生在机场运营繁忙时段，当时消防车正在响应一架美联航飞机报告的异味紧急情况。三、详细报道1. 主要内容A. 事故经过当地时间周日晚 23:40 左右（北京时间周一 03:40），加航 8646 航班刚刚从蒙特利尔降落。与此同时，纽约和新泽西港务局的一辆消防车正紧急响应一架美联航飞机报告的"异味问题"。两车在跑道发生碰撞。B. 伤亡情况根据港务局首席执行官 Kathryn Garcia 的通报：两名飞行员在事故中死亡41 人被送往医院救治32 人已出院，其他人伤势较重消防车内的警士和警官情况稳定，无生命危险C. 飞机损毁社交媒体上的视频显示，这架由 Jazz Aviation 运营的飞机机头上翘，损毁严重。目击者 Leo Medina 告诉 BBC："我们离现场只有大约 100 米远。飞机就像被切成两半一样。"2. 技术细节A. 事件时间线graph TD A[周日 23:40 加航8646航班降落] --> B[消防车响应美联航异味报告] B --> C[飞机与消防车相撞] C --> D[41人送医救治] C --> E[机场立即关闭] E --> F[整夜 旅客滞留] F --> G[周一 08:00 航班大面积取消] G --> H[周一 14:00 机场重新开放] H --> I[安检排长队]B. 空管录音在事故发生前的几秒钟，塔台工作人员可以听到有人大喊："Truck One，停下，停下，停下！"这表明空管人员可能已经发现危险。C. 跑道安全管理机场跑道安全涉及多个系统的协调：空管塔台负责指挥飞机起降地面运营部门协调车辆移动紧急响应车辆需要快速穿越跑道3. 数据与事实A. 机场影响所有进出港航班取消或延误至周一下午受影响航司：美航、达美、西南、美联航、加航B 航站楼（加航运营所在）周一上午所有离港航班除一架外全部取消B. 旅客影响大量旅客滞留在候机大厅有人睡在地板上或挤在长椅上旅客通过电话尝试重新安排行程许多旅客带着小孩C. 混乱加剧机场官员警告旅客应"预期会有持续的延误和取消"，并在出发前与航司确认。由于政府部分停摆导致 TSA（运输安全管理局）人手不足，进一步加剧了混乱。四、影响分析1. 行业影响A. 机场安全管理这起事故引发了对机场跑道安全管理系统的质疑。紧急车辆与飞机在跑道上的协调机制将成为调查重点。B. 空管程序空管塔台与地面车辆的沟通协议可能需要重新审视和加强。2. 用户影响A. 现有旅客大面积航班取消导致行程严重延误旅客滞留机场数小时重新安排行程成本和时间损失B. 航空公司加航面临重大公关危机可能面临巨额赔偿航班运营受严重影响3. 技术趋势A. 跑道安全技术机场地面雷达系统车辆定位追踪技术自动化防撞预警系统B. 调查技术飞行数据记录仪（黑匣子）跑道监控录像空管录音分析五、各方反应1. 官方回应纽约市市长 Zohran Mamdani 将此描述为"悲惨的碰撞"，并表示国家运输安全委员会正在调查周日的这起事件。"我感谢我们的急救人员，他们的迅速行动挽救了生命。"港务局首席执行官 Kathryn Garcia 表示，她已在医院探望了消防车上的两名警官，他们能够说话，当局正在通知他们的家属。2. 业内评价A. 专家观点航空安全专家指出，飞机与地面车辆相撞虽然罕见，但每次都值得深入调查，以防止类似事件再次发生。B. 安全标准国际民航组织对跑道安全有严格规定，包括车辆进入跑道的审批程序和空管协调机制。3. 调查进展美国国家运输安全委员会已接管调查，将重点关注：空管指令记录车…

Manyana：基于 CRDT 的版本控制系统展望
type: item
date: 2026-03-22T22:52:48+00:00
description: Manyana：基于 CRDT 的版本控制系统展望一、新闻概述1. 标题Manyana：Bram Cohen 发布基于 CRDT 的版本控制系统，合并永不失败2. 发布时间2026 年 3 月3. 来源Bram Cohen 官方博客二、核心内容1. 事件摘要A. 主要内容BitTorrent 创始人 Bram Cohen 发布 Manyana 项目，这是一个基于 CRDT（Conflict-Free Replicated Data Types，无冲突复制数据类型）的版本控制系统演示，提出了版本控制的未来愿景。B. 核心亮点合并永不失败，CRDT 保证最终一致性更智能的冲突标记，显示"发生了什么"和"谁做的"行顺序永久化，避免多分支合并问题历史记录存储在数据结构中，而非依赖 DAGRebase 不需要销毁历史约 470 行 Python 代码实现2. 关键信息A. 涉及技术CRDT（Conflict-Free Replicated Data Types）版本控制数据结构：WeaveB. 项目状态概念验证级别演示公有领域代码单文件操作未实现：Cherry-picking、本地撤销C. 核心特性无阻塞合并信息性冲突标记永久行排序历史感知3. 背景介绍A. 作者背景Bram Cohen 是 BitTorrent 的创始人，在分布式系统和版本控制领域有深厚经验。B. 技术背景传统版本控制系统（如 Git）使用 3-way merge，存在冲突处理困难、合并顺序敏感等问题。CRDT 是分布式系统中常用的数据结构，能保证最终一致性。三、详细报道1. 主要内容A. CRDT 基础原理CRDT（无冲突复制数据类型）的核心特性：合并永不失败最终一致性保证合并结果与顺序无关适用于多分支并行开发graph TD A[分支 A 修改] --> M[CRDT 合并] B[分支 B 修改] --> M C[分支 C 修改] --> M M --> R[一致的结果状态] M -.从不失败.-> RB. 冲突标记改进传统 VCS 的冲突标记：<<<<<<< left ======= def calculate(x): a = x * 2 logger.debug(f"a={a}") b = a + 1 return b >>>>>>> rightManyana 的智能冲突标记：<<<<<<< begin deleted left def calculate(x): a = x * 2 ======= begin added right logger.debug(f"a={a}") ======= begin deleted left b = a + 1 return b >>>>>>> end conflict改进点：标记显示操作类型（删除/添加）标记显示操作来源（left/right）清晰展示冲突的结构无需脑力重构发生了什么C. 核心设计特性特性 1：行顺序永久化当两个分支在同一点插入代码时，CRDT 选择一个顺序并保持永久。这解决了以下问题：冲突部分在不同分支上以不同顺序解决多人独立工作时合并结果不一致传统 VCS 在没有共同祖先时的合并困难特性 2：冲突不阻塞合并合并总是产生结果并发编辑"距离太近"时才会标记冲突冲突仅用于审查，不阻止工作继续算法追踪"每边做了什么"，而非仅显示两个结果特性 3：历史存储在结构中状态是一个 Weave（编织结构）：包含文件中曾经存在的每一行每行带有添加和删除的时间元数据合并不需要查找共同祖先不需要遍历 DAGgraph LR A[状态 A] --> M[CRDT 合并] B[状态 B] --> M M --> R[结果状态] R --> W[Weave 结构 包含完整历史] W -.无需.-> DAG[传统 DAG]D. Rebase 的改进传统 Rebase 的问题：创建虚构历史销毁原始提交的真实上下文激进 rebase 产生无共同祖先的拓扑CRDT 系统的 Rebase：可以逐个重放提交到新基线同时保留完整历史仅需在 DAG 中添加"主要祖先"注解优势：激进 rebase 不再破坏可追溯性传统 3-way merge 在无共同祖先时失效CRDT 不在乎，历史在 Weave 中2. 技术细节A. 架构设计graph TB subgraph Manyana File[文件] --> CRDT[CRDT 引擎] CRDT --> Weave[Weave 结构] Weave --> History[历史记录] Weave --> State[当前状态] end CRDT -.合并永不失败.-> Weave Weave -.包含.-> History Weave -.派生.-> StateC. Weave 数据结构Weave 是…

GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息
type: item
date: 2026-03-22T22:47:47+00:00
description: GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息一、新闻概述1. 标题GrapheneOS 拒绝遵守年龄验证法律，宁可不卖也不收集用户信息2. 发布时间2026 年 3 月 22 日3. 来源Tom's Hardware二、核心内容1. 事件摘要A. 主要内容专注于隐私保护的 Android 分支项目 GrapheneOS 正式声明，将不会遵守新兴的年龄验证法律，拒绝在系统设置时收集用户年龄数据。B. 核心亮点GrapheneOS 明确表示永远不会要求提供个人信息、身份证明或账户宁可放弃某些地区的市场，也不妥协隐私原则多个国家和地区正在推进类似年龄验证法律2. 关键信息A. 涉及法律巴西 Digital ECA（Law 15.211）：已生效，单次违规罚款高达 5000 万雷亚尔（约 950 万美元）加利福尼亚州 Digital Age Assurance Act（AB-1043）：2027 年 1 月 1 日生效科罗拉多州 SB26-051：已通过州参议院B. 罚款金额加州：过失违规每名受影响儿童 2500 美元，故意违规 7500 美元巴西：每次违规最高 5000 万雷亚尔C. 涉及产品GrapheneOS 操作系统及其相关服务3. 背景介绍A. GrapheneOS 简介GrapheneOS 是一个专注于隐私和安全保护的 Android 分支操作系统，由加拿大非营利组织 GrapheneOS Foundation 开发。B. 法律背景全球多国正在推进要求操作系统收集用户年龄数据的立法，理由是保护儿童免受不当内容影响。三、详细报道1. 主要内容A. GrapheneOS 官方声明GrapheneOS 在 X 平台发布声明：GrapheneOS 将保持全球任何人可用，无需提供个人信息、身份证明或账户。GrapheneOS 和我们的服务将继续在国际上提供。如果 GrapheneOS 设备因法规无法在某个地区销售，那就这样吧。B. 各地法律进展巴西：Digital ECA（Law 15.211）已于 2026 年 3 月 17 日生效，要求操作系统供应商实施年龄验证，违者将面临高额罚款。加利福尼亚州：州长纽瑟姆于 2025 年 10 月签署的 Digital Age Assurance Act（AB-1043）将于 2027 年 1 月 1 日生效。该法律要求每个操作系统供应商在账户设置期间收集用户年龄或出生日期，并通过实时 API 将数据传输给应用商店和开发者。科罗拉多州：SB26-051 于 2026 年 3 月 3 日通过州参议院，包含类似要求。C. 法律管辖权问题GrapheneOS Foundation 是注册的加拿大非营利组织，这些法律并非源自加拿大。但管辖权问题仍存在不确定性。美国联邦检察官曾成功引渡并定罪隐私聚焦的比特币混合器 Samourai Wallet 的开发者，其中一名被告居住在葡萄牙。2. 技术细节A. 年龄验证机制加利福尼亚州的法律不要求照片 ID 或生物特征验证，用户只需在设置过程中自行申报年龄。B. 执法机制加州法律由州总检察长执行，对过失违规每次最高罚款 2500 美元，故意违规每次最高 7500 美元。3. 数据与事实A. 合作伙伴影响摩托罗拉与 GrapheneOS 于 2026 年 3 月 2 日在 MWC 上宣布建立长期合作伙伴关系，将把这款强化操作系统带到未来的摩托罗拉硬件上，结束 GrapheneOS 长期仅支持 Google Pixel 设备的排他性。搭载 GrapheneOS 的摩托罗拉手机预计于 2027 年推出。如果摩托罗拉销售预装 GrapheneOS 的设备，这些设备需要遵守销售市场的当地法规，或者摩托罗拉可能需要限制地理销售范围。B. 其他类似案例GrapheneOS 并非首个拒绝遵守年龄验证法律的公司，也不会是最后一个：开源计算器固件 DB48X 的开发者最近发布法律通知，声明其软件不实施、不能实施也不会实施年龄验证MidnightBSD 更新其许可证，禁止巴西用户使用四、影响分析1. 行业影响A. 技术趋势隐私保护与监管要求之间的冲突日益凸显开源项目和隐私优先的组织面临合规挑战B. 法律趋势多国正在推进类似年龄验证立法监管边界与互联网开放性的冲突加剧2. 用户影响A. 现有用户GrapheneOS 服务将继续国际可用用户隐私保护得到维护B. 潜在用户某些地区的用户可能无法购买预装 GrapheneOS 的设备技术用户仍可自行刷机安装C. 地理限制巴西、加利福尼亚州、科罗拉多州等地区的消费者可能面临购买限制。3. 技术趋势A. 隐私优先更多隐私优先的项目可能采取类似立场去中心化和自托管趋势可能加强B. 监管应对技术行业需要找到平衡隐私保护和合规的方…

GitHub Actions 新增定时任务时区支持
type: item
date: 2026-03-22T13:55:57+00:00
description: GitHub Actions 新增定时任务时区支持一、新闻概述1. 标题GitHub Actions 新增定时任务时区支持2. 发布时间2026 年 3 月 19 日3. 来源GitHub 官方博客二、核心内容1. 事件摘要A. 主要内容GitHub 官方在 2026 年 3 月 19 日的 changelog 中宣布，GitHub Actions 现已支持为定时任务（scheduled workflows）指定时区。用户不再局限于使用 UTC 时间，可以直接使用 IANA 时区标识符来配置本地时间执行。B. 核心亮点可在 cron 表达式中添加 timezone 字段支持 IANA 标准时区标识符（如 America/New_York、Asia/Shanghai）解决了困扰开发者近 4 年的需求同时发布了无需自动部署的环境配置功能2. 关键信息A. 版本说明功能类型：Improvement（功能改进）发布日期：2026 年 3 月 19 日相关讨论：GitHub Community Discussion #13454B. 涉及产品GitHub ActionsCI/CD 定时任务调度3. 背景介绍A. 历史背景该功能需求最早于 2022 年在 GitHub Community Discussion #13454 中提出。在功能发布之前，GitHub Actions 的定时任务仅支持 UTC 时间，导致非 UTC 时区的开发者需要手动计算时差，特别是在涉及夏令时（DST）的情况下更加复杂。B. 用户痛点亚洲时区用户（如 GMT+8 的新加坡）难以准确设置每月第一天的午夜任务需要手动调整夏令时和冬令时的时间差跨时区团队的协作调度困难三、详细报道1. 主要内容A. 功能更新新增 timezone 字段，开发者可以在 workflow 的 cron schedule 配置中直接指定时区：on: schedule: - cron: '0 8 * * *' timezone: 'America/New_York'B. 技术细节支持所有 IANA 时区数据库中的时区标识符timezone 字段与 cron 表达式配合使用系统会自动处理该时区的夏令时转换C. 已知问题发布初期存在一个小 bug：当 workflow 同时包含 schedule（带 timezone）和 workflow_dispatch 时，手动触发会报错。错误信息为「timezone in scheduled workflows is not yet supported」。但定时调度本身正常工作。2. 技术原理graph LR A[用户配置 Cron + Timezone] --> B[GitHub Actions 调度器] B --> C{解析时区} C --> D[转换为 UTC 执行时间] D --> E[在指定本地时间触发 Workflow]A. 配置示例示例 1：北京时间每天上午 8 点执行on: schedule: - cron: '0 8 * * *' timezone: 'Asia/Shanghai'示例 2：纽约时间每周一上午 9 点执行on: schedule: - cron: '0 9 * * 1' timezone: 'America/New_York'示例 3：柏林时间每月 1 日午夜执行on: schedule: - cron: '0 0 1 * *' timezone: 'Europe/Berlin'B. 旧版变通方案对比在时区支持发布之前，开发者使用的变通方案：# 旧方案：手动计算 UTC 时间 on: schedule: # 北京时间 8:00 = UTC 0:00 - cron: '0 0 * * *' # 或者在 workflow 中检查时间 jobs: check_time: runs-on: ubuntu-latest steps: - name: Check if it's 8 AM run: | current_hour=$(TZ='Asia/Shanghai' date +'%H') if [ "$current_hour" == "08" ]; then echo "run_tasks=true" >> $GITHUB_ENV fi四、影响分析1. 用户影响A. 现有用户无需修改现有配置，向后兼容可逐步将 UTC 配置迁移为本地时区需要注意已知的 workflow_dispatch bugB. 新用户可以直接使用本地时区配置，降低使用门槛无需手动计算时差，减少配置错误2. 技术趋势A. 标准化采用 IANA 时区数据库标准，与主流编程语言和系统保持一致时区自动处理夏令时，符合国际化最佳实践B. 用户体验GitHub 持续关注…

维基百科再度拉黑 Archive.today，删除 69.5 万条存档链接
type: item
date: 2026-03-22T09:51:19+00:00
description: 维基百科再度拉黑 Archive.today，删除 69.5 万条存档链接一、新闻概述1. 标题维基百科再度拉黑 Archive.today：利用访问者浏览器发动 DDoS 攻击2. 发布时间2026 年 2 月 20 日3. 来源维基百科社区共识、Solidot、IT之家等多家媒体报道二、核心内容1. 事件摘要A. 主要内容英文版维基百科编辑达成共识，决定将网页存档网站 Archive.today 及其镜像站点（archive.is、archive.ph）列入黑名单，并清理分散在约 40 万个页面中的 69.5 万条引用链接。B. 核心亮点维基百科史上最大规模的链接清理行动之一Archive.today 被指控利用访问者浏览器对持异见者发动 DDoS 攻击该网站还涉嫌冒用他人身份、篡改存档内容2. 关键信息A. 涉及数据受影响页面：约 40 万个待删除链接：约 69.5 万条DDoS 攻击频率：每 300 毫秒发送一次请求B. 涉及服务Archive.today 主站archive.is、archive.ph 等镜像站点CAPTCHA 验证页面（被植入攻击代码）C. 事件时间线2023 年 8 月：博主发表调查文章2025 年 10 月：FBI 发出传票2026 年 2 月：DDoS 攻击曝光2026 年 2 月 20 日：维基百科正式拉黑3. 背景介绍A. Archive.today 简介Archive.today（又称 archive.is 或 archive.ph）是一个私人资助的网页存档网站，成立于 2012 年。与互联网档案馆的 Wayback Machine 不同，该服务采用用户主动提交的方式存档网页，不遵守 Robots 排除标准。B. 历史争议2013-2016 年：曾被维基百科拉黑，原因包括僵尸网络和链接垃圾2015 年：封锁芬兰 IP 地址，避免与政府纠纷被中国、哈萨克斯坦封锁三、详细报道1. DDoS 攻击事件A. 事件起因2023 年 8 月，博主 Jani Patokallio 发表文章，利用公开信息调查 Archive.today 幕后运营者的身份，文章点击量约 1 万次。2025 年 10 月，FBI 向域名注册商 Tucows 发出传票，要求提供 Archive.today 注册者信息。媒体报道时引用了 Patokallio 的博客，称 Archive.today 创始人可能来自俄罗斯。B. 攻击手段Archive.today 向 Patokallio 发送邮件要求撤下文章（被 Gmail 归类为垃圾邮件）。在未获回应后，该网站在 CAPTCHA 验证页面中嵌入了恶意代码。攻击原理：graph LR A[用户访问 Archive.today] --> B[弹出 CAPTCHA 验证] B --> C[页面加载恶意 JavaScript] C --> D[每 300ms 发送请求] D --> E[目标博客服务器] E --> F[带宽耗尽/费用增加]只要用户保持 CAPTCHA 页面打开，恶意代码就会每隔 300 毫秒向 Patokallio 的博客发送一次请求，通过大量访问者的浏览器形成分布式拒绝服务攻击。C. 威胁与骚扰Archive.today 运营者对 Patokallio 进行辱骂和威胁，声称要开发与他名字相关的 AI 色情内容。2. 其他恶意行为A. 篡改存档内容Archive.today 被发现在存档页面中擅自插入与持异见者相关的内容，破坏了存档作为可靠证据的可信度。B. 冒用身份该网站涉嫌冒用他人身份进行操作。3. 维基百科的决策A. 社区讨论DDoS 攻击事件曝光后，维基百科志愿者发起了关于是否将 Archive.today 加入黑名单的讨论（RFC 5）。B. 最终决定维基百科编辑达成共识：立即弃用 Archive.today将其添加到垃圾黑名单创建编辑过滤器阻止添加新链接删除所有指向该站点的约 69.5 万条链接四、影响分析1. 行业影响A. 网页存档生态Archive.today 曾被视为仅次于互联网档案馆的第二重要网络存档服务，特别适用于：收费网站的存档大量使用 JavaScript 的页面被 Robots.txt 阻止的页面此次事件将严重影响其可信度和使用率。B. 存档服务信任危机用户对第三方存档服务的信任度下降，可能促使用户转向：互联网档案馆 Wayback Machine自建存档方案Perma.cc 等学术存档服务2. 用户影响A. 维基百科读者约 40 万个页面的引用链接失效部分历史证据难以追溯需要寻找替代存档来源B. 数据保存爱好者失去一个重要的存档工具对存档服务的可靠性和中立性产生质疑3. 技术趋势A. CAPTCHA 安全性此次事件暴露了 CAPTCHA…

本田取消电动车项目及其未来竞争力危机
type: item
date: 2026-03-18T00:08:59+00:00
description: 本田取消电动车项目及其未来竞争力危机一、新闻概述1. 标题本田取消电动车项目及其未来竞争力危机2. 发布时间2026 年 3 月 14 日3. 来源TechCrunch二、核心内容1. 事件摘要A. 主要内容本田宣布取消其在美国市场的电动车项目，包括三款从零开始设计的电动车和一款由通用汽车代工的车型。B. 核心亮点本田取消 Acura RDX、Honda 0 轿车和 SUV 三款车型的开发停止 Prologue 车型的生产，该车完全由通用汽车设计和制造公司将问题归咎于美国关税和中国竞争2. 关键信息A. 涉及产品Acura RDX（电动版）Honda 0 轿车Honda 0 SUVPrologue（通用汽车代工）B. 市场影响本田在电动车领域将进一步落后竞争对手错失汽车行业两大转型机遇：电动化和软件定义车辆C. 财务数据本田在中国市场去年亏损近 160 亿美元3. 背景介绍A. 行业环境传统汽车制造商面临补贴削减和中国汽车制造商激烈竞争的双重压力。B. 公司现状本田核心业务依赖内燃机，在电动车领域缺乏实质性进展。三、详细报道1. 主要内容A. 项目取消详情周四，本田宣布暂停电动版 Acura RDX 和 Honda 0 轿车、SUV 的开发。这三款车型是本田首批从零开始设计的电动车，但对外披露的信息极少。周五，Automotive News 报道本田将停止 Prologue 的生产。这款车本质上是通用汽车的产品，由通用汽车完全设计和制造。B. 本田的策略失误本田将问题归咎于美国关税和中国竞争，但这些只是表面原因。文章指出，本田从一开始就没有真正可行的电动车战略。对于本田等转型初期的传统汽车制造商来说，电动车只是换了一种动力总成的汽车。这种思维导致本田认为可以等待转型期过去，在电机和电池技术成熟后再简单替换燃油车的零件。graph TD A[传统车企思维] --> B[电动车只是换动力] B --> C[等待技术成熟] C --> D[简单替换零件] E[正确路径] --> F[从头设计电动车] F --> G[轻量化] F --> H[高效能] F --> I[低成本] style E fill:#90EE90 style B fill:#FFB6C62. 技术细节A. 燃油车改造的问题许多汽车制造商发现，将电池塞进原本为内燃机设计的汽车中效果不佳。虽然可以缩短开发周期，但最终产品重量大、效率低、制造成本高。以福特为例，Mustang Mach-E 虽然在销量上成功，但在财务上却是亏损产品。Mach-E 基于Escape 燃油车平台修改而来，福特 CEO Jim Farley 表示，由于过去的工程决策，Mach-E 的线束比特斯拉重 70 磅。在汽车这样复杂的产品中，这种小错误会不断叠加。B. 错失的学习机会本田将错失以下关键学习机会：开发经验：从零开始设计电动车的经验制造经验：电动车的生产制造经验供应链：培育新的供应商和供应链用户反馈：了解用户在电动车中真正看重什么3. 软件定义车辆A. 概念介绍汽车行业正在经历第二大变革：软件定义车辆。软件定义车辆的核心功能可以通过空中更新（OTA）进行升级和改进。B. 消费者期望购买特斯拉、Rivian、比亚迪等品牌电动车的消费者已经习惯了频繁的系统更新、流畅的车载娱乐软件和先进的驾驶辅助系统。本田在这些领域都还没有显著进展。C. 电动车与软件定义的关系软件定义车辆不一定是电动车，但两者往往相辅相成。电动车的大电池更容易为强大的计算机供电，并允许在汽车停放和关闭时进行空中更新。本田可以制造燃油版软件定义车辆，但不太可能这么做，原因与放弃电动车相同：旧方式现在更容易，也更有利可图。graph LR A[电动车大电池] --> B[支持强大计算机] B --> C[OTA 空中更新] C --> D[功能持续升级] D --> E[软件定义车辆] F[传统燃油车] --> G[电池容量有限] G --> H[计算能力受限] H --> I[更新能力不足] style A fill:#87CEEB style F fill:#FFB6C64. 数据与事实A. 本田中国市场表现本田在最近的财报中表示：本田未能提供比新型电动汽车制造商更具性价比的产品，导致竞争力下降。中国市场的逆风因素导致公司去年亏损近 160 亿美元。B. 本田品牌定位危机本田面临身份危机。其核心是一家内燃机公司，擅长制造优质发动机，但这越来越不重要了。多年来，本田以制造驾驶者之车为荣，车辆轻量化、高效、操控性好。但当汽车能够自动驾驶时，驾驶者之车的意义何在？C. 市场现实人们选择本田是因为它可靠且价格合理。操控性好只是锦上添花。但电动车承诺比燃油车更可靠，而且随着中国汽车制造商的实践，一旦电池价格下降，整车成本也会下降。如果本…

每一层审查让你慢 10 倍
type: item
date: 2026-03-17T11:29:21+00:00
description: 每一层审查让你慢 10 倍一、新闻概述1. 标题每一层审查让你慢 10 倍2. 发布时间2026 年 3 月 16 日3. 来源apenwarr.ca（Avery Pennarun 的个人博客）二、核心内容1. 事件摘要A. 主要内容Tailscale CEO Avery Pennarun 发表观点文章，指出软件开发中每一层审查都会让流程变慢 10 倍。文章分析了为什么 AI 代码生成无法解决这一瓶颈，并提出了通过减少审查层级和建立信任文化来提高开发效率的方案。B. 核心亮点每一层审查会让流程慢 10 倍（按实际时间计算，而非工作量）AI 的加速作用被后续审查等待时间抵消传统 QA（质量保证）模式反而会降低质量通过模块化和小组信任文化替代多层级审查2. 关键信息A. 版本号/发布内容这是一篇博客观点文章，非产品发布B. 重要数据简单 Bug 修复：30 分钟同事代码审查：300 分钟（5 小时）设计文档批准：50 小时（约 1 周）跨团队协调：500 小时（12 周，一个季度）高管决策：10 个季度（约 2.5 年）C. 涉及产品/技术软件开发流程、代码审查、质量保证、AI 编码助手、模块化架构3. 背景介绍A. 前置版本/历史作者 Avery Pennarun 之前有多篇关于系统设计的文章，本文是其系统设计系列的延续，特别关注 LLM（大型语言模型）时代的软件工程问题。B. 相关上下文随着 Claude Code 等 AI 编码工具的兴起，软件开发速度大幅提升，但传统的审查流程成为新的瓶颈。三、详细报道1. 主要内容A. 审查层级的速度衰减规律作者提出一个经验法则：每一层审查会让流程变慢 10 倍。这里的变慢指的是实际时间，而非工作量。大部分额外时间都花在等待上。具体示例：graph LR A[简单 Bug 修复 30 分钟] --> B[同事代码审查 300 分钟] B --> C[设计文档批准 3000 分钟] C --> D[跨团队协调 30000 分钟] D --> E[高管决策 75000 分钟]B. AI 无法解决等待延迟问题AI 编码工具可以将编码时间从 30 分钟缩短到 3 分钟，但：如果开发者用节省的时间自己审查 AI 生成的代码，仍然是循环等待如果直接提交未验证代码，审查者仍需 5 小时，且会因阅读低质量代码而不满如果用于大型项目，代码太长无法一次审查，需要拆分为多个小块，每个都有 5 小时审查周期C. QA（质量保证）的悖论作者引用 W. E. Deming 的质量管理哲学，指出传统 QA 模式的问题：在工厂环境中，如果每一轮 QA 能捕获 90% 的缺陷，理论上两轮就能减少 100 倍缺陷。但现实中的问题：第一道 QA 知道有第二道 QA，会降低工作标准第二道 QA 不愿过于严格，因为这会影响同事的评价生产人员知道有 QA 检查，会降低生产时的质量控制这种"多层检查"模式实际上激励了质量控制的外部化，而非内部化。D. 日本汽车制造业的启示著名的丰田生产系统完全取消了专门的 QA 阶段，而是给每个工人一个"停止生产线"按钮。当发现缺陷时，任何人都可以停止生产线进行修复。美国汽车制造商试图复制这一系统，安装了同样的按钮，但没有人敢使用，因为害怕被解雇。关键差异在于信任：员工信任上级真心希望了解每个缺陷管理层信任员工会主动发现问题执行层信任系统确实有效E. 代码审查的真正使命代码审查者的工作不是审查代码，而是弄清楚如何让这一类评论在未来不再出现。等到审查发现错误时，错误已经发生了。审查只是症状，而非根本原因。F. 模块化和小组协作的解决方案作者提出的解决方案：组件应该由能全权负责的小团队构建小团队可以建立对质量的共识和信任通过清晰定义的接口，组件可以可靠地交付给其他团队可以让多个小组竞争构建同一组件，通过进化选择质量利用 AI 快速尝试不同的模块边界代码现在很便宜，但好的想法仍然稀缺。AI 编码使我们能比以往更快地实验新想法。2. 技术细节A. AI 开发者的堕落循环作者描述了 AI 辅助开发中常见的恶性循环：graph TD A[1. 原型快速完成] --> B[2. 发现 Bug 让 AI 修复] B --> C[3. 每次修复引入新 Bug] C --> D[4. 用 AI 代理审查代码] D --> E[5. 人工在代理间传递数据] E --> F[6. 需要代理框架] F --> G[7. 让 AI 编写代理框架] G --> A许多开发者陷入这个循环，不断让 AI 生成更复杂的代理框架，而实际代码质量没有提升。B. 单体和微服务的平衡微服务之前名声不好，因为它们"太微"。在原始术语中，一个"微"服务正好适合"两个披萨团队"独立构建和运维。有了 AI，可能只需要一个披萨和一些 token。有趣的是…