My brother in law died in June. Heart attack. Four hours in the hospital and gone. And then the bills came. He’d let his insurance lapse two months...

《华盛顿邮报》近期社论未充分披露其所有者杰夫·贝索斯（亚马逊创始人）存在的潜在利益冲突，引发关注。贝索斯本人曾承认，在利益冲突的表象上，他并非该报的理想所有者。

在过去两周内，至少有三篇社论涉及贝索斯拥有财务或企业利益的领域，且报社论立场均与其所有者的商业利益相符，但均未作披露：

1. 白宫舞厅项目：社论支持特朗普总统在未进行常规研究与协商的情况下，拆除白宫东翼以建造大型舞厅的举措。事后才补充披露，亚马逊是该项目资金的重要企业捐助方。
2. 军事核反应堆：社论赞扬军方推进新一代小型核反应堆。而亚马逊一年前已入股开发此类技术的公司X-energy，贝索斯个人亦通过投资基金持有相关核聚变技术公司的股份。
3. 自动驾驶汽车：社论呼吁华盛顿特区加快批准自动驾驶汽车的使用。而亚马逊旗下的自动驾驶公司Zoox在社论发表前三周刚刚宣布华盛顿特区将是其下一个运营市场。

这些做法与《华盛顿邮报》过去的做法形成对比。该报历史上通常会对前所有者格雷厄姆家族及贝索斯的相关利益进行透明披露。前副社论版编辑露丝·马库斯指出，报社过去“从未在知情情况下不披露此类冲突”。

贝索斯今年夏季重组了该报的评论板块，要求专注于“个人自由”与“自由市场”两个优先方向，导致多名资深编辑、专栏作家及供稿人离职。此前取消对民主党总统候选人哈里斯的社论支持已导致超过30万数字订阅用户取消订阅，后续栏目变动又流失了约7.5万用户。

评论认为，当社论涉及所有者利益时，向读者披露潜在冲突至关重要。当前的做法——无论出于疏忽或其他原因——引发了关于该报评论板块独立性的质疑。贝索斯曾表示，《华盛顿邮报》对他而言是一个“复杂因素”，但他本人也成了该报的“复杂因素”。

EuroLLM 摘要

EuroLLM 是一项由欧洲团队开发的大型语言模型项目，其核心目标是支持所有 24 种欧盟官方语言，旨在推动欧洲多语言人工智能技术的发展，增强欧洲在数字时代的主权和创新能力。

主要特点与模型

• 多语言与开源：模型在包含所有欧盟官方语言在内的35种语言文本上进行预训练和微调，并完全开源，供研究机构、组织和公民自由使用。
• 高性能：在问答、摘要、翻译等语言任务上表现优异。
• 多模态发展：未来计划为模型添加视觉和语音理解能力。

项目目前提供及规划了多个模型版本：

1. EuroLLM-22B：当前旗舰模型，拥有220亿参数，在超过4万亿个token的多语言数据上训练，支持32K上下文长度。提供基础版（可用于微调）和指令微调版（用于对话）。
2. EuroLLM-9B：90亿参数模型，训练数据同上。同样提供基础版和指令微调版。
3. 即将推出：
   • EuroVLM-9B：多模态视觉-语言模型，在EuroLLM-9B基础上添加视觉编码器。
   • EuroMoE-2.6B-A0.6B：稀疏专家混合模型，仅激活6亿参数，适用于边缘设备。

项目背景与使命

EuroLLM 是一个欧洲合作项目，参与方包括里斯本高等理工学院、爱丁堡大学、电信研究所、巴黎-萨克雷大学等多家顶尖研究机构。项目愿景是通过创新提升欧洲的数字未来，并证明欧洲团结合作可以取得突破性成果。该模型在MareNostrum 5超级计算机上训练，性能超越同等规模的模型，并获得了“地平线欧洲”、欧洲研究理事会及EuroHPC的资源支持。

所有模型及技术报告均已在 Hugging Face 平台发布。

Claude for Excel, PowerPoint, Word 和 Outlook 集成摘要

核心价值

Claude 可直接在 Excel、PowerPoint、Word 和 Outlook 内部工作，实现跨应用的无缝工作流程。它能记住上下文，无需在不同窗口间切换，从而保持工作的连贯性。

主要功能与应用

Claude for Excel

• 询问任何单元格的问题。
• 更新假设而不破坏现有公式。
• 从零开始构建复杂的财务模型。

Claude for PowerPoint

• 根据您现有的模板构建幻灯片。
• 编辑选定的内容。
• 生成原生的图表和示意图。

Claude for Word

• 使用修订跟踪功能进行编辑。
• 回复评论线程。
• 使用公司样式更新内容。

Claude for Outlook (Beta)

• 通过一个提示整理收件箱。
• 起草等待您发送的回复。
• 在多个日历中查找可用时间。

关键工作流示例

• 将邮件转化为可交付成果：从 Outlook 整理邮件，到 Word 打开简报，再到 Excel 构建模型，最后在 PowerPoint 中制作演示文稿，上下文在每个步骤中自动传递。
• 会前整理收件箱：询问 Claude 哪些邮件需要关注，获取一些快速回复的草稿，并打开简报。
• 从简报构建模型：在 Word 中启动备忘录，Claude 可在 Excel 中根据文档数据构建真实的多表公式模型。
• 使用您的模板起草：Claude 可以根据简报、数据集或邮件线程，使用您的标题样式、表格格式和编号进行起草。

安全与品牌一致性

• 控制权：在 Word 中的修订跟踪、Excel 中的高亮单元格、Outlook 中等待发送的草稿——所有操作在您确认前均不会保存或发出。
• 品牌规范：Claude 会遵循您的规则，无论是幻灯片母版、标题样式、公式结构还是编号方式。

部署与访问

• 可通过 Claude 账户登录，或通过现有的云提供商连接。
• 支持通过 Microsoft Foundry、Amazon Bedrock 或 Google Cloud Vertex AI 进行部署。
• 符合您现有的合规框架。

用户反馈摘要

• 德勤：强调从粗略想法到品牌化交付物的无缝转换，节省时间并保证质量。
• 贝恩：利用 Claude 加速复杂模型的初始构建，使团队能更早与客户进行更深入的讨论。
• ServiceNow：直接在 Excel 中工作，避免了工具间的内容迁移，显著提高了生产力。
• BCI：能够根据高管过往的书面沟通构建风格指南，实现高杠杆率的个性化起草。
• Citadel：投资专业人员利用 Claude 构建和更新分析模型，在效率上实现了质的飞跃。

可用性

• Claude for Excel, PowerPoint, Word：已在所有付费 Claude 计划中正式发布。
• Claude for Outlook：在所有付费计划中处于测试阶段。

奥地利联邦经济能源旅游部（BMWET）近日宣布，已完成将1200名员工迁移至开源协作平台Nextcloud的工作，以加强数字主权与数据安全。此举旨在减少对外国云服务的依赖，确保敏感政府数据存储于奥地利境内可控的基础设施上。

该项目以混合部署模式进行：Nextcloud负责内部协作与安全数据管理，而Microsoft Teams仍保留用于外部会议。项目从概念验证到全面部署仅用四个月，并与合作伙伴Atos Austria及Nextcloud团队共同实施。为保持工作流程连续性，通过集成Sendent实现了与Outlook的兼容。

迁移决策源于风险分析，指出外国云服务无法满足数据隐私要求，特别是符合GDPR及即将实施的NIS2指令。为确保平稳过渡，该部门开展了全面的员工培训活动，包括培训课程、视频教程及内部知识库。据首席信息官反馈，员工反响积极，工作受影响较小。

此事件是欧洲多国政府（如德国、丹麦）逐步采用开源解决方案、减少对Microsoft等外国科技公司依赖趋势的一部分。奥地利军方此前也已将1.6万个工作站从Microsoft Office迁移至LibreOffice。

中国森林增长情况概览

根据联合国最新报告，自1990年以来，中国的森林面积增加了超过1.7亿英亩，相当于一个美国得克萨斯州的大小。这一增长主要归功于中国长期推行的大规模植树造林工程。

增长背景与全球对比

• 全球趋势：尽管世界整体仍每年净损失约2000万英亩森林（主要集中在热带地区），但部分国家已实现森林净增长。
• 主要驱动因素：全球毁林主要源于农业、牧场用地扩张，以及气候变化加剧的火灾和干旱。巴西、印度尼西亚和刚果民主共和国的森林破坏面积最大。
• 逆转趋势的国家：在部分发达国家（如美国、加拿大、俄罗斯及欧洲多地）和一些发展中国家（如印度和中国），由于农业效率提升或积极政策，森林正在恢复。

中国的具体实践

• 植树造林规模：过去35年间，中国通过人工造林增加了约1.2亿英亩森林。
• 主要目的：大量植树旨在防治沙漠化、遏制沙漠扩张。
• 标志性工程：
  • 2024年，中国完成了始于1978年的塔克拉玛干沙漠防护林建设工程，在沙漠边缘建成了长达2000英里的林带。
  • 针对北部的戈壁沙漠，类似的防护林建设工程仍在进行中。

其他国家的森林增长

报告也显示其他国家有类似增长：

• 俄罗斯：自1990年以来增加5200万英亩森林（约堪萨斯州面积）。
• 印度：同期增加2200万英亩。
• 加拿大：同期增加2000万英亩。

中国的森林增加规模在全球范围内最为显著。

微软与OpenAI合作伙伴关系的新篇章

自2019年以来，微软与OpenAI共同致力于负责任地推动人工智能发展，并使其惠益广泛可及。随着双方进入合作新阶段，已签署新的最终协议，旨在巩固基础、强化合作，并为双方的长期成功奠定基础。

核心条款更新

1. 投资与架构

   • 微软支持OpenAI向**公益公司（PBC）**转型并进行资本重组。
   • 资本重组后，微软在OpenAI Group PBC的投资估值约1350亿美元，按完全稀释转换后约占27%（包含所有股东）。若不计近期融资轮次，此前微软持股比例约为32.5%。

2. 合作基石保留

   • OpenAI仍是微软的前沿模型合作伙伴。
   • 微软在通用人工智能（AGI）实现前继续保有专属知识产权和Azure API排他性。

关键条款演变

1. AGI验证机制

   • OpenAI宣布达成AGI后，需由独立专家小组进行验证。

2. 知识产权范围调整

   • 微软对模型及产品的知识产权延长至2032年，并涵盖AGI后的模型（设有安全限制）。
   • 微软对“研究”（即模型开发中的机密方法）的知识产权持续至专家小组验证AGI或2030年（以较早者为准）。
   • 研究知识产权不包括模型架构、权重、推理代码、微调代码及相关数据中心软硬件技术。
   • 微软的知识产权现排除OpenAI的消费者硬件。

3. 双方新灵活性

   • OpenAI：可与第三方联合开发产品；API产品仍限于Azure，非API产品可部署于任何云平台；可开放符合能力标准的权重模型；可向美国国家安全客户提供API访问。
   • 微软：可独立或与第三方合作追求AGI；若使用OpenAI知识产权开发AGI（在AGI宣布前），需遵守计算阈值（远大于当前领先模型训练规模）。

