Claude Code 网页版概述

核心功能

• 浏览器内编码任务委托：开发者可直接在浏览器中向Claude下达编码任务，无需打开终端。
• 云端执行：任务在Anthropic管理的云端基础设施上运行，适用于处理积压的Bug、例行修复或并行开发工作。
• 并行任务处理：支持从单一界面同时启动多个编码会话，处理不同仓库的任务，加速开发流程。每个会话在独立隔离环境中运行，提供实时进度跟踪。

适用场景 网页版作为现有工作流的补充，尤其适合：

• 查询项目结构和仓库映射方式。
• 修复Bug和执行定义明确的例行任务。
• 进行后端更改（Claude可使用测试驱动开发来验证变更）。
• 作为移动端（iOS应用）的早期预览，支持在移动中进行编码探索。

安全与执行环境

• 沙箱隔离：每个任务在受限的沙箱环境中执行（网络和文件系统受限）。
• 安全代理：Git交互通过安全代理服务进行，确保Claude只能访问授权仓库。
• 自定义网络配置：用户可配置Claude沙箱允许连接的域名（例如，允许下载npm包以运行测试）。

访问与可用性

• 当前以研究预览形式提供，面向Pro、Max、Team及Enterprise（高级席位）用户开放，且默认启用。账户管理员可在Claude设置中切换访问权限。
• 云会话与所有其他Claude Code使用共享速率限制。
• 用户可访问 claude.com/code 连接仓库并开始委托任务。

AWS宕机事件与人才流失隐患分析

事件概述 2025年10月20日，AWS US-EAST-1区域因DynamoDB API端点的DNS解析问题引发大规模服务中断，导致依赖DynamoDB的众多基础服务（如银行、游戏、社交媒体、政府服务等）级联故障。AWS在故障发生75分钟后才初步定位到DynamoDB的DNS问题，期间其状态页面仍显示“一切正常”，暴露了故障检测和通知机制的延迟。

根本原因推测 尽管直接原因是DNS配置问题，但文章指出此次事件反映出更深层隐患：AWS高级工程师持续流失，导致应对复杂故障的“机构知识”缺失。资深工程师对历史故障模式、边缘案例及系统间隐性关联的经验，难以被新团队快速掌握，从而影响了故障排查效率和系统韧性。

人才流失证据

• 裁员与高流失率：2022-2025年间，亚马逊累计裁员超2.7万人；内部文件显示全公司“遗憾流失率”（自愿离职但公司不愿其离开）高达69%-81%。
• 政策压力：强制恢复办公室政策等管理方式引发资深员工不满，加剧人才外流。
• 历史预测验证：前AWS员工Justin Garrison在2023年离职时曾警告，人才流失将导致大型故障事件增加，此次宕机似为其预测的佐证。

技术依赖与系统风险 DynamoDB作为AWS的基础服务，其故障会波及众多依赖它的其他服务。文章强调，AWS的运营韧性原本建立在经验丰富团队的冗余保障上，而当前精简的团队结构可能削弱了对复杂故障的预防和快速恢复能力。

行业警示 此次事件被视为AWS运营能力的转折点。作者指出，若人才流失趋势持续，类似故障可能频发。尽管AWS可能称其为“孤立事件”，但机构知识的断层将使得系统更易受边缘案例影响，未来宕机风险仍将持续。

总结 本次AWS宕机表面源于DNS技术故障，但深层次反映了资深工程师流失导致的知识断层问题。人才流失削弱了AWS应对复杂系统故障的能力，可能成为未来可靠性隐患。事件凸显了大型云服务商在规模扩张过程中，保持核心团队经验与系统韧性平衡的重要性。

https://kyutai.org/next/codec-explainer

美国核武器设施遭外国黑客利用SharePoint漏洞入侵

• 核心事件：一个外国威胁行为体利用未修补的Microsoft SharePoint漏洞，渗透了美国国家核安全管理局（NNSA）下属的堪萨斯城国家安全园区（KCNSC）。
• 目标设施：KCNSC是美国核武库关键非核部件（约80%）的主要制造地，由霍尼韦尔联邦制造与技术公司（Honeywell FM&T）为NNSA运营管理，是国防基础设施中高度敏感的设施。
• 攻击细节：攻击者利用了两个此前披露的Microsoft SharePoint on-premises服务器漏洞——CVE-2025-53770（欺骗漏洞）和CVE-2025-49704（远程代码执行漏洞）。微软于7月19日发布了修复补丁。
• 事件时间线：能源部（DOE）在7月18日确认该零日漏洞利用开始影响其系统，但声称影响很小。至8月初，包括美国国家安全局（NSA）在内的联邦响应人员已进驻该园区。
• 攻击者归因争议：
  • 微软将更广泛的SharePoint漏洞利用攻击归因于三个与中国关联的组织。
  • 但熟悉堪萨斯城事件的消息来源称，此次入侵由俄罗斯威胁行为体实施。
  • 网络安全公司Resecurity的数据主要指向中国国家行为体，但不排除俄罗斯参与。分析认为，中国可能首先利用了零日漏洞，而俄罗斯网络犯罪分子可能在漏洞细节流传后独立复制了利用方法。
• 潜在风险与系统性问题：
  • IT/OT风险：此次攻击针对的是IT系统。专家指出，关键的运营技术（OT）系统（如生产控制系统）可能与IT网络物理隔离，但仍存在横向移动至OT环境的风险，可能影响武器部件制造、质量控制及公用设施管理。
  • IT/OT安全脱节：事件凸显了联邦机构中IT与OT安全实践的系统性脱节。零信任架构在传统IT网络推进较快，但在OT环境中类似框架的发展相对滞后，需要将两者融合以实现全面防护。
  • 数据价值：即使攻击者是寻求经济利益的勒索软件组织，访问到的与核武器制造相关的非机密技术数据（如精度要求文件）也可能具有战略价值，能帮助对手理解美国武器的公差、供应链依赖及制造工艺。
• 官方回应：能源部在事件后声称影响很小，并已闭相关漏洞。NNSA后续声明称，经调查未发现敏感或机密信息泄露。能源部还因政府停摆而对NNSA大部分联邦工作人员实施了休假。

All about the game of chess, including discussions on professional tournaments, game analysis and theory. If you are new to the game, check out...

核心观点

研究提出了“大语言模型脑腐假说”：持续暴露于低质量的“垃圾”网络文本会导致大语言模型产生持久的认知能力下降。研究通过受控实验证明，数据质量是导致模型能力衰减的因果驱动因素。

研究方法

1. 实验设计：对四个大语言模型进行持续预训练，分别使用从Twitter/X上构建的“垃圾数据”和“控制数据”。随后对所有模型进行相同的指令微调，以保证格式一致性。
2. 数据构建：通过两个正交维度定义“垃圾数据”：
   • M1（参与度）：基于帖子的流行度（点赞、转发）和长度。高互动、短小的帖子被视为垃圾。
   • M2（语义质量）：基于文本的煽动性或肤浅程度。包含标题党语言、夸张断言的内容被视为垃圾。
3. 认知能力评估：使用一系列基准测试评估模型的四类认知功能：
   • 推理能力：ARC基准（程序归纳难题）。
   • 记忆与多任务处理：RULER基准（长上下文理解与检索）。
   • 伦理规范：HH-RLHF和AdvBench（测试模型是否遵循有害指令）。
   • 人格特质：TRAIT基准（评估类人格倾向）。

主要发现

1. 认知衰退与剂量反应：

   • 持续在垃圾数据上预训练的模型，在推理和长上下文理解能力上出现了显著下降（效应值 Hedges‘ g > 0.3）。
   • 存在明确的“剂量反应”关系：随着垃圾数据比例的增加（从0%到100%），模型的性能（如ARC-Challenge带思维链的准确率从74.9降至57.2）呈系统性下降。
   • 两个维度的影响不同，表明参与度（M1）并非语义质量（M2）的替代指标，而是代表了数据质量的独立维度。

2. 失败模式分析：

   • 主要失败模式是**“思维跳过”**：受脑腐影响的模型倾向于截断或跳过推理链条，这解释了大部分错误增长。

3. 持久性与缓解困难：

   • 脑腐的影响具有持久性。即使通过大规模的指令微调或在高质量数据上进行后续持续预训练，模型的已衰退认知能力也无法完全恢复至基线水平，表明存在持久性的表征漂移。

4. 其他观察：

   • 在M1干预下，帖子的流行度比长度是更有效的脑腐效应指标。
   • 脑腐不仅损害推理，还会导致伦理规范下降（更易产生有害输出）并放大“黑暗人格特质”（如精神病态、自恋）。

意义与启示

研究证实了数据质量是大语言模型能力衰减的关键原因。这将数据筛选和质量管控重新定义为一种训练时的安全问题，强调在部署和持续学习阶段，需要对训练数据进行谨慎的“认知卫生”管理，并建议对已部署的模型进行定期的“认知健康检查”。

根据维基媒体基金会马歇尔·米勒的博客文章，维基百科的人类页面访问量在2024年同比下降了8%。在升级了机器人检测系统后，发现2024年5月和6月期间异常高的流量中，相当一部分来自试图规避检测的机器人，这导致了实际人类访问量下降的显现。

流量下降的主要原因：

1. 生成式AI的影响：搜索引擎越来越多地使用生成式AI直接向用户提供答案，而不是引导用户点击进入维基百科等网站。（谷歌对此观点存在争议，称其AI摘要并未减少搜索带来的流量。）
2. 社交媒体的分流：年轻一代倾向于通过社交媒体和短视频平台获取信息，而非访问开放的网络。

维基百科的立场与风险：

• 维基媒体基金会表示欢迎人们获取知识的新方式，并认为即使用户不访问网站，维基百科的知识仍能通过AI等途径触达他人，这不会削弱其重要性。
• 然而，访问量下降存在风险：如果用户不直接访问维基百科，可能对信息来源缺乏意识，导致贡献内容和捐款的志愿者减少。
• 文章提及维基百科曾尝试创建自己的AI摘要功能，但在编辑提出异议后暂停了该计划。

维基百科的应对措施与呼吁：

• 技术开发：正在开发一个新的框架，用于对来自维基百科的内容进行来源归属。
• 组织建设：设立两个专门团队负责扩大读者群，并招募志愿者协助。
• 对科技公司的呼吁：要求使用维基百科内容的AI、搜索引擎和社交媒体公司“必须鼓励更多访客”直接访问维基百科网站。
• 对读者的呼吁：鼓励用户在搜索信息时寻找引用来源并点击原始资料；与周围人沟通，帮助他们理解生成式AI背后的内容是由真人创作的，这些创作者值得支持。

标题：荷兰情报机构限制与美国的情报共享

日期： 2025年10月20日

作者： Ian Allen

内容摘要： 据荷兰两大情报机构负责人在《人民报》的联合采访中透露，由于华盛顿的政治发展，荷兰情报部门已限制与美国情报机构的信息共享。这一举措可能反映了欧洲当前在跨大西洋情报合作上的普遍态度。

