## 保存雪花：制作你自己的化石
制作持久的雪花复制品是可能的，以便在室内进行详细研究。存在几种“石化”雪花的技术。
一种简单的技术，在《大众科学》中广受欢迎，使用快干胶。通过小心地将一滴冷的稀快干胶和盖玻片应用于冷却的显微镜载玻片上的雪花上，经过一两周的硬化，就可以形成复制品。
替代方法包括使用溶解在二氯乙烷中的Formvar（一种聚乙烯醇缩醛树脂），或透明丙烯酸喷漆。Formvar技术需要仔细配制溶液才能获得最佳效果，而丙烯酸喷漆最适合使用轻薄均匀的涂层，以避免融化冰。
这些保存技术允许在雪花融化后很久对雪花结构进行详细检查，为科学观察和欣赏提供了一个独特的机会。
每日HackerNews RSS
这场 Hacker News 讨论围绕着雪花的保存展开。最初的帖子链接到加州理工学院的一篇文章，引发了用户分享相关经验和技术。
许多评论者提到了丹妮尔，一位用雪花制作珠宝的艺术家，她的方法可能涉及使用 Formvar——一种用于捕捉雪花形状的化学物质。其他人描述了替代方法，包括使用快干胶和将雪花转移到银或金上。
讨论还深入探讨了保存雪花的术语，争论这些雪花是否可以被认为是“化石”，因为雪花本身并非生物。有人建议使用“铸造”、“印记”或简单地称之为“保存标本”。一个有趣的岔路讨论了如果雪花以微生物为核，是否可以被认为是含有生命，从而有可能被化石化。实际考虑因素，例如在低温下粘合剂所需的长期固化时间，也被提及。
## 链式思考：一种强大的技巧，而非真正的推理
链式思考 (COT) 极大地提升了大型语言模型 (LLM) 的能力，使它们能够通过逐步解释来解决复杂问题，看似一项突破，但作者认为这很大程度上是一种*技巧*，用于从本质上有限的模型中引出推理。
核心问题在于效率。LLM 通过预测下一个词元运作，这是一个计算量大且随输出长度增加的过程。作者证明，需要真正“思考”的任务（例如寻找质数）应该比简单任务花费更长的时间，但 LLM 在未使用 COT 的情况下将它们同等对待。COT 通过允许模型通过更多词元来*模拟*扩展的计算，从而规避了这一点，本质上延长了它的“思考”时间。
然而，作者认为真正的推理并不依赖于语言。动物和人类经常进行非语言推理，例如梅西在瞬间做出的足球决策——速度快到无法进行内心独白。语言是一种瓶颈，是一种交流工具，而非思想的引擎。
COT 迫使 LLM 以一种低效的、基于词语的方式进行推理。就像图像生成在低维嵌入空间中更快一样，推理需要一个超越词元预测的专用空间。虽然 COT 是一项有价值的进步，但它是一种权宜之计，作者认为未来的 AI 需要根本不同的方法来实现真正的智能。
## 思维链：大型语言模型是否真的在推理？
一个Hacker News的讨论围绕着一篇2023年的博客文章展开，质疑“思维链”（CoT）提示在大型语言模型（LLM）中是否代表了真正的推理。核心论点认为LLM运作方式是复杂的马尔可夫链，从概率分布中进行采样。模型并非在*推理*，而只是“预热”——探索状态空间，直到到达可能包含正确答案的区域。
一些评论员指出，LLM被训练直接从语言分布中采样，而“预热”类似于在该分布中找到高概率区域，而不是真正地收敛到稳定状态。另一些人则将LLM与双过程理论（人类中的快速与慢速思维）进行类比，认为CoT模仿了系统2的思维方式。
这场辩论触及了生成回应与主动*寻找*解决方案之间的区别，一些人认为LLM缺乏独立识别问题的能力。最后，文章提到了一项关于爱因斯坦对语言和思想的看法的主张，并将其与最近围绕Yann LeCun的争议联系起来。最终，这场讨论质疑LLM中推理的表象是真正的认知过程，还是一种统计学上的假象。
监控机器和应用程序：Stork 汇总有关托管 Kea 的系统健康状况以及 Kea 本身的状态和活动级别的数据。报告的参数包括内存、CPU 利用率、软件版本和正常运行时间。 监控池利用率和高可用性：Stork 显示配置的池，包括已配置和分配的地址数量，甚至跟踪共享网络中的池利用率。图形元素突出显示高利用率区域，以提醒操作员采取行动。监控高可用性对，并显示其配置的角色和状态，方便查看哪些服务器未建立备份，以及何时发生故障转移事件。 管理主机预留：使用图形界面选择主机标识符、分配主机名、预留 IP 地址、关联客户端类以及配置启动文件信息和 DHCP 选项，以添加、更新和查看 DHCPv4 和 DHCPv6 主机预留。
## Hacker News 上关于 Kea DHCP 的讨论
一场 Hacker News 讨论围绕着 Kea，一个现代的、开源的 DHCPv4 和 DHCPv6 服务器。它因其灵活性和功能而受到赞扬，特别是其钩子系统，可用于在大型部署（数十万台机器）中进行定制。但用户体验各不相同。
一些人报告了从 ISC DHCP 顺利迁移的情况，尤其是在 OPNSense 中（ISC DHCP 现在已被弃用），并赞赏 Kea 的稳定性和易于排错性。另一些人则在使用 pfSense 时遇到了静态 IP 预留问题，例如分配延迟或意外行为。人们也对 Kea 对于简单家庭使用的复杂性表示担忧，通常更喜欢 dnsmasq，因为它简单且占用资源少。
几位用户指出可能存在与 DNS 集成问题，一些人更喜欢 Pi-hole 或 unbound 等解决方案。一个反复出现的主题是取代 ISC DHCP 的挑战，因为它具有遗留支持，并且需要付出努力来适应独特的用例。该讨论还涉及了高可用性配置对于关键网络服务的重要性。
Acme，互联网变革性协议之一的简史
Acme, a brief history of one of the protocols which has changed the Internet
2 天前
## ACME：自动化互联网安全
本文详细介绍了ACME（自动化证书管理环境）的历史和影响，该协议 благодаря Let’s Encrypt 推动了广泛的HTTPS采用。ACME诞生于简化获取和管理TLS/SSL证书的复杂过程的需求。Let’s Encrypt由Mozilla、EFF等机构于2013年创立，旨在提供免费、自动化的证书。
Let’s Encrypt成功的关键在于ACME——它使客户端能够在无需人工干预的情况下向证书颁发机构证明域名控制权。虽然事后看来自动化似乎理所当然，但对于将非营利性服务扩展到互联网规模而言，它至关重要。
ACME通过IETF（RFC 8555）标准化，促进了蓬勃发展的客户端生态系统，并与商业CA合作，甚至整合了外部帐户绑定等功能以用于计费。如今，ACME处理了超过60%的所有公共TLS证书，推动全球HTTPS使用率从39%提高到83%以上。
持续的创新，例如ARI扩展，不断发展ACME，但客户端采用仍然是一个挑战。展望未来，ACME的潜力超越了网络安全，并探索了设备证明和更广泛的证书颁发框架。ACME证明了开放协议和协作开发如何极大地改善互联网安全和可访问性。
## Let's Encrypt 与网络安全的发展
这个Hacker News讨论围绕一篇博客文章展开，详细介绍了Let's Encrypt (LE)对网络安全和隐私的影响。在LE出现之前，获取和维护TLS证书是一项手动、昂贵且常常被忽视的过程，导致许多网站运行在不安全的HTTP协议上。LE通过提供免费、自动化的证书颁发和续订，彻底改变了这一现状，有效地使TLS成为网络的默认设置。
虽然LE因提升加密并保护免受被动网络监控（例如来自ISP）而受到广泛赞扬，但评论员们争论LE是否真正增强了*整体*隐私。一些人认为，“大科技”公司仍然主导着数据收集，而TLS只是将加密转移到有利于它们。人们也对TLS普及世界中固有的元数据泄露以及它对网络检查构成的挑战表示担忧。
对话涉及历史背景——包括斯诺登事件的影响以及谷歌推动加密的举措——并探讨了替代方法，如基于DNS的身份验证和证书透明度。最终，该讨论强调了LE对网络安全的重要贡献，同时也承认了面对强大的数据收集者时，在线隐私的持续复杂性。
基于FastLanes高性能的Zig整数压缩库。Zint内部使用FastLanes，因此实现了完全向量化的差分编码和位打包。安全的解压缩API。可以安全地解压缩不受信任的输入。动态压缩输入中的每个块（1024）元素。如果有利，则自动应用差分编码。 const Z = @require("zint").Zint(T); const compress_buf = try std.heap.page_allocator.alloc(u8, Z.compress_bound(input.len)); const compressed_size = Z.compress(input, compress_buf); const compressed = compress_buf[0..compressed_size]; const output = try std.heap.page_allocator.alloc(T, input.len); try Z.decompress(compressed, output); std.debug.assert(std.mem.eql(T, output, input)); 根据你的选择，以任一方式授权。除非你明确声明，否则你有意提交包含在作品中的任何贡献，如Apache-2.0许可中定义，将以双重许可方式授权，不包含任何其他条款或条件。
一个名为FastLanes的新整数压缩库，用Zig语言编写，最近在Hacker News上分享。开发者ozgrakkurt正在积极寻求反馈并改进项目。目前，FastLanes利用差分编码和位打包进行压缩。
最初的反馈质疑了该库的有效性，特别是处理大量重复值数据集（例如全零）的能力。人们担心当前的实现，每1024个字重置一次，在这些情况下可能会*增加*存储大小。开发者澄清说，1024字块大小是为了向量化差分编码和位打包而优化的，并计划将其调整为其他策略，如RLE。
讨论的一个关键点是，所有压缩算法都需要元数据，这意味着压缩数据有时可能大于原始输入。该库设计用于压缩文件格式中的列页，但开发者打算公开核心FastLanes API以供更广泛使用。
家猫对男性照顾者更频繁地发出问候叫声。
Greeting Vocalizations in Domestic Cats Are More Frequent with Male Caregivers
2 天前
启用 JavaScript 和 Cookie 以继续。
## 猫咪沟通与照顾者：黑客新闻摘要
一项最新研究（来自黑客新闻讨论链接）调查了家猫的叫声，发现它们更频繁地向男性照顾者喵喵叫。这项在土耳其进行的小样本研究（n=31）表明，这可能是因为男性照顾者需要更明确的语音提示才能注意到并回应猫咪的需求。
讨论迅速扩展到更广泛的动物沟通话题。用户分享了用响片训练猫咪、教它们指令（成功率各异）以及观察到复杂的行为，表明猫咪的理解水平比以前认为的更高——甚至有人提出猫咪的语言能力可与3-4岁的孩子相媲美。然而，怀疑论盛行，许多人指出理解和服从之间的区别，并质疑复杂猫语的证据。
一些评论员强调了研究方法中潜在的问题，包括对p值操纵的担忧以及由于小样本量和特定文化背景导致的有限推广性。该帖子最终展示了一场关于猫咪智力和沟通能力的活跃辩论，由个人经验和科学探究推动。
## 用户研究价值的侵蚀 生成式人工智能工具的兴起威胁着以人为本研究的核心原则。虽然人工智能在模式识别和数据分析方面表现出色，但依赖它来*进行*研究——生成计划、进行“访谈”、综合洞察，甚至创建人物角色——会导致平庸且缺乏差异化的结果。这并非创新，而是一场竞相降低成本的竞赛，牺牲了只有熟练研究人员才能提供的细致理解。 推动人工智能驱动研究的并非自然发展，而是由工具供应商寻求增加利润和高管优先考虑速度而非质量所驱动。这制造了一种危险的效率幻觉，掩盖了对真正用户理解的漠视。接受这种趋势可能会使用户研究人员变得多余，将他们的角色降低到对人工智能输出进行质量控制。 作者反对被动采用这些工具，敦促研究人员捍卫他们的专业知识，并优先考虑工作的独特人性方面——建立联系、情境化发现和提供有影响力的洞察。最终，优先考虑人际联系和严格的方法至关重要，并且明确反对自动化核心研究职能的“红线”对于维护该职业的价值至关重要。
一位开发者创建了一个8086微处理器的微码交互式在线浏览器，基于之前提取和反汇编的数据。该工具允许用户以可读格式探索21位微指令，并提供工具提示解释每个字段，以及可点击的跳转目标以便于导航。
该浏览器包含一个“按指令浏览”功能，将超过300条记录在案的8086指令直接链接到其对应的微码例程——令人惊讶的是，只有大约60个独特的例程处理所有指令。
通过研究微码获得的见解揭示了8086设计的迷人细节：寄存器ID具有上下文相关的含义，内部命名不一致，程序计数器（IP）使用“CORR”操作管理预取地址进行调整，并且存在大量的代码重用——尤其是在利用核心“XI”微操作的算术指令中。这个浏览器提供了对这款经典CPU内部运作的深入研究。
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 工作 | 提交 登录
8086 微代码浏览器 (nand2mario.github.io)
142 分，作者 zdw 1 天前 | 隐藏 | 过去 | 收藏 | 2 条评论
djmips 14 小时前 [–]
在微代码级别逐步执行一些 8086 代码会很有趣。回复
ajenner 4 小时前 | 父评论 [–]
我写了一个名为 xtce-trace 的程序 (https://www.reenigne.org/software/xtce_trace.zip ) 来做到这一点（尽管是非交互式的 - 你只需给它一个程序，它就会生成一个逐周期跟踪，显示执行了哪些微代码行）。GloriousCow，又名 Daniel Balsom 最近修复了它的一些错误，并将其变成了一个真正的模拟器 (https://github.com/dbalsom/XTCE-Blue )，但它尚未完成，目前没有二进制发布版。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
最近，Linux内核开发社区讨论了改进`xchacha20poly1305_encrypt`函数安全性的问题，该函数是加密层的一个关键组件。该函数接受数组参数（如密钥和nonce），但未强制进行大小检查，这可能导致参数重新排序等危险错误。 最初，有人提出了一种涉及指针间接调用的解决方案，需要调用者修改代码。然而，开发者发现了一个鲜为人知的C语言特性——在数组参数声明中使用`static`关键字——可以在不修改现有函数调用情况下实现相同的大小检查。 虽然`static`无法捕获*所有*与大小相关的错误，但它可以防止常见的漏洞，例如参数顺序错误和数组大小不足。尽管有人担心该关键字的语法很笨拙（“一个可怕的hack”），Linus Torvalds还是批准了它的使用，并指出它已经存在于内核中。目前正在考虑使用类似于`at_least`的宏来提高可读性。这表明即使像内核这样成熟的代码库，也可以通过利用鲜为人知的C语言特性来增强安全性。
这次黑客新闻的讨论围绕着 LWN.net 最近的一篇文章，该文章详细介绍了 C 语言中带尺寸检查的数组参数。核心问题在于 C 语言如何处理传递给函数的固定大小数组——特别是编译器对数组大小缺乏强制执行。虽然 GCC 会在数组太小的情况下提供有用的警告，但 C 标准将传递一个过小的数组的指针定义为未定义行为，即使没有访问越界内存。
对话延伸到与 C++ 的比较，在 C++ 中，`std::array` 和类似结构提供了更安全的替代方案。C++ 不支持使用 `static` 关键字来指定数组大小，因此需要使用宏或模板参数等解决方法。参与者们争论了这个 C 功能的实用性，并指出它采用率有限，以及 C 和 C++ 自 90 年代以来的差异。
一个反复出现的主题是 C 语言的历史设计缺陷，特别是数组自动衰减为指针，这会导致歧义和潜在错误。有人建议将数组包装在结构体中，以及使用其他语言（如 D 语言的 value-type 数组）中的功能的优势，以及编译器标志用于更严格检查的可能性。讨论还涉及抽象中的零-一-无穷规则以及明确限制的重要性。
## Common Lisp & WebAssembly: 构建 WECL
本文详细介绍了如何使用 WECL (Web Embeddable Common Lisp) 构建和交叉编译 Common Lisp (CL) 程序到 WebAssembly (WASM)。目标是将 CL 生态系统扩展到 WASM 支持的运行时环境，从而使 CL 代码能够直接在 Web 浏览器和其他 WASM 环境中运行。
该过程首先构建 ECL (Embeddable Common Lisp) 的主机版本，然后使用它来交叉编译为 WASM。目前这依赖于 Emscripten SDK，WASI 的移植正在进行中。一个关键特性是扩展 ASDF (CL 的构建系统)，将整个系统编译成 WASM 的静态库。这涉及定义新的 ASDF 操作来创建目标文件和构建库，管理依赖关系，以及处理主机环境和目标环境之间的编译差异。
WECL 在此基础上，提供 JavaScript FFI、窗口抽象和浏览器内 REPL 支持。它包含用于运行 Web 服务器并通过 SLIME (LIME) 连接到本地 Emacs 实例的脚本。虽然交叉编译仍在不断发展，但所描述的工具能够将 CL 代码直接嵌入到 Web 页面并在浏览器中高效运行。该项目由 NGI0 Commons Fund 资助。
一个黑客新闻的讨论强调了通过 WebAssembly (WASM) 将 Common Lisp (CL) 带到网络浏览器的努力。 初始帖子链接到一个名为 WECL 的项目，专注于将 CL 交叉编译到 WASM。
评论者指出另外两个相关的项目：Valtan 和 JSCL，并指出它们从不同的角度解决这个问题。 一个关键的讨论点是版本控制系统的选择。 虽然有些人更喜欢 Git，因为它的熟悉性（以及 Magit 等工具），但另一些人则欣赏 Fossil 的集成方法，将 wiki 和问题跟踪与仓库捆绑在一起——这一功能在个人项目中越来越受欢迎。
总体情绪是积极的，对 CL 在 Web 开发领域的扩展感到兴奋。