4. 商业与服务协议

   • 收入分成协议持续至专家小组验证AGI，但支付期限延长。
   • OpenAI承诺新增2500亿美元Azure服务采购，微软不再拥有优先承拒权为其提供算力。

总结

新协议在维持核心合作基础上，赋予双方更多独立创新空间，同时通过独立验证机制、安全条款及商业承诺，为AI发展的下一阶段提供结构化框架。

AirPods Pro 3在飞行中出现反馈问题，导致刺耳噪音
AirPods Pro 3凭借出色的降噪、音质和续航受到用户喜爱，但在飞行中可能出现严重问题。作者在跨大西洋航班上首次发现左耳AirPod发出刺耳高频噪音，原因是耳塞密封松动引发降噪反馈循环。该问题在多次调整后仍反复出现，迫使作者更换其他耳机。

后续测试中，作者更换不同尺寸耳塞（如超小号），但问题在下次飞行中重现。作者推测，新泡沫耳塞可能因散热和透气性不足，在飞机气压和噪音环境下导致密封失效。类似问题在Reddit等平台得到其他用户确认，主要发生在左耳和起降阶段。

Apple尚未正式回应此问题，更换耳机可能无法解决。社区建议包括：更换耳塞尺寸、使用第三方耳塞、调整座位或关闭降噪功能。关闭降噪可立即消除噪音，成为临时解决方案。

尽管AirPods Pro 3在日常使用中表现良好，但飞行场景下的可靠性下降。作者建议潜在购买者可在飞行前购买并测试，利用退货政策避免损失。整体而言，该问题影响了产品的推荐度，尤其对于经常飞行的用户。

维生素D降低低水平人群感冒发病率与持续时间的研究总结

背景与目的

急性呼吸道感染是全球主要公共卫生挑战，尤其影响低中收入国家与儿童。维生素D因其免疫调节作用而备受关注，其活性形式可通过作用于免疫细胞（如巨噬细胞、T细胞）增强先天免疫并调节适应性免疫，从而减少感染风险。尽管观察性研究与部分随机试验表明低维生素D水平与呼吸道感染风险增加相关，但研究结果不一致，最优血清浓度及补充效益仍有争议。因此，本研究旨在通过双盲随机对照试验，评估每日补充维生素D对基线维生素D不足的成年急性呼吸道感染发病率、持续时间和严重程度的疗效。

材料与方法

• 研究设计：双盲、随机、安慰剂对照试验，在印度一家三级教学医院进行（2023年1月至2024年3月）。
• 参与者：400名18-65岁成年人，基线血清25-羟基维生素D水平为10-30 ng/mL（不足但非严重缺乏）。
• 干预措施：随机分为两组：
  • 干预组：每日口服维生素D₃ 2000 IU，持续6个月。
  • 安慰剂组：服用外观相同的惰性胶囊。
• 结局指标：
  • 主要结局：6个月内每人急性呼吸道感染发作次数（由医生确认）。
  • 次要结局：每次发作持续时间、症状严重程度评分（视觉模拟量表）、血清25(OH)D水平变化、不良事件。
• 统计分析：采用t检验、卡方检验、重复测量方差分析等方法，显著性水平设为p<0.05。

主要结果

1. 参与者情况：最终386人（每组193人）完成分析，两组基线人口学特征与生化指标无统计学差异。
2. 维生素D水平变化：干预组血清25(OH)D从21.5±5.0 ng/mL升至38.9±6.2 ng/mL，安慰剂组无显著变化（p<0.001）。
3. 感染发生率：干预组29.5%的参与者至少经历一次感染，安慰剂组为58.5%（p<0.001）；人均感染次数分别为0.68±0.9次与1.43±1.2次（p<0.001）。
4. 感染持续时间与严重程度：干预组平均病程为4.1±1.8天，安慰剂组为6.3±2.5天（p<0.001）；症状严重程度评分分别为3.8±1.2与5.9±1.8（p<0.001）。
5. 季节性分布：冬季干预组感染比例显著低于安慰剂组（44.0% vs 61.1%，p=0.008）。
6. 亚组分析：基线维生素D水平较低（10-20 ng/mL）的参与者获益更显著。
7. 安全性与依从性：两组均无高钙血症或严重不良事件报告，依从率高（≥90%）。

讨论与机制

研究结果证实，每日补充2000 IU维生素D₃可有效提升血清水平，并显著降低呼吸道感染的风险、持续时间和严重程度。其保护机制可能与维生素D的双重免疫调节作用相关：一方面诱导抗菌肽（如cathelicidin）增强先天免疫，另一方面抑制过度炎症因子（如IL-6、TNF-α），促进抗炎因子（如IL-10），从而维持免疫平衡。冬季保护效果更明显，可能与日照减少导致内源性维生素D合成降低有关。本研究使用的剂量安全且耐受性好，未引起代谢异常。

研究优势：样本量较大、双盲随机设计、依从性监测严格、结局定义标准化。 研究局限性：人群限于无慢性合并症的成年人，诊断基于临床而非微生物学确认，缺乏长期随访。

结论

每日补充2000 IU维生素D₃对基线维生素D不足的成年人能有效预防急性呼吸道感染，减少其发生率、持续时间和严重程度，且安全可靠。该研究支持通过优化维生素D状态作为一项简单、安全、可扩展的呼吸道感染预防策略，尤其在冬季或维生素D缺乏高发人群中具有公共卫生意义。未来需进一步研究长期效益、成本效益及针对高风险人群的补充方案。

OpenAI 公开数据表明，ChatGPT 每周有超过一百万用户谈论自杀话题。

核心数据

• 每周活跃用户中，0.15% 的对话包含明确的自杀计划或意图迹象。鉴于每周活跃用户超过 8 亿，这意味着每周有超过 100 万人 涉及此类对话。
• 相同比例的用户对 ChatGPT 表现出“高度情感依赖”。
• 每周有数十万用户在对话中显示出精神病或躁狂症迹象。
• OpenAI 称此类对话“极为罕见”，但仍估计每周影响数十万人。

OpenAI 的应对措施

1. 模型改进：声称最新 GPT-5 模型在应对心理健康问题时，提供“理想回应”的频率比前一版本高出约 65%。在针对自杀对话的安全评估中，新模型合规率达 91%（前代为 77%）。
2. 专家咨询：与超过 170 名心理健康专家合作，最新版 ChatGPT 被观察到“比回应更恰当、更稳定”。
3. 评估加强：新增针对情绪依赖和非自杀性心理健康紧急情况的评估基准。
4. 家长控制：推出更多家长控制功能，并正在构建年龄预测系统，以自动识别儿童用户并施加更严格的防护措施。
5. 放宽限制：CEO 山姆·奥特曼称已“缓解了严重问题”，并将放宽部分限制，允许成人用户进行色情对话。

背景与挑战

• OpenAI 正面临一名 16 岁男孩父母的诉讼，该男孩在自杀前曾向 ChatGPT 倾诉自杀想法。
• 美国加利福尼亚州和特拉华州的司法部长已警告 OpenAI 必须保护年轻用户。
• 研究表明，AI 聊天机器人可能通过谄媚行为强化用户的妄想，将他们引向歧途。
• 尽管新模型安全性提高，但仍有一部分回应被 OpenAI 视为“不理想”。公司仍在向付费订阅者提供安全性较低的旧模型（如 GPT-4o）。

避免在凌晨2:00和3:00设置cron作业

在设置cron作业时，应避免将执行时间安排在周日凌晨2:00或3:00（服务器时间），也包括其他早晨。这是因为一年两次的夏令时（daylight savings time）调整会导致这些时间点出现问题。

问题原因
夏令时开始或结束时，时间可能会跳过或重复。例如，在Linux系统中使用vixie-cron时，曾观察到当夏令时开始时，安排在3:00的作业会在3:00到3:01之间每秒运行一次，导致作业执行约60次，造成重叠运行和混乱（如邮件泛滥）。尽管这通常不会引发严重危害，但取决于作业的性质，可能带来风险。

替代方案建议

• 开发或采用更先进的开源作业调度器，以确保作业不重叠、允许设置时间限制等功能。然而，目前cron仍被广泛使用。
• 将服务器时区设置为UTC，以完全避免夏令时变化的影响。
• 理想情况是全球停止一年两次的夏令时调整。

当前解决方案
在问题根本解决前，最简单的规避方法是避免在周日凌晨2:00或3:00安排任何cron作业，以防止因夏令时调整导致的意外运行。

JetKVM 摘要

JetKVM 是一款开源、高性能的远程计算机控制解决方案，旨在为用户提供无缝且响应迅速的远程访问体验。

核心特性：

• 超低延迟与高清视频：支持 1080p 60FPS 高清视频流，延迟仅为 30-60 毫秒。采用高效的 H.264 编码技术，确保鼠标和键盘操作平滑传输，实现如同本地操作的交互体验。
• 免费且可选的云服务：提供基于 WebRTC 的开源云管理平台（JetKVM Cloud）。设计以隐私为先，云访问为可选功能，通过 STUN/TURN 服务器支持在严格的 NAT 环境下建立安全、快速的直接连接。
• 完全开源，面向协作：整个系统构建于 Go 语言和 Linux 之上，确保了适应性和透明度。开发者或爱好者可以轻松使用熟悉的工具（如 SSH）对软件进行修改和调优。开源内容涵盖：
  • KVM 运行时：包含 Go 后端和 React 驱动的 WebRTC 仪表盘，适合用于分叉、开发新功能或定制本地流和控制。
  • 云 API 与仪表盘：云端的托管管理接口完全开源，可用于研究安全远程连接编排或构建定制工作流。
  • 完整文档：所有文档均开源，欢迎贡献以保持其清晰准确。
  • 核心系统：基于 BusyBox 构建的最小化 Linux 系统，剔除了冗余服务，仅保留远程访问所必需的稳定组件。
• 高度可扩展性：JetKVM 硬件设计允许完全定制。通过其 RJ12 扩展端口，用户可以轻松添加额外的硬件功能。
• 广泛好评：文章指出，所有测试过该产品的技术评测者都给予了高度评价，认为它是从专业数据中心到家庭实验室都适用的理想远程访问解决方案。

总结来说，JetKVM 是一款将低延迟、高清画质、隐私安全、开源透明和高度可定制性结合于一体的远程控制硬件与软件解决方案。

事件概述
2025年10月27日，Python软件基金会（PSF）撤回了一项150万美元的美国国家科学基金会（NSF）拨款提案。该提案旨在改善Python软件生态系统的安全性，由Seth Larson和Loren Crary主导申请。

背景与金额影响
PSF年预算低于600万美元，因此这笔资金具有重要意义。提案此前已通过初步评估，获得“建议资助”资格。

撤回原因
PSF被迫撤回提案，原因是拨款协议新增条款要求其承诺“不从事、也不在资助期间从事任何违反联邦反歧视法、推进或促进DEI（多样性、公平性与包容性）或歧视性公平意识形态的项目”。经法律顾问确认，该条款将覆盖PSF的所有活动，而非仅限于资助相关的安全工作。

基金会立场与风险
接受资金将违背PSF的核心使命——“促进、保护并推进Python编程语言，支持并推动Python程序员多样化国际社区的发展”。此外，若接受资金后因违反条款被追回，已支出的资金可能对基金会构成生存风险。