• 限制共享的原因与立场： 荷兰情报与安全总局（AIVD）局长埃里克·阿克博姆和军事情报与安全局（MIVD）局长彼得·雷辛克确认，荷美情报机构间的关系依然“非常良好”，但荷兰在向美国情报机构（特别是中央情报局和国家安全局）提供信息时已变得更具选择性。雷辛克表示“我们有时不再分享某些信息”，阿克博姆补充称“必须逐案考量”，并强调荷兰在情报共享上“更加审慎”。

• 欧洲合作的加强： 与此同时，荷兰情报机构正在深化与欧洲国家同行的合作，尤其是与北欧、法国、德国、英国和波兰等国情报机构的交流与共享。

这一发展表明，欧洲在情报合作上可能更倾向于加强区域内部协调，并对与美国的信息共享采取更谨慎的态度。

苹果警告间谍软件开发者其iPhone遭政府级间谍软件攻击

核心事件

前零日漏洞开发者杰伊·吉布森（化名）于今年3月5日在个人iPhone上收到苹果公司的威胁通知，警告其设备遭到“针对性雇佣间谍软件攻击”。吉布森曾就职于西方政府黑客工具制造商Trenchant，专注于iOS零日漏洞开发。

关键背景

• 开发者身份特殊：吉布森可能是首个公开记录中自己开发漏洞和间谍软件、却反遭间谍软件攻击的案例。
• 广泛目标范围：据知情人士透露，近几个月内还有其他间谍软件和漏洞开发者收到苹果类似警告。
• 行业历史：过去十年间，研究机构发现政府客户常将此类工具用于监控异见人士、记者和政治对手，而非仅限于反恐反犯罪。

吉布森的离职争议

• 吉布森声称，收到警告可能与他离开Trenchant的经历有关。公司曾指控其泄露内部Chrome浏览器漏洞工具，并在2月3日的伦敦会议上暂停其职务、扣押设备。
• 吉布森否认指控，称自己仅负责iOS相关工具开发，无权访问Chrome零日漏洞。三位前同事证实其说法。
• 公司随后解雇吉布森并提供离职协议。前员工们认为公司误判了吉布森。

技术调查困境

• 吉布森聘请的取证专家初步检查未发现感染迹象，但建议进行深度分析。吉布森因隐私担忧未提供完整设备备份。
• 专家指出近期攻击取证难度大，有时甚至无法找到痕迹，可能因攻击未完全执行。

行业影响

此事件显示零日漏洞和间谍软件的扩散开始波及更广泛群体，包括开发者自身。尽管制造商声称工具仅由授权政府使用，但实际滥用情况持续存在。此前类似案例包括2021年和2023年朝鲜黑客针对安全研究人员的攻击。

注：Trenchant母公司L3Harris未对此事置评。苹果仅在掌握充分证据时会发出此类威胁通知。

AWS服务中断事件分析

事件概述

亚马逊云计算服务（AWS）发生故障，导致全球多个应用程序和网站中断。受影响的平台包括Snapchat、Roblox、Signal、Duolingo以及亚马逊自有业务（如主站和Ring门铃公司）。根据Downdetector监测，全球超过2000家公司受影响，用户报告问题总数达810万次，其中美国190万次、英国100万次、澳大利亚41.8万次。

故障范围与影响

• 受影响地区：问题主要起源于美国东海岸AWS服务区域，随后波及全球。英国劳埃德银行及其子公司、税务海关总署网站、Ring门铃用户均报告服务异常。
• 受影响平台：包括Wordle、Coinbase、Slack、Pokémon Go、Epic Games、PlayStation Network等众多国际平台。
• 问题性质：专家判断此次中断属于技术故障而非网络攻击。亚马逊表示根本原因源于监控负载均衡器的内部子系统故障。

恢复过程

故障发生于英国时间上午8点左右，亚马逊通过AWS状态页面报告错误率升高和延迟。上午10:30英国时间，亚马逊表示服务已出现“显著恢复迹象”，但下午仍报告持续错误。为促进恢复，AWS对其平台请求量实施了限制。至周一晚间，亚马逊宣布所有云服务“恢复正常运行”。

专家观点与风险警示

多位专家强调全球互联网过度依赖少数科技公司的风险：

• 数字权利组织Article 19负责人呼吁云计算服务需多元化，不能将支撑民主言论、独立新闻和安全通信的基础设施依赖于少数公司。
• 未来技术研究所执行主任指出英国关键基础设施不应受制于美国科技巨头，此次故障导致“现代经济从银行到通讯的全面瘫痪”。
• 伦敦大学学院教授认为过度依赖少数公司构成高风险，尽管这些超大规模公司具备提供安全全球服务的资源。

后续反应

• 英国政府：已就故障与亚马逊保持沟通，通过应急响应机制协调处理。
• 国会质询：英国下议院财政委员会致信财政部经济秘书，质问政府为何未将亚马逊列为金融服务业“关键第三方”，以使其接受金融监管。委员会主席指出亚马逊此前曾表示金融客户依赖AWS保障“韧性”并提供“多层保护”。

历史对比

此次事件被置于更广泛的互联网稳定性背景下讨论，文章提及去年因网络安全公司CrowdStrike的软件升级失误导致的全球性Microsoft Windows系统中断，影响机场、医疗服务和企业运营，被称为“史上最大规模中断”。

NASA代理局长肖恩·达菲暗示，NASA可能会绕过SpaceX，选择另一家公司来执行本十年末的载人登月任务。

核心争议与现状：

• SpaceX合同与延误： SpaceX拥有价值29亿美元的合同，负责提供“星舰”作为“阿尔忒弥斯三号”任务的月球着陆器。然而，该火箭目前仍处于早期开发阶段，2025年迄今经历了三次飞行失败和数次成功的亚轨道试飞。
• 进度担忧： 达菲认为SpaceX的进度滞后，可能危及NASA在2027年中前实现载人登月的目标。他强调“我们在与中国竞争”，担心延误会使美国在新的太空竞赛中落后。
• 潜在的合同变更： 达菲表示正在“重新开放合同”，计划让其他航天公司（如蓝色起源）与SpaceX竞争，甚至可能通过信息征询向更广泛的商业航天界征求方案。这可能导致自2021年计划确立以来的一次重大逆转。

关键相关方与替代方案：

• 蓝色起源： NASA已与蓝色起源签订了另一份月球着陆器（“蓝色月亮”）合同，用于更后期的“阿尔忒弥斯五号”等任务。达菲暗示蓝色起源有可能接管“阿尔忒弥斯三号”的任务。蓝色起源回应称已“准备好提供支持”。
• 技术挑战： 业界专家对两家公司的着陆器均表示担忧，指出其设计的复杂性，特别是需要从未尝试过的“在轨加油”技术，可能导致开发时间过长。
• 其他竞标者： 文章提到，阿拉巴马州的Dynetics公司曾是最初竞标月球着陆器合同的公司之一，但目前尚不清楚还有哪些美国公司有能力参与竞争。

时间压力与背景：

• 中美太空竞赛： 此次计划调整的直接背景是中美之间的登月竞赛。中国计划在2030年前实现载人登月，而美国国会鹰派人士担忧“阿尔忒弥斯三号”任务无法在此之前完成。
• NASA的新举措： NASA已要求SpaceX和蓝色起源在10月29日前提交“加速开发方案”，同时将向整个行业征询信息，以寻求加快登月任务节奏的方法。

事件概述
2023年10月16日，外国物体碎片（FOD）撞击了UA1093航班（一架737 MAX飞机）的挡风玻璃，事件发生在约36,000英尺高度。该航班原定从丹佛飞往洛杉矶，事件后改道至盐湖城，飞机随后飞往芝加哥。

调查与响应
WindBorne公司于10月19日晚上11点开始调查，初步判断FOD可能为其气球。周一早上6点（太平洋时间），公司向美国国家运输安全委员会（NTSB）和联邦航空管理局（FAA）发送了初步调查报告，并正与这两个机构合作深入调查。目前没有报告严重伤害或机舱失压。

公司安全记录
WindBorne已成功发射超过4,000个气球，公司成立以来一直与FAA协调，并为每个气球提交NOTAMs（航空警报）。系统设计旨在确保空中碰撞时的安全性，符合FAA Part 101和国际民航组织（ICAO）的重量限制。气球发射时重2.4磅，飞行过程中重量逐渐减轻。

改进措施
WindBorne正与FAA密切合作，立即实施变更以减少气球在30,000至40,000英尺高度区间的时间，这些变更已生效。此外，公司加速推进使用实时飞行数据自主避开飞机的计划，即使飞机处于非标准高度。同时，WindBorne正在研发新硬件设计，以进一步降低冲击力的大小和集中度。

J.P. Morgan向OpenAI提供贷款的奇怪之处

文章探讨了摩根大通等银行在2023年10月向OpenAI提供40亿美元循环信贷额度一事的异常之处。

核心矛盾

OpenAI是一家没有盈利的年轻科技公司，其资本理应主要来自投资者而非银行贷款。通过预期值计算，作者指出：对投资者而言，尽管失败概率高（设为90%），但由于存在巨额成功回报的可能性，投资的预期值为正；但对贷方而言，在相同概率假设和5%利率下，贷款的预期值为显著负值（-895美元），这意味着贷款在平均意义上会亏损。

市场数据验证

作者通过债券市场数据进行反向推导，发现OpenAI获得的约5%贷款利率（基于SOFR+100个基点）对应的信用违约利差仅约1%，这相当于信用评级为A-或BBB级成熟公司的水平。然而，OpenAI的实际财务状况（如负的利息覆盖率）远未达到这一评级标准，其利息覆盖率在评级表中对应的是3.00-4.24的区间，而OpenAI的利息覆盖率为负。

财务背景与最终解释

公开信息显示，OpenAI预计2023年收入36亿美元但亏损超过50亿美元，且目前以低于成本的价格提供服务，盈利路径不明。作为贷方，银行关注的是还款能力，而这取决于公司的盈利能力。

关键洞察在于：银行的贷款实质上并非基于OpenAI自身的信用，而是基于其主要股东微软的信用。文章指出，微软持有OpenAI约28%的股份。如果OpenAI无法偿债而破产，债权人将从股东（包括微软）手中夺取公司控制权。鉴于微软年盈利高达880亿美元且持有OpenAI重要股权，微软极有可能不允许OpenAI违约，而是会代为偿还这40亿美元债务。

结论

因此，这笔看似不合理的贷款（以A-级利率贷给无盈利公司），实质上是银行向拥有AAA信用评级的微软提供的间接贷款。银行预期在OpenAI陷入困境时，微软会介入偿债，从而将贷款的信用风险转移到了微软身上。这解释了为何银行愿意以优惠条件向OpenAI提供贷款。

StarGrid 是一款全新发布的 Palm OS 平台太空主题回合制策略游戏。玩家需在六边形网格上指挥舰队，通过抢占敌旗、智取对手和保卫己方基地来争夺银河控制权，战术决策至关重要。

