文章概述： 作者分享了其第一个成功副业项目的经历——一个用于TradingView平台的自动绘制谐波形态脚本。该项目从个人需求出发，发展为付费产品，并带来超过15,000美元的收入，但后期维护工作使其倍感疲惫。文章详细叙述了从开发、营销、面对挑战到最终寻求“自动化”解救的整个过程，并总结了个人收获的经验教训。

核心内容总结：

1. 项目起源与成功开端：作者在2020年为简化自己在TradingView上手动绘制谐波形态（一种技术分析方法）的过程，用PineScript开发了自动化脚本。在发现其价值后，通过Gumroad销售该脚本的订阅权限，并通过创建免费精简版脚本、在TradingView发布交易观点和建立YouTube频道进行营销，逐步获得了付费用户，实现了初始的销售成功。

2. 随之而来的挑战与消耗：

   • 客户服务压力：随着用户增加，作者需要处理大量邮件和评论，包括技术问题、功能请求（甚至一些不切实际或基于“加密货币交易大师”理论的）、以及反复解释基本信息。
   • 不愉快的互动：遭遇了用户试图免费获取源代码、索取投资建议、提出不合理退款要求（甚至发起支付争议）、以及欺诈行为（如使用被盗信用卡）。
   • 个人兴趣转移：作者自身因忙于其他工作已不再进行日内交易，失去了对项目的热情，维护工作逐渐从乐趣变为负担。

3. 应对与“自动驾驶”策略：

   • 尝试出售项目未果，因项目技术栈（PineScript）和目标市场过于小众。
   • 转而利用n8n等工具实现自动化：自动处理购买后的授权、通过Telegram机器人管理订阅、建立在线表单收集试用申请。
   • 设置边界：严格限定支持范围（仅服务付费客户），停止功能更新，大幅减少查看和回复非关键信息的时间。此举显著降低了工作量，改善了作者的心理状态，但项目增长也随之放缓。

4. 总结的经验教训：

   • 防止耗尽：发布产品仅是开始，持续的维护（尤其是客户支持）可能令人精疲力竭。如果副业不再是兴趣所在，必须设置界限以保护个人时间和精力。
   • 善用工具：对于全球销售，使用Gumroad这类“记录商户”可避免处理复杂的税务问题。
   • B2C销售的挑战：直接面向消费者的销售需要处理更多样化、有时更棘手的客户互动，但仍是可行的商业模式。
   • 保持友善：对客户保持友好和同理心（如慷慨退款）虽可能偶尔被利用，但有助于建立良好声誉和获得正面反馈。

5. 项目现状与反思：项目目前作为一项几乎无需维护的被动收入（每月约200美元）存在，作者计划在管理成本超过收益时将其关闭。虽然经济回报可能不及同等时间投入的客户工作，但整个过程带来的经验对构建未来项目极具价值。

Zen 浏览器概述

Zen 是一款基于 Firefox 引擎、类似 Arc 的开源浏览器，专注于提供更平静的网络体验。其设计强调美观性、隐私保护及功能实用性，旨在帮助用户提升工作效率，而非分散注意力。

主要特性与功能

• 工作区：允许用户将标签页按项目分类组织，并可轻松切换不同工作区，保持工作区整洁。
• 紧凑模式：通过隐藏标签栏来扩大屏幕可用空间，仅在需要时显示，提升浏览空间效率。
• 快速切换：提供快速访问常用标签页的功能，无需浏览历史记录即可轻松切换。
• 分屏视图：支持并排查看两个标签页，便于同时对比和切换内容。

核心理念与支持

Zen 以平衡美观、性能和隐私为核心价值，致力于在用户体验与数据保护之间取得协调。项目依靠赞助商支持维持发展，用户也可通过直接捐赠参与其中。

该浏览器以隐私为中心，不收集用户数据，专注于打造高效、安静的浏览环境。

麻省理工学院（MIT）领导层描述了不续签爱思唯尔（Elsevier）最大期刊合同的经历，总体评价是积极的。MIT长期以来试图通过大额捆绑合同避免供应商锁定，在2019年，该校仍按标题逐一订阅约675种爱思唯尔期刊。2020年，他们采取了重大举措，取消了全部675种期刊的合同，此后用户仅能立即访问2020年之前的存档内容。据MIT图书馆估计，此举使其年度节省了原支出的80%以上，每年节省约200万美元，并通过替代方式满足了大部分文章请求，通常可在几分钟内完成。

在与教职员工和大学行政人员奠定基础后，过渡相对顺利，研究人员的反对意见极少。大多数教职员工支持图书馆根据MIT价值观采取原则性立场，并找到了替代方式获取所需研究资料，无需订阅爱思唯尔。四年后，对即时访问缺失感到最困难的教职员工主要集中在生命科学领域。

这一经历凸显了MIT过去基于历史支出的爱思唯尔期刊订阅成本，与图书馆实际为用户提供阅读访问所需费用之间的巨大差异。在出版方面，MIT的分析表明，爱思唯尔的“阅读与发布”提案并未提供财务规模经济。虽然各机构的具体情况不同，但MIT图书馆员认为其他机构也可能从类似举措中受益。他们有兴趣与他人合作，利用节省的资金集体投资于开放出版。

准备工作 2019年，MIT的开放获取临时工作组建议制定一个以价值为基础的新框架，作为与出版商进行机构合同谈判的基础。该文件于2020年5月正式通过，明确了学院对开放获取和公平性的承诺，并为图书馆在谈判中提供了关键工具。校园内日益增长的信念是，MIT支持开放学习、开源软件和开放学术的传统也应体现在其与出版商的关系中。基于原则的新框架确保了诸如期刊合同谈判等决策牢牢植根于机构的价值观。图书馆馆长Chris Bourg表示，继续向那些封锁本校学术成果的公司支付数百万美元，与MIT支持开放教育和研究的历史不一致。

这些原则是与MIT图书馆系统委员会协商制定的，其成员在争取支持方面被证明至关重要。文件草案在与MIT五所学院委员会的会议上进行了分享，并由图书馆代表和委员会教职成员共同进行演示。重要的是有来自教职员工的支持者能够进行同行交流。许多教职员工热情支持基于原则的方法，而一部分人虽认同原则，但对访问可能改变表示担忧。此前加州大学系统取消了与爱思唯尔的合同，表明MIT并非孤例，这有助于当时缓解部分担忧。

决策、成果与校园反应 在2020年与爱思唯尔的谈判中，MIT将其原则作为新合同谈判的基础呈现给出版商代表。一旦明确该公司不会同意推进MIT框架中概述的原则（例如允许所有作者保留版权），图书馆决定不续签合同，于当年7月生效。为支持MIT社区，学术交流馆员创建了网页指导用户获取文章的选项。最初几个月，主要通过馆际互借和开放获取文章提供访问。一些学者（尤其是生命科学领域）对缺乏即时访问表示担忧，MIT随后还与Reprints Desk签订了合同，提供按需按篇付费的访问服务。

“周转时间过去和现在对于几乎所有请求几乎都是即时的，”Bourg说。使用这种非订阅访问策略的组合，92%的文章在1分钟内送达，97%在1小时内送达。许多大学担心按篇访问可能导致成本超过标准大额捆绑合同，但这在MIT并未发生。图书馆每年在商业文献传递上花费约30万美元。

Bourg表示：“我们花了数年时间建立联盟，获得了院长、系主任和教务长的支持，他们从一开始就提供了支持。虽然一些学者对稍慢访问带来的不便感到沮丧，但我们一直努力减少摩擦和不便。我们没有任何证据表明MIT的研究和教学质量有所下降。”

2022年，爱思唯尔再次联系MIT希望重启合同谈判。此次Bourg由MIT合同律师陪同，谈判再次基于MIT出版商合同框架。MIT要求明确其支付的商品和服务、利用合同促进学术交流体系公平性的方法，以及允许所有MIT作者（包括非通讯作者）在没有禁令的情况下在知识库中公开其文章的合同。然而，公司再次提出了标准的“阅读与发布”合同提案，MIT决定继续保持无合同状态。

MIT图书馆员继续收集有关期刊需求的数据，并倾听教职员工的调整情况。图书馆预计有限数量的MIT学者可能购买了个人期刊订阅。大多数人似乎愿意通过文献传递或其他访问机制多走一小步，以支持MIT的价值观。

MIT预计在无合同期间将维持类似的节省水平。虽然对Reprints Desk的需求可能随时间略有增加，但随着公开获取文献比例的增加（特别是2022年OSTP备忘录全面实施后），这一需求可能会被显著抵消。按需阅读访问的任何成本增加，也可能低于MIT若保持期刊订阅合同所面临的价格年涨幅。

下一步和建议 Bourg对众多人所做的工作以及高级领导层看到的逻辑感到自豪：为研究人员不需要的内容付费是不合理的。取消合同是校园内关于学术交流未来更广泛对话的一部分，她希望这一对话能继续下去。Bourg给其他机构的建议是：“关注使用和成本数据，在校园内寻找关心公平和开放问题的盟友。这既符合我们公共参与的价值观，也符合经济利益。”

