Gemini 1.5：下一代模型介绍

谷歌发布了其下一代人工智能模型Gemini 1.5，该模型在性能上实现了显著提升，并在多模态长上下文理解方面取得突破。

核心创新：混合专家架构

Gemini 1.5采用了高效的混合专家架构。与传统单一神经网络不同，MoE模型将网络划分为多个较小的“专家”子网络。根据输入内容，模型会智能地仅激活最相关的专家路径，从而大幅提升训练和推理效率，使模型能更快学习复杂任务并保持高质量。

突破性进展：超长上下文窗口

1.5 Pro模型具备革命性的长上下文处理能力。标准版本拥有128,000 token的上下文窗口，而实验性功能更可支持长达100万token的输入，创下大型基础模型的新纪录。这意味着模型能一次性处理：

• 1小时视频
• 11小时音频
• 超过30,000行代码
• 超过70万字文本

谷歌在研究中甚至成功测试了高达1000万token的上下文。

增强的能力与性能

1.5 Pro模型在文本、代码、图像、音频和视频的综合评估中表现优异：

• 在87%的基准测试中超越前代1.0 Pro版本。
• 与目前最大的1.0 Ultra模型性能相当。
• 在“大海捞针”测试中，能在长达100万token的文本中以99%的准确率找到嵌入信息。
• 展现出强大的上下文学习能力，例如仅通过提供的语法手册就能学习一门濒危语言并实现翻译。

具体应用示例包括：

• 复杂信息推理：分析阿波罗11号402页任务记录，理解对话和事件。
• 跨模态理解：解读44分钟的无声电影情节与细节。
• 长代码分析：处理超过10万行代码，理解各部分功能并提出修改建议。

可用性与测试

1.5 Pro模型现已通过AI Studio和Vertex AI向开发者和企业客户提供有限预览。标准128,000 token上下文窗口版本将在模型更广泛可用时推出。测试期间，早期用户可免费试用100万token上下文功能（尽管延迟可能较长），未来将推出分级定价。

伦理与安全

谷歌强调，该模型遵循其人工智能原则和安全政策，经过了广泛的伦理与安全测试，包括内容安全和潜在危害评估，并针对长上下文特性开发了新的测试方法。

Gemini 1.5的发布标志着谷歌在推动人工智能更实用、更高效方向上的又一重要步伐，旨在为全球数十亿用户、开发者和企业带来新的可能性。

事件概述
Nginx 核心开发者 Maxim Dounin 宣布，由于 F5（Nginx 所有者）管理层干预 Nginx 长期安全策略并忽视开发者及社区意见，他将不再参与 F5 主导的 Nginx 开发，并启动新项目 Freenginx。

关键背景

• 2022 年 F5 关闭莫斯科办公室后，Dounin 以志愿者身份继续参与 Nginx 开发。
• 近期 F5 新管理层单方面干预 Nginx 安全政策，违背原有协议及开源精神，Dounin 认为这导致 Nginx 不再是“为公共利益维护的免费开源项目”。

行动与目标

• Dounin 即日起退出 F5 的 Nginx 开发，成立 Freenginx（网址：http://freenginx.org/）。
• 该项目旨在由开发者主导，避免企业任意决策影响开源开发，欢迎社区贡献参与。

Observable 2.0：面向数据应用的静态站点生成器

Observable 正式推出 Observable 2.0，其核心是一个开源的静态站点生成器 Observable Framework，旨在帮助团队构建快速、美观的数据应用、仪表板和报告，以更有效地用数据进行沟通。

核心定位与优势

Framework 定位于弥补传统 Notebook 在数据展示方面的不足。Notebook 适用于临时性的数据探索，但在构建精致的仪表板和应用时存在局限（如单栏布局、信息密度低、编辑界面始终可见）。Framework 旨在提供更好的用户体验，将 JavaScript（用于前端交互式图表）与任意后端语言（如 SQL、Python、 R 等用于数据准备）相结合。

主要特点

1. 开发者友好：项目基于本地文件，支持使用熟悉的编辑器、版本控制、单元测试和 CI/CD，甚至可以离线工作。
2. 卓越的用户体验：提供响应式网格、主题、深色模式、键盘导航等开箱即用的功能，且高度可定制。
3. 解决“最后一公里”数据加载问题：传统仪表板在用户查看时实时查询，速度慢。Framework 的 数据加载器 在构建时预先生成静态数据快照，使页面加载瞬间完成，同时保证了数据隐私和安全。
4. 开源与灵活性：Framework 免费开源，项目可部署到任何地方或托管在 Observable 平台。

设计目标

1. 更好的开发工作流：采用基于文件的范式，便于集成现有开发工具链。使用原生 JavaScript 语法和 ES import，提升互操作性和易学性。
2. 更好的用户体验：工具本身通过合理的默认设置（如美观的 Markdown 页面、预构建主题）引导开发者构建高性能、高质量的数据应用。
3. 更好的数据架构：允许开发者使用任何语言和库进行数据准备，并在构建时生成优化后的静态数据快照。这种架构分离了数据处理与前端展示，既实现了即时加载，又增强了安全性。

总结

Observable Framework 代表了数据应用开发的一种新范式，它通过静态生成和预处理数据，显著提升了应用性能和用户体验，同时为开发者提供了现代化的、灵活的工作流程。Observable 2.0 希望通过 Framework 为数据分析与展示提供一个端到端的解决方案。

Asahi Linux 项目在 Apple Silicon 上的 OpenGL 支持正式超越苹果

核心事件
Asahi Linux 项目宣布其在 Apple Silicon 芯片上提供的 OpenGL 支持已超越苹果官方，打破了苹果自 2013 年 macOS 10.9 以来将 OpenGL 长期停滞在 4.1 版本的局面。

背景与现状

• 苹果的策略：自 2013 年起，苹果便未更新其 OpenGL 实现（版本 4.1）。2018 年，苹果正式将 OpenGL 标记为“已弃用”，并将开发重心转向自有的低开销图形 API——Metal。尽管在从 Intel 处理器向自研芯片过渡期间，苹果仍维持旧版 OpenGL 的兼容性，但未做任何升级。
• Asahi Linux 的突破：该项目为 Apple Silicon 设备开发的 Linux 驱动，成功实现了高于苹果版本的 OpenGL 支持，成为 Linux 生态在 Apple 硬件上的重要进展。

