Safe Superintelligence Inc. 公司概述

核心使命
公司专注于构建安全的超级智能（SSI），视其为当代最重要的技术问题，并已成立全球首个专注于此的专项实验室。

公司定位与目标

• 名称与使命统一：Safe Superintelligence Inc.（SSI）既是公司名称，也是其唯一的产品目标和整体路线图。
• 所有资源（团队、投资、商业模式）均围绕 SSI 对齐，无分散注意力的产品周期或管理开销。
• 通过技术突破同步推进能力提升与安全保障，确保安全始终领先于能力发展，从而实现“和平扩展”。

商业模式与原则

• 商业模式旨在隔绝短期商业压力，保障安全、可靠性和进步不受干扰。
• 以科学和工程突破为驱动，快速推进能力发展的同时保持安全领先。

公司架构与人才

• 美国企业，在帕洛阿尔托和特拉维夫设有办公室，依托两地人才与资源。
• 组建精干顶尖的工程师与研究团队，全心专注于 SSI 研发。
• 面向全球招募人才，提供参与解决时代最重要技术挑战的机会。

联系方式
提供申请加入、获取更新及联系的渠道。
（版权信息：Safe Superintelligence Inc. © 2024 - 2026）

这是一个基于四色定理的互动谜题游戏。

游戏目标：玩家需要为英国及爱尔兰的地图上色，使得任意两个地理上相邻（接壤）的区域颜色不同。

交互方式：通过点击地图区域进行涂色操作来完成挑战。

核心概念：该游戏是一个数学谜题的温和介绍，其核心是展示四色定理——即在任何平面地图上，只需最多四种颜色，就能确保所有相邻区域颜色相异。

俄罗斯方块字体

字体设计
该字体中的每个字母和数字均由七种标准俄罗斯方块（I、J、L、O、S、T、Z）各一块组成。设计确保每个字符都能通过逐块堆叠并遵循游戏中的支撑规则实际构建出来。设计过程中借助了BurrTools软件，用于验证方块能否嵌入候选字母轮廓。颜色基本遵循俄罗斯方块公司的标准，也可切换为纯黑色。初始旋转遵循标准的超级旋转系统。

谜题玩法

• 谜题字体模式：字母以正确旋转和水平位置显示，垂直位置代表其下落顺序。用户可通过思考或动画下落来推断字母。
• 动画字体模式：即使未开启谜题模式，也可在动画完成前猜测字母。
• 黑色纯图案模式：尝试用七种方块完美拼出给定形状（类似BurrTools解决的拼图问题）。

相关数学研究

• 完全信息版俄罗斯方块是NP完全问题，意味着在给定初始布局和后续方块序列时，判断能否存活或清屏在计算上难以高效求解。
• 类似结论也适用于使用k-连块的k-tris变体。最近的研究分析了少行少列俄罗斯方块的复杂性，本字体即出现在该论文中。

致谢与灵感

• 该字体灵感来自2017年BRIDGES会议上与Alex Streif及Kadon企业Kate Jones的合作，最初使用5种“自由四连块”（S与Z视为同型，J与L视为同型）设计。
• Kate Jones曾为Kadon手册设计其他多连块字体。本字体更贴近俄罗斯方块规则，强调反射对称性和堆叠支撑。
• 其他数学与谜题字体可通过相关链接查看。反馈或问题可通过邮件联系Erik，源代码发布于GitHub。

Claude 3.5 Sonnet 核心总结

核心发布与可用性

• 定位：Claude 3.5 系列的首发模型，在多项评估中超越竞品及 Claude 3 Opus，同时兼具中端模型的速度与成本优势。
• 获取渠道：在 Claude.ai 和 iOS 应用免费提供，Pro/Team 订阅者享有更高调用限制；可通过 Anthropic API、Amazon Bedrock 和 Google Cloud Vertex AI 获取。
• 定价与规格：输入 $3/百万 token，输出 $15/百万 token，支持 200K token 上下文窗口。

性能与编程能力

• 基准测试：在研究生级推理（GPQA）、本科级知识（MMLU）和编程（HumanEval）方面创下行业新标杆。
• 速度与文本生成：运行速度是 Claude 3 Opus 的 2 倍；在理解细微差别、幽默和复杂指令方面显著提升，能生成自然且高质量的内容。
• 编程表现：在内部代理编程评估中解决了 64% 的问题（Opus 为 38%）。能独立编写、编辑、执行代码，并轻松处理代码翻译和遗留系统迁移。

顶尖的视觉能力

• 作为迄今最强的视觉模型，在标准视觉基准上超越 Opus。
• 擅长视觉推理（如解析图表）以及从不完美图像中精准转录文本，高度契合零售、物流和金融服务的数据提取需求。

全新功能：Artifacts

• 在 Claude.ai 推出 Artifacts 功能，将 AI 生成的代码片段、文档或网站设计展示在独立的专用窗口中。
• 用户可实时查看、编辑和扩展内容，标志着 Claude 从对话 AI 向动态协作工作环境的演进，未来将扩展至团队及组织级的知识共享与协作。

安全与隐私承诺

• 安全评估：经严格红队测试，安全级别维持在 ASL-2。与英、美 AI 安全研究所（AISI）合作进行预部署评估，并整合外部专家（如 Thorn 的儿童安全专家）反馈以防范滥用。
• 隐私保护：坚守隐私原则，未经用户明确许可，绝不使用用户提交的数据来训练生成式模型。

未来规划

• 模型家族：计划于今年晚些时候发布 Claude 3.5 Haiku 和 Claude 3.5 Opus，以完善 3.5 系列。
• 功能拓展：开发新模态及企业应用集成；探索“记忆（Memory）”功能，使模型能根据设定记住用户偏好与交互历史，提供更加个性化和高效的体验。

Octomind 公司弃用 LangChain 构建 AI 代理的决策与反思

背景与初衷

• Octomind 公司使用 AI 代理（结合多个大语言模型）自动创建和修复 Playwright 端到端测试。
• 自 2023 年初起，在生产环境中使用 LangChain 超过 12 个月，于 2024 年移除。
• 选择 LangChain 的最初原因：其组件和工具丰富、受欢迎，承诺能快速将想法转化为代码。

弃用 LangChain 的核心原因

1. 抽象僵化，限制灵活性：

   • 随着需求复杂化（例如，需要实现子代理交互、根据业务逻辑动态更改工具可用性），LangChain 的高级抽象成为障碍。
   • 其设计初衷是隐藏细节，但这导致团队在需要实现底层自定义行为时，难以深入或修改框架内部逻辑。
   • 例如，LangChain 不提供外部观察代理状态的方法，迫使团队缩减实现范围以适应框架限制。

2. 过度抽象增加复杂度，降低可理解性：

   • 通过一个简单的“将英文翻译为意大利文”的代码示例对比，说明 LangChain 相比直接使用 OpenAI 客户端，引入了多个不必要的抽象（如提示模板、输出解析器、链语法），显著增加了代码复杂性，却未带来实质收益。
   • 框架倾向于在抽象之上再叠加抽象，迫使开发者以嵌套抽象的思维理解 API，导致调试困难，经常需要理解庞大的堆栈跟踪和框架内部代码。

3. 对开发团队生产力产生负面影响：

   • 团队花费大量时间理解和调试 LangChain 本身，而非构建产品功能。
   • 无法自由地将需求编码实现，必须将需求“翻译”成框架兼容的方案。

替代方案：采用模块化构建块

• 摒弃框架依赖：公司决定完全移除 LangChain，转向不使用任何特定框架的开发模式。
• 识别核心需求：认为大多数应用所需的核心组件是：
  1. 用于与 LLM 通信的客户端。
  2. 用于函数/工具调用的机制。
  3. 用于 RAG 的向量数据库。
  4. 用于跟踪、评估等的可观测性平台。
• 采用构建块方法：专注于简单、底层的代码，谨慎选择外部包。这种方法保持架构精简、可适应，让开发者能专注于解决问题本身。

结论与建议

• 框架的局限性：在快速演进且尚未形成稳定使用模式的领域（如 LLM 应用），框架为固化模式设计的结构可能限制创新和迭代速度。
• 学习的价值：不使用框架虽然前期需要更多时间自行搭建工具集并深入研究，但这是对团队和应用未来的重要投资，有助于掌握领域基础知识。
• 保持简单：在当前阶段，建议保持代理使用模式简单，专注于顺序代码、提示迭代和输出质量改进。
• 最终成效：采用模块化构建块和最小化抽象后，团队的开发速度更快，摩擦更少。

项目概述

