TripleCamera 的博客

前端写的越烂的人，代码行数越多

我发现，前端写的越烂的人，代码行数越多。

因为他不知道怎么用最简单的方法去实现功能，他只是在那里不停的堆叠代码，直到代码能正常工作为止。

6 月 1 日（日）

谐音梗真是人类一项伟大的发明

我终于知道为什么 2025 软工结对项目要叫《影蛇舞》了——因为 MyGo 有一首歌叫《影色舞》。

我觉得谐音梗真是人类一项伟大的发明。

6 月 3 日（二）夜

嗜睡

我感觉我这两天变得非常嗜睡。可能是之前复习太累了，现在要狠狠地补觉。

昨天早上我六点半就醒了，又饿又累，没办法，只能强打精神起来，去食堂吃了个早饭。到了八点半又睡下了，一觉睡到了十一点半。醒来又赖了会床，十二点半的时候去开了组会。

今天早上是八点半醒的，还想睡但是肚子饿，没办法，只好又去食堂吃了个早饭。到了十点钟，睡下了。

醒来的时候已经是下午一点了，组会已经开完了，高考语文也考完了。突然有一种莫名的伤感。

6 月 7 日（六）

我们都知道，北航的 MOS 操作系统是从 MIT JOS 移植过来的。（如果你还不知道这一点，说明你既没有认真读过指导书、宣发页等官方资料，也没有认真看过知乎等非官方资料；甚至没有认真参与水群，因为水群里会有学长提到这一点。）

但是我们都不知道的是：MOS 到底是衍生自 JOS 哪一年的版本？毕竟指导书里没有写，学长也没有说。我曾问过高阶助教，高阶说他也不知道，具体年份已经不可考了。他还说，要是发现了 MOS 的问题，大家就一起讨论，然后把它改掉。除非涉及到核心问题，不然考证完全没有必要。

那么我为什么要去问高阶，又要费大力气去考证这个呢？原因如下：

缘起

为什么我会想到考证 MOS 的历史呢？这还要从我重做课下任务说起。我去年做实验的时候，被代码和指导书的各种问题折磨，吃了不少苦；今年做助教的时候，自然希望能改掉实验课的诸多问题——但当时想要改掉的问题已经被我忘光光了。于是我认为，要想发现实验课的不足，就要设身处地，重做一遍课下任务。可惜的是，许多助教并不看重这一点，他们认为，既然去年吃了一遍苦，今年又何必再吃呢？于是他们就没有重做课下，自然也就少了很多发现。

这不，在我重做课下的过程中，由于我对 MOS 理解的加深，越来越多的疑惑逐渐浮出水面。下面我举两个例子：

第一个例子是 KADDR 宏，这个宏的作用是将物理地址转换为 kseg0 虚拟地址，便于在内核态直接访问：

1
2
3
4
5
6
7
8
9

// translates from physical address to kernel virtual address
#define KADDR(pa)                                                                                  \
	({                                                                                         \
		u_long _ppn = PPN(pa);                                                             \
		if (_ppn >= npage) {                                                               \
			panic("KADDR called with invalid pa %08lx", (u_long)pa);                   \
		}                                                                                  \
		(pa) + ULIM;                                                                       \
	})

不过这个宏有一些问题：它没有对传入的 pa 参数作类型转换。我在写 Lab2 的时候，就曾经往里面传了个 Pte * 类型的值，结果 KADDR 就直接对指针做了加法，导致计算结果发生了溢出。在我翻看我去年的代码时，才发现我去年在同样的地方被坑过一次，甚至还发了篇帖子求助助教。

于是我和助教们讨论了一下。如果 KADDR 是一个函数，那它必定会对传入的参数进行类型转换；但 KADDR 是个宏——于是这就成为了一个暗雷。

第二个例子是 va2pa 函数，这个函数的作用是查询页表，将虚拟地址转换为物理地址：

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

static inline u_long va2pa(Pde *pgdir, u_long va) {
	Pte *p;

	pgdir = &pgdir[PDX(va)];
	if (!(*pgdir & PTE_V)) {
		return ~0;
	}
	p = (Pte *)KADDR(PTE_ADDR(*pgdir));
	if (!(p[PTX(va)] & PTE_V)) {
		return ~0;
	}
	return PTE_ADDR(p[PTX(va)]);
}

但是这个函数有个问题：它最后没有加上页偏移。于是有同学在讨论区里发帖询问这样设计的用意。高阶助教也开了个 issue，希望把这个函数移动到测试程序中。

于是我对 MOS 的代码质量产生了担忧。另外，这一届的同学们非常热情，揪出了 MOS 操作系统的许多 bug（这可能是因为我们今年开源了答案）。这加深了我对 MOS 代码质量的怀疑。

除此之外，由于 MOS 代码较为晦涩难懂，加上注释全部由英文写成，同学们在阅读代码的过程中遇到了很大阻力，于是有些同学向代码中补充注释。甚至还有人给每一行都加上注释（我个人感觉这样做无异于阐释经文），还有人将代码中的英文注释翻译成中文。

我不禁感到疑惑：MOS 的代码质量为何差强人意？MIT JOS 的代码质量本来也是这样的吗？还是说在移植的过程中出现了质量下降的问题？

前置知识

我们都知道 MOS 是从 MIT JOS 移植过来的，但这还远远不够。我在去年和今年期间搜集到了一些有关资料，为考证工作带来了便利。下面就让我向你介绍一些前置知识。

知乎

众所周知，吐槽你 6 系最好的地方就是知乎。有人在知乎上提问：如何评价北航计算机学院操作系统课程及其实验？目前已有 16 个回答。

在这些回答中，许多被害惨了的同学纷纷吐槽这门课程的不足。其中不乏一些尖锐的批评，让我们看到了这门课程在几年前是多么的不友好。另外还有同学拿这门课与 6.828 作比较，希望课程能多多吸收 6.828 的优点。

值得庆幸的是，最后一个回答发布于 2022 年——这说明近几年我们这门课并没有什么逆天操作，让同学把课程组挂到知乎上（笑）。

旧版指导书

OS 实验有一本厚厚的指导书。每年都会发布新的指导书，课程组也提醒我们不要用旧版指导书。但在去年做实验的过程中，我就对这门课程的历史产生了好奇，于是四处搜寻往届指导书。我从往届的 GitHub 仓库里翻到了学长顺手传上去的指导书，有 2023 年、2021 年、2019 年的版本。但紧接着，我找到了宝藏——旧版指导书的源代码！

根据 README 的介绍，这门课程早期的助教们于 2015 年 7 月决定要编写指导书，并在 2016 年 3 月开始编写。从开始编写以来，指导书一直在 GitHub 上开源，直到 2018 年改为自建 GitLab 托管。Releases 中有编译出来的 PDF，最后一版 v2.1.4 发布于 2017 年 10 月 10 日。

这版指导书与我们现在使用的指导书有很大不同：书名叫《小操作系统实验指导书》；没有“引言”部分，取而代之的是“编者序”（非常中二）“教师寄语”，以及一张大事表，上面记载着操作系统实验课程自 1999 年以来的发展。

现在版本指导书的“引言”部分，以及去年新增的宣发页，都包含了旧指导书的部分内容，但略去了一部分细节。

值得一提的是，指导书在 2023 年还正式出版过，名字叫《MOS 操作系统实验教程》，是一本狼书。感兴趣的同学可以去图书馆借一本看看。

旧版代码

对于操作系统实验这门课来说，GitHub 上最有价值的并不是指导书，而是学长们的代码！大多数同学在完成实验的时候，或多或少都参考过学长的代码。值得一提的是，考虑到大家课下大量借鉴学长的代码，课下题目约等于送分，加上部分学长代码有 bug，会在课上考试时爆雷；因此课程组在今年开源了 MOS 操作系统代码（含答案）（GitHub • Gitee），大家终于可以参考 100% 正确的官方代码了！

大家在参考学长代码的时候，肯定是越新越好。因为 MOS 每年都有一些小改动，太旧的代码可能没有办法正常工作。但我的目的是考古，所以代码肯定是越旧越好。就这样，在花费了一些时间翻找后，我居然找到了一份 2015 年的 MOS 源码！源码仓库的作者也是旧版指导书仓库的作者，他叫 SivilTaram，根据仓库中遗留的线索推断，应该就是大事表中所说的刘乾学长。下面让我们来好好研究一下这个仓库：

• 首先，仓库的名字叫做 Jos-mips，说明当时还没有 MOS 这个名字。
• 仓库的结构和现在的 MOS 很像，但也有一些不同：比如说，当时并没有 kern 目录，那内核代码应该放在哪里呢？
• 多个 Makefile 中都有 Zhu Like 的版权声明，时间为 2007 年，根据大事表推断，应该是参与 MIPS 移植工作的朱沥可学长。
• mips_init() 函数已经成形了。
• 现在的 vprintfmt() 函数，当时叫做 lp_Print()，意义不明。

这一天是 2025 年 4 月 8 日，找到这个仓库为我的考证工作打下了坚实的基础。

【内部资料】指导书与代码提交记录

由于我有幸担任了 2025 年操作系统实验助教，因此可以接触到内部资料：指导书和 MOS 两个仓库的提交记录。这些内部资料为考证工作带来了方便，但没有它们也能得出下文的结论。

• 指导书在 v2.1.4（2017 年 10 月 10 日）及以前的提交记录与 GitHub 上的提交记录完全重合。
• MOS 提交记录始于 2022 年 9 月 4 日。尚不清楚在此之前是使用何种方式分发代码的。
  • 根据我在当助教期间得到的信息，MOS 最开始使用的模拟器是 GXemul，CPU 架构为 MIPS R3000。近两年才改为使用 QEMU 和 MIPS32 4Kc。

MIT 操作系统课程

接下来，让我介绍一下 MIT 的操作系统课程。首先，建议阅读一下 CS 自学指南（csdiy.wiki） 对 MIT 6.S081（原名 6.828）这门课程的介绍。

由于我并不是 MIT 的学生（笑），所以只能通过翻阅官网的方式了解这门课程的历史。幸好官网对校外是完全开放的，我不仅能查阅课程资料，还可以下载各个 Lab 的代码。

在春季学期到暑假的这段时间，我将之前下载的各种资料整理了一下，准备上传到 Internet Archive。由于资料还没有整理完成，所以分了几批上传。但是 IA 的网页上传工具实在是太难用了，上传时不能新建文件夹，只能上传后再移动，在此过程中系统自动生成的文件也删不掉，于是我只好新建了一个 GitHub 仓库来暂存各种资料，并不定期同步到 IA。你可以前往 Internet Archive 或 GitHub 来查阅我整理的资料。我还请求第三方为它们做了备份，所以有了双重保险，不用怕它们丢失了。

最开始 MIT 并没有操作系统课。2002 年，MIT 开设了 6.097: OPERATING SYSTEM ENGINEERING 课程。2003 年，课程代码更改为 6.828。这门课程共分为三个部分（参考链接）：

• 讲座：课程前半部分讲解 UNIX v6 操作系统的源代码，后半部分讲解操作系统的重要概念。
• 阅读：课程前半部分的阅读材料为参考书《Lions' Commentary on UNIX 6th Edition》（中文版：《莱昂氏UNIX源代码分析》），后半部分的阅读材料为各种论文。
• 实验：2003 年共有 7 个实验（Lab），从 Lab0 到 Lab6，学生需要从头构建一个操作系统。
  • 学生需要从官网下载 .tar.gz 格式的实验代码。切换到下一个 Lab 时，需要手动应用上一个 Lab 所做的更改。

在接下来的十几年中，这门课程的结构并没有发生太大变化，让我列举其中的一些重要事件：

• 2004 年，学生构建的操作系统被命名为 JOS。（参考链接）在本文中，为了方便称呼，我将 2004 年以前的版本也称作 JOS。
• 2006 年，由于 UNIX v6 过于老旧，课程团队将其移植到了现代 C 语言和现代 x86 架构上。新系统被称为 xv6，从此课上改为讲解 xv6 源代码。（参考链接）
• 2008 年，课程组改用 Git 分发实验代码。切换到下一个 Lab 时，可以直接使用 git merge 命令进行分支合并。

到了 2019 年，这门课程发生了翻天覆地的变化：课程代码更改为 6.S081，由研究生课程变为本科生课程。同时难度大幅降低，从完成 JOS 操作系统（x86 架构）变为改进 xv6 操作系统（RISC-V 架构）。最后一次开课是在 2024 年秋季。

更多细节可以在上文提到的 mit-6.828-lab-files 项目中的 README 中找到。

MOS 断代工程

我们已经准备好了 MIT 6.828 的历届代码，以及一份 2015 年的 Jos-mips 代码。接下来，我们就可以开始为 MOS 做一次“断代”了。

根据指导书中的大事表，课程组在 2007 年发现并完成了 JOS 实验，同时开始了移植工作，到 2009 年完成移植。那么移植的到底是 2007 年还是 2009 年的版本呢？我决定把 MIT 每一年的代码都拿出来比较。

由于 Makefile 中有 Copyright (C) 2007 字样，于是我从 2007 年开始比较。我从 MIT 6.828 官网下载了 2006 年和 2007 年的代码。（注：按理来说应该下载 2007 年和 2008 年的代码，但我脑抽了。）非常可惜的是，这两年的 Lab5 和 Lab6 代码都缺失了。我只好用 Lab4 的代码进行对比。

首先，运行如下命令：

1

$ diff -ru 2006/lab4 2007/lab4 > 2006-2007-lab4.diff

得到一份 2006 年和 2007 年的 Lab4 差异。接下来，我们将这些差异与 Jos-mips 逐一比较：

• 对于 2007 年新增的内容：
  • 如果 Jos-mips 中也有，说明 Jos-mips 使用的很可能是 2007 年或更晚的版本。
  • 如果 Jos-mips 中没有，不能说明什么，因为可能本来就没有，也可能是移植的过程中删掉的。
• 对于 2007 年删除的内容：
  • 如果 Jos-mips 中还存在，说明 Jos-mips 使用的很可能是 2006 年或更早的版本。
  • 如果 Jos-mips 中也没有，不能说明什么，理由同上。
• 对于 2007 年修改的内容：
  • 如果 Jos-mips 中与 2006 年版一致，说明 Jos-mips 使用的很可能是 2006 年或更早的版本。
  • 如果 Jos-mips 中与 2007 年版一致，说明 Jos-mips 使用的很可能是 2007 年或更晚的版本。
  • 当然，大多数情况下，Jos-mips 中也没有相关内容。

在这里我举几个例子：

1. 我是占位符。

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

   diff -ru 2006/lab4/inc/trap.h 2007/lab4/inc/trap.h --- 2006/lab4/inc/trap.h 2006-10-12 03:56:25.000000000 +0800 +++ 2007/lab4/inc/trap.h 2007-10-09 23:32:52.000000000 +0800 @@ -16,7 +16,7 @@ #define T_TSS 10 // invalid task switch segment #define T_SEGNP 11 // segment not present #define T_STACK 12 // stack exception -#define T_GPFLT 13 // genernal protection fault +#define T_GPFLT 13 // general protection fault #define T_PGFLT 14 // page fault /* #define T_RES 15 */ // reserved #define T_FPERR 16 // floating point error [...]

   这里修复了一处 typo。Jos-mips 在 include/trap.h 中也有这段代码，其中的 typo 并没有修复，说明很可能是 2006 或以前。

2. 我是占位符。

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

   diff -ru 2006/lab4/kern/init.c 2007/lab4/kern/init.c --- 2006/lab4/kern/init.c 2006-10-12 03:56:25.000000000 +0800 +++ 2007/lab4/kern/init.c 2007-10-09 23:32:52.000000000 +0800 @@ -33,8 +33,6 @@ // Lab 2 memory management initialization functions i386_detect_memory(); i386_vm_init(); - page_init(); - page_check(); // Lab 3 user environment initialization functions env_init();

   这里删掉了 page_init() 和 page_check() 这两个函数的调用。Jos-mips 的 mips_init() 中也有这两个函数调用（但 page_check() 被注释掉了），说明很有可能是 2006 或以前。

