请启用 JavaScript 和 cookie 以继续
每日HackerNews RSS
最近的一场 Hacker News 讨论聚焦于 NASA 和 IBM 发布的一款全新开源地理空间 AI 模型。用户称赞该项目做到了真正的开源——即在训练数据和方法论上保持透明，这与许多仅提供“开放权重”或缺乏清晰文档的“二进制黑盒”式现代 AI 模型形成了鲜明对比。
这场对话引发了关于软件透明度的更广泛讨论。参与者认为，发布编译后的二进制文件不等同于开源，因为后者依然无法获取真正的源代码。另一些人指出，本地软件与 SaaS 之间存在关键区别：尽管本地工具（即使是闭源的）可以通过反编译实现用户控制，但 SaaS 解决方案却让用户对底层系统完全丧失了自主权。归根结底，该讨论再次强调了社区的倾向：相比不透明的行业标准 AI 发布，用户更偏好那些提供清晰、易获取文档及可验证“源代码”的项目。
403 禁止访问
斯坦福大学近期在《自然-神经科学》上发表的一项研究指出，人类大脑发育源于两个不同的神经外胚层祖细胞谱系——一个形成前脑和中脑，另一个形成后脑。尽管一些媒体将其夸大为发现了“两个器官”，但该研究的核心科学突破在于确定了区分这两个细胞群的特定遗传标记。
这一发现解决了发育生物学中一个长期存在的难题：即为何历史上在体外培养功能性脑干（后脑）神经元一直很困难。通过认识到这些细胞具有谱系特异性，且与前脑细胞需要不同的发育环境，研究人员成功开发出一种在实验室中培养后脑运动神经元的新技术。
这项研究对于研究肌萎缩侧索硬化症（ALS）和脊髓性肌萎缩症（SMA）等神经退行性疾病具有重要意义。这些疾病主要影响脑干，由于无法获取或培养相关的组织，此前很难对其进行建模。虽然大脑作为“复合器官”的进化概念引起了科学界的浓厚兴趣，但该研究的主要实际价值在于，它使研究人员能够培养此前“无法生长”的脑干细胞，从而为医学研究提供了重要工具。
**TypeSafe Computer Use** 是一个高性能、高性价比的 macOS 自动化框架，支持 AI 通过自然语言指令完成计算机任务。与那些每次操作都需要分析完整屏幕截图、资源消耗巨大的“前沿”模型不同，TypeSafe 利用专门的决策模型，可在毫秒级时间内从动作列表中做出选择。
**主要优势：**
* **成本与速度：** 运行成本约为标准大模型计算机使用方案的 1/150，且速度显著更快。
* **确定性工作流：** 不依赖单一的大型模型，而是通过 OCR 和 macOS 辅助功能树（AX）读取屏幕，使用轻量级分类器选择动作，仅在文本输入时调用“写入”模型。
* **安全性与效率：** 采用“不向模型发送截图”的策略，利用结构化数据进行决策，并通过置信度门控循环防止错误。
* **可观测性：** 记录每一步的操作，并附带标注截图和精确计时，允许用户离线回放、检查及调试故障。
该项目专为 macOS (14+) 和 Python (3.12+) 构建。对于优先考虑速度和预算、而非重度推理能力的自动化任务，它提供了一个强大的替代方案。
这篇 Hacker News 帖子讨论了一个名为“Typesafe-computer-use”的项目，该项目利用一种成本更低的新型分类模型来实现 Mac 电脑任务自动化。
讨论因项目对 AI 的使用而呈现出明显的两极分化。许多用户批评该项目是“电子垃圾”（slop），指出其 README 和代码提交记录看起来完全由 AI 生成。批评者认为这体现了作者缺乏诚意且对社区不尊重，一些用户甚至表示将抵制任何没有人工审核痕迹的项目。另一部分人则为该项目辩护，认为代码质量比文档更重要，且由大语言模型生成的说明文档正逐渐成为一种可接受的新标准。
除了关于 AI 伦理的讨论外，一部分评论者探讨了该方法的技术价值。他们将使用 Jev 这类小型确定性分类模型与传统的基于大语言模型的智能体进行了对比，指出前者在自动化任务中具有显著的成本和速度优势。一些参与者对此持乐观态度，认为这代表着 AI 应用正转向更务实、“触手可及”的方向，而不再仅仅局限于围绕前沿模型产生的炒作。
由索菲亚·维斯帕罗夫（Sophia Vysparov）管理的旧金山洋葱期货公司（The San Francisco Onion Futures Company）提供黄洋葱实物交割的私人可转让远期合约。合约最长可提前六个月预订，通过专有算法定价，每颗洋葱价格在 3 美元至 12 美元之间，付款流程由 Stripe 处理。 该公司声称其业务符合美国法典第 7 卷第 13-1 条的规定，因为它是作为私人卖家而非“组织化交易所”或“交易委员会”运作。交割安排在合约指定的月份进行，主要服务区域包括旧金山、多伦多、西雅图和芝加哥，其他地区可提供第三方配送服务。 合约通过唯一密钥管理，允许所有者安全地转让所有权或更新联系信息。密钥一旦转让，前所有者即失去访问权限，以确保隐私。该公司不提供现金结算或退款，即使交割失败亦是如此；但用户可在交割月之前转售其合约密钥。如有疑问，可通过 [email protected] 与公司联系。
“旧金山洋葱期货公司”（San Francisco Onion Futures Company）是一个旨在探索 1958 年《洋葱期货法案》（Onion Futures Act）相关法律灰色地带的创意项目。该法案是在一系列市场操纵丑闻后，在美国禁止了洋葱期货交易。
尽管该网站促成了洋葱交付合约的“购买”行为，但创办者明确表示，这主要是一个艺术项目。该平台作为一种私人的、直接面向消费者的服务，而非受监管的“贸易委员会”运营，从而避开了联邦政府对有组织洋葱期货交易所的禁令。
该项目在 Hacker News 上引发了关于期货市场经济理论的热烈讨论。参与者们辩论了期货到底是“降低”了还是仅仅“吸收”了波动性，对比了各类农产品（如土豆与洋葱）的耐储存性，并分析了为何洋葱会被专门列为禁止对象，而其他大宗商品却保持合法。许多用户参与了该网站“荒诞主义”的性质讨论，将其视为金融交易的戏仿，而另一些用户则针对套期保值、供应链物流以及农产品市场操纵的历史背景提供了独到的见解。
Goroutine 泄露（即 Goroutine 在同步原语上被永久阻塞）对 Go 应用程序构成了严重威胁，会导致内存耗尽和 CPU 开销增加。虽然 `goleak` 和 `synctest` 等现有工具在单元测试中行之有效，但它们无法检测生产环境中的泄露。
Go 1.27 引入了一个轻量级的 **Goroutine 泄露分析器**，可通过 `runtime/pprof` 或 `/debug/pprof/goroutineleak` 端点使用。与传统的性能分析不同，该工具利用改进的垃圾回收机制来区分“活跃”的 Goroutine 和在通道、互斥锁或 `sync` 包原语上永久阻塞的 Goroutine。通过映射这些原语的可达性，它能够以极低的误报率提供高精度检测。
该分析器有助于精确定位代码中的问题，例如提前返回、未关闭通道，或锁与通道之间的循环依赖。虽然它仅限于 Go 的原生原语，且在 GC 周期中会带来轻微的性能开销，但它为审计长期运行的生产服务提供了一种稳健的手段。建议开发者将此分析器与标准测试实践相结合，以确保并发代码在整个应用程序生命周期中保持健康和高性能。
抱歉。
SDCC（Small Device C Compiler）是一套可重定向、经过优化的 C 语言编译器套件，专为各种 8 位微控制器设计，包括 8051、Z80、STM8、6502 和 Padauk 架构。该项目最初由 Sandeep Dutta 创建并以 GPL 协议发布，目前由全球志愿者社区通过 SourceForge 进行维护。 该套件提供了一个全面的开发环境，包含 `sdcc` 编译器、`sdas/sdld` 汇编器/链接器、`ucsim` 模拟器以及 `sdcdb` 源码级调试器。它支持 ANSI C 标准（C89、C99、C11、C23），并包含全局公共子表达式消除、循环优化和全局寄存器分配等强大的优化功能。 SDCC 处于活跃开发状态，经常发布更新以支持新的硬件和 ISO C 标准。虽然该项目主要由志愿者推动，但近期已获得 NGI0 Commons Fund 和 Sovereign Tech Fund 的资助，以提升其可靠性、安全性和硬件支持。SDCC 正式支持 GNU/Linux、Windows 和 macOS 系统，用户可通过项目的 SourceForge 页面获取二进制文件和源代码。官方鼓励用户通过邮件列表和论坛寻求支持，并在提交错误报告时提供可复现的代码。
Hacker News 上关于“小型设备 C 编译器”（SDCC）的讨论，突显了它在嵌入式系统——特别是针对 8051、Z80 和 STM8 等 8 位微控制器——中持久的作用。
尽管用户们分享着几十年前使用 SDCC 的怀旧故事，但讨论也反映出如今人们对该编译器的两极分化看法。许多开发者承认，对于小众的旧架构而言，它是“必要”且免费的资源，尽管他们也指出该编译器“漏洞百出”，且在优化策略上存在古怪之处——例如窥孔优化（peephole optimization）问题或对 `volatile` 限定符的处理。
辩论的很大一部分集中在现代微控制器的格局上。一些人认为，像 STM32、ESP32 和 RP2350 这样的新平台提供了更好的价值和性能，使得老式 8 位芯片在大多数任务中显得过时。相反，爱好者们则捍卫 PIC/AVR 芯片在专业、低功耗或混合信号应用中的地位，因为在这些应用中，数模转换器（DAC）和比较器等硬件级功能至关重要。最终，虽然 SDCC 仍然是特定传统生态系统中不可或缺的工具，但对于这些旧架构是否还能与功能丰富的现代微控制器竞争，社区内部仍存在分歧。
构建 Rust 语言服务器（LSP）是一项宏大的架构挑战，它与传统的编译器设计有着本质区别。编译器旨在追求二进制的正确性，而 LSP 必须在代码残缺甚至存在语法错误的情况下，提供有用且低延迟的反馈。
LSP 的核心在于一个“猜测引擎”。它必须应对复杂的各种需求：管理虚拟文件系统、在无竞态条件下并行执行读取查询，以及对代码库进行索引——通常会使用增量计算（如 salsa）或基于磁盘的预取缓存（如 Rust Glancer）等技术。
关键要点如下：
* **“即时可用”原则**：LSP 必须在完整工作区索引完成之前，就提供文档符号或悬停提示等即时价值。
* **元数据依赖**：解析和分析需要版本（edition）、换行符以及工作区结构（例如 `Cargo.toml`）等上下文信息，这意味着即使是简单的任务也是有状态的。
* **处理不一致性**：由于 IDE 中的代码往往是不完整的，LSP 必须具备容错能力，并提供“最佳猜测”的补全建议和诊断信息。
* **架构选择**：开发者必须在内存占用与延迟之间取得平衡，权衡是采用单体增量数据库，还是通过多进程路由来避免全局崩溃。
归根结底，构建 LSP 的本质是在混乱且不断变化的状态中解读用户的意图。
这篇 Hacker News 的讨论探讨了为 Rust 构建语言服务器协议（LSP）的技术复杂性，并辩论了该协议本身的优劣。
主要议题包括：
* **“双重需求”困境：** 用户期望 LSP 既能提供快速的“尽力而为”型编辑辅助（即使代码语法有误），又能进行深入可靠的分析。平衡这些相互冲突的需求及其不同的延迟要求是开发者面临的主要障碍。
* **技术挑战：** 开发者分享了“错误恢复”的策略，强调鲁棒的解析虽然困难但至关重要。建议包括使用有效代码状态的持久化快照，以便在当前编辑不完整时维持上下文。
* **LSP 架构争论：** 讨论中有相当一部分内容批评了基于 JSON-over-TCP/管道的通信方式。一些人认为，类似于 COM 的进程内同步模型会更高效，而另一些人则捍卫当前的异步 IPC 模型，认为其具有语言无关的灵活性、故障隔离性，并且能避免阻塞 UI 线程，是必不可少的。
* **结论：** 尽管许多人承认当前的 LSP 实现存在性能折衷，但它仍是实现“编辑器无关的分析”与“特定语言工具”解耦的务实行业标准。
现代科学极其依赖计算，然而科学软件往往处于隐藏、不可复现且不透明的状态。作者认为，由于计算结果完全取决于生成它们的代码，因此开源软件不仅是一种工具，更是科学方法本身的一个基本组成部分。 真正的科学需要系统且可验证的知识。如果代码无法获取或缺乏文档，研究人员就无法验证、修改或建立在现有发现之上，从而使这种“科学”失去意义。通过采用开源实践——公开代码、确保环境完全可复现（例如使用 NixOS），并以协作方式维护模型——科学可以借鉴开源开发中迭代与透明的成功经验。 作者展望了一个研究成果可以即时复现、科学模型像全球社区驱动项目一样不断演进的未来。为实现这一目标，学术界必须转变文化：研究人员必须从第一天起就优先分享稳定且有文档记录的代码，而学术机构必须正式认可软件开发是科学进步的核心贡献。通过将开源软件等同于科学方法，我们可以加速发现进程，增强信任，并确保我们的集体知识保持持久可靠。
这篇 Hacker News 的讨论探讨了一个引发思考的观点，即“现代科学等同于开源软件”。该观点主张建立一种标准，使科学成果能够通过可访问的数据和代码实现即时复现。
**核心论点：**
* **可复现性目标：** 支持者主张论文应包含容器或存储库的链接，以便重新运行、验证和修改分析过程。这将推动科学向“可执行”知识转变。
* **现实差距：** 批评者指出，学术界深受激励机制错位的影响。高质量的开放获取研究往往不如“操纵数据（p-hacking）”得出的结论受重视。此外，许多实验科学涉及无法轻易容器化的物理、非数字变量。
* **采纳障碍：** 除了技术挑战（如软件失效或依赖冲突）之外，还存在深层的结构性问题：专有数据囤积、严格的知识产权/专利法以及高昂的出版成本。
* **拟议解决方案：** 建议包括为数据管理职业提供更好的资金支持、增加使用 Zenodo 等平台，以及转向要求公开数据的法律强制措施。
尽管一些参与者担心将科学比作“软件”过于简化了科学复杂且具有探索性的本质，但共识反映出人们对日益数字化的世界中陈旧学术实践的挫败感与日俱增。
LispBM
关于
入门指南
文档
社区
立即尝试（WebAssembly）
GitHub
·
Discord
LispBM 是一门专为微控制器设计的类 Lisp/Scheme 编程语言，其特色在于采用了受 Erlang 启发的并发机制、消息传递、模式匹配以及进程监控功能。该语言具有极高的可移植性，支持 32 位和 64 位架构，既可运行于裸机环境，也可在 FreeRTOS、ChibiOS、Zephyr、Linux 和 Windows 等操作系统上运行。目前，项目提供了一个基于 WebAssembly 的 REPL 环境供测试使用。
该项目近期在 Hacker News 上引发了讨论，用户对其作为 MicroPython 的潜在替代方案表现出了兴趣。然而，社区反馈也指出该项目亟需改进文档。批评者指出，项目中缺乏易于理解的“Hello World”示例或硬件相关实例（如 LED 闪烁），并要求在实现细节、资源需求以及具体语言方言方面提供更高的技术透明度。针对对可移植 Lisp 实现的兴趣，有参与者还提到了“Ribbit”，这是一个紧凑且兼容 R4RS 标准的 Scheme 实现，目前已支持 25 个不同的平台。