最近量子物理学的争论集中在观察者的作用上。物理学家Vlatko Vedral 倡导“多世界”诠释，反对传统的“哥本哈根”诠释，后者认为观察从根本上影响量子现实。Vedral 认为观察者不应被视为特殊情况，这阻碍了量子力学与引力统一的进展。
然而，文章认为，试图消除观察者最终会以伪装的形式将其重新引入。哥本哈根诠释并不否认量子力学适用于*一切*，包括观察者，但强调了任何相互作用都会产生的内在纠缠——使得真正客观、与观察者无关的现实无法定义。
核心问题不在于物体在被观察时是否表现出奇怪的行为，而在于我们对独立的“物体”的概念在量子力学中本身就存在缺陷。试图绕过这个问题需要任意定义什么是“观察者”或“测量”，实际上是将它们偷偷地重新带入等式。作者最终倾向于“QBism”，一种优先考虑观察者通过其相互作用主动塑造现实的角色，并承认理解量子力学是一个持续且复杂的过程的诠释。
每日HackerNews RSS
## 黑客新闻讨论摘要：“为什么我不支持多世界诠释”
一篇最近发表在《Nautilus》上的文章，质疑量子力学的多世界诠释（MWI），在黑客新闻上引发了争论。 许多评论员批评文章质量，指出作者的哲学背景导致了一种“你选哪边”的框架，而非严谨的科学方法。
讨论强调，MWI并非量子物理学家中最流行的诠释——在对1100名物理学家的最新调查中，哥本哈根诠释目前领先，但总体置信度较低。 一个关键点是，MWI并不意味着每次量子分裂都会能量翻倍；能量守恒定律适用于*每个*世界内部。
评论员也抱怨《Nautilus》的文章质量似乎有所下降，并提到广告增加和限制增多。 有人认为，关于量子诠释的争论往往会偏离客观，更像社会学或心理学，而非可检验的物理学。 最终，许多人认为这篇文章是对MWI的困惑且不具说服力的批判。
## luarrow：Lua 中的优雅函数管道 luarrow 为 Lua 带来了受 Haskell 启发的函数组合和真正的管道操作符，增强了代码的可读性和可维护性。它利用 Lua 的运算符重载，提供了两种风格：**管道风格**（使用 `%` 和 `^` 实现从左到右的数据流，类似于 OCaml/Julia）和 **Haskell 风格**（使用 `*` 和 `%` 实现从右到左的组合）。 该库提供了 `arrow` 用于管道组合（例如 `42 % arrow(f) ^ arrow(g)`）和 `fun` 用于数学风格的组合（例如 `fun(f) * fun(g) % x`）。两者都能达到相同的结果，但满足不同的偏好——管道风格因其更广泛的应用而推荐。 luarrow 是纯 Lua 实现，没有依赖项，提供出色的性能，尤其是在 LuaJIT 环境中。它允许编写更简洁、更具表现力的代码，从而实现诸如“无点风格”之类的技术。可以通过 [luarocks](https://luarocks.org/) 轻松安装。详细文档和示例可在 [GitHub](https://github.com/aiya000/luarrow.lua) 上找到。
一个新的 Lua 库“Luarrow”旨在为该语言带来真正的管道操作符和 Haskell 风格的函数组合。该库使用 `%` 和 `^` 符号将函数串联起来，从而创建可读的数据转换流程。
然而，Hacker News 上的讨论显示出一些担忧。用户指出，`^` 操作符垂直堆叠时视觉上显得笨拙，感觉指向“错误”的方向。一个关键的批评集中在“arrow”（箭头）这个关键字的选择上，有人建议使用“which”（哪个）或“through”（通过）等替代词可以提高可读性和易用性。
一些评论者建议如果喜欢这种风格，可以直接使用 Haskell，而另一些人指出 Lua 现有的函数语法可以变得更简洁，从而更好地支持这种模式。总的来说，该库因其雄心壮志而受到赞扬，但同时也引发了关于语法选择以及 Lua 是否适合这种函数式编程风格的争论。
经济实惠的现代便携式卡带播放器和录音机，具有双声道立体声播放功能。音质良好，可播放所有（I-IV型）卡带。频率响应：40Hz-11KHz（I型），信噪比50dB，失真1%，哇音和颤动0.3%，耳机输出功率：32欧姆时2x2mW。
## 现代Walkman 与对旧技术的怀旧
最近一篇Hacker News上的帖子引发了关于卡带播放器和其他“复古”音频格式（如MiniDisc和黑胶唱片）复兴的讨论。虽然一些评论者对这种趋势的持久性表示怀疑，认为卡带与现代数字音乐相比不便，但许多人表达了对这些旧技术的强烈怀旧之情。
对话突出了像MiniDisc这样的格式的独特吸引力，它提供了数字音质和录音、曲目命名等功能，但最终却受到索尼专有技术的阻碍。其他人则回忆起物理介质提供的触觉体验和精心策划的聆听体验，与流媒体服务的无限选择形成对比。
一个关键点是，许多现代卡带播放器由于制造选择有限，仍然使用相同且质量较低的内部机制，这使得老式播放器更具吸引力。尽管存在客观缺点，但这种吸引力似乎源于对更专注和有形音乐体验的渴望，以及对一些人来说，一种时尚宣言。 讨论还涉及了iPod的持久吸引力以及其他停产技术（如便携式AM/FM收音机）可能出现的类似复兴。
## CXL 与异构内存的未来：摘要
现代应用程序，特别是人工智能和数据分析，对内存容量和带宽的需求不断增加，通常超过标准服务器所能提供的能力。计算互连链路 (CXL) 作为一种解决方案出现，它能够通过 PCIe 添加大量内存，但采用它并非易事。最近来自 UCSD 的研究，涉及对 13 个服务器系统的广泛测试以及与行业合作伙伴的合作，揭示了关键的注意事项。
CXL 擅长**大规模容量扩展**和**有针对性的带宽提升**，适用于对延迟不敏感的工作负载。然而，它会引入**延迟税**——访问速度比本地 DRAM 慢 50-300%。成功的 CXL 实现需要仔细的架构规划。
至关重要的是，性能因 CPU 而异。**英特尔早期型号 (Sapphire Rapids/Emerald Rapids) 存在有限的 LLC 对远程 CXL 内存的访问限制**，需要将工作负载固定到本地插槽。AMD Zen4 和英特尔 Granite Rapids 则没有这个问题。此外，AMD 平台显示出**读/写性能不对称**，写入速度较慢。尽管存在延迟，添加 CXL 可以*降低*整体系统延迟，从而防止 DRAM 饱和。
最终，CXL 并非 DRAM 的替代品，而是为容量受限的工作负载（例如大规模科学计算，如 AlphaFold3）提供的新内存层级。理解这些细微差别对于最大限度地提高异构内存系统的性能至关重要。研究团队已在 ArXiv 上分享了详细的观察结果，并在 GitHub 上开源了他们的基准测试套件。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
《银河系漫游指南》到连贯架构：5条编程规则 (sigarch.org)
8 分，由 matt_d 发表于 22 小时前 | 隐藏 | 过去的 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
网络的成功源于其固有的*包容性*——浏览器能够优雅地处理不完善的代码，即使对于技术水平较低的开发者也能保证可访问性。这与 XHTML 形成了鲜明对比，XHTML 试图强制执行严格的编码标准，但最终导致了令人沮丧的用户体验，并走向衰落。
这种开放的原则超越了代码本身。作者认为，网络充满活力的多样性——由来自各行各业的人们构建，包括像艾伦·图灵这样的先驱者和 ARM 处理器的一位跨性别女性联合设计师——是其力量的源泉。
因此，拥抱宣扬排斥和不容忍的仇恨意识形态，与网络的价值观根本相悖。就像软件中的单一文化会扼杀创新一样，偏见也会损害社区并阻碍未来的贡献。网络依靠连接和包容性来蓬勃发展，那些鼓吹分裂的人在其中没有立足之地。
## 人工智能与博物馆：重审数字化转型
本次演讲探讨了人工智能对博物馆藏品的影响，认为它迫使人们重新评估过去的“数字化转型”努力。演讲者提出了三个核心观点：博物馆应促进对文化的重访， “数字化转型” 揭示了预先存在的挑战，专业人士必须根据自身情况定义“数字化”和“博物馆”。
讨论强调了人工智能如何暴露博物馆实践中长期存在的问题——不完整的元数据、难以获取的策展知识以及对过时系统的依赖。例如，库珀·休伊特博物馆开放数据发布揭示了数据缺口，以及旧目录描述实际上是数字化前的数据库的认识。
目前博物馆中人工智能的应用主要集中在面向员工的工具：从图像中提取文本（旧金山博物馆），生成物体描述（芝加哥艺术博物馆），以及自动化翻译等任务（洛杉矶郡立艺术博物馆）。然而，演讲者告诫人们不要依赖人工智能来*解决*现有问题，而应先解决数据组织和可访问性等根本问题。
最终，演讲强调人工智能的价值不在于自动化，而在于突出系统性挑战。演讲者敦促博物馆专业人士优先考虑事实准确性，保持对数据的控制，并批判性地对待人工智能的局限性，倡导积极主动的方法，而不是被动接受。他们认为，未来取决于理解人工智能的风险和机遇，同时坚持博物馆的核心价值观。
## JiaLiChuang平台总结
JiaLiChuang是一个全面的硬件创新平台，提供从开源项目到制造的全方位服务。它拥有活跃的社区，包括论坛、市场和教育资源，例如“创意大学”和“星火计划”，支持初学者和高级硬件爱好者。
该平台提供PCB及PCBA制造、3D打印（树脂、尼龙、金属）和CNC加工等服务，以及EDA软件和CAM工具。其重点是促进开源硬件，例如基于RK3568处理器、配备AMOLED屏幕的小型平板电脑（成本约150元，GPL 3.0许可）。
JiaLiChuang还提供供应商平台用于采购，以及各种软件解决方案，包括SaaS 3D技术。它旨在成为硬件创作者的一站式平台，涵盖设计、生产和社区支持。
访问被拒绝。您没有权限访问此服务器上的“http://pallais.scholars.harvard.edu/sites/g/files/omnuum5926/files/2025-11/Power%20of%20Proximity%20to%20Coworkers%20November%202025.pdf”。 参考编号：18.4e7c3617.1765247520.1ea31252 https://errors.edgesuite.net/18.4e7c3617.1765247520.1ea31252
## 理解与分析系统中的延迟
本文强调了依赖*平均*延迟测量值的危险性，这可能会掩盖关键的性能问题——例如在关键事件期间的缓慢响应。相反，工程师应该关注*百分位数*（95%、99%等）来了解最坏情况。
核心思想是量化请求处理每个阶段所花费的时间，区分**墙钟时间**（用户体验）和**CPU时间**（实际处理）。延迟源于**微延迟**（函数调用、分配）和**宏延迟**（网络、I/O）。将延迟视为一个*分布*至关重要——大多数请求很快，但异常值很重要。
Python 提供了用于**CPU 性能分析**（cProfile、line_profiler、snakeviz）的工具，以识别计算瓶颈，以及用于**墙钟时间性能分析**（py-spy）的工具，以捕获等待造成的延迟。除了性能分析之外，使用 Prometheus 和 OpenTelemetry 等工具进行的**监控**可以创建连续的指标（直方图），用于实时监控。
最后，本文提倡在生产环境中进行**持续的延迟性能分析**，以主动识别性能回归，并了解延迟在负载下的变化。这涉及平衡采样率与开销，并可视化数据以将延迟峰值与部署或配置更改相关联。关键要点：可见性是优化的第一步。
一个 Hacker News 的讨论围绕着 Python 中的延迟分析，起因是 quant.engineering 上的一篇文章。最初对文章质量存在怀疑，一位评论员称其为“AI 生成”，缺乏实质内容。
核心争论在于 Python 分析方法。一位用户认为采样分析器是不必要的，声称使用像 FunctionTrace 这样高效的工具进行函数跟踪可以实现较低（~1-10%）的开销。其他人反驳说，行分析器*可能*会引入显著的开销（2-5 倍），尤其是在已经优化过的代码中。
FunctionTrace 的许可问题受到了质疑，因为它不是传统的开源许可。讨论还涉及了对延迟敏感型应用（如算法交易）的语言选择，一些人质疑 Python 与 C++ 或 Rust 相比的适用性，而另一些人则为 Python 在使用 turbodbc 等工具优化后的性能辩护。多位用户报告了在使用 FunctionTrace 进行测试时，开销结果各不相同。