由于驾照快要过期，提前快两个月预约，今天终于轮到我来位于Santa Teresa 的DMV见识 #人类的多样性 来了。由于我家附近的广受人民群众欢迎的DLPC已经关闭，我预防性地请了一整天假。

首先说排队，此DMV对于有预约和无预约的客户是分成不同的队列在门外排队的，但无预约客户显著多于有预约的，因此如果不注意观察的话很容易排在无预约客户队列。DMV的车位显然是不够的，因此需要注意观察走出DMV的人并眼疾手快地占据车位。

预约客户需要由工作人员在一个iPad上进行checkin，但该操作只能在预约时间前10分钟才可以开始操作，因此预约客户和无预约客户相比只是前者在阴凉处冻着等，后者和一大群其他不做预约的客户在太阳底下晒着等。此步骤需要提供的材料是DMV提供的真证件预审批准书，然而尽管该批准书上有条码，工作人员依然需要通过询问预约时间、姓名并手工在一个长长的列表中选出申请人才能完成操作。为了省纸或是为了少维护一个标签打印机，排队编号是手写的。

在等待过程中，门口的工作人员不厌其烦地向排队的乡民们解释什么是真证件，为什么您老有了护照完全可以直接登机等问题。此间还有个年轻人说您看我已经在网上get inline了，放我进去放我进去，工作人员说您那个并不是预约，您这种情况还是需要排队的，年轻人的眼神从有光变化到失望再到空洞随后木然地去阳光下暴晒。

实际办理的过程其实还挺快的，大致上是确认信息准确，尽管预审文件上说携带全部文件原件但其实只需要提供护照卡，当场做一个简单的视力测试，双眼，左眼，右眼，工作人员从3组5行5列的视力表中选出三行分别读出即可。随后按指纹🫆，付费，打印收据然后去旁边排队拍照即可。

使用手机NFC用信用卡支付需要额外收2.1%手续费，驾照更新的费用为$45。

来FMT1完成 delphij.net 旧服务器的下线。

今天来讲个草台班子的故事你们也开心开心。

月初，有人为了支持C++19的时区功能在 FreeBSD 上增加了往 /usr/share/zoneinfo 里安装精简版时区数据库 tzdata.zi 的功能。同时大哥做了个自选动作，安装了一个表示时区数据版本的 version 文件。

然后ruby的rubygem-tzinfo花了。

原因是rubygem-tzinfo预期 /usr/share/zoneinfo 里面全都是TZ格式的编译好的数据，这类数据的文件开头有一个44字节的文件头，于是该包直接断言了可以读出至少44字节，而version文件只有6字节。

把version删掉发现居然就没事了，定睛一看rubygem-tzinfo遍历文件的时候把文件名里带 . 的都直接跳过了，此前我寻思，这tzdata.zi是个文本文件怎么也不可能通过接下来的断言呀。

然后Mac上这个version文件叫 +VERSION，它，以及各种Linux上有各种五花八门的自选安装的非TZ格式的文件，在rubygem包里是用排除名单的方法让系统自动绕过这些文件的。

如此复杂的一套机制竟然一直都能work。话说这个遍历的过程不能直接把异常接了跳过那些看起来不是TZ文件的文件吗？

凌晨一点，困扰于不知道为啥家里redmine突然就不能动了的家住圣何塞的李先生在看了以上rubygem-tzinfo上面一系列眼花缭乱的workaround摞workaround，一个bug是bug，一堆bug能work的现状，顿时两眼一黑，遂写了封信给增加version的大哥写信：C++库看起来并妹有真的用到这个文件，要不咱把这文件直接，🔪砍了，或者改成Mac上的名字？

今天早上，该文件被砍掉了，看起来FreeBSD 14.3 RC1之前就能完全修好了。

感恩维持这个世界运转的各路草台班子。

8 CFR 214.3中提到:

Failure of a school to receive SEVP notices due to inaccurate DSO e-mail addresses in SEVIS or blockages of the school's e-mail system caused by spam filters is not grounds for appeal of a denial or withdrawal.

写这个CFR的有高人啊，这么宅的角度都给堵上了。 #论为什么需要一个自己能控制的邮件系统

差点就顺手把某大唱片公司的YouTube频道给当作盗版商给举报了，还好在操作前先咨询了一下专业人士😢

今天这门票值了。

OS：工作有害健康。

热泪盈眶了，北京大妈都比贵司cloud有觉悟啊

花了20分钟尝试解决一个路由问题，最后发现是对RFC 3927的理解不深导致的，十五年前的设计中采用的RFC 1918编址其实才是比较正经的解法，盲目跟风采用RFC 3927地址的问题在于这些地址是链路本地（link-local）的，by definition这些地址就不应该路由所以直接在路由代码里就drop掉了，听包听了个寂寞的李先生丢开了tcpdump开始了grep，然后惊喜地发现这段代码是这么写的：

#define IN_LINKLOCAL(i) (((in_addr_t)(i) & 0xffff0000) == 0xa9fe0000)

嗯，a9fe，这个就有点巧妙了。您也别管grep找不找得到，您就说这写法是不是能把事儿给办了吧。

所以接下来的解决方案有：a）维持大致上两个站点采用星形拓扑，但将两站间共享服务放回RFC 1918内网上，b）改采网状拓扑，在几台机器之间直接拉一组N对N的网状VPN链接然后再把OSPF跑起来。

个人倾向于a，主要原因是本来这边的网络也是星形结构，最终这些端到端的VPN链接并不真的改善可靠性。转了一圈又回到了原点（只是这次搬家的副作用是内网变成/32而不是/23了，考虑到这个做法其实更方便跨机房搬家我打算以后就这么干了）

https://github.com/jemalloc/jemalloc jemalloc的代码库archived😱

体检报告出来了，真是不年轻了。

https://www.britishmuseum.org/collection/object/W_1953-0411-71 原来「收到的铜品质不对，于是愤怒地花了几个小时刻泥板来抱怨」的文物是真的… #TIL