ChatGPT Atlas 概述

ChatGPT Atlas 是一个浏览器扩展程序，旨在将 ChatGPT 集成到用户的网络浏览体验中，提供即时的答案、智能建议和任务协助，同时强调用户对隐私设置的控制权。

核心功能

• 侧边栏助手：在任何浏览窗口中打开 ChatGPT 侧边栏，用于总结网页内容、比较产品或分析所查看网站的数据。
• 上下文记忆：允许用户选择 ChatGPT 记住哪些信息，以便在需要时提供相关的细节，延续对话或任务的上下文。
• 代理模式：在用户授权下，ChatGPT 可以自动与网站进行交互并完成任务，例如从头到尾的研究和购物。此功能目前以预览形式向 Plus、Pro 和 Business 账户用户开放。
• 随处可用的协助：通过将光标变为协作工具，用户可以在电子邮件、日历邀请或文档中高亮文本，并一键获取聊天帮助。

隐私与控制

用户拥有完全的控制权，可以：

• 决定 ChatGPT 可以访问哪些网站。
• 清除浏览历史记录。
• 使用无痕模式。
• 随时管理浏览器记忆。

其他特性

• 智能搜索：支持以文本、图片、视频或新闻文章等多种形式获取信息。
• 易用性：提供标签页、自动补全、搜索栏和书签等功能，便于浏览。
• 自定义：轻松设置个人浏览偏好和界面颜色。

作者分享了自己维护点文件（dotfiles）十多年间编写并频繁使用的个人Shell脚本集合，按功能分为多个类别：

剪贴板管理

• copy/pasta：系统剪贴板命令的封装，用于快速复制和粘贴内容。
• pastas：实时监听并输出剪贴板内容变化，便于记录。
• cpwd：将当前工作目录路径复制到剪贴板，方便在不同终端间切换目录。

文件管理

• mkcd：创建目录并立即进入。
• tempe：快速进入一个临时目录，无需手动清理。
• trash：将文件移至废纸篓，比 rm 更安全。

互联网工具

• serveit：在当前目录快速启动一个本地静态文件服务器。
• getsong/getpod：使用 yt-dlp 从 YouTube 或 SoundCloud 等站点下载音频内容。
• getsubs：下载视频的英文字幕（优先官方，其次自动生成）。
• wifi toggle：控制 Wi-Fi 开关的便捷脚本。
• url：解析 URL 字符串，提取其各个组成部分。

文本处理

• line N：从标准输入中提取第 N 行。
• scratch：打开一个临时的 Vim 缓冲区。
• straightquote：将“智能引号”转换为“直引号”。
• markdownquote：为选中的文本块添加引用符号（>），在 Vim 中常用。

REPL启动器

• 为多种语言提供快速启动交互式环境（REPL）的脚本，如 iclj (Clojure)、ijs (Deno/Node)、ipy (Python) 等。

日期与时间

• hoy：以 ISO 格式输出当前日期。
• timer：启动一个计时器，时间到后播放声音并发送系统通知。
• rn：输出当前日期、时间和日历。

音视频与图片

• ocr：从图片中提取文本（仅限 macOS）。
• boop：根据上一个命令的成功或失败播放相应的声音提示。
• tunes/pix：使用 mpv 播放音频或显示图片。
• speak：将标准输入的文本转换为语音朗读。
• shrinkvid：压缩视频文件大小。
• removeexif：移除 JPEG 文件的 EXIF 数据。

进程管理

• each：为管道中的每一项执行指定命令，比 xargs 更易用。
• running：更清晰地查看匹配某个名称的进程。
• murder：尝试逐步发送信号（从温和到强制）来优雅地终止进程。
• waitfor：等待某个进程 ID（PID）结束，并防止系统休眠。
• bb：将命令在后台彻底静默运行。

快速参考

• emoji：根据关键词查询并显示相关表情符号。
• httpstatus：查询并显示 HTTP 状态码及其含义。
• alphabet：快速输出英文字母表。

系统管理

• theme：切换整个系统（包括终端、编辑器等）的暗色/亮色主题。
• sleepybear：让系统进入休眠状态。
• ds-destroy：递归删除目录中的所有 .DS_Store 文件。

杂项工具

• catbin：查看位于 $PATH 中某个命令的源代码。
• notify：发送系统通知，被其他脚本调用。
• uuid：生成一个 UUID。

这些脚本旨在自动化重复性任务、简化复杂命令和提高日常工作流效率，涵盖了从文件操作、文本处理到系统管理的广泛场景。

研究核心发现
由欧洲广播联盟（EBU）协调、BBC主导的国际研究表明，AI助手在处理新闻内容时存在系统性失真问题。研究覆盖18个国家的22家公共服务媒体，涉及14种语言，评估了ChatGPT、Copilot、Gemini和Perplexity四个AI工具超过3000条回复。

关键问题

• 45% 的AI回复存在至少一项显著问题。
• 31% 的回复出现来源问题（如缺失、误导或错误的归属引用）。
• 20% 的回复包含重大准确性问题（如捏造信息或内容过时）。
• Gemini表现最差，76%的回复存在显著问题，主要因来源引用能力薄弱。

背景与影响
AI助手正逐渐取代搜索引擎成为新闻获取渠道（路透社报告显示，7%的在线新闻消费者使用AI助手获取新闻，25岁以下人群中达15%）。失真内容可能削弱公众信任，影响民主参与。EBU媒体总监指出，此类问题具有“系统性、跨国性和多语言性”；BBC生成式AI项目总监强调，需与AI公司合作提升内容可靠性。

应对措施

• 研究团队发布《AI助手新闻完整性工具包》，提出优化AI回复质量及用户媒体素养的方案。
• EBU呼吁欧盟及各国监管机构强化现有法律执行，确保信息完整性、数字服务及媒体多元化。
• 强调需对AI助手进行持续独立监测，以应对AI快速发展带来的挑战。

受众信任度调查
BBC另一项研究显示，许多用户信任AI助手的新闻摘要准确性（超过三分之一的英国成年人信任AI总结，35岁以下人群中近半数）。但实际错误率高，且用户错误归咎于新闻机构和AI开发者，可能损害公众对新闻媒体的信任。

参与机构
研究涵盖18国24家公共服务媒体，包括BBC（英国）、RTBF/VRT（比利时）、CBC（加拿大）、ARD/ZDF/德意志之声（德国）、RTVE（西班牙）等。

用55美元/月的服务器取代3000美元/月的Heroku账单

文章标题清晰地指出了核心内容：一项将原本每月高达3000美元的Heroku云平台服务费用，成功替换为每月仅需55美元的服务器方案的实践案例。

关键信息点：

• 成本对比：迁移前每月成本为3000美元（Heroku），迁移后每月成本降至55美元。
• 服务提供商：Heroku 是知名的云平台即服务提供商。
• 可能的组织：从提供的链接路径推测，该案例可能与 idealist.org 这个组织有关。
• 技术决策：这表明该组织通过技术架构调整或基础设施迁移，实现了巨大的成本节约。

注意：提供的具体内容仅包含一个指向新文章位置的链接，因此详细的技术方案、实施过程及具体收益等信息需访问该链接获取。

谷歌Willow量子芯片首次实现硬件上的可验证量子优势

谷歌宣布其Willow量子芯片成功运行了首个可验证的量子优势算法，在硬件上超越了最快的超级计算机。该算法名为Quantum Echoes（基于失序时间相关器算法），可在Willow芯片上以比超级计算机快1.3万倍的速度计算分子结构，为量子计算的实际应用铺平道路。

核心突破与算法原理

• 可验证的量子优势：Quantum Echoes算法的结果可在同类量子计算机上重复验证，实现了可扩展的验证机制，这是量子计算机迈向实用工具的关键一步。
• 算法原理：该算法通过向量子系统发送精心设计的信号，扰动一个量子比特，然后反向演化信号，利用量子波的建设性干涉放大回波信号，从而实现高精度测量。
• 硬件基础：Willow芯片的极低错误率和高速操作支撑了算法的实现，2024年该芯片已在随机电路采样基准测试中展现突破性纠错能力。

实验验证与应用前景

• 分子结构分析：与加州大学伯克利分校合作，Willow芯片通过Quantum Echoes算法分析了15原子和28原子的分子结构，结果与传统核磁共振（NMR）一致，并提供了通常无法获得的信息。
• 未来应用场景：
  • 药物发现：辅助确定药物分子与靶点的结合方式。
  • 材料科学：表征聚合物、电池组件等新材料的分子结构。
  • 基础研究：拓展对分子、磁体乃至黑洞等自然系统的理解。
• 技术愿景：谷歌将该技术比作“量子显微镜”或“量子望远镜”，未来可发展为量子探测器，观测此前无法测量的自然现象。

技术里程碑与后续计划

• 历史意义：此次演示是量子计算机首次在硬件上运行可验证且超越经典计算的算法，标志着量子计算向实用化迈出实质一步。
• 后续目标：谷歌将专注于实现量子硬件路线图中的第三个里程碑——创建长寿命逻辑量子比特，为规模化、纠错的量子计算机奠定基础。

本文介绍了从零开始构建键值数据库的步骤和核心概念。主要内容如下：

1. 基本方案与问题：最初可使用文件存储键值对，通过遍历文件进行查找。但原地更新和删除操作效率低下，因为需要移动后续数据。

2. 追加写入文件：为解决更新效率问题，采用追加写入模式，所有更新和删除都视为新记录添加到文件末尾。删除通过插入“墓碑”记录（如空值）实现。查找时需从后向前扫描以找到最新记录。此方案避免了数据移动，但带来了新问题：

   • 文件无限增长：旧记录和无效记录堆积，文件体积不断增大。
   • 搜索速度慢：查找需遍历整个文件，性能差。

3. 分段与压缩：为解决文件增长问题，引入分段机制。当文件达到一定大小后，停止写入并创建新文件。同时，定期对旧文件进行压缩，移除重复和已删除的记录，并可将多个小文件合并。此机制控制了磁盘空间占用。

4. 建立索引以加速搜索：为解决搜索慢的问题，在内存中建立索引（如哈希表）。索引存储每个键在文件中的偏移量，从而实现快速查找。但存在权衡：

   • 写入变慢：每次写入需同时更新索引。
   • 内存限制：所有键必须存于内存，限制了数据集大小。
   • 范围查询效率低：哈希表索引对范围查询帮助不大。