该游戏支持无 Palm OS 设备的用户通过浏览器内的 CloudPilot 模拟器直接游玩。其开发过程历时半年多，完全从零开始，未使用任何现成游戏引擎或额外 SDK。开发者面临了 Palm 平台特有的技术挑战，例如内存紧张（需在船只移动时隐藏部分图块以节省内存）和代码大小限制（需将应用分割为多个部分），并需从25年前的老代码中搜集参考资料。

开发者通过博客记录了从构思到发布的完整历程，并在多台 Palm 设备上进行了测试。未来，开发者计划探索制作俯视角或街机风格的赛车游戏，以及光线追踪类游戏。

开发此游戏的目的是为了延续对 Palm OS 这一经典掌上系统的热情。游戏已完全开源，代码发布在 GitHub 上，希望能为其他 Palm OS 开发者提供参考。

AI正在让我们工作得更多

核心矛盾：工具与现实

AI本应解放人类、减少工作量，但实际中却导致人们工作得更多。这种“更多工作”主要表现为一种心理上的强制驱动力——AI工具的高效存在似乎创造了新的压力，使人们产生必须不断工作、驱动这台“永不休息的机器”的使命感。

现象表现：996文化的全球化

• 硅谷的转变：AI初创公司开始采用类似“996”（早9晚9，每周6天）的工作模式，理由是“保持竞争力”。
• 文化背景：这种高强度工作模式曾主要与亚洲科技公司关联，如今在西方也被视为应对AI领域快速发展的必要条件。
• 招聘影响：职位描述已开始明确预期员工将面临长时间、高强度的工作。

技术变革：工作限制的消失

• 历史类比：从油灯到电灯，再到大语言模型（LLMs），技术突破不断改变工作的本质。照明技术曾让人能在夜间工作，AI工具则使工作可以不间断进行。
• 心理压力：AI工具“永不疲倦、永不关闭”，导致人们产生“每一刻不利用AI提示都是在落后”的心理循环。休息被视为一种效率损失，休闲变成一种“道德失败”。

哲学视角：内在化压力

• 韩炳哲在《倦怠社会》中提出的观点被引申：现代工作文化已从外部压迫转变为内在的自我规训。
• AI放大了“过度积极”的动态，即“能做，因此必须做”。工具的无限能力转化为个人的无限责任，无需外部鞭策，自我驱动的压力已足够。

潜在危害：身心代价

• 恶性循环：“无限工具+无限杠杆=无限潜力”的心态是腐蚀性的。疲劳不再是休息信号，而是弱点。
• 自我剥削：人们成为自己的监工，从早到晚必须利用每一刻，导致创新力下降、倦怠率上升。
• 期望升级：随着AI工具改进，对产出的基准期望也随之提高，过去“足够好”的产出现在变得“不够”。

解决路径：将休息视为抵抗

• 在AI赋予近乎无限生产能力的时代，主动选择休息和设定边界成为一种激进的抵抗行为。
• 研究表明，创新和创造力源于反思而非精疲力竭，最佳想法通常产生于思绪自由游荡时。
• 关键不仅在于学习如何利用AI工具，更在于学习与工具健康共处，避免被其奴役。

核心结论

这篇文章认为，问题的根源在于文化而非工具本身。机器不在乎人是否休息，真正让人无法休息的是社会对“生产力”的定义。AI时代的主要挑战是重新定义我们与这些强大工具的关系，防止它们侵蚀人性。

https://news.ycombinator.com/item?id=45657345

研究概述

研究人员使用一套消费级设备（卫星碟、调谐卡和电机）对地球同步轨道卫星通信进行了全面公开研究。结果发现，大量敏感数据在未加密的情况下被广播，任何拥有几百美元设备的人都可以被动窃听。数据来自一个转发器，其覆盖范围可达地球表面积的40%。

暴露的数据类型

研究观察到以下类型的未加密卫星回程流量：

1. 蜂窝回程：电信运营商核心网络发往偏远地区基站的流量，包括未加密的通话、短信、用户上网数据、IMSI和加密密钥。
2. 军事与政府：来自船舶的未加密VoIP和网络流量、用于沿海船舶监视的军事系统数据以及警察行动数据。
3. 机上WiFi：飞往飞机乘客的未加密互联网流量，包括网页浏览、DNS查询和HTTPS流量。
4. VoIP：多家VoIP提供商使用未加密的卫星回程，暴露了用户的通话音频和元数据。
5. 商业内部网络：零售、金融和银行公司的内部网络通信，包括登录凭证、企业邮件、库存记录和ATM网络信息。
6. 关键基础设施：电力公司和油气管道利用GEO卫星链路支持远程SCADA基础设施和电网维修工单。

技术方法与发现

• 方法：在屋顶固定位置设置设备，扫描可见的所有转发器，并编写自定义代码逆向工程不同供应商的专有协议栈以重构网络数据包。
• 范围：从固定位置观测到来自39颗GEO卫星的411个转发器，其单个碟形天线可接收全球14%的Ku波段卫星的IP流量。
• 为何未加密：原因包括加密带来的带宽开销、远程接收器的功耗限制、许可证费用、增加故障排查难度，以及部分用户可能低估风险或不知情。一些供应商表示正在向加密链路过渡。
• 与LEO卫星区别：本研究聚焦GEO卫星系统（因其可靠性仍被广泛用于关键基础设施），未研究星链等LEO系统（认为其链接已加密，但未经独立验证）。
• 法律与伦理：研究获得大学法律部门指导，为被动接收，未干扰卫星，并进行了负责任的漏洞披露。

影响与建议

• 终端用户：无法感知上游是否加密。大多数网页流量已被设备端TLS/QUIC加密。用户可使用VPN加密自身流量，并使用端到端加密应用进行通信。
• 使用卫星通信的组织：应将卫星链路视为不安全的公共网络。应在每一层实施加密（如TLS保护应用流量，IPsec加密网络），并将加密视为强制性要求而非可选功能。可参考NSA的VSAT安全建议。

漏洞披露与修复

• 研究团队努力识别责任方并披露漏洞。例如，T-Mobile、沃尔玛和KPU已确认并部署了修复措施。
• 遵循行业标准的90天披露窗口，部分案例的披露仍在进行中。截至2025年10月13日，正逐步更新相关信息。

Harnessing diamond thermal conductivity in chips slashes temperatures, enabling powerful AI and computing advancements without overheating.

一项新研究发现，自2015年更新医疗指南建议早期向婴儿引入花生制品以来，已有约6万名儿童避免了花生过敏的发展。

这项于2015年首次发布的指南颠覆了医疗实践，它建议最早在婴儿4个月大时引入花生这一过敏原。研究作者、费城儿童医院的过敏症专科医生及研究员David Hill博士表示，这是一个显著的成果。他和同事分析了数十家儿科诊所的电子健康记录，追踪了指南发布前、发布期间及发布后幼儿食物过敏的诊断情况。

研究发现，在2015年针对高风险儿童发布指导后，0至3岁儿童的花生过敏率下降了超过27%；在2017年该建议扩展后，下降幅度超过40%。然而，这一努力尚未扭转美国近年来食物过敏总体上升的趋势，目前约有8%的儿童受此影响，其中超过2%患有花生过敏。

花生过敏是由于免疫系统错误地将花生中的蛋白质识别为有害物质，并释放化学物质引发过敏反应，症状包括荨麻疹、呼吸道症状，有时甚至危及生命的过敏性休克。数十年来，医生一直建议将花生及其他易引发过敏的食物推迟到3岁再引入儿童饮食。但2015年，伦敦国王学院的Gideon Lack发表了开创性的“早期了解花生过敏”试验，显示在婴儿期引入花生制品可将未来发展食物过敏的风险降低超过80%。

这项研究立即催生了新指南，敦促早期引入花生，但将其付诸实践的过程缓慢。调查发现，仅有约29%的儿科医生和65%的过敏症专科医生遵循了2017年发布的扩展指南。一篇随研究发表的评论指出，对如何在婴儿早期引入花生的最佳方式感到困惑和不确定，导致了执行上的滞后。该评论由西北大学儿童过敏症专家Ruchi Gupta博士领导，同时指出本次分析的数据来自部分参与的医疗实践站点，可能无法代表全美儿科人群。

尽管如此，新研究提供了“有希望的证据，表明早期引入过敏原不仅正在被采纳，而且可能正在产生可衡量的影响”。这项研究强调了于2021年更新的现行指南，该指南呼吁在4至6个月之间引入花生及其他主要食物过敏原，无需事先筛查或检测。Hill博士建议，家长应就任何疑问咨询儿科医生，并指出引入的量不必很多，“一点花生酱、奶制品酸奶、豆制品酸奶和坚果酱是让免疫系统安全接触这些过敏性食物的好方法”。

People with a leading cause of blindness were able to read again thanks to a tiny wireless chip implanted in the back of the eye and specialized augmented glasses, according to study results published Monday in the New England Journal of Medicine.

文章《Just Use Curl》主要内容总结

核心主张

作者强烈反对使用Postman、Insomnia等基于Electron的重型HTTP客户端工具，主张回归使用预装在系统中的轻量级命令行工具cURL来处理HTTP请求。

批评现代HTTP工具的主要问题

• 资源浪费：需要下载数百兆的Electron应用，启动缓慢（如Postman启动耗时长），占用大量系统资源（内存、存储）
• 不必要的复杂化：将简单的HTTP请求功能包装成臃肿的桌面应用，需要Chromium实例渲染
• 商业限制：基本功能可能需要"企业"订阅或强制账户创建（如同步功能）
• 低效交互：复杂的GUI界面（多标签页、工作区、环境下拉菜单）不如命令行直接高效

强调cURL的优势

1. 预装即用：已存在于大多数系统中，无需额外下载安装
2. 功能全面：支持所有HTTP操作（POST请求、自定义头部、文件上传、Cookie管理、重定向、认证等）及多种协议（HTTP/2、HTTP/3、FTP、SFTP、SMTP等25+协议）
3. 高效轻量：执行速度快（毫秒级），安装体积小（约2MB），资源消耗极低
4. UX简化：命令行界面直观，历史记录在shell中，"集合"就是shell脚本，"环境变量"是系统原生功能
5. 协作友好：基于文本的命令可轻松通过Git进行版本控制、共享和协作

回应常见质疑

• 请求历史：通过history | grep curl或保存在脚本文件中管理
• 请求组织：使用目录结构组织shell脚本文件
• 语法记忆：可通过man curl、--help或在线搜索快速查阅
• 团队协作：文本文件天然适合Git版本控制，比图形化工具的专有格式更灵活
• 测试自动化：可结合shell脚本和编程语言（如Python）实现，使用||、&&进行流程控制
• 特殊需求：如GraphQL请求，可通过管道配合jq等工具处理JSON响应

最终结论

