上个月，在接受法新社采访时，他警告说，世界比以往任何时候都更需要他作品中捕捉到的讽刺。“我们所处的状况令人震惊，”他说。“我们都太富有了。我们正在消耗世界上所有的东西。而且我们不能。这是不可持续的。”英国摄影杂志编辑黛安·史密斯在Instagram上发布的一篇致敬文章中称帕尔为“战后摄影的巨匠”。“他是个有趣的人——总是乐于接电话，尤其是在很早的时候，而且总是非常直接。他做自己的事情，努力工作，一路上帮助他人——他度过了充实的一生。”多年来与帕尔合作艺术和设计项目的乔纳森·斯蒂芬森告诉BBC新闻，他平静地在观看足球比赛时去世，并补充说他是一位“坚定而忠诚的朋友”。他说：“与马丁的眼睛和思想交流是一种巨大的荣幸——并且不断地受到启发。马丁对日常生活的热情具有感染力。”
每日HackerNews RSS
## 马丁·帕尔在黑客新闻上的纪念
黑客新闻上的讨论哀悼摄影师马丁·帕尔的逝世，他以经常引发争议但极具影响力的作品而闻名。用户分享了个人轶事和对他的影响的反思。
一位评论员回忆说，小时候深受帕尔的“最后的度假地”系列作品的触动，后来还与这位摄影师见面，形容他既是摄影大师——与卡蒂埃-布列松齐名——又非常平易近人。
其他人承认他的作品具有主观性，尤其是在描绘新布莱顿等地时，并指出他独特的艺术视角以及在平凡事物中发现美和叙事的能力。帕尔对彩色胶片、大画幅相机和闪光灯的创新使用也被赞扬为当时的一种清新风格。
分享了链接到他的网站、维基百科页面以及关于他作品的文章，以庆祝他让“平凡事物看起来非凡”的遗产。
这篇内容以埃德温·艾伯特的《扁平世界》为隐喻，说明许多程序员由于不熟悉Lisp宏等强大概念而面临的局限性。作者认为，像Clojure这样的语言提供了一种“更高维度”的编程——在编译时操作语言本身的能力——从而产生根本上更好的代码。 然而，这种力量在很大程度上未被重视。作者指出“blub悖论”——倾向于否定自己熟悉框架之外的想法——以及解释需要思维转变的概念的困难。大多数程序员对“自动化”（如函数）感到满意，但难以理解*扩展*编程核心逻辑的抽象概念。 学习这种新的思维方式，虽然最初会让人感到不适，但会释放出显著的优势。它需要好奇心和认识到自身的认知偏差。最终，作者认为，停留在“扁平世界”——受传统思维限制——是一种选择，而成长来自于拥抱不熟悉的想法，即使它们最初看起来不合逻辑。
最近的一次Scala 2.13到3的迁移最初看起来是成功的——编译通过，测试全绿，初步部署也没有问题。然而，在生产环境中几个小时后，出现了一种神秘的性能下降，表现为Kafka延迟增加，尽管数据负载适中。
广泛的调查，包括负载测试和依赖回滚，都未能确定原因。性能分析显示CPU使用情况发生了显著变化：Scala 3版本在JIT编译器中花费了更多时间，并且令人惊讶的是，在Quicklens库中花费了更多时间。
Quicklens中的一个微妙的bug，导致Scala 3中低效的链式求值，被确定为罪魁祸首。升级该库解决了问题，恢复了与Scala 2.13的性能一致性。
关键经验是，看似无缝的迁移可能会隐藏性能回归，尤其是在使用依赖于元编程的库时。即使初步测试看起来成功，对性能热点进行彻底的基准测试也至关重要，以避免在生产环境中出现意外的瓶颈。
## Scala 3 性能问题与社区讨论 - 总结
一篇最近的博文详细描述了将 Scala 项目从 2.13 版本迁移到 3 后遇到的性能下降问题，具体与新的 `@inline` 关键字行为有关。在 Scala 2 中，`@inline` 是对编译器的建议，而在 Scala 3 中则强制执行，导致过度内联和 JIT 编译开销。作者发现了一个导致低效链式求值错误的 bug，最终通过库更新解决了。
Hacker News 的讨论强调了对 Scala 3 开发的更广泛担忧。许多人同意迁移具有破坏性，工具仍然落后。一些人批评语法更改（特别是可选的无大括号风格）是不必要的，并且会分散注意力。
一个反复出现的主题是，Scala 的开发优先考虑了学术理想，而不是实际的行业需求，这与 Kotlin 更务实的做法形成对比。人们对 Scala 的可维护性、支持以及“类型安全教会”表示担忧。虽然承认 Scala 的强大功能，但许多人认为 Kotlin 提供了一种更易于访问和良好支持的体验，从而导致其采用率不断提高。另一些人则为 Scala 辩护，指出其表达能力和 JVM 的性能优势。
## PostgreSQL 锁：死锁、对象锁与谓词锁
PostgreSQL 使用各种锁定机制来确保数据一致性。这包括关系级别锁、行级别锁和等待队列（并非总是公平的）。一个关键问题是**死锁**，当两个或多个事务相互阻塞时发生，每个事务都在等待另一个事务持有的资源。PostgreSQL 使用“等待图”检测死锁，并在可配置的 `deadlock_timeout` (默认 1 秒) 后中止一个事务来解决它。`lock_timeout` 提供了一种避免无限等待的方法。
除了关系/行锁之外，**对象级别锁**保护系统级资源，如表空间和模式。
**谓词锁**是一种更细微的机制，历史上旨在防止可序列化隔离级别下的“幻读”。虽然最初设计用于锁定条件（如 `a > 10`），但现在主要跟踪事务之间的数据依赖关系——特别是读写 (RW) 和写读 (WR) 依赖关系——以检测潜在的异常。
谓词锁在关系、页面或元组级别运行，并升级到更粗粒度（页面然后关系）以管理内存使用。 它们的使用受参数（如 `max_pred_locks_per_transaction`）的限制，并受 B 树、哈希、GiST 和 GIN 索引的支持。 事务必须在可序列化级别运行才能使用谓词锁。
一个 Hacker News 的讨论围绕 PostgreSQL 锁，特别是 **咨询锁**。虽然原始文章（来自 habr.com）详细介绍了各种锁类型，但对话强调咨询锁是管理分布式应用程序并发的强大工具。
用户分享了在多机器环境中，咨询锁有效地防止了错误的经验，尤其是在数据库模式初始化等任务中。一个关键优势是在连接终止时自动释放，简化了管理。
然而，也存在一些注意事项：咨询锁 *必须* 由获取连接来解锁，这需要为某些作业使用专用连接。关于 *如何* 使用它们存在争论——有些人短暂地使用它们来同步资源访问，而另一些人则长时间保持它们以进行独占进程控制。
最后，有人警告不要使用 `hashtext` 来生成锁号，因为可能发生冲突，并建议将锁号定义为专用包中的常量。
《卫报》调查显示，全美Family Dollar和Dollar General门店普遍存在价格差异，对低收入购物者影响尤为严重。各州检查记录显示，自2022年1月以来，Dollar General出现超过4300次违规，Family Dollar出现2100次违规，错误率经常超过法律限制。在北卡罗来纳州，一家Family Dollar连续四次检查不合格，近四分之一的扫描商品实际价格高于标价。 这些多收费用通常源于人手不足和销售后未能及时更新货架价格，虽然每次的差额可能很小，但对于预算紧张的人来说却意义重大。一些州正在采取行动——亚利桑那州和科罗拉多州已与这两家连锁店达成和解协议——但处罚通常很轻，对零售商来说支付罚款比解决问题更划算。 顾客报告称，对不准确的价格感到沮丧，并且难以获得退款。这两家连锁店拒绝接受采访，仅发表声明重申致力于价格准确。专家认为，这一问题反映了一种商业模式，优先考虑低成本而非准确的定价，最终给那些负担能力最弱的人带来负担。
航班19号的失踪如何助长了百慕大三角的传说
How the Disappearance of Flight 19 Fueled the Legend of the Bermuda Triangle
2 天前
启用 JavaScript 和 Cookie 以继续。
## Sonner：一个流行的Toast库的故事
Sonner，一个Toast通知库，已经迅速流行起来——每周npm下载量超过700万次，并被X、Vercel等公司采用，以及作为shadcn/ui的默认库。尽管市场竞争激烈，但Sonner的成功源于其对优雅性和用户体验的关注。
创建者有意选择了独特的名称“Sonner”（法语中“敲响”的意思），而不是功能性的名称，优先考虑了易记性。至关重要的是，Sonner视觉上吸引人的堆叠动画虽然并非全新，却是第一个被广泛可用的开源实现。
除了美观之外，Sonner还优先考虑流畅的开发者体验。它避免了像Context这样的复杂React模式，而是利用了一个简单的观察者模式和一个直接的`toast()`函数调用。诸如滑动消失、展开Toast以及处理标签页非活动状态等功能，都体现了对细节的关注。动画使用CSS过渡处理，以实现可中断性，并且巧妙的CSS技术保持了hover状态和拖动功能的一致性。
最终，Sonner的成功归功于其美丽的设计和易用性——提醒我们，在软件开发中，优先考虑美学可以成为强大的差异化因素。
## macOS 应用结构：历史概述
早期的 Mac 应用（如 QuarkXPress 4.11）将资源——窗口、菜单等——存储在与可执行代码分离的“资源分支”中。这与简单的命令行程序形成对比。Mac OS X 的出现带来了从 NeXTSTEP 继承的重大转变，即“捆绑包”结构。
现代 macOS 应用本质上是结尾为 `.app` 的目录，包含一个 `Contents` 文件夹。该文件夹包含可执行代码（在 `MacOS` 中）、资源（如图标，在 `Resources` 中）以及潜在的共享库（`Frameworks`）。 重要的是，`Info.plist` 定义了应用元数据——可执行文件名称、所需的 macOS 版本、文档类型——而 `PkgInfo` 保留了经典的 Mac OS 类型/创建者信息。
启动应用涉及 `launchd`、`LaunchServices` 和 `RunningBoard`，它们都依赖于 `Info.plist` 数据。 随着时间的推移，安全功能（如代码签名，Leopard 中添加）和公证引入了 `_CodeSignature` 和 `_MASReceipt` 等目录。
如今的捆绑包越来越集中组件——以前分散在 Library 文件夹中——在应用本身内（例如，`Library`、`XPCServices`、`Plugins`）。这种自包含的方法简化了安装、更新、删除，并通过签名和公证增强了安全性，无论 Intel 还是 Arm 架构。
## macOS 应用解剖与开发者困境
一篇最近在 Hacker News 上的帖子剖析了 macOS 应用程序的结构，突出了开发者面临的复杂性。虽然核心结构相对标准，但现代 macOS 的要求，例如公证，增加了显著的障碍。
公证，旨在提高安全性，实际上是强制性的，因为未公证的应用会向用户触发严重警告，需要导航系统设置才能运行。开发者们表达了担忧，认为公证并未明显提高安全性，反而增加了每年 99 美元的成本。与 Windows 和 iOS 的比较显示出类似的“付费才能玩”的情况，Windows 代码签名在历史上成本更高，但最近通过 Azure 代码签名得到了改善。iOS 应用分发也面临着测试要求的挑战。
讨论揭示了开发者对苹果控制和缺乏透明度的沮丧，尤其是在验证流程和证书吊销方面。一些开发者选择使用 Web 应用来避免平台特定的麻烦，而另一些开发者则强调 macOS 标准化结构的优势，尽管存在额外的摩擦。最终，这场对话强调了一种日益增长的观点，即平台限制正在阻碍开发者，并可能扼杀创新。
本文详细记录了对53篇研究论文引用的扫描结果，揭示了大型语言模型（LLM）生成的参考文献存在显著问题。使用引文验证工具的分析发现，不准确现象普遍存在。 超过60%的论文列表存在问题，范围从完全捏造的作者和标题到不正确的细节，如出版年份或网址。许多引用*部分*匹配现有论文，但作者列表或关键元数据有重大更改。在一些情况下，提供的引用指向不相关的文章，甚至不存在的来源。 这些错误并非随机的；有些论文完全捏造了作者列表，而另一些论文则正确引用了论文，但修改了细节。这表明LLM并非仅仅是记错，而是主动构建听起来合理但错误的引用。这些“幻觉”的频率凸显了在使用LLM进行学术研究和文献综述时的一个关键可靠性问题。与每篇论文相关的评分范围为0.5到8.0，表明受影响的研究领域广泛。
启用 JavaScript 和 Cookie 以继续。
## 代码中的重复：并非总是坏事
一则 Hacker News 的讨论强调了一个常见问题：在软件开发中过度热衷于“不要重复自己”（DRY）原则。许多开发者报告说，他们通过积极地重构来消除重复，从而创建了脆弱且难以更改的代码库，导致函数职责过于宽泛，缺乏明确的目的。
核心论点是，并非所有重复都有害。由*偶然*相似性产生的代码重复应该被保留，而源于共享*概念*的重复才是抽象的有效候选对象。过早或考虑不周的抽象会导致复杂且难以维护的系统。
许多评论者强调代码需要通过清晰的名称和目的来证明其存在价值。其他人指出过度工程的危险以及务实方法的重要性，建议少量的重复可能比复杂的抽象更好，尤其是在没有全面的自动化测试的情况下。Sandi Metz 的著作（“Poodr”）被推荐用于学习识别适当的抽象。最终，这场讨论提倡深思熟虑地权衡利弊，并优先考虑可维护性，而不是严格遵守 DRY 原则。