作者出于个人兴趣，利用现代FPGA技术，将经典的Cray超级计算机微架构实现为一块功能性腕表。这是一个在长期Cray复兴项目中的“趣味项目”，旨在利用不断发展的硬件（更便宜、更小的FPGA），以简化且可维护的方式实现一个二进制兼容的Cray J90核心，并将其封装在可穿戴设备中。

技术实现

• CPU核心：基于作者多年来逐步演变的RTL代码，最终用System Verilog重写了一个非周期精确但二进制兼容的Cray Y-MP/C90/J90核心。主要区别在于地址总线从Cray-1的22位扩展到32位（可寻址32GB内存）。为简化设计，移除了向量链接功能，向量寄存器使用2R1W SRAM实现，指令缓存也针对FPGA进行了优化。
• 系统架构：核心运行在Diligent CMOD-A7 FPGA开发板上，时钟频率105 MHz（与真实J90一致）。系统包括CPU核心、少量SRAM和通过FIFO连接的SPI接口。一块Teensy 3.6微控制器作为前端处理器，负责控制复位、初始化内存、并通过SPI驱动CPU，同时向一块圆形OLED显示屏输出图像。
• 软件与功能：为了展示向量处理能力，腕表运行一个木星及其63颗卫星的N体引力模拟。程序通过Python编写并验证，最终转换为机器码在FPGA上执行。该模拟仅需127条指令，并能维持40 MFLOPS的性能。

腕表设计与“看时间”

• 外壳设计：选择Cray C90的1/25比例模型，主要是因为其顶部的圆形穹顶恰好能容纳OLED显示面板。外壳使用3D打印制造，内部经过精心布线，塞入了电路板并留有电池空间。
• 显示与读时：显示屏实时运行木星卫星的引力模拟，绘制卫星在黄道面的坐标。读时极具挑战性：用户需要根据已知的起始时间，通过观察卫星的实时位置来推断当前时间。作者认为这种复杂和不易理解的特性，正是该项目所追求的。

总结

该项目是作者对超级计算机历史热爱的趣味实践，它成功地将一个功能完整的（尽管大幅简化的）Cray计算核心集成到一个可穿戴的腕表形态中。虽然实用性有限，更像一个桌面上的奇趣摆件，但它充分展现了作者在硬件设计、复古计算模拟以及将复杂技术微型化方面的技能与创造力。

欧盟理事会撤回“聊天监控”法案投票

欧盟理事会及其参与者决定撤回由欧盟轮值主席国比利时提出的“聊天监控”计划的投票。因缺乏多数支持，该议题被从议程中移除，比利时的草案被无限期推迟。

• 法案核心与争议：该计划要求监控所有公民的聊天消息及其他数字通信，包括对端到端加密服务进行“客户端扫描”。其目标是检测已知和未知的滥用材料及诱导行为。专家警告，此举易产生大量误报，可能使无辜公民被错误识别。比利时版本引入了“上传审核”，即用户需同意扫描，否则将无法发送图片、视频和网址。批评者认为这只是对原概念的重新包装。
• 强烈反对声音：
  • Signal总裁梅雷迪思·惠特克指出，此举从根本上破坏了加密，并在数字基础设施中引入严重漏洞，其影响具有全球性。
  • Threema称该法案是危险的大规模监控倡议。
  • 前欧洲议会议员帕特里克·布雷耶等人警告，支持者利用欧洲议会选举后的过渡期推进议程。
  • 爱德华·斯诺登批评称，欧盟官员试图通过发明“上传审核”一词来推行一项普遍反对的大规模监控措施。
• 后续展望：
  1. 立法进程陷入不确定，将退回重新商议。讨论将在夏季休会后恢复。
  2. 关键时间点：7月，欧盟理事会轮值主席国将由比利时转交匈牙利，后者已承诺将推进打击网络儿童性剥削的相关立法。
  3. 主要矛盾：欧洲议会坚决反对任何绕过端到端加密的措施，预计后续谈判将非常激烈。成员国与议会需在2026年4月前达成协议。
  4. 重要表态：欧盟司法专员维拉·朱罗娃在6月20日首次公开承认，欧盟委员会的《儿童性虐待法规》提案会破坏加密，这与过去该委员会的一贯立场相比是重大转变。
  5. 隐私倡导组织将继续敦促欧盟公民保持警惕，参与这场关于数字隐私与监控的辩论。

X 窗口系统首次发布（1984年6月19日）

1984年6月19日，罗伯特·W·沙伊夫勒（Robert W. Scheifler）通过电子邮件宣布了X窗口系统的诞生。他在麻省理工学院LCS（计算机科学实验室）为VS100图形终端开发了这一系统。其开发借鉴了W窗口系统的大量代码，但关键创新在于将接口从同步改为异步，从而显著提升了性能，据称整体性能约为W系统的两倍。

邮件指出，尽管系统代码已较为稳固，但仍存在一些待修复的缺陷。LCS内部已停止使用W系统，并开始在X上积极构建应用程序。沙伊夫勒呼吁当时仍在使用W的用户认真考虑向X迁移，并称X“并非终极窗口系统，但可作为一个良好的实验起点”。

截至发布时，X系统已提供CLU语言和Argus语言的接口，C语言接口正在开发中。已有的三个应用程序包括：

• 文本编辑器（TED）
• Argus的I/O接口
• 一个初级的窗口管理器

邮件同时提到，当时尚未编写任何文档，沙伊夫勒公开邀请志愿者协助撰写。他提供了观看演示的地点（NE43-531房间）和联系电话，并欢迎对代码感兴趣者携带磁带前来获取，也欢迎开发者参与修复已知缺陷。

这封邮件标志着X窗口系统的正式亮相，为其后来成为Unix及类Unix系统中最主流的窗口系统奠定了基石。

NPM 与 NodeJS 应更努力让 ES 模块易用

作者在重返 JavaScript 和 TypeScript 开发后，在 NodeJS 环境中频繁遇到与模块系统相关的错误，这些错误都涉及导入、类型检查和模块加载，反映了当前 JavaScript 生态系统在核心模块机制上存在混乱。

模块系统的发展历程

JavaScript 和 TypeScript 的模块系统经历了显著演变：

• 早期没有标准模块系统，解决方案包括 IIFEs、AMD、require.js 等。
• CommonJS 成为事实标准，通过 require() 和 module.exports 工作。
• ES6 引入了新的 import / export 语法，开发者开始借助 Babel 和 TypeScript 将其编译为 CommonJS 代码。
• ES Modules (ESM) 被引入以改进静态分析和运行时加载效率，但在 NodeJS 中引入了复杂性：需要使用 .mjs 扩展名或在 package.json 中设置 "type": "module"，且与庞大的 CommonJS 生态系统互操作仍然痛苦。

当前采用情况

根据对 GitHub 高星项目和 NPM 下载量最多包的分析，ES Modules 的采用率在推出 5 年多后仍然较低：

• 仅有约 9-27% 的 JavaScript/TypeScript 项目通过 package.json 中的 type 字段声明自己是 ES Modules。
• 不到 6% 的文件通过 .mjs、.cjs、.mts 等扩展名声明为 ES Modules。

这导致许多项目既需要使用 ES Modules，又需要处理与遗留 CommonJS 代码的互操作问题，过程复杂。

改进建议

为简化生态系统并推动 ESM 采用，作者提出以下建议：

1. 弃用专用扩展名：停止支持 .mjs、.cjs、.mts 等，统一使用 .js、.jsx、.ts、.tsx，多数项目已依赖 type 字段而非文件扩展名。
2. 调整初始化默认值：npm init、yarn init、pnpm init 应默认设置 "type": "module"；包管理器的 publish 命令应在 type 未设为 module 时发出警告。
3. 升级常用库：通过手动或自动化 PR 将社区最常用的库迁移到 ES Modules。
4. 在 NPM 注册表明确模块字段：要求新包明确声明模块类型，让使用 CommonJS 的包（如为支持旧版 NodeJS）更显式。
5. NodeJS 未来可考虑停止支持 CommonJS：正式弃用 require 和 module.exports，以加速迁移。

作者希望听取社区对解决 ES Modules 与 CommonJS 互操作痛点的看法。

文章《高级塑料回收的妄想》深入探讨了塑料污染危机和所谓的“高级”化学回收技术（热解法）的局限性。其核心论点是，塑料行业大力推广的热解法并非解决塑料危机的切实方案，而更像是一种维持塑料生产现状的“绿色洗白”策略。

1. 塑料危机与行业叙事

• 塑料无法在自然界中分解，全球每年生产4.3亿吨塑料，科学家强调减少生产才是关键。
• 但塑料生产商和化工公司自1980年代起就将污染问题归咎于废物管理，并声称回收可以解决。他们早就知道传统（机械）回收收效甚微。