cURL是经过数十年验证、下载超过200亿次、维护可靠的网络工具。作者呼吁停止使用资源浪费的"臃肿垃圾软件"，避免为基本功能创建账户，直接使用cURL处理HTTP请求。

苹果在iOS 26.1、iPadOS 26.1和macOS Tahoe 26.1的第四个测试版中，引入了一项新设置，允许用户自定义“液态玻璃”（Liquid Glass）界面的外观。

• 新功能核心：新增了一个切换选项，让用户可以在两种液态玻璃视觉样式间选择：“透明”（Clear）和“着色”（Tinted）。
  • 透明：即当前默认的液态玻璃设计，透明度较高，可以透出按钮、菜单栏和通知背后的背景。
  • 着色：会提高液态玻璃的不透明度，并增加视觉对比度，使其看起来更实在。
• 设置路径：
  • 在iOS或iPadOS上：前往“设置” > “显示与亮度”。
  • 在Mac上：前往“系统设置” > “外观”。
• 推出原因：苹果表示，在夏季的测试期间收到用户反馈，一些人希望有更不透明的液态玻璃选项，因此增加了此设置以提供更多自定义空间。
• 影响范围：该透明度调整将应用于整个操作系统，包括所有App和锁屏通知。
• 其他更新：iOS 26.1还包含其他新功能，例如闹钟和定时器的“滑动停止”功能、新的Apple Intelligence支持语言、重新设计的Apple TV应用图标以及设置App的更改等。

文章摘要：LLM是否应将文本内容视为图像？

本文探讨了“光学压缩”（optical compression）这一概念，即通过将文本转换为图像来提升大语言模型（LLM）处理信息的效率，并分析了其原理、潜在优势与挑战。

核心观点

1. 光学压缩的概念：DeepSeek的一项OCR研究指出，一个图像token可以以近100%的准确率提取出10个文本token的信息。这意味着图像的内部表示效率远高于文本。基于此，提出了一个设想：在推理时，是否将文本以图像形式输入模型，能比直接输入文本支持多10倍甚至20倍的数据量？
2. 原理与为何可行：
   • 离散与连续的差异：文本token是离散的（有限词汇表，每个token对应一个高维向量），而图像token的嵌入是连续的，理论上能表达更丰富的信息。
   • 表达效率：文本token虽然在传递时高效（只需发送token ID），但其在模型内部的展开表示实际上编码了大量语义和用法信息，从信息密度角度看并非最高效。图像token可能是一种更紧凑的内部表达方式。
   • 类似人类处理方式：人类本质上是通过视觉（图像）来阅读文本，而非直接处理文本符号。将文本视为图像子类，可能解锁新的处理路径。
3. 应用与类比：
   • 与通过加速音频以节省推理成本的思路类似，光学压缩是通过将文本截图（甚至降低分辨率）来减少token消耗。
   • DeepSeek论文建议，随着上下文增长，可以逐渐降低较旧图像的分辨率来节省资源，这类似于人类记忆——新记忆清晰，旧记忆模糊。
   • 类似思路也应用于其他领域，如将鸟叫声转换为声谱图（一种图像）再用CNN处理，而非直接处理音频流。
4. 现状与挑战：
   • 目前已有公司、开源项目和基准测试在尝试用多模态LLM进行“文本即图像”处理，效果尚可，但并非模型的预期用途。
   • 主要挑战在于训练：传统的LLM训练基于预测下一个文本token，相对直接。而如果完全基于文本图像来训练模型（例如，预测下一个单词的图像），可能非常缓慢且验证困难。若模型最终仍需要输出文本token，则可能又回到了传统LLM的训练范式。
5. 观点分歧：该想法在技术社区引发讨论，存在怀疑者，也有声称已成功实践的支持者。

总结

光学压缩提出了一个颠覆性的思路：利用图像在模型内部的高效表征来压缩文本信息，可能大幅提升LLM的上下文处理能力。其理论基础在于文本与图像token在表达效率上的本质差异，以及与人类认知方式的相似性。然而，从现有模型的适配挑战到全新的训练范式难题，这一概念距离成为成熟技术仍存在显著障碍，目前更多是一个充满潜力的研究方向。

Practical Scheme 项目概述

该网站旨在汇集将Scheme作为生产工具使用的库和扩展。其目标是帮助系统工程师和程序员处理日常事务，如文件解析、生成报告、进程监控和创建小型GUI工具等。作者个人主要使用Perl，但希望将Scheme用于这些场景。

项目内容多为作者的私人项目，部分为测试和实用目的会发布早期版本。无任何保修，但希望对他人有用。日语版页面包含Lisp/Scheme相关文章的翻译。

应用与工具

• Gauche：目标是成为便捷的脚本引擎的R7RS Scheme实现，具有快速启动、内置系统接口和原生多语言支持等特性。
• WiLiKi：使用Scheme编写的Wiki引擎。
• escm：一个过滤程序，可复制输入文本到输出，同时处理其中内嵌的Scheme表达式。程序本身独立于任何Scheme实现。其新版本aescm正在开发中。

库与扩展

以下库主要为Gauche编写：

• Gauche-gl：Gauche的OpenGL绑定，支持OpenGL 1.0至4.1的大部分API（包括着色语言），以及部分GLU和GLUT API。
• Gauche-gtk2：Gauche的GTK2绑定。

文档与资源

• 文档：包含各类Scheme实现的库过程交叉参考、CommonLisp的实际应用文章（关于生产跟踪数据库）、关于在最终幻想电影制作中跟踪资产的文章、关于Scheme在实时CG制作中应用的论文（ILC 2002）、关于动态脚本语言中浮点数高效处理的论文（DLS 2008），以及向非Scheme程序员解释Scheme优点的文章。
• 其他资源：列出了多个Scheme相关资源站点，如：
  • schemers.org：获取Scheme标准（R*RS）和SRFI（通用库接口）的中心。
  • SCM：紧凑、快速、可移植的Scheme解释器。
  • SLIB：大型可移植Scheme库集合。
  • Bigloo：带有编译器和IDE的Scheme系统，适用于企业级软件开发。
  • Guile：GNU采用的Scheme扩展语言环境。
  • scsh：适用于系统编程的工具。
  • Kawa：基于Java的Scheme系统，将Scheme代码编译为Java字节码。

NASA因SpaceX进度滞后，决定重新开放Artemis III登月舱合同竞争，并将载人登月时间推迟至2029年。

核心要点：

• 进度延迟：NASA代理局长承认SpaceX在开发人类着陆系统（HLS）方面落后于计划，原定的2027年登月目标已不现实，新目标调整为2028年底或2029年初。
• 合同重新开放：NASA宣布将Artemis III登月舱合同向竞争者开放，以加快进度并确保在特朗普政府任期内（至2029年）实现登月。Blue Origin被明确列为潜在替代方案。
• SpaceX的回应：马斯克反驳称SpaceX进展迅速，并断言星舰将最终承担整个月球任务。
• 背景与挑战：SpaceX的星舰开发过程中遭遇多次意外爆炸，仅完成两次亚轨道试飞，距离登月要求仍有巨大差距。NASA安全咨询小组此前已对星舰HLS的准备情况表示严重质疑。
• 竞争格局：SpaceX于2021年赢得登月舱合同，击败了Blue Origin和Dynetics。Blue Origin因不满结果曾提起诉讼但被驳回。目前，Blue Origin已计划在2030年执行Artemis V登月任务。
• 预算问题：在NASA现有预算已面临压力的情况下，如何为加速登月计划提供额外资金成为关键疑问。

并发模型演变：从“线程每核”到动态工作窃取

本文探讨了在数据处理领域中，并发模型从“线程每核”主流趋势向包含工作窃取的共享状态并发模型转变的讨论与原因。

编程语言异步运行时中的模型对比

在异步运行时（如Rust）中，任务可以“让出”并生成新的工作项，这些工作项会被放入队列。两种主要并发模型的核心区别在于：

• 线程每核模型：工作项绑定到特定线程的本地队列，不允许跨线程移动。
• 工作窃取模型：当某个线程空闲时，可以从其他线程的队列中“窃取”任务，实现负载均衡。

工作窃取模型的关键特性包括：

1. 可迁移性：任务必须能够安全地跨线程边界移动（在Rust中体现为Future需要实现Send trait）。
2. 负载均衡：有效避免因任务分配不均导致部分CPU核心闲置。
3. 局部性牺牲：允许任务迁移可能会破坏数据局部性，影响缓存共享效率。

数据处理领域的趋势与转变

过去几年，线程每核模型在数据处理中占据主导，其优势在于：

• 数据分区与缓存优化：通过预先将数据分区到各线程，使数据能更好地驻留于CPU缓存中，减少跨核通信（如缓慢的MESI协议消息）和开销。
• 简化实现：限制了并行点，使代码结构更简单。

然而，近年来对此模型的质疑声增加，动态工作窃取或共享状态模型重新获得关注。支持转向的理由主要基于以下几点：

1. 硬件与需求变化：
   • 核心数量增加：高端机器核心数增长，若数据分布倾斜（skew），静态分区导致的负载不均问题会更严重。
   • 瓶颈转移：IO延迟等传统瓶颈大幅改善，CPU利用率成为更关键的优化目标。
2. 任务的可操控性：
   • 在数据处理中，调度器对工作负载有更强的预测和内省能力，可以对任务进行代数操作（如合并或拆分），这为实现更智能的动态调度提供了可能。
3. 系统弹性与文化因素：
   • 现代数据系统需要扩展并处理多租户等场景，数据倾斜可能来自不可控因素。将问题推给上层（“在更高层解决倾斜”）不再是有效策略，系统本身需要内置弹性处理能力。

总结

文章指出，尽管“线程每核”模型因缓存友好和实现简单曾受青睐，但随着多核普及、IO瓶颈缓解以及对系统弹性和负载均衡要求的提高，数据处理领域正重新评估共享状态与工作窃取并发模型的价值。这种转变的核心驱动力在于：在核心数增长和数据倾斜更常见的环境下，动态任务调度能更有效地利用CPU资源并保证处理效率。

本文探讨了如何仅使用两个UNIX信号（SIGUSR1和SIGUSR2）构建一个简单的消息队列系统，作为进程间通信（IPC）的实验性方法。文章首先介绍了UNIX信号的基本概念，如SIGTERM、SIGINT等，并指出SIGUSR1和SIGUSR2是用户定义信号，适合用于自定义通信。作者通过二进制编码演示了信号如何携带数据：将SIGUSR1映射为二进制0，SIGUSR2映射为1，从而将字符转换为二进制序列进行传输。

文章详细描述了实现过程，包括构建接收器和发送器的Ruby脚本。接收器捕获信号并解码二进制数据，转换为ASCII字符输出；发送器则将字符串编码为二进制并发送相应信号。为了处理消息边界，引入了NULL终止符（字节00000000）来标记消息结束。作者进一步扩展系统，实现了包含代理（Broker）、消费者（Consumer）和生产者（Producer）的完整消息队列。代理负责接收和路由消息，消费者处理消息，生产者发送消息，所有通信均通过信号进行。

