delphij's Chaos

统计，是让不同的专家能够从同样的数据中总结出截然相反结论的不二法门。

在这里也发一遍免得哪天 X上发表的原版 没了。

今年二月的时候，我发过一个段子：

「你是什么时候意识到自己可能需要休假了？」

「有一天我临睡前在家里的票务系统里给自己开了票，要求在家里的DNS域上添加 staging，preprod 等几个子域来符合最佳实践，然后在第二天醒来以后看到系统发出的今日待办事宜邮件的时候。」

段子归段子，我认为搭起票务系统是我在疫情期间干的最改善生活品质的一件事了。这里分享一下我的一些个人经验。

为什么你有可能会需要一套票务系统？或者说，票务系统能帮我干什么？

事务追踪系统，或者，由于其中的事务往往也被称作「票」（ticket），我个人也常戏称为票务系统， 在成规模的团队软件开发中是经常使用的一种工具。票务系统可以记录开发期间的各类任务， 将任务分解成多个可操作的子任务、为这些任务排列优先级，并将其分配给具体的人。 对任何工作而言，将工作拆解到较为具体的、可以由一个人完成，并且具有优先级和依赖关系属性的子任务， 都有助于帮助人们迅速、高效地完成工作。

在工作中我个人也很喜欢使用事务追踪系统来跟踪一些开发以外的事务性活动，并且将事务追踪系统作为一种类似笔记的工具使用， 在「票」中关联一系列相关文档，这有助于在事后总结经验或将重复性的事务性工作整理成更容易使用的形式（例如作弊条文档， 或是将常用的重复部分变成程序等等）。

前文 说到，我从2020年9月20日开始采集打印机耗材的使用情况， 当时估计该耗材可以用到2021年9月初，然而在2021年8月中开始娃就重新回到学校去上课了，因此耗材的使用大幅下降。 最终，在累计打印了7570页（硒鼓的规格是约6500页；在打印机打印到7098页之后打印机认为可以再打71页， 然后该估计值随着又打印了将近500页之后从71页逐步一路增加到了76页）之后，我决定将该硒鼓换掉。

替换 HP LaserJet P2055DN 硒鼓的操作非常简单：关闭打印机电源、把旧的硒鼓抽出、拆开新硒鼓包装， 握住硒鼓两端摇数次令碳粉分布均匀，抽出保护锁片，插入打印机，启动打印机即可。

查了一下购买记录，这个硒鼓是2022年3月4日从 TonerBuzz 购买的， 当时认为硒鼓还剩大约18%，现在看来是过虑了。此外不得不感叹一下，激光打印机真是太皮实了。

根据洛杉矶时报报道，骇客可能窃取了全部美国人的社会安全号。

社会安全号码（Social Security Number, SSN）是依据 42 U.S.C. § 405(c)(2) 发给一部分美国纳税人（包括公民、永久居民，以及有工作许可的临时居住在美国的人员）的一个九位数字。 目前，这个号码是由社会保障署（Social Security Administration）发给这些纳税人的， 尽管社会安全号码的设计本意是帮助社会保障署区分这些纳税人的，但由于它是由联邦机构签发的终生不变的数字， 因此它成了事实上的美国全国身份证识别代码，并且在税务以及许多其他地方都有使用。

之前没有特别注意这个漏洞，这里稍微记一笔。

PostgreSQL 包含一系列系统视图，这些系统视图可以用来查询系统表。 由于 pg_stats_ext 和 pg_stats_ext_exprs 这两个视图在 PostgreSQL 14-16 的 16.3、15.7 和 14.12 之前的版本中缺少了必要的访问控制， 因此未经授权的用户将可以通过这些视图访问其他用户通过 CREATE STATISTICS 创建的一系列统计数据，而这些数据可能会揭示这些未经授权的用户原本没有权限访问的数据，或是函数的执行结果。

PostgreSQL 在 16.3、15.7 和 14.12 中修正了这一问题，但这仅限于新安装的情况。 对于已经安装好的正在运行的数据库，管理员还必须重建这两个系统视图以收紧权限（加入了 WITH (security_barrier) 以及 WHERE 子句来限制访问）。 修正脚本位于源代码的 src/backend/catalog/fix-CVE-2024-4317.sql (对于 FreeBSD pkg 用户，这些修正脚本会安装到 /usr/local/share/postgresql/fix-CVE-2024-4317.sql)， 使用 psql 运行即可。

Have you ever thought about this?

In 100 years, like in 2124, we will all be buried with our relatives and friends.

Strangers will live in our homes we fought so hard to build, and they will own everything we have today. All our possessions will be unknown and unborn, including the car we spent a fortune on, and will probably be scrap, preferably in the hands of an unknown collector.

Our descendants will hardly know who we were, nor will they remember us. How many of us know our grandfather’s father?

After we die, we will be remembered for a few more years, then we are just a portrait on someone’s bookshelf, and a few years later our history, photos and deeds disappear in history’s oblivion. We won’t even be memories.

If we paused one day to analyze these thoughts, perhaps we would understand how ignorant and weak the dream to achieve it all really was.

If we could only think about this, surely our approaches, our thoughts would change, we would be different people.

Always having more, no time for what’s really valuable in this life. I’d change all this to live and enjoy the walks I’ve never taken, these hugs I didn’t give, these kisses for our children and our loved ones, these jokes we didn’t have time for. Those would certainly be the most beautiful moments to remember, after all they would fill our lives with joy.

And we waste it day after day with greed and intolerance.

其实想搭一套 paperless-ngx 已经挺久的了， 趁着四月底休假的时候搞了一动。

我们经常会有一些各式各样的 PDF 文档，例如和各种供应商、公司之间签署的文件、账单， 以及参加一些学术会议时留下的幻灯、资料等等。比较自然的办法就是创建不同的文件夹来分门别类地保存。 然而，简单地用文件系统来保存这些文件有这样一些问题：

这篇和较早的 线上重做 FreeBSD GPT 引导分区 情况有些类似，但略有不同。

前段时间 Andriy Gapon 为 Samsung 860 / 870 SSD 增加了一个 quirk。 Samsung 的 SSD 内部使用的是 8K 或 16K 的存储页，但为了和业界标准兼容， 它的控制器为 4K 扇区做了优化。

今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时， 我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：

Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for 
  gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
  (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
  to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
  alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
  (2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
  alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
  TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
  (prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
  relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
  delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK  XXXXXXXXXX
  XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)

原载于 Telegram 频道。

今天来讲个关于备份的小故事。

以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要， 所以备份自然也是必不可少的。为了确保备份的安全性， 他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。

一切看起来万无一失，直到有一天他们的系统出现了问题，需要从备份中恢复数据。

自然，有那么多份不同时间的磁带的系统管理团队是不觉得有什么可慌的， 可是等到他们拿回了一大摞磁带的时候却傻了眼。

从磁带中恢复的只有一个符号链接 (symbolic link)。

不仅如此，之前更早的磁带里也都是同一个符号链接。最终他们成功恢复了半年之前的数据， 配合数据恢复公司恢复的硬盘数据，在几个星期之后终于把东西七七八八地怼回看起来是正确的样子了。

这是怎么回事呢？原来，他们在备份的时候选择了一个目录，然后慢慢的这个目录越来越大， 直到有一天有个大聪明表示不如这样吧，我们把数据搬到一块新的、更大的盘上，然后建个符号链接。

系统运行一切正常，甚至于备份也变得快了很多呢。

这个故事告诉我们，做了自动化备份之后，时不时的就得试试看备份出来的数据是不是真的能恢复成希望的样子。