3. 我是占位符。

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

   diff -ru 2006/lab4/kern/kclock.c 2007/lab4/kern/kclock.c --- 2006/lab4/kern/kclock.c 2006-10-12 03:56:25.000000000 +0800 +++ 2007/lab4/kern/kclock.c 2007-10-09 23:32:52.000000000 +0800 @@ -1,7 +1,9 @@ /* See COPYRIGHT for copyright information. */ -/* The Run Time Clock and other NVRAM access functions that go with it. */ -/* The run time clock is hard-wired to IRQ8. */ +/* Support for two time-related hardware gadgets: 1) the run time + * clock with its NVRAM access functions; 2) the 8253 timer, which + * generates interrupts on IRQ 0. + */ #include <inc/x86.h> #include <inc/stdio.h>

   Jos-mips 的 lib/kclock.c 中也有这段注释，而且和 2006 版一样，说明很可能是 2006 或以前。

证据有很多，这里就不一一列举了。总之，经过耐心比对，可以认为 Jos-mips 使用的是 2006 年或更早的版本。

随后我又比较了 2005 和 2006、2004 和 2005。最后认定 Jos-mips 使用的是 2004 年或更早的版本。我还想继续比下去，可惜 2003 年的文件已经全部丢失了（其实是路径变化，我没有找着而已），2002 年的文件全部禁止访问。

这些工作花费了我两天的时间——4 月 15 日和 17 日。

MIT OpenCourseWare

就在断代工作被迫中止的同一天，事情又迎来了新的转机。就在 17 日当天，不甘心的我试图在网上搜索 MIT 6.828 2003，结果意外发现了 MIT DSpace（MIT 数字图书馆）上的 OpenCourseWare Archive，里面有 2003 年的存档。

首先介绍一下 MIT OpenCourseWare。这是 MIT 的公开课平台，里面有各类课程的公开资料。更多信息可以去看英文维基百科，我这里就不过多介绍了。

——说起来，北航似乎也曾经有过一个公开课平台。我们知道，智学北航的网址是 spoc.buaa.edu.cn。我曾经查过 SPOC 这个缩写，它的意思是“小型私人在线课程”（Small Private Online Course），与 MOOC（Massive Open Online Course，大规模开放在线课程）互为反义词。于是我尝试了一下 mooc.buaa.edu.cn 这个网址，没想到这个网站确实存在，但是已经罢工了。翻阅存档可知，这里曾经是北航的公开课平台。哈哈。

好消息是：OCW Archive 里确实保存着 2003 年版的公开课；坏消息是：当我兴高采烈地把装着所有 Lab 代码的 ZIP 文件都下载下来以后，才发现它们都打不开。

我一度以为是 Ark 压缩文件管理工具的问题，后来换成 Windows 用 7-Zip 试了一下，还是不行。

幸好还有时光机！4 月 24 日，我从时光机下载到了 2003 年的存档，结果发现原始文件与 DSpace 上的存档并不一致。——这说明 DSpace 上的存档很有可能损坏了。但具体是哪里的问题呢？我用 xxd 将两个版本的 lab1.zip 转换为十六进制文本文件，但是由于我的注意力比较涣散（笑），并没能发现其中的不同。直到我将每行显示多个字节拆分为每行一个字节，注意力才变得集中起来——

注意到所有十六进制大于等于 80 的字节全部被替换为 EF BF BD，也就是 U+FFFD。因此推测工作人员在归档过程中可能不小心以 UTF-8 格式保存了这些二进制文件。

没想到 MIT 的员工也会犯这么低级的错误😕。

真相大白

进一步对比 OCW 2003 版和 2004 版以后，我几乎可以肯定，MOS 使用的就是 OCW 2003 版。学长们当年很有可能从 MIT OCW 下载了这门课的代码，然后将其移植到 MIPS。当然，最后还剩下一点小小的疑惑，就是为什么他们在 2007 年尝试 JOS 的时候选用的是 OCW 2003 版，而不是 OCW 2006 版。一种可能的解释是，2006 年的课程在 2007 年 3 月上线，在此之前 OCW 上放的是 2003 年课程。

既然现在已经有了 MOS 当年参考的 JOS 源码，我们就能好好解答一下之前提出的那些问题了：

为什么 KADDR 不会对 pa 做类型转换？

我们可以在 inc/mmu.h 中找到 KADDR 的定义：

1
2
3
4
5
6
7
8

// translates from physical address to kernel virtual address
#define KADDR(pa)						\
({								\
	u_long ppn = PPN(pa);					\
	if (ppn >= npage)					\
		panic("KADDR called with invalid pa %08lx", (u_long)pa);\
	(pa) + KERNBASE;					\
})

很显然 JOS 也没有做类型转换。但他们在 2004 年版中加上了（此时这一定义移动到了 kern/pmap.h）。

1
2
3
4
5
6
7
8
9

// translates from physical address to kernel virtual address
#define KADDR(pa)						\
({								\
	u_long __m_pa = (pa); \
	u_long __m_ppn = PPN(__m_pa);				\
	if (__m_ppn >= npage)					\
		panic("KADDR called with invalid pa %08lx", __m_pa);\
	__m_pa + KERNBASE;					\
})

这说明他们很可能是忘记了，后来经过同学提醒加上了。

我觉得这个补丁完全可以 backport（向后移植）给 MOS。

为什么 va2pa() 最后没有加上页偏移？

让我们看看 JOS 的写法（所属文件 kern/pmap.c）：

1
2
3
4
5
6
7
8
9

//
// Checks that the kernel part of virtual address space
// has been setup roughly correctly(by i386_vm_init()).
//
// This function doesn't test every corner case,
// in fact it doesn't test the permission bits at all,
// but it is a pretty good sanity check. 
//
static u_long va2pa(Pde *pgdir, u_long va);

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

static u_long
va2pa(Pde *pgdir, u_long va)
{
	Pte *p;

	pgdir = &pgdir[PDX(va)];
	if (!(*pgdir&PTE_P))
		return ~0;
	p = (Pte*)KADDR(PTE_ADDR(*pgdir));
	if (!(p[PTX(va)]&PTE_P))
		return ~0;
	return PTE_ADDR(p[PTX(va)]);
}

声明处的注释提到，这个函数是用来检查虚拟地址空间是否设置正确的。实际用例也证明了这一点：

• JOS：kern/pmap.c 文件下的 check_boot_pgdir() 和 page_check() 函数。
• MOS：kern/pmap.c 文件下的 page_check() 函数，kern/env.c 文件下的 env_check() 函数，以及 lab2_2 和 lab2_3 测试点。

——全部为测试函数。

另外，到了 2005 年，JOS 将这个函数重命名为 check_va2pa()，并增加了一些注释。可能是为了强调这个函数只能用于测试吧。

1
2
3
4
5
6
7
8
9

//
// Checks that the kernel part of virtual address space
// has been setup roughly correctly(by i386_vm_init()).
//
// This function doesn't test every corner case,
// in fact it doesn't test the permission bits at all,
// but it is a pretty good sanity check. 
//
static physaddr_t check_va2pa(pde_t *pgdir, uintptr_t va);

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

// This function returns the physical address of the page containing 'va',
// defined by the page directory 'pgdir'.  The hardware normally performs
// this functionality for us!  We define our own version to help check
// the check_boot_pgdir() function; it shouldn't be used elsewhere.

static physaddr_t
check_va2pa(pde_t *pgdir, uintptr_t va)
{
	pte_t *p;

	pgdir = &pgdir[PDX(va)];
	if (!(*pgdir & PTE_P))
		return ~0;
	p = (pte_t*) KADDR(PTE_ADDR(*pgdir));
	if (!(p[PTX(va)] & PTE_P))
		return ~0;
	return PTE_ADDR(p[PTX(va)]);
}

我觉得这个补丁 backport 不 backport 都行。

通过这两个示例可以看出，由于 2003 年是 JOS 被创造出来并用于教学的第二年，2003 年版的 JOS 难免有一些漏洞。

更多发现

MOS 的 user/include/fs.h 中记录了文件系统魔数（magic number）：

1

#define FS_MAGIC 0x68286097 // Everyone's favorite OS class

这是同学们喜闻乐道的小彩蛋，体现了我们这门课程来自 MIT 6.828。往年甚至有同学傻乎乎地去讨论区问这串数字是什么意思，大家只是点赞不说话。

唉，让我给这些云里雾里的同学解释一下吧！

既然有了 JOS 的源代码，我们就可以很轻易地在 JOS 的源代码中找到这一句（inc/fs.h）：

1

#define FS_MAGIC	0x68286097	// Everyone's favorite OS class

前四位 6828 显然代表 6.828，那后四位 6097 呢？如果你认真读了这篇文章的前半部分，你会认识到它们代表 6.097，也就是这门课程在前一年的旧代码。2003 年引用 2002 年的代码，非常合理吧。

另外 2006 年，这个魔数变成了 0x4A0530AE，旁边的注释是“related vaguely to 'J\0S!'”（4A 是 J 的 ASCII 码，53 是 S 的 ASCII 码，中间的 0 和 O 相似，大概吧）。2006 年以后很长一段时间似乎都没有变，04、05 年什么样我就不知道了。

北航与 MIT 指导书在 Lab6 中管道竞争部分的内容相似度很高，说明当初编写指导书时肯定参考了 MIT 的指导书。可惜 MIT 的指导书没能流传下来，也许是不小心弄丢了。（当然，也不排除另一种可能：学长们编写完指导书后觉得 MIT 的指导书没用了，就故意扔掉了。）

展望未来

通过考证历史，我们终于揭开了 MOS 身上的重重的谜团。然后呢？接下来该怎么做？这些工作有什么意义？下面我分享一下我个人的看法。

首先，通过考证，加深了我们对 MOS 历史悠久这一点的认识。在此之前，我们一直以为 MOS 的历史从 2007 年开始；但这些工作将 MOS 的历史上溯到了 2003 年。许多同学都认为 MOS 已经过时了。诚然如此。从 2003 年到 2025 年，MIT 的操作系统课程一直在迭代，到现在已经发生了翻天覆地的变化。但 MOS 从 2009 年移植到 MIPS 架构以来，整体的课程设计并没有发生大的变化。虽然助教们做了许多移植方面的工作，比如将 MOS 从 GXemul 移植到了 QEMU，从 R3000 移植到 4Kc，但这些变化始终没有触及到根本。

同学们希望进行课程改革。比如这届就有助教希望推翻 MOS。但是大刀阔斧的改革必然需要消耗大量精力。这些年计院和软院一直拿不出足够的精力来改革，加上今年削减了助教名额和补贴，改革成了一件遥遥无期的事情。在此之前，我们还是得继续用 MOS。

其次，在我“重新发现”JOS 以后，我们需要来一次“重新移植”。虽然大家都知道 MOS 移植自 JOS，但当年的助教们没有保存好关于 JOS 的资料，以至于 JOS 的源代码和资料都没有传下来。后来的助教们只能按照自己的想法，为 MOS 打上各种补丁。考虑到助教们的水平有限（S.T.A.R. 助教全部为本科生），代码质量劣化是在所难免的事。加上 2022 年以前 MOS 的代码没有使用 Git 管理，导致现在连打补丁的历史也几乎不存了。

既然现在已经找到了当年移植所参考的 JOS 源码，那么我们就可以挑选出 JOS 中闪光的地方，“重新移植”到 MOS 已经腐烂的地方上。代码质量不能再劣化下去了，最好能从现在开始有所改观。

最后，考虑到 2003 年版 JOS 漏洞较多，我们可以研究更新版本的 JOS，取其精华 backport 到 MOS，给 MOS 来一次“升级”。考虑到 2004 和 2005 年版不完整，我们可以将 OCW 2006 年版设置为下一个目标。MIT 的操作系统课用 JOS 一直用到了 2018 年，所以理论上来说可以一直“升级”到 2018 年版。当然实际操作起来大概率是到不了的。

我的助教生涯已经结束了。希望后面的助教可以学习一下 MIT 6.828 2003，然后对 MOS 进行改进。

感想

写到这里，回顾我这一学期以来的考证工作，不由得感慨万千。我打算把我的这些感想都留在这里。

操作系统课每年都要培养五百多名学生。这五百多人中，有多少人曾经对 MOS 的历史产生过好奇呢？操作系统课每年都要招收约二十名助教。这二十人中，有多少人对 MOS 的代码质量产生过疑惑呢？

这使我想起另一件事来了。有学生在讨论区里询问 Thinking 4.9 的第一问是否有问题。我和另几位助教讨论以后，一致认为有问题，但由于出题的助教没有留下答案，我们也无法得知他的意图，只好打算把这一问删掉。

经过考证，这道思考题是 2018 年加入的，距今已有七年时间。没想到这七年间，大部分同学都在想方设法地阐释这道思考题的合理性；可能有同学在心中产生过怀疑，也可能有同学向助教表达过质疑，但并没有获得助教的关注。这让我感到非常失望。指导书不是完美无缺的，MOS 也不是，学长学姐们留下的博客更不是。我们乐于看到大家的质疑，而非盲从。

二十年前的助教们学习 MIT JOS，并把它移植到 MIPS 平台上。十年前的助教们照着 MIT 的指导书编写北航自己的指导书，激昂文字，别管看不看得懂，反正激昂就对了。——那些历史已经离我们远去了。那些历史材料没有保存好，是学长们的失误，我们也无法挽回了。

着眼现在。我知道许多同学对 MOS 有所不满，对操作系统这门课程有所不满，乃至对计院、软院的培养方案也有所不满。这并没有什么问题，一方面，上一轮课程改革已是十年以前，经过十年的时间，你 6 系引以为傲的体系结构课已经僵化了。另一方面，考虑到这些年的内卷情况逐渐加重，助教们不得不更加关注自己的保研加分，课程改革缺乏动力。现在体系结构课程已经开始削减助教预算和人数了，未来甚至有取消保研加分的风险。改革已成为了遥遥无期的事情。

但是我认为，大家作为助教，不应该将眼光局限于完成带领一届学生的任务，拿到保研加分。还应该为下一届、下下一届，为这门课程的未来着想。虽然今年少了两个高阶助教名额，但是我们也注意到了一些变化：今年助教团队中，软院学生人数明显增加。我们推测，这可能是因为 S.T.A.R. 助教取消保研加分的消息传了出去，导致对保研加分更加敏感的计院学生人数下降。只能说，希望这届助教能更有责任吧。

最后，我想借《编程》《边城》中的最后一句话结束本文：

课程改革也许永远不会开始了，也许明年开始！

从去年 5 月开始撰写这篇文章以来，转眼已经过去半年了。其实本文的主体部分早在去年暑假就已经完成了，只剩下部分细节的补充，以及修改润色环节。但是因为考研和种种杂事一直拖到现在才完成。在这半年多的时间里，外部环境发生了一些变化：2406 取消了 STAR 助教的保研加分，MOS 在 2022 年以前的提交记录也找着了（其实它一直都在，只是我们都不知道而已）。因此，本文中描述的某些情况已经过时了——但是我不想再去写最近发生的这些事情了，这样下去真写不完了。因此，本文描述的情况会截止到去年暑假，也希望大家能体会到那段时间助教们对这些事情的看法。

最后感谢另两位 OS 助教帮我审阅这篇文章。就此匆匆定稿。

2026 年 2 月 17 日

最近我们为 OSome 做了一次兼容性更新，使其能够兼容新主楼机房的 Firefox 70。

背景