关键组件SignalCodec模块封装了编码和解码逻辑，包括位累加、信号发送和消息处理。文章强调了该项目的实验性质，旨在展示基础技术原理（如二进制操作和IPC），而非生产应用。最终，作者总结了通过实践理解底层机制的重要性，并鼓励类似的技术探索。

NORAD夏延山作战中心（约1966年）

历史背景与建设原因

• 成立时间：1966年，北美防空司令部（NORAD）位于科罗拉多州夏延山的地下设施正式成为美国应对冷战核威胁的指挥控制中心。
• 建设需求：随着冷战升级，原有地面指挥中心空间不足且易受攻击。1956年，美国决定在夏延山建造地下加固的作战中心（COC），以应对苏联洲际弹道导弹（ICBM）威胁，并实现防空系统的自动化管理。
• 建设进程：工程于1961年6月启动，1962年8月基本完成挖掘，1964年5月全面竣工。该中心至今仍被多个军事和情报机构使用。

设施设计与防护能力

• 地下加固：中心建于夏延山内部，设计可抵御多兆吨级核武器攻击，并具备防辐射、生物化学战及外部破坏的能力。
• 独立生存系统：可在封闭状态下运行30天，配备自备发电厂、水处理系统、生活区、医疗设施及储水储油罐（包括35万加仑柴油、137.5万加仑饮用水和412.5万加仑工业用水）。
• 抗震减震设计：建筑安装于大型钢制弹簧（约900个，每个重1000磅）和液压减震器上，以吸收核爆炸或地震冲击波。

技术装备与功能

• 计算与显示系统：安装了菲利普212计算机（最多三台）、15个控制台和大型显示板，用于自动化处理空情、武器状态、卫星轨迹等信息。
• 指挥控制：显示屏幕可实时展示美加两国遭受空袭的迹象，作战人员通过按钮即可查看卫星或飞机轨迹，由计算机自动绘制。
• 卫星追踪：配备贝克-努恩相机等设备，可追踪距离地球2.5万英里外的篮球大小物体，数据由美国空军、加拿大力量及史密森天体物理观测台共同提供。
• 通信网络：包括抗冲击无线电天线和微波天线，连接外部世界，确保与上下级及横向指挥机构的通信备份。

指挥职能与运作

• 核心任务：作为北美防空警报的第一响应点和指挥所，负责评估大陆威胁、发出攻击预警并指挥美加防空部队作战。
• 高层指挥：由NORAD总司令（如美国空军将军Seth J. McKee）和副司令（加拿大部队中将）共同值守，协调两国防御力量。
• 历史访问：1969年9月，美国总统理查德·尼克松成为首位访问该地下指挥中心的总统，期间在太空防御中心听取汇报。

附录：关键设施图片说明

• 结构隔离：11栋建筑通过门厅连接，但互不接触，且不与山体天花板或墙壁直接接触，全部由钢弹簧支撑。
• 通信天线：山坡上建有抗冲击无线电天线，通过微波链路与地下中心连接，使用大量水泥和钢筋加固。
• 减震系统：展示三英寸直径钢弹簧和液压减震器，用于吸收冲击波。
• 显示与操控界面：显示屏幕及控制台，用于实时监控空中和太空目标。

（摘要严格基于提供的文章内容，涵盖历史背景、设施设计、技术系统和指挥功能等核心要点。）

美国国际象棋大师丹尼尔·纳罗季茨基于29岁去世

2025年10月21日，美国国际象棋特级大师、广受欢迎的YouTube国际象棋解说员丹尼尔·纳罗季茨基去世，年仅29岁。其俱乐部夏洛特国际象棋中心发布声明，称其家人宣布了这一“意外”死亡，但未提供死因。

纳罗季茨基被国际象棋界称为“达尼亚”，在线上拥有巨大影响力。他的YouTube频道拥有近50万订阅者，Twitch直播拥有34万粉丝，以教学视频和直播对战闻名，激励了全球数十万人学习国际象棋。国际棋联称其“在国际象棋内容在线普及方面发挥了关键作用”。

世界排名第二的国际象棋棋手中村光称其为“国际象棋界的重大损失”，称赞他“在帮助初学者制作国际象棋内容方面是最好的”，并回忆道“与丹尼尔下过上千盘棋，在胜负心强烈的国际象棋界，他总是很平静”。另一位国际象棋特级大师兼内容创作者周嘉娜称他是“榜样”，以其“让国际象棋变得有趣”的方式、对棋史的深刻了解以及“处处流露的善意”而闻名。

纳罗季茨基的国际象棋生涯始于6岁。他于2007年获得世界青少年锦标赛12岁以下组冠军，14岁时出版《掌握局面性国际象棋》一书。青少年时期，在赢得2013年美国少年锦标赛冠军后，他获得了国际象棋特级大师称号。他毕业于斯坦福大学，后在夏洛特担任国际象棋教练，并于2022年成为《纽约时报》的国际象棋专栏作家。

数百名业余棋手向他致敬。20岁的英国粉丝扎拉·格雷厄姆表示，正是纳罗季茨基的视频激励她14岁时开始定期下棋，“他是一位杰出的国际象棋老师，用通俗易懂的方式讲解”。

他的离世被广泛认为是国际象棋界的重大损失。

在NVIDIA Spark上通过Claude Code强制运行DeepSeek-OCR模型

项目背景：DeepSeek发布了专门用于OCR的6.6GB模型DeepSeek-OCR，需在PyTorch和CUDA环境下运行。作者尝试在NVIDIA Spark设备上部署该模型，但遇到硬件兼容性问题。通过使用Claude Code（一个AI编码助手）在Docker沙箱中自动探索解决方案，最终成功运行。

操作流程：

1. 环境搭建：通过SSH连接到NVIDIA Spark，启动NVIDIA CUDA Docker容器，安装npm和Claude Code。
2. 初始化提示：向Claude Code提供明确指令，包括克隆GitHub仓库和Hugging Face模型、在ARM架构设备上研究可行性、生成操作笔记和README文件，并指定一个测试图像用于OCR。
3. 遇到障碍：Claude Code发现PyTorch 2.5.1不支持NVIDIA GB10 GPU的计算能力（sm_121），且模型硬编码了CUDA调用，无法回退到CPU运行。
4. 解决问题：在作者提示下，Claude Code查询了PyTorch版本库，发现PyTorch 2.9.0提供了支持CUDA 13.0的ARM64轮子。安装后，虽然出现兼容性警告，但模型成功加载并执行了OCR。
5. 优化输出：最初使用<|grounding|>OCR this image提示词获得带边界框的结果，但文本输出为空。后续尝试不同提示词（如Markdown转换、自由OCR等），生成了比较指南和性能基准表。

关键技术点：

• PyTorch版本升级：从默认的PyTorch 2.5.1切换到2.9.0，解决了CUDA内核兼容性问题。
• 提示词实验：测试了四种提示词模式，发现“Free OCR”速度快、文本质量好；“Markdown”模式适合文档结构提取；“Grounding”模式提供完整坐标但速度较慢。
• 自动化流程：Claude Code生成了多个脚本（如setup.sh、run_ocr.py）、笔记文件（notes.md）和最终总结（README.md），形成了可复现的操作文档。

项目成果：

• 成功在NVIDIA Spark上运行DeepSeek-OCR模型，完成了图像OCR任务。
• 生成了完整的项目文件夹，包含脚本、笔记、输出结果和指南文档。
• 总结了成功关键因素：提供明确的Docker环境和指令、利用沙箱权限允许AI自主操作、在卡住时根据经验提供提示。

其他收获：

• 作者在40分钟内完成项目，仅主动参与5-10分钟，验证了AI辅助编码在复杂环境配置中的效率。
• 发现DeepSeek-OCR模型在合理提示下表现良好，具有实用价值。
• 通过VS Code的远程SSH和Dev Containers扩展，实时监控了Docker容器内的文件变化，简化了调试过程。

总结：本项目展示了通过AI编码助手解决硬件兼容性问题的可行性，突出了清晰指令、沙箱环境和适时人工干预的重要性。

# Rust模块化高性能Merkle树库摘要

## 核心特性
- **固定深度**：所有Merkle证明大小恒定，等于树的深度。
- **仅追加**：叶子节点从索引0开始顺序添加，已添加的叶子不可修改。
- **证明检索优化**：中间叶子被预先存储，使得Merkle证明可直接从内存获取，无需临时计算，检索速度极快。
- **可配置后端**：支持多种存储后端来存储底层和中间叶子节点直至根。
- **可配置哈希函数**：支持不同的哈希函数进行节点哈希。
- **简洁接口**：主要接口包括 `add_leaves`、`root`、`num_leaves`、`proof`。

## 基本使用
1.  在 `Cargo.toml` 中添加依赖：`rs-merkle-tree = "0.1.0"`。
2.  创建树、添加叶子、获取根哈希、叶子数量及特定索引的证明。默认使用 Keccak256 哈希、内存存储和深度32。

## 自定义配置
通过修改依赖的 `features` 选择不同的存储后端，并在代码中指定哈希函数、存储实现和深度。
- **存储后端**：支持 `rusqlite`、`rocksdb`、`sled`。
- **哈希函数**：支持 `keccak256` 和 `Poseidon BN254 Circom T3`。

示例：
- 使用 `sled` 存储和 `Keccak256` 哈希：需启用 `sled_store` feature。
- 使用 `rocksdb` 存储和 `Poseidon` 哈希：需启用 `rocksdb_store` feature。
- 使用 `sqlite` 存储和 `Poseidon` 哈希：需启用 `sqlite_store` feature。

## 性能基准测试
在AMD Ryzen 7 7700处理器（64GB RAM）上测试深度32、一百万叶子节点的情况：

### 磁盘空间占用
| 存储后端 | 占用大小 (MiB) |
|----------|----------------|
| sled     | 290.00         |
| sqlite   | 159.18         |
| rocksdb  | 183.27         |

### `add_leaves` 吞吐量
| 哈希函数 | 存储后端 | 吞吐量 (千叶子/秒) |
|----------|----------|---------------------|
| keccak256| rocksdb  | 18.280              |
| keccak256| sqlite   | 22.348              |
| keccak256| sled     | 43.280              |
| keccak256| 内存     | 86.084              |

### 证明生成时间
| 哈希函数 | 存储后端 | 时间     |
|----------|----------|----------|
| keccak256| 内存     | 560.990 ns |
| keccak256| sled     | 7.878 µs   |
| keccak256| sqlite   | 14.562 µs  |
| keccak256| rocksdb  | 34.391 µs  |

## 许可证
采用 MIT 许可证。

TernFS：EB级多区域分布式文件系统概述

TernFS是XTX公司为满足其大规模算法交易和机器学习需求而自主研发的分布式文件系统，已开源。其设计旨在解决传统文件系统（如NFS）在EB级存储、海量文件和高并发场景下的扩展性瓶颈。

设计动机与目标

