delphij's Chaos

我给本站的 RSS 和 Atom feed 加了一个纯 JavaScript 实现的 XSLT 处理器，为浏览器移除内建 XSLT 支持做准备。

本站在2021年2月5日为RSS feed和sitemap添加了XSLT样式，后来重新设计本站主题 chaos-theme 时也沿用了这一做法。

这些 XML 文档便于程序读取，但直接给人看就不太直观；XSLT 可以把它们转换成 HTML，让同一份内容同时服务于程序和人类读者。

前几天我收到了一封措辞颇为客气的邮件：

Subject: Urgent Link Update – Prevent Misinformation

Dear partner delphij.net,

It has come to our attention that your site still contains a hyperlink to our former domain. This domain is no longer managed by our organization and now carries content that could be misconstrued as affiliated with us, potentially leading to misinformation.

Please replace this outdated link with our official and active website:

Old URL: futureofflight. org
New URL: futureofflight.en-html.org

The old link appears in: https://blog.delphij.net/posts/2009/09/-/

We appreciate your cooperation in promptly correcting this matter to maintain editorial accuracy.

Best regards,

Grace Condie, Web Content Coordinator

Future of Flight Team

---

This email and its contents are confidential and intended only for the recipient. If you are not the intended recipient, please do not share or use this information and notify the sender.

大意是说，我多年前（2009年）一篇记录去华盛顿州旅行的文章里，链接到了波音飞行博物馆当时使用的域名 futureofflight.org。邮件称该域名已不再由他们维护，并建议我将其替换为「官方且活跃」的所谓新域名：futureofflight.en-html.org。

如你所见，对方还十分贴心地在旧域名中添加了空格，防止我误触；甚至还指出了有问题的 URL，行文措辞也显得颇为得体客气。

最近给 blog 增加了一个自定义的 404 错误页面。像 Hugo 这样的静态网站生成器在构建时，默认会把渲染好的 404 页面直接输出在网站根目录下，即 /404.html。

针对这类页面，我们通常希望：

1. 当访客访问不存在的网址时，服务器呈现该页面的内容，并且 HTTP 状态码必须是 404。
2. 当有人（或爬虫）直接在浏览器中访问 /404.html 时，同样呈现其内容，但返回的 HTTP 状态码依然必须是 404，而不是 200 OK。

今天收到家里的消息，北京时间2026年8月19日22时11分，姥姥在睡梦中平静地走了。

操作系统在演进过程中经常会碰到一个很现实的问题：一方面，内核和基础系统不可能几十年保持原样，数据结构会变，系统调用会增加，某些早期设计也迟早需要推倒重来；另一方面，一个已经发布出去的ABI 又不能想改就改。如果几十年间内核里的数据结构换了一批又一批，这艘船究竟还是不是当年那艘船？保证它在用户态眼里仍然是同一艘船的关键，就在于 ABI 的稳定性。否则系统每升级一次，过去编译好的程序都有可能需要重新编译，整个生态很快就会变得难以维护。

最近，FreeBSD 的 ports 代码库由于一次技术事故进行了一次历史重写。

作为一个平时基本不怎么碰前端代码的开发者，以前偶尔遇到需要折腾前端的需求时，我总有一种「摸着石头过河」的感觉。

最近我就碰到了这样一个棘手的场景：我的某个网站上需要调用的一些服务，在中国大陆的网络环境下访问时经常会出现加载失败或极度缓慢的问题。为了保证用户的浏览体验，比较理想的做法是：检测到访客来自中国大陆时，默认将他们重定向到支持大陆访问的同类型备用服务上。

今年，软件安全领域出现了一个新的变化：AI 辅助下的漏洞发掘，正在迎来真正的井喷式增长。

随着大模型对复杂代码理解能力的跃升，安全研究人员手中的工具获得了质的飞跃。这股浪潮最直观的表现，便是我们作为开源代码维护者，在收件箱里收到的大量问题报告和邮件。

⚠️ 这是一篇我关于著作权和版权的个人研究，内容未必准确，并非法律建议。

最近和一位小伙伴聊起了一个很有意思的版权问题：如果一个作品本身已经进入了公有领域（比如某国发表超过 50 年的单位作品），但它的「现代扫描件」还不到 50 年，那么直接使用这个扫描件，或者基于这个扫描件获取知识，算不算侵权？

我的观点是这样的：如果直接拿着这个高清扫描件去商用或分发，可能会存在侵权风险；但是，如果你只是提取了扫描件里传递的「知识」（也就是原本那份 50 年前的公有领域作品的内容），并且在自己的创作中没有照搬扫描件独有的特性（比如扫描者加的水印、特定的色彩修复等），那么应该认为这一作品是派生自已经进入公有领域的知识，而非受著作权保护的该知识的这种表现形式，因而并不构成侵权。

打个比方：如果有人拍了一张 17 世纪世界名画的高清照片，我看着这张照片，临摹了一幅仿制画。我认为我并没有侵犯摄影师的版权。除非我连摄影师独特的打光、其独特的拍摄角度，甚至照片上的噪点纹理也都一起画进去了。

今天，结合美国和世界各国的著作权处理原则，水一篇关于版权边界的思考。当然，本人并非法律专业，虽然工作中经常需要和授权许可打交道，但这些仅仅是个人理解，并非法律建议。

IEEE Std 1003.1-2024 (POSIX) 中对于 errno 的定义如下：

The lvalue to which the macro errno expands is used by many functions to return error values.

在更早期的 POSIX（Issue 5 及以前）以及 X/Open 文档中，曾经规定 errno 是一个外部变量（extern int errno），但这使得 errno 无法实现线程安全，因为所有线程共享同一个全局变量，一个线程的系统调用返回的错误码会覆盖另一个线程的值。因此，POSIX Issue 6（即 SUSv3 / IEEE Std 1003.1-2001）将这一要求删除，改为现在的定义：只要求 errno 是一个展开为 int 类型的可修改左值（modifiable lvalue）的宏。这为实现者提供了足够的自由度，以支持线程安全的 errno。

ISO C 标准在 C90/C89 时期已经不再要求 errno 是外部变量。