上周四（3 月 27 日）是我第一次去新主楼上机，我被那里的环境震惊到了：

• 讲台上没有教师机，也不能统一控制所有机器开关机。
• 助教说课程平台只能用 Chrome 浏览器访问，跳板机和 GitLab 仓库只能用火狐浏览器访问。（什么规则怪谈）
• 电脑无法联网校准时间，只能手动校准。时间过快过慢都进入不了系统。

开始考试的前几分钟，好几个同学反映无法正常访问系统。经过一番排查，我们最终通过换浏览器、校准时间、换座位等方法解决了这些问题。在接下来的一个多小时里，倒是没有多少同学寻求帮助，于是我打算趁机研究一下上面说到的那条“规则怪谈”。

首先看一下电脑配置：

• Windows 7 Service Pack 1
• Google Chrome 79.0.3945.117
• Mozilla Firefox 70.0.1

再看一下症状：

• 对于课程平台，使用 Chrome 可以正常打开，使用 Firefox 打开后显示为空白。
• 对于跳板机和 GitLab，使用 Firefox 可以正常打开，使用 Chrome 打开时提示证书错误，但是选择继续访问后可以正常访问。

原因

使用 Firefox 打开课程平台，然后打开控制台，可以看到一条报错信息：

1

SyntaxError: invalid regular expression flag s

我根据旁边提供的代码行列坐标定位到了出错的语句，然后复制到控制台重新运行了一遍，确认是这条语句导致的错误。

然后我上网搜索了一下。MDN 的报错信息解释页面上说是正则表达式写错了，FreeCodeCamp 上说换成 Chrome 就能解决……还是看看 Bugzilla 和 MDN 浏览器兼容性数据是怎么说的吧：

正则表达式的 s 旗标于 ES2018 加入。对 s 旗标的支持早在 2017 年就已提出，但直到 2020 年 6 月的 Firefox 78 才支持。反观 Chrome，早在 2017 年 10 月发布的 Chrome 62 中就已支持了这一功能。

考试结束后，我对错误的来源展开了调查。首先我需要安装 Firefox 70 来稳定复现这一漏洞。由于在 Linux 上直接安装旧版可能会破坏系统环境，我暂时换到了 Windows。（有人向我推荐了 mozregression，日后可以试一下。）确认稳定复现之后，就可以开始深入调查了。

启动开发服务器（debug 构建），并在 chunk-vendors.js 中查找出问题的正则表达式 /^-{3}\\s*[\\n\\r](.*?)[\\n\\r]-{3}\\s*[\\n\\r]+/s，可以找到来源文件：

1
2
3
4
5
6
7
8
9

/***/ "./node_modules/mermaid/dist/mermaid.min.js":
/*!**************************************************!*\
  !*** ./node_modules/mermaid/dist/mermaid.min.js ***!
  \**************************************************/
/***/ (function(module, exports, __webpack_require__) {

eval("...");

/***/ }),

然后使用 npm list mermaid 来检查 mermaid 的版本：

1
2
3
4

> npm list mermaid
pendulum-frontend@0.1.0 D:\Code\osome\pendulum-frontend
└─┬ @wekanteam/markdown-it-mermaid@0.6.2
  └── mermaid@9.3.0

可以看到，mermaid 作为 @wekanteam/markdown-it-mermaid 的依赖项被安装，且版本为 9.3.0。

我直接在 mermaid 的 GitHub 仓库上开了个 GitHub Codespaces。经过一番 blame，确定相关正则表达式引入自 mermaid-js/mermaid#3706，于 2022 年 11 月 21 日合并，于 v9.3.0 发布。另外，通过搜索构建成品，可以发现 v9.3.0 含有相关正则表达式，而上一个版本 v9.2.2 不含，从而得出相同的结论。

因此将 mermaid 降级到 v9.2.2 即可解决问题。

解决方案

为了确保不会出现依赖问题，我们在降级 mermaid 的同时还要降级 @wekanteam/markdown-it-mermaid。以下是二者的版本对应关系：

因此，我们需要将 mermaid 锁定在 9.2.2，同时将 @wekanteam/markdown-it-mermaid 锁定在 0.6.1。package.json 的配置如下：

1
2
3
4
5
6
7

  "dependencies": {
    "@wekanteam/markdown-it-mermaid": "0.6.1",
    // ...
  },
  "overrides": {
    "mermaid": "9.2.2"
  },

使用 Firefox 70 访问，网站内容可以正常显示了。

另外控制台还有两处报错，它们的原因也很快被找到了：

• 打开教程时报错：SyntaxError: invalid regular expression flag s——这是因为教程中的某些组件会加载远程服务器上的 OSome，从而引发相同的报错。
• 报错：SyntaxError: invalid identity escape in regular expression——这是因为依赖项 mavon-editor 尝试加载高版本的 highlight.min.js。由于目测讨论区的 Markdown 编辑器没有受到影响，加上考试时并不需要用到讨论区功能，因此暂时不予修复。

不得不说我对 Vue 的理解还是太浅薄了。

问题

这学期我担任 OS 开发组助教，任务之一就是制作宣发页。

宣发页使用 Vue 3、Vuetify 3、Vue Router 4 制作。现在有个需求，需要让助教列表支持查看往届助教。由于我那段时间没空，这项任务就交给了另一位助教。经过几次修改后，这项功能合并到了主分支。下面是最小复现示例：

Vue Playground

值得注意的是，最初的版本不长这个样子。在最初的版本中，“课程助教”选项卡是用 <v-btn> 实现的，点击展开菜单，再次点击菜单项即可跳转——和官方文档里的溢出到菜单示例几乎一模一样。但是每个 <v-tab> 下方都有一个横条（文档中叫 slider），用来指示当前选中的选项卡。而 <v-btn> 下方没有 slider，这就导致路由切换到“课程助教”页面时，slider 并不会自动更新，还位于其他选项卡下方：

于是这位助教改成了用 <v-tab> 套 <v-btn> 实现，并把交互逻辑改成了悬浮展开菜单、点击跳转。一位高阶助教又在此基础上进行小修，将 <v-btn> 改为 <button>，修复了样式问题。

不得不说，这位助教的实现虽然能用，但是存在一些问题：

• 用户在没有外部提示的情况下，往往会直接点击选项卡，很难发现需要悬停才能展开菜单。（文字右侧本来有一个下三角图标的，可惜去掉了，再加回来就好）
• 移动端无法做出“悬停”这一动作（长按什么的都不行），因而无法展开菜单。
• 视觉上有一点不足是，目前被选中的菜单项（2024/2025）不会显示为选中状态。
• 最后，代码写得非常不优雅。通过 CSS 让按钮和其他两个选项卡一样宽。navigateTo 函数更是不知所云，结尾为什么要调用 nextTick，这位助教也说不清——他说他是用 ChatGPT 写的。

我希望能重新实现这个功能，目前有三个策略：

• 上策：既使用 <v-tab> ，又支持点击展开菜单。另外“课程助教”选项卡和其下的菜单项能够正确显示为选中状态。
• 中策：为了支持点击展开菜单而放弃 <v-tab> 的 slider，改回之前的 <v-btn>。在此基础上，菜单项要能够显示为选中状态。
• 下策：彻底放弃选项卡套列表的布局，改为在 AssistantPage 内部做一个下拉菜单。

第一版

简化

首先我查阅了 <v-tab> 的 API 文档，在里面找到了 to 选项。这个选项对应 Vue Router 的 to 属性，用这个比自己实现函数方便多了。于是我把 @click="navigateTo(item)" 换成了 :to="`/assistant?year=${item}`"。

修改后出现了一个问题，当我查看助教列表时，2025 和 2024 两个列表项都会处于选中状态。幸好，API 文档里提到了 exact 属性，加上以后，就只有当前选项卡处于选中状态了。

注：<v-tab> 的 exact 属性对应旧版 Vue Router 中 <router-link> 的 exact 属性（现已移除），其要求当前路径与给定路径完全相同（包括 query 参数）。

提问

接下来我不知道该怎么做了。于是我想去 StackOverflow 提问。考虑到光贴代码不好测试，我用 CodeSandbox 制作了一个最小复现示例，然后附到了我的问题上。随后有人提醒我，如果链接失效，我的问题将变得一文不值，于是我又附上了完整的代码。

Vuetify 源码分析

问题提完后，我又回到了研究中。我用开发者工具给选项卡标签（<a>）打上了“属性修改时”断点，开始调试。但由于调用堆栈过于混乱，无法追踪（这里面还涉及到了事件队列），只好改为阅读 Vuetify 源码。值得一提的是，用 GitHub Codespace 看源码真的非常方便。

根据堆栈信息，我们找到了以下文件：

/packages/vuetify/src/composables/group.ts

1
2
3

  watch(isSelected, value => {
    vm.emit('group:selected', { value })
  }, { flush: 'sync' })

/packages/vuetify/src/components/VTabs/VTab.tsx

1
2
3
4

        <VBtn
          ...
          onGroup:selected={ updateSlider }
        >

我花了很久的时间来研究 updateSlider 函数，最后发现是一堆复杂的数学计算，用来实现滑条移动的动画……

可惜的是，以上这些代码中并没有响应点击事件的逻辑。下面这个才是重点：

/packages/vuetify/src/components/VBtn/VBtn.tsx

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

    function onClick (e: MouseEvent) {
      if (
        isDisabled.value ||
        (link.isLink.value && (
          e.metaKey ||
          e.ctrlKey ||
          e.shiftKey ||
          (e.button !== 0) ||
          attrs.target === '_blank'
        ))
      ) return

      link.navigate?.(e)
      group?.toggle()
    }

最重要的是最后两行。先看一下 link 和 group 的定义：

1
2

    const group = useGroupItem(props, props.symbol, false)
    const link = useLink(props, attrs)

先说 link.navigate?.(e) 一行，其中 useLink 函数是对 Vue Router RouterLink.useLink() 的封装。所以这个 link.navigate?.(e) 其实是调用了 RouterLink 的 navigate() 方法。

再说 group?.toggle() 一行。在 useGroupItem() 中可以找到 toggle() 的定义：

1
2
3
4
5
6

  return {
    ...
    toggle: () => group.select(id, !isSelected.value),
    select: (value: boolean) => group.select(id, value),
    ...
  }

看来是在更新选项卡所在组（也就是 <v-tabs> 选项卡组）的数据。

很遗憾，这次源码分析并没有找到多少实用信息。但就在这时，有人回答了我的问题——但只有一个人。他的解决方法是监听选项卡的状态更新，然后判断这次更新是否是通过点击“课程助教”选项卡造成的——如果是的话就把状态改回去，然后弹出菜单。可惜的是，他并没有用 Vue Router，因此对我的价值也不大。

不过，他这种方法给了我一些启发……

更多 Vuetify 源码和一些 Vue 特性

他的回答中提到了 update:model-value，这是文档中记录的一个事件（文档中称之为 update:modelValue）。VTabs.tsx 中确实定义了这个事件，但并没有触发，我通过研究发现触发逻辑写在 useProxiedModel() 里。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

  emits: {
    'update:modelValue': (v: unknown) => true,
  },

  setup (props, { attrs, slots }) {
    const model = useProxiedModel(props, 'modelValue')
    ...
    useRender(() => {
      ...
      return (
        <>
          <VSlideGroup
            ...
            v-model={ model.value }
            ...
          >
            ...
          </VSlideGroup>

          ...
        </>
      )
    })
    ...
  },

至于 v-model 这个属性，文档中也有多个示例使用，是用来绑定选项卡组状态的，其值为当前选中的选项卡。你可以为 <v-tab> 设置 value 属性，如果不设置的话，默认就是 0、1、2……

接下来，我通过查阅 Vue 文档了解了 v-model 的底层原理：原来 v-model 会展开为 v-bind 和 v-on！那么，如果我不用 v-model 这个简写，而是手动指定 v-bind 和 v-on，那我岂不是可以控制数据的更新了？

于是我给 <v-tabs> 加上了 v-bind:model-value 和 v-on:update:model-value，并对数据更新进行了拦截：如果新值为 2 就不更新，其他情况下正常更新。这可比等它更新完再改回去要方便多了。

1
2
3
4

        <v-tabs
          :model-value="selectedTab"
          @update:model-value="$event => $event !== 2 ? selectedTab = $event as number : undefined"
        >

以及在 <v-menu> 被点击时手动更新选项卡状态：

1
2
3
4

                <v-list-item
                  ...
                  @click="selectedTab = 2"
                />

最后要清理旧逻辑。“课程助教”选项卡不需要点击跳转了，也就不需要 to 属性了；<v-menu> 从也可以悬停弹出改为点击弹出了。navigateTo() 和那堆 CSS 都用不到了，可以删掉了。以下是第一版的代码：

Vue Playground

第二版

看上去非常好！可惜还有一点美中不足：如果先进入助教列表页面，然后刷新，那么 slider 会回到“发展历史”下方，而不是继续停在“课程助教”下方。

在 Vue Playground 中，我们使用的是 Memory 模式，因此当前路由不会记录在 URL 中。当你刷新页面时，你会回到初始路由 /。若要改变初始路由，请在 router.ts 中创建 router 后加入如下代码：

1	router.push('/assistant?year=2025');

在着手修复这个小 bug 之前，不妨让我们先回头看一下第一版的改动。我们可以使用 v-model 来将 <v-tabs> 的状态双向绑定到 selectedTab 上。v-model 会被展开为 v-bind:model-value 和 v-on:update:model-value，前者将 selectedTab 的值传入 <v-tabs>，后者在 <v-tabs> 更新状态时将新值同步到 selectedTab。即前者读取 selectedTab，后者写入 selectedTab。我们所作的修改是：

• 拦截正常写入逻辑。当 <v-tabs> 欲写入的新值为 2 时，不写入。
• 额外新增写入逻辑。当点击菜单中的菜单项时，写入 2。

目前的问题是缺乏初始的写入逻辑。那么最简单的解法就是在初始化时根据当前路由设定初始值。

次优解

只需要在 app.vue 的 <script setup> 中添加如下代码：

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

import { useRoute } from 'vue-router';
const route = useRoute();
switch (route.path) {
  case '/':
    selectedTab.value = 0;
    break;
  case '/professor':
    selectedTab.value = 1;
    break;
  case '/assistant':
    selectedTab.value = 2;
    break;
  default:
    selectedTab.value = -1;
    break;
}

即可正确初始化 selectedTab。注意在 <script setup> 中不能使用 $route，需要通过 useRoute() 来获取 route 对象。

最优解……？

虽然问题解决了，但是我还想介绍一种更简单的方法。

我在 StackOverflow 上搜索如何获取当前路由的时候，看到这个问题以及其下的许多回答都提到了 计算属性（computed）。于是我去了解了一下计算属性，然后发现之前的逻辑完全可以使用计算属性重写。

我们将 selectedTab 改为计算属性实现，让其在路由改变时自动变化。这样就不需要再去手动更新它了，<v-tabs> 的 @update:model-value 和 <v-list-item> 的 @click，都可以删掉了。

以下是重写后的 <script setup>：

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

import { computed } from 'vue';
import { useRoute } from 'vue-router';

const route = useRoute();
const years = ["2025", "2024"]
const selectedTab = computed(() => {
  switch (route.path) {
    case '/':
      return 0;
    case '/professor':
      return 1;
    case '/assistant':
      return 2;
    default:
      return -1;
  }
});

总揽全局，我们发现：点击按钮时路由更新，路由更新触发 <v-tabs> 组件状态更新，组件状态更新触发 slider 更新。现在我们所做的，就是重写“路由更新触发组件状态更新”这一步骤。

最后我们修复两个小 bug：

• 点击“课程助教”时菜单栏的位置和选项卡略有重叠，这是 <v-tab> 嵌套 <button> 搞的鬼，把 <button> 去掉即可。
• 给“课程助教”右侧加个下三角图标。