技术影响与后续计划

• 提升应用兼容性：更先进的 OpenGL 版本支持，将改善原生 Linux 应用的性能与兼容性。同时，这也为 Valve 的 Proton 等兼容层（用于在 ARM 设备上运行 x86 Windows 游戏）创造了更好条件。
• Vulkan 进展：项目团队表示 Vulkan 支持也已“走在正轨上”，这将进一步丰富图形 API 选择，提升游戏和高性能应用体验。

系统支持与局限

• 当前功能：Fedora Asahi Remix 已能较好支持 M1/M2 Mac 的多项硬件，包括摄像头、扬声器、Wi-Fi、蓝牙及图形加速。
• 尚未支持的功能：Thunderbolt、USB-C 视频输出、内置麦克风及 Touch ID 指纹传感器等功能仍不可用。
• 近期更新：2024 年 1 月的更新增加了 HDMI 输出、DRM 受保护网站播放支持（通过 Widevine）、部分机型的 Touch Bar 支持等。

M3 芯片支持展望

• 开发者表示，对 M3 芯片的基本支持预计需要至少六个月时间，主要工作包括为其 GPU 开发驱动。由于开发主要依赖 Mac mini 机型，而目前尚无 M3 Mac mini，这可能会进一步影响进度。

苹果M1芯片实现符合规范的OpenGL 4.6支持

核心突破

2024年2月14日，开源Linux驱动为苹果M1/M2系列芯片实现了完整的OpenGL 4.6和OpenGL ES 3.2标准支持。此前M1仅支持非符合规范的OpenGL 4.1驱动，这严重限制了现代图形应用的兼容性。新驱动已通过超过10万项一致性测试，被列入官方符合规范驱动列表。

技术意义

• 摆脱厂商锁定：开源驱动遵循开放标准，使Blender等应用无需特殊移植即可在M1上运行
• 版本跨越：从OpenGL 4.1升级到4.6新增数十项必要特性，包括鲁棒性、SPIR-V支持、计算着色器等
• 生态推进：继2023年成为首个符合M1规范的图形API驱动（OpenGL ES 3.1）后，正向Vulkan支持迈进

硬件挑战与解决方案

核心矛盾

M1硬件对OpenGL 4.6所需特性支持有限，但新版本特性是实现DirectX/OpenGL层叠渲染的必要条件。

关键技术突破

1. 特性替代策略：

   • 几何着色器、曲面细分、变换反馈 → 计算着色器实现
   • 剔除距离 → 转换插值值实现
   • 裁剪控制 → 顶点着色器结语程序实现

2. 鲁棒性实现细节：

   • 缓冲区鲁棒性：通过umin指令将越界访问安全限制在缓冲区内，返回零或有效数据
   • 统一缓冲区优化：利用“前导码”技术将鲁棒性计算移至着色器前导执行，消除运行时开销
   • 顶点缓冲区创新：将单一缓冲区多属性模型转换为多缓冲区单属性模型，使每个属性可独立计算有效顶点范围
   • 边界情况处理：过小缓冲区替换为零缓冲区，确保完全安全

3. 图像鲁棒性难题：

   • 硬件在级别越界时返回非零值而非标准要求的零值
   • 采用标量比较选择技术：通过设置无效坐标强制硬件返回零值
   • 优化方案：ulesel指令+预加载常量，仅需单条指令完成验证

测试验证

通过强制实现符合规范的缓冲区和图像鲁棒性行为，驱动在要求严格的浏览器等应用场景中提供更好的安全防护，同时兼容依赖鲁棒性的现代游戏。

展望

该驱动为M1系列芯片带来了完整的现代OpenGL支持，消除了应用移植障碍，下一步将继续推进Vulkan支持的开发工作。

YC: 创业需求 2026年夏季

YC传统“创业需求”（RFS）分享他们希望看到创始人去解决的创意。这些只是他们资助方向的一部分，并不代表申请YC必须遵循这些方向。

核心主题

YC认为，AI已不再是功能，而是基础。他们看好新一代创业公司重建软件、服务与芯片，并将AI推入物理世界。以下为具体方向：

1. 现代农业革新

问题：农业过度依赖化学农药，导致残留、抗药性、成本上升和恶性循环。 机遇：AI视觉、廉价传感器、精准机器人和生物技术（微生物、RNA）的成熟，使“精准农业”和“生物防治”成为可能。目标是大幅减少化学品使用，同时提高产量。

2. AI原生发现引擎

愿景：从“AI研究助手”升级为能自主运行“假设-实验-分析”闭环的智能系统，加速科学发现（如药物研发、材料科学）。

3. AI原生服务公司

趋势：AI能力从“辅助工具”发展到“直接提供服务”。总服务市场远大于软件市场。目标是取代（而非优化）现有外包服务，如保险经纪、会计、合规等。

4. 智能个性化医疗

机遇：个性化诊断成本（如基因测序）急剧下降，AI代理能分析个人健康数据，结合个性化疗法（如mRNA），推动医疗民主化。

5. 企业“大脑”

需求：构建能整合企业零散知识（邮件、会议、数据库）的结构化、可执行的“公司大脑”，为AI代理提供可靠操作基础，实现安全自动化。

6. 反无人机蜂群防御

挑战：现有防御体系无法应对廉价、自主的无人机蜂群攻击。 方向：开发软硬件一体化的“反蜂群堆栈”，如高容量拦截器、传感器融合软件、非动能防御（如气溶胶、缠绕物）及攻击自主性的新方法。

7. 软件高度个性化

未来：利用先进的代码生成能力，让用户能深度自定义软件界面和功能，而非使用千篇一律的界面。这需要重构软件交付栈。

8. 太空计算与推理芯片

机遇：可重复使用火箭将大幅增加太空运力，需要针对太空环境优化的（质量、散热、抗辐射）推理芯片。

9. 硬件快速迭代

差距：美国硬件迭代速度远慢于中国（如深圳）。需要构建能极大缩短“设计-制造”循环的初创公司，特别是在快速生产和集成设计、制造、物流方面。

10. 太空工业化

愿景：在月球和太空发展工业能力，特别是通过电解和3D打印从月球风化层中提取原材料和制造复杂结构。