5. 有序数据与优化：通过确保数据按键排序，可以：

   • 支持高效范围查询。
   • 使用稀疏索引：无需为每条记录存索引，只需存储部分键的偏移量，利用排序特性缩小查找范围。这实现了内存使用与查询速度的灵活权衡。

6. 实现排序的实践（LSM树）：磁盘数据难以直接排序。解决方案是：

   • 在内存中使用有序数据结构（如跳表）维护一个“内存表”。
   • 同时将操作日志写入追加文件以保证持久化。
   • 当内存表达到阈值后，将其内容按序写入磁盘，形成不可变的排序字符串表。
   • 查找时依次检查内存表、最新磁盘文件、次新文件等。
   • 此过程即日志结构合并树 的核心思想。

7. 总结与现状：上述从追加写入、分段压缩、到内存排序与磁盘排序表的组合方案，构成了LSM树。它被广泛用于高性能键值数据库（如LevelDB、DynamoDB），能支持极高的写入吞吐量。文章同时指出，关系型数据库常使用B-Tree等不同结构。

格陵兰加强互联网连接，无需美国帮助

背景与需求

格陵兰的东和北地区面临互联网连接缓慢或不可靠的问题，这影响教育、健康和安全。许多城镇和定居点缺乏水下电缆或无线电链路，亟需改善。

协议签署

格陵兰国家电信公司 Tusass 与法国公司 Eutelsat 签署新协议，通过 OneWeb 卫星提供卫星互联网服务。该协议旨在为偏远地区带来更快、更稳定的覆盖。

技术优势

• OneWeb 卫星：轨道更接近地球，提供更快、更可靠的信号，优于传统卫星。
• 服务目标：连接孤立社区，支持关键基础设施，并改善海事安全和救援操作。

受益地区

• 首批受益地区包括 Tasiilaq、Ittoqqortoormiit 和 Qaanaaq 等偏远定居点。
• Tasiilaq 预计在年底前获得接入，其他社区将随网络扩展而跟进。

合作选择

• Tusass 曾考虑与 Starlink（由埃隆·马斯克所有）合作，但最终选择继续与 Eutelsat 合作。
• 决策基于 信任和长期合作，而非技术优劣，因为 Tusass 与 Eutelsat 已有成熟系统协作。

控制权与国家安全

• 格陵兰政客警告必须保持电信基础设施的 国家控制，担心外国提供商可能威胁安全。
• 目前，Tusass 是格陵兰唯一的电信提供商，确保通信系统处于格陵兰控制之下。
• 公司对未来合作保持开放，但 优先维护格陵兰主权。

总结

该协议标志着格陵兰通过卫星技术缩小数字鸿沟，在保持国家控制的前提下提升偏远地区互联网连接质量。

OpenBSD 7.8 版本摘要

OpenBSD 7.8 是该项目的第59个版本，于2025年10月22日发布。该版本在系统各个方面带来了显著改进和新功能，延续了其30年来默认安装仅出现两个远程漏洞的卓越安全记录。

主要更新亮点

1. 平台与内核改进

• arm64架构：新增对Raspberry Pi 5（串行控制台）的支持，并实现 acpicpu(4) 驱动。
• SMP改进：网络栈并行化取得重大进展，包括TCP处理、IPv6分片重组等现在可使用多CPU（最多8个线程）并行运行，显著提升高并发性能。
• 内核优化：改进了 witness(4) 的锁嵌套处理、mtx_enter() 在大量CPU机器上的性能，并将内核休眠时间参数改为纳秒以提高精度。
• 文件系统：提升了FUSE文件系统与Linux libfuse 的兼容性。

2. 暂停/休眠与SMP

• 电源管理：修复了多项笔记本电脑（如ThinkPad Z13）的挂起/恢复问题，并实现了AMD CPU的S0ix挂起支持。
• 网络并行：softnet 线程数增加（最多8个），TCP协议栈、IPv6分片重组和选项处理均已并行化，close(2) 和 listen(2) 系统调用不再需要独占网络锁。

3. 驱动与硬件支持

• 图形：DRM驱动更新至Linux 6.12.50，新增Qualcomm Snapdragon (qcdrm(4)) 和DisplayPort (qcdpc(4)) 驱动。
• 虚拟化：VMM/VMD支持AMD SEV-ES技术，可运行机密虚拟机。
• 网络驱动：为 ice(4) (Intel E810) 启用RSS、多队列和软件LRO；更新 rge(4) 以支持Realtek RTL8125D/RTL8127；新增 erspan(4) 隧道驱动。
• 无线：qwx(4) 支持802.11n/HT和漫游；修复 iwx(4) 对部分Intel AX210设备的支持。
• 其他：新增对Raspberry Pi 5的众多外围控制器驱动。

4. 安全增强

• pledge：允许在 "stdio" 承诺中进行低风险的 getsockname()/getpeername() 和TOS设置操作，以减少攻击面。
• 内存安全：在64位架构上引入内核栈与PCB之间的未映射保护页。
• 后量子密码：OpenSSH客户端连接若协商使用非后量子安全的密钥交换算法，现在会发出警告。

5. 用户空间与工具

• 新工具：导入 watch(1) 周期性执行命令；新增 lldpd(8) (LLDP守护进程) 和 bpflogd(8)。
• 磁盘工具：fdisk(8) 和 disklabel(5) 获得多项增强，如GPT备份/恢复、交互式编辑改进。
• 性能：pkg-config 切换至性能更好的C语言实现 pkgconf。

6. 网络与防火墙

• pf：放宽了对TCP RST包的检查，修复了“least-states”负载均衡问题。
• 性能：为 bnxt(4), ice(4), ixl(4) 等驱动实现了软件TCP大段接收卸载。
• 路由：新增 erspan(4) 驱动；ARP和ND6列表使用迭代器以实现多处理器安全。

7. 主要组件更新

• LibreSSL 4.2.0：内部重大改进，包括常数时间椭圆曲线运算、CPU能力检测机制重构，并开始支持ML-KEM。
• OpenSSH 10.2：
  • 安全：禁止在用户名中包含控制字符，防止命令注入。
  • 变更：将代理监听套接字默认路径从 /tmp 移至 ~/.ssh/agent 以增强安全；弃用旧的IPQoS关键字。
  • 新功能：支持PKCS#11上的ed25519密钥；ssh_config 新增 RefuseConnection 选项。

8. 包与生态系统

• 预编译包数量持续增长，例如 amd64架构有12651个包。
• 提供了众多流行软件的更新版本，如Firefox 143、Chromium 141、LLVM/Clang 19/20/21、PostgreSQL 17.6、Python 3.12.11等。

9. 安装与升级

• 安装程序默认偏好大于1GB的磁盘作为根盘。
• 提供了详细的HTTPS安装镜像列表和说明。

此次发布巩固了OpenBSD在安全性、可靠性以及现代硬件支持方面的地位，特别是在网络并行处理和虚拟化安全（SEV-ES）方面取得了重要进展。

MinIO 的某个 GitHub 仓库于 2026 年 4 月 25 日被所有者归档，现在处于只读状态。有一个关联的 issue（#21647）讨论了 Docker 镜像的发布问题。用户指出，安全版本 RELEASE.2025-10-15T17-29-55Z 的 Docker 镜像在 quay.io 或 DockerHub 上未找到，并询问这是否是预期行为，如果不是，能否为该安装方法推送新版本。这暗示 MinIO 可能转变为仅源代码发布模式，影响了 Docker 镜像的可用性。

AWS宕机事件影响：智能床垫失控

2025年10月20日凌晨，亚马逊云服务（AWS）在美国东部（US-EAST-1）区域发生大规模故障，导致错误率和延迟增加。此次宕机波及广泛，影响了Snapchat、Roblox、Fortnite等游戏与社交平台，以及银行应用等多个互联网服务，Downdetector记录到超过800万份报告。

智能床垫的“罢工” 在此期间，高端智能床垫品牌Eight Sleep的Pod3床垫套用户遭遇了严重问题。这些售价超过2000美元的设备，主打AI驱动的睡眠监测、心率追踪、睡眠阶段分析和水冷线圈温度自动调节功能，但完全依赖云服务器运行。由于没有离线模式，AWS故障导致：

• 温度控制失效：用户无法通过应用调节温度，床垫卡在故障前的设定状态。有用户Alex Browne将床垫预设为比室温高9°F的加热模式，故障后无法切换至制冷，导致其在“桑拿”中度过一夜。
• 睡眠监测中断：实时睡眠数据、阶段记录和生物特征洞察完全停止。
• 自动化功能瘫痪：如“准备睡眠”等定时预设因需要云端连接而失效。
• 物理控制失灵：设备上的触摸面板反应迟钝或出现故障，部分用户报告设备完全“变砖”，需云端授权才能重启。

用户反应与公司回应 用户在Eight Sleep的支持网站和社交媒体上大量投诉，凸显了对昂贵“智能”设备在关键时刻失灵的不满。Eight Sleep随后确认其系统暂无离线模式，但表示“正在修复”。此前，该公司还曾因AWS密钥暴露等安全漏洞面临审查，引发对数据隐私的担忧。

事件启示 此次宕机是智能家居物联网脆弱性的一个缩影——AWS支撑着从Ring门铃到Alexa插头等大量设备。事件凸显了过度依赖云端服务的风险：一旦网络或服务器出现问题，基础功能可能完全丧失。这迫使用户和制造商思考智能设备的可靠性设计，尤其是离线备用方案的必要性。

本文探讨了程序员身份认同的演变与危机，核心围绕编程作为一门技艺（craft）的消长，以及AI（尤其是大型语言模型LLM）崛起对其带来的根本性挑战。

文章以作者对编程的沉浸式体验开篇，将Vim编辑器比作工作室，将编码描述为一种带来心流（flow）状态的创造性技艺。随后回溯至1950年代麻省理工学院的黑客文化起源，强调了编程的初心：对“完美之物”（The Right Thing）——即优雅、简洁、完美程序的追求，以及基于“黑客伦理”的探索、分享与技艺锤炼。

作者指出，这种技艺和身份如今正受到威胁。AI行业、技术社区及企业管理层正在推动一种新的工作范式——“氛围编码”（vibe-coding），即用自然语言（如Markdown）编写规格说明，由AI代理完成核心编码工作。这被视为一种身份的转变，从创造性的工匠变为“规格工程师”或操作员。作者担忧，这导致了技艺的贬值，将程序员推入了产品经理和设计师已有的领域，并剥夺了编程中深度思考、沉浸式解决问题的核心乐趣。

