## 常春藤：从消遣到高精度数学 出于对一个有趣项目的需求，作者用Go语言创建了常春藤，一种伪APL语言，它意外地演变成了一个用于高级数学计算的工具。尽管最初比其他APL衍生语言弱，但常春藤采用精确算术（大整数和有理数）被证明出奇有用，甚至被用于移动应用程序。 Go语言库中高精度浮点数的出现带来了新的挑战，促使作者深入研究如何以扩展精度计算超越函数，如正弦和余弦。现有的算法不足以满足需求，作者不得不重新审视和完善数学概念。 常春藤的实现利用了泰勒级数和参数归约等技术，最终采用了Spouge近似（由Causley改进）来计算Gamma函数。这涉及到复杂的系数计算，由常春藤的基于数组的结构高效地处理。尽管承认存在不完美之处以及优化参数方面仍然存在疑问，作者还是取得了令人印象深刻的精度——Gamma函数超过48位小数——展示了常春藤进行高精度数学运算的能力。这个项目源于对有趣编码练习的渴望，最终推动了语言所能达到的极限。
每日HackerNews RSS
一个 Hacker News 的讨论围绕着一篇博客文章，详细介绍了在名为“Ivy”的系统中实现超越函数的方法。用户很快指出，这与现有的 Emacs 包“Ivy”存在命名冲突。
对话随后转移到准确计算反正切函数等函数的挑战。一位评论者强调了一种比标准泰勒级数更高效的反正切级数，并引用了计算 Pi 的资源，并将该方法的发明归功于牛顿（由欧拉普及）。
进一步的讨论涉及了*实现*与*逼近*超越函数的哲学问题，一些人认为由于其无限性，真正的实现是不可能的，而另一些人则指出计算机代数系统成功地利用了它们。有人怀旧地提到了 Blogspot 的持续存在及其不太理想的移动端渲染。
## 使用被动安全 API 迁移到微服务 迁移到微服务架构需要构建“被动安全”的 API——设计成能够优雅地处理故障，而不会造成数据损坏或重复。这意味着确保请求要么精确一次完成，要么进入清晰可见的可恢复状态。 作者通过实现一个用于处理订单的端点来应对这一挑战，最初面临外部 API 调用、重试和潜在中断的问题。解决方案涉及几个关键步骤： 1. **异步处理：** 使用消息代理将非关键任务（如通知）卸载到后台工作进程。 2. **事务性分阶段作业（消息输出箱）：** 通过在事务*内*将消息插入数据库表来保证消息传递，然后由单独的工作进程可靠地发布它们。 3. **幂等性：** 使用客户端提供的唯一“幂等性密钥”来确保可以安全地重试请求，而不会产生意想不到的副作用。这涉及跟踪请求阶段和恢复点。 4. **消息收件箱：** 使用单独的表跟踪已处理的消息 ID，以去重消息。 这种方法确保在数据库事务中不会发生外部副作用，至少一次传递消息，并安全地处理重试。最终，这种设计创建了一个健壮、有弹性的 API，能够在分布式微服务环境中处理故障并保持数据一致性。为长期可维护性，清理旧的幂等性密钥和处理废弃的请求也至关重要。
## 被动安全API设计：摘要
这次Hacker News讨论围绕一篇关于设计“被动安全”API的博文展开——这意味着失败（崩溃、重试、中断）不应导致重复工作或不可恢复的状态。虽然在语义上通常与**幂等性**（重复操作没有额外影响）相关联，但被动安全是*为什么*，而幂等性是*如何*。
几位评论员强调了**持久执行**框架（Temporal, Restate, DBOS）作为现有解决方案，但警告说它们通常实现“至少一次”传递，依赖于幂等性，而不是真正的“恰好一次”处理。
一个关键要点是，实现被动安全并不*需要*像采用持久执行或微服务这样的大规模架构变革。像**事务性输出队列**这样的模式可以在更少的复杂性下提供显著的优势。“让安全路径成为最容易的路径”的原则被强调为API设计的关键。
关于计算中同步性的本质存在争论，一些人认为所有操作从根本上来说都是异步的，而另一些人则捍卫了将某些调用建模为同步的实用性。最终，讨论强调了在API设计中主动解决潜在的故障模式以确保健壮性和可靠性的重要性。
欧洲核子研究组织接受10亿美元私人捐款用于未来环形对撞机。
CERN accepts $1B in private cash towards Future Circular Collider
2 天前
启用 JavaScript 和 Cookie 以继续。
## 欧洲核子研究中心为未来环形对撞机获得10亿美元资金
欧洲核子研究中心（CERN）为其雄心勃勃的未来环形对撞机（FCC）项目获得了10亿美元的私人资金。 这引发了Hacker News上关于基础物理研究的实际应用问题的讨论。
尽管一些人质疑鉴于该项目巨大的成本，其价值如何，但许多人强调了CERN在具有影响力的衍生技术方面的历史。 这些包括万维网、分布式计算方面的进展（如LHC计算网格）、医学成像技术（Medipix/Timepix）、癌症疗法（PIMMS、MEDICIS），甚至对工业超冷却技术的贡献。
争论的中心在于，像希格斯玻色子这样的*具体*发现是否能转化为日常应用，以及为实现这些发现*所需*的技术进步。 一些人认为，该对撞机的主要好处是培养STEM职业和推动工程边界，无论是否有立竿见影的科学突破。 另一些人则表示怀疑，指出过去一些项目对现实世界的影响有限。 还有人担心可能会“追溯性地”调整理论模型，以证明对撞机的能量范围。
Please provide the content you want me to translate. I need the text to be able to translate it to Chinese.
## Archyl：新型C4模型文档平台
Archyl是一个用于可视化和文档化系统架构的新平台，使用C4模型。它的目标是从代码中直接发现架构，并使文档与代码库保持同步。
最初在Hacker News上的反应指出它与IcePanel等现有工具相似，并呼吁该领域需要更多竞争。然而，人们对潜在的厂商锁定表示担忧，因为Archyl目前将其模型存储在其专有平台上。
开发者澄清说，计划提供导出选项和基于文本的格式，并且当前的Git集成是只读的，以确保数据完整性。他们强调Archyl并非旨在成为“真相的来源”，而是一个用于派生元数据和可视化的工具，安全性是优先考虑的。
用户讨论了与CI/CD管道同步的重要性以及对开放生态系统的需求，并强调了使用Structurizer和IcePanel的经验。虽然Archyl的潜力受到赞扬，但其可用性取决于支持更广泛的生态系统集成，而不是创建一个孤立的解决方案。还记录了一个与GitHub注册相关的问题。
经过十年的 Linux 使用和广泛的“发行版跳跃”——从 Mint 到 Arch，Gentoo（以及随之而来的倦怠！），Fedora，最后是 NixOS——作者开始探索声明式发行版的世界。 最初，作者曾认为 Nix 只是一个 DevOps 工具，但随着项目依赖管理和系统软件包漂移带来的挫败感日益增加，作者改变了想法。 Nix 能够创建隔离的、按项目划分的环境（解决了 Ruby 版本问题），并且其声明式方法——通过配置文件定义*期望*的系统状态，而不是查询当前状态——被证明极具吸引力。 这促使作者对 Guix 产生了兴趣，Guix 是一个使用 Guile Scheme 进行配置的 Nix 分支。 尽管之前因稳定性问题而犹豫不决，但 Guix 1.5.0 的改进，特别是对 KDE 的一流支持，促使作者尝试使用它，并记录了安装和初步体验。 声明式系统所提供的控制、可重复性和版本控制是其核心吸引力所在。
## Guix 系统 初次印象 (来自 Nix 用户)
一位用户分享了从 NixOS 切换到 Guix 的初步体验，Guix 是一个 GNU 发行版，提供类似声明式包管理的方法。主要吸引力在于避免 Nix 语言，转而选择 Guile Scheme。
作者发现 Guix 在优势上与 NixOS 很大程度上可比——可重现的构建、声明式配置——但指出 Scheme 最初的学习曲线更陡峭。评论区的讨论强调了 Guix 对桌面高级用户的潜力，同时也承认 NixOS 更侧重于服务器和嵌入式系统。
提出的担忧包括软件包可用性（Nix 拥有更多选择）和 ZFS 支持。使用 Guix 进行服务器部署是可行的，但不如 NixOS 成熟。评论者讨论了各种服务器管理和密钥处理方法，提到了 `guix deploy`、`nixos-anywhere`、`deploy-rs`、`sops-nix` 和 `clan.nix` 等工具。
一些用户争论 Nix 与 Scheme 的优劣，有些人欣赏 Scheme 的灵活性，而另一些人则认为 Nix 更易于管理。一个反复出现的主题是，希望在两种语言的复杂性之外，有更简单的配置选项。
这个轶事突显了与遗留系统合作的令人沮丧的现实，以及向后兼容性的令人惊讶的怪癖。作者的任务是在IBM System 370的黑白调试器中添加颜色，于是开始寻找相关的文档——在一堆文档中找到一本实体文件夹。
搜索揭示了一种囤积信息的职场文化（特别是同事马修对手册的保护态度），这种文化源于害怕成为找不到所需资源的人。最终，文档被找到，显示`WRTERM`宏*确实*支持颜色，但只有黑色（默认）或红色——而且仅当终端配备了罕见的“双色带”时。
这个故事说明，看似简单的改进可能会受到几十年来的设计选择和早期计算硬件的限制，同时还要应对在互联网时代之前获取信息的实际挑战。
## 向后兼容性与技术债：摘要
这次Hacker News讨论的核心在于历史局限性如何以令人惊讶的方式持续影响现代技术。最初的轶事强调了看似武断的限制——例如编程库中6个字母的函数名——由于需要向后兼容性而仍然存在。
这些限制源于早期的计算技术，如大型机，甚至更早的穿孔卡和电报机。例如，6个字母的限制可能源于对旧编译器和架构的支持，甚至可能与早期机电计算器的机械原理有关。
对话扩展到更广泛的例子，包括长颈鹿低效的回声喉神经（进化限制的结果）和Windows继续使用CR LF换行符（从CP/M和早期DOS继承而来）。核心要点是，许多当前的科技“怪癖”并非设计选择，而是支持遗留系统和避免破坏现有功能的结果。这被描述为数十年增量开发积累的一种“技术债”。
官方版本：Springer网站上的官方版本是开放获取的。[链接] 四元数代数，官方版本 勘误与增补 [PDF] 第一版（2021年印刷）的勘误与增补 当前版本：勘误与增补已合并到以下（最新）版本中。[PDF] 四元数代数，出版后版本 (v.1.0.6u, 2025年10月6日) 为需要更新频率较低版本的用户保留的稳定版本。[PDF] 四元数代数，稳定出版后版本 (v.1.0.5, 2024年1月10日) 补充材料 [PDF] 四元数代数伴侣 存档版本：以下草稿仅供存档使用——您几乎肯定需要上述版本之一。[PDF] v.0.9.28, 2021年5月20日 [PDF] v.0.9.23, 2020年8月2日 [PDF] v.0.9.15, 2019年5月26日 [PDF] v.0.9.14, 2018年7月7日 [PDF] v.0.9.2, 2017年4月18日
## Hacker News 上关于四元数代数的讨论：总结
最近 Hacker News 的讨论集中在**四元数代数**及其在各个领域的惊人普遍性上，从量子物理学到计算机图形学。最初的帖子强调了四元数（特别是 SU(2)，归一化的四元数）比传统的 3D 旋转更基本，影响了诸如粒子物理学之类的领域——解释了玻色子和费米子以及旋量的行为等现象。
对话探讨了四元数频繁出现在 HN 上的*原因*，理论从怀旧工程师回忆起它们在图形学中的用处，到它们固有的“神秘”性质不等。 许多评论员指出，Ken Shoemake 在 1985 年将四元数引入计算机图形学是一个关键时刻，解决了诸如万向锁（Gimbal Lock）的问题。
进一步的讨论涉及与复数、洛伦兹群，甚至麦克斯韦方程组的联系，一些人提倡更广泛地使用**几何/克利福德代数**作为更统一的框架。 最终，该帖子展示了人们对四元数的持久迷恋——一个优雅地解决复杂问题并持续引发好奇心的数学概念。
超过二十年来，作者一直在完善一种照片管理流程，重点在于长期保存照片、统一来自多个来源的图库以及改善查看体验。至关重要的是，此流程*完全*依赖于嵌入在照片文件中的EXIF元数据——避免了外部数据库的脆弱性。 在Google Photos的变动扰乱了他之前的设置后，作者寻找替代方案并发现Immich很有前景。他将Immich用作只读查看器，连接到他位于Synology NAS上的主要照片存储，该存储由一个名为Elodie的自定义命令行工具组织。 他开发了一个插件，将Immich与Elodie集成，从而可以通过EXIF更新实现组织（相册、描述、收藏夹），并自动备份到他的NAS和Dropbox。这通过直接将更改写入照片文件来避免Immich对数据库的依赖。虽然由于Immich和Elodie的交互方式而具有挑战性，但该解决方案比标准文件系统提供了更丰富的查看体验，满足了他重温回忆的愿望，并确保了照片的长期保存。代码可在GitHub上找到（issue #496）。
## Immich & 自托管照片管理
这次黑客新闻的讨论围绕着 **Immich**，一个自托管照片管理系统，以及替代方案。许多用户报告成功从 Apple Photos 迁移到 Immich，称赞其易于安装和强大的功能，如上下文和 OCR 搜索。一个关键优势是将机器学习任务（如图像处理）卸载到本地网络上更强大的机器上，即使这些机器没有 Nvidia GPU。
用户分享了从 iCloud 提取照片的技巧，包括直接使用 Immich iOS 应用、通过 Mac 下载，或使用像 `immich-go` 和 `iCloud Photos Downloader` 这样的工具。人们对 Apple 的 iCloud 导出过程（缓慢、不可靠）表示担忧。
**Nextcloud + Memories**、**Photostructure** 和 **Elodie**（一个利用 Claude Code 构建的定制解决方案）等替代方案也被讨论。有些人更喜欢更简单的解决方案，例如使用 Syncthing 直接管理文件和打印物理副本。对话强调了对照片存储和元数据控制的渴望，避免与云服务相关的供应商锁定和隐私问题。
最终，该帖子展示了一个社区积极寻求和构建强大、自托管的个人照片管理解决方案。
Goldbridge 正在构建面向全球最大资产类别——房地产的金融操作系统。每年有超过 1 万亿美元的租金流向房东的银行账户，其中约四分之一被锁定在闲置储备和押金中——还有数十亿美元因不必要的房产费用而流失。随着 2027/28 年将有 2.5 万亿美元的房地产贷款到期，房产所有者迫切需要尽快增加收入。Goldbridge 通过创建第一个面向房地产所有者的 AI 驱动银行平台来解决这个问题。我们获得 Y Combinator 和其他世界一流投资者的支持，我们的 CEO 是一位 2 次 YC 创始人、前白宫顾问以及拥有并运营 100 套房产的房地产专家，他对该行业有着深刻的理解。完整职位描述请见：https://www.goldbridgebanking.com/careers/forward-deployed-engineer
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
疯狂增长 Goldbridge (YC F25) 正在招聘前线部署工程师 (ycombinator.com)
1天前 | 隐藏
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：