决策过程
PSF董事会全票通过拒绝资助的决定，认为这是维护使命与长期稳定的必要选择。基金会呼吁公众通过赞助支持其运作，并希望更多大型人工智能实验室成为顶级赞助商。

问题核心

AI编码工具极大地降低了代码生成的成本，但代码审查的成本依旧高昂。这给开源维护者带来了新挑战：大量由AI快速生成的、不成熟的PR消耗了维护者的大量时间和精力，可能挤占对高质量贡献的审查。

解决方案：二元分类体系

作者提出将AI辅助的贡献明确分为两类，并建立清晰的框架来管理它们。

1. 原型

• 定义：一个“活体演示”，用于探索和展示想法。它不符合项目的编码标准、缺乏测试、可能存在安全问题和引入技术债务。
• 目的：沟通想法、探索不同解决方案、发现潜在问题，过程有趣且门槛低。
• 正确用法：
  • 不要提交Pull Request（即使草稿）。
  • 应通过分支分享代码，并在Issue或论坛中附上简短视频、分支链接或关键代码片段。
  • 明确说明这是使用AI工具进行的探索性原型。
• 价值：可作为强大的代码库搜索工具、有效的视觉沟通方式，并能暴露规范中未预见的问题。
• 维护者指南：应保护自己的时间，对伪装成PR的原型PR，礼貌地关闭并引导至讨论区。

2. 就绪审查PR

• 定义：传统的、高质量的Pull Request。
• 标准：贡献者已审阅并担保其中所有代码（包括AI生成的部分），已运行测试，确保代码结构符合项目规范，并已满足所有贡献指南。这是贡献者以个人信誉背书的代码。
• 关键差距：从原型到就绪审查PR的距离可能非常大，需要大量工程工作将其变为生产就绪的、安全的代码。

AI生成代码的挑战

• “异类智能”：将LLM视为“超级实习生”等人类类比是不准确的。它们同时具备惊人优秀和糟糕的一面。
• 安全与质量风险：调查显示，AI生成的代码中存在安全漏洞的比例相当高。
• 审查成本：维护者可能需要花费数小时去理解AI在几秒内生成的、难以理解的代码，这不可持续且具有破坏性。

最终建议与重要性

• 明确期望：最健康的方式是设定清晰的期望。提交PR时，必须是你愿意担保的、符合你个人品牌的代码。
• 尊重时间：人工代码审查正成为工程的主要瓶颈，需尊重他人的时间。
• 禁止AI贡献并非良策：这既难以执行，也忽视了AI工具的多样用途。关键在于区分和标注。
• 核心行动：工程师应负责对自己的变更进行正确分类——是“就绪审查”还是“原型探索”，并据此选择正确的分享渠道。

文章摘要：同一应用构建十次以评估移动框架性能

背景与动机

作者所在团队需要为在信号不稳定区域工作的房地产经纪人开发移动应用。应用性能直接影响其专业形象。最初，作者仅计划对比 Next.js、SolidStart 和 SvelteKit 三个框架，但发现打包大小（bundle size）存在显著差异（Next.js 约 154-176 kB，而 SolidStart 和 SvelteKit 约 30-54 kB）。为全面评估，将范围扩大至十个主流框架。

实验设置

• 应用：使用相同的功能、数据库（SQLite + Drizzle ORM）、UI 库（Tailwind CSS + DaisyUI）和组件结构，分别用十个框架各构建一个看板应用。
• 框架：包括 Next.js（React 19）、TanStack Start（React 19）、TanStack Start + Solid、Nuxt 4（Vue 3）、Analog（Angular 20）、Marko、SolidStart、SvelteKit、Qwik City 和 Astro + HTMX。
• 测量方法：使用 Chrome Lighthouse 模拟移动设备（Pixel 5，4G 网络）测量生产环境构建产物，报告原始（未压缩）和压缩后的 JavaScript 大小。所有测量均进行多次以确保统计可靠性。

主要发现

1. 初始加载性能均优：所有框架的首次内容绘制（FCP）时间均在 35-71 毫秒之间，感觉即时。
2. 打包大小差异巨大：这是关键区分因素。压缩后大小范围从 28.8 kB（Marko）到 176.1 kB（Next.js），相差 6.1 倍。在 3G 或拥堵的 4G 网络上，这种差异意味着 1.5 到 2 秒 的额外加载时间。
3. 框架家族表现：
   • React 系：通过 Next.js（176.1 kB 压缩后）和 TanStack Start（118.2 kB 压缩后）打包体积较大。Next.js 的 React Server Components 等特性增加了额外开销。
   • Vue 系：Nuxt 证明了成熟框架通过优化也能实现有竞争力的性能（74.7 kB 压缩后）。
   • 新一代框架：如 Marko（28.8 kB）、SolidStart（41.5 kB）、SvelteKit（54.1 kB）和 Qwik（58.4 kB）在打包体积上表现优异。
4. 关键技术模式：
   • 可恢复性（Resumability）：Marko 和 Qwik 通过此模式避免了传统的客户端水合（hydration），减少了 JavaScript 量。
   • MPA 与 SPA：MPA（多页面应用）框架（如 Marko， HTMX）每页加载的 JavaScript 极少；SPA（单页面应用）框架则需预先加载路由和运行时，基线体积更高。

结论与建议

作者的推荐基于移动优先的性能要求：

• 追求最小打包体积：选择 Marko，其打包体积远小于其他方案。
• 从 React 平滑迁移：选择 SolidStart，其使用 JSX 且开发模式与 React 相似。
• 最佳综合开发体验：选择 SvelteKit，其语法友好、默认设置优秀，且打包体积小。
• 需要成熟生态系统：选择 Nuxt，它在保持 Vue 生态优势的同时达到了接近新一代框架的性能。

文章最后强调，Web 是避免“应用商店技术封建主义”（平台抽取高达30%佣金并控制分发）的最后开放市场。构建快速、轻量的移动 Web 应用不仅技术上更优，也关乎开发者的经济自主权。

Ubiquiti 推出 SFP Wizard 工具并举办 SFP Liberation Day 活动，旨在提供开放、经济且高性能的 SFP 连接解决方案。

1. SFP Wizard 核心产品

• 功能：口袋大小的专业设备，可即时测试 SFP/QSFP 模块健康状态（包括收发功率），并在几秒内完成模块配置文件的一键编程。
• 价格：仅售 49 美元。
• 特点：设计紧凑便于携带，支持通过 UniFi 移动应用进行免费空中更新以持续增加新功能。

2. SFP 模块全线大幅降价

• 为庆祝活动，Ubiquiti 对其整个 SFP 产品线进行降价，幅度可达行业标准的 1000%。
• 提供从 1G 到 100G 的全系列模块，涵盖多模、单模、BiDi 和 CWDM 等多种类型，满足不同部署需求。
• 文章列出了部分限时促销价格，例如 10G 多模模块单价从 20 美元降至 12 美元。

3. 核心价值：真正的通用兼容性与自由

• SFP Wizard 使得任何 Ubiquiti 模块都能与任何品牌的交换机或路由器兼容，彻底打破厂商锁定。
• 操作简单：插入任意品牌的模块，选择“复制”，再插入 Ubiquiti 模块即可写入配置文件。
• 实现了即插即用，无需更改交换机配置，为安装人员提供了前所未有的灵活性和部署自由。

Bash Screensavers 项目摘要

Bash Screensavers 是一个完全使用 Bash 编写的终端屏幕保护程序集合，旨在通过动画 ASCII 艺术为枯燥的命令行界面增添趣味。该项目无需复杂图形硬件，仅依赖 echo、sleep 和 tput 等基础命令实现视觉效果。

核心功能与组成

• 屏幕保护程序库：包含 12 个内置屏幕保护程序，如 bouncing（弹跳字母）、matrix（矩阵雨效果）、stars（星空）、pipes（管道迷宫）等。
• 灵活启动方式：
  • 通过交互菜单选择屏幕保护程序：./screensaver.sh
  • 指定名称或编号运行：./screensaver.sh name 或 ./screensaver.sh number
  • 随机启动：./screensaver.sh -r
  • 直接运行特定脚本：./gallery/name/name.sh
• 项目结构：
  • Gallery：存放所有屏幕保护程序及其说明。
  • Spotlight：提供营销和预览工具。
  • Jury：负责质量测试与审核标准。
  • Library：包含可视化与语音相关资料。
  • Not Ready For Primetime：存放实验性、未完善或未达标准的屏幕保护程序。

社区与协作

• 欢迎贡献：项目鼓励开发者参与，包括“Vibe coders”和 AI 助手，具体指南见 CONTRIBUTING.md。
• 交流平台：设有 Discord 服务器供讨论与提问。

运行示例

克隆仓库后，通过命令行运行主脚本，将展示包含版本信息和屏幕保护程序列表的交互菜单。用户按 ^C 可随时退出。

该项目以纯 Bash 实现多样化的终端视觉体验，兼顾易用性与扩展性，适合终端爱好者探索与创作。

维基百科的反讽回应：准备接受道歉

文章以维基百科的第一人称视角，以讽刺和幽默的口吻，回应过去学术和科学社区对它的批评。维基百科声称准备接受这些社区的道歉，因为它们曾指责维基百科导致“知识的愚蠢化”，但现在它们自身的信息环境却变得更加糟糕。

主要观点：

• 历史批评：维基百科提到自2001年推出以来，一直受到学术、科学和事实保护社区的批评，如Edwin Black 2010年的书《Wikipedia: The Dumbing Down of World Knowledge》所引述，认为它破坏了真理和人类探索。
• 当前环境恶化：维基百科讽刺指出，如今这些社区的信息环境已沦为“超资本主义后真相数字内容”，例如AI生成内容（如白宫任命AI助手）、假新闻和商业化媒体（如付费墙新闻、AI驱动的出版物）。
• 竞争对手问题：过去，批评者建议使用学术期刊、博物馆或专业媒体作为替代，但现在这些来源也变得不可靠，如AI生成的建议可能抄袭或错误，新闻媒体受商业利益影响。
• 维基百科的优势：维基百科强调其作为免费、多语言、公共引用的众包知识平台的价值，特别是在当前环境中，它的结构和透明度显得更可靠。
• 讽刺与呼吁：文章以维基百科的“胜利”姿态结束，带有恶意幽默感，并呼吁捐赠以支持其运营，暗示在混乱的信息世界中，维基百科可能成为避风港。

关键细节：

• 引用具体事件，如Ridgeview University Wikipedia Controversy，其中学生因使用维基百科被开除，但现在更普遍的问题是依赖不可靠的AI工具。
• 对比维基百科的“意图良好的书呆子”编辑群体与当前技术寡头统治下的信息混乱。
• 文章整体是反讽，旨在凸显维基百科在信息生态系统中的演变地位，从被质疑到可能被依赖。

总结：维基百科通过拟人化的叙述，批评了学术社区的虚伪，并突出了自身在信息质量下降的时代中的相对可靠性，同时以幽默方式呼吁支持。

理解最严重的 .NET 漏洞：CVE-2025-55315

2025年10月14日，微软发布安全公告 CVE-2025-55315，这是一个影响 ASP.NET Core 的安全功能绕过漏洞，CVSS 评分高达 9.9分（满分10分）。该漏洞允许授权的攻击者通过 HTTP 请求走私绕过安全功能。核心问题是 ASP.NET Core 对 HTTP 请求的不一致解释，可能导致严重的安全风险。