11. 为AI代理设计的推理芯片

问题：当前AI芯片设计针对“提示-响应”模式，而AI代理工作负载是循环的、突发性的。 机会：设计专为代理工作流程优化的芯片，关注快速上下文切换、推测解码和持久化KV缓存。

12. AI原生挑战传统SaaS

逻辑：AI大幅降低软件构建成本，使初创公司有望以AI原生方式，挑战甚至取代看似坚不可摧的传统SaaS巨头（如ERP、芯片设计软件）。

13. 为AI代理构建软件

机会：AI代理将成为互联网的下一个主要用户。需要为代理构建全新的基础设施，即机器可读接口（API、MCP）、完善的文档和代理优先的软件，而非在人类界面基础上修补。

14. 向大型企业销售

转变：AI使小型团队能快速构建精密产品，满足大型企业需求。F100级公司的高管正积极寻找AI解决方案，初创公司现在能更快获得大客户并达成交易。

15. 半导体供应链2.0

痛点：先进芯片供应链复杂、不透明且脆弱，依赖过时工具管理。 需求：构建能提供实时分配跟踪、多级风险监控、出口合规等的现代化供应链管理平台，需深度行业知识。

16. 公司AI操作系统

愿景：构建能将公司所有运营数据（会议、票据、客户互动）转化为可查询、可学习的“统一智能层”的系统，使公司形成自我优化的闭环，而非开环。

Gitlab Meeting Simulator 2024 是一个模拟GitLab会议的工具，旨在帮助用户在特定情境下维持工作假象或避免干扰。

• 项目概述：该项目通过模拟GitLab会议场景，为用户提供一个背景音效或虚拟环境，常用于家庭或远程工作设置中。
• 用户反馈：来自YouTube的推荐语显示，该工具被广泛用于：
  • 需要独处时，播放会议模拟让家人离开。
  • 隐瞒失业状态，假装在家工作，每天早上播放以避免父母打扰。
  • 部分用户甚至不了解GitLab，但仍反复使用该工具。
• 核心功能：通过生成会议音效或视觉模拟，帮助用户营造工作氛围，解决家庭干扰或维持职业形象。
• 用户场景：主要适用于远程工作者、自由职业者或需要临时工作掩饰的个人，提供一种简单有效的方式来管理外界期望。

Reor：本地运行AI模型的笔记应用

核心定位：Reor 是一款注重隐私的本地AI个人知识管理桌面应用，通过本地运行AI模型自动组织笔记内容。

主要功能：

• 智能链接：自动分析笔记内容，通过向量相似性建立笔记间的关联
• 语义搜索：支持基于语义的笔记搜索
• AI问答：基于检索增强生成（RAG）技术，从笔记库中获取上下文回答用户问题
• 本地运行：所有数据存储在本地，AI模型完全在设备端运行

技术架构：

• 基于 Ollama、Transformers.js 和 LanceDB 技术栈
• 笔记内容被分块并嵌入到本地向量数据库中
• 支持运行本地大语言模型和嵌入模型

使用模式：

1. 编辑模式：类似Obsidian的Markdown编辑器，侧边栏可显示相关笔记
2. 问答模式：LLM基于检索的笔记上下文回答问题

产品理念：

• 认为AI思维工具应默认本地运行
• 通过"人类+LLM"双生成器模式增强思考能力
• 交叉引用当前笔记与历史笔记库中的相关想法

安装与使用：

• 支持 Mac、Linux 和 Windows 系统
• 从官网或GitHub发布页下载安装
• 首次启动时选择笔记目录，手动导入Markdown文件
• 通过设置界面可下载和管理本地AI模型
• 也支持连接OpenAI兼容API

开发信息：

• 开源项目，采用 AGPL-3.0 许可证
• 欢迎社区贡献，提供问题跟踪和贡献指南
• 项目名称"Reor"在拉丁语中意为"思考"

OpenAI申请美国商标“GPT”未通过。美国专利商标局（USPTO）拒绝了“GPT”作为商标的注册申请，原因是“GPT”被认为是通用描述符，即“生成式预训练变换器”（Generative Pre-trained Transformer）的缩写，属于行业普遍术语，不能作为某一公司独占的商标。OpenAI原计划通过商标保护“GPT”技术，以限制他人用该名称，但因公众及业内人士广泛使用该词，导致该申请被驳回。这一结果意味着其他企业和开发者在美国仍可自由使用“GPT”作为产品名称或描述，未受商标限制。

质子内部的结构远比传统认知复杂，其表现形式因探测方式不同而改变。高中物理常将质子描述为带正电的简单球体，大学阶段则引入由三个夸克（两个上夸克和一个下夸克）构成的模型。然而，数十年的实验研究揭示，质子是一个量子力学实体，其内部蕴含着意想不到的复杂性。

1967年，斯坦福直线加速器中心（SLAC）的深度非弹性散射实验首次证明了夸克的存在：电子被强力轰击质子后，从质子内部的点状碎片（夸克）上反弹。这一发现开启了通过调整电子能量和分析散射粒子来探究质子内部结构的系列实验。更高的能量可带来更高的分辨率，揭示更精细的结构。

然而，简单的三夸克模型存在严重缺陷。实验发现，夸克的自旋总和远小于质子的自旋，且三个夸克的质量仅占质子总质量的约1%。这表明质子远不止三个夸克。

1992年至2007年运行的强子-电子环形加速器（HERA）将电子对质子的撞击能量提升了约千倍。HERA实验发现，质子内部不仅有夸克，还充满了低动量的瞬态夸克-反夸克对以及传递强相互作用的胶子，它们构成了一个“海”。这些结果验证了量子色动力学（QCD）理论，该理论描述了夸克通过胶子相互作用，并带有“色荷”。QCD能很好描述这种高能量碰撞下短暂存在的夸克和胶子云，但对于SLAC实验中那种能量较低、三个夸克保持一定距离的稳定状态，其计算却极为困难。

