## 程序化道路生成：连接曲线
本文详细介绍了生成平滑、逼真道路背后的核心几何原理。其基础在于“剖面”——道路的抽象横截面，充当控制点，类似于贝塞尔曲线。这些剖面定义了道路*如何*弯曲，而不是定义整个道路形状。
挑战在于仅使用直线和圆弧平滑地连接这些剖面。解决方案利用“圆角”构造：从每个剖面的端点延伸直线，找到它们的交点，然后用弧线和线段连接。
然而，简单的弧线并不总是足够的，尤其是在道路需要改变方向（“S”形曲线）时。在这种情况下，使用三次埃尔米特样条曲线计算一个中间剖面——一条由起点/终点及其切线定义的平滑曲线——并将其放置在样条曲线的拐点附近。
虽然存在边缘情况，但作者实施了一个设计约束：防止用户创建需要过于复杂解决方案的情况。这确保了鲁棒性。下一步是处理道路交叉口，并将这些构建块拼接成完整的网络。最终，这种方法提供了一个灵活的系统，用于创建多样且可信的道路布局。
每日HackerNews RSS
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
道路背后的简单几何学 (sandboxspirit.com)
9 分，作者 azhenley 1小时前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
阿米加图形
Amiga Graphics Archive
18 小时前
1985年推出的Commodore Amiga电脑，在当时拥有无与伦比的图形处理能力。 它配备了一套复杂的定制芯片，使其能够实现其他个人电脑无法企及的功能。 本网站致力于展示为Commodore Amiga家用电脑制作或使用的图形作品。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Amiga 图像 (lychesis.net)
11 分，来自 sph 1 小时前 | 隐藏 | 过去 | 收藏 | 讨论 帮助
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 欧盟电池护照：摘要 从2027年起，欧盟将要求所有新电池（包括智能手机、电动汽车和电动自行车中的电池）拥有“数字护照”。该护照是一种通过二维码访问的数字记录，详细记录电池的整个生命周期——从原材料采购和碳足迹到性能、维修历史和可回收性。 目标是促进电池材料的循环经济，减少对进口的依赖，并确保负责任的采购和回收。对于消费者而言，这意味着更大的透明度和做出明智购买决策的能力。您将能够根据环境影响比较产品，在购买二手电池时验证电池健康状况，并使用记录的维修历史验证保修索赔。 电池护照还激励制造商生产更耐用、可维修和可回收的产品。虽然该法规适用于2027年2月*之后*投放市场的电池，但现在就开始通过优先考虑电池健康并选择参与试点计划的制造商（如苹果、三星和特斯拉）进行准备是推荐的。该举措是迈向更广泛的“数字产品护照”的垫脚石，涵盖更广泛的商品，使消费者能够获取生命周期数据，从而做出更可持续的选择。
最近的 Hacker News 讨论集中在一项新的欧盟法规上，该法规要求在欧盟区域内销售的电池必须配备“数字电池护照”。然而，关于该法律的范围存在困惑。最初的文章暗示*所有*锂离子电池都需要护照，包括智能手机中的电池。但该法规正式适用于容量超过 2kWh 或用于电动汽车的电池。
评论员指出文章报道中的差异，质疑其准确性，并指出该来源是一个收据管理应用程序，而非法律分析网站。虽然护照可以增强对二手电动汽车/电动滑板车电池市场的信心，但一些人担心增加的官僚程序可能会增加成本并阻碍小型、低成本设备（如电动滑板车）的可及性，从而抵消其益处。
Spectrimage分析上传的照片，在您的浏览器中直接创建视觉色彩光谱，无需服务器连接。它首先将图像调整大小，最长边不超过300像素，然后将每个像素转换为HSL（色相、饱和度、亮度）。 颜色被分为180个色相区间（2度切片），非彩色（黑、白、灰）被单独分离。在每个区间内，像素按亮度排序，最暗/最亮的20%用于定义阴影和色调，而中间的20%代表纯色。 最后，这些颜色列以ROYGBIV顺序排列并在画布上显示，列的高度反映了色相的普遍程度。每列内的渐变视觉上表示从色调到纯色再到阴影的过渡，即使对于大型图像也能提供平滑快速的色彩分析。
一个探索在图像中可视化颜色光谱的项目最近在Hacker News上分享，引发了设计师和开发人员的讨论。核心理念在于超越简单的颜色样本，后者被认为不足以代表照片、动画和电影中细微的颜色范围。
评论者特别关注可视化效果的“迭代7”，并提出了改进建议，例如在Y轴上设置最小高度以更好地表示光谱，以及使用饱和度来区分低值和零值。 还有人建议使用对数刻度来解决颜色压缩问题，并提出一种类似于矢量示波器的极坐标表示方法。
总的来说，该项目因其引人注目的视觉效果和提供对图像颜色构成快速直观理解的能力而受到赞扬，超越了传统的条形可视化方式。 也有人请求提供该项目的源代码。
## 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 讨论
一位 Hacker News 用户 (hjconstas) 正在考虑将他对蜡封信件的热情转化为一项“蜡封即服务”(WSAS)。 最初的动机是为了打造引人注目的推广方式，他开发了一种使用帕尔帖元件和冰水快速冷冻蜡并加速封印过程的方法。
他正在评估这项服务的兴趣，提供定制蜡封，并希望进一步自动化该过程。 讨论主要集中在技术方面——例如如何使蜡居中、印章制作（可能使用 3D 打印）以及要求展示帕尔帖元件的设置视频。
评论者建议潜在市场，例如婚礼，但也讨论了定价问题，并建议每封信 4-5 美元的价格比目前的 8 美元更具吸引力。 其他人指出，类似的服务已经在意想不到的地方出现，例如手电筒推广活动中包含蜡封的感谢信。 原始发帖者承认了非 SaaS 模式的可能性，并感谢了关于定价的反馈。
## 软件开发中的替罪羊机制
软件故障很少通过客观分析来解决；相反，组织常常陷入一种**替罪羊**模式，反映了古代社会的仪式。当问题出现时，会产生对可见行动的压力，导致选择一个“受害者”——一个基础组件或技术——来承担责任，无论实际原因如何。这并非关于解决问题，而是通过归咎来恢复社会秩序。
这种“**战争理由工程**”是由那些利用失败来推动自己偏好解决方案的人推动的，他们将现有系统描绘成固有缺陷。一个损坏的功能成为拆除一个正常运行的基础的理由，即使它与故障无关。这受到确认偏差和可得性偏差等认知偏差的助长，并在低信任环境中蓬勃发展。
敏捷运动本身就是一个典型的例子，其中“瀑布模型”成为更广泛的项目失败的便捷替罪羊，从而实现方法论的彻底转变。
抵制这种模式需要严格的根本原因分析，将故障与基础分离，并根据价值评估解决方案，而不是将其视为对感知缺陷的反应。认识到这种动态——危机、替罪羊、虚假因果关系——对于培养更理性、更有效的工程文化至关重要。最终，选择工程而非叙事对于避免重复破坏和重建的循环至关重要。
这场 Hacker News 讨论围绕一篇博客文章展开，该文章批评了一种以“替罪羊”为名的解决问题倾向，尤其是在工程和政治领域。原文（未在此处包含）的核心论点是，基于证据探究事物*为何*发生，正在被寻找*谁*来责怪所取代。
评论者争论这是否是人类固有的行为（一种“人类礼仪”），或者是一种特定于文化的现象，有人指出，缺乏“意外后果”等概念的文化更容易将责任归咎于个人。 还有人指出，这种倾向也会在软件组织中显现，有时会导致个人被不公平地针对。
一个主要的争论点是作者是否准确地定义了“工程”——一些人认为作者混淆了工程与科学理解，而另一些人则认为，即使是不良系统也可以被“设计”成成功，即使这种设计令人不快。 最终，这场讨论触及了在复杂环境中理想主义原则与务实解决方案之间的紧张关系。
## Brunost：一种新挪威语编程语言
John Lindbakk 创建了“Brunost”，一种受同名挪威山羊奶酪启发的函数式编程语言——香甜、顺滑且富有深度。该语言的独特之处在于它严格执行新挪威语（Nynorsk），一种挪威书面标准，要求所有变量、函数和参数名称都符合其词典。如果未使用新挪威语，则会标记错误。
Brunost 是一种解释型语言，具有松散的类型系统，解释器使用 Zig 编写以提高速度。主要特性包括不可变性（使用 `fast`）、条件语句 (`viss`)、函数 (`gjer`)、循环 (`forKvart`、`medan`) 以及异常处理 (`prøv`/`fang`)。
作者承认该项目具有趣味性，不打算构建完整的生态系统，但欢迎贡献。示例展示了 Brunost 的功能，包括斐波那契数列、FizzBuzz 甚至康威生命游戏的实现。虽然不打算用于生产环境，但 Brunost 是一次有趣的语言设计探索，也是对新挪威语的庆祝。感兴趣的人可以在 GitHub 仓库中进行实验。
## Brunost：一种基于新挪威语的编程语言 - Hacker News 讨论摘要
一个指向“Brunost”编程语言的链接，该语言围绕挪威新挪威语方言设计，在 Hacker News 上引发了热烈的讨论。该语言旨在营造独特的挪威感觉，甚至争论着关键字的正确新挪威语术语（例如“kalkuler”与“beregn”）。
评论者探讨了有趣的概念，例如使用挪威语语法冠词（“en”、“et”、“ei”）分别表示常量、变量和集合。 还有关于遵守新挪威语语法规则的讨论，例如省略牛津逗号并要求“og”作为最终列表分隔符。
几位用户强调了这种语言在挪威政府机构中的实际潜力，特别是对于在使用挪威语变量和函数名时提高清晰度。 还有人提出了为芬兰语设计类似语言的概念，强制在参数中正确使用语法格。 一些荷兰语和挪威语母语者注意到新挪威语令人惊讶的易读性，而另一些人则表示更喜欢在编程中使用英语关键字。 讨论还涉及本地化软件的挑战以及旧程序（如 Word Basic）中翻译关键字的历史问题。
## 重新思考软件安全：极简内核方法 当前的软件部署依赖于在完整的Linux内核之上运行单个进程的容器——一个庞大而复杂的系统，大多数应用程序不需要它的许多功能。这造成了一个巨大的攻击面，尤其是在处理不受信任的代码，例如第三方库或AI代理时。现有的解决方案，如精简内核或unikernel，在复杂性和维护功能方面面临挑战。 这种方法提出了一种激进的简化：与其减少内核，不如*只*构建所需的部分。分析表明，大多数进程只使用一小部分系统调用（大约40个，而总共有450个）。这个想法是将这些必要的系统调用实现为一个库——一个“库内核”，并在二进制级别拦截标准的系统调用指令（0F 05）。 通过在加载时重写二进制文件，用跳转到自定义处理程序的指令替换系统调用指令，从而绕过拦截的挑战（编译器集成、libc覆盖）。这个处理程序在轻量级虚拟机中运行，使用LSTAR MSR机制捕获JIT编译的代码，并通过自愈机制以最小的开销执行策略并模拟系统调用。 这创建了一个安全、可审计的环境，所有与系统的交互都受到控制，为安全执行不受信任的代码（如AI代理）提供了基础。这是朝着一个专注于安全和可见性的极简VM运行时迈出的第一步。
这个Hacker News讨论围绕一种技术，该技术使用基于KVM的虚拟机在Linux二进制文件*加载时*重写每个系统调用。作者实现了一个“shim”，它拦截了客户机VM内的系统调用，提供了完整的可观察性——记录每个尝试的系统调用（即使被拒绝），并带有时间戳和结果。
一个关键点是，为什么需要重写系统调用，而KVM可以直接捕获它们并在原始二进制文件上运行。作者澄清，二进制文件并不直接在宿主内核上运行；它完全在轻量级VM内运行，这意味着像`strace`这样的标准工具无法看到这些系统调用。
相反，shim *是* 系统调用处理程序，比传统的跟踪提供更全面和防篡改的日志。关于VM架构和二进制文件加载过程的更多细节将在后续帖子中提供。SECCOMP_RET_TRACE、SECCOMP_RET_TRAP和SECCOMP_RET_USER_NOTIF等替代方案也被提及为沙箱选项。
## 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新信任模型的沮丧上，该模型旨在增强安全性。用户认为目前的实现过于严格，阻碍了开发流程。具体而言，系统错误地将scratch buffer标记为不信任，并且广泛禁止在不信任代码上进行宏展开，即使这些宏在可证明上是安全的。
多位评论者强调需要更细粒度的权限和沙盒机制，并指出Linux上的Firejail和Landlock等工具作为潜在解决方案。核心问题是安全性和易用性之间的权衡——过于激进的安全措施可能会被寻求提高效率的用户禁用。
还有人分享了使用AI生成代码的经验，表达了对代码缺乏深入理解以及拥有自己代码的价值。一个关键的结论是，信任系统需要透明，并且不能阻碍合法的工作。