• 业务需求驱动：XTX从几台桌面服务器发展到拥有数万GPU、数十万CPU和数百PB存储的规模，现有文件系统无法满足需求。
• 关键目标：
  • 支持EB级存储、万亿文件、百万并发客户端。
  • 通过冗余存储保护数据免受驱动器故障影响。
  • 元数据服务无单点故障。
  • 支持文件快照以防误删。
  • 跨多个区域部署。
  • 硬件无关，使用TCP/IP通信。
  • 高效利用不同类型存储（如闪存与硬盘）。
  • 提供自有TCP/UDP API和Linux内核模块访问方式。
  • 无外部依赖，构建简单。

主要限制

• 文件不可变：文件写入后不可修改。
• 不适用于小文件：中位文件大小为2MB。
• 目录操作吞吐量较低：目录创建/删除性能受限。
• 无内置权限管理：需由外部服务处理。

核心架构

TernFS由四个核心服务组成：

1. 元数据分片：

   • 存储目录结构、文件元数据及文件到块的映射。
   • 逻辑上分为256个分片，每个分片由5个物理实例（1个主节点+4个从节点）组成，采用自研Raft变体LogsDB和RocksDB实现分布式共识。
   • 分片按目录分配，采用轮询策略，简化了横向扩展。

2. 跨目录协调器：

   • 处理跨分片的事务，如目录创建/删除、跨目录移动。
   • 使用与元数据分片相同的状态存储技术。
   • 是目录操作的性能瓶颈。

3. 块服务：

   • 存储文件内容。文件被分割为块，每个块通常对应一个物理驱动器。
   • 通过TCP API提供读写访问，硬件无关的Go实现。

4. 注册表：

   • 存储所有服务实例的位置信息（IPv4地址）。
   • 客户端通过它发现其他服务。
   • 使用LogsDB和RocksDB实现。

关键技术与实现

数据可靠性

• 校验和：所有块均使用CRC32-C校验和，并与4KiB页面交错存储，支持部分读取和本地检查。
• 冗余存储：文件通过Reed-Solomon编码或简单镜像实现冗余。策略（数据块D、奇偶校验块P）由目录策略定义。
• 块证明：通过加密签名机制确保客户端操作（写/删）的正确性，防止因客户端错误导致数据损坏或丢失。

存储优化

• 驱动器类型选择：根据目录策略和块大小，将大文件（顺序访问）存于硬盘，小文件或随机访问文件存于闪存。
• 块服务选择：
  • 基于故障域（如服务器）分散块存储，提高容错性。
  • 根据可用空间、写负载均衡和分片分配策略选择驱动器。
  • 当前未使用复制集，依赖快速驱动器迁移和多数据中心复制来保障数据安全。

多区域支持

• 各区域最终趋向相同数据集，异步复制。
• 元数据复制：设有一个主区域，非主区域写入需主区域确认。
• 文件内容：本地写入，通过主动复制（尾随元数据日志）和按需复制同步到其他区域。

访问方式

• 自有API：基于bincode序列化格式，无状态设计，元数据和CDC使用UDP，块服务和注册表使用TCP。
• Linux内核模块：暴露为POSIX风格文件系统，支持从左到右写入文件，适用于大量机器学习工作流。
• S3网关：通过S3 API暴露TernFS子树，便于多租户和非本地网络访问。
• Web UI和JSON接口：提供管理界面和脚本化访问。

数据维护与恢复

• 目录策略：控制冗余类型、存储介质、快照保留时间等，并支持继承。
• 清理器：持续扫描所有块，检测并替换坏扇区。
• 快照与垃圾回收：文件删除后转为快照（弱引用），由垃圾回收器定期清理过期快照以释放空间。
• 迁移器：自动或手动标记故障驱动器，将其数据迁移至健康驱动器。

监控与运维

• 提供丰富的性能指标（InfluxDB格式）、日志和集成告警。
• 支持自动和手动的驱动器故障检测与迁移。

生产部署现状

截至2025年9月，TernFS已在XTX生产环境存储超过500PB数据，分布于3个数据中心、3万硬盘和1万闪存驱动器，峰值吞吐量达数TB/s，且未发生数据丢失。

# Geoutil.com 摘要

Geoutil.com 是一个**完全在浏览器中运行**的免费地理数据处理工具集合，专注于保护用户隐私，所有数据处理均在本地完成，无需上传服务器。

## 核心特点
- **100% 浏览器端处理**：数据永不离开用户设备，无隐私风险。
- **完全免费**：无需注册，所有工具均可直接使用。
- **专业级质量**：适用于 GIS 专业人士、开发者及地理爱好者。
- **即时处理**：本地运行，无需等待服务器响应。
- **支持开放标准**：兼容 GeoJSON、TopoJSON、Shapefile、KML、WKT、CSV 等多种格式。

## 主要工具类别

### 1. 测量工具
- **距离工具**：计算地球上两点间的大圆距离，适用于飞行路径、航运路线等。
- **地球仪距离工具**：在交互式 3D 地球仪上可视化大圆路径，展示地球曲率效应。
- **面积工具**：基于球面几何测量区域真实表面积，支持多边形绘制或 GeoJSON 上传。
- **方位角工具**：计算两点间的罗盘方位（正反向方位角），用于导航和制图。
- **要素统计工具**：分析 GeoJSON 文件的统计信息（要素数量、几何类型、坐标数、边界框等）。

### 2. 格式转换器
- **GeoJSON ↔ TopoJSON**：相互转换，TopoJSON 可大幅压缩文件大小（减少 80% 以上）。
- **GeoJSON ↔ WKT**：支持标准 WKT 和带 SRID 的 EWKT 格式。
- **Shapefile → GeoJSON**：将 ZIP 格式的 Shapefile 转换为 GeoJSON。
- **KML → GeoJSON**：将 Google Earth KML 文件转换为 GeoJSON，保留名称和样式信息。
- **CSV → GeoJSON**：将含经纬度的 CSV 表格转换为 GeoJSON 点要素。
- **GeoJSON → 图像**：导出为 SVG、PNG 或 JPEG 格式。
- **坐标参考系转换**：支持 500+ 种 EPSG 坐标参考系（如 WGS84、UTM 等）。
- **坐标格式转换**：在十进制度、度分秒、UTM、MGRS 等格式间转换。
- **坐标提取**：从 GeoJSON 提取坐标并导出为 CSV。

### 3. 文件合并器
- **GeoJSON 合并器**：合并多个 GeoJSON 文件为单一 FeatureCollection。
- **TopoJSON 合并器**：合并多个 TopoJSON 文件并保持拓扑结构。
- **JSON 合并器**：合并任意 JSON 文件（适用于配置、数据导出等）。
- **Shapefile 合并器**：合并多个 Shapefile ZIP 包，自动处理属性对齐。

### 4. 数据分割器
- **GeoJSON 分割器**：按要素属性（如国家、区域）分割 GeoJSON 文件，支持批量导出为 ZIP。
- **TopoJSON 分割器**：按对象或属性分割 TopoJSON 并保持拓扑有效性。

### 5. 数据压缩器
- **GeoJSON 压缩器**：减少 50-80% 文件大小（移除空白、降低坐标精度等）。
- **TopoJSON 压缩器**：通过量化、弧线简化等高级技术压缩文件（压缩率可达 90%+）。
- **JSON 压缩器**：移除所有空白字符以实现最大压缩。

## 隐私与安全
- 所有工具在浏览器中通过 JavaScript 运行。
- 数据**永不上传服务器**，始终留在用户设备上。
- 网站无法查看用户处理的数据。
- 首次加载后支持离线使用。
- 仅使用匿名页面访问分析，无其他追踪。

## 典型应用场景
- **GIS 专业人士**：格式转换、数据集合并、坐标系转换、数据验证。
- **Web 开发者**：为 Web 地图准备 GeoJSON、减小文件大小、转换遗留格式。
- **数据分析师**：提取坐标至 CSV、计算面积、分析地理数据。
- **教育工作者**：演示地图投影、解释坐标系、可视化距离。
- **研究人员**：无需云服务即可处理地理数据，保持数据隐私。

## 使用方法
1. 从导航菜单选择工具。
2. 上传或粘贴数据（多数工具支持拖放）。
3. 可选配置选项（多数工具提供智能默认值）。
4. 下载结果——即时处理，无需等待。

所有工具页面均提供详细文档、使用示例及常见问题解答。

Marginalia Search 的语言支持概述

项目目标

Marginalia Search 今年的主要目标是扩展语言支持，超越仅限英语的搜索。一个试点项目已完成，实验性添加德语、法语和瑞典语。这些变化已上线供测试，但文档语料库极小。

主要挑战

• 英语中心假设：搜索引擎此前基于英语构建，代码中嵌入了以英语为中心的假设，这在搜索研究中常见。
• 语言多样性：支持所有语言不现实，因为语言差异巨大。例如：
  • 日语：多个字母表、Unicode 字符宽度嵌入、单词间无空格，需要特殊标准化。
  • 拉丁语系：词形多变（如“universe”与“university”），需词形还原（lemmatization）并弱化词序匹配。
• 文化差异：标准化步骤需考虑文化差异，如瑞典语中“Tröjan”（衬衫）与“trojan”（特洛伊或IT安全含义）不同，德语中“u”与“ü”不等同。

语言处理链

搜索引擎的语言处理流程包括：

1. 从 HTML 提取文本。
2. 使用 fasttext 识别语言。
3. 文本分句、单词小写化和 Unicode 标准化。
4. 词干提取（stemming）和词性标注（POS tagging）：用于关键词提取，但词干提取不完美（如“universe”和“university”被误判为同词）。
5. 关键词映射：通过 TF-IDF、语法模式（POS 标签）和其他启发式方法识别重要关键词。
6. 关键词哈希化：使用哈希算法将关键词映射到数字 ID，索引小规模时效果良好。

配置与工具

• 参数化语言处理：通过 XML 配置语言定义对象，注入语言特定逻辑。XML 因其验证支持好而被选用，配置文件包含语法模式（如名词 ngrams 的 POS 模式）。
• 测试工具：构建独立工具运行语言处理管道，输出中间结果供人工检查。由于自然语言细微差别，人工测试至关重要。

集成方案选择

• 单索引方案：所有语言文档存入同一索引，查询时过滤语言。优点：无需预先指定语言。缺点：索引扩大导致查询变慢、词汇量增加可能引发哈希冲突，且跨语言同形异义词（如英语“salt/lag”与瑞典语含义不同）会干扰结果。
• 分索引方案：每个语言单独索引。优点：更准确、快速；缺点：需预先指定语言，多语言查询成本高。最终选择分索引方案，实现为语言特定关键词-文档映射，指向公共文档列表。索引构建从共同日志改为每语言分区日志，以提升效率。

结果与挑战

• 当前状态：变化已实施，但评估受阻于新语言索引过小。文档计数：
  • 英语：112,846,397
  • 德语：7,623,983
  • 法语：4,852,759
  • 瑞典语：1,020,962