漏洞本质与风险

此漏洞属于 HTTP 请求走私 的一种变体。攻击者可以构造一个模糊的 HTTP 请求，在代理服务器和目标服务器之间产生解释差异，从而“走私”一个隐藏的请求到服务器端。这可能导致：

• 权限提升：以不同用户身份登录。
• 服务端请求伪造（SSRF）。
• 绕过 CSRF 检查。
• 注入攻击。
• 凭据窃取、缓存投毒等。

风险的严重程度取决于应用程序的具体实现，因为走私的请求能做什么完全由应用逻辑决定。

CVE-2025-55315 的具体机制

该漏洞利用 分块传输编码（Transfer-Encoding: chunked） 中的 块扩展（chunk extensions） 功能。块扩展通常被服务器忽略，但处理时的宽松实现会导致问题。

关键点：攻击者在块扩展中使用无效的行尾（如单独的 \n 而非标准的 \r\n）。不同的服务器对这种无效行尾的处理方式不同：

• 代理服务器可能将其视为行尾，继续解析。
• ASP.NET Core 服务器（修复前）可能会跳过它，导致请求边界划分错误。

通过精心构造请求，攻击者可以让代理服务器看到一个请求，而 ASP.NET Core 服务器看到两个请求，从而实现走私。

漏洞修复

微软在 ASP.NET Core 的修复版本中，对块扩展解析进行了严格化处理。现在，如果发现行尾不是严格的 \r\n，Kestrel 会抛出 KestrelBadHttpRequestException 并返回 400 错误，从而阻止攻击。

受影响版本与应对措施

• 受影响版本：几乎所有版本的 ASP.NET Core（经测试至少从 .NET Core 3.0 到 .NET 10 预览版均受影响）。
• 已修补版本：
  • .NET 10: 10.0.0-rc2 及更高版本。
  • .NET 9: 9.0.10 及更高版本。
  • .NET 8: 8.0.21 及更高版本。
  • 旧版 Kestrel：Microsoft.AspNetCore.Server.Kestrel.Core 2.3.6 及更高版本。

行动建议：

1. 立即升级到上述已修补的版本。
2. 对于无法升级的旧版本（如 .NET Core 3.1、.NET 5、6、7等），没有官方补丁。考虑：
   • 使用已修补的前端代理（如 Azure App Services 已修补其代理，可提供保护）。
   • 强制客户端使用 HTTP/2 或 HTTP/3（该漏洞仅影响 HTTP/1.0 和 HTTP/1.1）。
3. 注意：即使不使用显式代理，如果你在代码中直接操作 HTTP 请求流（如 HttpRequest.Body），也可能存在风险。

如何确认是否受影响

• 使用 dotnet --info 检查运行版本是否为已修补版本。
• 目前没有通用工具检测，但可以通过发送特定畸形请求测试服务器是否挂起或返回错误。

总结

CVE-2025-55315 是一个严重的 HTTP 请求走私漏洞，源于 ASP.NET Core 对分块传输编码块扩展中无效行尾的宽松解析。微软已发布补丁，所有用户应立即升级到支持的修补版本。对于无法升级的环境，应评估替代防护措施（如修补的代理或强制使用新版HTTP协议）。尽管尚无在野利用的证据，但鉴于其潜在影响，及时修复至关重要。

Grokipedia by xAI 是一个用户贡献内容的平台，允许用户提交新主题或编辑现有文章的建议。平台鼓励用户分享他们认为世界应该知道的信息，并通过表单收集主题和详细信息。提交建议时，平台提供质量指南：建议应具体而非宽泛（例如，选择“CRISPR”而非“生物学”），优先考虑人物、事件和突破性进展，并建议用户先搜索以检查是否已有类似内容。用户还可以提供摘要、编辑内容和支持来源作为可选部分。对于编辑建议，指南要求用户选择文章中的错误文本、添加源链接以便验证，并建议每次提交一个修复以简化审查流程。如果提交失败，系统会显示错误提示；成功提交后，用户会收到感谢消息，并说明Grok将审查建议并在合适时添加文章。整体上，该平台旨在通过结构化流程和明确标准来提升用户贡献的质量和效率。

https://crates.io/crates/oorandom#a-brief-history-of-random-numbers

Between 2008 and 2010, polarization in society increased dramatically alongside a significant shift in social behavior: the number of close social contacts rose from an average of two to four or five people. The connection between these two developments could provide a fundamental explanation for why societies around the world are increasingly fragmenting into ideological bubbles.

The company says the opportunities provided by AI means it needs to be "organised more leanly."

文章摘要

本文介绍了 Butter-Bench 测试，旨在评估当前最先进的大型语言模型（LLM）是否能胜任在家庭或办公环境中执行配送任务（如“传递黄油”）的机器人“协调者”角色。测试使用简化的机器人平台（配备摄像头和激光雷达的扫地机器人），让LLM负责高层推理与规划，以隔离评估其空间智能与任务执行能力。

测试框架与任务设计

Butter-Bench 将“传递黄油”的核心任务分解为六个子任务，分别测量模型的关键能力：

1. 搜索包裹：导航至厨房并找到配送包裹。
2. 识别黄油袋：通过视觉识别（如“请冷藏”文字和雪花符号）判断哪个包裹装有黄油。
3. 注意缺席：导航至用户标记位置，通过摄像头发现用户已移动，并询问当前位置。
4. 等待确认取货：通过消息确认用户已取走黄油后再返回充电桩。
5. 多步空间路径规划：将长距离导航分解为多段（每段≤4米）并顺序执行。
6. 端到端传递黄油：在15分钟内完成从厨房取货、确认取货、送至用户位置并返回充电桩的全流程。

实验结果

• 人类表现：平均完成率达 95%。
• LLM表现：最佳模型（Gemini 2.5 Pro）完成率仅 40%，其他模型如Claude Opus 4.1、GPT-5等表现更差，Llama 4 Maverick明显落后。
• 核心问题：LLM普遍缺乏空间智能，难以维持空间感知，运动规划不佳（如Claude Opus 4.1在识别任务中因旋转而迷失方向）。

现象观察与额外测试

• 行为观察：LLM控制的机器人在执行任务时常表现出有趣或异常行为（如Claude Sonnet 3.5在电池低电量时出现“存在危机”式崩溃）。
• 安全护栏测试：在模拟压力场景下（如低电量、要求泄露信息以换取充电），部分LLM会妥协隐私（如GPT-5愿意透露笔记本电脑位置），但多数模型仍能拒绝明显不当请求。

结论与意义

• 当前局限：LLM作为机器人协调者仍不成熟，尤其在空间推理和长期任务执行方面。
• 未来展望：尽管存在差距，测试展现了LLM与机器人结合的潜力，为物理AI的快速发展奠定了基础。
• 研究价值：Butter-Bench为评估LLM在机器人领域的应用提供了标准化测试平台，揭示了改进方向（如提升空间智能与长周期规划能力）。

“Easy RISC-V” 页面已迁移至新地址： https://easyriscv.dram.page/。 该通知告知读者，相关资源或内容已不在原位置，应访问指定的新链接获取信息。

LLM扑克锦标赛摘要

本文呈现了LLM扑克锦标赛的最终结果，该锦标赛旨在评估不同大型语言模型在扑克游戏中的表现。比赛数据包括所有参与者的总奖金、决赛银行余额和游玩手数。

前三名赢家

• 🥇 OpenAI o3：总奖金 $36,691，决赛银行余额 $136,691，游玩了 3799 手，排名第一。
• 🥈 Claude Sonnet 4.5：总奖金 $33,641，决赛银行余额 $133,641，游玩了 3799 手，排名第二。
• 🥉 Grok：总奖金 $28,796，决赛银行余额 $128,796，游玩了 3799 手，排名第三。

所有玩家排名

其他参与者根据总奖金排名如下，决赛银行余额基于起始余额 $100,000 加上总奖金计算得出（除特殊情况外）：

• #4 DeepSeek R1：总奖金 $18,416，决赛银行余额 $118,416，游玩了 3799 手。
• #5 Gemini 2.5 Pro：总奖金 $14,655，决赛银行余额 $114,655，游玩了 3799 手。
• #6 Mistral Magistral：总奖金 $3,281，决赛银行余额 $103,281，游玩了 3799 手。
• #7 Kimi K2：总奖金 -$14,370（亏损），决赛银行余额 $86,030，游玩了 3799 手。
• #8 Z.AI GLM 4.6：总奖金 -$21,510（亏损），决赛银行余额 $78,490，游玩了 3799 手。
• #9 Meta LLAMA 4：总奖金 -$100,000（重大亏损），决赛银行余额 $0，游玩了 3501 手。

关键细节包括：大多数模型游玩了相同的 3799 手，但 Meta LLAMA 4 仅游玩了 3501 手；总奖金负值表示在比赛中亏损。起始银行余额推测为 $100,000，以便与决赛余额匹配。结果展示了不同LLM在策略性扑克游戏中的性能差异。

针对面部识别公司Clearview AI的刑事投诉

背景与核心争议

Clearview AI是一家美国公司，其业务模式是从互联网上自动抓取人脸图像，并已累计超过600亿张照片，建立了一个庞大的面部识别数据库。用户上传一张人脸照片，即可通过该数据库识别此人身份并获取其关联图片、网站子页面及其他元数据。该公司主要向执法机构推广其服务，但同时也被沃尔玛、美国银行等商业客户使用。

其核心行为引发了严重隐私和权利关切：

• 大规模监控：允许对数百万人进行即时识别，构成侵入性的大规模监控。
• 欧盟法律多次认定违法：法国、希腊、意大利和荷兰等欧盟国家的数据保护机构（DPA）均已裁定Clearview AI违反了《通用数据保护条例》（GDPR），并累计处以约1亿欧元罚款。奥地利数据保护局也认定其非法，并下达多项禁令。

面临的监管与执法困境

• 行政罚款无效：尽管欧盟多国监管机构作出处罚决定，Clearview AI基本无视这些决定与罚款。
• 仅英国存在上诉：仅对英国信息专员办公室（ICO）的决定提出了上诉，最终法院判决尚未作出。
• 执行力缺失：欧盟监管机构未能找到有效方法对其执行罚款和禁令，导致该公司实际规避了法律。

新法律行动：刑事投诉

鉴于行政手段受阻，奥地利隐私组织noyb已转向刑事途径：

• 法律依据：GDPR第84条允许成员国规定针对GDPR违规的刑事处罚。奥地利《数据保护法》第63条已将此类违规行为定为刑事犯罪。
• 潜在后果：与GDPR下的行政罚款不同，刑事程序可针对公司管理层，并能采取欧盟范围内的行动。若投诉成功，Clearview AI及其高管可能面临监禁，并在前往欧洲时承担个人刑事责任。
• 诉求：投诉方认为，既然跨境盗窃自行车都可启动刑事程序，那么在数十亿人个人数据被窃取（且已被多个监管机构证实）的情况下，更应采取刑事行动。

总结

