Development

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

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

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

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

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

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

在上一家公司的时候曾经有很多关于 cron(8) 的想法，但一直没有付诸实施，很多东西放在本地慢慢生锈了。

去年年底的时候我开始着手去修了一些 cron(8) 的 bug，其中包括为 cron 之前不够完整的 PAM 支持进行了改进。

背景：PAM

Pluggable Authentication Module (PAM) 为一系列身份验证相关的操作提供了一组通用的接口。在没有 PAM 之前，应用程序需要实现大量重复的代码来完成类似的操作，例如要求用户输入密码并进行验证等。这么做的问题在于缺乏灵活性，例如，管理员可能希望将用户数据保存到 LDAP 目录中，或是使用指纹等新式验证方式。PAM 使这些相关操作可以通过插件来完成，应用程序不再需要关心「如何验证用户身份」（用户名、密码等等是不是正确），而只需要向 PAM 询问「该用户的身份是否合法？」即可。这层抽象简化了应用程序开发者的工作，并且赋予了系统管理员更大的灵活性。

PAM 将系统的认证工作分成了四组基本操作：

• auth：验证用户身份（比如检查密码）。
• account：检查账户是否有效（比如是否过期、是否允许在此时间登录）。
• password：用于修改密码。
• session：会话管理，即用户「进门前」和「出门后」需要进行的环境搭建或清理工作。这是本次更新的核心。

什么是标点悬挂

标点悬挂 (Hanging punctuation) 是一种排版微调技术。当一行文字以标点开头或结尾时，标点可以「悬出」段落的对齐边界，使正文文字的视觉边缘保持整齐。虽然差别细微，但在大段文字的排版中，这种整齐的边缘能在一定程度上提升阅读体验。

借着 Vibe Coding 的东风，我为 blog 重新设计了一套模板，希望解决一些此前用的基于 ink 模板中存在的一些问题，并彻底清理掉一些历史包袱。

这件事还要从 Search Console 的 Core Web Vitals 报告说起。报告显示，旧主题使用的 Noto Serif SC 网页字体加载缓慢，并在渲染过程中导致了显著的累积布局偏移（CLS）问题。

在调整网站 CSS 的过程中，我逐渐意识到原有主题模板存在不少结构性问题；与其零碎修补，倒不如直接推倒重来。我的想法是，首先用 Hugo 新建一个最新版的最小模板，然后逐渐在上面添加我需要的功能，于是我列了一个需求 wishlist 清单：

前几天有小伙伴在整理某个代码仓库的时候，希望把仓库里的代码和数据分离以便于管理。由于他使用的是 git，所以很快大语言模型便引导他用上了包括filter-repo 在内的一系列禁术，其间就有了一段关于是应该使用 git submodule 还是 git subtree 的讨论。

先说我的结论，对于绝大多数人，特别是已经动了重写历史这种念头的人来说，理想的选择是 git submodule。

新的 C++ 标准中 不允许给 main 指定 linkage-specification 了。

当然，考虑到原本 main() 也是 C 运行环境在开始运行程序的时候调用的，而 C 运行环境自然也预期 C linkage，即不按照 C++ 的习惯对符号根据参数增加名字前缀，因此大部分编译器在遇到 C++ 程序定义全局 main() 的时候也会按照习惯采取 C linkage方式去翻译。这一规则首先被 GCC 采纳，随后 LLVM 也跟进了。

上周末抽时间把服务器升级到了 FreeBSD 14.0-RELEASE。软件的发布中存在许多的工序，大致上，在 releng/ 分支上的代码树会正式命名为 -RELEASE，同时由一位 Release Engineer 开始最终的 build（对应的文件会发布到 FTP 上，并在 网站 上提供链接），并在适当的时候将 releng/ 分支上的代码tag 成 release。此后， Security Team 需要将 Release Engineer 签名的 -RELEASE 放到 freebsd-update builder 上再次 build、签名，并生成二进制更新所需的文件。

由于安装用的 ISO 映像文件都比较大，传统上将这些映像文件分发到全球的镜像站点上需要一些时间。现时，云服务提供商往往还有自己的 QA 步骤，因此最终宣布 -RELEASE 的时间往往会比 FTP上出现的时间晚上一周左右。技术上这段时间这个 build 依然只是一个发布候选版本(Release Candidate)，因此普通用户不应使用这些版本，因为在这一周的时间如果遇到一些突发状况的话可能会需要将这个版本撤回(例如原本应发布为 FreeBSD 4.6.1 的 FreeBSD 4.6.2 就是这样的情况)。

软件项目中，实现同一功能的源代码只保留一份是一项十分重要的最佳实践，这种做法可以带来许多显而易见的好处：

1. 简化依赖关系管理。 对于 C/C++ 项目来说，如果同一个函数库有不同的版本，意味着必须设法确保其中不包含同一符号的多个变体。
2. 减少技术债的积累。 只保留一个版本意味着参与项目的所有开发者都使用最新版本的库，或是从一个接近最新版本的库升级到最新版本，这要比把技术债留给后人去解决要容易许多。尽管升级时需要考虑的问题会更多一些，但这也意味着更好的一致性。只留一份版本意味着在升级时必须通盘考虑全局的影响，配合持续集成测试的使用，这也会带来更好的代码品质，并让整个团队能够更快地进行迭代。
3. 节省各类存储占用。
4. 改善整体安全性。问题只需在一处进行修正。

2009年的时候 kmacy@ 做了 一些初步的工作，但后续没有继续推进。这之后 我 考虑重新把这个事给做掉，但苦于平时比较忙因此未能如愿。最终， Yoshihiro Ota完成了大部分的工作。