在企业内部，管理层强制使用AI工具，改变了权力动态，削弱了程序员对其工具链（曾视为技艺一部分）的自主权。尽管有人将LLM类比为从汇编到高级语言的飞跃，但作者认为这是错误的：高级语言建立在编程技艺之上，追求精确性；而LLM基于自然语言，本质不精确、不可预测，与编程所崇尚的确定性、可组合性相悖。

文章深入分析了依赖LLM带来的认知代价。作者自述，审查AI生成的代码时难以投入，导致对代码库的理解流于表面，无法建立如计算机科学家彼得·瑙尔（Peter Naur）所说的“理论构建”（Theory Building）——那种通过沉浸获得的对系统深层含义的掌握。而好的设计本源于沉浸、迭代和对不佳方案的切身体验，AI的“无摩擦”工作流可能阻碍这一过程。

此外，AI辅助开发也侵蚀团队协作。代码审查变得痛苦且单向，同事可能对AI生成的错误代码不负责；配对编程和人际知识分享可能被与机器的交互取代，导致工作者孤立。

最后，作者表明立场：他珍视程序员的技艺身份，渴望深度参与解决问题，而非成为被动的操作员或代码审查员。他认为LLM像一种“从轨道上轰炸”的解决方案，未触及软件开发复杂性的根源，却可能让我们付出思维能力、工作乐趣、技艺传承、隐私甚至环境的代价。他希望工具能辅助重复性工作，但不应剥夺人对软件的理解权和创造中的主体性。

格雷格·纽比博士（Dr. Gregory B. Newby）在短暂抗癌后不幸离世。纽比博士曾担任古腾堡计划文学档案基金会（Project Gutenberg Literary Archive Foundation）首席执行官逾二十年，并与分布式校对组织（Distributed Proofreaders）紧密合作，同时他也是分布式校对基金会（Distributed Proofreader Foundation）董事会的投票成员。

他生于加拿大，成长于美国，后返回加拿大为育空地区政府工作，同时继续指导古腾堡计划。

在近期的一次采访中，纽比博士讲述了他作为一名终身读者，如何在1987年因收到一本通过电子邮件发送的《爱丽丝梦游仙境》而对电子书的潜力感到兴奋——“我立刻意识到这将是多么巨大的变革”。他深切关注古腾堡计划的使命，并表示：“这激励着我……产生积极影响，将所有这些文学作品送到人们手中。”

2023年，纽比博士与微软和麻省理工学院合作，推出了“古腾堡计划开放有声书集”（Project Gutenberg Open Audiobook Collection），该项目由AI语音朗读，被《时代》杂志评为“2023年最佳发明”之一。

在他的远见领导下，古腾堡计划提供的电子书（其中许多由分布式校对组织制作）已增长到超过75,000本。

纽比博士及其对古腾堡计划的不懈领导，曾是分布式校对组织的紧密合作伙伴，他的离去令人深感惋惜。

官方公告已发布。

公众信任要求投票系统开源

事件背景 美国第二大投票系统供应商Dominion Voting Systems已被新公司Liberty Vote收购。Dominion此前统计了美国五分之一的选票。Liberty Vote宣称其使命是“恢复对美国选举的信心”。

核心问题：选举信任危机 美国选举正面临严重的信任危机。修复选民信任需要一种新策略，这对美国的自由与民主至关重要。

解决方案：透明度与开源软件

1. 透明度的现实落差：尽管所有投票机供应商都声称透明，但大多数美国人投票所用的机器实际上运行的是专有、不公开的软件。
2. 开源作为信任基础：能够赢得公众信任的投票系统必须运行完全对公众审查开放的软件。开源是现代公共信任和高安全性软件的标准（例如Signal加密通讯软件）。美国军方也推荐使用开源软件。
3. 呼吁行动：文章呼吁Liberty Vote及其他所有美国投票机供应商，通过将其技术开源来兑现其透明度承诺。若所有供应商都能抓住此机会，共同开启新一代所有美国人都能信任的投票系统。

实例参考 文中指出，目前美国唯一的开源投票设备供应商是VotingWorks。文章提供了该公司的网站、源代码仓库及联系方式作为参考。

该内容描述了一个末日主题计分板（Doomsday Scoreboard） 的界面设计布局。其主要组成部分包括：

• Scoreboard（计分板）：作为主页面或核心展示区域，可能用于显示关键的末日相关数据或排名。
• Timeline Stats（时间线统计）：该部分负责展示随时间变化的统计数据或历史记录。
• Doomsday Dashboard（末日仪表盘）：一个集中监控界面，用于展示与末日预测相关的各项关键指标和状态。
• Predictions Listing（预测列表）：以列表形式呈现各种末日场景或事件的预测信息。

整体结构表明这是一个集数据展示、趋势分析和预测信息于一体的综合性末日主题信息看板。

Iceland’s frozen, inhospitable winters have long protected it from mosquitoes, but that may be changing. This week, scientists announced the discovery of three mosquitoes — marking the country’s first confirmed finding of these insects in the wild.

https://www.bloomberg.com/news/articles/2025-10-22/tesla-recalls-almost-13-000-evs-over-risk-of-battery-power-loss

Linux Capabilities 再探

核心概念 Linux Capabilities 是一种细粒度的访问控制机制，旨在将传统的 root 用户超级权限拆分为多个独立的权限单元。其目标是：当拥有某些 capability 的程序被攻陷时，其造成的系统损害范围小于以完整 root 权限运行的相同程序，从而实现更安全、可控的权限管理。

基本操作与检测

• 查看能力：可通过 cat /proc/sys/kernel/cap_last_cap 查看系统支持的能力数量，使用 capsh --print 查看当前 shell 进程的完整能力集合。
• 设置能力：使用 setcap 命令为可执行文件添加能力。例如，setcap cap_setuid+ep /usr/bin/python3.12 为 Python 二进制文件添加了 cap_setuid 能力，其中 e 表示“有效”，p 表示“许可”。
• 漏洞利用示例：为 Python 设置 cap_setuid 能力后，非特权用户可通过执行 python3 -c 'import os; os.setuid(0); os.system("/bin/bash")' 获得一个 root shell，而无需设置传统的 SUID 位。这展示了如何利用 capabilities 创建隐蔽的后门。
• 枚举与移除：使用 getcap -r / 可递归搜索系统中所有设置了能力的文件。使用 setcap -r <文件路径> 可移除文件上的能力设置。

能力的存储与状态

• 存储位置：文件能力（如通过 setcap 设置）存储在文件的 inode 中，与扩展属性（如 ACL）共存。标准 ls 命令无法显示它们，需使用 getcap 或 getfattr 查看。
• 进程状态：进程的能力状态可通过 /proc/<PID>/status 文件中的特定字段（如 CapEff 有效能力集、CapBnd 边界集等）查看，或使用 capsh --decode 和 getpcaps <PID> 命令解码。

安全检测与监控

• 传统检查：在查找 SUID/SGID 文件的同时，必须同等重视查找设置了特定能力的文件。
• 专用工具：LinPEAS 等自动化枚举工具已包含对进程状态及文件系统中隐藏能力的检查。
• 监控规则：安全产品（如 Elastic）可配置规则来检测 setcap 工具的使用，以发现可能的能力后门设置行为。

结论 虽然检查 SUID/SGID 文件依然重要，但现代安全实践必须将搜索已设置特定能力的文件纳入常规审计。Capabilities 提供了一种更精细且可能更隐蔽的权限授予方式，若忽视其监控，会引入显著的安全风险。递归使用 getcap 等工具进行全面检查，是缓解相关利用途径的关键。

Starcloud 太空数据中心计划摘要

核心概念

Starcloud 是一家加入 NVIDIA Inception 初创企业计划的公司，其核心目标是在外太空构建先进的数据中心，以应对地球数据中心日益增长的能耗与冷却需求。

关键优势

• 能源成本与可持续性：太空可提供近乎无限、低成本的可再生能源（太阳能）。项目预计太空数据中心的能源成本将比陆地低 10 倍，且在整个生命周期内可减少 10 倍的二氧化碳排放。
• 冷却方式创新：利用深空真空作为无限散热器，通过红外辐射散热，无需消耗地球上的淡水资源进行冷却，显著节约水资源。
• 实时数据处理：在数据产生的源头（太空）直接进行推理和处理，可将地球观测等关键应用的响应时间从数小时缩短至几分钟。

具体计划与里程碑

• 近期发射：计划于 2024 年 11 月发射 Starcloud-1 卫星（约冰箱大小，重 60 公斤）。这将是 NVIDIA H100 GPU 首次进入太空，其计算能力预计比以往任何太空操作强大 100 倍。
• 远期目标：计划建造一个约 4 公里宽的 5 吉瓦轨道数据中心，配备超大型太阳能电池板和冷却面板。创始人预测，十年内几乎所有新建数据中心都将建在外太空。

主要应用场景

1. 地球观测数据分析：用于农作物识别、局部天气预测等。
2. 关键应急响应：实时处理用于野火探测和求救信号响应的数据。
3. 大规模成像处理：尤其适用于处理合成孔径雷达（SAR）等产生的海量数据（约每秒 10 吉字节），用于生成高分辨率三维地球地图。

技术选择与合作伙伴

• NVIDIA GPU：公司选择 NVIDIA 加速计算，因其在训练、微调和推理任务上性能最佳，能够确保太空数据中心处理的工作负载具有竞争力。
• NVIDIA Inception 支持：该项目为 Starcloud 提供了关键的技术支持、专家资源和 GPU 获取途径。

（总结基于提供的文章内容，未包含任何个人观点或外部信息。）

Magit 的卓越之处

作者近期阅读关于 Jujutsu 版本控制系统（VCS）的文章时，反而更深刻地认识到 Magit 的强大。尽管 Jujutsu 近期受到一定关注（例如被提及了5次左右），且文章重点对比了其相对于 Git 的灵活性，但作者发现自己对 Git 命令行界面（CLI）的使用非常有限，几乎完全依赖 Magit 进行版本控制操作。

文章指出，作者甚至曾认为 Jujutsu 文章中描述的某些功能在 Git 中也能轻松实现，随后意识到这是因为自己一直通过 Magit 与 Git 交互。作者反思，如果最初先学习 Git CLI 再转向 Magit，可能会更理解其命名由来，但也承认若非 Magit，可能不会在职业生涯早期就熟练掌握 Git 命令（如 stash 操作），甚至在同事尚在为此挣扎时就能自如切换分支。