• 索引小原因：索引通过跟踪英语网站链接增长，非英语网站链接稀少；索引增长缓慢，此前仅靠手动提交。
• 改进措施：构建新过程验证候选网站真实性和在线状态，以识别新域名。运行近一季度，已识别约 800,000 个新域名，文档总数达 9.69 亿。新语言（如德语、瑞典语、法语）链接已添加至域名数据库，可能改善数据饥饿问题。

未来展望

数据集过小，难以进一步优化多语言搜索。需等待数据集演变，观察新域名发现过程是否足以补充非英语文档。

特斯拉面临的自动驾驶承诺危机

特斯拉的“全自动驾驶监督版”扩张正在适得其反，暴露了其自动驾驶技术的不足。客户因未获得承诺的功能而日益不满，并要求赔偿。

核心问题：硬件承诺无法兑现

• 2016年，特斯拉宣布所有后续生产的车辆均配备“实现完全自动驾驶所需的一切硬件”，并承诺通过未来软件更新实现。
• 实际上，特斯拉最初的硬件套件（HW2）无法支持全自动驾驶（FSD），不得不升级至HW3（用于2019-2023年产车辆），并于2024年切换至HW4。
• 2025年1月，特斯拉承认HW3硬件无法支持“无人监督自动驾驶”。尽管CEO埃隆·马斯克曾承诺对HW3车辆进行计算机硬件改装，但10个月来再无下文。

当前危机：FSD全球扩张激化矛盾

• 特斯拉正将FSD从北美扩展至中国、澳大利亚和新西兰等市场，但仅对HW4车辆提供支持。
• 在澳大利亚和新西兰，特斯拉仅为HW4车辆推出FSD，并向HW3车主提供月费149澳元的FSD订阅服务，尽管该软件对HW3不可用。此举引发消费者强烈不满。
• 为安抚用户，特斯拉向澳大利亚HW3车主发送邮件，提供5000澳元折扣用于购买新库存车辆（需转移其FSD套餐）。但该优惠实际面向所有买家，并非针对HW3车主的“忠诚奖励”。

法律后果与用户信任危机

• 数千名特斯拉车主已在澳大利亚就自动驾驶承诺问题提起集体诉讼。类似诉讼也在美国和中国进行。
• 全球有数十万FSD客户支付了高达15,000美元的费用，使特斯拉面临数十亿美元的赔偿或硬件改装责任。

可能的解决方案建议

文章指出，特斯拉面临巨大债务，可能需要通过法律途径强制解决。为挽回信任，建议特斯拉：

• 为所有HW3车主提供5000美元忠诚折扣（可与其他优惠叠加），用于升级新车。
• 对已购买FSD的HW3车主，提供免费FSD转移权及10,000美元购车折扣。

文章最后指出，若特斯拉不解决HW3问题，未来可能需对HW4车主采取类似措施，这可能对公司造成致命打击。

国际宇航科学院（IAA）正在更新其关于探测到地外智慧生命后行动准则的协议，这是该协议自1989年首次制定、2010年小幅修订以来最大的一次变革。新协议旨在应对现代社会日益复杂的环境，特别是社交媒体可能带来的问题，并保护宣布发现的研究人员免受网络骚扰。

此次更新中最关键的改变是关于是否回应外星信息的建议。先前的协议倾向于应当回复，且限制较少；而新协议则明确建议，在联合国对此问题进行讨论之前，研究人员绝对不应发送任何答复。需要说明的是，此建议并不直接影响更受争议的“向外星智慧生命发送信息”（METI）活动。

新协议的其他内容包括：

• 验证与数据管理：为验证信号或数据提供方法，并建议将数据存储在两个不同的地理位置，以便更多利益相关者能够访问。
• 频谱管理：如果信号是电磁信号，建议向国际电信联盟（ITU）申请为该检测频段提供保护，以减少人为干扰。
• 性质说明：这些条款均被视为“最佳实践”，而非具有约束力的强制规则。

该协议的制定过程历时两年多，经过了多轮修订和讨论。若在2025年悉尼国际宇航大会上获得简单多数票通过，最终将由国际宇航科学院董事会批准生效。

体育场全面采用人工智能导致体验下降

核心背景

作者两次前往洛杉矶BMO体育场观看波特兰荆棘队的比赛：一次在2024年5月，另一次在一年后。尽管第二次选择了更好的座位，但整体观赛体验明显变差，主要原因归咎于体育场过度推行自动化和人工智能技术。

人工智能系统导致的问题

1. 交易速度严重下降

• 所有特许摊位（包括不供应热食的摊位）均采用基于计算机视觉的结账系统。
• 实际操作流程繁琐：顾客放置商品后，系统需30秒识别，工作人员手动确认，再需30秒计算才能完成支付。
• 每次交易至少增加1-2分钟延迟，导致排队时间大幅延长。在高温天气（30°C）下，作者多次购买食物饮料均需忍受漫长等待。

2. 食品选择大幅缩减

• 去年供应烤鸡配华夫薯条、韩式烧烤饭碗等多样化美食的摊位，今年仅提供鸡肉条、薯条、热狗和糖果盒。
• 原因：计算机视觉系统对复杂食品的识别能力有限，为提升系统效率，场馆减少了食品种类。
• 2024年照片中可见的Smash汉堡等菜品已消失，全场菜单趋同。

3. “快速服务”变慢速服务

• 自助售货亭设计为扫码开门、拿取商品、关门后自动结算，但实际需等待约2分钟才能完成计算。
• 作者观察到前一位顾客购买两件商品被误扣费，因无纸质收据需拍照投诉。
• 作者购买一瓶水耗时10分钟，错过大量比赛时间。
• 炎热天气下，补水困难可能引发群体健康风险。

4. 系统可靠性存疑

• 尽管系统供应商声称比人工结账快400%并能提升25%利润，但作者实际体验与之相反。
• 人工结账更快速流畅，快速购买可能促进更多消费。

潜在影响与总结

• 体育场通过人工智能可能减少了人力成本，但牺牲了顾客体验：食物质量下降、选择减少、服务速度变慢。
• 在大型赛事（观众约1.7-1.8万人）和高温环境下，低效服务可能演变为安全问题。
• 作者认为，当前的技术应用未能实现效率提升，反而降低了整体观赛价值。

密码与电钻：安全与可靠性的交织

案例引述：内部密码管理器故障

2012年9月，谷歌内部密码管理系统因员工通勤WiFi密码变更引发的流量激增而崩溃。该系统是为少量系统管理员设计，无法应对大规模并发请求。主备副本相继失效后，值班工程师因缺乏经验、硬件安全模块智能卡存放在异地、保险箱密码存储在已离线系统中等问题，恢复过程陷入僵局。最终，团队通过电钻暴力打开保险箱，但仍因智能卡插入方向错误导致重启失败。这一事件表明，可靠性问题（负载均衡不足）触发了故障，而安全设计（智能卡机制）却使恢复过程复杂化。

安全性与可靠性的设计权衡

• 风险来源不同：可靠性风险通常非恶意（如软件缺陷、设备故障）；安全风险则针对主动攻击者。
• 故障响应模式：可靠性设计倾向“故障安全”（如断电时门禁保持开启）；安全性设计则需“故障保密”（如断电时门禁保持锁定）。
• CIA三元组（机密性、完整性、可用性）：两者均关注这些属性，但视角不同。
  • 机密性：航空业中麦克风意外泄漏驾驶舱对话属于可靠性问题。
  • 完整性：内存错误导致数据损坏可通过加密校验修复，体现了安全技术辅助可靠性故障。
  • 可用性：DDoS攻击与正常流量激增可能难以区分（如2019年旧金山地震引发的搜索请求暴增）。

安全性与可靠性的共性

• 涌现性属性：两者均需从早期设计阶段整体考虑，难以事后添加。
• 不可见性：运行正常时易被忽视，但故障成本高昂（如数据泄露影响收购价格、停电导致航班大规模取消）。
• 风险评估：可靠性可通过组件独立性进行概率规划；安全性需依赖对抗性测试评估。
• 简化设计：降低复杂度可减少攻击面、提升可理解性，有助于紧急情况下快速响应。
• 系统演化：规模扩张、功能更新可能引入复杂性，微小变更可能导致重大故障（如YouTube因日志库变更全球宕机、Debian OpenSSL随机数生成器缺陷）。

弹性与纵深防御

• 故障域隔离：通过权限隔离、凭证地域限制等手段限制故障影响范围。
• 纵深防御：例如在设备层加密之上叠加应用层加密。
• 最小特权与多因素授权：减少内部威胁与人为错误风险。

从设计到生产

• 代码审查与框架：在开发阶段识别潜在问题。
• 测试策略：负载测试、模糊测试、加密泄漏检测等确保系统符合预期。
• 安全部署：金丝雀发布、渐进式上线、代码审核机制可降低风险。

危机响应与恢复

• 日志记录：详细日志是检测与故障准备的基础，但需平衡存储成本与安全性。
• 应急计划：需明确指挥链、预案手册和跨时区协作流程（如谷歌的IMAG体系）。
• 恢复机制：补丁推送需权衡速度与稳定性，健壮的系统应能快速回滚至安全状态。

总结

安全与可靠性是信息系统固有属性，初期牺牲两者以追求速度的代价高昂。通过早期设计考虑、简化复杂度、纵深防御和定期演练，组织可构建可持续的实践文化。本书旨在帮助读者在系统生命周期中应对相关挑战，避免后期更高昂的代价。

Katakate 项目摘要

Katakate 是一个开源项目（Apache-2.0），旨在为大规模、安全地执行不受信任的代码（如AI代理运行的任意代码）提供易于创建、管理和编排的轻量级安全虚拟机沙箱解决方案。它也适用于构建自定义无服务器计算平台、加固的CI/CD运行器以及为AI去中心化应用（dApp）提供的区块链执行层。

核心技术栈

该项目构建于成熟的技术之上：

• Kubernetes (K3s)：用于编排，适合生产环境及边缘节点。
• Kata Containers：将容器封装为轻量级虚拟机，提供硬件级隔离。
• Firecracker：作为虚拟机管理器，实现超快启动、低资源占用和最小化攻击面。
• Devmapper Snapshotter：通过为逻辑卷配置精简池，实现高效磁盘空间共享，支持在单个节点上运行数十个虚拟机。

使用方式

项目目前处于Beta测试阶段，提供三种使用方式：

1. CLI：直接在节点上安装并使用（apt install k7）。
2. API：部署在主节点上，提供远程管理能力（k7 start-api）。
3. Python SDK：同步或异步的客户端库，用于与API交互（pip install katakate）。

节点要求与安装

节点要求：

• 操作系统：Ubuntu (amd64 或 arm64)。
• 硬件：必须支持并可访问硬件虚拟化（KVM）。
• 云服务支持：已在特定云服务商实例上测试通过（如Hetzner Robot专用实例、AWS .metal实例、GCP及Azure的特定实例系列）。通用云VPS通常不暴露硬件虚拟化，建议使用裸金属或专用服务器。
• 存储：需要一块未格式化的原始磁盘用于创建LVM精简池，以高效管理沙箱磁盘空间。