2. “高级”回收技术的承诺

• 行业现在推销一种称为热解法的化学回收技术，它使用高温将塑料分解回分子构件。
• 宣称的优势是：能处理传统回收无法处理的塑料（如冷冻食品包装），并将其转化为质量等同于新塑料的材料，实现真正的“循环经济”。

3. 调查揭示的真相与局限 作者通过追踪一个用热解技术制作的塑料水果杯的案例，揭露了以下关键问题：

• 实际产出率极低：100磅塑料废料经热解后，仅能产出约15-20磅可用于制造新塑料的化学物质（如丙烯和乙烯）。
• 最终产品中回收成分极少：由于热解产生的石脑油被污染，必须与大量化石燃料来源的石脑油（通常超过90%）混合稀释。因此，物理上最终产品中的回收材料含量通常不超过10%，实际可能只有2%-5%。
• 依赖“质量平衡”会计手段夸大宣传：行业使用复杂的会计方法（如质量平衡和自由归属），将有限的回收材料“价值”集中分配到某些产品上，从而在标签上声称更高的回收百分比（如“39%回收塑料”），但产品本身并未发生物理改变。这是一种误导性的营销。
• 依赖高品质、未使用的塑料废料：许多热解设施为保证工艺稳定，主要使用消费前的工业废料，而非从消费者手中回收的杂乱塑料。这些清洁废料本可轻易通过传统方法回收。
• 环境与健康成本：热解过程释放苯、二噁英等致癌物，其温室气体排放量甚至高于用原油生产新塑料。

4. 行业推动与影响

• 塑料行业正利用热解技术的“潜力”，游说各国政府和联合国条约制定者，试图将讨论重点从限制生产转向“管理废物”，并推动接受化学回收。
• 行业还游说放宽回收定义和空气污染法规，已有半数美国州放宽了热解的空气污染规定。
• 然而，根据分析师的乐观估算，即使全球所有热解项目满负荷运行，三年内最多也只能替代全球年新塑料产量的0.2%。

5. 结论 作者认为，热解法是一个被过度吹捧的“童话”，目前乃至未来都无法有效缓解塑料危机。其在商业上既不具规模，也不高效，反而主要服务于延续塑料生产和化石燃料依赖的行业利益，是一种分散公众对真正解决方案（减少塑料生产）注意力的策略。

Atkinson Dithering 摘要

背景与意义

• 1984年Macintosh发布，采用512x342分辨率、72 DPI的黑白显示器。其视觉设计核心之一是使用抖动算法，将有限的黑白色调模拟灰度图像。
• 本文介绍了两种常用抖动技术：Floyd-Steinberg抖动和Atkinson抖动，后者是Macintosh上的常见变体。

Floyd-Steinberg抖动

• 原理：基于误差扩散。当像素量化（如黑白二值化）产生误差时，将误差按比例分配给相邻未处理像素，使整体分布接近原始灰度。
• 实现：采用从上到下、从左到右的单次扫描。误差掩码定义为相邻像素的偏移量和权重（例如[1,7], [w-1,3], [w,5], [w+1,1]）。JavaScript实现示例展示了如何原地修改像素数组并扩散误差。
• 特点：边缘误差可能跨行扩散，但由于抖动的噪声特性，这不影响视觉效果。

Atkinson抖动

• 原理：Bill Atkinson开发的变体，误差扩散模式更宽，且只保留3/4的误差（误差除以8而非16）。掩码包括更多相邻像素（如[0,1,w-2,w-1,w,2*w-1]）。
• 实现：类似Floyd-Steinberg，但使用更大的误差缓冲区和均匀权重分配。JavaScript实现示例展示了简化版本。
• 效果：与Floyd-Steinberg相比，产生更丰富的对比度，但在极亮或极暗区域可能损失细节。图像示例对比显示Atkinson抖动在视觉上更悦目。

在iKe中的实现

• 利用iKe的/i操作符加载远程图像，使用灰色调色板转换为[0,255]灰度矩阵。
• 初始化全局误差缓冲区和掩码，定义函数d来处理单个像素：结合累积误差、量化颜色、更新缓冲区并扩散误差。
• 最终代码将整个图像缩放为[0.0,1.0]并应用抖动函数，展示了在iKe环境中的简洁实现。

总结

• Atkinson抖动作为Floyd-Steinberg的改进，通过调整误差扩散比例和模式，提升了图像主观质量，成为经典技术。
• 文章通过代码示例和图像对比，清晰阐述了算法的原理与实际效果。

Wc2：基于异步状态机解析的 Unix wc 程序优化

项目目的

本项目旨在通过引入异步状态机解析算法来优化经典的 Unix wc（字数统计）程序，而非单纯更换编程语言。该算法显著提升了处理速度，即使使用 JavaScript 实现，其性能也超越了 C 语言编写的原版 wc。

核心算法与项目结构

算法的核心是逐字节读取输入并传递给状态机，通过查表更新状态并计数。核心循环代码极其简洁，复杂性主要体现在状态机表的构建上。项目包含三个主要版本：

• wc2o.c：25 行的极简版本，仅支持 ASCII，用于直观展示状态机算法的核心逻辑。
• wc2.c：完整的 C 语言版本，构建了更大的状态机表以支持完整的 UTF-8 解析，并提供 -P 选项以测试 C 语言指针算术（如 *buf++）对性能的影响。
• wc2.js：JavaScript 实现版本。

解决传统 wc 的性能痛点

原版 wc 的性能瓶颈主要在于处理多字节字符（如 mbrtowc()）和空格判断（如 iswspace()）。许多重写项目通过仅支持 ASCII 来规避这些开销。本项目实现了完整的 UTF-8 支持并妥善处理无效输入，证明了状态机算法在处理复杂字符集时依然保持高效，无需“作弊”。

基准测试与性能表现

项目使用多种大文件（含非法字符的 PDF、纯 ASCII、随机 UTF-8、全单词、全空格）进行基准测试：

• 传统 wc：性能受输入内容影响极大。处理非法字符或 UTF-8 时速度显著下降，且 macOS 和 Linux 版本的表现差异明显。
• Wc2（状态机方法）：性能极其稳定，完全不受输入数据类型的影响。C 和 JS 版本的速度均全面超越原版程序。JS 版本得益于 JIT 编译，在此类简单计算算法上表现出极强的竞争力。

异步可扩展性

除了绝对速度，该算法的可扩展性更为关键。类似于 Nginx 使用状态机逐字节解析 HTTP 请求（无需像 Apache 那样缓冲整个请求头），以及 DFA 正则表达式相比 NFA 无需回溯缓冲，状态机解析器能够以流式方式逐字节处理数据，无需额外缓冲，极大地降低了内存占用，非常适合网络程序和高并发场景。

辅助工具

项目还内置了三个辅助工具以支持测试与验证：

• wctool：用于生成大型基准测试文件。
• wcdiff：用于对比不同 wc 实现的输出差异。
• wcstream：用于分块 fragmented 输入文件，曾借此发现 macOS 原生 wc 的一个 Bug。

React Lua 项目总结

项目概述

React Lua 是上游 ReactJS 17.x 到 Lua 的全面移植版本，针对性能和正确性进行了高度优化，并将上游类型转换为 Luau 类型注解。该项目是 roblox/react-lua 的 Fork，旨在解决原 Roblox 仓库只读、不接受社区贡献且未发布到公共注册表的问题，致力于成为 Roblox 及全球 Lua 社区的首选 React 方案。

项目结构与状态

项目采用 Monorepo 结构管理多个子包：

• 已移植核心包：包括 react（基础接口）、react-reconciler（核心协调逻辑）、scheduler（协作调度）、shared（共享工具）及测试相关的 react-test-renderer 等，构成框架基础。
• 未移植/不计划移植包：主要涉及 DOM/特定平台渲染（如 react-dom）、实验性 API 或 Webpack 专属包。
• DevTools：部分核心调试工具已移植，其余计划未来整体评估移植。
• 非上游专属包：包含 react-roblox（Roblox 渲染器）、react-shallow-renderer 以及 roact-compat（旧版 Roact 兼容层）。

与 Roact 的兼容与差异

项目旨在取代 Roact 并尽可能保持兼容。为适应 Roblox 生态和平滑过渡，保留了以下行为差异：

• Stable Keys：允许使用表键（table keys）作为子元素的稳定键。
• Context：移除已弃用的 _context，统一使用语义等价的 createContext。
• 类组件 Refs：允许 refs 指向实际的类组件实例（原 Roact 不支持）。
• Bindings：保留 Roact 特有的 createBindings 和 joinBindings 功能。

贡献指南