随着与爱思唯尔保持无合同状态所节省的资金不断积累，MIT有兴趣与其他图书馆合作，将这些资金再投资于社区控制的开放出版计划，以更好地服务于自身校园和更广泛的学术界。Bourg指出，图书馆的每个人都以某种方式做出了贡献——从直接参与谈判、供应商评估、技术工作，到实施替代访问的工作流程创建、协助用户、收集和分析数据、进行演示、安排和协调会议等等。这是一项真正的全图书馆努力。

注意：有兴趣将节省自大额捆绑合同的资金投资于开放计划或寻求解除捆绑的替代访问策略的机构，欢迎加入SPARC谈判实践社区的战略优先工作组。

Zed AI 概要总结

Zed AI 是 Zed 编辑器推出的托管服务，旨在通过集成先进的人工智能模型，为开发者提供高效、透明的 AI 辅助编程体验。其核心是与 Anthropic 公司合作，使用 Claude 3.5 Sonnet 模型，并对 Zed 编辑器进行了优化以实现极速响应。

核心功能与设计理念

Zed AI 强调透明性和用户控制，其 AI 功能并非黑箱操作，而是深度融入编辑器文本处理的核心工作流中。主要通过两个核心功能实现：

1. 助手面板：

   • 本质：一个完整的文本编辑器，用于与 AI 模型交互。用户可以直接查看、编辑用于生成响应的完整请求文本（包括代码片段、历史记录、文件内容等），从而获得完全的透明度和控制权。
   • 上下文构建：通过一系列斜杠命令快速、灵活地向对话中插入上下文：
     • /tab：插入当前打开的标签页内容。
     • /file：插入特定文件或目录树的内容。
     • /terminal：插入终端输出。
     • /diagnostics：插入整个代码库的诊断信息。
     • /fetch：插入任意 HTTP URL 的响应。
     • 这些命令支持扩展（通过 WebAssembly 或 JSON 协议），允许用户创建自定义命令。

2. 内联转换：

   • 激活：通过 Ctrl-Enter 触发，允许用户在代码编辑位置通过自然语言提示来转换或生成代码。
   • 技术亮点：采用自定义的流式差分协议，与 Zed 的 CRDT 缓冲区结合，能够逐个令牌地实时显示模型的输出变化，实现低延迟的交互体验。
   • 上下文复用：转换使用助手面板中构建的完整上下文，确保过程透明。用户还可以在助手面板内部递归地应用内联转换，用于迭代优化提示词。

技术实现与优化

• 与 Anthropic 深度合作：Zed 的文本中心界面和高性能特性吸引了 Anthropic 工程师的关注，双方展开了合作。目前，Zed 是 Anthropic 许多工程师的日常开发工具。
• 性能优化：Zed 与 Anthropic 合作实现了提示缓存测试版，即使在上下文窗口包含数千行代码时，也能提供闪电般的响应速度并降低成本。

未来发展路线

Zed 团队正在持续扩展 Zed AI 的能力，重点包括：

1. 复杂转换工作流：开发 /workflow 命令。该命令允许助手面板与项目文件进行双向交互，AI 模型可以输出一系列步骤建议，直接指导对项目文件的内联转换，从而实现更复杂的、由 AI 引导的编码任务。
2. 高效的上下文构建工具：认识到构建合适上下文是 AI 辅助开发的关键挑战，正在开发新工具：
   • /project（已可用）：帮助快速查找并插入相关的项目信息到助手面板。
   • /auto（开发中）：将基于当前任务自动插入上下文，同时保持所有插入内容可见和可编辑，兼顾便捷性与控制权。

总结

Zed AI 代表了 Zed 团队对 AI 辅助开发的愿景：将大语言模型的能力无缝、透明地集成到一款快速、可靠且专为文本操作设计的编辑器中。它赋予开发者完全的控制权，让 AI 成为提升生产力的强大工具，而非不可控的黑箱。该服务目前在初始发布期间免费提供。

文章指出，语义网作为早期的“Web 3.0”概念（旨在实现机器可读的网站），如今已被广泛采用，其实现程度足以让人认为我们已身处“Web 3.0”时代。它并非未来，而是当下，其普及主要通过嵌入网页的结构化元数据实现，常隐藏在标记代码中。

文章以博客文章为例，展示了如何使用 JSON-LD（关联数据JSON）格式添加元数据。具体做法是在HTML页面的<head>中加入<script type="application/ld+json">标签，内含符合Schema.org模式的JSON数据，如定义类型（@type: BlogPosting）、标题、作者（Person类型）等字段。

采用语义网元数据的主要好处包括：

1. 社交分享优化：社交媒体平台（如Twitter、Facebook）能生成包含图片和描述的丰富链接预览，从而提升点击率。
2. 搜索增强：搜索引擎爬虫能更智能地抓取内容，并在搜索结果中显示更多有用信息（如作者），吸引用户点击。
3. 自动聚合与分发：内容可能被自动聚合服务发现和展示（例如出现在手机新闻流中）。

JSON-LD的应用不止于博客，还有多种类型，例如用于描述事件的Event、产品的Product等。文章以作者自己的数据网站csvbase为例，展示了Dataset类型的JSON-LD，其中包含数据集名称、URL、维护者、多种格式的数据下载链接（如CSV、Parquet），甚至通过“CSVW”子模式描述了表格列的数据类型。这有助于数据搜索引擎（如Google Dataset Search）理解和呈现数据集。

文章驳斥了“用AI自动解析网页即可”的观点，理由有二：

1. 大语言模型（LLM）解析可能出错，而提供明确的元数据能确保准确性。
2. 强制依赖需要昂贵GPU算力的LLM来读取网页，是一种倒退，且具有排他性。

在替代方案方面，文章简要提及了Facebook的Open Graph Protocol、microdata和Twitter的Twitter Cards等，但认为JSON-LD因其结构化程度和广泛支持而势头最劲。

最后，文章将语义网描述为一项 “无聊但已成功的技术”，它已低调地普及，只是没有迎来一个所谓的“胜利时刻”。作者暗示，如果谷歌能像对待其他服务一样，推出并最终关闭一个相关的推广项目，JSON-LD的知名度或许能像RSS一样得到提升。

如何建造5万吨锻造压力机

技术背景与需求

20世纪40年代末至50年代初，喷气发动机的发明推动了美国军用飞机设计的革命。飞机速度突破音障，对材料（如镍基合金、钛合金）和制造工艺提出了新要求。使用大型锻件或挤压件替代众多小型零件组装，能够生产更轻、更强、更精简的部件，减少紧固件数量，降低制造成本并提升性能。然而，锻件和挤压件的尺寸受限于现有压力机的能力。

重型压力机计划的起源与启动

美国国防部于1950年启动“重型压力机计划”，旨在建造前所未有的大型锻造和挤压设备。该计划部分受到德国技术发展的启发——德国早在一战后就开始建造大型压力机以加工镁、铝等金属。二战后，美国缴获了部分德国压力机并加以研究。计划最终确定建造10台大型压力机（4台挤压机、6台锻造机），由空军管理、国防部资助，但交由私营企业租赁运营，政府分享少量收入。

建造过程与技术挑战

这些压力机规模庞大，例如5万吨级锻造压力机高达十层楼，能产生足以抬起一艘战舰的压力。建造它们是一项巨大工程：

• 基础工程：锻造压力机大部分位于地下，需要挖掘100英尺深的坑并用13英尺厚的混凝土衬砌。
• 组件制造：压力机由数百吨重的铸钢构件组成（如200吨横梁、145吨拉杆），这些部件的生产和运输需要特殊方法，部分由国外制造商提供。
• 配套基础设施：需要建造数千加仑容量的水箱、复杂高压泵送系统、大型熔炉以及能处理更大金属锭的生产线。例如，美国铝业公司在克利夫兰专门建造了50万平方英尺的工厂来容纳这些压力机。 到1956年，所有压力机均已完成并投入运营。

成效与应用

重型压力机的效益远超预期：

• 大幅优化飞机制造：用少量大型锻件替代数百个小型零件和成千上万的紧固件，显著减轻重量、降低复杂度。例如，一个案例中，272个零件和2700颗铆钉被4个锻件取代；另一个案例中，零件成本降低30%，重量减少6%。
• 减少加工时间和成本：压力机可生产接近最终形状的复杂部件，极大减少材料去除和机加工时间。部分零件的机加工成本从18000美元降至500美元。
• 广泛军事与民用应用：不仅用于军用飞机（如B-52轰炸机，其节约的成本超过整个压力机计划的投资），还扩展至弹道导弹、核潜艇、航天器（如水星号飞船的铍隔热罩、土星五号火箭的铝制锚固件），以及商业飞机（如波音747的钛合金起落架梁）。
• 长期经济回报：截至1960年代，该计划已节省约5亿美元的制造成本；到21世纪初，几乎所有美军飞机及空客、波音的飞机都使用了这些压力机生产的零件。

技术影响与启示

• 推动航空航天工业发展：重型压力机被认为是“工业史上金属加工领域最迅速、影响最深远的进步”，使湿翼设计等先进结构在经济上可行，奠定了现代航空航天工业的基础。
• 制造工艺的革命：通过整体锻造/挤压大型复杂部件，优化了设计与制造的集成，降低了成本并激发了新技术可行性。
• 类比与延续：特斯拉在汽车制造中采用大型铸造（Giga-casting）技术替代众多零件，降低了车身成本20%-40%，是类似的制造革命。这表明通过大型一体化部件推动技术进步仍有空间。
• 当前挑战与反思：美国在建造此类巨型设备的能力上有所衰退，现代压力机部件制造依赖外国公司（如德国SMS集团），大型铸造机也多由中国企业供应。这凸显了维持先进制造技术和基础设施能力的重要性。