最新研究带来了更多意外。2022年8月发表的一项大规模数据分析（利用机器学习处理过去50年的超过5000个质子数据）发现，在相对较软的碰撞中，质子偶尔会显现出由粲夸克和反粲夸克组成的成分——每个粲夸克的质量都超过质子自身质量的三分之一。这意味着质子内部不仅存在瞬时的“海夸克”，还可能以量子叠加态的形式，更持久地包含这类重夸克。例如，质子有时可能呈现为一个五夸克态（如上、下、粲夸克与一个上夸克、反粲夸克组成的分子状结构）。

这一发现具有重要影响。在大型强子对撞机中，理解质子的初始成分对于解释碰撞结果至关重要，重夸克的出现会影响稀有粒子产生的概率。此外，当宇宙线质子与大气层中的质子碰撞时，粲夸克的出现可能导致产生额外的高能中微子，干扰对宇宙起源中微子的观测。

未来，下一代实验如计划于2030年代运行的电子-离子对撞机（EIC）将进一步探索质子。EIC旨在提供更高分辨率的质子“快照”，实现三维重建，并绘制内部夸克和胶子的自旋分布图，最终解答质子自旋起源等基本问题。

这是一个Aldi商品价格信息页面，主要展示了2023年11月20日至11月26日期间的特定商品价格地图。

该页面属于aldipricemap.com网站，它声明并非Aldi官方网站。所有价格信息仅供参考，实际店内价格可能随时变动且与网站信息不同。

该价格地图展示的当周商品主要包括：

• 节日相关食品：如6英寸一品红盆栽、火鸡胸肉、肉馅饼、冷冻甜点等。
• 生鲜产品：球芽甘蓝、芹菜、红薯、土豆、菠萝、脐橙等。
• 即食与加工食品：速食土豆泥、蘑菇汤、奶酪酱、英式切达干酪、意式肉干、冷冻蔬菜等。
• 酒类饮料：香槟、冰酒、桃红葡萄酒、梨味硬苏打水等。

页面最后提醒用户，网站将更新至11月27日当周的新产品和价格，并提供了查看最新价格地图的链接。

本文的核心观点是：在软件技术咨询中，客户表面上寻求解决的复杂技术难题，其根本原因往往是组织内部的“人的问题”，而非纯粹的技术挑战。

作者是一名专注于软件架构、协议开发等领域的技术顾问。他揭示了行业的一个秘密：当公司寻求高层技术咨询时，通常意味着已存在严重问题。然而，专业团队本应能解决明确的技术难题，因此，许多看似技术的问题，实则源于团队沟通、领导力或组织文化等“人的问题”。

作者发现这类问题的“秘密技巧”是：与团队中最资深的工程师进行一次90分钟的谈话，并提出一个问题：“这个地方哪里出问题了？” 详细记录其反馈。随后，将整理后的内容转述给公司管理层，这常被视为深刻的见解。

作者强调，分享此技巧并非批评特定客户，而是希望潜在客户在聘请专家前先自我诊断。他建议领导者应直接与一线工程师沟通，积极倾听他们的真实反馈和担忧。这不仅能获取宝贵信息，更能通过实际行动提升团队士气和信任，这是外部顾问无法替代的。

最终，作者指出，在厘清并解决组织层面的“人的问题”后，若确实存在复杂的分布式系统等纯技术需求，他便能提供高效的专业服务。文章的核心启示在于：技术问题的解决，始于对“人”与组织文化的关注与改善。

如何在不同设备间复制文件？

文章探讨了在个人设备间（如手机与电脑）复制文件时遇到的痛点，并寻求最简单、无需依赖现有在线服务、跨平台且不留中间存储垃圾的解决方案。

核心规则与挑战

作者提出了四项主要规则：

1. 无需现有服务账户：禁止使用 Dropbox、Google Drive、邮件草稿等。
2. 对非技术用户友好。
3. 跨平台流程一致。
4. 不留中间垃圾：文件传输不应在服务器等中间环节留下永久或临时的存储痕迹。

通过对比分析现有工具（如云盘、邮件附件、蓝牙、USB线、AirDrop等），作者发现大多数流行方案无法同时满足所有规则，尤其在“不留中间垃圾”方面普遍不合格。虽然 USB 线、蓝牙和某些技术工具（如 scp）能满足部分规则，但易用性或跨平台一致性存在缺陷。

作者的解决方案

作者选择了基于 WebSocket 的自建方案：

1. 思路：利用浏览器的 WebSocket API，在局域网内搭建一个简单的 WebSocket 服务器，实现设备间直接传输文件数据。
2. 技术实现：
   • 使用 Go 语言（Gin 和 Melody 框架）搭建了一个基础的 WebSocket 服务器，用于在客户端之间广播消息。
   • 在客户端使用 JavaScript，通过 FileReader 和 slice 方法将大文件分块读入内存，并转换为可传输的格式（如 Uint8Array）。
   • 通过 WebSocket 将文件分块从一台设备发送到另一台设备，并在接收端按顺序重新组装成完整文件。
3. 评估：该方案满足规则1（无现有服务账户）和规则4（不留中间垃圾），但在规则2（易用性）和规则3（一致性）上表现不佳。主要问题是需要用户自行搭建和维护 WebSocket 服务器，这对非技术用户来说门槛过高。

结论

文章总结指出，在设备间复制文件依然繁琐，现有工具要么流程不一致，要么会留下存储垃圾。浏览器及其提供的文件API为构建跨平台方案提供了可能，WebSocket 是一个可行的技术方向。然而，对于普通用户而言，使用 USB 存储设备或数据线可能仍然是更直接、更省时的选择。作者最终提出的方案主要解决了其个人需求，但尚未成为普适的、用户友好的终极解决方案。

逆向工程加密物联网协议：GoodWe 智能电表与太阳能逆变器

背景与初始问题

作者于2023年安装了家用太阳能光伏系统，设备为GoodWe DNS G3逆变器和HomeKit 1000智能电表。安装后发现，查看发电数据必须将设备连接到GoodWe云端（SEMS门户），并通过其应用或网页界面获取，缺乏本地监控功能。作者希望本地抓取数据并理解云端通信内容。

逆向工程过程

1. 初步探测

• 网络扫描：使用nmap发现设备开放Telnet端口（23），默认凭证为admin/admin，进入后接口有限。
• 流量捕获：设备定期向tcp.goodwe-power.com:20001发送数据包，但数据主体为高熵加密块。逆变器型号可通过Modbus协议读取数据，但智能电表不支持。
• 固件提取：通过Telnet命令导出固件，分析发现为eCos RTOS系统（MIPS架构），并检测到AES加密相关库函数。