• 结构对齐：保持目录、文件名和符号名与上游一致。
• 溯源注释：镜像文件顶部需添加包含上游特定 commit hash 的链接注释。
• 偏差处理：因 Lua 特性（如数组索引从 1 开始）导致的逻辑修改，需在代码上方添加 -- ROBLOX deviation: 注释；纯语法差异（如使用 Polyfill 替代展开运算符）无需添加注释。
• 专属命名：Roblox 特有的新文件和测试文件需分别使用 .roblox.lua 和 .roblox.spec.lua 后缀。

《Hypermedia Systems》书籍概要

《Hypermedia Systems》一书旨在重新发掘赋予Web生命力的革命性思想，提出了一种更简洁的方法，利用htmx和Hyperview来构建Web及其他平台的应用程序，其核心是在不使用单页应用（SPA）框架的情况下增强Web应用。

核心理念与技术

该书倡导回归Web和超媒体驱动的应用（HDA） 的本质，通过轻量级的技术（如htmx）来简化开发流程，替代当前复杂且沉重的SPA框架，为开发者提供一条更直接、更易维护的路径。

目标读者

本书主要面向以下群体：

• 对现代Web开发实践的复杂性感到沮丧的开发者。
• 希望重新巩固Web基础知识的开发者。
• 期望将Web应用引入移动端的开发团队。
• 寻求了解超媒体和REST架构理念的普通程序员。

作者与编辑

• 作者：Carson Gross, Adam Stepinski, Deniz Akşimşek。
• 编辑：William Talcott。
• 前言作者：Mike Amundsen。

获取方式

该书提供多种获取途径，包括付费的精装版、平装版、EPUB和Kindle电子书（分别从亚马逊和Lulu购买），以及永久免费的在线阅读版本。

Pre-Scheme Restoration 项目概述

项目背景与启动

该项目获得 NLnet 基金会资助，核心目标是恢复并推广 Pre-Scheme 编译器，将其作为现代静态类型低级函数式编程语言的基础。

Scheme 语言简介

• 源自 MIT 的 Gerald Jay Sussman 和 Guy L. Steele Jr. 的研究，是 Lisp 家族的重要成员。
• 影响深远，标准化程度高，用于教学、研究及多个实现方案。
• 社区活跃，应用包括游戏开发（如 Lisp Game Jam）、分布式编程环境移植（如 Goblins/Hoot）、操作系统包管理（Guix）等。

Pre-Scheme 的由来与特性

• 作为 Scheme 48 的引导子集，由 Richard Kelsey 开发。
• 具备 Scheme 语法与宏支持、基于 Hindley/Milner 的静态类型系统、优化的 C 代码生成能力。
• 限制包括无垃圾回收、尾调用优化有限、不支持高阶功能（如一等续体、完整数值塔）。
• 长期仅用于 Scheme 48 引导，未广泛传播。

项目恢复的动机

• 低层系统语言（如 Rust、Zig）兴起，静态函数式编程需求增长。
• Scheme 社区对系统级开发兴趣提升，但缺少替代 C 的实用低层语言。
• Pre-Scheme 可填补 Scheme 与系统编程之间的空白，适用于虚拟机、操作系统、嵌入式开发等场景。

项目主要目标

1. 移植性：将 Pre-Scheme 编译器适配至多个 R7RS 兼容 Scheme 实现。
2. 工具链改进：优化开发工作流集成，改进文档与测试。
3. 语言增强：
   • 扩展类型系统以支持系统语言中常见的尺寸化数值类型。
   • 完善和类型（tagged unions）与模式匹配语法。
   • 将默认字符串类型改为长度前缀 UTF-8 表示。
4. 兼容性提升：改进与 R7RS 的兼容性，开发标准库。
5. 工具与文档：提供命令行编译器、Emacs 插件、教程及示例项目。

社区与进展

• 通过 Fediverse、RSS 订阅及 IRC 频道（#guile-steel）保持更新。
• 代码仓库托管于 Codeberg。

致谢

• 感谢 Christine Lemmer-Webber 的推动与社区支持。
• 特别鸣谢 Luis Filipe 提供的 CC BY-SA 4.0 授权插画。

通过ONNX Runtime与WebGPU实现浏览器端20倍速背景去除

核心优势

利用ONNX Runtime结合WebGPU和WebAssembly，相比多线程CPU性能提升20倍，相比单线程CPU提升550倍，在浏览器中直接实现交互式背景去除。

服务器端处理的挑战与客户端优势

传统方案依赖GPU服务器进行背景去除，但在浏览器中运行具有以下优势：

• 降低服务器负载和基础设施成本
• 通过分布式负载提升可扩展性
• 避免数据传输，更易符合数据保护政策
• 支持离线处理

影响客户端可行性的关键因素

1. 执行性能：交互式应用的关键，需控制在几秒内完成
2. 神经网络下载大小：影响首次使用体验

性能优化三大维度

• 首次执行：模型下载时间（受网络带宽影响）
• 首次运行：会话初始化时间（页面每次加载均需执行）
• 后续运行：推理时间（取决于网络结构和算子效率）

技术实现方案

模型转换与优化

1. 格式转换：PyTorch模型 → ONNX格式
2. 精度优化：
   • fp32（168MB）→ fp16（84MB）→ QUINT8（42MB）
   • fp16在视觉质量与性能间取得平衡，QUINT8因伪影问题被排除

执行环境

• ONNX Runtime Web：支持浏览器内推理
• WebGPU执行提供者：从v1.7.0开始支持，Chrome 113+、Edge 113+等浏览器默认支持

性能评估（测试设备：MacBook Pro 13" 2024, M3 Max）

首次使用（网络下载）

以84MB fp16模型为例：

• 10 Mbps带宽：约67秒
• 100 Mbps带宽：约6.7秒（典型场景）

首次运行（会话初始化）

后续运行（推理性能）

关键发现

• WebGPU显著优势：相比最佳CPU方案提升16-20倍，相比单线程CPU提升550倍
• fp16模型优势：下载体积减半，WebGPU上性能更优（GPU硬件对fp16有优化）
• 交互式体验：首次运行约300ms，后续运行约100ms，接近实时性能

实际应用与未来展望

当前已在@imgly/background-removal-js开源包中实现，适用于：

• 电商产品图实时背景去除
• 图像编辑应用
• 基于浏览器的图形设计工具

未来计划：

• 将背景去除功能移植到所有支持的平台
• 探索浏览器端视频背景去除的可行性

结论

WebGPU技术使浏览器成为真正的应用平台，在IMG.LY的设计工具中，既支持设备端、本地部署，也支持云端执行的神经网络方案。ONNX Runtime作为跨平台推理引擎，为这一技术栈提供了可靠基础。

Curl 在 Steam 游戏中的使用情况统计

本文介绍了开源项目 curl 在 Steam 游戏平台上的普及程度及最新的数据统计结果。

• 背景与早期统计：一年前，作者曾撰文统计使用 curl 的游戏，当时仅发现 136 款游戏在致谢名单中提及 curl。尽管当时许多人认为该数字被严重低估，但缺乏实际数据支撑。
• 数据来源与统计方法：近期，作者利用第三方数据库网站 SteamDB（该网站会提取并分析 Steam 游戏所使用的 SDK）的数据进行了重新核实。由于 SteamDB 的单一列表显示上限为 10,000 款游戏，作者通过按游戏发布年份进行过滤和累加，得出了最终的统计总数。
• 核心数据：在 SteamDB 数据库目前收录的 91,559 款 Steam 游戏中，共有 22,734 款游戏被识别出使用了 curl，占比高达 24.8%。
• 总结：作者对这一庞大的数据感到惊叹，并认为 curl 作为一个起初的“业余爱好”项目，能够被近四分之一的 Steam 游戏所采用，是一项极为出色的成就。

像1987年一样从头编写一个扫雷游戏

这篇文章详细介绍了如何利用古老的X11协议，不依赖庞大的GUI库，从零开始构建一个完整的扫雷游戏应用。

核心主题与背景

作者的动机源于看到微软官方扫雷应用体积庞大、包含广告和内购的现象。他计划沿用此前在X11和Wayland上创建极简GUI应用的经验，用类似的原则实现一个完整的游戏，以验证其是否也能达到数百MB的体量，并估算所需的工作量。

技术实现方法