重要更新：微调平台下线计划

根据2026年5月8日的更新，OpenAI正逐步关闭微调平台。新用户已无法访问，但现有用户在未来几个月内仍可创建训练任务。所有已微调的模型在其基础模型被弃用前，将继续支持推理服务。

GPT-4o 微调功能概述

OpenAI正式面向所有付费层级开发者推出 GPT-4o 及 GPT-4o mini 的微调功能。开发者可通过自定义数据集对模型进行微调，从而在特定用例中以更低的成本实现更高的性能。微调功能支持定制回复的结构与语气，或遵循复杂的领域特定指令，且仅需数十个训练样本即可取得显著效果。

定价与限时免费额度

• GPT-4o：训练成本为每百万 Token 25美元；推理成本为输入每百万 Token 3.75美元，输出每百万 Token 15美元。至9月23日，每个组织每天可免费获得100万个训练 Token。
• GPT-4o mini：至9月23日，每个组织每天可免费获得200万个训练 Token。

成功案例

• Cosine (Genie)：这款 AI 软件工程助手利用真实软件工程师的工作示例微调 GPT-4o，使其能够以特定格式（如代码补丁）输出。Genie 在 SWE-bench Verified 基准测试中取得了 43.8% 的最先进（SOTA）成绩，并在 SWE-bench Full 中达到 30.08% 的 SOTA 成绩，实现了该基准测试历史上最大幅度的提升。
• Distyl：在领先的文本到 SQL 基准测试 BIRD-SQL 中排名第一。其微调的 GPT-4o 模型在查询重构、意图分类、思维链和 SQL 生成等任务中表现出色，执行准确率达到 71.83%。

数据隐私与安全

• 数据所有权：微调模型完全由用户控制，用户对其业务数据（包括所有输入和输出）拥有完全所有权。数据绝不会被共享或用于训练其他模型。
• 安全机制：OpenAI 实施了分层的安全缓解措施，包括持续运行自动化安全评估并监控使用情况，以防止微调模型被滥用并确保其符合使用政策。

shadPS4 早期PS4模拟器项目总结

项目概述 shadPS4 是一个早期的 PlayStation 4 模拟器，使用 C++ 编写，支持 Windows、Linux 和 macOS 操作系统。它是一个模拟器核心，不包含图形用户界面（GUI），最终用户需下载 QtLauncher 来使用。项目始于趣味性尝试，目前能成功运行《血源诅咒》、《黑暗之魂：重制版》、《荒野大镖客：救赎》等部分游戏，但仍处于早期开发阶段，体验可能不完善。

主要特点

• 跨平台支持：兼容主流的三大桌面操作系统。
• 早期但可行：已能运行一些知名游戏，开发者承诺会定期发布小更新。
• 开源与社区驱动：采用 GPL-2.0 许可，欢迎开发者参与贡献。拥有 Discord、X（Twitter）和官方网站用于交流与发布新闻。

编译与构建 项目提供了在不同平台下的构建说明：

• 可使用 Docker 进行容器化构建。
• 分别为 Windows、Linux 和 macOS 提供了详细的构建指南。
• 注意：macOS 用户需要至少 macOS 15.4 版本，且在 Intel Mac 上可能存在严重的 GPU 相关 bug。

使用方法

• 基本启动：通过命令行运行，指定游戏文件夹标识符（如 CUSA00001）或直接指向 ELF 文件（path/to/game.elf）。
• 命令行参数：支持多种参数，如 --fullscreen true（全屏）、--config-clean（清理配置）等。详细用法可通过 --help 查看。
• 调试与问题报告：项目提供了专门的调试文档。

控制与输入

• 支持键盘和鼠标输入，并预设了控制器按键到键盘的映射方案（例如，W/S/A/D 对应左摇杆，I/K/J/L 对应右摇杆）。
• 支持即插即用的 Xbox 和 DualShock 控制器。
• 用户可以在设置菜单中自定义每个按键的映射（支持每个绑定最多三个键、鼠标按钮、鼠标移动模拟摇杆等），自定义设置会按游戏保存。

固件文件要求

• 模拟器需要加载部分 PlayStation 4 固件模块才能正常运行游戏。
• 必需的模块（如 libSceAudiodec.sprx 等，共 15 个）需要放入模拟器的 sys_modules 文件夹。
• 重要声明：这些固件模块必须从用户合法拥有的 PlayStation 4 主机中提取。

团队与致谢

• 列出了核心开发团队成员（如 georgemoralis, psucien 等）和 Logo 设计者。
• 项目特别感谢了其他团队/项目，包括 Panda3DS、fpPS4、yuzu、felix86 和 emudev.org，他们在模拟器开发、系统逆向工程、着色器编译器设计等方面提供了重要帮助或启发。

文章摘要：《Calling All Hackers》

本文出自《Phrack》杂志第71期，作者cts（@gf_256）以黑客和创业公司CEO的双重身份，探讨了黑客精神、金融市场本质及创业生态的深层问题。

核心观点

1. 广义的黑客定义：黑客不仅是技术高手，更是理解世界复杂系统运行方式的人——从计算机底层到金融规则、从社会结构到个人生活。这种理解力可用于突破限制、做出明智决策。

2. 加密货币市场的真相：

   • 代币的核心目的：价格“上涨”（Pump）是其唯一功能。
   • 两种主要发行模式：
     • “亚洲安排”：交易所、做市商、VC与项目方形成利益闭环，通过拉高出货（Pump and Dump）获利，散户最终接盘。
     • “西方方式”：通过更复杂的叙事（如“颠覆性技术”、“强大团队”）包装项目，本质仍是依赖炒作和估值泡沫，VC常通过生态项目或做市来维持热度。
   • 安全问题根源：急于上线代币以抓住市场热点，导致代码质量低劣，安全让位于速度。

3. 金融系统基础：

   • 固定收益（债券）：价值基于未来现金流的现值（DCF模型），利率（折现率）是关键。零利率环境（ZIRP）导致资金对估值不敏感，催生了大量烧钱换增长的“CAC模式”（如廉价网约车、外卖），最终成本转嫁至社会。
   • 股权（股票）：价值包含基本面（未来现金流的现值）和投机性（由市场情绪和叙事驱动）。科技股常具有高投机性，部分公司（如示例中的Airbnb）通过股份类别设计使创始人/早期投资者保持绝对控制权。
   • 股东价值优先的悖论：法律要求公司优先为股东利益服务，但股东是流动性最强、最不投入的利益相关方。这导致公司可能为短期股价损害员工、客户和社区的长期利益。追求股东价值最大化也被视为维持美元霸权、吸引全球资本的策略。

4. 风险投资（VC）与创业的扭曲：

   • VC的激励：追求极端回报（100倍以上），以覆盖大多数失败投资。因此偏好“可规模化”、“定义品类”的公司，即使其产品可能华而不实。
   • 对创始人和公司的影响：VC推动创始人成为“邪教领袖”式的宣传家，不断追求更高估值和叙事，而非可持续业务。这导致：
     • 公司发展方向可能偏离初心，追求高风险高回报的“彩票”。
     • 创始人心理压力巨大，员工体验糟糕。
     • 资本涌入导致行业文化被“收编”和庸俗化（如网络安全会议）。

5. 给黑客的建议与呼吁：

   • 理解系统：学习金融和资本市场的运作是获取影响力的第一步。
   • 保持批判与行动力：不要陷入无力感。黑客应追求创建可持续的企业，以系统化地创造正面影响（如提供好工作、服务客户）。
   • 负责任地经营：将公司视为持久的价值创造机器，而非快速套现工具。保持私有化，关注现金流与可持续性，捍卫价值观。
   • 谨慎融资：仅在必要时融资，确保控制权和长期愿景不受侵蚀。警惕要求牺牲长期利益换取增长的投资人。
   • 保护黑客精神：在“黑客”身份被商业化的时代，守护其探索、理解和改变系统的核心精神。新一代黑客应学会驾驭资本和社会系统，而非被其支配。

总结

作者呼吁黑客超越纯粹的技术视野，理解并参与塑造经济和社会系统。通过创建符合黑客伦理的企业，可以在系统内实现有意义的改变，而非仅作为外部的破坏者。文章是对当前创业文化、VC逻辑和金融化社会的深刻批判，也是一份赋予黑客能动性的宣言。

• Rootkit恶意软件：能够隐藏自身文件、进程等，并与操作系统内核直接交互以控制系统核心功能。
• FudModule变种安装技术：
  • 早期版本使用“自带易受攻击驱动”技术，通过安装存在漏洞的合法驱动获取内核权限。
  • 最新变种则利用Windows内置驱动appid.sys（AppLocker服务的一部分）中的漏洞，无需第三方驱动。
• 关键漏洞（CVE-2024-38193）：
  • 由Avast安全公司发现并私下报告给微软。
  • 该漏洞直接集成于Windows操作系统，比第三方驱动漏洞更具危险性，被研究者视为黑客的“圣杯”。
  • 微软耗时约六个月修复该漏洞，期间朝鲜黑客组织Lazarus持续利用该漏洞进行攻击。