2. 协议分析

• 帧结构：协议帧以POSTGW开头，包含长度字段、设备信息、时间戳和加密数据块，末尾为Modbus CRC-16校验码。
• 加密缺陷：在网络中断后恢复时，相同时间戳（作为IV）连续发送的帧中，前几个加密块完全相同，表明可能使用AES-CBC模式且IV重复。
• 密钥破解：假设密钥硬编码于固件中，编写工具遍历固件作为密钥候选，以时间戳为IV解密并计算熵值。最终发现密钥为全1字节（0xFF），成功解密数据。

3. 数据映射与实现

• 对照SEMS门户API返回的实时数据，逆向映射解密后的数据字段（如电流、电压、功率等）。
• 构建Prometheus导出器：通过中间人攻击截获设备数据包，解析指标后转发至GoodWe云端，同时支持本地监控并拦截未知数据包（如固件更新）。

安全发现与建议

安全问题

• 设备默认凭证为admin/admin，且开放未加密的Telnet调试接口。
• 设备AP模式（Solar-WiFi）默认密码为admin，存在未认证的配置端口（UDP协议）。
• 加密方案仅保护指标数据，设备型号和序列号以明文传输。
• 厂商具备远程管理能力，包括固件更新。

安全建议

• 将设备置于隔离的IoT VLAN中，避免直接暴露于公网。
• 更改Telnet、Web界面及Wi-Fi AP的默认密码。
• 使用作者开发的Prometheus导出器，可在保留云端功能的同时本地监控，并自动丢弃未知数据包（理论上可阻止远程管理）。

结论

作者成功逆向了GoodWe设备的加密通信协议，并构建了本地监控工具。研究过程揭示了物联网设备中常见的安全疏忽，如硬编码凭证、弱加密实现和调试接口暴露。尽管协议使用AES加密，但实现缺陷（IV重复）导致安全性不足。此工作展示了在设备厂商未提供本地API时，通过逆向工程实现自主监控的可能性。

IP分片：你以为你理解但其实并不完全理解的技术

核心概念

IP分片是将一个IP数据包分割成更小片段以便通过网络路径传输的技术。每个网络链路都有一个最大传输单元（MTU），路径MTU（PMTU）是源到目的地路径上所有MTU的最小值。当数据包大于PMTU时，就会发生分片。

为什么IP分片重要

分片对性能有多重负面影响：

• 开销增加：每个分片都需要独立的IP头，增加了协议开销
• 延迟增大：接收端必须等待所有分片到达才能重组
• 资源消耗：CPU、内存和网络带宽消耗增加
• 可靠性下降：分片更容易被丢弃，因为路由器和防火墙可能将其视为安全风险

理解IP分片的挑战

文章作者在实现VPN时发现，即使是网络专家也常常无法准确预测IP分片的行为。影响分片的因素包括：

• 本地接口MTU
• IP版本（IPv4/IPv6）
• IP头选项
• 传输协议（TCP/UDP等）
• 套接字选项
• 系统级PMTUD设置
• PMTU缓存条目

fragquiz：测试IP分片理解的工具

作者开发了fragquiz游戏来帮助人们学习IP分片：

• 工作原理：发送超过本地MTU的数据包，同时改变IP版本、传输协议和分片选项
• 实现技术：使用traceroute风格的TTL技术，通过ICMP Time Exceeded消息获取分片信息
• 挑战：某些路由器会重组分片后再发送ICMP消息；Linux版本需要root权限；PMTU缓存会影响测试结果
• 测试结果：在网络专家会议RIPE 87上，参与者集体得分仅约80%，表明IP分片确实难以理解

新的PMTU发现算法

作者与同事开发了一种创新的路径MTU发现算法：

• 核心思路：同时发送所有可能的常见数据包大小（如1280、1400、1500、8000、9000字节）
• 工作机制：接收端对每个收到的数据包发送确认，发送端将PMTU设置为最大确认的数据包大小
• 定期重探：每10分钟重新探测更大的MTU，如果路径MTU增加则重新探测所有更大的尺寸
• 优势：只需一个RTT延迟，实现简单（一个计时器、一个静态表、一个变量）
• 权衡：可能比传统算法使用更多带宽

关键见解

1. IP分片的实际行为比理论描述更复杂
2. 操作系统设置和网络环境显著影响分片行为
3. 现有的PMTU发现方法存在局限性
4. 通过实际测试（如fragquiz）可以更好地理解IP分片的实际行为

文章最后提出了一个挑战：在相同配置下运行fragquiz命令，观察结果是否一致，这进一步展示了IP分片行为的复杂性。

日本极道粉丝杂志的世界 (2009)

文章探讨了日本极道（黑帮）粉丝杂志的独特文化现象。这些杂志存在数十年，充当了极道世界的“行业刊物”，内容涉及凶狠专横、擅长刀剑枪械、拥有全身刺青、从事非法交易和洗钱的帮派成员。它们易得程度令人惊讶，在报摊、便利店、书店、公共图书馆甚至某些政府办公室都有售。

在日本，极道组织被视合法实体，以致力于“保护传统价值”的兄弟会组织名义运作，类似于美国的扶轮社或童子军。据警察厅统计，有22个公认的极道组织，共宣称拥有8.6万名成员。其中最大的是山口组，宣称有5万名成员及关联者。

许多日本人，包括一些警察，对这些刺青帮派分子怀有敬畏和钦佩。他们被视为可爱的法外之徒，一种“必要之恶”，用以阻止“邪恶外国罪犯”危害街道安全。在许多中年上班族眼中，极道成员过着理想生活——拥有过多的金钱、美酒、刺激和美女，因此这些杂志成为他们逃避现实、幻想更美好生活的方式。

最著名的极道粉丝杂志包括《实话时代》、《实话时报》、《实话文档》和《朝日艺能》。它们通常与某个特定的犯罪集团关系密切。住吉会（1.2万名成员）、稻川会（1万名成员）等组织的头目经常接受杂志的长篇采访。采访内容很少涉及犯罪活动，而是谈论过往荣耀、帮派战争和日本传统价值观，但偶尔也会提及集团当前的非法活动。