1. 直接使用X11协议：作者选择直接通过Unix域套接字与X服务器通信，而不使用libX11、libxcb等常见库。X11协议自1987年诞生后变化不大，在各种Unix系统上普遍存在，且其2D应用模型无需直接操作GPU。
2. 编程语言：使用Odin语言实现，其标准库提供了必要的套接字和图像加载功能。但作者强调，这种方法同样适用于C或其他可进行底层套接字通信的语言。
3. 实现步骤概要：
   • X11认证：实现MIT-MAGIC-COOKIE-1认证协议，解析.Xauthority文件以获取令牌，确保在如Gnome等环境下正常运行。
   • 建立连接：打开Unix域套接字，完成X11握手，获取如根窗口信息、资源ID等关键连接信息。
   • 创建窗口与图形上下文：通过发送一系列X11请求来创建窗口、图形上下文，并订阅鼠标和键盘事件。
   • 加载与绘制资产：将包含所有游戏图形（如覆盖格、数字、地雷）的PNG精灵图嵌入程序。将其转换为X11要求的像素格式，上传至一个离屏像素图。随后，通过高效的CopyArea请求将精灵图的不同部分绘制到窗口上。
   • 事件处理与游戏逻辑：循环接收并处理X11事件（窗口曝光、键盘释放、鼠标按钮释放）。鼠标点击触发扫雷的洪水填充算法来揭开格子，按下Enter键可重置游戏。实现标准的扫雷规则：点击到地雷则失败，揭开所有非地雷格子则胜利。

关键技术与设计特点

• 轻量与独立：最终的可执行文件静态链接，大小仅约300 KiB，运行时堆内存使用恒定约1 MiB，与微软官方应用相比有数量级的优势。
• 性能与网络友好：资产只需上传一次到服务器（或GPU），后续绘制仅发送少量CopyArea指令，在网络环境下优势明显。
• X11认证：文章详细展示了如何解析二进制的.Xauthority文件以支持认证，这是一个常被库隐藏的细节。
• Odin语言特性：文中展示了Odin在错误处理（or_return, or_break）和内存管理（显式分配器、临时分配器）方面的特点。

最终成果与结论

作者成功实现了一个功能完整、体积小巧的扫雷游戏。其代码量约数百行，证明了使用原始X11协议创建复杂GUI应用是完全可行的，并且能产生极其精简的软件。

作者总结认为，X11虽然陈旧且有些繁琐，但它“不挡道”，一旦实现基础功能，开发者便可以专注于游戏逻辑。这种方法摆脱了对庞大库和框架的依赖，具备出色的可移植性和透明度。文章最后附上了完整的源代码以供参考。

文章《As you learn Forth, it learns from you (1981)》由David Sands撰写，主要介绍了Forth语言的核心特性、与Basic的对比、作者的个人实践以及Forth的基本编程概念。

Forth是一种可扩展的语言，其词汇能像人类知识一样被使用者不断定义和分层构建。与Basic相比，Basic虽然开发速度快，但系统不会从程序中学习，执行效率较低；而Forth采用“线程代码”结构，作为解释器与编译器的结合体，在编写速度接近Basic的同时，运行速度可快10至20倍。

作者最初受1980年《Byte》杂志专刊启发，尝试了多种Forth版本。在发现Stackworks的SL5版本在CP/M系统下存在局限性（如难以生成可烧录ROM的代码、磁盘操作慢等）后，作者基于North Star DOS的优势（磁盘速度快、内存管理灵活、支持多程序共存、便于编写从零地址开始的ROM代码等），利用Allen Ashley的PDS汇编开发系统，用Z-80语言编写了自己的Forth版本。该版本运行速度是原版的两倍，磁盘访问速度更快，并实现了编辑器、Forth解释器和机器码监控程序在内存中共存，大大提升了交互开发效率。

文章随后阐述了Forth的两个核心新概念：

1. 数据栈：所有数据操作都通过栈进行，变量主要用于存储地址。
2. 逆波兰表示法：运算符位于操作数之后。

文中详细介绍了Forth的各类词汇：

• 终端词：如.（打印）、CR（回车）、KEY（获取按键）、EMIT（输出字符）。
• 栈操作词：如算术运算符、DUP（复制栈顶）、SWAP（交换栈顶两项）。
• 系统变量与命令：如DP（字典指针）、DECIMAL/HEX（进制转换）。
• 定义词：以冒号:开头、分号;结尾，用于组合已有词汇创建新词汇。

文章还说明了如何创建常量（CONSTANT）、变量（VARIABLE），以及使用@获取值和!存储值的方法，并强调这些操作习惯后能提升编程流畅度，减少对传统变量的依赖。

在程序结构方面，Forth使用条件分支和循环，摒弃了GOTO。语法包括：

• IF...THEN 和 IF...ELSE...THEN
• DO...LOOP（计数循环）
• BEGIN...END / BEGIN...UNTIL（后条件循环）
• BEGIN...WHILE...REPEAT（前条件循环）

文末提醒了Forth编程的注意事项：由于编译后无法还原源码，需自行做好记录；磁盘空间以“屏幕”或文件段管理；栈操作错误（上溢/下溢）在编译模式下可能导致系统崩溃，因此系统未内置自动检测以防降低运行速度。其他可能引发崩溃的情况包括加载错误的磁盘文件、错误修改系统变量或Forth代码区等。

文章最后简要提及，与常进行浮点运算的Basic相比，Forth默认使用16位整数运算，速度优势明显；但可通过加载磁盘代码库来扩展浮点运算和三角函数等高级功能。

F (2006) 编程语言总结

语言概述

F 是一种纯函数式、连接式（concatenative）编程语言，最初作为 False 语言的扩展设计。它融合了 K3 的列表操作和 Joy 的 dip 组合子，支持浮点和符号数据类型，并在语法上强制一次性赋值。

核心特性

• 连接式范式：词（words）表示函数，词的连接表示函数的组合。在 F 中，所有操作本质上都是从 (环境; 栈; 队列) 三元组到三元组的函数映射。
• 纯函数式：无副作用。支持变量赋值但不允许重新赋值，无法存储动态状态。环境作为参数传递并作为值返回。
• K 动词集成：实现了所有 K 语言动词，部分作为底层原语，部分在预定义库（prelude）中派生。
• 单符号原语：所有原语均用单个符号表示，并遵循助记原则（如通用数学符号、K/False 映射、同音词或相关符号对）。

执行模型

解释器通过循环处理输入队列，直到队列为空。根据队列首项的类型（如整数、列表、未定义/已定义符号或函数），执行压入结果栈、创建变量、取值或函数应用等操作。

关键功能与机制