• 攻击方：朝鲜黑客组织Lazarus。
• 未披露信息：未提供Lazarus利用该漏洞的起始时间、受影响组织数量、最新FudModule变种是否被终端保护服务检测到，也未提供入侵指标。

Rye 与 Uv：Python 包管理的整合与未来

Uv 的快速演进与 Rye 的过渡 自 Rye 的管理权移交至 Astral 公司以来，Astral 在 Python 打包工具方面取得了显著进展。其底层的解析器和安装器 uv 性能大幅提升，并新增了修改 pyproject.toml、工作区支持、本地包引用、脚本安装以及 Python 环境管理等原本依赖 Rye 才能实现的核心功能。作者建议现有的 Rye 用户开始关注 uv 并向开发团队提供反馈。

解决工具碎片化，追求生态统一 随着 AI 和机器学习的繁荣，Python 吸引了大量新开发者。然而，当前 Python 包管理工具种类繁多、互不兼容且缺乏一致性，导致开发者经常在不同工具间反复横跳，严重影响了使用体验。作者强调，包管理工具应当追求在该领域的“主导”地位，这能确保社区投资和精力集中于单一技术栈，从而为所有开发者提供最佳的体验。

Uv 的潜力与社区倡议 作者认为 uv 最有潜力成为 Python 包管理的主导工具，并期待 Rye 的未来版本能够退役其特有功能，全面迁移至 uv 并仅作为其别名存在。为了推动生态统一，作者呼吁社区逐步淘汰不再推荐的旧工具，减少推荐繁杂的包管理方案。正如过去社区从 easy_install 成功迁移到 pip 一样，重要 Python 项目的维护者应积极尝试 uv，并考虑将其作为向用户推荐的首选工具。

关于 Astral 商业背景的考量 针对 Astral 作为风投（VC）支持公司可能带来的潜在风险，作者指出，uv 的代码高度可分叉且易于维护。即使在最坏的情况下（如公司倒闭或采取不当的许可证策略），社区也能轻松接管，整体生态的处境依然会比 uv 出现之前更好。

澳大利亚政府批准AAPowerLink项目，旨在向新加坡出口太阳能电力

Sun Cable公司表示，该项目的获批“象征澳大利亚政府对其能在适当监管条件下完成这一国家重要项目的信心”。公司澳大利亚董事总经理Cameron Garnsworthy称此批准为项目旅程中的“里程碑时刻”，并将专注于在2027年前达成最终投资决定。

项目概况与规模： AAPowerLink项目计划部署17至20吉瓦（GW）的太阳能装机容量，以及36.42至42吉瓦时（GWh）的储能设施。项目将通过长达4,300公里的海底电缆，连接澳大利亚北部领地与新加坡，同时为北部领地首府达尔文及周边地区供电。

项目开发分为两个阶段：第一阶段向达尔文的绿色工业客户供应900兆瓦（MW）电力，第二阶段供应约3吉瓦（GW）。此外，项目还将通过2吉瓦（GW）的高压直流（HVDC）海底电缆向新加坡客户供应1.75吉瓦（GW）电力。据Sun Cable称，项目完全建成后，可通过海底电缆满足新加坡约15%的总用电需求，预计供电将于2030年代初开始。

当前进展与后续步骤： 该项目已获得印度尼西亚当局的批准。目前，Sun Cable正与北部领地的传统土地所有者就《原住民土地使用协议》进行谈判，以推进社区投资与项目实施。在新加坡，公司正与新加坡能源市场管理局就海底电缆互连组件的有条件批准申请进行合作。同时，公司也在与印度尼西亚政府就监管和许可事宜进行沟通，以共享海底路线的相关知识及水文数据。

项目总监Andrew Barton此前曾表示，该项目将“使用全球已部署项目的成熟技术”，并称其“将释放太阳能的潜力”。

Handwriter.ttf 项目摘要

项目概述

Handwriter.ttf 是一个概念验证项目，它通过滥用 Harfbuzz 的 WASM Shaper，在运行时动态合成手写体字形。该项目受 llama.ttf 的启发，旨在探索 WASM Shaper 在字体整形职责之外的更疯狂用途。其核心是一个超轻量级的 RNN 模型（约14MiB），用于实时生成和光栅化手写风格的字形。

使用方法

• 环境要求：需要在链接了启用了实验性 WASM Shaper 的 libharfbuzz 的应用程序中运行。目前没有任何产品默认支持此功能。
• 快速体验：项目提供了预构建的 Docker 镜像 hsfzxjy/harfbuzz-wasm-handwriting-synthesis，其中包含 TTF 文件和一个修改版的 gedit 编辑器。
  1. 在带有 X11 的 Linux 系统（包括 WSL）上克隆仓库。
  2. 在项目目录中运行 make run 命令，该命令会拉取 Docker 镜像并启动 gedit。
  3. 在弹出的 gedit 窗口中输入文本。每行需要以 # 开头才能触发合成效果（例如输入 #hello world）。
• 提示：由于模型的局限性，某些笔画可能显示异常，在文本后追加一个空格通常可以改善效果。

技术实现细节

• 算法：遵循 Alex Graves 的论文《Generating Sequences With Recurrent Neural Networks》，采用 RNN 模型进行手写合成。生成过程分多步进行，给定输入文本，模型在每一步预测下一个笔尖位置，生成一系列笔画。随后，使用 Bresenham 直线算法将笔画光栅化为像素位置，这些位置最终被设置为一系列“黑盒”字形的偏移量。
• 模型选择：作者尝试了更新的模型，但其运行时延迟无法接受，因此选择了该 RNN 模型。

性能与优化

• 速度：经过高度优化后，最终的 TTF 文件在 Intel Ultra 125H 处理器上可实现 0.08 秒/字符 的生成速度。每段文本的生成时间与其长度成正比。
• 关键优化手段：
  • 使用 rten 作为推理后端，确保神经网络运算通过 SIMD 指令执行。
  • 预转置矩阵乘法（MatMul）的右侧操作数使其为列优先，提升约15%的性能。
  • 运行时需编译 wasm-micro-runtime 并启用 SIMD (-DWAMR_BUILD_SIMD=1)，同时必须使用 wamrc 对 WASM 文件进行 AOT 编译。
  • 在 wamrc 中启用特定优化选项（如 --opt-level=3、特定 load/store 操作的 --enable-segue 以及 --enable-tail-call），进一步将性能提升约55%。

许可证

该项目采用 Apache 2.0 许可证，版权所有者为 hsfzxjy (2024)。

DEGAS：全身高斯虚拟人的细节表情

研究目的 尽管神经渲染技术在创建逼真的可动画全身和头部虚拟人方面取得了显著进展，但将丰富的面部表情细节融入全身虚拟人仍是一个未被充分探索的领域。本文提出了 DEGAS，这是首个基于 3D 高斯溅射（3D Gaussian Splatting, 3DGS）的全身虚拟人建模方法，旨在实现具有丰富且细腻面部表情的全身虚拟人生成。

方法结构与技术细节

• 核心模型：利用特定主体的多视角视频进行训练，学习一个条件变分自编码器（Conditional Variational Autoencoder）。
• 驱动信号与生成：将身体运动和面部表情作为联合驱动信号，在 UV 布局（UV layout）中生成高斯图（Gaussian maps）。
• 创新表情驱动机制：在面部表情驱动方面，摒弃了 3D 头部虚拟人中常用的 3D 可变形模型（3DMMs），转而采用仅通过 2D 人像图像训练的表情隐空间（expression latent space）。这一创新有效弥合了 2D 说话人脸与 3D 虚拟人之间的技术鸿沟。

关键功能与实验结果

• 高保真渲染：结合 3DGS 的强大渲染能力和表情隐空间的丰富表现力，模型能够驱动虚拟人重现照片级逼真的渲染图像，并精准还原微妙的面部表情。
• 数据集与验证：在现有数据集以及研究团队新提出的“全身说话虚拟人”数据集上进行了实验，充分验证了该方法的有效性。
• 音频驱动扩展：借助 2D 说话人脸技术，研究还提出了该方法的音频驱动扩展版本，为开发交互式 AI 智能体（Interactive AI agents）开辟了新的可能性。

Vasilis van Gemert 在文章中指出，网络行业和学生普遍对“语义化”（semantics）感到抵触，他提倡将关注点从“语义化”转向**“HTML的用户体验”**，这一转变能更有效地激发学习兴趣和行业实践。

• 核心问题：绝大多数网站忽视了HTML的正确使用（如标题层级混乱、表单缺少标签、用div代替链接或按钮）。作者发现学生和从业者对“语义化”一词感到厌烦。
• 教学方法转变：作者不再强调“语义化”，而是展示HTML元素带来的具体UX功能和优势。例如：
  • 使用<label>标签：可将标签与输入框关联，实现点击标签聚焦、屏幕阅读器播报等交互。
  • 使用真正的<a>链接：相比带有点击事件的<span>，能提供专门的右键菜单、屏幕阅读器链接列表导航、键盘聚焦等完整UX层次。
  • 使用正确的<input>类型（如email）和required属性：在移动端优化键盘并实现基于HTML的表单验证。
  • 使用<details>和<summary>：无需JavaScript即可实现内容展开/收起。