结果没想到，修了这两个 bug 又引入了新的 bug？！

现在点击“课程助教”时，slider 会直接滑动到“课程助教”下方。这使我百思不得其解。我用 Vue DevTools 看了一下，发现在教师团队页面点击“课程助教”选项卡时，虽然 <VTabs> 的 modelValue 属性仍然为 1，但 <VSlideGroup> 的 modelValue 属性却已经变成了 2。这是为什么？？

我不由得对之前没有弄懂的 useProxiedModel() 产生了怀疑。但是由于实在看不懂这个函数的内容，只好交给 Copliot 解释。

豁然开朗了。由于我们删掉了 <v-tabs> 的 @update:model-value，导致 useProxiedModel() 认为 <v-tabs>“不受控”，于是只会将外部 modelValue 的更新单向同步到内部，而内部 modelValue 的更新则不会同步到外部。这就导致内外 modelValue“脱节”。

那么该如何解决呢？我们可以向 <v-tabs> 传入一个空的 @update:model-value，但那样只会让代码变得更乱。如果我们能将读写逻辑封装在一块儿就好了。——之前研究计算属性时瞥到过的可写计算属性就派上用场了。

成功！

以下是最终版的 selectedTab：

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

const selectedTab = computed({
  get() {
    switch (route.path) {
      case '/':
        return 0;
      case '/professor':
        return 1;
      case '/assistant':
        return 2;
      default:
        return -1;
    }
  },
  set() {
    // Do nothing.
  }
});

以下是最终版的代码：

Vue Playground

后记

这次探索真的非常不容易！虽然最后的代码实现看上去并不复杂，但是为了写出它们，我阅读了 Vuetify 源码，并学习了 Vue 的各种机制。由于我对 Vue 的理解尚浅，缺乏实践经验，导致研究的过程更加的冗长。

但是，这次探索也非常有意义。它让我对 Vue 和 Vuetify 有了更深入的理解。在此之前，我只会“搭积木”似的将各种组件“缝”在一起，这是我第一次对组件进行深入的自定义。

在探索初期，我曾让 Copilot 帮我实现需求，但它并没能写出让我满意的代码。那时 DeepSeek 刚刚火起来，可惜我后来并没有尝试让 DeepSeek 实现，之后如果有机会，可以问问 DeepSeek，看看它能不能做出来。

另外如果你对我的研究过程或实现方式有任何的建议，欢迎在讨论区提出。谢谢！

开学第一天

今天是开学第一天。

早上九点，我不情愿地起了床。走到食堂，看着琳琅满目的食物，不知道该吃什么。突然灵机一动：就吃泡面吧！

吃完泡面，就骑车去上课。今天唯一的一节课是上午三、四节的算法。老师念 PPT，超无聊。

这是课上唯一一件有意思的事：老师问，什么是算法；有人答，\(程序 - 数据结构 = 算法\)。

晚上六点我去食堂吃饭，七点要开组会。到了食堂又不知道该吃什么，突然灵光一现，想吃地下一层的肉酱面，但那里的队很长。我以为组会七点半到八点就能结束，于是打算开完会再去吃饭。结果没想到我们一边开会，一边闲聊，一直拖到九点才开完。我本来已经对食堂不抱希望了，结果过去一看，大部分窗口都打烊了，卖面的窗口却还开着。最后我如愿以偿吃到了肉酱面。

晚上回到宿舍，看见班上的某位同学在楼道里窜来窜去，跟着他去了他们宿舍，才知道 Python 全英出分了，他正在四处打听成绩。他们宿舍的人分数都在 94–96 之间，又问我的成绩。我拿手机一查——94。于是他们就开始怀疑这门课是随机打分的了。不过不管是不是随机打分，他们都觉得这是门绝世烂课。我大惊，问他们希望拿到多少分，他们说，拿到 95 分就算满意，拿到 98 分就算很满意。

唉，保研。

9 月 2 日（一）定稿

食堂逸事

刚才我在吃饭，对面来了个小伙子，还挺有礼貌，问我这儿有没有人。

我说没有，他就坐了。

我看他穿着 2306 新定做的 T 恤，就问他是不是大二的，他说是。

我说我大三，也是计算机的。

然后他热情地跟我打了个招呼，说老东西好。

我沉默了半晌，强忍笑意，然后问他刚才叫我什么。

他说老同志。

接着他又问我说您是哪位，我说不必了。

9 月 10 日（二）晚于学五食堂

注：用“老东西”称呼学长学姐，以及用“小东西”称呼学弟学妹，是一种网络玩笑用语，不适合于线下交流。

新北村

刚刚做梦，梦见我在新北村。

我说新北村是个什么地方？

不知道，只知道刚下课，人很多，乌泱泱的一大片。

9 月 12 日（四）午于新北

Android 平台开发技术：何去何从？

下午去图书馆研究了一下上节课结尾讲的几个案例。案例没有现成的工程文件，只有制作步骤，步骤还不是很完善。做的时候遇到了问题，翻 PPT 也找不到答案，还得上网去搜。

于是课前我早早到了教室，希望能问问身边的人是怎么学这门课的。我认识的人本就不多，结果好多人到上课了还没出现——十分钟后我才意识到他们不是迟到了，是直接翘课了。

我前面的一排人都没有在听课，他们在看网上的教程。

课间我去问了几个北京学院的同学，她们有人已经开始自学了，有人打算抱别人大腿。

下课以后我问了问室友，室友还没开始学呢，他也准备自学。

我呢？我有什么大腿可以抱呀，好大腿早被抢完了，现在只能靠自己了。

唉，你 6 系是这样的。

9 月 18 日（三）

疯狂小杨哥

周日晚上关了灯，我们却睡不着觉，于是聊起天来。

室友聊到了一些话题。

我问他小杨哥是谁。他回答了我。

我说我不刷短视频。他回答了我。

另一个室友说了一些话；但发起这个话题的室友反驳了他。

我说没有人为他写人物志吗，第三位室友回答了我。我说，他之所以这么火，某种程度上也反映了中国互联网的现状啊——更多人还是喜欢直播带货，但这是为什么呢？第一位室友回答了我。

他聊到了一些事情。一些传闻。

我说这样不好，第二个室友发表了一下自己的看法。

一想到这位室友将来一定会发达，我就很庆幸自己不是他的女朋友（？）。

9 月 23 日（一）夜

休息一下

一觉醒来，浑身疲惫——已经晚上八点了。我竟然一口气睡了三个小时！在吃晚饭前，我赶紧提笔写下了这篇博客。

这两天真是太累了！尤其是昨天，一整天都在赶 ddl。晚上八点半上完课，我没有选择回宿舍，而是继续留在教室写作业。一直写到十一点，然后回宿舍继续写，写到一点才睡觉。晚上只睡了五个多小时，今天上午还连上了四节课，身体真的吃不消。本想着中午能睡个好觉，结果睡了十几分钟就醒了。然后去参加心理活动，从两点半一直活动到四点。结束后大家又聊了会天，等回到宿舍已经是五点了。

没想到整个 6 系的心理活动，居然只来了 20 个人——其中只有五六个本科生，而且没有大二的（大二的估计还在写计组……）。整场活动还是很有意思的，感谢大家能在百忙之中抽出时间来参加一个不加博雅的活动。😆

上次这么累还是在上周：周一到周三一直在忙，好不容易周四不忙了，结果得了小感冒，难受了几天。周末还没休息够呢，又开始忙了。

之前和同学商量着上周末出去玩，结果因为有事推迟到了这周三，这周三又有心理活动，就想再推迟到这周末……结果这两天给周末又排了一堆事，加上大家还要写作业，于是接着推迟了……

为什么总是这么累呢？最近确实 ddl 很多，但不得不承认的是，我一直在被 ddl 追着跑。如果我能提前解决掉一些长期任务，也不至于拖到最后……但说实话，这样真的很难。我一旦有空闲时间，就会被各种杂事排满，而且它们大多和学习关系不大……

现在终于能松口气了，但是我还不敢松——真怕现在松多了，将来又要受罪。

我觉得我需要锻炼自己的耐力。昨天晚上我在上课的教室坐了两个半小时，内心毫无波澜。要是平时也能这样就好了。假如哪天我能平心静气地在图书馆坐一整天，那才算是练成了。

唉。时间就像海绵里的水，你不挤，自然有人逼你挤。

11 月 20 日（三）晚

不可持续发展

这篇文章早就该写出来了，可惜一直拖到了现在……

最近几周一直很忙。

我对同学说，如果说我前几周的生活方式是可持续发展，那么这几周就是不可持续发展。

前几周虽然也很忙，但还不至于那么忙：每天还是有充足的时间休息的，偶尔还可以去运动一下，以及做一些自己喜欢的事情。到了这几周，就已经忙到不仅别的事情做不了，连睡觉也睡不安宁了。我自己曾经说过：

当你想睡觉却不能睡的时候，说明你已经长大了。

每天都疲于学习，应接不暇地赶 ddl，带来的结果是作息混乱：午觉睡太久，晚上不饿；晚饭吃得晚，睡得更晚；早上没精神，不仅上课犯困，有几次还差点迟到。除此之外，我对生活的兴趣也有所衰退，已经出现了驱动力不足的现象。

虽然每天都在泡图书馆，但最后还是搞砸了一些事情。有时我在想，如果我之前再努力一些，结果会不会好一点？虽然我总会安慰自己：我已经够努力了，我已经做得很好了，但有些事情实在搞得一团糟，令我不能满意。

要想在繁忙的生活中做到面面俱到、一事不落真不容易。记错时间，忘记琐事的情况时有发生。幸运的是，我把大大小小的事都记在清单上，虽然没记录下来的事情还是会忘记，但只要记在了清单上，就再也不会忘记了。需要注意的是，整理清单也是需要时间的，我尽量抽出琐碎的时间来整理。

我才不可持续发展了几周，就已经出现了这么多“毛病”了。那些卷王每周都在不可持续发展，他们的心理承受能力该有多么强大。

12 月 9 日（一）晚

最优化

考最优化（计算机工程中最优化的方法）的前一天，我在图书馆上自习。

学累了就在大厅里溜达。只见打印机前已经排起了队，想必都是打印复习材料的。突然碰到一位认识的熟人，她手里拿着好几份刚印好的往年题，说是顺便也帮同学打了。

没过一会又碰到一位同学，只见他站在打印机前等机器吐纸。我走上前去打招呼，只见他在印最优化的 PPT。让我吃惊的是，他选的是单面打印，而且每页 PPT 占满一张纸。我问他为什么不用双面打印，或者把几页 PPT 拼在一起，他说不会操作，以前都是室友代打的，今天第一次自己来打。

他把几乎所有的 PPT 都打了一遍，一共 230 页，花了 23 块钱。他说他打之前没注意页数，结果打完了才发现竟然有厚厚一摞。他想按照章节订起来，结果用图书馆的大号订书机发现根本订不穿。于是他就拿着这一摞纸回去了。

我回到宿舍，才发现室友都把 PPT 印了一份。问他们为什么，他们说不印白不印。于是第二天，只有我一个人拿着作业答案和往年题上了考场。

考完试那天晚上，我问他印的 PPT 有没有派上用场，他说写运输问题的时候看了一眼，此外再没有了。

12 月 27 日（五）晚

结束了

结束了。

上午十点，铃声响起，最后一门考试八股文数据库宣告结束，这个学期也画上了句号。

接下来该干什么呢？我的室友们下周就要回家了，我想趁机和他们出去玩一玩。另外一个月前我就和同学有约，但因为忙一直拖到了现在，趁他们还没回家，也该安排一下了。

但令人担心的是，最近甲流闹得很凶。南方的室友们老家没有甲流，他们想早点回去；北方的室友们要考虑的就多了：他们需要权衡早点回家和待在学校哪个更安全。

——这是昨天他们告诉我的。但是中午的时候，他们突然问我，晚上要不要出去吃饭。我问“你们不怕流感吗”，他们说“都考完了，得就得了”——看来他们已经无所畏惧了。

于是晚上我们美美地吃了一餐。店里的人比上次要少，应该是流感的原因。

1 月 8 日（三）晚

最后一天的梦

刚才我做了一个奇怪的梦。梦到自己刚睡醒，拿起手机看时间。看小时，好像是 8 点多，又好像是 10 点多，怎么都看不清楚。这时室友突然进来了，跟我说 12:20 了，快起来，下午 2 点还要考军理。我又看了一眼手机，可是还是没看清楚。

然后我就醒了，想把这个梦发到群里。拿起手机一看，群里正在聊天呢。有个 2407（？）的小东西，把和梦拓学长的聊天记录发到群里，好像是晚上看什么电影，结果好几个老东西都在下面说，这下知道是哪个群了——原来好多学长都加了那个群。

1 月 18 日（六）
1 月 21 日（二）补录

夏季学期的前夕

TODO

上课第一天

7 月 4 号星期四是上课的第一天。

早上六点五十，我就起了床。一顿磨蹭以后，到食堂已经七点三十几了，于是吃了碗馄饨，就跑去上课。到了教室，只见已经来了好多人，把有插座的座位都给占上了。

台上的老师说：“我是被迫上这个课的。”我身边的一个同学小声说：“我也是被迫上这个课的。”

然后就开始上课了。上午一共四节课，老师课上说英文，课下讲中文。课间的时候，我因为久坐浑身难受，就去楼道里活动了下。只见整条走廊空荡荡的，偶尔看到有个教室亮着灯，里面却只坐了一个同学。

随着时间的推移，我身旁有些同学的电脑续航能力不足，快要没电了。正好我带了一个插线板，于是我把它取出来，请靠墙的同学把它插到墙上的插座上，然后借给他们用。我自己倒是没有用，助人为乐了属于是。

前三节课是老师讲，第四节课就轮到我们做题了。题目有选择、填空和编程题，中午十二点截止。大家做完题后，就纷纷离开了教室。

下午还有编程课，内容是五道编程题，限一周内完成。但是不必去教室，于是我们就在宿舍里写完了作业。

——这样看来，即使不在学校，也可以上这门课。

下午，我正在宿舍写作业，室友突然说他电脑开不了机了。

他按下电源键，电源键上的小灯亮起，但是屏幕不亮。昨晚还好好的，他说，我也没干什么呀。于是我们提着电脑，去了学校里的维修店。

修电脑的人脸白白的，看着面善，穿了一件花色衬衫，平易近人的样子。他看了电脑的症状，又看了电脑的型号（Lenovo Legion R9000K2021H），得出了一个骇人的结论：要换 CPU。他说，拯救者的一系列型号用的都是 AMD 的 CPU，所以都有接触不良的问题。他先让我们摸键盘的中心位置，室友摸到那里有温度，他说是 CPU 在发热；接着，他用手掌按压那里，同时按下电源键——他说他是在试着把 CPU 压回去。不过，他的尝试失败了。

然后他开出了价钱：换 CPU 要 1900。紧接着他用微信联系了一个自称是联想客服的人，问对方换主板需要多少钱，对方答 10000+。我的室友吓了一大跳。

至于我嘛，我是不太信他这一通操作的，想去联想售后先看看。那个人也没阻拦我们，直接告诉我们南门就有官方维修店。我也在高德上查到了，可惜马上就关门了。室友说他不着急用电脑（现在他拿 Mac 当生产力，这台电脑只用来打游戏），于是我想明天先去售后看看。虽然电脑已经过了保修期，但咨询应该是免费的。于是室友听从了我的建议。

我们把电脑放回了宿舍，然后一起吃麦当劳去了。麦当劳 7 件任选 72 元，不错。

7 月 14 日（日）定稿

不上课的第一天

TODO

第一个周末

TODO

老上海

TODO

串门

今天（7 月 26 日）的作息很糟糕。

