给软件开发者准备的优质简报，每日阅读 10分钟。
France Launches Government Linux Desktop Plan as Windows Exit Begins
法国政府加速推进数字主权战略，减少对非欧洲技术的依赖
- 2026年4月8日，法国数字部际管理局（ DINUM）联合国家企业总局（DGE）、网络与信息安全局（ANSSI）及国家采购局（DAE）召开部际研讨会，在总理及多位部长推动下，标志着法国和欧洲数字主权战略进入加速阶段
- DINUM宣布从Windows系统过渡到Linux；法国国家医疗保险局已将其8万名员工迁移至部际数字基础工具（Tchap、Visio、FranceTransfert）；政府还计划在2026年底前将健康数据平台迁移至可信欧洲解决方案
- 法国推动建立前所未有的公共与私营部门联盟，通过数字公共资源和互操作性标准（如Open-Interop、OpenBuro项目）整合各方力量减少技术依赖
- 各部委及其下属公共运营商须在秋季前制定各自的减少依赖计划，涵盖工作站、协作工具、杀毒软件、人工智能、数据库、虚拟化、网络设备等领域
- DINUM将于2026年6月举办首届"数字产业会议"，届时将正式建立公共-私营"欧洲主权联盟"，为数字产业提供明确的需求可见性
- David Amiel部长明确表示"我们必须摆脱对美国工具的依赖，重新掌控数字命运"，强调数字主权是战略必需品而非选项
Claude mixes up who said what
Claude混淆消息来源的严重Bug解析
- 问题本质：Claude有时会将发送给自身的消息误认为来自用户，这种"身份混淆"Bug在性质上与"幻觉"或"权限边界缺失"完全不同
- 典型案例：作者遇到Claude无视自己的错别字后仍坚称是用户说的；Reddit用户发现Claude指示"拆除H100"后声称这是用户的命令；nathell分享了Claude自问"是否提交进度"却当作用户批准的案例
- 广泛影响：文章登上Hacker News榜首后，多位用户确认在chatgpt.com等其他平台也遇到过类似问题，表明这已不是个别现象
- 触发规律：该Bug似乎出现在对话接近上下文窗口极限时的"迟钝区"，可能涉及系统框架层面的问题而非模型本身
- 关键澄清：问题不在于用户给予AI的权限是否过大，而在于AI系统在消息溯源上存在根本性缺陷，容易将自身输出错误地归因于用户
I still prefer MCP over skills
我仍然更偏好MCP而非Skills
- MCP作为API抽象层，将"调用什么"与"如何实现"分离，LLM只需调用
devonthink.do_x()这类工具函数，无需理解底层实现细节 - MCP的核心优势在于：远程服务零安装即用、客户端自动同步更新、OAuth优雅认证、跨设备真正可移植、自然沙箱隔离机制，以及按需智能加载节省上下文窗口
- Skills依赖CLI安装，但ChatGPT网页版、Perplexity、标准Claude等大多数AI工具环境无法运行CLI，导致在大量使用场景下完全失效
- Skills面临部署繁琐、密钥管理混乱、生态碎片化（各平台安装方式不统一）、以及需将整个SKILL.md文档加载进上下文的膨胀问题
- MCP应用于服务连接层（Google Calendar、Chrome、Hopper调试器、Xcode、Notion等应原生提供MCP端点），Skills应专注于知识教学和流程规范（如git用法、内部术语、PDF处理方式、密钥管理模式）
- MCP与Skills的最佳组合是"连接器层+知识层"：先用MCP处理实际连接和工具调用，再针对使用过程中发现的坑（如日期格式要求、结果截断参数）编写Skill作为作弊小抄，为后续会话提供上下文提示
Native Instant Space Switching on macOS
macOS 原生即时桌面切换解决方案
- macOS 切换桌面（Spaces）时的动画效果虽短，但频繁切换时令人不适，苹果公司长期忽视用户禁用该动画的请求
- 现有解决方案均有缺陷："减少动态效果"设置仅替换为淡入淡出效果且影响浏览器；yabai 需禁用 SIP 且强制作为平铺窗口管理器使用；第三方虚拟空间管理器非原生且多余；BetterTouchTool 则需付费
- 作者推荐 InstantSpaceSwitcher，该工具通过模拟高速触控板滑动手势实现即时切换，无需禁用 SIP，与作者的 PaperWM.spoon 窗口管理器兼容
- 支持直接跳转到指定编号桌面，提供命令行界面
ISSCli，可用left、right或index <n>参数操作 - 安装方式灵活：Homebrew 安装（
brew install --cask jurplel/tap/instant-space-switcher）、源码编译或直接下载预编译二进制文件 - 另有基于相同原理的触控板滑动版工具 iss，由他人独立开发
How NASA built Artemis II’s fault-tolerant computer
NASA阿耳忒弥斯II号猎户座飞船的容错计算机架构
- 猎户座飞船采用双车辆管理计算机（VMC）加四飞行控制模块（FCM）架构，每台VMC包含2个FCM，每块FCM配备自检处理器对，共8个CPU并行运行；系统采用"故障静默"设计理念，检测到辐射诱发的错误计算后立即停止输出，而非传递错误结果，从而简化传统的三元表决机制，改用优先级排序的源选择算法从健康通道中选取输出
- 系统基于严格确定性架构，通过时间触发以太网和ARINC653兼容调度器实现时间与空间分区，确保所有FCM在同一时刻接收相同输入、执行相同代码、产生相同输出；每秒校准各模块本地时钟至网络"真时"，若应用未在严格时限内完成则自动静默、复位并重新同步
- NASA使用高性能超级计算机进行大规模故障注入测试，模拟极端辐射环境和灾难性硬件故障场景，验证软件能否成功实现故障静默并恢复；系统设计可承受在22秒内损失3个FCM后仍安全运行于最后一个模块，失效的FCM可中途复位、重新同步状态并重新加入运行
- 配备完全独立的备份飞行软件（BFS），运行在不同硬件和操作系统上，采用独立开发的简化飞行软件，专门用于应对主系统软件中可能导致所有主通道同时失效的共模故障；BFS持续后台运行并自动通过源选择接管故障的主计算机
- 硬件层面采用三重模块冗余（TMR）内存，每读一次自动纠正单位错误；网络接口卡使用双通道实时比对；整个网络采用三平面三重冗余设计，所有网络交换机均配备自检策略，确保通信链路中的位翻转触发故障静默而非发出错误指令
- 即使在完全断电的"死母线"极端情况下，猎户座飞船也能自动恢复：先稳定自身姿态并指向太阳恢复太阳能，再调整尾部朝太阳保持热稳定性，最后尝试重新建立与地球通信；宇航员也可手动配置生命维持系统或穿戴航天服
You can't trust macOS Privacy and Security settings
macOS隐私与安全设置界面存在误导性漏洞
- 系统界面与实际权限不符：macOS“隐私与安全性”设置中的“文件与文件夹”权限列表无法准确反映应用的真实访问权限。一个应用可能在后台拥有对受保护文件夹的完全访问权限，但该列表却可能显示其为被阻止状态，或者根本不显示该应用。
- 用户主动操作会绕过权限系统：当用户通过应用程序的“打开/保存面板”主动选择一个受保护文件夹时，系统将此视为用户“表达了意图”。这一操作会移除对该文件夹的沙盒限制，允许应用程序无需TCC授权即可访问。即使之后在设置界面中关闭相关权限，该访问权限依然存在。
- 关键绕过机制在于扩展属性：用户通过打开/保存面板选择文件夹后，系统会在该文件夹上添加一个名为“com.apple.macl”的受保护的扩展属性。这个属性是应用程序绕过沙盒约束的关键，并且它不受TCC权限系统的控制。
- 权限重置困难且不彻底：取消此类绕过授权极其困难。即使在终端中执行
tccutil reset All命令并重启Mac来重置应用的隐私设置，上述扩展属性仍然会保留在文件夹上，使得权限重置不完整。 - 漏洞利用需要精心设计但真实存在：恶意应用需要诱导用户在特定时机通过打开/保存面板选择目标文件夹才能利用此漏洞。然而，许多用户报告的应用能在未出现在权限列表的情况下访问文件夹，表明这种绕过授权的情况确实在现实中发生。
WireGuard makes new Windows release following Microsoft signing resolution
WireGuardNT v0.11 和 WireGuard for Windows v0.6 正式发布
- Jason A. Donenfeld 宣布发布 WireGuardNT v0.11（底层内核驱动与 API 接口）和 WireGuard for Windows v0.6（高层管理软件、命令行工具及 UI），因距上次更新间隔较长且有相关新闻报道而破例发送公告邮件
- 代码大幅精简：提升最低支持的 Windows 版本后移除了数十年积累的兼容性代码、替代代码路径、动态分发逻辑等技术债务，累积了大量 bug 修复和性能改进，构建基础更加稳固
- 新增功能包括支持单独删除允许的 IP 地址而不丢包（该功能此前已在 Linux 和 FreeBSD 上实现），以及在 IPv4 连接上设置极低的 MTU 值
- 工具链全面升级，涵盖驱动构建工具 EWDK、用户态工具链 Clang/LLVM/MinGW、UI 程序语言 Go 以及 EV 证书签名基础设施，并在微软已停止支持的 Windows 10 1507 Build 10240 上完成测试
- 提交新版 NT 内核驱动至微软签名时账户曾被暂停，经作者在 Hacker News 和 Twitter 发文引发关注后次日即获解除，作者明确表示此为官僚流程问题而非恶意或阴谋，多数新闻报道尚未更新以反映该问题已快速解决
- 内置自动更新程序会提示用户点击升级，或可使用约 80KB 的下载器直接获取并验证安装最新版本
CPU-Z and HWMonitor compromised
CPUID网站遭劫持，合法下载链接被替换为恶意软件
- 事件时间与范围：2026年4月9日至10日约六小时内，CPUID网站的一个次要API功能遭入侵，HWMonitor、CPU-Z等工具的下载链接被随机替换为恶意链接，用户可能下载到文件名异常的伪造安装程序（如HWMonitor 1.63更新指向"HWiNFO_Monitor_Setup.exe"）。
- 攻击方式：攻击者并未篡改原始签名文件，而是劫持了下载服务层，向64位HWMonitor用户推送包含伪造CRYPTBASE.dll的恶意安装程序。
- 恶意软件运作机制：该恶意软件尽量避免磁盘写入，主要在内存中运行，使用PowerShell与C2服务器通信，下载额外代码后在受害机器上编译.NET载荷并注入其他进程。
- 窃密行为：恶意软件试图通过Chrome浏览器的IElevation COM接口访问和解密存储的凭据，且其基础设施与此前针对FileZilla用户的攻击活动存在关联。
- 事件处置：CPUID已确认并修复入侵，但未披露API的具体入侵方式及受影响用户数量；此事件表明攻击者无需接触源代码即可通过劫持下载服务造成严重危害。
USB for Software Developers: An introduction to writing userspace USB drivers
软件开发者的USB入门指南
- USB设备驱动可以在用户空间编写，无需编写内核代码，难度与使用Socket网络编程相当，libusb库提供热插拔检测、设备枚举和 claiming interface 等功能
- 文章以Android手机Bootloader模式（Fastboot）为例，通过libusb的
libusb_hotplug_register_callback注册热插拔回调，使用libusb_control_transfer发送控制请求获取设备描述符 - 设备通过VID（供应商ID）和PID（产品ID）进行标识，描述符包含设备的完整信息如设备类、最大包大小等，可使用
lsusb -d VID:PID -v命令查看详细描述符树 - USB端点有四种传输类型：控制传输（固定端点0x00，用于初始化配置）、批量传输（大容量非实时数据，优先级最低）、中断传输（低延迟小数据，如HID设备）、等时传输（实时音视频流）
- USB是主从架构，端点具有方向性——IN端点用于主机接收数据，OUT端点用于主机发送数据，端点地址最高位为1表示IN、为0表示OUT，且每个端点只能单向传输
- Fastboot协议实现：通过OUT端点0x02发送字符串命令（如"getvar:version"），设备通过IN端点0x01响应，返回4字节状态码（如"OKAY"）加上数据
Bluesky April 2026 Outage Post-Mortem
Bluesky 2026年4月服务中断技术复盘
- Bluesky于4月6日（周一）发生大规模服务中断，持续约8小时，影响约半数用户，故障前兆始于4月4日（周六），团队直至周三才定位并修复根本原因，官方表示这是其任职以来最严重的故障
- 根本原因：
GetPostRecord端点是系统中唯一缺少并发限制（errgroup.SetLimit）的接口，新部署的内部服务虽每秒仅发送不到3个请求，但每个请求批量包含1.5万至2万个URI（正常仅1-50个），导致同时启动数万个goroutine连接memcached，连接关闭后在TCP TIME_WAIT状态下耗尽服务器可用端口 - 诊断困难：团队最初误判为网络传输问题，且缺乏按客户端区分的监控指标，所有缓存类型（post cache、user cache等）同时报错，新服务仅部署在一个数据中心，进一步增加了定位难度
- "死亡螺旋"机制：大量错误日志触发阻塞式write(2)系统调用，导致Go运行时线程数从150激增至约1500（增长10倍），引发频繁的stop-the-world GC暂停；同时高度调优的GOGC和GOMEMLIMIT参数导致服务频繁OOM；memcached连接池饱和后，重启的进程因旧连接仍处于TIME_WAIT状态而无法创建新连接，形成持续恶化循环
- 修复方案：临时措施是为memcached客户端配置随机回环IP（127.x.x.x）以扩展可用端口空间；根本修复则是为GetPostRecord端点添加
group.SetLimit(50)并发限制 - 经验教训：需要在故障发生前建立per-client可观测性和大规模请求监控；高频错误日志不如Prometheus指标或OTEL追踪适合高并发系统；状态页曾误报为第三方供应商问题，实际为内部代码缺陷