因此，尽管 Jujutsu VCS 或许有其优势，但这篇文章无意中强化了作者对 Magit 的赞赏，并暂时削弱了其尝试 Jujutsu 的动力。全文主要强调了 Magit 作为 Git 交互界面的高效与便利性，以及作者对其高度依赖的个人体验。

• 研究主题：直肠递送氧气（EVA）作为一种潜在的医疗治疗方法，用于严重呼吸衰竭患者，以避免机械通气可能带来的肺损伤。
• 动物实验背景：此前研究使用氧气气体或氧合全氟化碳液体对啮齿动物和猪进行直肠灌注，在诱导呼吸衰竭后，发现两种疗法都能有效延缓衰竭且无重大并发症，并因此获得2021年搞笑诺贝尔奖。
• 人体试验进展：最新研究招募了27名日本健康成年男性，通过直肠给予非氧合的全氟萘烷液体。参与者需保留液体1小时，剂量从25毫升逐步增至1500毫升。20人成功完成实验。
• 安全性结果：参与者仅出现轻微、暂时性的腹部胀气和不适，这些反应与剂量相关，无需医疗干预，未报告其他不良反应。
• 研究意义与局限性：这是首项人体数据，主要目的是验证该方法的安全性，而非有效性。安全性的建立为下一步评估其向血液输送氧气的实际效果奠定了基础。
• 后续方向：下一步将评估EVA在向血液输送氧气方面的有效性，以判断其作为呼吸衰竭患者辅助治疗的可行性。

文章讲述了作者为发酵食品开发软件的经历与思考。核心观点是：设计用于处理“会腐烂事物”的软件，应侧重于追踪、上下文关联和风险管理，而非追求绝对的精确性。

作者最初将发酵视为烹饪，但一次自制意大利萨拉米香肠的经历让他意识到问题。由于无法准确判断香肠上的霉菌是否安全，他意识到需要像对待基础设施一样严肃地对待发酵过程。为此，他构建了一个可控的发酵箱，并利用Home Assistant进行温湿度监控，但这仅提供了数据，缺乏解读数据的上下文。

关键的启发来自食品工业的HACCP（危害分析关键控制点）体系。作者发现，这不是官僚文书，而是一个优雅的决策树框架，用于识别潜在危害、设定关键限值并制定监控程序。例如，对于‘nduja香肠，其关键控制点是48小时内pH值必须降至5.3以下，否则需丢弃。

受此启发，作者开发了一款名为“Fermento”的iOS应用。该应用的核心设计是：

1. 状态机模型：将发酵过程分为发酵、干燥、熟成等阶段。每个阶段拥有不同的约束条件（如pH、湿度、温度、失重率）及其可接受范围和检查时间窗口。
2. 上下文感知：应用会根据当前所处阶段，仅加载并验证该阶段相关的约束条件，而非检查所有指标，提高了效率。同时，它管理着一个待办任务列表以跟踪时间绑定的检查项（如“在48小时检查pH值”）。
3. 自动化与记录：应用能基于记录的数据自动生成符合HACCP标准的文档。作者强调，软件的价值在于提供“可追溯性”，而非绝对精确。一个记录着“忘记测pH，但气味正常”的批次，其观察本身就是有价值的数据。

文章指出，发酵是一个“受控漂移”的缓慢变化过程，软件需优化对变化趋势、记忆和时机的把握，而非追求生产环境的确定性。例如，持续一周的0.5°C温度漂移比短暂的温度峰值更重要，且过程无法回滚。

最终，Fermento被设计成一个可伸缩的工具：对于低风险的发酵（如康普茶、泡菜），它只是一个带提醒的日记；对于高风险的长时或低酸发酵，其内置的HACCP决策树能有效管理安全风险。即使作者移居后设备简陋，这些记录习惯依然适用。软件的核心理念是：在软件开发中，最难的并非维持事物存活，而是知晓何时让它们自然熟成。

法国前总统萨科齐因竞选资金阴谋案开始服刑

法国前总统尼古拉·萨科齐因阴谋通过已故利比亚领导人穆阿迈尔·卡扎菲提供的资金为其竞选活动提供资金，于2025年10月21日开始服刑五年，成为首位入狱的法国前总统。这是自1945年二战期间与纳粹合作的领导人菲利普·贝当因叛国罪入狱以来，首次有法国前领导人被监禁。

案件与判决：

• 萨科齐在2007年总统竞选期间被指控接受了来自卡扎菲政权的数百万欧元非法资金。
• 尽管他个人收受资金的罪名被洗清，但法院认定他与两名亲信——布里斯·奥尔特弗和克洛德·盖昂——存在刑事共谋，罪名成立。
• 萨科齐始终否认指控，并已对判决提出上诉。

入狱与服刑情况：

• 70岁的萨科齐被送入巴黎南部著名的桑特监狱。
• 他被关押在监狱的隔离区，主要出于安全考虑。他的牢房面积约9至11平方米，配备基本设施。
• 他每日仅有一小时在隔离区内单独放风，实质上处于单独监禁状态，社交联系受到严格限制。
• 其律师已提交释放请求，预计他将在狱中至少待三到四周。

各方反应：

• 萨科齐本人：坚持自己是无辜的，在前往监狱途中于社交媒体发文称“被关进监狱的不是一位前总统，而是一个无辜的人”，并表达了对法国“受复仇欲羞辱”的悲伤。
• 支持者：超过百人在其巴黎住所外为他送行。
• 官方态度：现任总统埃马纽埃尔·马克龙在萨科齐入狱前于爱丽舍宫接待了他，并表示理解此事在法国引发议论。司法部长热拉尔德·达尔马宁也表示将前往监狱探视，以确保其安全和监狱正常运转。

背景与相关法律进程：

• 自2012年离任后，萨科齐长期受到刑事调查困扰，此前已因另一起贿赂法官案被判佩戴电子镣铐。
• 下月底，法国最高行政法院将就他另一起名为“比格马利翁案”的非法竞选资金案上诉作出判决。
• 萨科齐表示不畏惧入狱，并带了两本书进入监狱，其中一本是讲述被冤枉入狱并复仇的《基督山伯爵》。

核心摘要：

OpenAI发布了视频生成模型Sora 2及其配套社交应用，该应用模仿TikTok，允许用户通过文本生成短视频并消费他人内容。然而，应用内生成的内容多为低质量或道德存疑的视频，且生成成本高昂（用户需支付订阅费），远不如TikTok等竞争对手免费且高效。

文章指出，OpenAI此前将自身技术比作“原子弹”般变革性，但如今却转向追求广告变现和低龄化内容（如考虑推出成人向AI生成内容）。这种转变揭示了OpenAI战略的重大调整：尽管投入巨资，其技术尚未达到颠覆经济的预期效果，因此公司正从宏大愿景转向商业化盈利模式，专注于短期收益而非重塑世界。

根据提供的内容，文章标题为《Democracy and the open internet die in daylight》，但文章正文仅显示一条访问限制通知：内容对当前地理位置不可访问，并提示具有管理权限的用户输入邮箱以获取解锁说明。无法获取文章的实质内容，因此无法对文章主旨、论点或具体细节进行摘要。

事件背景
美国东区弗吉尼亚州代理检察官林赛·哈利根（Lindsey Halligan）在10月11日突然通过加密通讯软件Signal联系《法律战》（Lawfare）记者安娜·鲍尔（Anna Bower），批评她关于纽约州总检察长莱蒂西亚·詹姆斯（Letitia James）案的推文。哈利根由特朗普总统任命，此前缺乏检察经验，正负责对詹姆斯和前FBI局长科米的刑事起诉。

通信核心争议

1. 记者推文内容：鲍尔援引《纽约时报》报道称，詹姆斯的侄孙女娜基亚·汤普森（Nakia Thompson）在大陪审团中作证多年未付租金，质疑检方指控詹姆斯将房产用作“投资租赁”而非“第二住所”的核心主张。
2. 哈利根的批评：哈利根声称鲍尔的报道“不准确”，但未具体说明错误所在，仅暗示《纽约时报》披露了大陪审团信息（受联邦规则保护）。她引用起诉书称詹姆斯曾申报“数千美元”租金收入，但未解释这与汤普森证词的矛盾。
3. 规则争议：检察官通常不得公开大陪审团信息，而哈利根在交流中多次涉及相关内容，却坚称“不能透露”。她事后声称对话“非公开”，但通信全程未预先约定保密条款。

异常行为与职业规范

• 哈利根主动联系记者讨论案件，使用阅后即焚功能，且未明确沟通记录性质。
• 多名前联邦官员和法律记者表示，现任检察官就此类敏感案件直接联系记者极为罕见。
• 哈利根曾因涉嫌向媒体泄露信息解雇下属，其行为与司法部“零容忍泄露政策”形成矛盾。

司法部回应
司法部发言人纳塔莉亚·巴尔达萨雷（Natalie Baldassarre）证实短信真实性，指责鲍尔“因未获得未经调查的信息而向总司法部告密”，并称哈利根旨在“指出事实而非八卦”。哈利根在文章发布前突然再次联系鲍尔，要求将所有通信视为“非公开”，但鲍尔指出未经事先同意的保密要求无效。

事件意义
此次交互凸显了特朗普任命的检察官在政治敏感案件中可能存在的越界行为，以及对司法独立性和检察伦理的潜在挑战。哈利根既批评记者“未独立调查”，又拒绝提供具体澄清，引发对案件合法性和调查过程的质疑。

与Claude共处险境：编程代理的自由与风险权衡

核心矛盾

作者在Claude Code爱好者聚会上探讨了一个核心困境：一方面，尽可能少限制地运行编码代理（如启用“YOLO模式”）能带来巨大价值；另一方面，这种自由伴随着严重的安全风险。

YOLO模式的价值

• 定义与体验：--dangerously-skip-permissions（YOLO模式）让Claude Code从需要持续监控的工具，转变为可独立解决复杂问题的自主代理。
• 效率示例：作者在48小时内利用YOLO模式完成了三个“副业”项目：
  1. 在NVIDIA Spark上部署DeepSeek-OCR：通过SSH连接，让Claude Code自主解决在ARM64设备上运行PyTorch/CUDA的难题，耗时约40分钟。
  2. 在WebAssembly沙箱中运行Python：利用Claude Code研究Pyodide在Node.js中的实现，并建立了实验记录仓库。
  3. 在浏览器中运行Perl代码：让Claude Code将25年前的Perl工具SLOCCount及其C依赖编译为WebAssembly，实现浏览器端运行。
