Spectrimage分析上传的照片，在您的浏览器中直接创建视觉色彩光谱，无需服务器连接。它首先将图像调整大小，最长边不超过300像素，然后将每个像素转换为HSL（色相、饱和度、亮度）。 颜色被分为180个色相区间（2度切片），非彩色（黑、白、灰）被单独分离。在每个区间内，像素按亮度排序，最暗/最亮的20%用于定义阴影和色调，而中间的20%代表纯色。 最后，这些颜色列以ROYGBIV顺序排列并在画布上显示，列的高度反映了色相的普遍程度。每列内的渐变视觉上表示从色调到纯色再到阴影的过渡，即使对于大型图像也能提供平滑快速的色彩分析。
每日HackerNews RSS
对不起。
## HTTP 路径中的双斜线：并非规范化问题 RFC 3986 定义了 URI 语法，明确允许空路径段，这意味着 URL 路径中的双斜线 (`//`) 在语法上是有效的。它们代表零长度的段，并非错误。根据 RFC 标准，规范化关注大小写、百分比编码和点段移除——*而非*折叠空段。 HTTP (RFC 9110) 使用 RFC 3986 的路径语法。路径是资源标识符的一部分，对其进行更改（例如折叠 `//`）会改变标识符本身，除非服务器明确定义这两种形式是等效的。 一些实现（例如启用 `merge_slashes` 的 nginx，以及 Go 的 `net/http.ServeMux`）错误地折叠双斜线。然而，这偏离了既定标准。在涉及嵌套层次结构的情况下，例如 Git 仓库，这些双斜线可以作为重要的分隔符，折叠它们可能导致歧义或功能损坏。因此，将 `//` 折叠为 `/` 并非正确的规范化。
## HTTP 路径规范化讨论总结
一 Hacker News 讨论集中在 Web 服务器是否应该“规范化”HTTP URL 路径中的双斜杠 (`//`)。核心论点是，虽然 RFC 3986 *不要求* 合并这些斜杠，但许多服务器（NGINX、Apache、Traefik）默认会这样做。
一些人认为这种默认行为是不正确的，因为它会改变原始 URL，并且对于期望特定路径结构（如 S3 对象存储）的应用程序来说可能很重要。他们提倡制定新的 RFC 来明确定义期望的行为。另一些人则认为，这不是一个根本性的缺陷，而是一个配置选择，试图标准化这可能会破坏现有系统。
这场辩论凸显了严格遵守规范与实用、既定的 Web 服务器行为之间的紧张关系。许多参与者强调，虽然 RFC 定义了 URL *解析*，但它并没有规定服务器应该如何将 URL *映射* 到资源。最终，这场讨论强调了 URL 处理的复杂性以及实现中可能出现的不一致性。
我们最初在一个小公寓里，为另一个商业想法寄送信件。那时我发现，蜡封的个性化触感对回复率影响最大。我开始制作简单的系统，尽可能多地手工制作蜡封。最初的手工流程，现在已经发展成一个复杂的操作，能够处理大量的批量邮件订单，同时保持其真实的手工感。
对不起。
## 软件开发中的替罪羊机制
软件故障很少通过客观分析来解决；相反，组织常常陷入一种**替罪羊**模式，反映了古代社会的仪式。当问题出现时，会产生对可见行动的压力，导致选择一个“受害者”——一个基础组件或技术——来承担责任，无论实际原因如何。这并非关于解决问题，而是通过归咎来恢复社会秩序。
这种“**战争理由工程**”是由那些利用失败来推动自己偏好解决方案的人推动的，他们将现有系统描绘成固有缺陷。一个损坏的功能成为拆除一个正常运行的基础的理由，即使它与故障无关。这受到确认偏差和可得性偏差等认知偏差的助长，并在低信任环境中蓬勃发展。
敏捷运动本身就是一个典型的例子，其中“瀑布模型”成为更广泛的项目失败的便捷替罪羊，从而实现方法论的彻底转变。
抵制这种模式需要严格的根本原因分析，将故障与基础分离，并根据价值评估解决方案，而不是将其视为对感知缺陷的反应。认识到这种动态——危机、替罪羊、虚假因果关系——对于培养更理性、更有效的工程文化至关重要。最终，选择工程而非叙事对于避免重复破坏和重建的循环至关重要。
## 技术领域及其他领域的替罪羊现象 - 摘要
最近的Hacker News讨论围绕一篇探讨“战争理由工程”（通过组织内部的替罪羊行为引发冲突，如同“战争的正当理由”）的博文展开。核心观点是，功能失调的文化通常不是通过真正的解决问题来处理问题，而是通过指责个人、工具或方法论。
讨论强调了勒内·吉拉尔的理论，即替罪羊是一种基本的人类行为，但警告不要将其简单地归结为“人性”，而忽视特定文化因素。例子从传统文化中因捕鱼网故障而指责个人，到软件开发中指责语言/框架不等。
评论员指出，这种现象在技术领域表现为将产品失败归咎于工程师，或者将责任推卸给过时的“瀑布”方法论，同时采用“敏捷”作为解决方案——通常只是压缩了指责周期。一些人认为，真正的工程关注根本原因的理解，而替罪羊行为仅仅是伪装成分析的政治操纵。另一些人则认为，问题并不总是出于恶意，而是源于缺乏理解和沟通。最终，讨论质疑识别替罪羊是否会阻碍真正的进步和问题解决。
## Brunost：一种新挪威语编程语言
John Lindbakk 创建了“Brunost”，一种受同名挪威山羊奶酪启发的函数式编程语言——香甜、顺滑且富有深度。该语言的独特之处在于它严格执行新挪威语（Nynorsk），一种挪威书面标准，要求所有变量、函数和参数名称都符合其词典。如果未使用新挪威语，则会标记错误。
Brunost 是一种解释型语言，具有松散的类型系统，解释器使用 Zig 编写以提高速度。主要特性包括不可变性（使用 `fast`）、条件语句 (`viss`)、函数 (`gjer`)、循环 (`forKvart`、`medan`) 以及异常处理 (`prøv`/`fang`)。
作者承认该项目具有趣味性，不打算构建完整的生态系统，但欢迎贡献。示例展示了 Brunost 的功能，包括斐波那契数列、FizzBuzz 甚至康威生命游戏的实现。虽然不打算用于生产环境，但 Brunost 是一次有趣的语言设计探索，也是对新挪威语的庆祝。感兴趣的人可以在 GitHub 仓库中进行实验。
对不起。
## 重新思考软件安全：极简内核方法 当前的软件部署依赖于在完整的Linux内核之上运行单个进程的容器——一个庞大而复杂的系统，大多数应用程序不需要它的许多功能。这造成了一个巨大的攻击面，尤其是在处理不受信任的代码，例如第三方库或AI代理时。现有的解决方案，如精简内核或unikernel，在复杂性和维护功能方面面临挑战。 这种方法提出了一种激进的简化：与其减少内核，不如*只*构建所需的部分。分析表明，大多数进程只使用一小部分系统调用（大约40个，而总共有450个）。这个想法是将这些必要的系统调用实现为一个库——一个“库内核”，并在二进制级别拦截标准的系统调用指令（0F 05）。 通过在加载时重写二进制文件，用跳转到自定义处理程序的指令替换系统调用指令，从而绕过拦截的挑战（编译器集成、libc覆盖）。这个处理程序在轻量级虚拟机中运行，使用LSTAR MSR机制捕获JIT编译的代码，并通过自愈机制以最小的开销执行策略并模拟系统调用。 这创建了一个安全、可审计的环境，所有与系统的交互都受到控制，为安全执行不受信任的代码（如AI代理）提供了基础。这是朝着一个专注于安全和可见性的极简VM运行时迈出的第一步。
## trust-manager：简化 Emacs 信任管理
Emacs 30 引入了一项重要的安全特性：显式文件信任。虽然默认将所有文件视为不信任，从而提高了安全性，但这可能会带来不便，导致用户为了可用性而禁用该系统。`trust-manager` 包，可在 MELPA 上获取，解决了这种冲突。
具体来说，Emacs Lisp Flymake 后端等功能对于不信任的文件会被禁用，提示用户消息并需要手动配置信任。`trust-manager` 通过在首次访问项目时仅提示用户*一次*是否信任，从而简化了此过程。然后会记住这个选择。
除了这种“即时”提示之外，它还会自动信任重要的文件，例如 init 文件和加载路径上的文件。模式行指示器（？）可以直观地标记不信任的缓冲区，从而实现快速的点击信任功能。用户还可以通过 `M-x trust-manager-customize` 或专用命令直接自定义信任设置。
`trust-manager` 旨在平衡 Emacs 增强的安全性与不会鼓励禁用关键保护的用户体验。
## Emacs信任系统与安全摩擦
最近Hacker News上的一场讨论围绕着Emacs针对文件和代码的新“信任”系统，以及更广泛的安全措施阻碍易用性的问题。核心论点是，**过于严格的安全措施，产生过多的摩擦，会导致用户禁用它**，最终适得其反。
用户分享了经验，工作中严格的IT安全措施促使他们绕过官方系统，增加了风险。人们担心Emacs系统过于保守，影响工作流程（例如自动补全），并鼓励授予广泛的权限。特别是，scratch buffer的未信任状态被指出是一个错误。
许多评论者认为，根本问题不仅仅是“信任”，而是依赖于大量的外部包和代码。讨论中提出的一个潜在解决方案是基于能力的沙箱机制，类似于浏览器安全，授予特定权限而不是广泛的信任。其他人强调需要更好的权限和隔离，并指出Linux上的Firejail和Landlock等工具。
最终，这场对话凸显了安全性和开发者体验之间的紧张关系，呼吁建立更少侵入性、更具逻辑性的系统。
## 序：概要
本文探讨了“序”的数学概念——我们如何基于诸如大小或年龄之类的标准来排列对象，重点不在于*依据什么*排序，而在于排序关系本身的*性质*。序被定义为具有二元关系（通常可视化为箭头）并遵循特定规律的集合。
**线性（全）序**很简单：每个对象都有明确的位置。它们遵循自反性（一个对象与自身相关）、传递性（如果 a > b 且 b > c，则 a > c）、反对称性（如果 a > b 且 b > a，则 a=b）和完备性（每对元素都是可比较的）。
**偏序**放宽了“完备性”的要求，允许存在不可比较的元素。当无法进行完全排序时，这很有用（例如，对从未互动过的人进行排名）。偏序与线性序一样，遵循自反性、传递性和反对称性。
重要的是，序可以被视为**范畴**——具有对象和它们之间关系的结构（态射）。缺乏反对称性的预序也是范畴。序中的**并**（最小上界）和**交**（最大下界）操作直接对应于范畴中的**余积**和**积**，分别。
本文介绍了**格**（具有并和交的偏序）和**分配格**，它们通过**伯科夫表示定理**与集合的包含序相关联。最终，理解序为探索更复杂的范畴概念奠定了基础。
## Hacker News 讨论总结：范畴论图解 – 序
一个 Hacker News 讨论围绕一篇试图图解序理论的博客文章展开，序理论是范畴论的基础概念。一些人认为这篇文章是一个有帮助且易于理解的入门介绍，但许多评论者批评其数学上的不准确和含糊不清。
几位用户指出了具体的错误，尤其是在反对称性和伯克霍夫表示定理的解释方面。他们认为文章混淆了局部序和严格序等概念，导致误导性的解释。另一些人则为作者的方法辩护，认为即使有缺陷的解释对于初步理解也可能很有价值，而且许多数学教材也包含错误。
讨论还涉及范畴论的更广泛价值，一些人强调了它在编程中的应用（类型类、数据结构）以及它提供统一数学语言的能力。一个关键点是，范畴论的抽象性使其在没有坚实的数学基础的情况下显得毫无意义。推荐了 Tom Leinster 的《基础范畴论》等资源，以获得更严谨的方法。最终，该讨论揭示了数学解释中可访问性和准确性之间的争论。
展示 HN：我制作了一个在不相交区间集合上工作的计算器。
Show HN: I made a calculator that works over disjoint sets of intervals
2 天前
## 区间并集算术计算器摘要 该计算器不仅对数字进行运算，还对*区间并集*进行运算。区间[a, b]代表a和b之间的所有数字，而并集将这些区间组合起来。这种“区间并集算术”克服了标准区间算术的局限性，特别是处理包含零的区间除法和保持封闭性。 该计算器的关键特性是*包含性*：结果始终包含从输入区间计算得出的真实值。这使其非常适合表示不确定性。 它支持标准运算（+、-、*、/、^）和函数（log、sin、cos等），这些运算可能导致不相交的区间并集。 “全精度”模式利用IEEE 754双精度来保证结果包含真实值，即使存在浮点数限制（例如，准确计算0.1 + 0.2）。 输入使用括号表示法表示区间([a, b])或直接使用数字（解释为单点区间）。该项目是开源的，欢迎提交错误报告和贡献。
## IPv6 为什么是现在的样子：总结 IPv6 的复杂性常常引发疑问，为什么不采用更简单的方案——比如仅仅扩展 IPv4 地址呢？然而，仅仅增加位数会产生根本性问题。任何新的 IP 版本都需要协议变更，从而需要与 IPv4 的共存机制，主要是双栈（同时运行两种协议）或转换。这些挑战是任何地址扩展固有的，并非 IPv6 设计特有的。 1994 年决定采用 IPv6 源于对地址耗尽之外的担忧，包括 IPv4 的局限性以及 OSI 等竞争性网络协议的兴起。IPv6 的目标不仅仅是更大的地址空间，它还融合了来自这些替代方案的特性，例如自动地址配置 (SLAAC)。 虽然 IPv6 并非完美——最初对 IPsec 的要求减缓了采用速度——但替代方案（“IPv8”等）并未提供可行的改进。它们常常重新引入相同的共存问题，或者提出会破坏现有互联网基础设施的功能。部署任何新的互联网标准都需要数十年时间，DNSSEC 和 RPKI 就是证据。最终，IPv6 的核心目的——提供一个巨大的地址空间——仍然是其主要理由，而其复杂性是过渡全球网络的不可避免的后果。