唯一不与杂志完全合作的是最大的山口组。自2005年新头目筱田建市上任后，山口组采取了不接受采访的政策。尽管如此，《实话文档》杂志仍大量报道山口组。杂志内容混杂，从吹捧到低俗：包括极道组织的联盟扩张、内部成员被开除、成员参拜神社和捣年糕的照片、“刺青角落”、关于女性生理的低俗文章、顶级风俗店的评测、记者亲身经历的报道，以及宣扬只有极道能阻止“野蛮人”的“外国人犯罪”专栏（迎合日本排外情绪，警察厅每年发布的外国人犯罪统计助长了这一神话）。此外，还有描绘极道头目生平的漫画系列，以及关于虚构极道成员在帮派战争中血腥冒险和滥交的连载漫画。

尽管极道粉丝杂志经久不衰，但公众对极道的批评日益增多，迫使山口组等组织进一步淡出公众视野。这使得杂志在新闻采集中不得不更具侵略性，并更现实地描写极道的本质。近期杂志已开始包含极道成员实际犯罪活动的详细报道，这自然与极道本身的利益相冲突。

此外，杂志面临着来自“漫画杂志书”的竞争，这类刊物结合了更多文本和漫画，并有描绘古今著名极道兴衰的漫画小说。尽管竞争加剧且全球经济不景气冲击杂志广告业，这些老牌杂志仍然屹立不倒。在很长一段时间内，它们不太可能消失或呼吁打击有组织犯罪，因为那样做无异于自断生路。

（作者杰克·阿德尔斯坦是《东京副都心》一书作者，曾为《读卖新闻》工作12年，是日本有组织犯罪的专家。）

该研究通过对《赫芬顿邮报》网站2013年至2015年间约4500万条新闻评论的分析，探讨了不同身份规则对在线讨论文明程度的影响。网站在此期间经历了三种评论身份制度的变迁：从轻易匿名阶段，过渡到稳定化名阶段（用户需认证身份但无需公开真实姓名），最终转向实名制阶段（评论与Facebook个人资料关联）。

研究发现：

• 在轻易匿名阶段，用户可随意创建多个账户，导致评论区被滥用、攻击性言论泛滥，环境恶劣。
• 引入稳定化名后，评论的文明程度和认知复杂度（如使用因果词汇、谨慎结论等指标）显著提升。研究将此归因于“破窗效应”：环境改善促使用户行为更友善，同时用户在固定化名下更关注自身在该社区的声誉。
• 然而，当转向实名制后，评论质量并未进一步提高，反而有所下降。研究推测，实名制可能改变评论动态，用户需考虑评论对更广泛社交圈（如Facebook好友）的影响，从而削弱了基于特定社区身份的责任感。

该研究挑战了“实名制必然促进文明讨论”的常见假设，指出稳定化名可能比完全匿名或实名更有利于构建建设性的在线讨论环境。其核心在于身份与特定论坛的关联性及用户对虚拟身份的责任感，而非单纯的匿名与否。

Waymo召回自动驾驶软件：两车先后撞击同一辆拖车

Waymo（谷歌母公司Alphabet旗下自动驾驶部门）于近期自愿召回其自动驾驶汽车软件。召回起因于在亚利桑那州凤凰城，两辆Waymo自动驾驶汽车在数分钟内先后撞上同一辆正在牵引皮卡车的拖车。

事故细节与原因

• 事故发生在拖车牵引皮卡时，皮卡并非正直拖行，而是以一定角度向后拖曳，且其前部部分侵入相邻转弯车道。
• Waymo在博客中说明，两辆涉事车辆的摄像头均错误识别了这一场景，并因此错误预测了牵引车辆的动态，最终导致碰撞。
• 事故发生时，两辆Waymo车内均无乘客（该公司在凤凰城运营无人驾驶叫车服务）。

公司的应对措施

• 事故发生后，Waymo立即通知了当地警方、州安全机构以及美国国家公路交通安全管理局（NHTSA）。
• 在调查原因后，Waymo修改了车辆软件，并于2023年12月下旬至2024年1月初期间，在其整个车队（捷豹I-Pace车型）中安装了更新版软件。
• 经与NHTSA讨论，Waymo决定提交召回报告。由于Waymo不向个人或公司销售车辆，此次软件更新仅针对其自身车队。

行业背景与关联事件

• Waymo在博客中强调，此次自愿召回体现了公司对安全部署技术及保持透明沟通的高度重视。
• 文章指出，自动驾驶汽车虽被业界认为可能比人类驾驶更安全，但仍常面临所谓的“边缘案例”（不寻常的驾驶场景）。这些案例虽定义上少见，但由于自动驾驶车辆行驶里程庞大，实际发生频率不容忽视。
• 此次事件让人联想到2023年通用汽车旗下自动驾驶子公司Cruise在旧金山发生的一起事故。当时Cruise车辆撞击了一名已被其他车辆撞倒的行人，并在碰撞后拖行了伤者。调查发现Cruise在信息披露上存在不足。该事故导致Cruise失去在加州的测试许可，并在全国范围内暂停测试，公司随后也对其软件进行了召回。截至报道时，Cruise的车辆运营尚未恢复。

本文探讨了在Elixir项目中，如何利用Rust语言及其Rustler库来安全、高效地管理可变数据，以弥补Elixir固有的不可变数据模型在某些特定场景下的不足。

核心问题与解决方案 Elixir基于不可变数据，这带来了稳健性和可扩展性，但有时不适用于需要可变状态的特定任务。将这部分剥离成微服务会增加架构复杂性。作者提出使用 Rustler 库，它允许用Rust编写Erlang NIF，从而在同一个BEAM虚拟机内创建一个受控的“可变数据区”，同时保持与Elixir代码的无缝交互。

Rustler的优势 与传统的C语言NIF相比，Rustler提供了：

1. 安全性：Rust的安全性保证可防止NIF崩溃导致整个VM失效。
2. 开发体验：提供了更好的接口和工具，使复杂的集成更可行。
3. 生态访问：可以利用Rust庞大的库生态系统。

具体目标与实现示例 作者的目标是实现一个能在Rust端持久保存数据（即可变状态）的资源，并通过Elixir函数对其进行操作。他们以封装Rust图数据库库Oxigraph为例，创建了一个名为FeGraph的包装器，实现了三个基本操作：

