由索菲亚·维斯帕罗夫（Sophia Vysparov）管理的旧金山洋葱期货公司（The San Francisco Onion Futures Company）提供黄洋葱实物交割的私人可转让远期合约。合约最长可提前六个月预订，通过专有算法定价，每颗洋葱价格在 3 美元至 12 美元之间，付款流程由 Stripe 处理。 该公司声称其业务符合美国法典第 7 卷第 13-1 条的规定，因为它是作为私人卖家而非“组织化交易所”或“交易委员会”运作。交割安排在合约指定的月份进行，主要服务区域包括旧金山、多伦多、西雅图和芝加哥，其他地区可提供第三方配送服务。 合约通过唯一密钥管理，允许所有者安全地转让所有权或更新联系信息。密钥一旦转让，前所有者即失去访问权限，以确保隐私。该公司不提供现金结算或退款，即使交割失败亦是如此；但用户可在交割月之前转售其合约密钥。如有疑问，可通过 [email protected] 与公司联系。
每日HackerNews RSS
“旧金山洋葱期货公司”（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 个不同的平台。
阿里巴巴集团旗下的研究机构达摩院开源了一款人工智能模型，该模型能够通过读取计算机断层扫描（CT）影像识别包括癌症在内的近150种腹部疾病，这是该公司在医疗人工智能领域不断布局的最新进展。 该研究所周五表示，这款名为“达摩雷达”（Damo Radar）的视觉语言模型旨在分析覆盖18个腹部器官的增强CT扫描影像，以识别各类疾病及其他异常情况，例如恶性肿瘤。 该模型利用CT扫描影像及其对应的临床报告进行训练。在近4万例真实临床检查中，该模型在146项临床发现上的平均曲线下面积（AUC）达到了0.913（AUC为1.0代表完美的诊断准确率）。 研究团队表示，这种训练方法最终可推广至其他类型的医学影像，并称该模型为“全球首个专家级通用医学影像模型”。
阿里巴巴开源了一款人工智能模型，能够检测癌症及近 150 种其他疾病。该项目发表在《自然-医学》杂志上，其核心是一个专为医学影像诊断设计的紧凑型模型（约 1.31 亿参数，大小约为 5GB）。
Hacker News 上的反应褒贬不一。批评者质疑研究人员主要依赖“受试者工作特征曲线下面积”（ROC-AUC）作为评价指标，认为在存在显著类别不平衡的医学诊断中，该指标可能会掩盖过高的假阳性率，他们主张改用精确率-召回率曲线（Precision-Recall curves）。另一些人则指出，该模型所使用的基于卷积神经网络（CNN）的特征编码器性能优于视觉转换器（Vision Transformers）。
除技术批判外，讨论还涉及更广泛的主题，包括计算机科学教育中统计素养的缺失、全球人工智能竞赛（用户讨论了中国实验室和工业蒸馏的作用），以及关于人工智能驱动的自动化对社会影响的哲学思考。一些评论者对这些发布背后的企业动机表示怀疑，并强调了人们对于人类被剥削以及人工智能基础设施快速且可能不可阻挡地扩张的持续焦虑。
请提供您想要翻译的内容。
抱歉。
``` { "id": "card_2x8gszy5folpA9s0TOCseE9ABDM", "card_account_id": "cacc_2zElEqQmMHmRxKwXvG1wYtZbLSr", "card_program_id": "cpgm_2x8gszy5folpA9s0TOCseE9ABDM", "authorized_user_entity_id": "enti_25n5phSY8StZxU4C2Y7gAREGUdB", "platform_id": "plat_23YquNWOPEukXhTbA1gZ6KBXMOI", "status": "已激活", "type": "虚拟卡", "bin": "41234567", "last_four_digits": "4471", "sequence_number": 1, "created_at": "2026-09-15T20:00:00Z", "expiration_month": 9, "expiration_year": 2030, "last_active_at": null, "last_paused_at": "2026-09-15T20:00:00Z", "last_inactive_at": null, "inactive_reason": null, "replacement_reason": null, "replacement_card_id": null, "original_card_id": null, "first_activated_at": null, "deactivated_at": null, "deactivation_reason": null } ```
抱歉。