早上七点半，闹铃像往常一样响起。我关掉闹铃想要再睡一小会。结果再一睁眼，已经是八点半了。唉。

我在图书馆度过了一上午。吃完午饭就回到宿舍看手机，结果弄得太兴奋了，午觉没睡着。下午三点只好又去图书馆。结果没想到四点多就开始犯困，用凉水冲了把脸，发现不那么困了，于是继续忙。一直坚持到六点，因为看代码看得头晕，只好回宿舍睡觉。

一觉醒来，发现自己从七点睡到了九点。肚子已经饿得咕咕叫了，得考虑晚饭吃什么了。

我开始叹息，感叹一天即将结束，自己的作息多么糟糕，效率多么低下。我觉得我应该为自己找点娱乐活动，让自己对生活充满期待……

可是我的肚子已经饿得咕咕叫了，我得先考虑晚饭吃什么。

我想随便吃点什么，草草结束这一天。但这一天还没有结束，九点才醒的我注定无法早睡。我在十一点前吃完了晚饭，如果一点开始睡觉，那么还有两个小时，应该做点事情，来给这一天增添一点乐趣。做什么呢？那就串门吧。和同学多一点交流，可以减轻独处一室的苦闷。

我先去了隔壁。隔壁的同学正在为 Python 大作业而奋斗。我由衷地佩服他们。

接着，我又来到了队长的房间。队长说他每天中午 12 点起床，下午 2 点开始准备比赛，一直忙到凌晨 2 点，中途只休息一两个小时——真是辛苦。

回到宿舍已是十一点半，于是我找到了更有意思的事情——刷 B 站。当然，后来我也写了一些博客。写博客要趁早，不然的话脑袋里的东西就忘光了；不过我认为，更重要的是用心去写作，不然就会写成无聊的流水账（像这篇一样）。

凌晨两点，我上了床，结束了凌乱的一天。希望明天会更好。

P.S. 第二天我九点醒的🤣️

7 月 29 日（一）定稿

室友回来了

室友回来陪我了，好耶！

明天和他一起去买水果。

7 月 27 日（六）定稿

比赛结束了，假期开始了

比赛结束了，我的假期开始了。

其实早在七月末，我们就想过放弃了。那时距离上一次例会已经过去了十天，我们都不知道其他队伍的进度，只知道一共有四个组，两个初赛名额，以及在上一次例会中我们组的进度是倒数第二（倒数第一几乎什么也没做）。到了 7 月 29 号开会的时候，大家纷纷秀出自己的进度。我们组 CPU 各个部件刚刚搭完，还没有组装呢，能不能按时测试完成都说不准。比我们快的那两个组呢，都已经组装完成开始测试了。不过最令我们惊讶的是——上次倒数第一的组竟然直接跑路了！为此我们不得不反思到底能否按时完成任务，最终大家都决定这几天再拼最后一把。

队长花费了几天完成了 CPU 的组装，随后就进入了漫长且痛苦的测试阶段。在组装和测试的过程中，我们帮不上什么忙，偶尔在自己负责的部件出错时帮忙修一修，大多数时候都在做自己的事。

队长一连串发现了好几个错误。每发现一个错误，都需要从测试数据中找出产生错误的指令，通过打印调试信息的方法逐步缩小范围，最后发现是模块的一些小 bug 造成的——真是搞心态。

8 月 2 号深夜，也就是 8 月 3 号凌晨，我们组的三个人齐聚队长的房间（还有一个人不在校），讨论是否应该继续做下去。此时距离 ddl 只剩下两天了，而我们的 CPU 不仅没有通过最基本的测试，甚至有些模块还没有组装上去。队长反思了我们组进度如此之慢的原因：一方面，这个比赛确实非常硬核，以至于根本没有多少人愿意参加；另一方面，我们前期实在是太磨蹭了，没有像其他组那样马不停蹄地赶进度，以至于最后调不完——但凡早两天搭完也还有戏。于是我们三人决定放弃。紧接着队长就让我们看他打了一把雀魂……

8 月 3 号深夜，也就是 8 月 4 号凌晨，我们再次齐聚队长宿舍。队长向那位不在校的队友明确表达了自己放弃的想法（队友自然同意了），并告诉我们他摆烂了一整天，现在过得非常快活。😆️

队长和另一位在校的队员都是 8 月 5 号回家，我 8 月 7 号也该回家了。我们的暑假总算是正式开始了。

8 月 7 日（三）定稿

感冒

我感冒了。

故事得从周六（3 月 16 日）说起。周六晚上，我洗完澡，擦身子的时候无意舔了一下嘴角，结果发现嘴角起了个小泡。

当时我就慌了，因为以前嘴角也起过泡，每次都会变得很大，然后结痂。于是我喝了很多水。可是第二天下午有植树和爬山活动，活动期间我怕上厕所，就没喝多少水。回来的路上遇到晚高峰大堵车，车开了快两个小时才到。我和其他人一样，睡了一路，醒来时就感觉嗓子干。当天晚上参加了一个线上会议，会开了两个半小时，期间没怎么喝水，也没有去厕所。虽然会后补了不少水，但是周一早上醒来的时候，嗓子还是开始疼了。

嗓子疼，吃饭也难受。幸好嘴角的泡结痂了，而且后来越结越大。那天我一整天都在疯狂喝水上厕所。等到周二早上，嗓子不疼了，但是开始流鼻涕了——感冒了。

我一开始以为是半夜着凉了，但是半夜没有开窗户。后来我猜测，可能是当天早上为了上体育课，穿少了，出门被吹了。总之上完体育课，流鼻涕就变得严重起来。周二周三连流了两天鼻涕，用了好多抽纸。感冒上课精神涣散，容易走神；上机头脑不清，智商下线。周二晚上流着鼻涕写完研讨课的 PPT，周三晚上迷迷糊糊写完 OS 课下。

我的一位室友和我同一天感冒，当天下午就请假在宿舍休息。他去校医院开了些西药，按时吃着，只是时不时咳嗽流涕，听着很是难受。

周四过后是周五。到了周五，情况又有变化：流鼻涕变少了，但是咳嗽变多了，而且有了痰。当天晚上，一位已经回老家的室友发来微信，说他去医院看病测了新冠，阳了，让我们也测测。于是我去美团上买了抗原试纸，我们三个都测了一下。结果是他们两个都是阴性，我是弱阳。

之后我继续吃药养病。本来感冒一天天好起来了，但是到了周日，由于我的室友半夜嫌热打开了窗户，导致我早上起床的时候着凉了，感冒又加重了。就这样继续吃药养病，一直到周五（26 日）才敢停药。之后的几天偶尔会突然间开始咳嗽，但嗓子一点也不疼……总而言之，感冒终于是好了。

4 月 7 日（日）定稿

下水道

下水道堵了。

在住进新北一个学期又一个月后，大家洗澡时发现，下水道堵住了。水多的时候一下子下不去，于是积在厕所里，有时甚至会从门缝里流出来。

我的室友希望找维修的师傅来通下水道，我则认为是头发堵住了下水道，自己用手掏一下就行了。可是他们却认为用手掏太恶心，坚持要请师傅来，说什么“专业的事要让专业的人来做”。我说就算师傅来了也是用手掏，无奈他们不听。

周四下午，室友好不容易想起来去找了一趟宿管。等到大概五点的时候，师傅就上门了，当时只有我一个人在宿舍。只见师傅拿了一根铁丝，把一个小筒从下水道里勾了出来——上面缠满了头发丝。师傅用手把头发丝掏干净，扔进垃圾桶里，把小筒放回去，然后打开水龙头冲了一会，确认没有堵住。师傅临走的时候，我问他以后堵住了怎么办，于是他把手上的铁丝送给了我，说以后可以用它把小筒勾出来。

我把这件事发到了舍友群里，舍友回了个“6”。下次应该惩罚他们徒手掏下水道😡。

3 月 24 日（日）定稿

你想活出怎样的人生

我和三个室友订了 4 月 7 号晚上 8 点的场次。难得整个宿舍一起去看电影。

我们早早出发，骑车十多分钟就到了太平洋影城。道路两侧的建筑绝非等闲之辈——中关村真乃卧虎藏龙之地。融科资讯中心名企林立，富丽堂皇，吊灯喷泉，灯红酒绿。我们匆匆赶路，早早就进了影厅。上百人的影厅里只坐了寥寥几人，电影开始时又进来一批人，一共只有十来人。

电影放了两个小时。结束时播放制作人员名单，我的室友起身要走，我却拉住他们，和他们说，看完片尾是一种表达尊重的方式。但当电影结束时，我已经开始哭了。

我们骑车匆匆回了学校。我的室友纷纷抱怨没看懂，认为这部电影十分费解。我感到十分无奈——他们既没能将各种隐喻与现实联系起来，又没能在高潮部分凭借点睛之笔一举拿下主旨，最后只能怪罪这部电影如何如何。

——这不，他们转身开始打游戏了。幸好我没有和他们一起打游戏，不然就不会有这篇文章了。

4 月 7 日（日）定稿

疲惫的周末

这可能是我开学以来最忙的一个周末了。

故事要从周五讲起。虽然是美妙的周五晚上，但我迫于 ddl，还是得泡在图书馆。来看看我的 ddl：

• 周六 12:00 交冯如杯论文中稿；
• 周六 20:00 OO 中测截止；
• 周二上午体测；
• 周二下午做 pre；
• 周三交冯如杯论文终稿。

转眼到了闭馆时分，我的 OO 虽然通过了中测，但代码质量不堪入目，需要重构。我起身的时候，发现身后是我认识的同学，就和她聊了起来。据她所说，这一块坐了很多 6 系的同学——可惜我不认识。她没有回宿舍，而是转身去了五号楼，说那里凌晨两点才关门。我虽然回了宿舍，但也没有早睡。写了会儿冯如杯，又改了会儿 OO，等到凌晨两点熬不下去了，才上床睡觉。我的室友则在两点到三点间上了床。

周六没有赖床，八点就醒了，但是很难受。稍作休息后奋战了一个上午，终于写完了冯如杯论文的中稿。危机暂时解除了，但我丝毫不敢懈怠，因为晚上八点就是 OO 的 ddl，在此之后我的代码就要封存起来，再不修改了。于是睡过午觉，我又去了图书馆。

重构真是件麻烦事。由于迭代前对架构的考量并不充分，我有新旧两套架构并存，一套用于新代码，一套用于旧代码。我小心翼翼地将旧代码从旧架构迁移到了新架构，并使用中测的公开数据进行反复测试，希望不要出问题。终于，到下午六点的时候，我将一部分代码完成了迁移，并且没有弄出 bug。虽然还剩一部分代码没有迁移，但我已经没有时间了，只得放弃。

晚上过得比较清闲，12 点就睡了，但是 12 点半又醒了，醒来发现自己满身是汗——今天格外的热。然后发现灯还开着，室友都在聊天。我睡不着，只好等他们关了灯才睡下——已是一点钟了。

周日七点多就起了，依旧是没有睡好。八点多就坐在了五号楼开始自习，在痛苦中度过了一个半小时，然后毅然决然回宿舍洗衣服 + 摆烂。到了下午，望着还没开工的 pre 和还没写完的冯如杯，我叹了口气，又回到了图书馆，并一直待到了十一点。

……所以我就这样一直泡着图书馆，希望自己有朝一日可以不用泡图书馆。

4 月 15 日（一）定稿

五一快乐

五一快乐！终于等到这一天了。虽然有些室友上周四就已经进入半放假状态了，但今天终于可以正式开启假期了。

英语课下课后，我陪室友去刷了 TD，晚饭吃了烤鸭。晚上处理了一些琐事，然后匆匆写完了这篇短文。

快来看看我的室友五一都有什么计划：

• 有个室友大半个假期都在京外度过，2 号先去参加音乐节，3 – 6 号还要去旅游。
• 有个室友整个假期都留校，说不定会在京内旅行。
• 还有个室友也要留校，假期安排以练球为主，学习为辅，也可以考虑京内旅行。

我呢？我计划大部分时间都待在学校，期间应该会回家一趟。我希望这些天能尽早把 ddl 在节后的作业写完，并提前完成一部分 ddl 稍远的作业。另外希望多做一些感兴趣的事。

5 月 1 日（三）定稿

我的五一假期被面向对象给毁了

😅️

5 月 6 日（一）定稿

重拾游泳

时隔近一年，我再次走进了游泳馆。

上次游泳还是在大一的末尾。那是最后一节游泳课，我拿着深水证和游泳课的高分成绩，走出了游泳馆。那天的天很晴，心情很好。可是在那之后，我就变得很忙很忙，再也没有时间碰游泳了。那张深水证也被我放进了钱包里，再也没有拿出来。

眼下正是五月的好时光。气温已经回升到舒适的程度，与游泳馆的水温十分接近。于是在五一结束后的第一周，我就决定踏入学院路的游泳馆，看看自己的游泳能力还残存多少。

学院路的游泳馆很是先进。储物柜用的不是钥匙而是芯片，浴室的环境也比沙河好了许多。我走到浅水区，做好热身，在背后绑了一块浮漂，又在手上拿了一块。然后缓缓进到水里，开始换气。

换气的时候就感觉到自己还是怕水。拿着浮漂游了一会，就感觉自己呼吸不太适应了——回到原点了。

游泳的人好多。有大人，也有小孩，但更多的是像我们这样的大学生。岸上的教练正在给一个大人讲着什么。我慢慢从旁边游过，让自己放平心态，坚持游久一点。经过一次次尝试，我渐渐能游 25 米，甚至 50 米了。

这时我感觉头被什么东西轻轻拍了一下，于是失了节奏，马上就从水里起来了。蹬几下游到一边，回头，发现是个小孩在学游泳。他两手各拿着一根海绵棒子，四处挥舞着。

又游了几个来回，终于过了（连续）100 米的大关。我在岸边独自庆幸，打算把手上的浮漂拿掉，用手划水。手脚配合很是得当，就是动作有点慢，摘了浮漂肯定不行。结果划着划着，时间就到了。

我把浮漂放回筐里，然后沿着岸边走到门口。看到对面的深水区里，去年教过我游泳课的老师，现在正带着学生练跳水。四名学生蹲在跳台上，他一声令下，他们就下饺子似的噗噗入水，然后在一遍遍催促声中快速冲刺。紧接着又是一排，又是一排……

下次有空还去游泳。希望能和同学一起去。

5 月 12 日（日）定稿

和软件学院的同学聊聊操作系统

看看软院的 CO——是弱化版的 CO（数字电路 + 背书，不搭 CPU 没有灵魂）。看看软院的 OO——是弱化版的 OO。只有 OS 是计软平等的。

周三晚上，我下了机，等电梯的时候碰到了软院的同学，于是萌生了采访他们的念头。按照约定，第二天晚上十点，我造访了他们的宿舍。我们先是花了好久的时间来互相了解对方的 OO，然后进入了正题——OS。

那么这两位同学是怎么学 OS 的呢？首先是理论课——他们不听理论课。因为理论课太无聊了，让人犯困，所以他们选择不听（好消息是，不听就不会犯困）。另外如果早上起不来，那就干脆不去了。这样做的结果就是作业写不出来，期中考试也一塌糊涂。我和他们聊天的时候，有人还在为信号量的作业焦头烂额。他说自己先尝试补课，如果还是不会再抄学长的博客（结局是哪条道路可想而知）。

接下来是实验。实验分为课下和课上。他们说，课下读指导书读不明白，就抄学长的。抄到最后自然是什么也不懂了——课上测试要花很多时间来写 exam，至于 extra，根本写不出来。

总结起来就是一句话：摆烂了。

临走之前我问他们有没有计划自学 MIT 6.S081，他们答道，上学期间肯定没空，假期又担心自己缺乏动力，只能等到放假再看有没有空。

