这个思想实验探讨了利用Go的模块系统进行Ruby包管理，从而实现令人惊讶的供应链完整性。通过将Ruby gems视为Go模块——在将`GOPATH`设置为Ruby加载路径后使用`go get`来获取它们——Ruby可以利用Go去中心化、版本化的文件系统布局和安全特性。 Go的导入路径约定（例如`github.com/rails/rails`）具有自描述性，并避免了对像RubyGems这样的中央注册表的依赖。至关重要的是，Go的代理(`proxy.golang.org`)会缓存模块，而`sum.golang.org`会为每个版本创建永久的、防篡改的密码学哈希日志。这提供了RubyGems所缺乏的完整性保证。 虽然这听起来很荒谬，但这个“黑客”展示了共享基础设施的潜力。一个概念验证的“go-bundler”表明依赖关系解析基本没有改变，只有获取过程外包给了Go。然而，仍然存在挑战——特别是与原生扩展和Go的文件系统特性有关。最终，这个实验强调了一个内容寻址、透明度日志分发层的优势，该层可能可用于多个软件包生态系统，即使将其改造到现有语言上是不切实际的。
每日HackerNews RSS
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
受诅咒的打包工具：使用 go get 安装 Ruby Gems (nesbitt.io)
24 分，SPBS 1 天前 | 隐藏 | 过去的 | 收藏 | 3 条评论
NewsaHackO 1 天前 | 下一个 [–]
使用 LLM 帮助校对或撰写博客文章是可以理解的，但直接将 ChatGPT 的答案复制粘贴到博客文章中并发布在这里有什么意义？如果它真的很有趣，为什么不直接发布提示词，让我们自己看看呢？回复
nasretdinov 1 天前 | 上一个 [–]
不错的文章！一个小问题：Go 可以通过 cgo 在进行 go get 时构建 C 代码，但当然，这可能无法生成 Ruby 模块期望的对象文件。回复
arccy 1 天前 | 父级 [–]
自从 1.18 版本以来，Go 在 "go get" 期间不再构建任何内容。
它现在只是下载。
https://go.dev/doc/go-get-install-deprecation 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
这个系列展示了在Lean 4 + Mathlib中形式化验证的令人惊讶且常常令人不安的“垃圾定理”，强调了类型理论对于不熟悉它的数学家来说的反直觉后果。这些定理源于Lean的具体定义——例如，定义除法时1/0 = 0——以及其底层的逻辑框架。 例子包括证明1/2的第三坐标是一个双射，将一个多项式的坐标等同于30的质因数分解，甚至表明黎曼猜想位于“非非”的拓扑闭包中。更根本地说，该系统允许证明*不同类型*的对象之间的相等性，例如断言二次互反律的证明等于一个双射，甚至在特定的（不一致的）公理下0=1。 这些结果不一定是缺陷，而是源于Lean处理相等性、命题和计算规则的方式。一些是Mathlib定义的产物，而另一些则暴露了类型理论、定义证明无关性，甚至Lean编译器的实现更深层的影响。它们说明了看似合理的数学概念在形式化的、类型理论系统中如何表现出意想不到的行为。
这个Hacker News讨论围绕着Lean定理证明器中的“垃圾定理”——看似无意义但技术上可证明的陈述，它们源于数学形式化。核心问题是Lean灵活的基础可能导致意外的结果，例如证明“3 ∩ 4 = 3”或“1/2的第三坐标是一个双射”。
虽然在Lean系统中在数学上是有效的，但这些定理可能会令人困惑并阻碍实际的证明开发。它们代表了一种“泄漏的抽象”，其中实现细节会干扰更高层次的推理。一些人认为这些定理是无害的，甚至是有用的，因为它们不允许证明*错误*的陈述。另一些人则担心它们的影响，尤其是在LLM辅助证明生成兴起的情况下，这些“变通方法”可能会被利用。
讨论涉及形式化验证中数学纯粹性和实用可用性之间的权衡，以及Lean是否应该优先阻止这些定理，还是仅仅要求用户意识到它们。一个关键点是Lean本身并不阻止这些定理，而是依赖于用户在证明中添加适当的约束。 许多评论者链接到相关的博客文章，解释了Lean方法背后的设计选择。
## Cloudflare：互联网用户的双刃剑
Cloudflare 为网站所有者提供便捷的免费服务套件——CDN、DNS 和基本安全，因此广受欢迎。虽然对于发达国家（美国、加拿大、欧洲）的用户来说通常比较稳定，但对于东南亚等地区的用户来说，体验却大不相同。
作者详细描述了由 Cloudflare 的安全功能触发的频繁且不必要的 reCAPTCHA 提示，影响了多个 ISP 跨越数百个 IP 的测试。这给用户带来了令人沮丧的体验，尤其是在 Cloudflare 被广泛采用的情况下。
除了持续的 CAPTCHA 之外，Cloudflare 数据中心在全球的不均衡分布也导致了问题。当较近的节点出现故障（即使是维护）时，流量并不总是被有效地重新路由，*增加*延迟，并可能导致网站崩溃——就像 Reddit 和 StackExchange 等网站在一次持续 4-5 小时的故障期间所经历的那样。
作者认为，免费服务的便利性不应超过这些负面影响，建议网站所有者优先进行核心优化，然后再依赖 CDN，并仔细考虑收益是否大于对大量互联网用户造成的潜在干扰。
## Cloudflare 与现代互联网体验 (2016)
2016年Hacker News上的一场讨论集中在对Cloudflare日益增长的沮丧情绪上，尽管其本意是保护网站。虽然承认Cloudflare解决了日益严重的垃圾邮件和攻击者问题——这些问题在早期互联网上基本不存在——但用户认为这种解决方案带来了新的问题。
许多评论者报告说，访问网站变得越来越困难，频繁遇到验证码，甚至完全被阻止，尤其是在使用不太常见的配置（如Linux上的Firefox）或从某些地理区域连接时（东南亚经常被提及）。核心抱怨是Cloudflare将安全负担从恶意行为者转移到了合法用户身上。
一些用户指出，关于误报缺乏透明度，以及申诉被阻止的困难。一些人建议使用替代方案，例如对过滤进行更精细的控制或微支付系统，但承认实施的复杂性。最终，讨论强调了一个权衡：安全性的提高是以可访问性和用户体验为代价的，而管理这种平衡的责任越来越落到最终用户身上。对话还指出，自2016年文章首次发表以来，这个问题只会变得更糟。
mruby是Ruby语言的一个轻量级实现，与Ruby 3.x版本高度兼容（不包括模式匹配），设计用于嵌入到应用程序中。它包括一个解释器（mruby）、交互式shell（mirb）和一个字节码编译器（mrbc）。字节码可以直接编译成C源代码文件以进行进一步集成。
mruby可通过GitHub（https://github.com/mruby/mruby）获取，并可通过诸如`ruby-install`之类的工具安装。由于其宽松的MIT许可证，mruby为各种环境（特别是嵌入式系统）提供了灵活性。
mruby具有一个名为`mrbgems`的包管理器，用于用C和Ruby创建扩展。mruby和C API都有文档。欢迎通过pull request贡献代码，并遵守项目指南。所有内容均采用MIT许可，贡献者保留版权，同时授予非独占权利。出于简化起见，该项目通常使用“mruby developers”作为版权名称。
## mruby：轻量级 Ruby 用于嵌入
这次黑客新闻讨论的中心是 **mruby**，它是 Ruby 编程语言的一个轻量级实现，设计用于嵌入到其他应用程序中，而不是像标准 Ruby (MRI) 那样作为一个独立的系统。
用户将 mruby 与 **Lua** 进行比较，Lua 是一种流行的脚本语言，常用于嵌入式系统和游戏开发。虽然有些人认为 mruby 是一种更简洁的语言，但 Lua 因其更强大的实现和更广泛的应用而受到赞扬，尤其是在日本以外。
一个主要的争论点是 **mruby 的嵌入 API**，它被认为比 Lua 的更复杂且文档记录较差。用户强调了 C API 的困难、缺乏清晰的文档（“阅读头文件”）以及手动内存管理的要求。
尽管存在这些挑战，mruby 仍然在一些利基领域找到了用武之地，例如在 **DragonRuby 游戏引擎**中，甚至用于在 **Dreamcast** 上开发游戏。它能够编译成单个自包含文件也是一个重要的分发优势。 讨论还涉及 Ruby 生态系统的整体状况及其未来。
启用 JavaScript 和 Cookie 以继续。
本文详细描述了在 Rust 项目中使用 Git 预提交钩子时遇到的挫折经历——一个简单的 FizzBuzz 实现。作者最初创建了一个基本的 Rust 程序，并设置了一个预提交钩子，以自动使用 `rustfmt` 格式化代码。然而，钩子的初始实现是在工作区运行，而不是在索引上运行，导致无法在提交之前捕获格式化问题。 后续的迭代尝试通过在已签出的索引版本上运行，然后仅在已修改的文件上运行来改进钩子。虽然这些改进解决了一些问题，但作者发现了一些根本性的限制：钩子会破坏 rebase 操作，在不同的分支上不可靠（由于不同的提交历史和钩子版本），并且会干扰 stash 等工作流程。 最终，作者得出结论，预提交钩子是一个“从根本上来说有缺陷的想法”，因为其固有的不稳定性和潜在地干扰合法的开发流程。他们强烈建议使用 **pre-push 钩子** 代替，强调它们应该快速、可靠，并在索引上运行，而不是工作区，并且在贡献文档中提供清晰的手动设置说明。
## Pre-commit 钩子：一个警示故事
最近 Hacker News 上的讨论强调了在 Git 工作流中使用 pre-commit 钩子存在的问题。虽然本意是自动化提交前的检查，但如果实施不当，它们可能会成为摩擦和沮丧的根源。
核心论点是 pre-commit 钩子常常被滥用——变得缓慢、不可靠或过于干涉。开发者经常绕过它们，从而使其失去作用。共识倾向于依赖 CI/CD 管道进行彻底检查，仅将 pre-commit 钩子用于*快速*、非侵入性的任务，例如基本的语法验证或防止意外提交密钥。
关键要点：
* **保持钩子简单：** 它们应该快速且确定性，避免网络访问或复杂的构建。
* **不要强制：** 允许开发者选择加入，而不是自动启用钩子。
* **CI 是真理之源：** 关键检查应始终在 CI 中执行。
* **考虑替代方案：** 例如 `jj fix` 这样的工具为格式化和代码风格提供了更优雅的解决方案。
最终，讨论强调优先考虑开发者体验，并认识到强制特定工作流程可能适得其反。一种灵活的方法，即 CI 处理强制执行，而 pre-commit 钩子提供可选的便利，通常是首选。
本文概述了 GitHub 平台上的功能和资源，该平台用于软件开发和版本控制。GitHub 为开发生命周期的每个阶段提供工具，包括**代码创建**（借助 Copilot & Spark 等人工智能辅助）、**开发者工作流**自动化（Actions、Codespaces）和**应用程序安全**（Advanced Security）。 它服务于各种用户——从**企业**到**初创公司**——并支持 DevOps、CI/CD 和应用程序现代化等各种**用例**，涵盖医疗保健和金融等行业。 除了核心开发之外，GitHub 还提供广泛的**资源**，如文档、博客和培训（GitHub Skills）。它还通过开源倡议、赞助和支持论坛来培养强大的**社区**。最后，该页面详细介绍了**企业解决方案**和可用的**附加组件**，如高级支持和增强的安全功能，以及条款和隐私政策等法律信息。
一位开发者（syn-nine）分享了他们参加一项极具挑战性的“Langjam”的经历——一个在严格的52小时内创建语言、编译器、虚拟机*和*游戏的比赛。今年的比赛深度令人印象深刻，评论员指出这些挑战的复杂度日益增加。
Syn-nine详细介绍了他们的全新语言“garlang”，强调了FORTH参数栈/scratchpad和x86汇编调用栈的独特结合，从而能够轻松实现多个返回值。他们对列表操作和递归深度复制函数等功能特别满意。尽管承认由于时间紧迫存在一些粗糙的地方，但他们认为garlang可以作为游戏脚本库很有价值。
该开发者还分享了他们提交的游戏链接，“Knots” ([https://syn9dev.itch.io/knots](https://syn9dev.itch.io/knots))。讨论中提到了之前的Langjams以及类似的快速开发挑战，如“七小时roguelikes”。值得注意的是，该项目未使用任何AI工具。
## 超越基本调度：动态 Cronjobs 本文重点介绍了一种简单但强大的技术，用于扩展 cronjobs 的功能，使其超越标准的调度限制。虽然 cronjobs 传统上用于重复性任务，但通过在 crontab 条目中直接加入条件检查，可以使其变得非常动态。 作者意识到，你可以利用 POSIX “test” 命令（使用 `[]` 或 `test`）来添加逻辑。例如，可以安排一个脚本在每周二早上 7 点运行，*除非* 是当月的最后一个星期二，通过检查七天后的日期是否仍然在同一个月内来实现。 除此之外，文章还演示了如何根据外部数据触发任务：仅在美國节假日（使用下载的节假日列表）运行脚本，根据天气状况（通过国家气象局 API），甚至由人工智能对当前新闻事件的评估来确定。 本质上，cronjobs 不仅限于基于时间的触发；它们可以响应几乎任何你可以编写脚本的条件，从而释放新的自动化灵活性。
## 动态 Cron 任务 & 系统调度 (Hacker News 讨论)
这次 Hacker News 讨论围绕着使用更动态和健壮的方法来增强 cron 任务调度。原始帖子强调在 cron 表达式中直接使用 shell 命令来有条件地执行任务，这是一种避免复杂脚本的巧妙方法。
一个关键的争论点在于是否坚持使用传统的 cron 或采用 Systemd 定时器。许多评论者提倡 Systemd，理由是它具有内置的锁定机制（避免“惊群效应”问题）和更灵活的调度选项，包括用于随机执行的泊松过程。
其他讨论点包括锁定机制的重要性（使用 `flock`）以防止任务重叠执行，管理节假日安排（建议从简单的 JSON 文件到专门的 API 集成，如 GOV.UK 的银行假日 JSON），以及版本控制 crontab/定时器单元的优势。 几位用户告诫不要将复杂的逻辑直接嵌入到 cron 定义中，而是倾向于使用包装脚本以提高可维护性。 最终，这次讨论展示了在类 Unix 环境中实现可靠且适应性强的任务调度的各种方法。
Hyperliquid，一个估值300亿美元的“去中心化”交易所，其运作方式与DeFi所期望的透明性和无需信任原则相去甚远。对其核心代码的逆向工程分析显示，它是一个伪装成链上系统的中心化系统。 关键在于，其源代码*并非*开源，而是依赖于下载的“数据块”进行执行。 该平台拥有一位具有上帝模式权限的“CoreWriter”，能够未经授权地操纵用户资金和系统参数。内置了追溯性交易量操纵机制，并且存在一个无解冻功能的计划冻结机制。只有八个未公开的地址可以提交交易，从而形成了一个中心化的控制点。价格预言机可以被无保护地覆盖，并且桥接提款可以被无限期审查。 治理提案被记录但无法验证，并且由于依赖于Circle的USDC，存在3.62亿美元的会计缺口。一个隐藏的、完全部署的借贷协议（“BOLE”）与交易所并行运行，增加了系统性风险。分析发现，存在允许制造交易量和单方面冻结链的功能。 这些发现表明Hyperliquid优先考虑控制而非去中心化，这引发了对用户安全和平台对其自身是下一代DeFi交易所的声明的严重担忧。
## Hyperliquid DEX 疑虑与加密货币辩论
最近的 Hacker News 讨论集中在 Hyperliquid 去中心化交易所 (DEX) 上。一位用户分享了糟糕的体验，指出交易卡住且客服回复令人担忧。具体而言，他们质疑 Hyperliquid 宣称的完全去中心化，因为交易存在版主干预，并且该平台为了“竞争优势”而选择保持源代码私密。这引发了对 Coinmarketcap 和 Coingecko 等平台是否应该将其归类为真正的 DEX 的质疑。
该帖子引发了关于加密货币领域诈骗价值和普遍性的更广泛辩论。虽然有些人仍然持怀疑态度，但另一些人则捍卫加密货币在抵御审查、对冲通货膨胀和无许可资金转移方面的潜力。然而，反驳意见指出，这些承诺往往无法实现，并且加密货币经常被用作诈骗工具，使那些已经拥有权力的人受益。最终，这场讨论强调了在加密货币领域中进行批判性思考和保持怀疑态度的重要性。
## AI 生成的警方报告：2024 年回顾 2024 年，人工智能用于撰写警方报告的数量激增，这主要得益于 Axon 公司的“Draft One”工具——该工具与其流行的随身佩戴摄像头捆绑销售。然而，这项技术引发了对准确性、透明度和正当程序的严重担忧，特别是由于有缺陷的报告可能会影响个人的自由。 一个关键问题是 Draft One 的设计：它在导出时*删除*最初由人工智能生成的草稿，这使得难以验证报告的来源，并可能允许警官将不准确之处归咎于人工智能，从而逃避责任。这种缺乏透明度阻碍了公众监督，Axon 公司有意设计该系统以避免“信息披露的麻烦”。 尽管存在这些担忧，但进展正在取得。加利福尼亚州和犹他州通过了立法，要求披露人工智能参与报告创建的情况，加利福尼亚州更进一步，强制保留初始草稿以进行审计，并禁止与供应商共享数据。 EFF 积极反对不负责任地使用人工智能，发布报告详细介绍了 Draft One 的缺陷，并发布了一份关于人工智能生成报告的公共记录请求指南。预计 2025 年会有更多州效仿，监管甚至可能完全禁止这种做法。