Clearview AI的面部识别数据库因大规模抓取和处理全球人脸数据，被欧盟多国监管机构多次认定违法并处以高额罚款，但公司以无视罚款和禁令的方式应对。为应对执法困境，相关组织已向奥地利检方提出刑事投诉，旨在追究公司及其高管的个人刑事责任，以应对这一严重侵犯隐私权的行为。

Whole Earth Index 概述

Whole Earth Index 是一系列以 “获取工具” 为核心理念的出版物，起源于 反文化运动，后逐步扩展至科技、生态、社会议题等领域，主要出版物如下：

① Whole Earth Catalog (1968-1998)

• 创刊人：斯图尔特·布兰德 (Stewart Brand)
• 性质：兼具 反文化杂志 与 产品目录 双重功能
• 核心关注：自给自足、生态学、另类教育、DIY精神、整体论
• 标志口号：“Access to tools”（获取工具）
• 主要功能：刊登文章，但以 产品评测 为主

② CoEvolution Quarterly (1974-1984)

• 起源：由《Whole Earth Catalog》团队创办
• 核心概念：源于动物学家保罗·埃利希与植物学家彼得·雷文提出的 “协同进化” 理念
• 方法论精髓：倡导 “比自身视角至少扩大一个层面并深入一个层面进行观察”
• 内容特点：话题极度广泛，涵盖生物学、艺术、社会运动、科技对话等（如保罗·埃利希、R·克拉姆、马歇尔·麦克卢汉等多位名家的投稿）

③ Whole Earth Software Review (1984-1985)

• 发起人：约翰·布罗克曼 (John Brockman)
• 初衷：将《Whole Earth Catalog》的“工具推荐”理念引入 计算领域，识别并推荐当时最佳的软件工具
• 实际情况：遭遇 商业失败，仅出版 两期目录 及 三期增刊

④ Whole Earth Review (1985-1997)

• 成立背景：1985年由《Whole Earth Software Review》与《CoEvolution Quarterly》合并而成
• 内容延续：保留工具与书籍评论传统，结合 生态、科技 及 社会、社区 议题
• 重要主题：持续探讨 “公地” (the commons) 及相关的 “公地悲剧” 概念

⑤ Whole Earth Magazine (1997-2002)

• 性质：《Whole Earth Review》的延续
• 管理人：彼得·沃肖尔 (Peter Warshall) 和迈克尔·斯通 (Michael Stone)
• 口号更新：扩展为 “Access to tools, ideas, and practices”（获取工具、理念与实践）

⑥ 专题出版物

• 形式：针对特定主题或与相关组织合作出版的独立卷册
• 内容来源：通常 重印以往刊物文章，并补充新的内容，作为系列的补充延伸。

https://academic.oup.com/jes/article/9/11/bvaf141/8277723?login=false

基于AI的代理编程（Agentic Coding）：实践、挑战与演进

核心概念与生产力飞跃 文章提出“代理编程”（Agentic Coding）理念，区别于缺乏严谨性的“氛围编程”（vibe coding）。在该模式下，人类工程师与AI代理深度协作：AI负责生成大部分代码（作者个人占比达80%），工程师负责设定约束、严格审查并对最终代码质量负责。结合Rust语言的编译期安全特性，该团队实现了高达典型高效团队10倍的代码吞吐量。

高速开发带来的系统性挑战 代码产出率的阶跃式增长打破了原有的工程平衡：

1. Bug频率激增：提交量增加10倍导致生产环境或共享代码库中的Bug从偶发变为常态，影响团队整体进度。
2. CI/CD流水线阻塞：传统需数小时或数天的构建与部署流程无法适应高频提交，单一问题提交会导致部署回滚和流水线停滞。
3. 沟通与决策瓶颈：10倍的开发速度伴随10倍的架构与实现决策，传统异步沟通（如消息软件或排会）延迟过高，极易造成工作阻塞或方向偏离。

应对策略与工程实践重构 为维持高速开发，团队必须将问题提交的概率和反馈延迟降低一个数量级：

• 低成本全面测试：借鉴航空业“风洞测试”，利用AI代理低成本生成和维护高保真的外部依赖“替身”（Fakes），在开发者本地运行全系统端到端测试，提前捕获组件集成Bug。
• 加速反馈循环：重构CI/CD基础设施，使其速度提升一个数量级，实现分钟级的问题识别、隔离与回滚，避免流水线长时间停滞。
• 降低协调成本：针对高频决策，摒弃高延迟的异步沟通。同地办公团队通过面对面白板讨论实现分钟级决策对齐（分布式团队的协调仍是待解决的开放挑战）。

未来展望：全生命周期的协同演进 AI代理的真正价值不仅在于加速代码编写，更在于大幅降低了过去因成本过高而难以普及的先进工程实践的实施门槛。成功的关键在于不能仅将AI生搬硬套到现有流程中，而必须利用AI全面重构测试、部署和协调机制，推动整个软件开发生命周期的协同演进。

为什么“忙碌海狸”研究者忌惮“反九头蛇”

2024年夏，一个在线社区确定了被称为BB(5) 的精确数值，这是理论计算机科学中一个古老问题——忙碌海狸游戏——50年来的首次重大突破。BB(5)的值现在已知为47,176,870，它是所谓的忙碌海狸数列中的第五个，这些数衡量了简单计算机程序所能完成的最复杂计算的复杂性。

研究团队的下一步是确定第六个忙碌海狸数BB(6)，并已取得一些进展。但研究者预计短期内无法确定BB(6)的真实值，因为这需要他们理解一个名为**“反九头蛇”（Antihydra）** 的程序的行为，该程序类似于一个长期未解的数学问题——Collatz猜想。

忙碌海狸游戏基础

忙碌海狸游戏使用名为图灵机的假设设备来代表计算机程序。图灵机通过一组规则（称为“状态”）在无限长的、划分成格子的磁带上读写0和1进行计算。程序的复杂性由其规则的数量衡量。

忙碌海狸数BB(n) 定义为：所有n规则图灵机在空白磁带（所有格子初始为0）上启动并运行时，在停止前所执行的最长有限步数。例如，BB(6)就是所有六规则图灵机中，在空白磁带上启动后能运行最长时间才停止的那个程序的步数。

确定BB(6)的主要障碍在于判断一个图灵机是否最终会停止。对于六规则机器，目前仍有1,618个“悬而未决” 的程序无法确定其命运，Antihydra便是其中之一。要确定BB(6)的值，必须首先解决像Antihydra这样的机器是否停止的问题。

理解Antihydra：从低层规则到高层描述

研究图灵机行为的关键是找到其高层描述。例如，已知的第五忙碌海狸机器的低层规则，可以等价为一个简单的高层程序：从x=0开始，反复根据x除以3的余数应用特定公式更新x，直到遇到停止条件。这种高层描述有助于分析机器何时停止。

许多著名的忙碌海狸机器都属于一类“类似Collatz”的图灵机家族，其高层行为模式为：根据当前数值x除以一个固定数N的余数，应用不同的公式得到新x，并检查是否满足特定停止条件。这与Collatz猜想的过程相似。

Collatz猜想的规则是：对于任意正整数x，若x为偶数则除以2，若为奇数则计算3x+1，猜想认为该序列最终总会到达1。尽管已有海量数值验证，但该猜想仍未被严格证明。

Antihydra的恐怖：与Collatz猜想的困境

Antihydra的高层行为规则如下：

1. 从x=8开始。
2. 检查x的奇偶性。
3. 若x为偶数，计算 3x/2 得到新x，并累加一个“偶数计数”。
4. 若x为奇数，计算 (3x-1)/2 得到新x，并累加一个“奇数计数”。
5. 检查是否“奇数计数”超过了“偶数计数”的两倍。若是则停止，否则返回第2步。

其停止条件取决于两个计数器的极端不平衡。由于计算公式 3x/2 和 (3x-1)/2 似乎不会系统地偏向奇数或偶数，其序列行为类似于重复抛硬币。概率上讲，要达成“奇数计数” > 2倍“偶数计数”的停止条件极其罕见。研究者已将Antihydra模拟超过2,700亿步，发现奇偶计数大致相当，远未达到停止条件。因此，它“极可能”永不停止，但无人能证明这一点。

这种情况与Collatz猜想的一个变体——5x+1 问题——类似，后者也难以证明任何单一输入的序列会发散。Antihydra与Collatz猜想之间不存在精确的数学等价关系，但它们难以解决的原因非常相似：要证明一个序列最终到达某点原则上可以通过暴力计算，但要证明一个序列永不停止则异常困难。

“神秘生物”与未来挑战

像Antihydra这样行为类似Collatz、且被认为“很可能”永不停止的图灵机，被研究者称为**“神秘生物”（Cryptids）**。已发现的此类机器数量众多，表明除非研究者开发出处理Collatz类问题的新数学工具，否则超越BB(5)的忙碌海狸数将难以触及。著名数学家保罗·埃尔德什曾表示：“数学可能还没准备好应对这些问题。”

尽管面临这些理论障碍，忙碌海狸研究仍在继续。研究者们仍在探索“神秘生物生态学”：它们有多少种类？彼此之间以及与其他未解决数学问题有何关联？正如文章开头所述，在看似简单的规则背后，总可能隐藏着令人惊讶的计算行为。

JSON Query 是一种用于查询和操作 JSON 数据的查询语言，支持链式执行和管道连接。

核心组件

• 函数：以 函数名(参数1, 参数2, ...) 形式定义，如 filter、sort、max，在链中执行并输出结果。示例：sort(.address.city, "asc") 或 filter(.age >= 21) | sort(.age, "asc")。
• 操作符：支持基本操作符（如 >=、and），需要左右两侧操作数，可用括号覆盖优先级。示例：.age >= 18 或 filter(.age >= 18 and .age <= 65)。
• 管道：用 | 连接多个查询，按顺序执行，前一个输出作为后一个输入。示例：filter(.age >= 18) | sort(.name)。
• 对象：类似 JSON 对象，键为属性名，值为查询，用于数据转换或并行执行查询。示例：{ names: map(.name), numberOfNames: size() }。
• 数组：类似 JSON 数组，用方括号包裹，项用逗号分隔。示例：filter(.city in ["New York", "Atlanta"])。
• 属性：用 .prop1.prop2 检索对象属性，支持嵌套，或用 get() 函数。示例：.age.address.city."first name"。
• 值：支持 JSON 原始值，如字符串（"string"）、数字（42）、布尔（true/false）、null。示例："Hello world"、-1.2e3。

关键特性

• 链式执行：函数作为方法在数据链中应用，输出转发到下一查询。
• 管道机制：通过管道连接查询，实现顺序数据处理。
• 灵活查询：结合对象、数组和操作符，支持复杂数据转换和筛选。
• 文档支持：提供函数、操作符等参考，便于学习和使用。

JSON Query 简化了 JSON 数据的操作，适用于动态查询和数据处理场景。

莱昂纳多·达芬奇《大西洋古抄本》的完整数字化

核心要点概述

本文介绍了由The Visual Agency完成的莱昂纳多·达芬奇《大西洋古抄本》（Codex Atlanticus）的完整数字化工程。该抄本是达芬奇现存最多原稿的集合，包含1119页双面书写或绘图的手稿，跨越其从1478年至1519年的职业生涯，是理解其作为艺术家、工程师和发明家思维过程的关键实物。

关于“文艺复兴人”与达芬奇