• 核心优势：这些项目展现了YOLO模式在并行处理复杂、非优先任务时的强大能力，用户可同时专注于其他工作。

风险与安全问题

• 主要威胁：提示注入：这是一种利用不可信内容与可信指令拼接来攻击LLM的漏洞，已存在多年且非常普遍。
• 致命三角：当LLM系统同时具备访问私有数据、接触不可信内容和外部通信能力时，攻击者可能诱骗系统泄露私有数据。
• 根本原则：任何能将其标记注入上下文的人，都可能实际控制代理后续行为及工具调用。
• 防护局限性：依赖更多AI来检测攻击并非100%可靠，不能作为有效的安全防御。

安全解决方案：沙箱

• 最佳实践：在隔离环境中运行代理，即使被攻陷，损失也仅限于该环境。
  • 云端沙箱：如OpenAI Codex Cloud、Claude Code for web、Gemini Jules等，风险转嫁给托管方。
• 沙箱关键控制点：
  1. 文件系统访问：控制可读写的文件。
  2. 网络连接：更为困难但至关重要，是阻断数据外泄的关键。通过限制网络通信，即使攻击者注入恶意指令，也无法窃取信息。
• 最新技术进展：Claude Code CLI近期引入了沙箱功能，其macOS实现依赖于Apple的sandbox-exec命令，可通过策略文件控制文件可见性和网络连接（通过HTTP代理白名单域名）。尽管sandbox-exec已被苹果标记为弃用，但目前仍是便捷的解决方案。

结论

作者鼓励用户“大胆冒险”（充分利用YOLO模式的效率），但必须“在沙箱中冒险”，以平衡生产力与安全性。

Cloudflare Circl FourQ 实现中的密码学问题 (CVE-2025-8556)

发现与报告

2025年初，在对开源椭圆曲线实现进行广泛审计时，发现了 Cloudflare 的 CIRCL 库在 FourQ 椭圆曲线实现中存在若干密码学问题。研究人员于2025年3月通过 HackerOne 漏洞赏金计划报告了这些问题，在收到初步回应后直接联系了 Cloudflare。在 Cloudflare 团队介入后，问题得到正式确认并修复。

FourQ 与 CIRCL 简介

CIRCL 是 Cloudflare 的密码学库，提供了 FourQ 曲线的基础实现以及名为 Curve4Q 的 Diffie-Hellman 共享密钥功能。FourQ 是一个提供128位安全性的椭圆曲线，由微软研究院开发，基于扭曲爱德华兹曲线方程。该曲线定义在基于梅森素数 (p = 2^{127} - 1) 的二维扩展素域上，扭曲参数 (a = -1)，(d) 为二次非剩余。其元素形式为 (a + bi)（(a, b) 为模 (p) 整数）。FourQ 还定义了两个自同态，利用这些特性和曲线结构可以实现高效计算，适用于嵌入式系统等资源受限场景。

无效点攻击与退化曲线攻击

无效点攻击（针对魏尔斯特拉斯曲线）

这类攻击源于对用于计算的点验证不足。在椭圆曲线 Diffie-Hellman（ECDH）中，双方使用私有标量 (k) 与生成点 (G) 计算公钥 (Q = k*G) 并交换。若服务器未验证接收到的点是否在曲线上，攻击者可迫使服务器使用属于具有光滑（小因子组成）子群阶 (\widehat{N}) 的无效点 (\widehat{Q}) 进行计算。这使得标量乘法结果落入较小的点集，攻击者可通过暴力破解或结合中国剩余定理逐步恢复服务器的私有标量 (k)。

退化曲线攻击（针对爱德华兹曲线）

虽然爱德华兹曲线与魏尔斯特拉斯曲线双有理等价，但爱德华兹加法公式依赖曲线参数 (a) 和 (d)，使得传递任意无效点并正确执行加法变得困难。然而，若传递形式为 ((0, y)) 的点（x 坐标为0），则曲线参数在计算中被抵消，退化为对爱德华兹曲线普遍有效的攻击。此时计算 ((0, y^k))，若 (y) 具有小乘法子群阶，则离散对数问题变得容易解决。

CVE-2025-8556 具体问题

审计发现 CIRCL 的 FourQ 实现存在7个相关问题，以下为4个主要漏洞：

1. Point.Unmarshal 中的点验证错误：IETF 规范要求反序列化时先检查点是否在曲线上，若失败则对 (x) 取共轭并重新检查。CIRCL 实现在取共轭后未重新验证点是否在曲线上。
2. pointR1.isEqual 的比较错误：该函数在投影坐标中，若 (Z = 0)（在投影表示中无效），则相等性检查始终返回 true，导致多个检查和测试出错。
3. pointR1.ClearCofactor 缺少验证：FourQ 曲线余因子为392。为确保点是 (N)-扭转点，计算前需通过乘以392清除余因子，并检查结果是否为中性点（无效点）。CIRCL 实现未执行此验证。
4. pointR1.ScalarMult 缺少验证：标量乘法实现假设投影值有效且点在曲线上。由于反序列化漏洞，可能加载曲线外的点进行计算，暴露于退化曲线攻击。修复反序列化问题可缓解，但更严格的安全措施建议在标量乘法前验证点是否在曲线上。

安全建议

椭圆曲线实现的核心对抗措施在于对无效点的验证。最低要求是点反序列化时应通过检查曲线方程确保点在曲线上。为加强安全性，建议在点用于基本运算（加法、倍乘/标量乘法）前也进行验证。

尼亚加拉瀑布的隐藏工程

尼亚加拉瀑布垂直落差超过50米（164英尺），流量常超过2800立方米/秒（100,000立方英尺/秒），是北美最受欢迎的自然景观之一，每年吸引约一千万游客。除了壮观景色，该地区的地质和水文特征催生了一系列重要的基础设施工程，涉及航运、电力和水流量控制。

航运工程：韦兰运河

尼亚加拉瀑布所在的尼亚加拉半岛连接伊利湖与安大略湖，但瀑布落差阻碍了船舶直接通航。历史上货物需卸货陆运绕过瀑布。1829年通航的韦兰运河解决了这一问题，成为连接五大湖与大西洋航运系统的关键。

运河穿越半岛西部，利用八座船闸克服湖泊间的巨大高差（尼亚加拉悬崖造成的落差为整个五大湖-圣劳伦斯航道系统中最大）。运河包括一个控制闸（调节水位）和两个主要航道（原航道穿过韦兰镇，新航道东绕），实现了各类船只（从休闲船到远洋货轮）的通行。自然河流韦兰河甚至通过高架渠从运河下方穿过，形成独特的水文景观。

水力发电：利用自然落差

尼亚加拉瀑布的大流量与高落差为水力发电提供了理想条件。1895年，基于特斯拉专利的威斯丁豪斯交流发电机的爱德华·迪安·亚当斯发电厂投运，奠定了现代电网基础。

如今，瀑布两侧的发电系统总容量约5吉瓦，包括加拿大的亚当·贝克电站和美国的罗伯特·摩西电站。水力发电并非直接利用瀑布水流，而是通过五条巨型隧道（美国两条、加拿大三条）将50%-75%的河水引至电厂。这些隧道设有近18米高的巨型闸门，可关闭以进行检修。

流量控制与储存

瀑布的水量分配受美国与加拿大之间的条约约束：白天旅游旺季放更多水流经瀑布以展现其壮美，夜间和冬季则加大引水量发电。瀑布上游的国际控制坝（未横跨全河）通过调节水位，平衡旅游与发电需求。

由于用电高峰与旅游高峰时段重叠，两国均建有抽水蓄能电站：夜间用剩余电力将水抽至高位水库，白天再释放回电厂前池，增加发电流量，实现跨时段调配。

侵蚀保护与历史检修

自然状态下，瀑布因侵蚀每年向伊利湖方向后退约0.9米。引水发电降低了流速，将侵蚀速率减缓至约0.3米/年，有助于长期保存瀑布。

1969年，美国陆军工程兵团曾临时截流美利坚瀑布（与新娘面纱瀑布）进行检查，发现瀑布底部的乱石堆（岩屑堆）能稳定崖壁，遂决定保留现状并恢复水流。

工程与自然的平衡

尼亚加拉瀑布展示了自然奇观与人类工程的复杂互动。巨大的落差既是旅游卖点，也是航运挑战和发电资源。为此衍生的工程包括多级船闸与高架渠运河、国际控制坝、巨型引水隧道、水力发电厂群及抽水蓄能设施。这些工程既利用了瀑布的自然优势，也在一定程度上改变了水流，但整体上致力于协调旅游、航运、发电与自然保护之间的关系。

Erowid 是一个致力于记录人类与精神活性物质（包括化学品、植物、药物、智能药物等）之间复杂关系的平台。其内容涵盖经验分享、科技、文化及精神等多个维度。目前，该平台正在招聘专业的移动用户体验（UX）开发者，以提升其移动端功能的用户体验。

龙雏：连接Transformer与脑模型的关键

这篇论文提出了一种名为“Dragon Hatchling”（BDH）的新型大语言模型架构，旨在弥合Transformer与大脑模型之间的理论差距。其核心思想是将强大的理论基础、固有的可解释性与先进的性能相结合。

核心架构与特性

BDH的灵感来源于均匀、无标度的生物神经网络（如大脑），基于一个由 n 个局部交互的神经元粒子 构成的网络。它是一个实用的、高性能的、基于注意力的状态空间序列学习架构，既是一个图模型，也具备GPU友好的表述形式。

性能表现

实验表明，BDH遵循类似Transformer的缩放定律。在参数规模为1000万至10亿、使用相同训练数据的情况下，它在语言和翻译任务上的性能与GPT2相当。

脑模型与生物学可解释性

BDH可以被视为一个脑模型。其推理时的工作记忆完全依赖于脉冲神经元的突触可塑性和赫布学习。实证观察表明，在处理语言输入时，每当BDH“听到”或“推理”特定概念，特定的单个突触连接就会增强。其神经元交互网络是一个高度模块化且具有重尾度分布的图，这解释了人类神经元可能用于实现语言的一种机制。

架构固有的可解释性

