Development

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

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

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

这里讨论一个犀利而无用的细节问题。事情的缘起是有人在 GitHub 上提了一个 pull request 要求把许多程序的main() 的终结部分从 exit(X) 改为 return X;，我反对了这一变动。

值得注意的是，在实践上，从 main 中 return 和调用 exit(3) 几乎等效的（此处还是有细微差别，后面将会讨论），原因是 C 运行环境库的启动部分（这部分会在连接过程中嵌入到可执行文件中，FreeBSD 的实现中，这部分位于 lib/libc/csu/libc_start1.c 的 __libc_start1：

1
2
3
4
5
6
7

void
__libc_start1(int argc, char *argv[], char *env[], void (*cleanup)(void),
    int (*mainX)(int, char *[], char *[]))
{
/* ... */
	exit(mainX(argc, argv, env));
}

原定4月25日开始的code slush和KBI冻结并未发生，主要的原因是 OpenSSL 3.0 还未合并，以及 OpenZFS 近期的一些可靠性问题。

其中，OpenSSL 3.0 由于对 API 的改动比较大，因此会导致一些 port 无法正常工作（PR 258413）。近期已经有一批 port 标记为与 OpenSSL 3.x 不兼容，不过修掉这些可能会需要不少时间。

History of qsort_r(3)

First introduced in Research Unix V3 and eventually standardized as part of C Standard Library as of ANSI/ISO C89, qsort(3) provided an abstract interface where programmers can perform sort operation over an array of objects, by supplying a pointer to that array, the total number of the member objects, the size of individual member object,as well as a compare function. The compare function is expected to take two parameters, both pointers to a member object, and it shall return a negative number, 0, or a positive number, if the first object is considered smaller, equal, or greater respectively.

由于使用的 port 的编译选项与官方的往往不一致（例如我非常讨厌 gnutls、avahi 这两个包，此外有时我希望使用一个和官方不太一样的 OpenLDAP 版本，或者采用不同的编译选项等等），我之前一直是 portmaster(8) 的用户。 portmaster 是Doug Barton 早年用 shell 脚本写的一个 portupgrade(1) 的替代品，和后者相比，它不需要使用数据库，并且充分利用了 shell 的任务管理功能实现了尽可能利用 CPU 的计算能力，我个人也从这个脚本中学到了不少shell 脚本的技巧。

不过，使用 portmaster 需要在每一台机器上都有一份 ports tree，并且由于直接操作的是本地的生产环境，因此对于比较基础的库，如 gettext 之类，或是在升级操作系统时，由于升级时间较久导致出现问题的可能性相对要大一些。另一方面，使用 port 来管理第三方软件意味着需要把联编过程中的所有依赖软件包全都都装到生产环境中，有时这是非常不经济的，例如大部分时候运行环境并不需要完整的跨平台 LLVM，等等，而使用 port 安装的话，每一个系统中都需要整体重新联编一遍。

我之前已经用过很长时间的 poudriere 了。这是一款现代化的联编系统，它充分利用了 FreeBSD 的一系列特性，包括 ZFS 快照/克隆、 tmpfs、jail 等等，支持交叉编译。除此之外它还支持使用 ccache 来减少重复编译，等等。不过，线上的机器出于习惯^H^H懒惰导致的惯性一直还是在沿用之前采用 portmaster 来进行更新。

疫情之前，娃在周末会去某个才艺班，上课的时间我觉得实在是比较无聊，于是就带上笔记本坐在星巴克做一些较小规模的代码清理工作。最终，我利用这些碎块化的时间完成了对 FreeBSD 的 fsck_msdosfs(8) 的核心代码的算法进行了改进，使其需要的内存用量变成了原先的 $1 \over 128$，这里稍微记一下当时的一些思路。

FreeBSD 最近终于完成了从 subversion 到 git 的转换（其实还没算彻底完成，不过 src/ 和 doc/ 都已经完成了）。

我个人用 git 用了蛮久了，最早开始严肃地用 git 大概是2012年年底 Illumos 从 hg 换成 git 的时候的事情，当时 FreeNAS 的开发也从 subversion 迁移到了 git，后来，我们也把 FreeNAS 内嵌的 FreeBSD 的开发搬到了 git 上面。

📜 历史文件已不具备现实意义

今天的一个偶然的发现。FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525。clang 3.8 2015/07/20 的版本同样有此问题。

之前， FreeBSD 上 strndup(3) 的实现是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

char *
strndup(const char *str, size_t n)
{
	size_t len;
	char *copy;

	len = strnlen(str, n);
	if ((copy = malloc(len + 1)) == NULL)
		return (NULL);
	memcpy(copy, str, len);
	copy[len] = '\0';
	return (copy);
}

而 OpenBSD 上的实现，则是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

char *
strndup(const char *str, size_t maxlen)
{
	char *copy;
	size_t len;

	len = strnlen(str, maxlen);
	copy = malloc(len + 1);
	if (copy != NULL) {
		(void)memcpy(copy, str, len);
		copy[len] = '\0';
	}

	return copy;
}

WhatsApp CEO及创始人 Jan Koum 宣布捐出一百万美元给 FreeBSD基金会。这是 FreeBSD 基金会成立十五年以来收到的 最大一笔捐款。

📜 历史文件已不具备现实意义

本文描述的是当时的 Google Compute Engine 行为，并未随时代更新，内容已过时。

初步尝试了一下 Google Compute Engine（G社类似 Amazon EC2的产品，基于 Linux/KVM）。确认 FreeBSD 可用（在家里用qemu建一个image出来，装好，然后打包扔到 Google 的系统上，然后用这个包建一个image，再用image起个instance）。