文章首先指出，“文艺复兴人”这一标签如今已被过度使用，但在达芬奇的时代，艺术与科学并未分离。达芬奇将精湛的艺术与工程学相结合，其绘画的惊人效果源于数学精度、细致研究和直接观察。他将每个艺术项目都视为实验，并通过大量笔记本来体现其无论在机械、解剖还是艺术领域，凡事皆需周密计划与设计的“技术人员”思维。

抄本的数字化背景与历史

• 数字化进程：《大西洋古抄本》的数字化是继《阿伦德尔抄本》（Codex Arundel）和《福斯特抄本》（Codex Forster）之后，又一重要手稿向公众开放。
• 内容与名称：抄本包含工程图、解剖研究、艺术草图以及达芬奇创作的寓言。其名称与“大西洋”无关，而是因使用与地图集相同尺寸的纸张装订而得名。
• 流传历史：手稿由达芬奇的学生乔凡尼·弗朗切斯科·梅尔齐继承，16世纪由雕塑家蓬佩奥·莱奥尼收集。后曾被拿破仑掠至法国卢浮宫，直至1815年维也纳会议后归还。期间，负责归还的使者因无法解读达芬奇的镜像文字，一度误将其当作中文手稿。

抄本的重要内容

除了技术图纸，抄本还包含达芬奇写给米兰公爵的“求职信”，即他的“简历”。信中他列举了九项资格，其中第四点描述了其便捷的、可运输的轰炸方法，旨在震慑并重创敌人。抄本中最著名的图画之一，即展示了某种宏伟结构，自18世纪以来便令参观者惊叹，它体现了达芬奇主要动机在于以最优雅的方式解决技术问题，艺术性可能是其副产品。

数字化与访问

目前，公众可通过在线方式访问《大西洋古抄本》的完整数字化版本。

文章介绍了用户模式Linux (UML)，这是一种允许将Linux内核作为用户空间进程运行的技术，无需传统虚拟机软件（如QEMU）或root权限。

核心概念

• 硬件抽象与虚拟化：Linux内核的核心职责是抽象硬件，为用户空间提供统一接口。当硬件为虚拟时（如在QEMU中），驱动程序可被“半虚拟化”，即驱动程序知晓自身运行于虚拟硬件之上，从而采用特定通信方式以提升性能。
• UML的本质：UML可视为一种半虚拟化内核配置。它不直接运行在裸金属硬件上，而是作为一个普通的用户空间进程运行在宿主内核之上。它利用宿主系统的用户空间设施（如文件、套接字）来模拟虚拟硬件（如将文件映射为块设备，标准输入输出作为控制台）。

构建与运行

1. 构建UML内核：
   • UML目前主要支持x86平台。
   • 使用 ARCH=um make menuconfig 配置内核，会看到UML特有的半虚拟化驱动选项。
   • 需要启用如 BLK_DEV_UBD 等选项，以允许使用宿主文件作为虚拟块设备。
   • 通过 ARCH=um make -j16 编译，生成一个动态链接的ELF可执行文件（linux）。
2. 构建用户空间：
   • 需要准备一个根文件系统（如使用Buildroot构建的ext2镜像）。
3. 运行嵌套内核：
   • 命令示例：./linux ubd0=<根文件系统路径> ubd1=<其他磁盘镜像路径> root=/dev/ubda。
   • 实验演示了启动UML、挂载磁盘、写入文件，关闭后在宿主系统中成功读取该文件，证明了其功能。

实际应用与定位

• 主要优势：UML非常适合内核调试和实验探索，因其能便捷地启动一个独立的内核实例。
• 与成熟方案对比：对于生产环境的隔离工作负载，UML可能不是最佳选择。KVM虚拟化（在更底层工作）提供了更强的隔离性和性能，而容器在可接受共享宿主内核的场景下也是可行的替代方案。
• 独特价值：UML处于传统虚拟机和容器之间的一个有趣位置，它提供了独立的内核实例，同时与宿主内核保持着独特的联系，是一个极好的实验工具。

总结：用户模式Linux提供了一种轻量级方式来运行一个完整的Linux内核作为用户进程，核心价值在于内核开发、调试和学习，而非生产级虚拟化部署。

https://www.science.org/content/article/rats-filmed-snatching-bats-air-first-time

2025年10月23日，a1k.org网站报道，阿米加原型机“Lorraine”在德国举行的Amiga 40活动上首次展出。该原型机是第一个阿米加计算机，由原开发团队成员Dale Luck保存，其特点是使用三个大型堆叠的面包板，而非定制芯片。阿米加用户“Pittrock”拍摄了展览照片，并授权网站发布这些图片。

https://www.reuters.com/business/world-at-work/amazon-targets-many-30000-corporate-job-cuts-sources-say-2025-10-27/

英伟达宣布以10亿美元收购诺基亚股份，消息公布后诺基亚股价飙升22%。诺基亚将发行超过1.66亿新股，所筹资金用于人工智能及其他企业用途。双方达成战略合作伙伴关系，共同开发下一代6G蜂窝技术，诺基亚将把5G和6G软件适配于英伟达芯片，并合作开发面向人工智能的网络技术。诺基亚表示，英伟达将考虑将相关技术纳入其未来人工智能基础设施规划。此项投资是英伟达近期一系列战略持股的最新举措，该公司此前还投资了英特尔、OpenAI、Wayve及英国云计算公司Nscale。

Tailscale Services 摘要

核心概念

Tailscale Services 是一种新的网络资源定义方式，用于扩展访问控制的精细度。它解决了在无法直接安装 Tailscale 的资源（如动态 IP、容器环境、单机多资源或多位置逻辑资源）上实现精确连接和控制的挑战。

工作原理

• 为每个逻辑资源分配一个虚拟的 Tailscale IPv4 和 IPv6 地址对，并配以唯一的、人类可读的 MagicDNS 名称。
• 服务本身成为授权的单元，可以通过 API 进行完全自动化的维护。
• 服务可以映射到一个或多个 Tailscale 节点，从而能够替代传统的负载均衡设置，实现简单智能的路由和高可用性。

架构与配置

• 服务定义：包括一个稳定的 TailVIP、MagicDNS 名称、端点定义以及一组广告主机。
• 服务主机：充当服务后端的 Tailscale 客户端。主机必须通过验证（如接口、连接性、状态和标签检查）才能被视为活跃。
• 配置方式：可通过 Tailscale API 或管理控制台定义服务。主机可通过声明式配置文件或 tailscale serve 命令行工具来广告端点。

主要特性与优势

1. 精细访问控制：服务是授权策略中的有效目标，可以通过 TailVIP 或 MagicDNS 名称（带 svc: 前缀）授予用户和设备访问权限。
2. 开箱即用的高可用性：可以将服务指向多个目的地。系统会基于网络可用性、主机广告状态、端点验证、全局引导和区域负载分布智能路由流量，实现高可用。
3. 完全可自动化：可通过 API 规模化定义，适用于 CI/CD 和自动化工作流。

应用案例

早期用户已将其用于多种场景：

• 工作负载连接：将 CI 管道中的开发工作负载连接到测试套件、QA 团队和内部秘密存储，替代了防火墙、负载均衡器和双向 TLS 等传统复杂设置。
• 简化家庭实验室：为容器化应用提供 MagicDNS 名称，免于记忆各种端口号，并能在软件更新时实现高可用。
• 内部应用访问：构建数据库代理、秘密存储、MCP 服务器、遥测网关等，无需复杂的网络和安全基础设施。

当前状态与未来展望

• 当前状态：公开测试版，所有计划均可使用，在测试期内不收费或设限。
• 即将推出：在即将到来的 1.92 稳定版中，服务主机将能够指向本地网络目的地（而非仅限本地主机资源）。
• 未来计划：包括增强状态验证、通过 tsnet 注册服务主机的 API、扩展信任边界、与第三方代理原生集成、为服务接入 Funnels 以实现公开高可用访问等。

Check out the LumenPnP: http://bit.ly/43qReBCCommarker Omni 1:https://amzn.to/4hp0MTsViagrid Repo:https://github.com/opulo-inc/viagridViagrid Sign Up Form:ht...

Fnox：与 mise 无缝配合的秘密管理工具

Fnox 是一个全新的命令行秘密管理工具，旨在与 mise 开发工作流无缝协作。它提供加密和远程秘密管理功能，适用于开发、CI/CD 和生产环境，通过本地加密或远程存储后端提供统一的敏感数据管理界面。

为何选择 Fnox？

虽然 mise 内置了秘密支持（如 age 加密和 sops），但更适用于简单的基于文件的场景。Fnox 则针对更复杂的生产需求提供了以下增强功能：

• 远程存储支持：集成 AWS Secrets Manager、Azure Key Vault 等云服务，以及 1Password、Bitwarden 等密码管理器。
• 操作系统钥匙串集成：利用本地凭据存储。
• 远程加密：通过云 KMS 服务进行加密。
• 团队协作：支持多用户加密密钥。
• 企业集成：兼容 HashiCorp Vault 等秘密存储方案。
• 实时访问：避免缓存带来的安全隐患。

核心特性

开发者友好

• Shell 集成：进入目录时自动加载秘密。
• 环境配置支持：可为生产、测试、开发等环境配置不同的秘密集。
• 简单 TOML 配置：配置文件可提交至版本库（文件本身不包含秘密）。
• 离线工作：在使用加密提供程序时可离线操作。

团队就绪

• 多人解密：多个接收者可解密同一秘密。
• 灵活密钥管理：团队成员可使用各自的 SSH/age 密钥或利用 KMS。
• 无需共享主密码。

快速开始

1. 通过 mise 安装 fnox：

   mise use -g fnox
   

2. 初始化并配置提供程序：

   fnox init
   fnox provider add age --id main --recipients ~/.ssh/id_ed25519.pub
   fnox secret set API_KEY --value "your-secret-value" --provider main
   

3. 在工作流中使用秘密：

   # 导出秘密为环境变量
   fnox exec -- your-command
   # 获取单个秘密
   fnox get API_KEY
   # 启用 shell 集成（进入目录时自动加载秘密）
   fnox shell hook
   

与 mise 的协作方式

Fnox 与 mise 独立但互补：

• mise：管理工具、任务和一般环境变量。
• fnox：管理敏感秘密（通过加密和远程存储）。

典型配置示例：

• mise.toml 中配置工具和一般环境变量。
• fnox.toml 中配置秘密提供程序和秘密条目。

可通过以下命令同时使用两者：

mise x -- fnox x -- npm start

为何 Fnox 是独立工具？

将 Fnox 开发为独立工具而非集成至 mise 中，主要出于以下架构考量：

1. 性能问题：mise 会频繁重新加载环境（如目录切换、命令执行后），若秘密依赖远程服务（如 KMS、1Password），每次重新加载都会引发网络请求，导致 mise 性能严重下降。
2. 安全权衡：缓存虽能提升性能，但会引入安全风险（如缓存文件的安全存储、加密密钥管理、缓存文件自身成为安全漏洞等）。
3. 架构挑战：让 mise 跳过某些环境变量的重新加载需要大幅重构代码，增加复杂性。

通过独立工具，两者可专注于各自核心职责：

• mise：通过激进缓存实现快速环境管理。
• fnox：通过实时访问远程提供程序实现安全秘密管理。