1. new()：创建一个新的内存数据库并返回一个资源句柄（引用）。
2. set(db, data)：向数据库中添加数据，并返回同一个句柄。
3. dump_db(db)：将数据库内容导出为字符串并返回。

关键技术：Resource机制 实现的核心是Rustler的 Resource 机制。它允许在Rust中定义一个结构体（如包含Mutex<Store>的MyGraph），并将其包装在ResourceArc中。这个ResourceArc对象可以像普通Elixir引用一样在BEAM和Rust之间传递，充当Rust端可变内存的句柄。通过rustler::resource!宏将该类型注册为资源后，NIF函数便能安全地操作其内部数据。

结果与意义 示例演示了完整的流程：在Rust端分配内存、操作数据，并通过相同的引用在Elixir端获取结果。这成功展示了如何在不改变Elixir整体数据模型的前提下，为特定功能（如复杂的内存状态管理、高性能计算）开辟一个安全的可变数据空间。

总之，Rustler为Elixir生态系统提供了强大的扩展能力，允许开发者在享受Phoenix等Elixir框架优势的同时，针对特定需求集成Rust的性能和可变数据管理能力，实现更灵活、高效的应用架构。

本文探讨了大型语言模型（LLM）工具库中提示词透明度的重要性，并介绍了如何通过代理工具拦截API调用以查看实际发送的提示词。

背景与动机

许多LLM工具库声称能提升输出质量（如安全性、确定性、结构化等），但其内部运作常对用户不透明。这些工具往往鼓励用户远离直接提示编写，导致用户难以理解其实际发送给LLM的提示内容。作者认为，查看这些提示是理解工具工作原理、评估其必要性和避免意外复杂性的关键。

核心观点：减少意外复杂性

• 采用抽象工具前需警惕引入不必要的复杂性。
• LLM抽象可能迫使用户用代码而非自然语言表达意图，这可能与LLM的初衷相悖。
• 查看提示可帮助判断：是否需要该框架？能否直接使用最终提示？能否写出更好的提示？API调用次数是否合理？

技术方法：使用mitmproxy拦截API调用

作者推荐使用mitmproxy（一款开源HTTPS代理）以框架无关的方式拦截请求：

1. 安装与配置：按官方指南安装mitmproxy，启动mitmweb获取交互界面。
2. 设置系统代理：将系统网络代理设置为localhost:8080。
3. 安装CA证书：访问http://mitm.it安装mitmproxy的CA证书以拦截HTTPS流量。
4. 限定作用域：配置完成后，建议关闭系统全局代理，仅通过Python环境变量定向代理流量，避免干扰。
5. 设置Python环境变量：在代码中设置REQUESTS_CA_BUNDLE、SSL_CERT_FILE和HTTPS_PROXY，使requests等库通过代理发送请求。

示例分析

通过拦截多个流行LLM工具库的API调用，作者展示了其内部提示词和调用模式：

1. Guardrails（用于结构化输出验证）：

   • 发现两次API调用：首次提示包含XML格式的输出要求；第二次用于修正未解析的JSON输出。
   • 洞察：使用XML模式实现结构化输出，过程较复杂。

2. Guidance（提供约束生成与编程式提示）：

   • 一个示例产生了7次API调用，其中5次用于独立生成想法，后续进行综合评估。
   • 洞察：多次独立调用可能导致想法冗余，单次提示可能更高效，体现了意外复杂性。

3. LangChain（SmartLLMChain特性）：

   • 示例中进行了4次API调用：两次生成想法，一次用于批评，一次生成最终答案。
   • 洞察：调用流程可能存在优化空间（如合并步骤），且提示中存在拼写错误，暗示未充分优化。

4. Instructor（结构化输出框架）：

   • 验证示例触发了3次API调用，最终使用函数调用模式进行验证。
   • 洞察：作者质疑是否需要三次调用，并赞赏其基于Pydantic的代码可读性，但仍建议通过拦截验证。

5. DSPy（用于优化提示的框架）：

   • 官方示例运行耗时超过30分钟，产生数百次API调用，用于迭代生成和选择少样本提示。
   • 洞察：高成本与高时间消耗突显了理解其工作原理的重要性；框架术语（如编译器、teleprompter）增加了学习曲线。

个人经验总结

• 作者不反对使用LLM工具库，但强调有意识地使用。
• 关注避免意外复杂性，查看提示有助于做出明智决策。
• 对过度疏远用户与LLM的框架持谨慎态度。
• 主张用户应主动要求了解工具的实际提示词（“Show me the prompt!”），以保持对工具的掌控和理解。

本文倡导通过技术手段（如mitmproxy）实现LLM工具内部运作的透明化，帮助用户评估工具必要性、避免不必要的复杂性，并做出更明智的技术选择。

亚马逊多领域科学职位摘要

总体概述

本文汇集了亚马逊多个团队的高级技术职位描述，核心目标是招聘机器学习科学家、数据科学家和经济学家，以开发大规模的AI驱动系统，优化业务运营、提升客户体验并直接影响关键绩效指标。

主要团队与职责领域

1. 广告测量科学：

   • 团队：隶属亚马逊广告的“测量、广告技术与数据科学”团队。
   • 核心任务：开发端到端的解决方案，测量广告支出对线上及线下销售的综合影响，并提供可操作的洞察。
   • 关键技术：生成式AI、经典机器学习、因果推断、自然语言处理和计算机视觉。
   • 职责：领导测量模型开发，与工程、产品和业务团队协作，将科学方案产品化，并为广告主优化媒体投资组合提供依据。

2. 定价优化与经济学：

   • 团队：包括P2优化科学团队和商店经济与科学团队。
   • 核心任务：
     • P2OS：专注于解决数字需求响应的测量难题，构建可信的因果识别策略以支持定价决策。
     • 商店经济与科学：从经济学视角研究亚马逊、卖家与客户的交互，开发因果模型来评估费用变化的影响，为服务定价提供科学依据。
   • 职责：作为领域负责人（经济学家），定义方法论，主导高风险分析，并与财务、定价产品经理等多方合作，将研究转化为战略行动。