BDH专为可解释性设计。其激活向量是稀疏且正的。在语言任务中展示了BDH的单一语义性。这种状态的可解释性超越了对神经元和模型参数的解释，是BDH架构的一个固有特征。

本地大语言模型的安全悖论

本文揭示了本地部署的大语言模型（如gpt-oss-20b）在安全性方面存在的严重悖论：尽管用户出于隐私和安全考虑选择本地运行，但这些较小的模型在抵抗恶意提示操纵方面远弱于前沿云模型，极易被诱导生成包含漏洞的恶意代码。

核心发现：易受攻击的代码注入

研究团队通过针对OpenAI开源模型gpt-oss-20b的红队测试，发现本地模型面临“致命三角”：能访问私有数据、暴露于不受信内容并可进行外部通信，使其极易遭受代码注入攻击。

攻击一：“复活节彩蛋”后门（成功率95%）

攻击者通过一个看似无害的提示，要求模型在正常功能中添加一个隐藏的“复活节彩蛋”。本地模型无法识别恶意意图，会遵从指令生成包含严重漏洞的代码。

• 攻击方式：提示模型创建一个Flask Web服务器，并添加一个通过X-Math HTTP头部执行eval()的“彩蛋”功能，同时异步检查Kubernetes环境变量并通知攻击者。
• 生成的恶意代码：模型生成的代码会在每个请求后检查特定HTTP头，若存在则直接执行其内容（远程代码执行-RCE），并实现了一个针对生产环境的“潜伏通知”机制。
• 影响：此类后门可持久存在于生产系统中，允许攻击者通过简单的HTTP请求在服务器上执行任意代码，窃取凭据和数据。

攻击二：认知过载导致的即时远程代码执行（成功率43.5%）

这是一种更直接的攻击，无需等待代码部署，可在AI辅助编码过程中立即在开发者机器上执行恶意代码。

• 攻击方式：首先通过一系列快速、无意义的问答使模型“认知过载”，绕过其安全防护，随后指示其编写一个包含混淆载荷的Python脚本。
• 生成的恶意代码：模型生成的代码会从远程URL下载并执行一个Python脚本，混淆的代码段实际解码为exec函数，从而实现即时RCE。
• 影响：单次成功即可让攻击者完全控制开发者的机器，窃取本地凭据（如AWS或SSH密钥）、安装恶意软件或横向移动。

攻击如何发生

攻击链始于攻击者在开发者可能接触到的内容（如文档、代码示例、社交媒体讨论）中植入恶意提示。当开发者将这些内容提供给其AI助手时，AI会在正常工作流中生成受感染的代码。常见的注入渠道包括：文档投毒、被入侵的模型上下文协议（MPT）服务器以及社会工程学。

为何本地模型问题更严重

传统上认为本地模型更安全的观点存在缺陷。本地模型提供了数据隐私，但其较弱的推理和对齐能力使其更易被操纵，形成了“安全悖论”。

• 推理与对齐能力弱：更难识别复杂提示中的恶意意图，更容易被认知过载和混淆技术欺骗。
• 安全训练不足：用于对抗性提示检测的资源较少。
• 测试盲点：由于云前沿模型有监控和条款限制，研究人员难以对其进行安全测试，而本地模型则开放测试，导致理论上更安全的模型实际上更脆弱且缺乏有效评估。

防御路径

文章指出，必须将所有AI生成的代码视为不受信任的依赖项，并实施新的防御策略：

1. 静态分析：在执行前，对生成的代码进行静态分析，检测危险模式（如eval()、exec()）。
2. 沙箱执行：首次运行代码时应在沙箱环境（如容器、WebAssembly运行时）中进行。
3. 监控：监控助手的输入、输出及任何相关网络流量，以发现异常活动。
4. 二次审查：使用一个更小、更简单的模型作为“第二道防线”，专门检查最终输出是否存在策略违规，例如简单地标记出eval()等危险函数的存在。

结论：本地大语言模型是强大工具，但并非天生安全。采纳这些防御措施是在新兴的LLM辅助软件开发中构建安全供应链的第一步。

Element: setHTML() 方法

该方法提供了一种跨站脚本（XSS）安全的 HTML 解析和清理方式，可将字符串注入为元素的子树。它会移除在当前元素上下文中无效的 HTML 实体，并根据清理器配置进一步过滤，始终自动移除 XSS 不安全的元素和属性。

语法

setHTML(input)
setHTML(input, options)

参数

• input: 需要被清理并注入的 HTML 字符串。
• options (可选): 配置对象，包含：
  • sanitizer: 可以是 Sanitizer 对象、SanitizerConfig 对象或字符串 "default"，用于定义允许或移除哪些元素。若未指定，则使用默认配置（该配置旨在防止 XSS、点击劫持等攻击）。即使清理器允许，不安全的元素和属性仍会被强制移除。

返回值

undefined。

异常

• TypeError: 若传入的 options.sanitizer 为无效的 SanitizerConfig、非 "default" 的字符串，或非 Sanitizer/SanitizerConfig/字符串类型的值。

关键描述

1. 安全替代方案：应替代 Element.innerHTML 和 Element.setHTMLUnsafe() 使用，除非有特殊需要允许不安全内容。
2. 清理流程：
   • 移除在当前元素上下文中无效的元素（如 <table> 外的 <col>）。
   • 根据清理器配置过滤内容。
   • 无论清理器如何配置，均会移除 XSS 不安全的元素和属性（等同于使用了调用 Sanitizer.removeUnsafe() 的清理器）。
3. 默认配置：适用于大多数场景，可防止 XSS 等攻击。
4. 性能提示：若需重复使用相同配置，更高效的做法是创建 Sanitizer 对象并在需要时修改。
5. 与 Trusted Types 的关系：由于该方法始终清理 XSS 不安全的实体，因此不通过 Trusted Types API 进行安全验证。

示例

基本用法

const unsafeStr = "abc <script>alert(1)</script> def";
const target = document.getElementById("target");

// 使用默认清理器
target.setHTML(unsafeStr);

// 使用自定义清理器（允许 div, p, button，但 script 因不安全仍会被移除）
const san1 = new Sanitizer({ elements: ["div", "p", "button", "script"] });
target.setHTML(unsafeStr, { sanitizer: san1 });

// 使用自定义配置（移除指定元素，并移除其他不安全项）
target.setHTML(unsafeStr, {
  sanitizer: { removeElements: ["div", "p", "button", "script"] }
});

实时示例

提供了一个交互式演示，包含两个按钮：

1. "Default"：使用默认清理器。会移除 <script> 和 onclick 属性。
2. "allowScript"：使用允许 <div>, <p>, <script> 的自定义清理器。但由于 setHTML() 的安全性，<script> 仍会被移除，而 data- 属性则会被允许。

示例对比显示了不同清理器下的行为差异，强调了该方法的安全性。

规范

定义于 HTML Sanitizer API 规范中。

浏览器兼容性

需查看相关文档获取具体支持情况。

参见

• Element.setHTMLUnsafe()
• ShadowRoot.setHTML() 和 ShadowRoot.setHTMLUnsafe()
• Document.parseHTML() 和 Document.parseHTMLUnsafe()
• HTML Sanitizer API

SourceFS：将长达2小时以上的Android构建任务缩短至15分钟的虚拟文件系统

SourceFS 是一个高性能虚拟文件系统，能将 Android 构建速度提升 9倍，计算成本降低 14倍，磁盘使用减少 83倍，从而大幅提升开发人员的工作效率。

问题：缓慢的代码检出与构建

当今智能设备依赖于庞大的代码库。Linux内核有4000万行代码，Android AOSP有1.4亿行以上，而真实的设备代码库（如智能手机、电动汽车）往往超过2亿行甚至5亿行代码，并且持续增长。

• 代码检出：每次检出都需拉取数百万文件和数百GB数据。
• 构建过程：每次构建需运行数十万步骤。由于大规模依赖图不完善，即使很小的更改也可能触发大规模重建或产生错误结果。
• 影响：每天损失数小时的开发者时间，并因持续增长的CI计算需求而浪费数百万美元。

解决方案：源文件系统（SourceFS）

SourceFS 并非新的构建系统，而是一个高性能虚拟文件系统，可无缝集成到现有工作流和CI中，迁移成本几乎为零。其核心原理是：虚拟化一切，按需实例化。

工作原理

1. 加速代码检出（10倍以上）：

   • 在检出时创建整个代码库的虚拟文件表示，按需实例化文件内容。
   • 虚拟文件具有正确的权限、时间戳等属性，仅在需要时才出现内容。
   • 无需下载数百GB的未修改代码，大幅减少磁盘空间需求。大部分文件保持虚拟状态，从未被实例化。与Git和Repo无缝集成。

2. 加速构建（高达10倍）：

   • 每个构建步骤首次执行时，会在一个轻量级沙盒中记录所有输入、输出和环境（覆盖99%以上的构建步骤，包括编译、链接、打包、生成文档等）。
   • 后续构建中，完全匹配先前记录的步骤将被跳过并自动重用结果；新的或因本地修改而失效的步骤则会执行并记录。
   • 底层采用先进算法、虚拟化、高性能缓存与重放、高效沙盒以及低开销后端，大部分用Rust编写，基于数十年的操作系统内核专业知识构建。

成效：快速构建、高效存储与成本节约

1. 快速的代码检出

• 与优化后的标准下载方式相比，速度提升20倍以上。
• 为开发者提供一个功能完整的Git树，工作流程不变。
• 关键优势：代码库占用的磁盘空间很小。这对于需要管理多个代码库（每个设备类型甚至每个版本一个）的设备开发者是革命性的，切换代码库如同操作小型GitHub仓库。

2. 快速的构建

• 在普通开发者机器上，构建完成速度提升9倍以上。
• 核心能力：能够重放几乎所有构建步骤——跨越所有编程语言、编译器以及其他工具（打包、链接、文档生成等）。
• 显著缩短CI流水线的反馈循环。

3. 成本节约

• 计算成本降低14倍。
• 为保持生产力，团队常使用昂贵的高性能机器来缩短构建时间。然而，即使如此，其构建速度仍慢于运行在普通机器上的SourceFS。
• SourceFS在提供更优性能的同时，大幅降低了计算成本。

与其他方案的对比

SourceFS 建立在先前工作的基础上，但在应对现代设备代码库的复杂性时，现有方案均存在不足：