5 月 12 日（日）定稿

好难过

今天好难过。

半夜，我失眠了。四点多钟意外醒来，浑身疲惫，但毫无睡意，不知过了多久才浅浅睡着。

睁眼一看表，已经六点五十了。这时想起来昨天和室友约好去吃肠粉，于是先洗了漱，然后去叫室友。叫了许久，室友终于醒了，但没想到他说他昨晚也失眠了，就不去了。我大失所望，只好去吃食堂了。

饭后我去了图书馆。刚写了一会 OO，到九点二十的时候，突然发现微信里说九点半有场讲座必须要听。我好痛苦——幸好，通知里说线下无法参会的同学也可以选择线上。于是我在图书馆打开了腾讯会议，进入了赛博会场。

会议从九点半开到了十一点，会后我又陷入忙碌，忙着学习、吃饭、午睡、赶路上课，浑身上下一百个不情愿。

下午上课时和室友商量晚上下馆子的事，结果别的室友都以忙碌为由拒绝了，只剩下我们两个。真的好可惜啊！我多么希望能和室友齐聚一堂，可是怎么劝，他都不肯来。

课后我待在宿舍一直学到六点，然后出发去吃饭。我们两个人点了三个菜（干锅肥肠、油麦菜、豆腐白菜汤），结果他的饭量并没有那么大，我的饭量更是小，最后素菜和汤都没吃完，我们把素菜打包了，汤就倒掉了。我心里觉得真的好可惜，我们浪费了好多。

饭后稍事休息，我又赶往图书馆写 OO。在悲伤的心情中捱到了十点半，然后匆匆赶回了宿舍。

真是一个难过的周五。希望明天会更好吧。

5 月 31 日（五）定稿

记忆

周一才想起来自己阳光打卡还差一次——但是周日就截止了。于是体育分数 -10。

然后我就想，我的大脑就好像是一个时间片轮转的记忆调度器。大脑内部有个不定时的计时器，控制着我时不时回想起一件还没有做的事情。然后我会判断现在能不能做：能做就做，不能做就先放着。至于下次想起来是什么时候……我不知道，也许是明天，也许是 ddl 的后一天。

6 月 5 日（三）定稿

坚持

昨晚失眠了，今早起晚了。六点五十的闹钟，关掉之后想休息一会，结果一睁眼七点半了。

于是刷牙洗脸，早饭没吃就去上体育课。今天太极拳考试，打拳打到筋疲力尽，幸好考试得了 100 分。回到宿舍热了一罐八宝粥作为早饭，吃了以后就去睡了。

我从十一点一口气睡到了一点，醒来的时候发现室友都还在睡……

下午小学了一会，就去上英语课了。上课前向室友借了一袋烤馍片——白味的，不好吃。

晚上和室友一起吃麦，然后在图书馆自习。事情越来越多了，时间越来越少了。

图书馆的闭馆音乐换成了《稻香》，鼓励着我默默坚持下去。

6 月 5 日（三）定稿

一代人有一代人的高考

今天（6 月 7 日）我参加了一场重要的考试。不是高考，而是 OS 期末考试。

考试 7:45 开始，为此我定了 6:25 和 6:30 的闹钟。虽然前一天晚上已经尽量早睡了，但最后只睡了不到 7 个小时，醒来还是很困。没办法，只好顶着困意起了床，去食堂吃早饭。

那天早上下着雨，所以在路上花的时间多了一些。吃完早饭赶到教室已经 7:40 了，只见教室里坐满了人——大部分人都已经到了。我找了个空位坐下，结果马上就发卷了。这里我犯了一个错误：没有去厕所洗把脸。这就导致我做题的时候还是有些困，速度不够快。

卷子发下来以后，我又犯了一个错误：没有先翻阅一遍试卷，规划一下时间。这就导致我做题时缺乏时间观念，前面写的太慢，最后还剩下一道半大题没有写完。

这次考试就在遗憾中结束了。我打着伞，慢慢走回了宿舍。本以为他们回到宿舍之后就会迫不及待地开始议论，结果没想到大家都一言不发。应该是无语了。

于是我上床补了觉，其他人则一直在玩吃鸡。醒来就是饭点了，我去食堂吃了顿丰盛的午饭。群里陆续传来同学请假的消息——下午还要上课呢。于是生活就这样继续了下去。

一代人有一代人的高考。我们的一生就是考试的一生。

6 月 10 日（一）定稿

OO 害了他

下午晒的被子一直忘了收
晚上下雨被困图书馆了，被子也湿透了😭
不过幸好 OO 和离散数学作业都写完了

——OO 害了他

6 月 10 日（一）定稿

考试加油

时间过得真快，明天就进入烤漆了。

今晚吃了肯德基，去了图书馆，现在坐在电脑前，希望在睡前留下点什么。

随着课程结束、作业减少，学习的动力也日渐消退。最近我一直在努力吃饭，虽然有时会嫌吃食堂吃腻了，很晚才吃饭或者出去下馆子；在努力睡觉，虽然有时会晚睡，导致早上起来没有精神；在努力学习，虽然有时会缺乏动力不愿前进。

细细想来，这已经是入学以来第四个烤漆了。每个学期都在凌乱中度过，每段烤漆都在匆忙中度过，只留下一地鸡毛，学生憔悴。

衷心希望这次烤漆能有所改观，少一点遗憾，已往不谏，来者可追。

祝考试顺利。

6 月 16 日（日）定稿

夏季学期要来了

美好的暑假从夏季学期开始。学习（内卷）无止境，整个暑假都可以算作夏季学期。夏季学期的选课在 6 月 20 日（四）12:40 开启。

中午 12:40，选课开放的时候，我还在吃午饭。等我不紧不慢地吃完回到宿舍，才从室友的口中得知选课已经结束了——虽然选课名义上是 25 号 17:00 结束，但对于 2206 的同学们来说，选课在开始的 3 秒钟后就已经结束了。

让我们来看看，大家都选了哪些课：

Python程序设计（全英文）

一般专业 + 全英课，而且只用上两周，大作业是小组合作，纯纯的绝世好课。唯一的缺点就是名额太少，年年爆满。今年也不例外，120 个名额瞬间抢空。

看到两门一般专都被抢空，我本来打算小学期好好休息的，结果在选课截止的那一天（25 日）下午，这门课偷偷加了 20 个名额，我就趁机挤进去了。不知道这门课最后有没有报满。

计算机视觉计算

略逊一筹了：首先只能算作一般专业课，其次还要上 6 周——暑假一共就 9 周，中间 6 周被它一占，回家就待不了几天了。所以说，这门课适合那些假期留校的同学。就这也能瞬间报满，我也是醉了。

不知道为什么最后反而空出来了几个名额，可能是 Python 扩容以后有些人改报 Python 了。

体育（5）[游泳1]

大三秋季要考游泳。大一大二没报过游泳课的可以趁暑假报一个，报了游泳课并顺利通过就能免去考试了。至于那些暑假也不打算报的，应该是上大学前已经学过了。

除此之外，剩下的课就没什么人报了。其中不乏一些计算机学院开的全英课，但——都要报全英课了为什么不报个水一点的。至于那些既不是一般专又不是全英的，纯纯浪费时间，不如好好享受这难得的暑假。

6 月 28 日（五）定稿

既然选择了 Arch，便只顾风雨兼程。——周国平没说过这句话

我装了 Arch Linux。

我之前上初中学网安的时候用过 Kali Linux，当时不懂事，用着玩的；上高中学 OI 的时候用过 NOI Linux，是基于 Ubuntu 的；还用过计组的虚拟机，是基于 Debian 的。今年寒假，我得到了升级硬盘、重装系统的机会，这也是一次安装双系统的机会。

那么，装什么呢？虽然 Ubuntu 开箱即用、易于上手，但是我想挑战一下自己。之前看到、听到身边有些人在用 Arch Linux，我便暗暗记在心里，想装个 Arch Linux 挑战一下自己。于是，在官方文档、B 站视频和知乎教程的帮助下，我在（1 月 23 日）一天之内就装好了 Arch。

但是，挑战才刚刚开始……

高分屏适配（1.23 – 1.24）

两次重启之后，黑白的终端和闪烁的光标并没有如期出现；取而代之的是一幅五彩斑斓的桌面。——KDE！屏幕中央的窗口上写着“Welcome to KDE Plasma”，正是对我安装成功最好的祝福。但是……这行字太小了。预装的 Windows 的缩放比例被设置成了 250%，而 KDE 对这一点全然无知。默认的 100% 缩放比例，让这个窗口显得如此渺小。

于是在安装完成后，我做的第一件事情就是适配高分屏。

ArchWiki 上对 KDE 的高分屏适配已经有了详细的教程，包括：

• 调节全局缩放率。

• 调节光标大小（X11 下光标大小不会跟随全局缩放率）。

• 调节面板高度（X11 下面板高度不会跟随全局缩放率）。

  这里有个小插曲：根据教程，需要设置环境变量来让面板高度跟随整体缩放。经过一番恶补，我终于学会了如何设置环境变量。但是，当我向 ~/.bash_profile 的末尾添加 set PLASMA_USE_QT_SCALING=1 并重启系统之后，我被卡在了登录页面——输入密码之后会黑屏，然后回到登录页面。

  当时我怕极了，以为新装的系统就这样被自己毁了。后来不知道在哪里查到，按 Ctrl + Alt + F3 可以开启一个新的终端，我就用这个终端删掉了那行致命的代码，让电脑恢复了正常。

  我把这件事告诉了湖人，湖人建议我装 Wayland。我装了以后，发现面板高度可以跟随整体缩放了。但是窗口中的内容都会变糊，于是放弃了 Wayland。

  第二天我研究的时候，发现右键面板，选择“进入编辑模式”，可以修改面板高度。于是我按比例调高了面板高度，问题就解决了。

设置中文（1.25）

简体中文本地化一文给出了设置中文的详尽步骤，照做即可。

在修改 /etc/locale.gen、运行 locale-gen 并安装 noto-fonts-cjk^包 之后，我在系统设置的语言选项中添加了简体中文，但是只有系统设置中的文本成功变为中文，其他软件仍是英文。经过查询，发现上述页面中已经提到了 KDE 可能会生成错误的语言配置文件，最后的解决方法是按教程修改 ~/.config/plasma-localerc 文件：

1
2
3
4
5
6
7

 [Formats]
-LANG=zh_CN
+LANG=zh_CN.UTF-8

 [Translations]
-LANGUAGE=zh_CN
+LANGUAGE=zh_CN:en_US

安装 Firefox（2.6）

室友在 Arch Linux 上装了 Chrome，而我选择 Firefox。摆在我面前的有两个选择——用包管理器安装和用 Discover 安装。

最开始我想用包管理器（这里用到了 yay）。ArchWiki 上说有一个“具有更好的 KDE 集成”的版本：firefox-kde-opensuse^AUR。但是我在编译的时候遇到了错误，于是转而用 Discover 安装。Discover 装东西真方便，现代的应用商店，点一下就装好了。

正巧那天我和一位同学聊天，聊到了这个问题。他说不建议我用 Flatpak 软件包，因为包管理器安装的软件运行更快、配置更方便。于是我去网上查了一下，看到论坛上有人说与其安装 Flatpak 软件不如用木棍戳眼睛（好吓人），那位同学阅后表示赞同。

另外他告诉我不要装 firefox-kde-opensuse——那是给 OpenSUSE 用的。于是我卸掉了 Flatpak 版 Firefox，改用了包管理器安装 firefox^包 和 firefox-i18n-zh-cn^包 这两个包。

高分屏适配后续（2.6 – 2.12）

我把我的困惑发到了讨论页，随后与一位大佬展开了长时间对线，最后修正了 ArchWiki 的相关内容。主要内容就是以下几点，感兴趣的可以去看讨论页。

1. ArchWiki 信息有误。面板上的图标确实可以根据面板大小自动缩放，不能根据全局缩放率自动缩放的是面板本身。
2. PLASMA_USE_QT_SCALING=1 可以解决让面板跟随全局缩放率自动缩放。正确的写法是 export PLASMA_USE_QT_SCALING=1，而不是 set PLASMA_USE_QT_SCALING=1。
3. 面板高度可以通过右键面板手动调节。
4. PLASMA_USE_QT_SCALING=1 也可以让其他桌面部件自动缩放。
5. 使用 Wayland 可以解决自动缩放问题。但是在修改全局缩放率后需要注销才能生效。

Vivado–VCS 联合仿真（2.6、2.17 – 2.19）

本来是打算安装在虚拟机上的，因为给我们培训的学长大都用的是 Ubuntu 虚拟机。但当我用 Debian 虚拟机安装的时候出现了空间不足的情况，扩容后虚拟机无法登录。于是我只好在群里求助，这时群里的学长纷纷推荐我用实体机 Linux 或者 WSL。想到我之前装的 Arch Linux 还不知道拿来干什么好，我决定试着装在 Arch 上。

学长结合自身经验与网上教程撰写了一篇《vivado-vcs联合仿真环境配置》，它将会带领我们披荆斩棘、乘风破浪。

Vivado

先安装，再除错。《联合仿真》给了一篇 Vivado 安装教程以供参考。

安装

有同学告诉我，vivado^AUR 在 AUR 上就有包。但是经过研究，我发现 AUR 上的包用起来比较麻烦——由于下载需要经过登录墙，所以必须手动下载完整版压缩包，然后放置在 PKGBUILD 所在的目录下。考虑到完整版压缩包大小约 100G，我不认为这是个好主意。但我的同学更愿意用 AUR 上的脚本，因为这样可以让 Vivado 归 pacman 管。他说，在 Linux 下安装软件就得严格使用包管理器，否则就会把系统搞乱，和 Windows 没有区别了。

经过一番思索，我最终还是选择用自带安装程序。下载好（版本 2023.2，大小约 300M）后执行命令：

1

# XINSTALLER_SCALE=2 ./FPGAs_AdaptiveSoCs_Unified_2023.2_1013_2256_Lin64.bin

1. 刚启动安装程序就发现 UI 小得可怜，同时控制台有提示：

   1 2 3 4

   INFO Could not detect the display scale (hDPI). If you are using a high resolution monitor, you can set the insaller scale factor like this: export XINSTALLER_SCALE=2 setenv XINSTALLER_SCALE 2

   所以要加 XINSTALLER_SCALE=2。
2. 配置安装选项时发现默认安装到 /tools/Xilinx，需要权限，于是只好退出了安装程序，加上 sudo 又来了一遍。

安装程序先是花了一个半小时下载了约 22G 的 Vivado，然后在十分钟以内完成了安装。不知道如果用了 AUR 上的包会怎么样。

除错

1. 安装结束时控制台有报错：

   1 2

   ######## Execution of Pre/Post Installation Tasks Failed ######## Warning: AMD software was installed successfully, but an unexpected status was returned from the following post installation task(s) /tools/Xilinx/Vivado/2023.2/bin/unwrapped/lnx64.o/vivado: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory /tools/Xilinx/Vivado/2023.2/bin/unwrapped/lnx64.o/vivado: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

   运行 Vivado 时同样产生了报错。

   1	$ /tools/Xilinx/Vivado/2023.2/bin/vivado

   1	/tools/Xilinx/Vivado/2023.2/bin/unwrapped/lnx64.o/vivado: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

   看来必须得处理了。

   通过搜索 ArchWiki，得知安装 libxcrypt-compat^包 即可解决。

2. 我是占位符。

   1	application-specific initialization failed: couldn't load file "librdi_commontasks.so": libtinfo.so.5: cannot open shared object file: No such file or directory

   《联合仿真》中说要安装 libtinfo5，但是 Arch Linux 中没有 libtinfo5，应该安装的是——ncurses5-compat-libs^AUR！