3. 基础技术与科学团队：

   • 团队：包括Amazon Robotics的Veritas团队和Alexa日常必需品团队。
   • 核心任务：
     • Amazon Robotics：研究神经符号AI，探索将语言模型与经典AI推理相结合，生成可验证正确性的方案，并应用于自动化与物流。
     • Alexa日常必需品：利用数据科学优化日常用户体验（如定时器、新闻、厨房引导），通过数据分析、建模和自动化框架来提升产品。
   • 职责：进行前沿研究，发表论文，构建和部署AI系统，并与工程和产品团队紧密合作，将创新技术应用于实际业务场景。

4. 广告基础模型：

   • 团队：专注于垂直广告产品与广告基础模型的创新团队。
   • 核心任务：利用先进的机器学习技术，特别是计算机视觉、NLP和深度学习，评估和增强广告效果，为创意制作提供数据驱动的预测和建议。
   • 职责：制定科学战略，识别高影响力机会，领导从构思到执行的科学项目，并构建预测模型以优化广告主表现和客户体验。

共同的关键职责与技能要求

• 端到端解决方案开发：大多数职位要求候选人能够独立或领导团队，完成从问题定义、模型设计、分析验证到生产部署的全过程。
• 高级技术专长：普遍需要机器学习、因果推断、计量经济学、深度学习、NLP、计算机视觉等领域的深厚知识。
• 跨职能协作与影响力：必须与产品经理、工程师、业务领导及运营团队紧密合作，确保模型可扩展、稳健，并将科学洞察转化为业务决策和行动。
• 领导力与影响力：包括制定技术愿景、指导初级科学家、参与招聘，以及在科学社区进行知识分享和成果发表。
• 业务导向：所有职位都强调工作的最终目标是直接影响客户体验、成本优化、网络可靠性、收入增长等核心业务指标。

结论

这些职位共同描绘了亚马逊在多个业务前沿，如何通过尖端的科学与工程实践来解决复杂的大规模问题。岗位要求高度的专业深度、强大的协作能力和将研究成果产品化以驱动实际业务价值的能力。

Nginx安全公告摘要

公告日期： 2024年2月14日

作者： Sergey Kandaurov

核心内容： 公告披露了Nginx HTTP/3实现中存在的两个安全漏洞，对应的CVE编号为CVE-2024-24989和CVE-2024-24990。

漏洞影响：

• 利用特制的QUIC会话，攻击者可能导致Nginx的worker进程崩溃（CVE-2024-24989， CVE-2024-24990）。
• 其中一个漏洞（CVE-2024-24990）可能产生其他潜在影响。

受影响条件：

1. Nginx在编译时启用了 ngx_http_v3_module（该模块默认不编译）。
2. Nginx配置文件中，在 listen 指令里使用了 quic 选项。

受影响版本： nginx 1.25.0 至 1.25.3。

修复版本： 此漏洞已在 nginx 1.25.4 版本中修复。

建议： 使用受影响版本并启用了HTTP/3（QUIC）功能的用户，应尽快升级到nginx 1.25.4或更高版本。

诺贝尔奖得主格雷格·塞门扎已累计有10篇论文因数据与图像问题被撤回。

塞门扎是约翰·霍普金斯大学医学遗传学教授、血管项目主任，曾因“发现细胞如何感知和适应氧气供应”的成就获得2019年诺贝尔生理学或医学奖。

在2019年之前，化名侦探克莱尔·弗朗西斯已在PubPeer网站上标记了塞门扎论文中可能存在的图像重复或操纵问题。自2020年10月起，更多侦探发布了相关质疑。

过去一年间，塞门扎作为共同作者的论文陆续被撤回，包括：美国国家科学院院刊（PNAS）上四篇、《癌基因》一篇、《生物化学杂志》两篇。每份撤回通知均说明是由塞门扎本人请求或同意撤回。

最新被撤回的是2013年发表于**《分子癌症研究》的一篇论文，标题为“胶原赖氨酸羟化酶2对缺氧诱导的乳腺癌转移至关重要”。该论文已被引用181次**。

此外，塞门扎此前还有一篇与Naoki Mori（已撤回31篇论文，位居撤回排行榜第24位）合著的论文于2011年被撤回。至此，塞门扎被撤回的论文总数达到10篇。

撤回通知指出：作者发现论文图3A中HIF-1α免疫印迹的第4、5、6泳道为相同图像。经内部审查证实，编辑同意撤回。作者对科学界致歉，对由此带来的不便深表遗憾。

该论文的部分作者同意撤回，但未能联系到其余三位作者。塞门扎本人未对置评请求作出回应。约翰·霍普金斯大学今年夏天被询问时，也未就是否正在调查此事发表评论。

早在2020年10月，就有PubPeer用户指出该图存在疑点。论文第一作者曾发布“原始未裁剪版本”的图片作为回应，但面对后续质疑未再回复。

文章总结：作者回顾了自己在Auth0公司六年的工作经历，直到公司被Okta收购后裁员的过程。以下是主要内容：

裁员经历

• 作者于2024年某周四收到裁员通知，此前已察觉公司重组和优先级混乱的迹象。
• 被裁员后，前同事通过社交平台互相支持，作者获得遣散费并规划与亲友见面。

Auth0的职业历程

• 2018年加入：负责SDK开发，学习OpenID Connect、OAuth 2等技术，接触单元测试、CI/CD等工程概念。
• 文化体验：通过巴拿马和洛斯卡沃斯团建活动感受到Auth0的独特文化——支持性环境、无责备文化、同事间真诚协作。
• 技术入职培训：担任导师，帮助新员工学习产品知识，认为这段经历塑造了公司文化。
• 疫情支持：公司鼓励员工平衡工作与生活，提供灵活安排，帮助作者度过家庭挑战期。
• Okta收购：2021年Okta以65亿美元收购Auth0，作者担忧文化消失，但初期仍感受到原有支持文化延续。
• 团队变动：后期在“Auth0 by Okta”品牌下工作，但感觉公司故事已接近尾声。

感悟与未来计划

• 作者感谢Auth0的两位创始人及同事，认为六年时间实现了十年般的专业成长。
• 计划未来几个月专注于写作、开源项目（budget-cli和data-getter）及个人生活，包括自行车比赛和陪伴家人。