• 对传统语义化教学的反思：
  • 过去的会议和教学长期强调标题层级和文档大纲，但效果甚微。
  • HTML5引入的<section>、<article>等区块化元素理论复杂且UX差异不明显，导致理解和实践困难（如“区块化滥用”）。
  • 相比之下，正确使用交互元素（如链接、按钮、表单）对UX的影响远大于理论性的语义结构。
• 教学优先级建议：应先通过展示交互元素带来的强大且免费的UX功能来激发兴趣，建立对UX的理解，之后再深入讲解标题、地标角色等更复杂、细微的模式。
• 行业展望：作者呼吁未来的会议和讨论应更多关注HTML元素实际带来的UX功能（如单选按钮的中间态、仅用HTML和CSS的友好表单验证、不同元素的上下文菜单等），而非停留在理论层面的“语义化”讨论。

德州立交桥为何如此高耸？

德州立交桥的现状
德克萨斯州拥有世界上最高的一批高速公路立交桥，其中达拉斯的“High Five”立交桥最为著名，高达百余英尺（约30米），拥有五层道路结构。这类高耸的立交桥是德州交通网络的典型特征。

立体交叉的必要性
高速公路采用立体交叉设计，让不同道路垂直交叉，避免交通信号灯和停车中断，从而提升通行速度与容量。当需要连接两条高速公路或复杂交通流时，立交桥应运而生。

常见立交桥类型

• 菱形立交：结构简单，成本低，但存在平面交叉口，流量有限，适用于次要道路。
• 苜蓿叶立交：通过环形匝道实现全方向转向，但环形匝道需减速，且“交织区”易引发拥堵和事故。
• 堆叠式立交：采用定向匝道和多层桥梁结构，消除交织问题，允许车辆高速通过，但造价高昂且占地较大。

德州立交桥高耸的原因：辅路系统
德州在高速公路两侧普遍修建辅路，连接沿线区域，最初是为了降低征地成本（通过提升土地价值补偿业主）。辅路系统使得立交桥需要额外一层来实现立体交叉，从而形成独特的五层堆叠式立交（“德州堆叠式”）。典型结构包括：

1. 底层主路（可能低于地面）
2. 地面辅路层
3. 上跨主路层
4. 两层定向匝道层
   这种设计导致匝道高点常超过百英尺，形成视觉冲击。

案例与影响
德州拥有多处五层甚至六层堆叠式立交，如达拉斯“High Five”、圣安东尼奥的“陀螺”式立交等。尽管辅路政策因成本效益和环境影响（如助长城市蔓延）而调整，但新建项目中辅路仍普遍存在。高耸立交虽展现工程实力，但也被批评为汽车中心化交通网络的象征，其巨额投资与可持续交通理念存在矛盾。

Plasmo 框架简介

Plasmo 是一个功能强大的浏览器扩展 SDK，旨在简化现代浏览器扩展的构建过程。它类似于 Next.js，但专为浏览器扩展开发而设计，帮助开发者专注于产品功能，而非配置文件和扩展开发的独特复杂性。

主要特点

• 一流支持：为 React 和 TypeScript 提供首选支持。
• 声明式开发：简化开发流程。
• 内容脚本 UI：允许在内容脚本中直接使用 UI 组件。
• 标签页页面：支持独立标签页扩展。
• 开发体验：实时重载和 React 热模块替换（HMR）。
• 配置与 API：支持 .env* 文件、Storage API 和 Messaging API。
• 高级功能：支持远程代码打包（如 Google Analytics）、针对多个浏览器和清单版本进行构建，并通过 BPP 实现自动化部署。
• 可选框架支持：除 React 外，还提供对 Svelte 和 Vue 的可选支持。

系统要求

• Node.js 16.x 或更高版本。
• 支持 MacOS、Windows 或 Linux 操作系统。
• 强烈建议使用 pnpm 包管理器。

基本用法

1. 创建项目：pnpm create plasmo example-dir
2. 进入目录：cd example-dir
3. 启动开发服务器：pnpm dev

文件结构

开发者可以通过特定的文件名来组织代码：

• popup.tsx：弹出窗口（Popup）页面。
• options.tsx：选项（Options）页面。
• content.ts：内容脚本。
• background.ts：后台服务工作者（Background Service Worker）。 此外，代码文件可按模块组织在各自目录中（如 popup/、options/、contents/ 等）。源代码也可放在 src 子目录中，但资源文件和配置文件通常需保留在根目录。

支持与社区

• 浏览器支持：具体支持的浏览器目标列表请查阅官方文档。
• 社区：Plasmo 社区主要在 Discord 上交流，是获取帮助和讨论的主要平台。社区遵循其行为准则。
• 贡献：项目欢迎贡献，详细指南请参阅相关文档。

附加信息

• 示例：官方提供了多个示例，展示如何与 Firebase、Redux、Supabase、Tailwind 等工具集成。
• 资源：官方文档和《Building Browser Extensions》一书是深入了解浏览器扩展开发的良好资源。
• 许可与状态：Plasmo 采用 MIT 许可证。目前处于 alpha 阶段，功能可能随版本更新而变化，使用时需注意。

Peng：基于Rust的最小化四旋翼模拟框架

概述

Peng是一个使用Rust编写的最小化四旋翼自主性框架，提供实时动力学模拟、轨迹规划与控制功能，并具备现代可视化能力。

核心特性

🚁 实时模拟

• 高保真度四旋翼动力学，支持参数可配置
• 模拟IMU（惯性测量单元）和深度传感器
• 可选RK4积分器以实现精确动力学计算

🎮 高级控制

• 带有可调增益的位置与姿态PID控制
• 积分抗饱和保护
• 支持不同控制频率

📍 丰富的轨迹规划

• 最小急动度（Minimum Jerk）直线轨迹规划器
• 利萨如曲线（Lissajous）规划器
• 圆形轨迹规划器
• 避障规划器
• 最小快照（Minimum Snap）航点导航规划器
• 二次多项式（Quadratic Polynomial）航点导航规划器
• 着陆规划器

📊 可视化与调试

• 通过rerun.io实现实时3D可视化
• 深度图渲染
• 状态遥测日志记录
• 可配置的日志记录频率

⚡ 性能

• 内存安全且高效的Rust实现
• 多线程深度渲染

快速开始

前置条件

• Rust
• rerun-cli

安装（从Crates.io）

cargo install rerun-cli
cargo install peng_quad
peng_quad config/quad.yaml

从源码安装

cargo install rerun-cli
git clone https://github.com/makeecat/Peng.git
cd Peng
cargo run --release config/quad.yaml

配置

可通过配置文件（如quad.yaml）进行设置，包括：

• 模拟参数（质量、惯性、控制增益）
• 控制参数（如PID增益）
• 轨迹规划器参数（航点、障碍物、轨迹类型）
• 可视化参数（相机内参、深度渲染）

疑难解答

若在使用rerun时遇到问题，请：

• 确保rerun-cli版本与Cargo.toml中的rerun版本匹配。
• Linux/WSL2用户请查阅rerun的疑难解答指南。

路线图

未来计划包括：

• 风场与环境效应模拟
• 电机动力学模拟
• 多四旋翼模拟
• 模型预测控制（MPC）

贡献与许可

欢迎各种形式的贡献，请查阅贡献指南。项目采用双重许可（MIT或Apache-2.0），使用者可任选其一。

引用

如在研究或工作中使用本项目，请引用：