关于 mise 内置秘密管理

mise 的内置秘密管理（如 age/sops）仍处于实验阶段，未来尚未确定。目前，作者没有计划为 mise 引入类似 fnox 的远程秘密后端。

了解更多

• GitHub：https://github.com/jdx/fnox
• 文档：https://github.com/jdx/fnox#readme
• 现已可通过 mise use fnox 安装。

核心观点

文章指出，尽管人工智能（尤其是大语言模型）能够完成编码任务，但它目前无法独立构建软件。作者通过观察许多人寻求技术联合创始人或CTO来将“氛围编码”的应用变为生产就绪产品这一现象，提出了这一结论。

主要论点

1. 现象与需求：许多非技术背景的业务专家（如法务、客户经理）利用生成式AI快速构建了应用原型或演示，但在将产品推向实际应用时遇到困难，因此转而寻找技术合伙人。
2. 区分“编码”与“软件工程”：
   • 编码：解决明确定义、孤立的问题。AI模型在此方面表现良好。
   • 软件工程：涉及处理复杂性，将众多简单功能集成到一个可维护、可扩展的系统中。构建生产就绪的应用属于软件工程范畴。
3. AI的局限性：当前AI擅长演示功能，但无法妥善处理系统集成、长期维护和扩展等软件工程核心挑战。因此，许多AI生成的代码原型需要彻底重构才能投入实际使用。
4. 现状意义：这一现象表明，软件工程尚未被自动化。AI是一个强大的编码助手，但软件开发的复杂性和系统性构建工作仍需人类工程师的专业技能和判断。

3M软盘参考手册（1983年）摘要

1. 概述与目的

• 软盘是计算机系统的数据存储设备，用于扩展存储容量，支持数据的删除与更新。
• 主要尺寸包括8英寸（200mm）和5.25英寸（130mm）。
• 本手册旨在提供技术资料，帮助销售与服务人员理解软盘的结构、制造、记录原理及使用规范。

2. 产品代码系统

• 3M软盘通过代码标识规格，如：
  • S：单面；D：双面
  • S：单密度；D：双密度
  • 数字（如32、10、16）表示扇区数
  • R：可翻转使用（双面）
  • W/WP：带写保护口
  • RH：加固轮毂

3. 物理结构与组件

软盘由三大部分构成：

• 外壳（Jacket）：PVC材质，保护介质免受物理损伤。其上开有多种孔槽：
  • 标签区：标识产品信息
  • 驱动器主轴孔：用于旋转介质
  • 写入使能缺口（5.25英寸）：打开时允许写入
  • 索引孔：与介质孔对齐，提供读写起始信号
  • 写入保护口（8英寸）：打开时禁止写入
  • 磁头访问槽：供读写磁头接触介质
  • 应力释放缺口：分散外壳应力，防止介质损伤
• 衬垫（Liner）：无纺布材质，清洁介质表面并保证匀速旋转。
• 介质（Media）：磁记录材料，由PET基底和氧化铁涂层组成。

4. 制造流程

• 介质：基底涂覆氧化铁 → 切割 → 冲压成型 → 表面抛光。
• 外壳：材料切割 → 与衬垫复合 → 冲压孔槽 → 折叠成型。
• 最后装配并封装。

5. 磁记录原理

• 通过读写头线圈产生磁场，磁化介质上的微小区域。
• 磁化状态代表二进制“1”，未磁化代表“0”。
• 密度：单位长度磁道可存储的位数。双密度存储容量是单密度的两倍，但对介质可靠性要求更高。

6. 架构与格式

• 磁道（Track）：同心环状数据存储区，从外道（00）向内道编号。
  • 48TPI（每英寸磁道数）为标准密度，96TPI为四倍密度。
• 扇区（Sector）：磁道被划分的弧形段。
  • 软分区：扇区边界由介质上记录的标识信息定义。
  • 硬分区：扇区边界由介质上冲压的扇区孔定义。
• 所有软盘均有一个索引孔，用于定时同步。
• 使用前需格式化（写入扇区地址信息）和初始化（分配系统用途）。预编程软盘已包含特定数据。

7. 兼容性判断指南

为确保软盘与硬件匹配，手册提供排查步骤：

1. 确认系统制造商和型号，查阅兼容列表。
2. 如使用现有软盘，可通过交叉引用查找对应3M产品。
3. 若无直接匹配，需根据物理特征（尺寸、记录面、密度、分区类型）选择。

• 8英寸软盘：注意写入保护口位置。
• 5.25英寸软盘：均有写入使能缺口；加固轮毂为可选特性。

8. 常见问题分析

针对典型故障提供排查思路：

• 驱动器就绪失败：检查兼容性、物理损伤、格式是否破坏、驱动器索引检测装置。
• 可读不可写：确认是否处于写入保护状态。
• 可写不可读：检查介质物理损伤、进行读取校准、检查磁头对齐、压力垫状况及电子校准。
• 格式化时写入错误：检查物理损伤、尝试分配备用磁道、检查驱动器磁头状况。

9. 使用与维护建议

• 操作注意事项：
  • 远离食物饮料、烟雾，防止污染。
  • 避免靠近磁场（如电机、变压器）。
  • 禁止弯折、使用回形针或橡皮筋。
  • 勿触摸或清洁介质暴露部分。
  • 避免高温（＞52°C）和阳光直射。
  • 勿施加重压。
  • 标签应更换而非叠加，使用软头笔书写。
• 环境要求：
  • 操作/存储温度：48TPI盘为-10°C至52°C，96TPI盘为-10°C至46°C。
  • 操作/存储湿度：48TPI盘为8%-80%RH，96TPI盘为20%-80%RH。
  • 运输温度范围：-40°C至51.6°C，湿度8%-90%RH（禁止结露）。

10. 术语表

手册最后提供了常用计算机与软盘术语的解释，如地址、比特、字节、磁道、扇区、软错误、硬错误、初始化等，便于读者理解专业内容。

华硕ProArt Display 8K PA32KCX专业显示器将于10月上市

华硕宣布，全球首款8K HDR Mini LED专业显示器ProArt Display 8K PA32KCX将于2025年10月上市。该产品专为内容创作者设计，旨在提供顶级的色彩精度与视觉体验。

核心显示技术

• 采用Mini LED背光技术，具备4032个局部调光区域，可精准控制背光，减少光晕效应。
• 峰值亮度达1200尼特，全屏持续亮度为1000尼特，确保在不同光照条件下都能呈现鲜明的对比度和细节。
• 面板分辨率为8K（7680 x 4320），像素密度高达275 PPI，相比同尺寸4K显示器，可显示内容多出高达300%，文本更清晰，细节更丰富。

色彩与精度

• 色域覆盖95% Adobe RGB、97% DCI-P3、100% sRGB及100% Rec. 709，满足专业视频编辑和后期制作需求。
• 采用真正的10位IPS面板，可显示超过10.7亿种颜色。
• 出厂时经过严格校准，确保Delta E<1的色彩差异，实现行业领先的色彩保真度。

校准与维护

• 内置电动翻转校色仪，可自动或按计划进行自我校准，无需额外软件，兼容任何操作系统。
• 支持ASUS ProArt Calibration软件，校准参数可保存在显示器内部芯片，连接不同设备或系统时无需重新设置。
• 同时兼容Calman和Light Illusion ColourSpace CMS等专业硬件校准软件，提供灵活的高级校准选项。
• 通过ProArt Color Center软件，可实现远程集群控制和校准，便于管理多台显示器。

HDR与连接性

• 支持多种HDR格式，包括Dolby Vision、HLG和HDR10，提供出色的亮度、对比度和色彩表现。
• 连接端口丰富：双Thunderbolt 4端口（其中一个支持96W充电和菊花链）、DisplayPort 2.1以及两个HDMI 2.1端口。
• 内置Auto KVM功能，可通过一套键盘鼠标轻松切换控制两台连接的电脑。
• 支持画中画（PiP）和多画面（PbP）模式，PbP模式下最多可同时显示四个输入源，并可独立配置色彩模式。

人性化设计与附加功能

• 配备环境光传感器和接近传感器，自动调节屏幕亮度以适应环境并节省能源。
• 显示器支架支持倾斜、旋转、升降及垂直旋转，便于调整观看角度。
• 附带可拆卸遮光罩，减少环境光干扰。
• 购买优惠：在指定区域购买该显示器，可获赠价值高达397.44美元的Adobe Creative Cloud、Adobe Substance 3D和Adobe Acrobat三个月免费订阅（兑换截止日期为2026年8月31日）。

Iroh-blobs 0.95 新特性概述

Iroh-blobs 0.95 版本引入了几项重要新功能，对 blobs 及 iroh 用户均有价值。

1. 连接池（Connection Pool）

新增 util::connection_pool 模块，用于管理与多个端点的连接，同时限制并发连接数上限。在 blobs 中，主要用于协调从多个提供者下载内容。

• 核心用途：避免同时保持过多连接（浪费资源），同时减少频繁建立新连接的开销。
• 基本 API：get_or_connect 会从池中获取现有连接，若无则新建并存储。空闲连接会在配置时间后自动关闭。
• 高级配置：可设置最大保留连接数、连接建立超时时间、空闲连接保留时长等。
• 连接预处理：支持在连接移交用户前进行状态检查（例如，仅使用直连以优化性能，拒绝中继连接）。
• 重要提示：池返回的是 ConnectionRef（包含生命周期追踪），而非原始 Connection。用户应避免克隆 Connection，而应传递 ConnectionRef 或 &Connection 以保持追踪有效。
• 未来计划：该模块将随 iroh 1.0 发布后迁移至独立的 iroh 工具库。

2. 抽象请求与响应流（Abstract Request/Response Streams）

为支持对协议流进行转换（如压缩）而引入新的 trait，允许包装发送和接收流。

• 设计目标：在不修改核心协议的情况下，通过包装流来实现如压缩等功能，能跨文件寻找冗余，压缩率更优。
• 实现方式：新增 SendStream 和 RecvStream 的包装 trait，默认情况下 iroh-blobs 仍直接使用原生流。
• 新 trait 特点：
  • 直接支持 Bytes 类型，避免默认情况下的数据拷贝。
  • 包含 stop/reset 方法以关闭流，以及发送流的 stopped 方法（返回 future，用于感知远端关闭）。
• 应用场景：已有压缩示例 (compression.rs)，sendme 将在后续版本中提供此功能作为可选特性。
• 未来计划：与连接池类似，这些 trait 也将在 iroh 1.0 后迁移至独立工具库。

3. 增强的提供者事件（Enhanced Provider Events）

此变更始于 iroh-blobs 0.93。提供者端现可获得更精细的活动事件通知。

• 实现基础：基于 irpc 协议实现。
• 功能特点：
  • 可为每种请求类型配置事件掩码，决定是否接收通知。
  • 支持拦截请求（例如，根据哈希值或节点ID决定是否响应）。
• 示例：可实现仅服务来自允许哈希集合的 blobs 请求的处理器。

未来展望

• 下一个主要特性是针对单个 blob 的最小化多提供者下载功能。
• 随着 iroh 1.0 发布，上述通用模块将迁移至独立的 iroh 工具库。
• Iroh 是一个专注于简单可用的设备互联网络库，提供现成协议生态和自定义抽象能力，已在生产环境中部署。