• 语义切换：支持 F 语义（使用名称时将其关联值压栈，需通过 ! 解引执行）和 Joy 语义（使用名称时直接执行其值），可通过全局变量 J 动态切换。
• 价（Valence）与电荷（Charge）理论：用于量化程序对栈和队列元素的消耗（价）与产生（电荷）数量。负值表示操作栈或队列的底部。
• 模式（Patterns）与 Shuffles：引入 XY 模式子语言，提供栈与队列之间的模式匹配与重构操作（如 ), (, }, {），可大幅简化代码，但会破坏严格的连接性。Shuffles 则是保留连接性的简化栈重排符号（如 ab-ba 表示交换）。
• 状态操作：提供 stack、unstack、queue、unqueue 等操作，结合通用的 continuation 原语 $ 来深度操纵栈和队列状态。

实现与变体

• 底层实现：F 的解释器由单个 K 语言脚本实现，包含全局状态（环境、栈、转移矩阵）、词法解析器及核心递归求值函数。
• G 语言变体：G 是 F 的一个变体，将 K 语言的副词（如 each, over, prior 等）直接实现为原语，并对部分操作符的符号映射进行了重新定义。

扩展到多TB数据集的经验教训

本文分享了作者在处理多TB级数据集时总结的经验，旨在帮助读者应对数据规模增长带来的挑战，并有效利用资源以达成目标。

核心原则

• 这不是一份严格的指南：旨在引入概念并解释其重要性，鼓励读者主动探索更优的工具。
• 算法优化优先：任何优化或扩展都无法弥补算法本身的缺陷。在考虑扩展前，必须先评估和优化算法。
• 目标：最大化利用现有资源，最快达成目标。

一、单机扩展

单机扩展主要关注通过并行计算来提升处理效率。

1. Joblib

• 用途：一个Python库，用于将代码并行运行。
• 特点：
  • 被scikit-learn、XGBoost等常用库使用，可靠高效。
  • 简单易用，几行代码即可将函数并行化到所有CPU核心。
  • 还具备缓存（memoization）和快速压缩持久化等优秀特性。

2. GNU Parallel

• 用途：一个强大的命令行工具，适用于预处理或数据提取。
• 特点：
  • 可在脚本外使用，用途广泛，甚至可以并行运行其他Python脚本。
  • 典型用例：同时解压大量文件、并行下载文件。
  • 默认使用所有CPU核心，并可通过SSH在多台机器上执行命令，能临时搭建计算集群。
• 注意事项：
  • 并行下载可能对服务器造成压力，甚至被视为DOS攻击，需负责任地使用。
  • 复杂的Bash命令难以维护，建议将其用于一次性任务，而非构建复杂的ETL流程。

二、多机扩展

当单机计算时间过长（例如任务需要数月或一年才能完成）时，应考虑多机扩展。

何时转向多机

• 关键指标：计算时间无法满足需求。
• 优势：
  • 性能与成本：与购买一台极其昂贵的强大单机相比，使用多台较小机器通常更具性价比。可以通过水平扩展近乎线性地提升CPU、内存和网络能力。
  • 网络与扩展性：可以利用多实例的网络带宽总和（如10 Gbit/实例），并通过增加实例数进行弹性扩展，不受单一实例的硬件上限约束。
• 重要提醒：仅在充分理解自身瓶颈后再进行多机扩展，避免过早过度工程化。有时，编写良好的命令行工具处理数据可能比整个Spark集群更快。

不同计算模型的工具选择

1. 令人尴尬的并行工作负载（易于并行化，任务间独立）

• 推荐工具：AWS Batch（或AWS Lambda）。
• 优势：可扩展、支持竞价实例以大幅降低成本，适合一次性任务。
• 主要瓶颈：通常不是计算速度，而是数据读写速度（如数据库或S3的吞吐量限制）。

2. 分析型工作负载（需对单一数据集进行大量交互式操作）

• 主要工具：Dask 和 Spark。
• Dask：
  • 优点：安装设置简单快速，API与Pandas/NumPy高度相似，对数据科学家友好，与PyData生态系统集成良好。
  • 缺点：成熟度相对较低，可能遇到偶发性错误或性能问题，不太适合超长时间运行的计算。
• Spark：
  • 优点：生态系统非常成熟稳定，许多大型组织已有投资和基础设施。
  • 缺点：设置比Dask复杂，学习曲线较陡。
• 选择建议：
  • 小团队/初创公司：建议先尝试Dask，可快速验证用例，降低入门门槛。
  • 已有大数据基础设施的大型组织：通常建议继续使用Spark，除非有特别理由。但也可以同时尝试Dask。

结论

管理多TB数据集需要深入理解数据和工具。通过Joblib和GNU Parallel优化单机资源；在必要时，使用AWS Batch、Dask或Spark进行多机扩展，以应对不同工作负载。成功的关键在于首先优化算法，并根据实际场景主动探索和选择合适工具。战略规划和资源管理与原始计算能力同等重要。

气动管技术在19世纪末至20世纪中期曾被寄望于革新多个行业，用于高效运输物品如现金、文件和邮件。然而，到20世纪中后期，该技术因成本、数字化和更便捷的运输方式而衰落，但在医疗领域却持续应用并复兴。

在医院中，气动管系统自1920年代起用于传送医疗记录、处方和标本，1960年代成为标准，显著提高了护士工作效率，减少了非护理任务时间。如今，它已成为新建医院的必备设施，类似于家用电器，主要用于运送实验室标本（占60%）、药品（30%）和血液产品（5%）。

技术方面，气动管使用直径6英寸的管道，以12-16英里/小时的速度运送最多5磅的胶囊，以保持标本完整性。系统从固定路线演变为网络化结构，类似于列车系统，由软件实时监控和管理，运行24/7。制造商参与医院早期设计，优化布局以匹配临床需求。

具体案例包括宾夕法尼亚大学医院每天处理近4000个标本，系统覆盖12英里管道，每天完成6000多次交易；密歇根医学院用于核医学，在铅衬胶囊中运送放射性材料，将运送时间从步行5-8分钟缩短至不到一分钟。

这些系统规模庞大，如密歇根医学院有150-200个站点、30个吹风机和150多个传输单元，每天运送约30000磅物品。医院管理者视气动管为如水电般的公用事业，对患者护理至关重要，它能快速运送标本和药品，减少等待时间，提升医疗服务质量。

OSRD (开源铁路设计师) 总结

项目概述

OSRD（Open-Source Railway Designer）是一款专注于铁路基础设施设计、容量分析和时刻表编制的开源 Web 应用程序。

核心功能

• 铁路设计：支持铁路基础设施的设计与列车时刻表的编制。
• 容量分析：提供运行冲突检测功能，并支持铁路容量的可视化展示。
• 短期规划：能够自动将新列车调度并添加至现有的列车时刻表中。

技术与生态特性

• 互操作性：系统专为互操作性设计，支持自定义的基础设施格式与信号系统协同工作。
• 开源开发：采用完全开源的模式，允许任何人自由使用、开发和分发该软件。

项目治理

OSRD 项目由 OpenRail Association（开放铁路协会）负责公开设计与托管，保障项目的公共属性与规范发展。

这篇文章探讨了从数字签名中恢复公钥的可能性，分析了多种古典及后量子签名方案的这一特性。

ECDSA：可以非常容易地从单个有效签名中恢复公钥。通过数学计算可以直接推导出公钥。

RSA：需要两个签名才能恢复公钥。通过计算签名和消息对应数值之间的大指数运算（例如使用扩展欧几里得算法），可以恢复出模数n，从而得到公钥。

Schnorr签名：其公钥是否可恢复取决于签名的具体形式。如果签名包含承诺值R，则可恢复公钥；如果只包含挑战值c，则无法恢复。

后量子方案：

1. Dilithium：由于在计算挑战值时哈希了公钥，公钥无法恢复。即使忽略此步骤，仅从签名中恢复公钥也需要解决大型线性方程组。
2. SPHINCS+：同样因为哈希了公钥而无法直接恢复。然而，通过侧信道攻击（如时序分析）可能泄露足够的信息来重建Merkle树根（即公钥）。
3. UOV：公钥可以恢复。虽然单个签名信息不足，但收集足够数量（约等于多项式变量数）的消息/签名对后，可以通过多项式插值法恢复出公钥多项式系统。

结论：不同签名方案在公钥可恢复性上差异显著。作者指出，公钥本质上并非秘密，即使某些方案在代数上不泄露公钥，验证逻辑中的侧信道也可能导致泄露。因此，在设计协议时应充分考虑这种风险。

Unique3D: 从单张图像生成高质量3D网格

核心概述

Unique3D是一个能够从单张图像高效生成高保真、多样纹理的3D网格模型的技术。其官方实现可在约30秒内完成从单视图图像到3D网格的生成。

主要特点与演示

• 生成质量：支持生成高保真且纹理多样的网格。
• 速度：推理速度快，Gradio演示速度最快。
• 多种演示入口：提供Gradio演示、HuggingFace演示和在线演示（aiuni.ai）。当Gradio演示拥挤时，可使用更稳定但稍慢的在线演示（需通过Discord获取邀请码）。
• 跨平台支持：目前主要支持Linux系统（适配Ubuntu 22.04.4 LTS和CUDA 12.1），Windows安装方法可通过相关Issue（issues/15）参考，社区提供了详细的Windows安装脚本和步骤。未来计划包括Windows支持、Docker支持和ComfyUI集成。

安装与使用

Linux环境

1. 使用Conda创建Python 3.11环境。
2. 安装Ninja、指定版本的diffusers和mmcv-full。
3. 根据requirements.txt安装其他依赖。
4. 从HuggingFace或清华云盘下载权重文件，解压至ckpt/目录下。

Windows环境

1. 可能需要Visual Studio Build Tools。
2. 创建并激活Conda环境。
3. 下载适用于Python 3.11的triton wheel文件。
4. 运行提供的批处理脚本install_windows_win_py311_cu121.bat进行安装。
5. 创建输出文件夹（如F:\tmp\gradio），然后运行本地Gradio演示。

运行推理

准备好权重后，运行命令 python app/gradio_local.py --port 7860 即可启动本地交互式推理。

获得更好结果的建议

输入图像的质量对输出结果有显著影响：

1. 构图：由于模型训练时对网格进行了归一化，输入图像应包含物体的最长边，否则可能导致结果被错误压缩。
2. 视角：模型对图像朝向敏感。正交正面视角、姿态自然的图像通常能产生最佳重建效果。
3. 遮挡：图像中物体的遮挡物越少越好，因为四个视角难以覆盖被遮挡的完整物体。
4. 分辨率：尽可能使用高分辨率的输入图像。

项目状态与未来

• 状态：该代码仓库仍在建设中，未来将上传权重、提供详细教程、增加更多本地演示细节、支持ComfyUI、Windows和Docker，并发布训练代码和更稳定的法线重建功能。
• 愿景：团队的目标是创建具有3D概念的4D生成模型，Unique3D是第一步。他们欢迎通过邮件或Discord进行研究合作和讨论。

致谢与引用

该项目借鉴了Stable Diffusion、Wonder3d、Zero123Plus等多个开源项目的代码。如果使用Unique3D，请引用其arXiv报告（ID: 2405.20343）。

EasyOS是一个实验性的Linux发行版，由Barry Kauler在2018年至2025年期间开发并维护。其官方网页提供了全面的文档，旨在帮助用户理解、安装、使用和参与该系统的开发。

主要特点与技术细节 EasyOS的设计理念与其他发行版不同，它倡导淘汰传统的ISO安装格式，转而采用更灵活的方式。其核心优势在于对“Easy Containers”的深度应用，这为系统提供了高度的安全性和隔离性，尤其体现在“超安全网页浏览”等方面。系统包含自己的包管理概念，并支持便捷的系统更新、版本升降级以及故障修复。

内置应用与功能 EasyOS集成了多个特色应用以简化使用：

• EasyShare：用于极其简单的网络文件与打印机共享。
• BluePup：一个易于使用的蓝牙管理工具。

开发支持 该系统鼓励社区参与开发，其文档涵盖了为EasyOS编写代码的指南、从源代码编译系统或应用程序的方法、调试指南，以及将系统翻译成不同语言的说明。

详尽的安装与部署教程 官方文档提供了极其详尽的安装指南，覆盖了多种硬件和配置：

• 支持安装到硬盘或新的SSD。
• 支持克隆现有安装或进行“Easy Frugal Installation”（简易安装）。
• 兼容Limine引导加载程序，也支持安装到已使用rEFind引导管理器的PC上。
• 提供了将系统写入闪存盘的教程。
• 包含在容器内运行Linux发行版的说明。

总结 EasyOS是一个功能全面、文档完善的实验性Linux发行版，专注于容器化技术、安全性与用户易用性。它既为终端用户提供了开箱即用的特色应用，也为开发者提供了深入参与的技术文档和指南。

文章标题指出，Bun在解码Base64方面比Node.js 22快得多，但两者都依赖于同一个底层库。文章内容显示了一个错误消息，建议用户禁用隐私相关扩展并重试，以解决在x.com上的问题。内容本身不提供关于Bun或Node.js性能比较的进一步细节或技术解释。

《计算帝国：1500年以来的技术与权力谱系》内容概述

《计算帝国：1500年以来的技术与权力谱系》（Calculating Empires: A Genealogy of Technology and Power Since 1500）是一个旨在探讨过去五个世纪中技术发展与权力结构演变之间深刻联系的项目或展览。提供的内容主要为其网站导航与内容目录，展示了该项目的核心框架与研究维度。

项目结构与核心内容

1. 导览与使用指南

项目提供了语音导览（Audio Tour） 和地图阅读指南（How to read the map），旨在帮助用户直观地理解项目的视觉化呈现方式（如知识地图）并引导用户进行探索。

2. 核心主题（Topics）

主题是项目的核心部分，系统性地划分为两大领域，详细拆解了技术在不同层面的应用与影响：

通信与计算（Communication and Computation）

聚焦于信息的处理、组织与传输技术，具体包括：

• 通信与网络：通信设备、用户接口、通信基础设施。
• 数据与算法：数据组织、算法、模型。
• 计算载体：人工计算者（Human computers）、硬件、非传统计算。

控制与分类（Control and Classification）

探讨技术如何被应用于人类社会、自然环境以及国家机器的管理、规训与扩张，涵盖范围极广：

• 人类与社会规训：时间管理、教育、情感与智力评估、人体、生物识别、医疗、监狱、警务、边境控制、官僚机构。
• 宏观权力与经济：殖民主义、政治与经济系统、生产、能源与资源分配。
• 自然与空间表征：岩石圈、大气圈与水圈、生物圈、天体圈、空间表征、建筑。
• 监控与武力：监控基础设施、军事学说、军事系统。

3. 关于项目（About）

提供项目的背景信息、研究初衷及相关介绍。

总结

该项目通过高度结构化的主题分类，全景式地梳理了自1500年以来，从基础通信、算法计算到社会监控、资源管理及军事扩张等各类技术手段，如何被用于构建、维持和扩张帝国与权力网络。其内容架构不仅展示了技术工具的演进，更深刻揭示了技术在人类分类、社会控制与全球权力重塑中的核心作用。

Midday：开源智能业务运营工具

Midday 是一款开源工具，旨在帮助企业更智能地运营。它通过整合发票、交易、时间追踪和财务洞察等功能，减少行政负担，让用户专注于核心业务。

核心功能

• 自动同步交易：自动拉取并统一所有进出账支付记录。
• 在线发票支付：客户可在线支付发票，付款自动跟踪。
• 自动对账：自动分类交易并匹配付款、收据和交易记录，确保账目准确。
• 时间追踪：跟踪可计费工时。
• 财务洞察：提供财务分析和见解。
• 账目导出：生成清晰账目供会计使用。

工作原理

1. 交易统一：所有业务支付自动从连接账户同步。
2. 发票支付：在线支付发票，付款自动记录。
3. 自动对账：交易自动分类和核对，保持记录准确。

节省时间

• 减少收据追踪：每周节省45分钟。
• 简化交易整理：每周节省1小时。
• 快速发票准备：每周节省1-2小时。
• 账目准备：收据、发票和交易自动整理，账目随时可用。

集成能力

可连接银行、电子邮件、支付和会计软件，几分钟内完成设置，与现有工具无缝协作。

当前是开展服务业务的良好时机

服务业务的定义

服务业务是指企业直接销售其工作产出，而非销售产品。例如：牙医、水管工、设计机构、泳池清洁工和咨询顾问等都属于服务业务。与之相对的是产品业务，即企业开发产品并将其销售给客户。例如，牙医需要购买诊所管理软件和清洁工具（产品），但患者为其定期检查服务（服务）付费。

传统观点：不应开展服务业务

传统上，技术从业者若想建立有价值的企业，通常应避免服务业务。因为全球市值前列的公司大多为产品公司，服务公司（如埃森哲）排名相对靠后。产品公司（尤其是软件产品）凭借规模化经济和低边际成本，能实现高利润率，因此更受投资者青睐。

建议的产品公司创建路径通常是：与用户沟通以确定产品方向 → 构建产品 → 销售产品，并尽可能同步进行以减少风险。然而，此路径失败率高，多数产品因无实用价值而难以销售，即使成功的企业也常需多年才能见效。

当前软件产品市场的挑战

如今，软件产品市场竞争极为激烈。以2010年为例，即使在小众垂直领域创立SaaS公司也可能成功，但现在每个细分市场已有多家成熟竞争者，单一产品策略难以突破。

复合型创业公司的选择与局限

复合型创业公司（同时开发多个互补产品）被提出作为解决方案，如估值140亿美元的Rippling。但此模式初期需投入大量资源（如Rippling启动时已有40名工程师），运营复杂且成本高昂，不适合所有创业者。

服务业务的优势与增长方式

服务业务能规避产品市场饱和问题，且无需研发阶段：一旦找到首个客户即可开始盈利。与潜在产品用户沟通时，可直接为他们解决问题并收费（费率可高于产品销售）。

服务业务的常见增长方式包括：

1. 提高收费：提升单位时间收益。
2. 雇用团队：通过雇佣他人出售时间。
3. 产品化：将部分服务标准化为产品（如Zenefits最初手动处理福利登记，后通过网站使之产品化）。
4. 自动化：利用技术减少时间投入。

AI为服务业务带来的关键机遇

当前适合开展服务业务的最重要原因在于AI驱动的自动化。尽管AI目前仅能执行基础任务，但其进展为半自主模式创造了可能：AI在人类监督下完成工作以确保质量。此模式特别适合服务业务——既能接近产品业务的利润率，又保留了服务模式端到端解决方案的特性。

结论

服务业务因无需研发阶段而易于启动，但传统上增长受限于提高收费、雇用或产品化等途径。若AI持续进步但尚未达到超人类水平（即处于半自主阶段），它将为服务业务提供大量自动化机会，突破传统增长限制，实现兼具灵活性与高利润的发展。

利用自由形式网页编辑器打造我的互联网角落

互联网三十年，其魔力已基本丧失。当前的网络体验被短暂“内容”、广告和少数平台所主导，缺乏个性。个人网站正成为历史遗迹，原因之一是制作一个手工网站需要过多的编码知识。我们亟需一种像制作PPT一样简单的工具，让个人网站复兴。

自由形式网页的理念

自由形式网页编辑器应具备以下特点：

• 绝对自由定位：可在页面任意位置放置元素，无需编写标记。
• 所见即所得：可直接拖放图像、文本、音频和视频到页面。
• 即时发布：创作完成后可快速部署至网络。

过去的工具如Microsoft FrontPage、Flash已过时，而现代的Squarespace等工具虽支持可视化编辑，但主要面向商业网站，而非个人创意表达。

核心工具：Hotglue

Hotglue 是一款开源的“所见即所得”网页制作工具，尽管已停止更新多年，但其核心理念极具启发性。

• 特点：界面简洁，提供完全空白的画布；可实时拖放元素并立即保存发布；提供对齐网格辅助。
• 优势：创作流程快速直观，无模板限制，非常适合制作视觉化、个性化的页面，如电子存档、视觉剪贴簿或作品集。
• 局限：默认不响应移动端；移动端操作不便；缺乏页面密码保护；音视频需手动嵌入；缺少图片替代文本。

受众与价值

自由形式网站适合以下人群：

• 思维更依赖视觉草图而非线性文档的人。
• 希望以非盈利目的创作和整合信息的人。
• 认可HTML/CSS/JS作为互动、自由格式文档潜力的人。 它旨在对抗当今网络的单调性，鼓励创建低结构化、高个性化的数字花园，而非被搜索引擎优化和广告逻辑支配的内容流。

其他替代方案与生态

• 其他工具：如 Tumult Hype（类似Flash的Mac应用）、MMM.page、Kinopio 等，提供了更现代但理念相似的自由创作体验。
• 发现机制：此类网站不依赖SEO，更适合通过网页环和联邦宇宙进行小众传播。
• 反对意见与回应：针对“不利于移动适配”、“生成代码质量差”等观点，作者认为在个人创作语境下，自由表达优先于技术规范。

结语

Hotglue 是一个概念的证明，证明了制作轻松、个性化网站的可能性。虽然存在局限，但它呼唤一个更野性、更少约束的网络空间的回归，让每个人都能像制作剪贴簿一样，轻松地构建属于自己的在线角落。

旋转曲线在远距离处保持平坦是外层天文学中最著名的发现之一，由薇拉·鲁宾及其合作者在1970年代末确立。早期的个案被视为偶然现象，但鲁宾通过对上百个螺旋星系的重复观测表明，平坦旋转曲线普遍成立，从而催生了现代暗物质范式。

旋转曲线本应下降：基于可见物质（恒星与气体）的质量分布，旋转速度应在光度分布边缘达到峰值后随距离递减。然而观测数据显示，在NGC 6946等星系中，旋转曲线在超出恒星边缘后仍保持平坦，暗示存在暗物质或需修正引力理论（如MOND）。

早期光学观测的旋转曲线延伸范围有限，质量不符约为两倍。原子气体通常延伸更远，提供了更远距离的示踪。阿尔伯特·博斯马等人的研究表明，平坦旋转曲线在气体分布范围之外依然持续。例如NGC 2403的旋转曲线在20个盘标长处仍保持平坦，迫使人们假设暗物质晕远大于星系本身，且其边界难以探测。

近年来的弱引力透镜技术为研究星系引力势提供了新途径。布劳弗等人基于KiDS巡天数据发现，径向加速度关系延伸至极低加速度区域，暗示旋转曲线在极远距离仍保持平坦。博士后托比亚斯·米斯特尔发展了一种改进的分析方法，通过对孤立星系的透镜数据进行堆叠，将旋转曲线的探测范围进一步推远。

米斯特尔等人的最新研究显示，孤立星系的平均旋转曲线在远超一百万光年的距离上仍保持平坦，且未见终止迹象。该距离已相当于银河系与仙女座星系之间的间隔。相比之下，单个星系UGC 6614的射电观测旋转曲线延伸约60千秒差距，而透镜数据将其外推了一个数量级。

这一结果对暗物质理论构成挑战：根据物质成团模型，UGC 6614质量的星系其暗物质晕维里半径约为300千秒差距，理论上应能观测到晕边界，但透镜数据未显示任何转折迹象。虽然存在“双晕项”（其他星系贡献的质量）可能干扰，但其精细调谐难以解释如此平坦的旋转曲线。

在MOND框架下，无限延伸的平坦旋转曲线是孤立星系的自然预言，环境场效应（宇宙其他质量的影响）应最终限制旋转曲线延伸，但通过选择孤立星系可最大程度推迟该效应。目前观测与MOND的预言一致，而暗物质解释则需额外假设。

总之，平坦旋转曲线已成为与开普勒定律类似的自然法则，表明星系遵循独特的动力学规则。最新透镜观测将其证实范围扩展至百万光年尺度，这与MOND的预期高度吻合，却对标准暗物质模型提出了严峻质疑，暗示现有理论可能需要根本性修正。

AdonisJS 概述

AdonisJS 是一个专为 Node.js 设计的 全栈 TypeScript 框架。它旨在通过表达力强的 API、清晰的约定和内置的全套工具，提升开发体验，让开发者能够高效、愉快地编写代码。

核心特点与优势

• 开发体验优先：框架提供了“开箱即用”的功能，简化常见任务（如数据库设置、身份验证），同时保持强大的功能和灵活性。
• 全栈与类型安全：它是 JavaScript 生态中少有的真正的全栈框架，支持从前端到后端的开发，并原生支持 TypeScript，提供类型安全。
• 功能完备：内置了构建应用所需的大部分功能，包括强大的开发者工具链、官方维护的常用功能包，以及灵活的架构，支持从原型到生产的全过程。
• 成熟稳定：该项目已持续发展超过十年，注重长期维护和稳定更新，采用 MIT 许可证开源。
• 灵感来源：其设计哲学类似于 PHP 生态中的 Laravel 或 Ruby on Rails，强调“电池已包含”的集成式框架理念，开发者认为它比 Express.js 等更底层的库更易用、结构更清晰。

社区与生态

• 用户反馈：众多开发者对其赞赏有加，主要评价包括：
  • 结合 Inertia.js 和 React 等前端框架的体验出色。
  • 认为它是 Node.js 世界中结构良好、开发体验优秀的全栈解决方案。
  • 对于喜爱 Laravel 的 PHP 开发者而言，AdonisJS 提供了相似的开发风格和工具（如 Ace CLI 之于 Artisan）。
• 社区支持：拥有活跃的 Discord 社区供开发者交流。
• 合作伙伴：由多家公司和个人赞助支持，以确保其独立发展和持续维护。

学习资源

框架提供了多种入门和学习途径：

• Adocasts：提供视频教程和课程。
• AdonisJS Plus：提供预构建的全栈组件和启动套件。
• 官方文档：全面且编写清晰的文档。
• 社区：通过 Discord 社区获取帮助。

NodeSwift 概述

项目目的

NodeSwift 是一个桥接 Node.js 与 Swift 代码的工具，实现两者的双向调用。主要应用场景包括：

• 在 Electron 应用中调用原生 macOS API 和 SwiftPM。
• 在 Swift 程序（如 macOS/iOS 应用或 Vapor 服务器）中使用 NPM 生态 API。
• 使用 Swift 编写性能关键模块以加速 JavaScript 代码。

核心特性

• 内存安全：依托 Swift 的内存安全机制和自动引用计数（ARC），开发者无需像使用基于 C 的 Node-API 那样手动管理内存。
• 简单灵活：采用渐进式披露设计，提供从基础到高级的 API 以满足不同开发需求。
• 原生体验：API 设计高度契合 Swift 编程习惯，例如通过遵循 NodeClass 协议暴露 Swift 类，并利用动态成员查找等特性简化互操作。
• 功能全面：在 Swift 中可访问完整的 Node.js API，涵盖 JavaScript 对象操作与事件循环调度。
• 跨平台支持：兼容 macOS、Linux、Windows 以及 iOS。

结构与工作原理

• 项目结构：一个 NodeSwift 模块由位于同一目录下的 SwiftPM 包和 NPM 包组成，两者均将 NodeSwift 作为依赖。
• 通信机制：Swift 包被编译并暴露为原生 Node.js 模块，供 JavaScript 代码通过 require 引入。双方底层通过 Node-API 进行通信，Swift 端由 NodeAPI 模块进行封装。

替代方案对比

• WebAssembly (WASM)：WASM 运行于虚拟机中，无法访问原生操作系统 API；NodeSwift 直接在裸机上运行，性能更佳且能调用原生 API。但若目标运行环境是浏览器，则应选择 WASM，因为 NodeSwift 依赖 Node.js 运行时。
• 其他 NAPI 封装（如 NAPI, NAN, Neon 等）：基于 C 的 NAPI 可移植性强但缺乏内存安全。NodeSwift 更适合需要在 Apple 平台上增强 JS 工具、将 Node.js 集成到现有 Swift 项目中，或偏好使用 Swift 语言的开发者。