## 规则学：一门新的科学
规则学，由作者创造的一个术语，是一门基础性的新科学，专注于研究简单规则的行为——本质上，当你建立一个系统并让它按照既定指令运行会发生什么。它不同于计算机科学（专注于*设计*程序）和传统数学（证明框架），而是侧重于*观察*规则*做什么*。
这种探索，作者已经实践了四十年，从具体的规则（如细胞自动机或图灵机）开始，并推广到更广泛的类别，可视化和测量它们的行为。一个核心挑战是**计算不可约性**——有时，了解规则结果的唯一方法就是简单地运行它。
规则学是理解复杂性的基础，既是模型的来源，也是一种“挖掘”计算宇宙以寻找技术应用的方法。它是一门实验科学，由观察驱动，但也具有理论性，探索计算上*可以*生成什么。作者强调简单性和明确的可视化是成功规则学研究的关键，这得益于像Wolfram语言这样的工具，它允许轻松地表示和执行规则。最终，规则学有望成为一个广阔、开放的科学探索领域，对基础理解和未来技术都具有影响。
每日HackerNews RSS
## 鲁里学：关于沃尔夫拉姆的新“科学”的讨论
斯蒂芬·沃尔夫拉姆最近推出了“鲁里学”，即研究简单规则的行为以及它们产生的复杂性。这在黑客新闻上引发了热烈的讨论，主要集中在它是否是一个真正的新领域，还是仅仅是对现有概念的重新包装。
许多评论员指出它与计算机科学（与艾伦·图灵早期关于模式形成的研究相关联）、数学（约翰·康威的生命游戏）和物理学（乌拉姆和冯·诺依曼关于细胞自动机的研究）等既定学科的相似之处。一些人戏称这“本质上就是哲学”。
一个反复出现的批评集中在沃尔夫拉姆自我推销的倾向以及为现有想法发明新术语上。人们对缺乏可证伪的标准以及除了理论探索之外的实际应用表示担忧。另一些人则为沃尔夫拉姆辩护，承认他的才智以及探索计算系统的潜在价值，即使他的方法非常规。
尽管存在怀疑，但许多人发现核心思想引人入胜，特别是通过简单规则理解复杂系统的潜力。这场讨论凸显了关于涌现、计算以及宇宙基本组成部分的本质的持续争论。
## zlob：更快、POSIX 兼容的 Globbing 库 zlob 是一个为 C、Zig 和 Rust 设计的高性能 globbing 库，旨在显著改进标准的 `glibc` 实现。`glibc` 的 `glob()` 已过时且速度慢，尤其由于强制排序和有限的功能支持。 zlob 旨在 100% POSIX 和 `glibc` 兼容，同时提供高达 10 倍的速度提升（通常快 1.2-1.7 倍）。它支持现代功能，如递归模式 (`**/*.c`)、大括号扩展 (`.{a,b}/*.c`)、`.gitignore` 文件和 bash extglob 语法。 主要功能包括 SIMD 优化、直接使用 `getdents64` 系统调用以加快目录列表的速度，以及具有路径长度信息的明确定义的 API，方便 FFI 集成。zlob 分析模式以进行优化，预编译常见情况（如带有扩展名的递归搜索），以实现最大效率。 针对 `glibc`、Rust 的 `glob` crate 和 Node.js 的 `fs.glob` 进行全面测试，确保 100% 兼容性。它作为 C 库、Zig 库和 Rust crate 提供，需要 Zig 工具链进行编译。
## 新的 Globbing 库：Zlob.h
一个新的 C 库，**Zlob.h**，旨在提供比 glibc 等标准选项更快、更全面的 globbing 功能。它与 POSIX、glibc 兼容，并支持 C、Zig 和 Rust 的现代 globbing 格式。
讨论的重点在于，改进现有的库（如 glibc）是否比创建新的库更好——一些人认为快速解决方案比冗长的贡献过程更具吸引力。用户还争论了 glob 模式中大括号扩展 `{a,b}` 的行为，并指出 Bash 和库的预期行为之间的差异。
其他评论涉及库的许可、可读性（指出 README 中的错别字），以及一个有趣的观察，即错别字可能表明是人类编写的，而不是 LLM 生成的。有人提出了关于在字符串列表而非直接在文件系统上进行 globbing 的问题，并建议使用 `fnmatch`。
经过18个月的停滞，街机博主带着对雅达利标志性街机游戏《Battlezone》制作过程的迷人一瞥回归。新发掘的1980年末的影像展示了雅达利位于加利福尼亚州桑尼维尔工厂的装配线，揭示了这些复杂机柜出人意料的流畅制造过程。
《Battlezone》在当时是一项技术成就，它推动了雅达利的矢量图形技术，创造了一种由埃德·罗特伯格领导的沉浸式第一人称坦克模拟游戏。机柜独特的潜望镜取景器最初备受争议，但却是这种体验的关键，并带来了重大的制造挑战。工业设计师迈克·奎里奥详细介绍了对其原始设计的修改，包括项目经理要求的添加以及为较矮玩家提供的可拆卸踏板。
影像突出了熟练的工人高效地搬运和包装这些机柜——1980年8月至1981年3月期间共生产了超过13,000台——使用工业吸盘轻松起吊。这是对这些“黄金时代”街机机器背后的人性化的一面难得的观察，提醒我们它们是经过精心制作的实物，而不仅仅是抽象的产品。
## Atari Battlezone 生产画面引发怀旧与AI讨论
最近分享的一段1980年Atari Battlezone街机柜生产线的画面，正在吸引Hacker News社区的关注，引发了怀旧之情和关于其真实性的争论。许多评论者回忆起年轻时玩这款游戏的回忆，回忆起其沉浸式的矢量图形和标志性的声音——甚至分享了一个基于浏览器Defender音效引擎的链接。
这段视频的来源已被CBS新闻团队证实，解决了最初对其为AI生成的担忧。然而，关于画面看似较高的分辨率以及员工与摄像机的异常互动不足的讨论仍在继续。
除了游戏本身，这篇帖子还引发了关于那个时代美国制造业、定制印花T恤的普及，以及在日益复杂的AI时代对在线媒体日益增长的不信任的讨论。这段画面就像一个迷人的时间胶囊，促使人们反思过去街机游戏和制造业的时代。
登录
## WebView性能问题与替代方案
一篇Hacker News讨论强调了Android平台上，WebView（用于在应用内显示网页内容）与完整的Chromium浏览器之间的显著性能差异。WebView较慢，因为当应用需要同步UI元素时，必须与Android渲染API集成，这会影响动画效果。
多位评论员指出，Facebook将系统WebView替换为自定义Chromium实现，以此证明了这个问题，详情请参见链接的Facebook工程博客文章。虽然系统WebView旨在实现资源共享和内存效率，但性能方面的权衡是巨大的。
对话还涉及更广泛的问题：企业优先考虑封闭生态系统而非Web标准，静态编译的内存效率低下（例如Electron），以及可能的解决方案，如Tauri和Chromium Embedded Framework (CEF)。用户可以选择在Android上将Firefox设置为系统WebView，但像Facebook这样的应用不会使用此设置。最终，许多人对这些问题仍然存在，尽管浏览器开发投入了大量资源，感到沮丧。
## Android 开发工具包 (AADK) 概要
AADK 是一个基于 gRPC 的 Android 开发框架，优先支持 ARM64 工作流。它被设计为多服务架构，GTK UI 和 CLI 作为轻量级客户端，将所有核心逻辑委托给后端服务。这些服务 – 包括 JobService（事件总线）、WorkflowService（流程编排）、ToolchainService（SDK/NDK 管理）、ProjectService（项目脚手架）、BuildService、TargetService 和 ObserveService（运行历史/制品） – 通过 gRPC 进行通信。
主要特性包括具有历史记录和实时流的作业管理、工具链处理（带有 ARM64 SDK/NDK 的自定义目录）、项目模板支持以及与 Cuttlefish 的集成以进行模拟。ObserveService 提供运行历史和输出清单，用于仪表板。
该系统仅支持 Linux ARM64 (aarch64)；x86_64 故意不支持。配置和状态通过 JSON 文件管理，系统不捆绑第三方工具链，而是按需下载。一套全面的 CLI 命令和 GTK UI 提供对系统功能的访问。其核心目标是提供高效的 Android 开发工具，特别是针对 ARM64，补充现有的工具，如 Android Studio。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
展示 HN: ARM64 Android 开发工具包 (github.com/denuoweb)
18 分，denuoweb 2 天前 | 隐藏 | 过去 | 收藏 | 2 评论
GUI 优先，多服务 gRPC 框架，用于在 AArch64 系统上进行 Android 开发工具包风格的工作流程。
lukevp 1 天前 [–]
这到底是什么？什么是 Android 开发工具包风格的工作流程？使用这个领域之外的术语会有所帮助，以便更容易理解其目的。回复
boberoni 1 天前 | 父评论 [–]
“devkit”对我来说不是一个熟悉的术语，但看起来这个项目是一个用于在 Linux arm64 上进行 Android 开发的 GUI 应用程序。
Google 官方支持 Android Studio、模拟器、SDK 等，用于 macOS arm64 和 Linux x86_64，但不支持 Linux arm64。这个项目填补了这一空白。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## MirageOS 并发：Lwt vs. Fibers
MirageOS 是一种独特的操作系统内核，采用完全事件驱动的方法，摒弃了传统的抢占式线程。这需要抽象来管理事件回调，目前 Lwt – 一个采用单子风格的 OCaml 线程库 – 是主要的解决方案。虽然有效，但 Lwt 的单子特性需要代码适配，并且为阻塞操作引入了闭包分配，这引发了 OCaml 社区的讨论。
像通过 Lwt_fiber 库提供的限定连续 (delimcc) 这样的替代方案，提供了一种潜在的更轻量级的方法，使用可重启的异常。比较 Lwt 和 fibers 的基准测试表明，对于简单的阻塞场景，fibers 最初的性能*不如* Lwt，因为异常处理的开销。然而，随着更深的调用栈和减少的阻塞频率，fibers 表现出更好的性能，避免了重复的闭包分配。
最终，性能差异对于 MirageOS 的核心需求来说似乎并不重要。Lwt 的关键优势在于它可以无缝编译到 Javascript，通过 js_of_ocaml 实现，从而实现浏览器可视化以及与 Node.js 的互操作性。选择更多地取决于代码互操作性以及其他语言（如 Javascript 的 `yield` 运算符）中并发功能的发展，而不是原始速度。
这个Hacker News讨论重温了一篇2011年的文章，比较了OCaml中定界连续性和Lwt线程机制。原文作者澄清他们现在使用Eio进行直接样式的IO，展示了一个不依赖单子的HTTP/1.1解析器示例。
一个关键点是OCaml 5中效应处理器的出现。这些效应为Lwt提供了一种更易读的替代方案，并且与原文中讨论的“delimcc技巧”相当，但性能得到了显著提高——本质上起到了栈切换的作用。对话强调了MirageOS生态系统内的一种方法转变，倾向于利用OCaml内置的效应系统来改善并发性和代码清晰度。
启用 JavaScript 和 Cookie 以继续。
## 史密森尼国家动物园迎来亚洲象雌性幼崽
史密森尼国家动物园宣布一头亚洲象雌性幼崽出生，引发了Hacker News上关于此类事件重要性的讨论。虽然这被认为是北美亚洲象种群遗传多样性的提升，但一些评论员质疑其新闻价值，因为与野生种群相比，圈养种群相对较小。
讨论扩展到关于动物园作用的更广泛辩论。许多人认为动物园对于保护至关重要，能够提高公众意识，并为支持野生种群的关键研究和繁殖计划提供资金。另一些人指出，动物园需要成为娱乐场所与它们的保护主张之间存在内在冲突，并举例说明了有争议的做法，如淘汰。
人们也对圈养大象的生活质量表示担忧，一位用户回忆起另一家动物园的恶劣条件。最终，这场讨论凸显了复杂的权衡：个体动物受限的生活与物种整体生存的潜在益处。
## 使信任无关紧要：代理AI安全摘要 DesoPK认为，当前代理AI安全方法存在根本缺陷，在于关注于*信任*AI，而非消除*对*信任的需求。核心问题不是对齐或提示工程，而是“环境权威”——赋予AI对系统（文件、网络、凭证）的广泛、持久访问权，并期望其行为良好。这创造了一种容易被利用的“混淆代理”问题，无论是有意还是无意。 解决方案不是更好的AI，而是更严格的系统机制。DesoPK 提出“仅减少权限”，即代理只能被授予有限的、有时限的权限，且无法升级。这需要一个内核级别的“控制平面”（KERNHELM）作为权限代理，机械地执行权限并分离规划与执行。 本质上，AI应该被视为固有不可信任的，在一种旨在防止其获得“神模式”的系统中运行——即使它试图这样做。这种方法借鉴了游戏开发和安全领域的经验教训，优先考虑强大的机制，而不是依赖AI的意图，从而通过设计而非希望使代理系统更安全。关键在于明确、可撤销的权限，以及防止代理自行授权任何操作。
最近一篇Hacker News上的帖子讨论了人工智能安全问题，将当前失败归结为“混淆代理人问题”的重复出现。作者DesoPK认为，仅仅依靠提示等软性约束来控制强大的AI代理是不够的。相反，他们提倡在系统层面边界上强制执行“硬性、仅减少权限的授权”——类似于内核控制，防止用户态的绕过。
讨论强调了游戏玩家（限制在沙盒中）和具有访问特权信息和高影响操作（API密钥、云控制）的编码代理之间的区别。与游戏规则就足够的情况不同，AI代理需要严格的边界，因为它们*会*利用任何漏洞。
核心论点是优先通过边界进行安全保障，而不是依赖代理的“意图”。尽管承认用户体验问题，DesoPK建议使用范围许可和快速权限撤销等解决方案，强调需要立即且可靠地限制代理的权力。 许多评论者质疑原始帖子是否由AI生成。
在 Fedora 43 容器、Ubuntu 26.04 容器以及常规 Fedora 42 安装中测试，出现相同错误。 直接使用了 README.md 中的示例。 GCC 存在并且可以正常编译代码： root:/claudes-c-compiler# cat > hello.c << 'EOF' #include <stdio.h> int main(void) { printf("Hello from CCC!\n"); return 0; } EOF root:/claudes-c-compiler# ./target/release/ccc -o hello hello.c /usr/include/stdio.h:34:10: error: stddef.h: No such file or directory /usr/include/stdio.h:37:10: error: stdarg.h: No such file or directory ccc: error: 2 preprocessor error(s) in hello.c root:/claudes-c-compiler# gcc -o hello hello.c root:/claudes-c-compiler# ./hello Hello from CCC! root@1b5343a2f014:/claudes-c-compiler#
## 空间连接与H3索引：性能提升
传统的空间连接（例如，`SELECT * FROM A JOIN B ON ST_Intersects(A.geo, B.geo)`）在规模较大时性能会下降，因为空间谓词阻止了高效的哈希连接，导致复杂度为二次方。本文详细介绍了Floe如何利用H3索引来显著加速这些查询。
H3将地球划分为一系列六边形单元的层级结构，提供紧凑的、基于整数的键，适用于高效连接。通过将几何体表示为H3单元ID的集合，`ST_Intersects`检查转换为更快的集合重叠操作。虽然这引入了保守的近似（可能存在误报），但最终的精确谓词重新检查确保了正确性。
该过程包括为两个表生成H3覆盖，在单元ID上进行连接，去重候选结果，然后应用空间谓词。这会将代价高昂的谓词从主要操作转移到清理步骤。使用世界城市/国家数据集的测试表明，使用H3分辨率3可以实现**400倍的加速**，将查询时间从约460秒减少到仅1.17秒。
这种方法实用之处在于它可以与视图/CTE一起工作，避免索引维护，并允许轻松试验分辨率级别。最终，H3索引使数据库能够利用其优势——并行哈希连接——来处理地理空间数据。
## 更快的地理连接：H3 索引总结
这次黑客新闻讨论的核心是使用 H3 索引来加速地理空间连接——查找地理位置数据之间的关系。其核心思想是为每个数据点预先计算 H3 单元格 ID，然后基于这些 ID 执行连接，而不是复杂的几何计算。
几位评论者分享了实施类似系统的经验。一位用户详细描述了一个 6TB 的 Elasticsearch 设置，用于索引 GPS 记录，利用 H3 的分层结构进行高效查询，包括方向匹配。 其他人指出，虽然有效，但 H3 并非总是最佳选择；传统的空间索引，如 R 树或 Elasticsearch 内置的 geo_shape 类型，在某些用例中可能更快。
一个关键的争论点在于 H3 缺乏“一致性”（一致的单元格大小），这可能会影响与替代 DGGS 系统（如 S2）相比的分析性能。 然而，H3 的简单性和数据无关性使其对分布式系统和流式数据具有吸引力，在这些系统中，频繁更新索引至关重要。 最终，最佳方法取决于具体要求、数据规模和性能优先级。