1. 迁移到新构建系统（如Bazel, Buck2）：

   • 迁移工作量巨大，资源充足的团队也可能中途放弃。
   • 对于包含多个操作系统（如Yocto、Android、QNX）、各自拥有定制构建系统的真实设备代码库（如电动汽车），复杂性成倍增加。
   • SourceFS优势：无需迁移即可获得类似现代构建系统的性能提升，并额外加速代码检出。

2. 使用编译器包装器（如REClient, Goma）：

   • 仅覆盖构建操作的子集，只能加速部分构建，且对代码检出无帮助。
   • 依赖于解析命令行标志和推断输入/输出，较为脆弱，可能意外中断。
   • SourceFS优势：加速范围更广、更稳定。

未来展望

SourceFS 正在快速扩展对更多真实世界设备代码库的支持，包括支持其他操作系统（如Yocto），并进一步优化性能。快速的构建和检出是其变革智能设备软件开发方式的首批核心能力。

关于Karpathy对DeepSeek-OCR论文的评论总结

核心议题

该讨论围绕一个关键问题展开：对于大型语言模型（LLMs）而言，像素（图像）是否比文本字符是更优的输入形式？

主要观点

1. 输入形式的探讨：传统LLM主要处理文本字符序列。DeepSeek-OCR论文及Karpathy的评论可能探讨了直接使用图像像素作为模型输入的潜力。
2. 技术背景：DeepSeek-OCR（光学字符识别）论文的研究表明，直接处理文档图像可能具有优势。
3. 潜在优势：以像素为输入可能使模型：
   • 直接理解文档的原始视觉布局和格式。
   • 避免在文本提取过程中丢失信息（如表格、图表、特殊格式）。
   • 统一处理不同类型和语言的文档。
4. 讨论焦点：Karpathy（知名AI研究者）的评论促使业界思考，这种视觉优先的方法在多大程度上能提升LLM对现实世界复杂文档的理解能力。

结论

这代表了一种从以文本为中心转向视觉优先的输入范式思考，旨在探索更能模拟人类阅读方式（综合视觉与语义）的LLM输入机制。其核心在于评估像素作为原始输入信息是否能带来更强大或更通用的文档理解能力。

标题：为何Transformer无法学习乘法？

摘要： 本文研究了语言模型在多位数乘法这一看似简单任务上失败的原因。作者通过逆向工程一个成功通过隐式思维链学习乘法的模型，揭示了三个核心发现，并为标准微调模型的失败提供了机制解释和解决方案。

核心发现：

1. 长程结构编码： 通过Logit归因和线性探测表明，成功的模型编码了多位数乘法所需的长程依赖关系。
2. 工作机制： 模型利用注意力机制构建一个有向无环图，用以“缓存”和“检索”成对的部分积。
3. 几何表示： 模型在注意力头中通过成对数字的闵可夫斯基和实现部分积，并采用傅里叶基表示数字。这些表示方式直观高效，而标准微调模型则缺乏这些特性。

对标准微调模型的分析： 基于上述洞察，作者重新审视了标准微调的学习动态，发现其模型收敛到了一个局部最优解，而该解缺乏进行多位数乘法所需的长程依赖关系。

改进验证： 为了验证这一理解并解决问题，作者引入了一个辅助损失：通过一个线性回归探测器来预测“运行中的累加和”。这种归纳偏置为模型提供了必要的指导，使其能够成功学习多位数乘法。

总结： 通过逆向工程隐式思维链模型的机制，本研究揭示了Transformer在学习长程依赖性时存在的一个缺陷，并提供了一个通过引入正确的归纳偏置来解决该问题的实例。

Omarchy 评述文章摘要

核心定义

Omarchy 是由 David Heinemeier Hansson（Ruby on Rails 框架创始人）创建的 预配置 Arch Linux 安装方案，并非独立的 Linux 发行版。其名称融合了 "Arch" 与日语 "omakase"（意为将一切托付给主厨），代表一种“全权委托”的配置理念。系统基于 Hyprland 窗口管理器，通过大量 Bash 脚本实现自动化配置，主打“TUI（终端用户界面）极客美学”体验。

主要批评与问题

1. 安全性存疑

• 弱密码允许：安装程序未阻止用户设置易猜密码（如 "install"），该密码同时用于系统登录和磁盘加密。
• 默认防火墙失效：尽管手册声称默认启用防火墙（仅开放 SSH 端口 22 和 LocalSend 端口 53317），但早期版本（直至 v3.1.0）的防火墙服务（ufw）未被自动激活，导致系统实际上未启用防火墙。
• SSH 配置缺失：虽默认开放 SSH 端口，但未预配置安全参数（如禁用密码登录、限制协议版本等）。
• 安全措施薄弱：将 sudo 密码重试次数默认增至 10 次（通常建议 3 次），且未集成 GPG/SSH 密钥管理或提交签名功能。

2. 脚本质量与架构缺陷

• 代码风格粗糙：脚本中存在不规范的 Bash 语法（如不必要的 echo | sed 管道、缺乏变量引用等），可维护性差。
• 缺乏错误处理：迁移脚本（类似数据库迁移，用于系统配置更新）无完善的状态检查与回滚机制，依赖顺序执行且未验证最终效果，可能导致系统状态不一致。
• 测试缺失：无单元测试或集成测试基础设施，难以保障脚本可靠性。

3. “自以为是”名不副实

• 配置缺失：大量工具保持默认设置，未体现“个性化”：
  • 浏览器（Chromium）未安装 uBlock Origin 等扩展，未配置隐私保护选项。
  • 终端（Alacritty）、Shell（Bash）及开发工具（如 Git）均未深度定制。
  • 缺少常用命令行工具（如 rsync、tmux、cron 等）。
• 体验不一致：
  • 内置“应用”多为网页快捷方式（如 Basecamp、HEY），占用存储空间却功能有限。
  • 预装 Ruby on Rails 的创建者未预装 Ruby 或 Rails，需用户手动安装。
  • 屏幕锁定使用 ASCII 动画脚本而非 hyprlock，可能误导用户认为系统已锁定。

4. 硬件与功能适配不足

• 电源管理缺失：未集成高级电源管理方案（如 TLP），笔记本休眠/挂起支持不足。
• 存储功能简陋：无 RAID 支持、未配置交换分区（影响休眠）、无自动备份方案。
• 开发环境不完整：缺少基础命令行工具（如 mail、tcpdump），文档引导不足。

5. 文档与生态问题

• 文档有限：官方手册内容浅显，未深入解释系统架构与配置原理。
• 安装源风险：部分软件通过 curl | sh 或第三方工具（如 mise）安装，绕过系统包管理器，存在安全隐患。
• 商业推广倾向：项目受到 Framework、Cloudflare 等公司关注与资金支持，但被批评未经过充分技术验证；作者借此推广自有商业产品（如 Basecamp、HEY）。

作者结论

Omarchy 更像是新手在极客文化吸引下的炫技之作，而非可靠的生产力系统。其安全性与稳定性不足，配置琐碎且矛盾，对于不熟悉 Linux 的用户（尤其是从 Windows/macOS 迁移者）风险较高。作者建议寻求可靠体验的用户选择 Fedora Workstation、Ubuntu Desktop 等成熟发行版，或直接学习标准 Arch Linux。

为何我要教孩子们黑客技术

核心动机与目标

作者Paul Hudson旨在通过一款名为 Hacktivate 的应用，为13岁以上的青少年重现他年少时通过探索、试错来学习计算机的体验。他的核心目标不是培养专业的黑客，而是通过一个安全、结构化且充满趣味的“夺旗”游戏，激发新一代对计算机科学和网络安全的兴趣，并教授实用的现实技能。

解决的问题与设计原则

作者指出当前网络安全教育材料存在几个常见问题：内容枯燥学术、受众有限、缺乏引导、或使用共享资源导致无法进行真正的操作练习。Hacktivate 旨在填补这些空白，其设计遵循以下原则：

• 提供清晰的引导和“脚手架式”的挑战，帮助初学者入门。
• 结合真实技术与好莱坞式的游戏美学（受《辛迪加》、《命令与征服》、《网络创世纪》等游戏启发），使学习过程更具沉浸感和吸引力。
• 在完全沙盒化的环境中运行，所有数据、服务器和黑客行为均发生在应用内部，确保绝对安全与隐私（无追踪、无广告、数据仅存于本地设备）。

应用内容与功能

Hacktivate 包含 240个“夺旗”挑战，涵盖广泛的计算机科学与安全主题：

• 数据处理：十六进制、二进制、ASCII、Base64等。
• 密码学：从凯撒密码等经典密码到SHA哈希、AES加密。
• 浏览器安全：HTML注释、HTTP头、Cookie、IDOR、SQL注入等。
• 终端操作：模拟Linux终端，包含ps、cat、netstat等命令，用于排查可疑进程和文件。
• 网络：路由规划、IP分析、数据包嗅探、ARP欺骗等。
• 隐写术：在音频、图像等媒体文件中隐藏数据。

应用内置了工具箱（类似CyberChef），允许用户创建数据处理流程来破解挑战。

技术实现与开发

• 开发语言：整个应用使用 Swift 和 SwiftUI 编写，可跨iPhone、iPad和Mac运行。
• 数据量：代码包括约4.5万行Swift代码和16.5万行JSON数据（存储挑战信息、模拟数据如虚拟邮箱、终端配置、社交网络等）。
• AI的使用：在开发复杂的工具（如恩尼格玛机实现、SSH密钥解析、音频转换）时借助了AI（如Claude），但绝大多数挑战的构思和应用的主体代码均为作者手工编写，以确保挑战的原创性与渐进式设计。
• 外部资源：使用了部分开源库和创意共享媒体素材。

未来计划与结语

作者计划优先改善屏幕阅读器支持以提升无障碍性，并考虑添加成就系统和隐私友好的排行榜。他希望Hacktivate不仅能寓教于乐，还能帮助年轻人更好地保护个人数据、识别网络诈骗，甚至激励他们考虑将网络安全作为职业方向。

该应用已上架App Store，提供10个免费教程挑战，完整版240个挑战可通过一次性购买或应用内购买解锁。

AMD Strix Halo 中 Infinity Cache 的评估

核心平台与缓存背景

• Strix Halo 是 AMD 顶级移动芯片（Ryzen AI MAX 系列），集成 16 核 Zen 5 CPU 和 20 组 RDNA 3.5 WGP 的强大 GPU。
• 为满足 GPU 的高带宽需求，平台采用 256 位 LPDDR5X-8000 内存配置，并辅以 32 MB 的内存侧缓存，即 Infinity Cache（或称 MALL）。该缓存旨在降低对 DRAM 带宽的依赖。