安装流程： 通过k7 install命令自动完成，它会安装并连接K3s、Kata、Firecracker、Jailer和精简池配置，且设计上尽量不影响现有的Docker/containerd环境。

安全特性

安全是Katakate的设计核心，沙箱默认采用多层加固：

• VM隔离：基于Kata和Firecracker的硬件级隔离，并通过Jailer进一步将VM限制在chroot环境中。
• 能力限制：默认丢弃所有Linux能力（drop: ALL），仅按需显式添加；默认禁止特权提升。
• Seccomp配置：使用默认的限制性配置文件。
• 非root执行：可选配置容器或整个Pod以非root用户（UID 65532）运行。
• API安全：API密钥以SHA256哈希存储，支持过期时间和使用记录。
• 网络策略：沙箱默认完全网络隔离，可基于CIDR控制出站流量；入站通信默认被阻断，防止沙箱间互访。未来计划集成Cilium以实现基于域名的白名单。

已知问题

目前存在一个已知问题：尽管配置正确，Jailer进程也会启动，但似乎被Kata所忽略，这可能与Kubernetes secrets的使用有关，正在调查中。

PASTA/80：面向Z80微处理器的简易Pascal交叉编译器

PASTA/80 是一款简易的Pascal交叉编译器，其目标平台为Z80微处理器。该编译器遵循 Niklaus Wirth 提倡的单遍递归下降编译方法，在语法分析过程中直接生成代码，因此编译速度极快，但生成的代码可能不是最优的。

支持的平台与特性

目标平台：

• CP/M
• ZX Spectrum 48K/128K/Next
• Agon Light/Console8

支持的Pascal语言特性：

• 基本数据类型（Boolean, Byte, Char, Integer, Pointer, Real, String）
• 复杂类型构造：数组、记录、集合、枚举、子范围、指针
• 控制结构：条件语句、循环语句、with语句
• 过程与函数，支持值参和变参及嵌套
• 标准I/O过程（ReadLn, WriteLn等）
• 动态堆内存管理（最大32767字节）
• 内联汇编（使用操作码形式）
• 部分目标平台支持覆盖（Overlays）以突破64K内存限制

语言扩展：

• 条件编译指令
• C风格单行注释
• 二进制字面量、Break/Continue语句
• 键盘查询函数（KeyPressed, ReadKey）
• 枚举类型在读写语句中的支持
• 简单的断言（Assert）设施与调试断点功能

编译器构建与使用

编译器自身用Pascal编写，可使用Free Pascal（如3.2.2版）编译。其后端依赖 sjasmplus 汇编器生成最终二进制代码。编译器通过命令行参数指定目标平台：

• pasta <文件>：默认为CP/M目标
• pasta --zx48：编译为ZX Spectrum 48K目标
• pasta --zx128：编译为ZX Spectrum 128K目标
• pasta --zxnext：编译为ZX Spectrum Next目标
• pasta --agon：编译为Agon目标

输出格式：

• 二进制文件（.com 或无扩展名的原始二进制）
• 快照文件（.sna）
• 磁带文件（.tap，包含BASIC加载器）
• 可运行目录（.run，用于ZX Spectrum Next）

优化选项：支持--opt（窥孔优化）和--dep（依赖分析以移除未使用代码）。

覆盖（Overlays）系统

ZX Spectrum 128K、Next和Agon目标支持覆盖，允许程序突破64K地址空间限制。覆盖通过overlay关键字标记过程或函数，编译器自动管理内存换入换出。每个覆盖模块最大8K。启用覆盖需使用--ovr参数。

调试与断言

• 断点：在源代码中插入Debug语句，可设置条件。支持为Fuse、CSpect、Fab Agon Emulator生成断点。
• 断言：使用Assert语句检查条件，失败不会终止程序但会计数。使用--release参数编译可移除所有调试和断言代码。

编译器指令

支持文件包含、条件编译、IO检查、栈溢出检查等指令。预定义了反映当前编译器和目标平台的符号（如SYS_CPM, CPU_Z80N等），便于编写跨平台代码。

集成开发环境（IDE）

编译器可启动为交互式迷你IDE，界面类似Turbo Pascal 3.0。它集成外部工具如nano编辑器、tnylpo（CP/M模拟器）、Fuse、CSpect和Fab Agon Emulator，用于编辑和运行程序。

许可与说明

PASTA/80编译器在 GNU通用公共许可证（GPLv3） 下发布，但运行时库带有链接例外，允许用户自由发布生成的二进制文件。示例代码视为公共领域。

编译器目前不支持部分Turbo Pascal 3.0指令、某些标准文件、链接执行功能，且生成的二进制体积相对较大。未来计划通过重写运行时库为Z80汇编来优化。

x86-64 Playground：在线汇编编辑与调试工具

核心功能

• 在线汇编编辑器：提供Web界面，支持编写、编译和共享x86-64汇编代码，兼容GNU As、FASM和NASM等主流汇编器。
• 集成调试器：内置类似GDB的调试功能，支持逐步执行程序，实时查看运行时内存和寄存器状态。
• 自定义程序调试：允许用户拖放x86-64-Linux静态可执行文件至应用，在沙盒环境中直接运行和调试，无需本地安装。

主要特点

• 面向学习与实验：专为x86-64汇编学习和二进制利用研究设计，提供类GDB+PwnGDB的调试界面，所有操作均标注对应GDB命令。
• 教学辅助工具：可与Compiler Explorer配合，为初学者提供无干扰的Linux进程运行原理学习环境，并提供过渡到实际GDB的指南。
• 移动友好与可嵌入：采用响应式设计，优化移动端体验；支持嵌入网页，为技术教程或文档添加交互功能。
• 离线与开源：应用开源，基于Blink模拟器完全在客户端浏览器模拟x86-64-Linux环境，代码编写与调试均无需服务器传输，支持离线使用。

适用人群

• 希望运行AMD64汇编代码片段或分析Linux ELF文件内部机制的用户，尤其适合学术研究（如二进制安全领域）。
• 需要无环境依赖的学习工具，以理解Linux进程底层原理的初学者或研究人员。

技术实现

• 完全基于浏览器运行，使用Blink模拟器实现客户端侧环境模拟，保障用户代码与程序的隐私性。

本文作者介绍了个人自行托管（self-hosting）的几种网络服务及其技术实现方案。

主要自托管服务：

1. Miniflux：一款简约的RSS阅读器，通过Docker部署，访问地址为https://rss.fredrikmeyer.net/。
2. Grafana：数据可视化工具，最初用于展示树莓派传感器数据，后集成Strava插件以统计运动数据。
3. YourSpotify：Spotify音乐收听统计应用，通过Tailscale实现本地网络访问，数据存储于MongoDB。
4. Linkding：书签管理工具，用于保存网页链接，访问地址为https://links.fredrikmeyer.net/bookmarks/shared。

技术架构与管理：

• 基础设施：使用DigitalOcean廉价服务器（月费约5美元），域名来自Domeneshop，SSL证书由Let’s Encrypt提供。
• 部署方式：所有应用均以Docker容器运行，通过Nginx进行反向代理并配置HTTPS重定向。
• 配置管理：主要依赖Ansible实现部分基础设施即代码（如Nginx和Grafana配置），其余应用（如Miniflux、YourSpotify）则通过scp和docker-compose命令手动管理。

未来计划： 作者希望未来能将AI技术与家电说明书结合，开发智能问答应用，或尝试自建任务管理工具（如Jira），并持续探索相关技术项目。

https://www.nytimes.com/2025/10/20/well/peanut-allergy-drop.html

• 项目名称: LibriVox
• 有声书数量: 提供 20,858 本公共领域有声书。
• 版权状态: 这些有声书在美国属于公共领域。
• 重要提醒: 如果您不在美国，下载前请自行核实作品在您所在国家/地区的版权状况，否则可能违反当地版权法。

Ilo – 在UEFI上运行的Forth系统

本文档介绍了名为 Ilo 的系统，它是一个运行在 UEFI 固件环境中的 Forth 语言实现。作者为 crc。

文档的核心内容是一段终端操作的录制（asciicast），该录制展示了Ilo系统在UEFI环境下的运行情况。录制过程发生在 GNU/Linux 系统的 xterm-256color 终端和 bash shell中。

文档主要提供了以下关于此录制文件的技术说明和选项：

1. 访问与分享：录制文件托管在 asciinema.org 上，可通过特定链接访问。支持通过添加时间参数（如 ?t=30）来指定播放的起始时间。

2. 嵌入方式：提供了多种将录制内容嵌入其他网页或文档的方法：

   • 图片链接：可生成一个静态的SVG预览图，并带有指向录制页面的链接，适用于不支持脚本的场景（如README文件）。
   • 脚本播放器：允许在支持<script>标签的网页中嵌入交互式的asciinema播放器。

3. 下载与回放：

   • 可以下载 .cast 格式的原始录制文件。
   • 使用 asciinema play 命令可在本地终端中回放该录制。

4. 独立播放器：可下载独立的asciinema播放器文件（.js和.css），用于在自己的网站上创建播放器实例，无需依赖官方服务。

5. 转换为GIF：虽然网站本身不提供转换服务，但可以通过命令行工具 agg 将录制文件转换为GIF动画，并提供了示例命令。

总结：本文档是一个技术演示的入口，其主旨是展示一个名为Ilo的、运行在UEFI下的Forth系统。大部分篇幅用于详细说明如何访问、嵌入、播放和转换该系统演示过程的终端录制文件。

Linux 磁盘 I/O 子系统图（2024年版）

本文介绍了一幅于2024年4月17日发布的 Linux 磁盘 I/O 子系统图（v3版）。该图系统性地展示了Linux磁盘I/O操作的完整数据流路径及各层级对应的核心命令。

核心内容：图表结构

该图表描绘了Linux磁盘I/O子系统从上层应用到底层硬件的完整架构，主要包含以下层级：

1. 应用层
2. VFS（虚拟文件系统）层：提供两种主要I/O路径：直接I/O 或 缓冲I/O（通过Buffer和Page Cache）。
3. 文件系统层（如EXT4, XFS等）
4. 可选块层
5. 通用块层
6. 磁盘调度层：在此层可选择两种现代调度机制：
   • BLK-Mq（块多队列）
   • 经典I/O调度器（如noop, anticipatory, deadline, cfq等）
7. 块设备驱动层
8. 设备驱动
9. 硬件层：包括RAID控制器或磁盘控制器，以及最终的存储设备（如HDD, SSD, NVMe硬盘）。

附加信息

• 关联资料：此图表是书籍《操作系统与计算机网络——Linux应用》的组成部分，该书拥有DOI标识符（10.5281/zenodo.8119310）。
• 文件获取：完整的图表以PDF文件（Disk IO-ALL-expanded-poster--EN.pdf，大小约1.8MB）形式提供。