@software{peng_quad,
  author       = {Yang Zhou},
  title        = {Peng: A Minimal Quadrotor Autonomy Framework in Rust},
  year         = {2024},
  publisher    = {GitHub},
  journal      = {GitHub repository},
  howpublished = {\url{https://github.com/makeecat/peng}},
}

本文介绍了作者在工作中遇到的一个内存泄漏问题，并分享了其排查和解决过程。核心内容如下：

• 应用场景：作者维护一个RAM密集型的酒店定价引擎应用。该引擎需要加载大量数据，构建内存索引，并执行查询。问题在于，尽管整个数据集远小于可用内存，应用在生产环境中却出现了内存不足（OOM）错误。
• 简化模型与问题发现：作者将问题简化为一个Rust程序模型，该程序通过Arc<RwLock>管理状态，并由一个后台线程定期刷新酒店数据。使用默认内存分配器时，内存使用稳定在约4GB，符合预期。然而，当切换到高性能的mimalloc分配器后，程序在刷新时内存使用量意外地增加了一倍（达到8GB），表现为内存泄漏。
• 艰难调试：作者花费了大量时间（文中比喻为“失去一周生命”）使用valgrind、perf、分析汇编代码等工具进行调试，最初误以为是应用代码中Arc生命周期管理的问题。
• 根本原因：问题根源在于mimalloc分配器的设计特性。mimalloc假设线程会定期进行内存分配操作，以此触发其内部记账和内存回收机制。在程序中，负责分配内存的主线程在启动后台线程后进入休眠状态。尽管后台线程正确释放了旧数据（Rust析构函数正常工作），但内存块被标记为“待释放”。由于主线程休眠，无法触发mimalloc的记账过程，导致这些已释放的内存块无法被重新利用，从而造成内存使用量虚假增长。
• 解决方案：作者通过将数据刷新操作集中到同一个专门的线程来解决此问题，确保进行内存分配和释放的线程保持活跃，能够定期触发分配器的记账机制。
• 总结与经验：此次经历让作者意识到，在排查棘手问题时，需要考虑底层工具（如内存分配器）的特性和行为，而不仅仅是应用程序逻辑。

Rust 安全垃圾回收技术：gc-arena 设计解析

1. Rust 与垃圾回收的现状

• Rust 标准库不提供带循环检测的垃圾回收（GC），但设计上存在挑战（所有权、可变性与别名互斥、最小运行时）。
• 作者为满足 piccolo（安全Lua运行时）的需求，开发了 gc-arena 库，目标是：
  1. GC指针在使用期间零开销（Copy、无运行时记账）。
  2. 运行时代码主要为安全Rust，避免类似C的内存不安全传染。

2. 核心技术挑战

• 正确追踪可达指针：遗漏追踪会导致释放后访问（UAF）。
• 确定GC根：管理（managed）指针可能存在于栈、堆或寄存器，缺乏语言运行时支持。
• 增量收集时的可变性：若已追踪对象（黑色）被修改并指向未追踪对象（白色），会破坏颜色不变式，可能产生悬垂指针。
• 指针生命周期控制：需确保GC指针不会逃逸出特定作用域。

3. 技术方案与实现

3.1 Collect trait 与安全追踪

• 所有可GC类型需实现 unsafe Collect trait 的 trace 方法，确保追踪所有可达指针。
• 提供 #[derive(Collect)] 宏安全实现，要求所有字段均实现 Collect，自动生成正确追踪逻辑。
• 禁止 Drop 实现：循环引用下无法确定安全的销毁顺序，通过内部 MustNotImplDrop trait 在编译时阻止。

3.2 内部可变性与写屏障

• GC指针仅提供共享引用（&T），修改需通过内部可变类型。
• gc-arena 提供 Lock（类似 Cell）和 RefLock（类似 RefCell），这些类型在修改时强制触发写屏障。
• 写屏障机制（向后写屏障）：当修改“黑色”对象时，将其重新置为“灰色”（待重新追踪队列），确保增量收集的正确性。

3.3 生命周期品牌化（Generativity）

• 利用Rust的高阶生命周期约束（HRTB）实现“生成性”：每次 Arena::mutate 调用时，'gc 生命周期为唯一生成值。
• Gc<'gc, T> 包含一个 Invariant<'gc> 标记，保证生命周期不变性，防止跨作用域指针混用。
• 通过回调闭包（for<'gc> FnOnce）强制GC指针仅在 mutate 调用期间有效，逃逸将导致编译错误。

3.4 根类型与生命周期投影

• Arena 的根类型 R 通过 Rootable trait 定义，使用类GAT技术（trait对象宏 Rootable!）实现生命周期参数化。
• Rootable! 宏利用 trait 对象自动实现特性，无需为每种根类型手动定义结构体。
• 根类型在 mutate 调用中可获取特定 'gc 的实例，但无法逃逸出回调。

4. 安全保证总结

• 收集安全：Collect trait 确保所有指针被追踪。
• 可变性安全：写屏障维护颜色不变式。
• 根确定性：单一根类型 + 生命周期品牌化保证收集时对象图稳定。
• 指针隔离：生成性 'gc 生命周期防止指针逃逸或跨Arena混用。

5. 实际应用与权衡

• 通过双向链表示例展示了完整用法：节点定义、安全修改、循环引用创建与收集。
• 设计带来较高使用成本（回调式修改、上下文参数传递），但提供了可证明的内存安全。
• 未来可能利用 async/.await 表达GC安全点以优化体验。

文章摘要：密码学中“YOLO”构造的常见错误与正确替代方案

本文指出，在密码学实践中，开发者常犯一个错误：基于哈希函数自行构建工具来解决特定问题（如合并多个值、生成MAC或派生密码密钥），这些临时方案被称为“YOLO”构造。它们看似简单直接，但通常存在安全缺陷。文章分析了三种常见YOLO构造的问题，并提供了经过验证的替代方案。

1. YoloMultiHash（多值哈希）

• 构造：将一组消息 M1, M2, …, Mn 用分隔符 S 连接后哈希：H(M1‖S‖M2‖S‖…‖S‖Mn)。
• 问题：存在歧义编码风险。如果消息本身包含分隔符 S，则不同语义的输入可能产生相同的哈希结果，破坏了哈希函数的抗碰撞性。此问题已被用于攻击广泛使用的库。
• 替代方案：
  • 使用专为多值哈希设计的标准函数，如 TupleHash（NIST SP800-185）。
  • 或使用支持类似功能的哈希函数（如BLAKE3的“状态化哈希对象”）。
  • 改进数据序列化，采用无歧义的编码格式（如Protocol Buffers、CBOR、BCS），避免依赖易混淆的分隔符。

2. YoloMAC（消息认证码）

• 构造：H(K‖M) 或 H(K‖S‖M)。
• 问题：
  1. 长度扩展攻击：对于Merkle-Damgård结构哈希（如SHA-256），攻击者可在已知 H(K‖M) 的情况下计算 H(K‖M‖X)，伪造MAC。
  2. 歧义编码：即使使用SHA-3等抗长度扩展的哈希，仍可能因密钥和消息格式不明确，导致不同密钥/消息对产生相同MAC。文中举例如：同一MAC值可对应一个“罪证”PDF和一个“无害”JPG文件。
• 替代方案：
  • 对于SHA-2系列，使用标准 HMAC，其设计已规避长度扩展攻击。
  • 对于SHA-3，使用 KMAC（支持XOF模式、可定制字符串，性能更优）。
  • 对于BLAKE2/BLAKE3，使用算法内置的密钥哈希模式。

3. YoloPBKDF（密码派生密钥）

• 构造：H(S‖P) 或迭代哈希 Ki = H(S‖Ki-1)。
• 问题：安全性极差。此类构造计算速度快、内存需求低，使攻击者（如使用GPU）能以极低成本（每秒数千亿次）暴力破解密码。增加迭代次数仅线性提升安全性，效果有限。
• 替代方案：使用现代内存硬密码哈希函数，如 Argon2 或 scrypt。它们不仅要求计算资源，还强制大量内存使用，极大增加并行攻击难度。在FIPS合规环境中，可结合NIST批准的PBKDF2与内存硬函数（如Balloon）生成密钥。

总结

开发者不应重复发明密码学轮子。问题已有成熟解决方案：对于多值哈希，使用TupleHash；对于MAC，使用HMAC/KMAC；对于密码派生，使用Argon2等内存硬函数。在选择哈希函数时，应考虑其是否原生支持所需功能（如BLAKE2的密钥哈希、SHA-3的KMAC）。利用经过广泛研究和验证的标准方案，才能确保安全性。

这篇文章报道了数学家克里斯托夫·凯勒和瑞恩·昂格尔最近的研究成果，他们通过数学证明推翻了斯蒂芬·霍金等物理学家于1973年提出的一个著名假设，即极端黑洞在现实中不可能形成。

极端黑洞的概念与历史观点 极端黑洞是理论物理中一类特殊的黑洞，它同时具有最大可能的电荷或自旋（与其质量相关）。其显著特征是事件视界处的表面引力为零，意味着视界不再“吸引”物体。尽管1973年霍金、巴丁和卡特提出的黑洞热力学定律（类比热力学定律）中，第三定律曾断言在有限时间内无法使黑洞的表面引力降至零，从而推论极端黑洞无法形成。1986年，物理学家维尔纳·以色列似乎进一步证实了这一点。

新的数学证明 凯勒和昂格尔在研究带电黑洞形成时意外发现，通过用标量场中的低频带电脉冲轰击一个中性黑洞，可以在有限时间内使其电荷增加的速度超过质量增加的速度，从而将其转变为一个极端黑洞。他们的分析指出，以色列之前的证明存在缺陷。通过构建三种不同的数学情境，他们最终证明“第三定律是死亡的”——已知物理定律并不禁止极端黑洞的形成。

额外发现与意义

1. 没有裸奇点：他们的证明显示，形成极端黑洞并不会像物理学家担心的那样导致裸奇点（即没有事件视界的奇点）出现。相反，带电物质云如果坍缩，会在特定的电荷阈值形成极端黑洞，超过该阈值则物质云会分散，不形成任何黑洞。
2. 理论突破：这项工作被誉为“数学回馈物理学的一个漂亮例子”，它打开了一个可能更丰富的宇宙图景，表明极端黑洞在天体物理上可能存在。然而，正如其他科学家指出的，数学解的存在不等于自然界必然利用它。
3. 未来方向：目前证明针对的是带电极端黑洞。对于更可能被观测到的快速旋转的极端黑洞，其数学处理更为复杂，需要进一步研究。这项成果也有助于更好地理解宇宙中可能大量存在的近极端黑洞。

现状与展望 尽管数学证明表明极端黑洞理论上可以存在，但其在自然界中是否真实存在仍是未知数。迄今为止，尚未观测到具有显著电荷的黑洞。寻找旋转极端黑洞以及相关的观测证据，将是未来研究的重点。

Permify 1.0：开源细粒度授权服务

Permify 是一个开源的授权服务，旨在帮助开发者快速构建和管理细粒度、可扩展且可扩展的访问控制。其设计灵感来源于谷歌全球一致的授权系统 Zanzibar。

核心功能与优势

1. 集中化与标准化：将授权逻辑从应用程序代码中抽象出来，使其成为一个独立的、易于管理、测试和调试的单一实体。
2. 构建细粒度权限：支持创建资源特定、层级结构、上下文感知等复杂权限和策略。其领域特定语言兼容 RBAC、ReBAC 和 ABAC。
3. 多租户支持：允许为不同的客户或组织（租户）设置隔离的授权逻辑和自定义权限，并进行统一管理。
4. 高性能与可扩展性：在运行时响应各种访问控制检查，实现低至 10毫秒 的响应速度，基础设施设计受 Zanzibar 启发，可轻松扩展。

Permify Cloud 与自托管版 (Community Edition) 对比

• 基础设施管理：云版由 Permify 管理所有基础设施（高可用、备份、安全等），用户可专注于开发。自托管版则需要用户自行负责服务器、维护、升级、安全等一切事务。
• 发布与功能：云版持续更新，享有所有高级功能（如可观测性面板）。自托管版每年发布四次，部分高级功能不可用。
• 部署与数据隐私：云版支持选择 AWS、GCP、Azure 区域部署，符合 SOC2 和 GDPR。自托管版用户拥有完全控制权，需自行负责合规与安全。
• 支持与成本：云版提供专业人工支持，费用基于月活跃用户数。自托管版仅有社区支持，用户需承担服务器等相关基础设施成本。

快速开始

可以通过 Docker 快速在本地启动 Permify 服务：

docker run -p 3476:3476 -p 3478:3478 ghcr.io/permify/permify serve

• 端口 3476 提供 REST API。
• 端口 3478 提供 gRPC 服务。
• 默认使用内存存储授权数据。

性能测试

在模拟 1000 个虚拟用户 和 每秒 10,000 次请求 的负载测试中，Permify 表现稳定：

• 请求成功率：100% (0 失败)。
• 平均延迟：21.3 毫秒。
• 中位延迟：15.38 毫秒。
• 第 95 百分位延迟：58.99 毫秒。

社区与贡献

Permify 是 CNCF 成员项目，由全球社区驱动。欢迎通过多种方式贡献：

• 为代码库贡献新功能或修复问题。
• 改进文档。
• 优化官方 Playground 工具。 项目有公开的路线图，并设有“赏金”计划，对通过合并 PR 修复特定问题的贡献者给予奖励。

ArcticDB：为何一家对冲基金要自建数据库

背景与动机

Man Group是一家全球性的大型另类资产管理公司，管理资产超过1600亿美元，年交易规模达6万亿美元。其核心业务是在各类市场（如宏观、趋势跟踪、信贷等）中，为养老基金等专业客户寻求非相关的阿尔法收益。该公司面临的核心挑战是“规模化寻找阿尔法”——在巨大交易规模、多样投资策略和海量数据环境下，保持高效率和低成本。

公司技术负责人James Munro指出，量化投资竞争的关键在于研究生产力，而非仅仅是低延迟交易系统。随着数据量（尤其是高频tick数据和另类数据）爆炸性增长，以及市场效率提高，寻找超额收益变得更具挑战性。

为何自建数据库？

1. 数据特性不匹配：金融数据（如债券数据）具有宽表、高维、稀疏、形状不规则的特点。例如，一个债券数据集可能包含40万个历史可交易债券作为列，导致数据表非常“宽”且庞大（数百GB）。传统关系型数据库的规范化Schema在灵活性和查询性能上难以满足需求。
2. 以DataFrame为核心的工作流：从2011年起，Man Group全面转向Python进行数据科学。在量化研究、回测、组合优化和风险分析的整个流程中，Pandas DataFrame已成为数据存储、移动和分析的基本操作单元，用户更关心整个DataFrame的读写和操作。
3. 现有方案的局限性：公司曾使用MongoDB等数据库，但面临扩展瓶颈（曾运行数百台MongoDB服务器）和性能不足的问题。单一用户的复杂计算就可能耗尽整个集群资源。
4. 对核心功能的需求：
   • 高性能：支持每秒数十亿行数据的读写。
   • 简单易用的API：提供类似操作本地DataFrame的体验。
   • 灵活性：能够高效处理用户自定义的各种数据形状。
   • 可扩展性与成本效益：避免维护庞大的数据库服务器集群。

ArcticDB 的设计与架构

ArcticDB是一个完全无服务器（serverless）、客户端驱动的数据库，其核心设计决策和架构如下：

1. 放弃严格的隔离性（Isolation）：传统ACID数据库中的隔离性（协调多个并发事务）需要复杂的锁和队列机制，是性能和扩展性的主要负担。ArcticDB选择放弃强隔离性，允许用户以更类似处理“文档”（DataFrame）的方式管理自己的数据版本，从而简化了架构。
2. 基于不可变数据结构的版本控制：
   • 每次写入或更新操作都会创建一个新的、不可变的版本。
   • 通过一个原子的“符号链接”操作，将数据名称指向新版本，确保原子性和一致性。
   • 旧版本被保留，天然支持“时间旅行”（回溯历史数据版本），这对数据科学研究至关重要。
3. 纯客户端架构与存储分离：
   • 所有数据库逻辑（索引、查询执行、数据压缩与分片）都在客户端库内完成。
   • 仅依赖外部存储系统（如AWS S3、共享文件系统、高性能本地SSD）来保证持久性（Durability）和可用性。
   • 消除了数据库服务器、作业队列等中间层，极大地简化了部署、扩展和运维。用户只需创建一个S3桶、配置权限并安装ArcticDB客户端即可拥有一个数据库。
4. 为DataFrame优化的数据层：
   • 数据以列式存储，针对时间序列分析和跨截面分析进行了优化。
   • 支持宽表（数百上千万列）和稀疏/参差不齐的数据，无需为了规范化而拆分数据。
   • 具备数据压缩、分块（tiling）和索引功能，以实现高效查询。

效果与优势

• 极致的性能与扩展性：官方演示显示，ArcticDB能从本地闪存以每秒40GB的速度读取数据。通过利用云存储的扩展性，系统容量几乎可以无限扩展。
• 运维简单：无需管理数据库服务器，扩展和安全的责任转移给了底层存储提供商（如AWS）。
• 用户体验一致：提供简洁的Python API，操作体验与Pandas高度相似，降低了量化工程师的学习成本。
• 支持复杂数据形状：能高效处理金融领域常见的宽表、异构和稀疏数据。
• 版本控制与回溯：内置的数据版本管理功能支持数据审计和科学实验的可复现性。
• 开源与协作：ArcticDB已开源，并与Bloomberg、QuantStack等公司合作，用于其产品（如BQuant）中。

总结

Man Group构建ArcticDB，是为了解决其核心业务中“规模化阿尔法”所面临的独特数据挑战。它并非要替代所有数据库，而是专注于为Python数据科学社区，特别是处理高性能、高维度时间序列和表格数据场景，提供一个无服务器、高灵活度、易于使用且能直接连接对象存储的解决方案。通过放弃强隔离性、采用客户端执行架构和不可变版本控制，ArcticDB在简化运维的同时，实现了极高的性能和扩展能力，已成为Man Group内部及外部金融机构的关键数据基础设施。

uv 0.3：统一的Python打包工具

uv是一个用Rust编写的极其快速的Python包管理器，最初于2月份作为常见pip工作流的直接替代品发布。本次0.3版本的发布标志着uv功能的最大扩展，使其从pip替代品发展成为管理Python项目、命令行工具、单文件脚本乃至Python本身的端到端解决方案。其定位类似于Python领域的Cargo，提供一个快速、可靠且易用的统一接口。

核心新功能与定位

此次发布将uv从一个单一工具扩展为一个统一的工具链，涵盖以下领域，并可替代多种现有工具：

1. 端到端项目管理：新增uv run、uv lock和uv sync命令。uv现在可以基于标准兼容的元数据生成和安装跨平台的lockfile，成为Poetry、PDM和Rye等工具的高性能、统一替代方案。
2. 工具管理：新增uv tool install和uv tool run（别名uvx）命令。uv可以在隔离的虚拟环境中安装命令行工具，并无需显式安装即可执行一次性命令（例如uvx ruff check），成为pipx的高性能替代品。
3. Python安装：新增uv python install命令。uv现在可以为您引导和安装Python，成为pyenv等工具的替代方案。
4. 脚本执行：uv现在支持基于PEP 723标准、带有内联依赖元数据的、独立的单文件Python脚本。只需uv run即可执行独立Python脚本。

所有这些功能都由一个极快、跨平台的依赖解析器提供支持，并配有全新的综合文档。

主要特性详解

1. 项目管理

uv能够管理整个Python项目，其API对Poetry/PDM/Rye用户来说会感到熟悉。

• 基于标准：使用pyproject.toml声明项目元数据（遵循PEP 621）。
• 跨平台lockfile：uv可以生成项目的lockfile，它是项目在某一时刻完全解析的依赖关系快照，确保项目环境在不同机器间保持一致。该lockfile是跨平台的，即使在macOS上生成，也会为Linux和Windows等其他平台生成解析方案。
• 高性能：uv的解析速度极快。在无缓存的情况下解析Jupyter项目依赖仅需约0.5秒（有缓存时约0.02秒）；解析包含所有可选依赖的Transformers项目，无缓存约7.48秒（Poetry需47.91秒，PDM需91.91秒）。
• 中心命令uv run：在项目环境中运行命令（无需显式激活虚拟环境）。它足够快，每次调用都会隐式地重新锁定和同步项目，保证环境是最新的、一致的。

2. 依赖源与工作区

• 依赖源：uv扩展了标准，支持开发期间使用相对路径和可编辑依赖。通过tool.uv.sources可以在开发时指定依赖的来源（如本地可编辑版本），同时发布时仍声明标准依赖。
• 工作区：受Cargo启发，uv支持工作区（例如一个Web应用及其关联的多个库包）。工作区中的每个包有自己的pyproject.toml，但共享一个lockfile，确保依赖一致性。可以通过uv run --package <name>在指定成员中运行命令。

3. 工具管理

• 安装与运行：使用uv tool install在隔离虚拟环境中安装命令行工具，使用uvx（或uv tool run）直接运行一次性命令（如uvx posting）。
• 管理：uv tool list列出已安装工具，uv tool upgrade --all升级所有工具。
• 速度快：通过uvx执行命令几乎无额外开销。

4. Python引导与安装

• uv现在可以自行引导和安装Python。安装uv后，运行uv python install 3.12即可安装特定版本。
• uv可以在需要时（如执行uv run时）自动下载缺失的Python版本，实现完全自引导。这意味着从一个全新的环境开始，仅通过安装uv和一条uvx命令，就能自动处理Python安装、环境创建、包安装和工具执行。

5. 单文件脚本支持

• uv提供对单文件Python脚本的一流支持，支持内联依赖元数据（PEP 723）。
• 使用uv add --script main.py "依赖"可以将依赖声明直接嵌入脚本中的特定注释块。
• 随后，uv run main.py会在一个隔离的、临时的虚拟环境中执行该脚本并安装所有依赖。
• 也可以使用uv run --with "依赖" main.py在运行时临时添加依赖。
• 结合Python自动安装功能，现在可以仅凭uv就运行独立的、可分发的单文件Python脚本，无需关心虚拟环境、依赖管理或Python版本。

设计理念与总结

uv的核心优势在于其极致的速度和统一的接口。它将项目管理、工具运行、Python版本管理、脚本执行等多个原本需要不同工具（pip, pipx, pyenv, Poetry/PDM/Rye）的场景整合到一个高性能的工具链中。通过始终使用标准lockfile和pyproject.toml，并针对开发流程添加实用扩展（如工作区、可编辑依赖），uv旨在为从初学者到大型项目团队的各类Python开发者提供一致、快速且可靠的开发体验。uv可以通过独立安装程序或从PyPI安装。

关于Unity的思考

Unity的现状与核心问题

Unity近年来面临多重挑战，其根源可追溯至过去十年。公司从2004年的小型创业团队发展为最流行的游戏引擎之一，但维持领先地位充满困难。作者作为2006年加入、2022年离职的前员工，观察到Unity的成功源于早期抓住了市场空白，但也正因资本驱动和战略转向引发一系列问题。

资本驱动的扩张与战略迷失

• 资本注入改变发展轨迹：2009年获得风险投资后，公司目标从“稳健生存”转向“快速增长”。2019-2021年的大规模收购和2020年IPO加速了这一过程。
• “黄金时代”与资本化后的差异：用户怀念的“好时光”（2012-2015年，Unity 4.x-5.x时代）对应初期资本注入后的稳定期，而非后来追求激进增长的阶段。
• 愿景缺失导致多向扩张：在实现早期愿景（成为灵活、跨平台的中小型团队引擎）后，Unity面临“下一步是什么”的困境。为满足资本回报要求，公司尝试多个新方向，但缺乏连贯战略：
  1. 拓展广告与数据业务：推出Unity Ads等业务，但隐私法规收紧使数据变现路径受阻。
  2. 进军非游戏行业：尝试覆盖建筑、汽车、医疗等领域，试图从这些习惯高许可费用的行业获取收入。
  3. 追求高端与AAA市场：2015年后大力投入高保真图形（HDRP）、艺术家工具等，试图摆脱“小引擎”形象。
• 内部文化冲突与技术路线分歧：R&D团队扩张导致多元甚至对立的技术理念：AAA开发者、Web开发背景者、底层性能优化专家等群体对引擎方向持不同看法，使产品丧失一致性。

产品与技术挑战

• 核心优势被侵蚀：Unity最初的优势在于：
  1. 原型开发便捷：灵活、通用，不限定游戏类型。
  2. 平台覆盖广泛。
  3. 编辑器可扩展性强。
  4. 迭代速度快：C#语言生态与编辑器快速重载。
• 高端化牺牲易用性：追求高性能和AAA级功能（如DOTS）导致引擎复杂化、碎片化，用户体验下降。
• API设计问题：
  • 渲染管线（SRP）困境：URP和HDRP本应是原型实验，却成为互不兼容的正式选项，源于API设计未能统一底层数据模型。
  • 扩展性不足：新功能多为封闭设计，用户难以定制，只能选择“使用或分叉维护源码”。
• 工具链效率低：包管理、资产导入、编译流程等影响迭代速度。

作者对Unity未来的建议

1. 回归核心优势：聚焦灵活性、可扩展性、跨平台与快速迭代，任何新功能都不应牺牲这些基石。
2. 提升工具链体验：
   • 自动化复杂流程，简化界面。
   • 编辑器扩展性应成为一等公民（如集成Odin Inspector等功能）。
   • 保持资产导入、编译、迭代流程快速稳定。
3. 分层API设计：
   • 底层API面向专家，提供高性能、灵活控制。
   • 高层API面向普通开发者，封装常见概念（如网格、材质）。
4. 统一渲染数据模型：不同渲染管线应基于相同场景数据工作，差异仅通过设置调整。
5. 开放源码：减少许可壁垒，助力开发者调试与项目推进。
6. 审视AI影响：当前引擎的复杂设置流程可能被AI生成内容颠覆；同时，Unity应思考如何既提供高层抽象（如“木材质”语义化设置），又保持底层API的先进性。

结语

作者希望Unity能明确发展方向，制定清晰计划，避免沦为“缓慢行进的失事列车”。技术团队与产品本应获得更好的发展环境，而非因战略混乱导致人才流失与用户转向其他引擎。

静电电机实现宏观尺度突破，或将在工业应用中与电磁电机竞争。传统电磁电机依赖稀缺材料，而静电电机主要使用铝、塑料等廉价材料，理论上效率可提升30%至近100%。美国威斯康星大学教授丹尼尔·卢多伊斯联合创办的C-Motive公司，已研制出扭矩达18牛·米、功率360瓦的宏观静电电机原型，据称是旋转式静电设备中扭矩和功率的最高记录。该技术在2024年IEEE能源转换大会论文中有所报告。

静电电机在微观尺度优势明显，但在宏观尺度因空气间隙中能量密度远低于电磁系统而面临挑战。C-Motive通过多项创新克服这一限制：在非导电转子和定子盘上设置放射状导体，通过精确的静电荷控制实现相位差以产生扭矩；采用六层转子与定子叠层结构；最关键的突破是研制出一种有机介电液体，其相对介电常数达20以上（空气为1），且粘度低、环保无毒，替代空气作为电介质以存储更多电场能量。此外，公司利用廉价高效的功率半导体器件开发了2000伏驱动系统，实现电场精准控制。

目前该360瓦电机已能驱动工业泵系统工作，功率比以往静电电机高数百倍。C-Motive正测试750瓦（1马力）电机，并计划开发1至5马力（750至3750瓦）机型，目标应用于工业自动化、制造和暖通空调等领域。研究团队表示，这项技术有望减少电机对稀土材料和铜的依赖，推动电气化领域的可持续发展。

欧空局的“木星冰月探测器”（Juice）成功完成了全球首次月球-地球连续引力辅助飞行。该探测器利用地球和月球的引力改变飞行轨道，节省了100-150千克燃料，并引导其踏上前往木星的“内太阳系捷径”。

任务过程与成效

• 8月19日，Juice以6840公里的近距离飞越月球，随后于8月20日飞越地球东南部上空。
• 引力助推效果：月球飞越使其相对太阳的速度增加0.9千米/秒；地球飞越则减少4.8千米/秒，最终将飞行轨迹偏离原方向100度，指向金星。
• 飞越期间，探测器启动全部十台科学仪器中的八台进行测试，并拍摄了月球和地球的图像与光谱数据，为抵达木星前的仪器校准提供了宝贵资料。

后续飞行计划 此次飞越将Juice重新导向金星。后续路径包括：

• 2025年8月：飞越金星，获得引力加速。
• 2026年9月与2029年1月：两次返回地球附近飞越，进一步获取引力助推。
• 2031年7月：最终抵达木星系统。

任务背景与科学目标 Juice于2023年4月由阿丽亚娜5号火箭发射升空，是欧空局主导的大型旗舰任务。其主要目标是对木星及其三颗大型冰卫星（木卫三、木卫四、木卫二）进行详细观测，研究这些卫星作为潜在生命栖息地的可能性，并探测木星复杂的磁场与辐射环境。

此次成功的月球-地球飞越不仅优化了燃料使用，还为探测器在复杂引力环境中的精密导航积累了经验，保障了后续科学任务的执行。