于是成功启动。配置缩放参见 ArchWiki。

为了测试 Vivado 的性能，我从龙芯杯官网下载了 MIPS 团体赛发布包，解压后将样例 CPU 的性能测试工程导入 Vivado：

1
2

$ cd nscscc2023-group-mips/perf_test_v0.01/soc_axi_perf_demo/run_vivado/mycpu_prj1/
$ vivado -source mycpu.xpr

VCS

先安装，再激活，最后除错。《联合仿真》给了一篇 CSDN 上的联合仿真教程，但是过于简略；又给了一篇激活教程，这篇写得不错。

安装

刚启动 Synopsys Installer，就发现字大得离谱——原来是不支持高分屏。于是我只好把全局缩放率改回了 100%。

配置安装选项时发现默认安装到 /usr/synopsys，需要权限，于是只好退出了安装程序，加上 sudo（以及 -install_as_root）又来了一遍。（梅开二度）

激活

安装完以后就需要激活了。用魔法召唤出 Synopsys.dat，放到对应目录下，执行：

1

$ /usr/synopsys/scl/2018.06/linux64/bin/lmgrd -c /usr/synopsys/scl/2018.06/admin/license/Synopsys.dat

……失败了？

1. 我是占位符。

   1	bash: /usr/synopsys/scl/2018.06/linux64/bin/lmgrd: 无法执行：找不到需要的文件

   激活教程中说要安装 lsb-core，但是 Arch Linux 中没有 lsb-core，应该安装的是——ld-lsb^包！
2. 我是占位符。

   1	(lmgrd) Invalid License File

   这使我百思不得其解。我一度以为自己的密钥有问题。经过上网查询，发现原来是因为 Synopsys.dat 的权限是 755，而 lmgrd 执意要把它改成 644。解决方法如下：（参考链接）

   1	# chmod 644 /usr/synopsys/scl/2018.06/admin/license/Synopsys.dat

3. 我是占位符。

   1	(snpslmd) Can't make directory /usr/tmp/.flexlm, errno: 2(No such file or directory)

   激活教程中已经给了解决方法：

   1	# mkdir /usr/tmp

除错

服务器架设完成后，我们创建一个测试程序，然后打开另一个终端来编译：

1
2

$ vcs test.v
$ ./simv

如果遇到以下报错，参照激活教程中的参考链接即可解决。

1

undefined reference to `pthread_yield'

如果看到以下输出，说明编译成功。

1

../simv up to date

联合仿真

联合仿真需要先用 VCS 编译 Vivado 的库，我在编译时就遇到了如下报错：

1

[Vivado 12-23673] compile_simlib failed to compile for vcs_mx with error in 28 libraries (cxl_error.log, Number of error(s) = 122)

仿真的时候卡住了，点击取消无用，向控制台发送 Ctrl + C 后仿真中止，并弹出如下报错：

1

[SIM-utils-79] Incompatible GCC compiled simulation library found! Library '/home/triplecamera/Documents/Vivado_lib_VCS' is compiled with GCC version '13.2.1', expected version is '9.2.0'. Please recompile the simulation library or set the correct compiled library path for '9.2.0'.

唯一的解决方法是安装旧版 gcc，我之后会尝试一下。

声音（2.19）

自从装上 KDE 开始右下角的声音图标一直是静音的，今天想把这个问题修好。按照 ArchWiki ALSA 页面中的提示安装了 alsa-utils^包，但是在解除静音时失败了。搜了论坛才发现那个页面后面提到了需要安装 sof-firmware^包，安装并重启后问题解决。

输入法（2.23、2.25）

参考 ArchWiki，安装 fcitx5-im^包组、fcitx5-chinese-addons^包 和词库（可选），配置 /etc/environment 并重新登录，最后在系统设置中添加输入法。安装之前记得做系统更新，不然就会像我一样失败🙃。

更多高分屏与中文适配（3.4）

最后还剩下 GRUB 和登录页面没有缩放且没有中文，解决方法如下：

• GRUB
  • 缩放：参见 ArchWiki 页面 HiDPI§降低帧缓冲分辨率。
  • 中文：由于执行 grub-mkconfig 时环境语言为中文，所以生成的 GRUB 配置中语言也变为了中文。
• 登录页面
  • 缩放：打开系统设置，选择开机与关机 > 登录屏幕 (SDDM) > 应用 Plasma 设置...，即可将全局缩放率等设置同步到登录页面。（参考链接）
  • 中文：参见我在 archlinuxcn BBS 发的帖子 和 Azure Zeng 的博客。

3 月 25 日更新：更新至 KDE 6 后登录页面无法同步缩放，我在 KDE Discuss 上发帖求助，得知此 bug 已被汇报，将在不久后修复。

4 月 12 日更新：再次检查发现工单已被标记为解决，但测试发现仍然无法同步缩放。通过查阅 Azure Zeng 的博客、上述工单及工单中的链接，我得到了另一种解决方法：修改 SDDM 配置文件 /etc/sddm.conf。

1
2

[General]
GreeterEnvironment=QT_SCREEN_SCALE_FACTORS=2.5,LANG=zh_CN.UTF-8

Java（3.4）

根据 ArchWiki，安装 jdk-openjdk^包（java-runtime-common^包 和 java-environment-common^包 会自动安装；jdk-openjdk 与 jre-openjdk^包 有冲突，二者只能选其一），重新登录之后使用 archlinux-java 配置 Java 版本。

蓝牙（3.14）

参见 ArchWiki 蓝牙页面。对我来说，由于之前没有安装 bluedevil^包 （其中包含了 bluez^包 等核心组件），所以安装了一下，随后完成教程第四步“启动/启用 bluetooth.service”，即可使用。

我听说 KDE 6 更新以后，KDE Connect 支持通过蓝牙连接手机，但是在我这里并没有试验成功。为此我在 KDE Discuss 中发帖求助，得知蓝牙连接功能因故暂时关闭。详情请见我发布的帖子。

Vivado again（???）

WIP

面对综合报错和仿真无法打开文件的问题，学长建议我安装 Vivado 2019。但是据说今年官方推荐的版本将改为 Vivado 2023，学长建议我保留 2023。

之前同学就建议我安装 AUR 上的 vivado^AUR，加上 Vivado 2019 的完整版安装包小了很多（26.5G），我觉得值得一试。

我最初的想法是使用支持 Vivado 2019.2 的 PKGBUILD（commit 3dbc515）进行构建，但是报错说有些包找不到。这是因为在三年多的时间里，有些包已经被其他包取代了。

于是我以最新 commit 为基底，修改了版本信息：

最后值得一提的是，在升级时跳过 vivado。

启动速度慢 + CPU 高占用（3.31 – 4.2）

最近两天，我的 Arch Linux 突然出现了一些问题，对日常使用有很大影响：

1. 启动速度慢。GRUB 加载 Linux 之后会黑屏 2 分钟，然后才能正常启动。
2. CPU 高占用。开机后风扇一直在高速运转，CPU 有一个核满载。

我在 archlinuxcn BBS 上发帖求助，两位大佬帮我解决了问题：

1. 检查内核日志可知是 Nouveau（NVIDIA 显卡开源驱动）的问题。解决方法是使用 NVIDIA 闭源驱动或者禁用独显，我选择了前者。
2. 使用 top/htop 查看 CPU 占用，得知是 Baloo 的问题，禁用即可。

非常感谢他们，同时使我认识到自己的 Linux 基础知识仍然匮乏。

下面附上安装 NVIDIA 闭源驱动的方法（总结自 ArchWiki 的 NVIDIA 页面）：

1. 查询显卡型号：

   1	$ lspci -k | grep -A 2 -E "(VGA|3D)"

2. 根据 ArchWiki 的指引，安装 nvidia 和 lib32-nvidia-utils（不同型号安装的包有所不同）。
3. 编辑 /etc/mkinitcpio.conf，删除 HOOKS 中的 kms。
4. 重新生成启动镜像：

   1	# mkinitcpio -P

5. 重启，完成。

微码（4.15）

微码的作用是将复杂指令分解为一系列简单指令。及时更新微码可以修复 CPU 的重大漏洞。

我根据 ArchWiki 上的教程，运行了以下命令来检查是否已经安装了微码：

1
2
3

# journalctl -k --grep=microcode
4月 15 19:38:29 triplecamera kernel: Register File Data Sampling: Vulnerable: No microcode
4月 15 19:38:29 triplecamera kernel: microcode: Current revision: 0x00000421

看来没有。于是我安装了 intel-ucode，重启后再次检查：

1
2
3

# journalctl -k --grep=microcode
4月 15 20:08:50 triplecamera kernel: microcode: Current revision: 0x00000432
4月 15 20:08:50 triplecamera kernel: microcode: Updated early from: 0x00000421

没想到居然已经装好了。赞。

电源管理方案（4.19）

查看电池状态时注意到电源管理方案不可用：

于是去 ArchWiki 上查了一下，发现 KDE 的电源管理依赖于 powerdevil 和 power-profiles-daemon。前者在我安装 plasma^组 时就一并安装了，后者需要手动安装。

安装过后重启，电源管理方案就可以使用了。

IntelliJ IDEA（4.22）

4 月 21 日那天，我突然想来一场“自我放逐”：从某一天开始，从 Windows 换成 Arch Linux，并且再也不要换回来了。看看自己能坚持多久。

为此我需要将平日会用到的软件在 Arch 上都装一份——其中之一就是 IntelliJ IDEA。去 ArchWiki 上看了发现只有 Community Edition，经过一番搜索才发现 Ultimate Edition 在 AUR 上。

5 月 1 日更新：已在 ArchWiki 上补充相关信息。

但愿是最后一次适配高分屏（4.25）

刚装上 Arch Linux 的时候，默认启动项是 Windows，所以每次想要启动 Arch 都要在开机时长按 F12，切换启动项。为了延长键盘寿命（笑），我决定将默认启动项改为 Arch 使用的 GRUB，然后在 GRUB 中选择启动 Windows 还是 Arch。

上回降低 GRUB 分辨率之后，Windows 的启动画面也变成了低分辨率（启动后分辨率会恢复正常），由于分辨率太低，厂商徽标无法显示，只能显示低清的 Win11 大蓝标，特别丑。Arch 虽然当时没有出问题，但换上 NVIDIA 专有驱动后也出现了启动分辨率同 GRUB 一致的问题。

Arch 的问题是 NVIDIA 专有驱动造成的，无法解决。Windows 的问题倒是可以解决：只需用命令提示符运行 bcdedit /set {globalsettings} highestmode on 或用 PowerShell 运行 bcdedit /set "{globalsettings}" highestmode on。（参考链接）

1
2

> bcdedit /set {globalsettings} highestmode on
操作成功完成。

VLC 高分屏适配（6.8）

使用 VLC 时遇到了下方按钮过小的问题——又要做高分屏适配了。

上网一搜就能搜到，传入环境变量 QT_SCALE_FACTOR（或 QT_AUTO_SCREEN_SCALE_FACTOR、QT_SCREEN_SCALE_FACTORS）即可。（参考链接）

先用命令行尝试一下，确实可以工作：

1

$ QT_SCREEN_SCALE_FACTORS=2.5 vlc

其实以上内容是我很久之前就研究出来的，今天突然想起来这项研究还没做完就赶紧补完写出来了。

我们在应用程序启动器（KDE 的“开始菜单”）中右键 VLC 的快捷方式，选择“编辑应用程序...”，然后切换到“应用程序”选项卡，将“环境变量”设置为 QT_SCREEN_SCALE_FACTORS=2.5。点击“确定”，Plasma 就会将 VLC 的系统快捷方式（位于 /usr/share/applications/vlc.desktop）拷贝到用户目录（~/.local/share/applications/），然后再进行修改，从而避免对系统快捷方式的影响。

再次打开 VLC，可以看到缩放正常了：

我正在担心打开文件的时候该怎么传入环境变量，结果一试，双击文件时也会应用环境变量——这点可比 Windows 做的好。

帮助中心（6.9）

每次我查看 KDE 应用程序的使用手册时都会跳转到官网——那么有没有办法离线查看手册呢？我去问湖人，湖人不知道，让我去加微信群。我加群后问了问题，可是一直没有人回答我。

最后我找到了 KDE 的帮助中心 KHelpCenter（软件包：khelpcenter）。确实是离线的，嗯。

paccache（7.15）

一不注意磁盘占用超过 80% 了。拿 Filelight 看了一下，发现能删的东西中，pacman 和 yay 的缓存占了大部分。

那么怎么清理呢？直接删掉缓存文件夹当然是可以的，但 ArchWiki 给出的方法是使用 paccache 或 yay -Sc。前者可以保留最近几个版本的包（默认是 3 个），后者只会保留最新版的包（yay -Scc 会全部删除，但没有必要那样做）。

我选择了前者：

1
2
3
4
5
6
7
8

$ paccache -d

==> finished dry run: 1383 candidates (disk space saved: 17.32 GiB)
$ paccache -r
==> Escalating privileges using sudo
[sudo] triplecamera 的密码：

==> finished: 1383 packages removed (disk space saved: 17.32 GiB)

清理完后磁盘占用 74%……有人可能问我（其实没人问）为什么不选择后者，我觉得即使选择后者也只能解一时之急，重新分区才是长远之计。

pacdiff（7.23）

起因是星期天滚系统的时候，sudo 更新了配置文件 /etc/sudoers，pacman 将新版本存到了 /etc/sudoers.pacnew，让用户手动处理差异。

这可造成了不小麻烦……我先试着用 Kate 打开，结果 Kate 因为权限不足打不开。我又用 sudo 运行 Kate，结果 Kate 拒绝以 sudo 模式运行。于是我只好用 Vim……先把 /etc/sudoers 移动到 /etc/sudoers.bak，再把 /etc/sudoers.pacnew 修改好以后移动到 /etc/sudoers——结果这第一步就出了问题，/etc/sudoers 不见以后，sudo 没法运行了。于是我只好用 root 账户完成了剩下的操作……

两天以后，glibc 更新了 /etc/locale.gen。因为手动处理差异太麻烦了，我就根据 ArchWiki 的指引尝试了一下 pacdiff。

pacdiff 支持各种差异工具。我想找个 GUI 的，最好是 KDE 的。嗯……最后找到了 kdiff3 和 kompare（前者是后者的新版）。那就来比试一番吧！

• Vim：配色亮目害眼。
• gVim：没用过，不熟。
• KDiff3：崩溃了……
• Kompare：能用，但是不能选择“不应用差异”，只能选择“应用差异”。

就这样。没一个能用的。

发送崩溃报告（7.23）

书接上回。我在尝试 KDiff3 的时候，KDiff3 崩溃了：

1

$ DIFFPROG=kdiff3 pacdiff

幸运的是，崩溃是可以稳定复现的：

1

$ kdiff3 /etc/locale.gen /etc/locale.gen.pacnew

此时屏幕右下角弹出了崩溃处理程序的通知，于是我试着汇报了一下：

点击“报告程序缺陷”，就会弹出一个窗口，上面有“发送自动报告”和“查看开发者信息”两个选项。前者会直接将崩溃信息发送到 crash-reports.kde.org，可惜只有开发者能查看。（参考链接）

后者则会显示详细的崩溃日志。可是堆栈信息中全是未知的符号——这是因为缺少调试符号包。点击右上角的“安装调试符号包”，安装完成后堆栈信息就清晰可见了。此时发送的崩溃报告就具备参考价值了。

最后介绍两个选项：

• 自动报告崩溃
• 自动下载调试符号包以提高崩溃报告价值

后者十分有用，我就把它勾上了。

修改分区（8.16 – 8.20）

上文提到，半年前规划的分区结构不甚合理：经过半年的使用，Arch 的地位不断上升并有可能（部分）取代 Windows，原先分配的 252 GiB 空间根本不够 Arch 施展拳脚。因此现在迫切需要对分区结构进行修改。

虽然 KDE 和 Gnome 的分区管理器都很好用，但它们不允许你在开着 Linux 的情况下修改 Linux 自身所在的分区——这就好比你没法拆掉自己脚下正踩着的那块地板，要想拆掉它，得先把脚拿开。所以，我们需要一股外部力量来完成修改分区的操作——这股力量正是 LiveCD。

GParted Live

GParted 提供 LiveCD 版本，所以我选择了它。事实证明，这款软件虽然能用，但是存在着一些小问题……

首先是老生常谈的问题——NVIDIA 显卡驱动。第一次进系统时我选了 GParted Live (Default settings) 启动项，结果黑屏了。由于之前帮室友装 Ubuntu 的时候遇到过类似的问题，所以我直接给启动参数加上了 nomodeset，问题顺利解决。后来查看 GRUB 菜单时，发现启动项 GParted Live (Safe graphic settings, vga=normal) 也加了这个参数——下次就用它来启动系统。

接下来是分辨率过高的问题——无论是 GRUB 还是桌面环境，字都小到看不清。幸好我有之前配置 GRUB 的经验，于是直接修改了 /boot/grub/grub.cfg：

1
2
3
4
5
6
7
8

 if loadfont $font; then
-  set gfxmode=auto
+  set gfxmode=800x600x32,auto
   insmod gfxterm
   # Set the language for boot menu prompt, e.g., en_US, zh_TW...
   set lang=en_US
   terminal_output gfxterm
 fi

GRUB 的分辨率降下来了。令我惊喜的是，系统的分辨率跟随 GRUB，于是系统的分辨率也降下来了。

另外还有截图工具双击没有反应的问题。经过一番翻找，我找到了这个桌面图标对应的配置文件：~/.idesktop/screenshot.lnk，里面写着运行程序所需的命令：gl-screenshot。我在终端中运行了这个命令，输出如下：

1
2
3

$ gl-screenshot
No gdialog or Xdialog was found!
Program terminated!!!

GitLab issue 里面说这个问题在最新的测试版中已经修复。可惜我没有空去试了，因为我想玩点不一样的——群友的 LiveCD。

群友的 LiveCD

我在 archlinuxcn 交流群中求助时，有人建议我使用群友的 LiveCD，里面包含了 Xfce 桌面环境和 GParted 等实用软件。

第一次启动的时候图形界面没有自动启动，第二次启动的时候就有图形界面了，原因未知。

调节缩放比（Scale）似乎有问题，于是我只好降低分辨率（Resolution）。

以下是修改前的分区（截图工具没装，只好拍屏了）：

GParted，启动！

终于可以对分区进行大刀阔斧的改造了！下面是分解动作：

1. 将 D 盘压缩至 512 GiB。（为了避免 NTFS 兼容问题，我在这一步使用了 Windows 的磁盘管理工具。）

2. 将 swap 分区删除。

3. 将 Linux 主分区移动到空闲区域的最左侧。

4. 创建 swap 分区，大小为 24 GiB，位于空闲区域的最右侧。

   这台电脑有 16 GiB 内存。ArchWiki 上说，如果要启用休眠，那么 swap 分区的大小应不低于内存大小；RedHat 建议，如果要启用休眠，那么 swap 分区的大小应至少为内存大小的 1.5 倍。虽然我还没有启用休眠，但为了长远考虑，最后我分配了 24 GiB。

5. 将 Linux 主分区扩展，占满空闲区域。

以下是修改后的分区：

善后工作

GRUB 和 Arch 的配置都是基于原有的分区结构生成的，现在分区结构变了，配置却还没有更新，势必会带来问题。果不其然：启动 Arch 时，虽然系统能正常启动，但 swap 分区没有正确挂载。

我插上 Arch 启动盘，但这次不需要走完装系统的整个流程。只需要依次挂载主分区、挂载 EFI 分区、启用 swap 分区，然后运行 genfstab -U /mnt >> /mnt/etc/fstab 更新 /etc/fstab 即可。以下是 /etc/fstab 的变更情况：

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

 # Static information about the filesystems.
 # See fstab(5) for details.

 # <file system> <dir> <type> <options> <dump> <pass>
 # /dev/nvme0n1p7
 UUID=1c13125e-cd3c-427b-adb0-8155a5c5122a	/         	ext4      	rw,relatime	0 1

 # /dev/nvme0n1p1 LABEL=SYSTEM
 UUID=EC68-766C      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

 # /dev/nvme0n1p6
-UUID=4c079726-ded2-4448-9e3a-40eefb72eb90	none      	swap      	defaults  	0 0
+UUID=f85dc3e2-6486-4cb2-b002-73bf4bfe232f	none      	swap      	defaults  	0 0

注意到只有 swap 分区的 UUID 产生了变化（因为我删除并重新创建了 swap 分区），各个分区的编号都没有变。这就是为什么 GRUB 仍然可以启动 Arch。但保险起见，我还是重新运行了 grub-mkconfig。

腾讯会议（8.28 – 8.29）

我在暑假时就安装了腾讯会议（wemeet-bin^AUR），但一直苦于没有人能帮我测试各项功能是否正常。直到返校以后，才有了和室友一起测试的机会。

经过各方面的测试，我发现：腾讯会议大部分功能都能正常工作，唯一的问题是 Wayland 下不支持屏幕共享：开启屏幕共享后只能操作腾讯会议的控制栏，点击屏幕的其他地方都没有任何反应；同时，会议中其他人看到的只有黑屏。根据 AUR 中的评论，有两种解决方法：

1. 改用 X11。注销并使用 X11 重新登录。

2. 使用 OBS 创建虚拟摄像机。安装 obs-studio、v4l2loopback-dkms、linux-headers，打开 OBS 即可看到“启动虚拟摄像机”按钮。配置好场景（添加来源“屏幕采集(PipeWire)”并缩放到刚好占满屏幕），点击“启动虚拟摄像机”，然后打开腾讯会议，将摄像头切换为“OBS Virtual Camera”，即可共享屏幕。（参考链接）

   注意：画布比例应为 16:9，否则腾讯会议会裁剪掉多余的部分。另外腾讯会议会对摄像头内容进行重度压缩，并且没有办法关闭。

那么就是这样。

Windows 字体（10.23 – 10.24）

一份使用了多种艺术字体的 PPT，在 Arch 上打开的时候，全篇都是 Noto Sans——看来电脑字体太缺了，得把 Windows 自带的那一套字体装上了。

我在 ArchWiki 上找来找去，只找到了 ttf-win7-fonts^AUR，需要手动从 Windows 7 机器或安装包中提取字体。问了别人以后，才知道有 ttf-ms-win11-auto^AUR，支持自动下载字体。可能是我找的不够认真。

于是安装 ttf-ms-win11-auto^AUR，完成。

Fontconfig（10.26）

安装以后重启电脑，发现好多地方的字体都变成微软雅黑了。虽然 Plasma 和部分软件可以设置默认字体，但还是有相当一部分软件不行（比如微信！）。于是这些软件都变成了微软雅黑。

真是丑到家了！（下图为 IntelliJ IDEA 截图）

看来配置 Fontconfig 这件事不能再拖了，于是我花时间研究了一下。

首先，我们试着运行一下 fc-match -s（参考链接），看看默认情况下的字体优先级如何：

1
2
3
4
5
6
7

$ fc-match -s
msyh.ttc: "微软雅黑" "Regular"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
msyhl.ttc: "微软雅黑" "Light"
FreeSans.otf: "FreeSans" "Regular"
...

可以看到，微软雅黑是排在第一位的。

ArchWiki 上提供了好几种不同的 Fontconfig 配置，看得我眼花缭乱。于是我开始研究配置文件的语法，最后自己写了一份：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>
  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>Noto Sans</family>
      <family>Noto Sans CJK SC</family>
      <family>Noto Sans CJK TC</family>
      <family>Noto Sans CJK JP</family>
      <family>Noto Sans CJK KR</family>
    </prefer>
  </alias>
  <alias>
    <family>serif</family>
    <prefer>
      <family>Noto Serif</family>
      <family>Noto Serif CJK SC</family>
      <family>Noto Serif CJK TC</family>
      <family>Noto Serif CJK JP</family>
      <family>Noto Serif CJK KR</family>
    </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Fira Code Retina</family>
      <family>Noto Sans Mono</family>
      <family>Noto Sans Mono CJK SC</family>
      <family>Noto Sans Mono CJK TC</family>
      <family>Noto Sans Mono CJK JP</family>
      <family>Noto Sans Mono CJK KR</family>
    </prefer>
  </alias>
</fontconfig>

非常简洁。

保存到 ~/.config/fontconfig/fonts.conf，清空缓存，然后再运行 fc-match -s，可以看到 Noto Sans 已经排到第一位了。

1
2
3
4
5
6
7
8
9

$ fc-cache -fv
...
$ fc-match -s
NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
msyh.ttc: "微软雅黑" "Regular"
msyhl.ttc: "微软雅黑" "Light"
...

LLVM（？）

TODO

声音问题（1.20）

最近几天，我的 Arch 突然识别不到笔记本自带的扬声器了。“音量”一栏显示“没有找到输出或者输入设备”。但是耳机还可以正常工作。

经过一番检查，我发现原来是设置里声卡被停用了。真无语😓

Verilog 是一门非常宽松的语言。但这并不是件好事。

有时我会在写 Verilog 的时候犯一些语法错误，我以为编译器会报警告，但是并没有。于是我就要花大力气去排查错误，最后为自己的粗心大意搭上好多时间。我觉得，如果编译器为此而报错，确实不太合适，但好歹报个警告吧？可是 Verilog 是一门非常宽松的语言，于是编译器就会偷偷地做隐式类型转换。实在是烦死了！

在我写 P5 的时候，有一些模块间的接线忘记定义了。Verilog 没有报错误或警告，而是直接把它们当作了 1 位的 wire。不过幸运的是，这其中有些变量应该是多位的，在连接时产生了位宽不匹配的警告，这才使我注意到这个失误。

Verilog 自动生成变量的行为是可以关闭的，使用预处理指令 `default_nettype none 即可禁用其下方的自动生成。但是，某些依赖自动生成的地方也会受到影响（比如 input 和 output）。此时我们需要限定禁用自动生成的范围。以下是一个示例：