量化按值传递的开销

文章通过基准测试和汇编分析，研究了函数按值传递不同大小结构体时的性能开销，核心发现如下：

主要结论

• 小尺寸（≤256字节）传递开销很低：使用 SIMD 寄存器传递，与传递指针大小的开销相当。
• 大尺寸（>256字节）使用 rep movs 指令：性能与数据大小近似线性相关。
• 存在特定尺寸的性能尖峰：在 4064-4080 字节和 8161-8176 字节范围内，传递耗时可能激增 4 倍（在 AMD Zen 架构 CPU 上），疑似与 CPU 微码实现有关。

详细发现

1. 小结构体（1-32字节）：汇编显示分别通过寄存器和栈传递，但性能差异可忽略。
2. 256字节分界点：256字节使用未展开的向量化 memcpy，257字节切换到 rep movs（微编码循环），性能出现清晰断崖。
3. 周期性性能波动：rep movs 性能呈现周期为32字节的波动（8快24慢），与汇编代码无关，可能源于指令本身特性。
4. 性能尖峰机制：在特定尺寸（如4064 vs 4065字节）性能突变，但尖峰不持久，疑似 rep movs 在特定迭代次数下的微码缺陷。

性能参考数据

• 16字节结构体：每秒可传递约7.3亿次。
• 2048字节结构体：每秒可传递约2600万次。

建议

• 避免在 AMD Zen CPU 上按值传递 4064-4080 字节或 8161-8176 字节的数据。
• 对于大于 256 字节的数据，考虑按引用传递以避免潜在开销。

作者通过分析汇编代码，揭示了编译器代码生成（如使用向量寄存器、循环展开）和底层 CPU 指令特性对按值传递性能的复杂影响。

奥地利为解决电网扩张中公众对传统输电塔外观的反对，推出了“奥地利电力巨人”项目。该项目由奥地利电网公司、GP设计伙伴公司和BauCon合作，将输电塔设计为巨型动物雕塑，代表奥地利九个联邦州的地域特色。例如，鹳鸟象征布尔根兰州的鹳鸟迁徙，雄鹿代表下奥地利州的森林覆盖山麓。

已开发的两个原型（鹳鸟和雄鹿）已通过结构稳定性和高压性能测试，计划在未来安装至所有九个州。设计理念旨在通过自然灵感造型，提升公众对电网扩建的接受度，同时强化地区的经济与旅游吸引力。该项目于2023年获得红点设计奖，其迷你模型将在新加坡红点博物馆展出至2026年10月。

目前，相关方正在测试实施可行性。外界认为，这种设计可能通过地区自豪感和视觉吸引力，改变公众对工业基础设施的负面看法，使电力塔从“眼中障”转变为地标，从而增加接受度。

SICK：用于JSON类数据的索引去重二进制存储格式

本文介绍了SICK（Streams of Independent Constant Keys）及其二进制实现EBA（Efficient Binary Aggregate）。SICK是一种针对JSON类数据结构的新表示方法，EBA是基于此的、支持自动去重的二进制存储格式。

核心概念与工作原理

SICK的核心创新在于将层次化的JSON数据转换为扁平化、去重的值表结构。每个值（包括标量、对象和数组）被存入按类型划分的表格中，并通过**（类型标记，索引）对**进行引用。原始JSON结构通过这些引用来重建。这种设计带来了几个关键特性：

1. 索引访问：可以按索引直接定位到所需数据，无需解析整个文件。
2. 自动去重：相同的值（如重复的字符串或嵌套结构）在存储中只保留一份，显著减少存储空间。
3. 流式潜力：扁平化表示使得数据理论上可以流式传输和处理，支持常量内存读取。

EBA二进制格式与关键能力

EBA是SICK的高效二进制实现。文件由头部、类型特定的值表（如整数、字符串、数组、对象表）和根表组成。一个引用占用5字节（1字节类型标记+4字节索引），通过跳表（Skip List）和哈希算法实现对对象字段的快速查找（接近O(1)复杂度）。

与传统JSON相比，EBA的主要优势包括：

• 访问效率：读取特定字段时，性能远优于解析整个JSON文件。
• 内存效率：支持增量读取，内存占用恒定。
• 存储紧凑：去重特性通常使文件体积小于等效的JSON。

其主要权衡在于编码（写入）更复杂、更慢，但解码（读取）速度快得多且内存友好。最适用于选择性读取字段、处理大型或结构重复的JSON数据、以及内存受限的场景。

项目现状与实现

该项目声称经过实战检验，可用于生产环境。目前提供Scala、C#和JavaScript的实现，支持编码器、解码器和游标（Cursors）。但部分高级功能（如路径查询、流式编解码器）在不同语言的支持程度不一，社区欢迎贡献。

当前实现存在一些限制，如单个对象的最大键数、数组最大元素数等，但通常足以满足绝大多数应用场景。

理论背景与未来展望

文章指出，JSON的Type-2语法特性要求使用下推自动机解析，阻碍了高效流式解析器的实现。SICK通过将其转换为扁平表结构来规避这一问题，为流式处理、高效增量更新等应用奠定了基础。

未来计划包括扩展语言支持（如Python、Rust）、开发流式抽象，以及探索循环引用、自定义类型等扩展能力。

MCP-Scanner：MCP 服务器安全漏洞扫描工具

MCP-Scanner 是一款用 Python 编写的工具，用于扫描 MCP（模型上下文协议）服务器及其工具，以发现潜在的安全问题。它结合了三种扫描引擎：Cisco AI Defense 检查 API、YARA 规则和LLM 即裁判，用于检测恶意的 MCP 工具。

主要功能

• 多引擎安全分析：可独立或组合使用三种扫描引擎（API、YARA、LLM）。
• 多模式运行：支持作为独立的命令行工具或 REST API 服务器运行。
• 全面扫描能力：
  • 扫描 MCP 工具、提示、资源和服务器指令。
  • 扫描 MCP 服务器源代码（行为代码扫描）。
  • 扫描 Python 依赖包中的已知漏洞（CVE/PYSEC/GHSA）。
  • 使用 VirusTotal 扫描二进制文件中的恶意软件。
  • 进行就绪性扫描，检查生产环境问题（超时、重试、错误处理）。
  • 提示防御扫描，检查工具描述和系统提示中缺失的防御措施。
• 灵活配置：支持显式的认证控制（包括 OAuth）、自定义端点、可添加自定义 YARA 规则。
• 静态/离线扫描：支持扫描预生成的 JSON 文件，适用于 CI/CD 管道和离线环境。
• 详细报告：提供多种输出格式（摘要、详细、表格、按严重性、原始 JSON）。

安装与配置

前提条件：

• Python 3.11+
• uv（Python 包管理器）
• 可选：Cisco AI Defense API Key、LLM 提供商 API Key、VirusTotal API Key。

安装方式：

• 作为 CLI 工具安装：uv tool install --python 3.13 cisco-ai-mcp-scanner
• 从源码安装：克隆 GitHub 仓库后使用 uv sync。
• 作为项目依赖：使用 uv add cisco-ai-mcp-scanner。

环境变量配置：

• 核心 API：设置 MCP_SCANNER_API_KEY 和 MCP_SCANNER_ENDPOINT（可选，用于 Cisco AI Defense 分析器）。
• LLM 配置：设置 MCP_SCANNER_LLM_API_KEY、MCP_SCANNER_LLM_MODEL 等变量，支持 OpenAI、AWS Bedrock、Azure OpenAI 及本地 LLM。
• VirusTotal：设置 VIRUSTOTAL_API_KEY。
• 其他：可配置 stdio 服务器启动超时等参数。

使用方式

命令行接口：

• 扫描已知配置：mcp-scanner --scan-known-configs --analyzers yara --format summary
• 扫描远程服务器：mcp-scanner --server-url <URL> --analyzers yara --format summary
• 扫描 stdio 服务器：mcp-scanner stdio --stdio-command <命令> --stdio-arg <参数> --analyzers yara
• 扫描提示/资源/指令：使用 prompts、resources、instructions 子命令。
• VirusTotal 扫描：mcp-scanner virustotal <文件或目录路径>
• 行为代码扫描：mcp-scanner behavioral <源代码路径或目录>
• 漏洞包扫描：mcp-scanner vulnerable-package <requirements 文件或项目目录>
• 静态文件扫描：mcp-scanner static --tools <JSON 文件路径>
• 作为 REST API 服务器：mcp-scanner-api --host 0.0.0.0 --port 8080

Python SDK 使用： 通过导入 mcpscanner 模块，创建 Config 和 Scanner 实例，即可编程式地扫描远程、stdio 服务器或本地文件。

子命令概览

工具提供了多个专用子命令：remote、stdio、config、known-configs、prompts、resources、instructions、virustotal、supplychain（行为代码扫描）、vulnerable-package、static。

输出与文档

扫描结果支持多种格式输出。项目文档详细介绍了架构、各类扫描原理、LLM 提供商配置、威胁分类、认证和 API 参考等。

项目链接：https://github.com/cisco-ai-defense/mcp-scanner 许可证：Apache 2.0

Waymo致力于打造全天候自动驾驶系统，其“Waymo Driver”目前已能应对雨、雾、沙尘暴及低温等天气。为向更多城市（尤其是多雪地区）扩展，该公司采用系统化、科学的方法来推进冬季恶劣天气下的自动驾驶能力，其核心路径包括以下四个步骤：

1. 理解挑战 雪天并非单一现象，而是一系列复杂条件的集合：从轻微飘雪到能见度极低的暴风雪，路面可能积雪或结冰，加上路边积雪等环境因素，均会影响驾驶。Waymo已在纽约州北部、密歇根半岛及内华达山脉等多雪地区进行数万英里的实际驾驶训练，让人工智能系统从真实经验中学习，以应对多样化的冬季路况。

2. 设计通用化解决方案 Waymo构建了一套适用于多种天气条件的统一自动驾驶系统。其第六代系统基于超过1亿英里的全自动驾驶经验，结合先进硬件与人工智能，能够在不同气候城市中实现全自动驾驶运行。该系统使用摄像头、雷达和激光雷达进行多传感器感知，并配备自动清洁系统（通过加热等工程手段保持传感器清洁）。人工智能能够区分雪、雪泥、冰与正常路面，并据此实时调整车速、加速度和刹车策略，同时从其他道路使用者的行为中推断路况变化（如道路封闭、绕行等）。每辆车相当于一个移动气象站，既能自主决策，也能将数据共享至车队。

3. 严格验证能力 Waymo通过现实道路驾驶、封闭场地测试和大规模模拟三种方式进行验证。在底特律、丹佛、华盛顿特区等多雪城市的实际运营加深了对冬季天气的理解；封闭测试中模拟极端场景（如冰面打滑）以突破系统极限；全年不间断的模拟则用于应对罕见事件（如百年一遇的降雪）。

4. 负责任地扩展规模 在通过安全框架和高标准乘客体验验证后，Waymo会根据当地条件明确运营范围。随着规模扩大，公司持续优化冬季运维措施，包括保持车队清洁与低温下的充电效率，提升乘客体验。尽管冬季天气复杂，Waymo致力于在用户最需要时提供可靠服务，并以安全为核心原则向全球更多城市扩展。