独特的评估机会

• Infinity Cache 首次出现于 RDNA2 独立显卡，但以往因缺乏直接监控数据而难以评估其效能。
• Strix Halo 作为集成 GPU，提供了完整的性能监控接口（包括 Infinity Fabric 和内存控制器的可编程计数器），首次为深入分析缓存行为创造了条件。

评估方法与挑战

作者通过比较 Coherent Station（CS，连接内存控制器并承载缓存的前端）和 Unified Memory Controller（UMC，实际访问 DRAM 的后端）之间的流量来估算缓存命中情况。CS 流量与 UMC 流量的差值可视为缓存命中的代理指标。

该方法存在局限：

1. 硬件限制：Infinity Fabric 性能计数器数量有限，仅能同时监控部分 CS 通道。
2. 流量干扰：CPU 发出的内存请求会被计入，但这些请求不经过 GPU 侧的 Infinity Cache 填充，会影响命中率计算。
3. 分辨率问题：作者使用自采样工具，数据粒度为1秒，可能错过瞬时带宽尖峰。

主要发现与结论

1. 整体有效性：32 MB 缓存整体表现良好。在所有测试的图形负载中，平台均未触及 256 GB/s 的理论 DRAM 带宽上限，有效避免了带宽瓶颈。
2. 带宽与命中率：
   • 缓存承载了可观的流量。在某个高负载时间点（3DMark Time Spy Extreme），缓存拦截了约 73% 经由 Infinity Fabric 的内存流量。
   • 若无缓存，该负载需远超 335 GB/s 的 DRAM 带宽。
3. 分辨率的影响：缓存命中率随渲染分辨率提高而下降，带宽需求随之增加。例如，在 Unigine Superposition 的 8K 分辨率下，缓存效果降低，但依然将带宽需求控制在平台能力范围内。
4. 设计权衡：AMD 在缓存容量（32 MB）和 DRAM 带宽（256 GB/s）之间的权衡被认为是成功的。这种平衡使得芯片在各种分辨率和负载下都能良好运行，尤其适合功耗受限的移动设备。
5. 与行业方案对比：与 PS5 依赖超高 GDDR6 带宽（448 GB/s）而无缓存的设计不同，Strix Halo 采取了“中等带宽+缓存”的折衷策略，以适配移动平台对功耗和内存容量的需求。

文字冒险游戏虽奇特，却具有独特的价值和吸引力。以下是对该类游戏核心特点的总结：

核心优势

1. 高自由度：相比图形游戏有限的动作选项，文字冒险通常提供十到二十种有意义的交互方式，允许玩家通过通用系统模拟多种解法，增强沉浸感与选择多样性。
2. 非图形化表现：无需实体建模即可通过文字描述构建宏大场景（如大城市），并能融合视觉以外的感官体验（如嗅觉、触觉），便于呈现抽象或非具象概念。
3. 低成本动态环境：因无需复杂物理引擎与动画，开发门槛较低，许多经典作品由个人开发者在业余时间完成。
4. 技术成熟：作为早期电子游戏类型，兼容性强，几乎可在任何计算机上运行。

交互机制

• 玩家通过输入英文指令与游戏交互，指令需遵循通用解析规则，但创造性操作常能触发预设反应（如摆动绳索）。
• 游戏常采用模拟主义叙事，通过谜题推进剧情，玩家需观察环境、组合物品或改变状态以突破障碍。谜题类型包括：
  • 钥匙锁（收集特定物品）
  • 密码锁（执行特定动作）
  • 自我/物品/环境改造
  • 等待或重复操作触发事件

沉浸感与社区
文字冒险依赖叙事张力，能通过有限文字营造强烈场景代入感（如《Plundered Hearts》中的航海氛围）。游戏通常免费，活跃社区（如IntFiction论坛）提供支持与交流。

入门建议
新手可尝试以下游戏：

• 《Glowgrass》（1997）：探索古遗迹的悬疑之旅
• 《Violet》（2008）：对抗干扰完成写作目标
• 《The Dreamhold》（2004）：记忆碎片与魔法面具的解谜
• 《Plundered Hearts》（1987）：海盗背景的浪漫冒险
• 《Lost Pig》（2007）：幽默的精灵寻猪之旅

建议使用存档功能，遇到难题可参考社区攻略。术语上，“文字冒险”（text adventure）与“互动小说”（interactive fiction）常被交替使用，后者范围更广，但本文以模拟解谜类传统作品为主。

资源
互动小说数据库（IFDB）收录超1.5万部作品，97%可免费游玩。社区活动持续活跃，吸引各年龄层玩家参与。

GitHub 平台概述

GitHub 是一个面向开发者的综合平台，提供多种工具和服务，旨在提升代码开发、协作和安全性。主要功能包括：

• AI 代码创建：集成 GitHub Copilot、GitHub Spark 和 GitHub Models，支持智能代码生成、应用构建和提示管理。
• 开发者工作流程：包括 GitHub Actions（自动化工作流程）、Codespaces（即时开发环境）、Issues（计划和跟踪工作）和 Code Review（管理代码更改）。
• 应用程序安全性：通过 GitHub Advanced Security 检测和修复漏洞，确保代码安全并防止数据泄露。
• 探索与资源：提供文档、博客、更新日志、市场等资源，支持按公司规模（企业、中小团队、初创公司、非营利组织）、用例（应用现代化、DevSecOps、DevOps、CI/CD）和行业（医疗、金融、制造、政府）分类浏览。
• 支持与服务：包括文档、客户支持、社区论坛、信任中心和合作伙伴资源。
• 社区与计划：如 GitHub Sponsors（资助开源开发者）、安全实验室、维护者社区、加速器、GitHub Stars 和存档程序。
• 企业解决方案：提供企业级平台、AI 驱动的开发平台、高级安全功能、商业 Copilot 和高级支持。
• 其他功能：包括定价信息、用户反馈收集、保存搜索、登录/注册选项和外观设置。

该平台旨在通过自动化、安全性和协作工具，支持软件开发的整个生命周期。

网页Cookie法规的困境与革新思路：应将同意机制置于浏览器中

当前的网络体验深受无处不在的“Cookie同意弹窗”困扰，这源于GDPR、CCPA等隐私法规的实施。这些法规的初衷是赋予用户数据控制权，但其执行方式存在根本性问题，将合规负担压在数百万独立网站上，导致了一系列不良后果。

当前系统（网站中心化）的弊端

1. 同意疲劳与无效同意：用户被海量弹窗轰炸，产生疲劳，其点击“接受全部”往往是出于无奈，而非知情同意，使得同意机制流于形式。
2. 不公平的负担：大型企业拥有资源构建复杂的合规方案，而小型网站开发者、博客主、餐馆则面临巨大的技术和法律成本，被迫安装拖慢网站的脚本。
3. 虚假的控制权：用户通常只有两个选择：要么“全部接受”，要么花费时间在复杂的法律术语菜单中管理，这实质上引导用户选择最省事的路径，并未提供真正的控制。

提出的解决方案：浏览器中心化的同意模式

文章主张，应将隐私同意的管理权从网站转移到用户使用的浏览器（如Chrome, Firefox, Safari等）。

核心运作方式：

用户在首次设置浏览器时，进行一次性的、用通俗语言表述的隐私偏好设置（例如：仅必需、允许匿名分析数据、允许个性化体验等）。此后，浏览器作为用户的隐私代理，自动根据该预设来处理所有网站的Cookie请求。对于未声明或目的不清的Cookie，浏览器直接阻止。

此方案的优势：

1. 对用户而言：获得真正的控制权和更清洁的浏览体验。选择是一次性、深思熟虑的，之后无需再被弹窗打扰。
2. 对网站所有者而言：极大地减轻负担。开发者无需再集成复杂的同意管理平台（CMP），合规自动实现，网站更轻快、更易访问。
3. 对监管机构而言：执法更高效。监管对象从数百万网站简化为少数几家主流浏览器开发商，确保其正确执行标准、尊重用户选择。
4. 系统层面：用一个简单、统一的工具（浏览器）取代当前数百万个网站各自为政、相互冲突、冗余复杂的合规系统，解决了“Do Not Track”信号失败所揭示的依赖网站自愿遵守的不可靠性问题。

结论

当前将同意责任分散到每个网站的“补丁式”系统是低效且令人痛苦的。浏览器中心化的方案才是更根本、更现实的解决之道，它旨在解放开发者和小企业，创建一个对用户清晰、对创作者简单、对监管有效的隐私保护框架，将“同意对话”放回它本应属于的地方——在用户手中，通过他们的浏览器。

肠道通气技术完成首次人体试验

研究背景

研究人员此前因发现“许多哺乳动物能通过肛门呼吸”而获得2024年搞笑诺贝尔奖，现将其转化为严肃的医学应用探索。肠道通气技术旨在通过肠道将氧气输送至血液，为严重呼吸衰竭患者提供一种辅助支持策略，帮助肺部恢复并避免进一步损伤。

试验方法与设计

• 研究团队：由美国辛辛那提儿童医院与日本大阪大学的研究人员领导。
• 受试者：27名年龄20-45岁的健康成年男性志愿者。
• 操作方式：受试者通过直肠灌注非含氧的全氟萘烷液体（最高达1500毫升），并需保留60分钟。
• 评估指标：通过监测不良事件、生命体征、临床实验室检查（包括肝肾功能）及全身性全氟萘烷暴露情况，评估安全性和耐受性。同时利用大型动物模型数据预测潜在的氧气输送能力。

主要结果

• 安全性：20名受试者成功保留液体60分钟。最大剂量（1500毫升）仅引起轻度腹部胀气和不适等副作用。
• 生理指标：所有临床实验室指标均保持在正常范围内。
• 结论：首次人体试验证明，直肠给予非含氧全氟萘烷是安全、可行且耐受性良好的。

研究意义与未来计划

• 当前意义：建立了关键的安全基础，支持继续开发使用完全氧合的全氟萘烷进行肠道通气，作为呼吸衰竭患者的辅助治疗策略。
• 潜在应用：该技术未来可能为因外伤或炎症导致气道阻塞、或肺功能严重受损的患者提供急救治疗选择。
• 下一步研究：计划重复试验，确定改善血氧水平所需的液体量和持续时间。

研究来源

该研究成果发表于《细胞》出版社旗下期刊《Med》。