1
2
3
4
5
6
7
8
9
10

module Example (
    input ...,
    output ...
);

`default_nettype none
    ...
`default_nettype wire

endmodule

转眼到了 P6。我从周六晚上开始写 P6，一直写到凌晨两点；第二天起床接着写，一直写到快要吃晚饭才写完。当时测试样例过了，但是弱测没过。眼看着时间快不够了，我三两下吃完了晚饭，然后就蹬着单车直接去找助教了。（其实助教推荐的做法是自己构造测试数据，然后通过官方的 Analyzer 来评判测试数据的强度，从而不断改进测试数据，最终找出 CPU 中的 bug。）

助教帮我从八点 de 到九点，de 出了两个特别低级的错误。一是我将转发信号常量（常量写在 constants.v 里）从两位扩展到了三位，但是相应的接口都还是两位。于是在作比较的时候发生了隐式转换，最高位被裁掉了。二是我的 DM 有一个接口没有接线，当时预留了接口却没有准备好有关的信号，等到准备好信号之后却把接线的事情忘了。出人意料的是，仿真时 ISE 没有报一个警告。

当助教帮我 de 完 bug 的时候，教室里就剩一两个人了，助教们要收工了。看助教忙到这么晚，我感觉有些对不起助教。于是我问助教如何才能让 ISE 的语法检查更严一些。助教告诉我，可以试试综合。于是我试着点了一下综合，结果五彩斑斓的调试信息夹杂着花式警告顿时喷涌而出。但是呢，综合的缺点是耗时比较长，所以助教建议在 P8 以前不要综合。

我去隔壁宿舍请教了一位大佬，大佬说他知道的唯一的办法也是综合 orz

周六下午，我的室友发微信问我有关转发的事情。原来他正在重写 P5 课下。当时正巧我也在重构 P5，于是就和他讨论了起来。

所以他为什么要重写呢？其实他在周一的时候已经重构过一遍了，但是对代码质量仍然不满意，于是他拿着之前的设计文档，花了一个下午加晚上，一共五六个小时，重写了一遍。但是重写以后通不过测试了，于是他又开始 debug。

我对他说，我非常不建议他重写，因为如果在重写时遇到了 bug 就要花好多时间去 de，如果 de 不出来只能周日晚上去求助助教。如果万不得已要重写的话，最好进行“忒修斯之船”式的重写，一次只重写一小部分，然后过一遍弱测中测强测。

打包、弱测、中测、强测的过程十分麻烦，于是我整了一个小脚本，挺好用的。贴在下面：

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

#!/bin/bash
# 部分代码由 ChatGPT 生成。

if [ -f "./P5.zip" ]
then
    echo "错误：文件 'P5.zip' 已存在。"
else
    zip -j ./P5.zip ./P5_L0_weak_2023/src/*.v
    co-submit 1124-1245 ./P5.zip
    co-submit 1124-1006 ./P5.zip
    co-submit 1124-1204 ./P5.zip
fi

我们推着姥姥到院子里散步的时候，她指着一丛鹤立鸡群的花，说这是 pú lán 花。

我用手机扫了一下，发现这是蜀葵（Alcea rosea）。仔细看来，它长得笔直而坚挺，有些甚至比人还高。它那宽大的叶子集中在下部，像张开的手掌。而花瓣和果实，都挂在高挑的枝头上。它的花瓣是鲜艳的粉色，它的果实是扁平的圆盘。

可是我没有查到 pú lán 这两个字怎么写。家里有长辈写下了“簠簋”这两个字，可是它们不读 pú lán，它们读 fǔ guǐ。

转眼到了十月，十一的闲暇给了我重拾这些琐事的机会。我在偶然间发现，如果在搜索“pulan”时加入“方言”二字，就能搜到“笸篮”这个词。但是这个词并不读 pú lán，而是 pǒ lán。下面的这篇文章提供了一些线索：

笸（po）篮：小时候经常在各家里见到的，一种竹编的用来盛放剪刀、针线、碎步条等杂物的器具，圆盆形，直径约30多厘米，有的外面还有油漆；关中有的地方读作pulan；

——《陕西人常说的一百字，你能写出几个》

接着搜索“笸篮花”，搜索结果却少得可怜。

焰火

又称“放花”。一般于春节或元宵节等喜庆节日放焰火。洋县磨子桥焰火自清代以来为最著名者，曾奉调入京参加国庆焰火晚会。主要有竿子花、笸篮花、马花、冲天炮、满天星、流星赶月、闹龙宫、火树银花、连珠炮等160多个品种，五光十色，绚丽多彩。

这是出现次数最多的搜索结果，原因在于这篇文章已经被转载到泛滥，以至于无法查证来源了。除此之外只剩以下几处零星的提及了：

• ……用牛皮纸、白杉纸、皱纹纸、有光纸剪的窗花、炕窑花、窑顶花、纸缸花、笸篮花……——《华池县志愿服务实践活动助力非遗文化传承》
• ……这条路两边无数“笸篮花”热情欢迎……——《感情记忆|避暑龙潭社区之断想》
• ……妈妈在民国年间用最廉价的本贡纸和毛笔画下的母本花样、纸缸花、笸篮花、帽盒花、壁斗花……——《母亲与窑洞 不该忘记的“中国女红”》
• 我印象最深的是初夏，门前院子和地的交界处，粉色的笸篮花（至今也不知学名）……——《第1449期【沈秀芳系列散文】我家的老房子（上）》
• 以及一部小说。

或许这只是少数人的一种叫法吧。

另外这些搜索结果都有一个共同点：就是它们都没有解释笸篮花是什么花。