2025-03-30 00:00:00
Clang 是一个基于 LLVM 的 C/C++ 编译器，与 GCC 相比有一些优势
如果 Linux发行版比较新，可以直接用包管理器安装；但如果发行版比较老旧，就只能编译安装了。本文介绍一些编译安装clang 的方法。
Clang 是 LLVM 项目的一部分。LLVM是一个编译器基础设施，它定义一种中间代码(IR)，并且能够将这种中间代码编译成各个平台 (x86, ARM, …) 的机器码。这在LLVM 中称为编译器后端。而 clang 则是 C/C++的编译器前端，负责将 C/C++ 代码编译成 LLVM中间代码。因此要编译安装 clang，我们就要编译 LLVM。
我们进入 LLVM 官网的下载页面 https://releases.llvm.org/ 下载 LLVM 源码。LLVM 10.0.0之后提供整合包 llvm-project 下载，包含clang 在内的各种 LLVM 组件。以最新的 20.1.0 为例，我们直接下载 LLVM20.1.0 并解压
1 |
|
LLVM 使用 CMake 构建，要求版本至少为 3.20.0。进入 llvm-project目录，接着创建 build 目录，然后执行 cmake
1 |
|
CMake 这一步可以传入各种参数，这里介绍一些常用的参数
CMAKE_BUILD_TYPE 构建类型，可以为 Debug,Release, RelWithDebInfo, 或MinSizeRel。默认为 Debug，一般设置为Release。DLLVM_ENABLE_PROJECTS 启用的组件。llvm-project中有很多组件，除了 clang，常用的还有clang-tools-extra 额外工具集。包含 clangd, clang-tidy,clang-doc, clang-include-fixer 等。lldb 调试器。Clang 编译的程序用 gdb调试可能会遇到各种问题，最好用 lldb 调试。lld 链接器，可替代 ld。bolt, polly, libclc等组件，具体可参见 LLVM 文档。多个组件之间用分号 ;分隔。DLLVM_ENABLE_RUNTIMES 启用的运行时组件。常用的组件有compiler-rt 编译器运行时。如果要用 Sanitizer系列工具（如 ASan），则必选。libcxx 和 libcxxabi 是 LLVM 的 C++标准库实现。Clang 默认将程序链接到系统的 libstdc++，但如果要链接到 LLVM的标准库 libc++，这两个必选libunwind 实现堆栈展开的库。如果要链接到libc++，则必选。libc, llvm-libgcc,offload 等组件，具体可参见 LLVM 文档。多个组件之间用分号; 分隔。CMAKE_INSTALL_PREFIX 安装路径前缀，默认为/usr/local。CMAKE_C_COMPILER 和 CMAKE_CXX_COMPILER分别指定 C 和 C++ 的编译器，默认为 gcc 和g++。后面我们会用到这两个参数。LLVM_ENABLE_LIBCXX 是否链接到 libc++。默认链接到libstdc++。后面我们会用到这个参数。如果 LLVM 的各个依赖项都没有问题、这一步成功后，便可执行make 开始构建
1 |
|
如果一切顺利，执行 sudo make install即可完成安装。安装前可以执行 make check-clang 执行 clang的测试用例，确认没有问题。
要成功构建 LLVM 20.1.0，GCC 版本至少为 7.4。然而在一些老旧发行版（如CentOS 7）中，GCC版本并不能满足要求。为此我们需要先用系统的老版编译器编译一个新版编译器，再用新版编译器编译LLVM。
1 |
|
这里我们编译的 gcc-9.1.0 是用于构建 LLVM的“临时”编译器，我们不把它安装到系统目录(/usr/local/)，而是安装到 ~/toolchains。GCC是系统编译器，不可随意升级，否则可能导致系统其它软件出现兼容性问题。
接着我们用刚刚编译的 gcc-9.1.0 构建 LLVM。
1 |
|
这里我们用 -DCMAKE_C_COMPILER 和-DCMAKE_CXX_COMPILER 指定 C/C++ 编译器的完整路径，也就是gcc-9.1.0 的安装路径 ~/toolchains/ 下的bin/gcc 和 bin/g++。LLVM构建过程中会执行编译出来的工具，这些工具都依赖于 gcc-9.1.0 的 C++运行库。因此我们要用环境变量 LD_LIBRARY_PATH指定动态库路径，确保它们能正常运行。
因为这样构建的 LLVM 工具链都依赖于 gcc-9.1.0 的运行库，我们要设置好LD_LIBRARY_PATH 才能正常运行它们。
1 |
|
前面使用 gcc-9.1.0 编译的 LLVM 工具链虽然可以运行，但是却依赖于gcc-9.1.0 的运行库。由于系统的 C++ 运行库不能随意升级，我们不便将gcc-9.1.0 的运行库安装到系统中。这里比较合适的做法是让 clang 做一次bootstrap（自举），用 gcc-9.1.0 编译的 clang 构建 LLVM，并链接到 LLVM 的C++ 运行库（也就是 libc++）。
1 |
|
这里我们则是将编译器路径设置成前面用 gcc-9.1.0 编译的 clang的路径。同时设置 -DLLVM_ENABLE_LIBCXX=ON 链接到 LLVM 的libc++。最后注意环境变量 LD_LIBRARY_PATH 除了需要指定gcc-9.1.0 的运行库路径之外，还需要指定前面 gcc-9.1.0 编译的 LLVM的运行库路径。
构建完成后，执行 sudo make install 安装即可。由于 LLVM20.1.0 的 C++ 运行库位于lib/x86_64-unknown-linux-gnu/（更老版本的 LLVM 则直接在lib/ 里），我们通常需要再配置下动态库搜索路径。
1 |
|
这样安装的 clang 就能正常运行了。
1 |
|
参考资料:
2025-02-16 00:00:00
在 C++开发中，内存越界是很头痛的问题。这类问题往往非常隐蔽，难以排查，且难以复现。为了排查这类问题，我们可以使用Address Sanitizer 这个工具。
Address Sanitizer (aka ASan) 是 Google开发的一款内存错误排查工具，帮助开发这定位各种内存错误，目前已经集成在主流工具链中。LLVM3.1 和 GCC 4.8 以上的版本均支持 ASan。本文介绍 ASan的使用方法和其基本原理。
在支持 ASan 的编译器加上编译参数 -fsanitize=address即可开启 ASan。例如我们有代码 test.c：
1 |
|
虽然存在内存越界写入，但是使用常规方法编译后，是能够“正常”运行的：
1 |
|
加上编译参数 -fsanitize=address 启用 ASan后，运行便会触发 ASan 报错：
1 |
|
ASan 告诉我们程序触发了一个堆越界 (heap-buffer-overflow)的报错，尝试在地址 0x602000000014 写入 4字节数据。随后打印出出错位置的堆栈。第 10 行 ASan还告诉我们越界的内存是在哪个位置被分配的，随后打印出分配位置的堆栈。
ASan的参数有编译参数和运行时参数两种。常用的编译参数有：
-fsanitize=address 启用 ASan-fno-omit-frame-pointer 获得更好的堆栈信息--param FLAG=VAL 传入，LLVM使用 -mllvm -FLAG=VAL 传入：asan-stack 是否检测栈内存错误，默认启用。GCC 使用--param asan-stack=0、LLVM 使用-mllvm -asan-stack=0 关闭栈内存错误检测。asan-global是否检测全局变量内存错误，默认启用。同理使用--param asan-global=0 或 -mllvm -asan-global=0可关闭。运行时参数通过环境变量 ASAN_OPTIONS设置，每个参数的格式为 FLAG=VAL，参数之间用冒号: 分隔。例如：
1 |
|
常用的运行时参数有：
log_path: ASan 报错默认输出在stderr。使用这个参数可以指定报错输出的路径。abort_on_error: 报错时默认使用 _exit结束进程。指定 abort_on_error=1 则使用 abort结束进程。disable_coredump: Asan 默认会禁用 coredump。指定disable_coredump=0 启用 coredump。detect_leaks: 是否启用内存泄漏检测，默认启用。ASan还包含 LSan (Leak Sanitizer) 内存泄露检测模块。handle_*: 信号控制选项。ASan默认会注册一些信号处理函数，参数置 0 表示让 ASan不注册相应的信号信号处理器，置 1 则注册信号信号处理器，置 2则注册信号处理器并禁止用户修改。handle_segv: SIGSEGVhandle_sigbus: SIGBUShandle_abort: SIGABRThandle_sigill: SIGILLhandle_sigfpe: SIGFPE因为 ASan 默认会注册 SIGSEGV的信号处理器，所以当程序发生段错误时，会触发 ASan 的报错而不是直接coredump。要想让程序像往常一样产生 coredump，可以指定参数handle_segv=0 不注册信号处理器，和disable_coredump=0 启用 coredump。
有些函数可能会做一些比较 hack 操作，又想绕过 Asan的越界检测。这可以通过声明属性__attribute__((no_sanitize_address)) 实现。例如
1 |
|
这样即使 chunk_size 访问越界，ASan 也不会报错。
更多参数可参考
ASan需要检测的是应用程序是否访问已向操作系统申请、但未分配给应用程序的内存，也就是下图中红色的部分。至于图中白色的部分，也就是未向操作系统申请的内存，是不需要检测的（一旦访问就会触发段错误）。
ASan 会 hook 标准内存分配函数（malloc、free等），所有未被分配和已释放的区域都会标记为红区。所有内存的访问都会被检查，如果访问了红区的内存，asan会立刻报错。例如，原本简单的内存访问
1 |
|
在启用 ASan 后，会生成类似如下的代码：
1 |
|
为了标记内存是否为红区，ASan 将每 8 字节内存映射成 1 字节的 shadow内存，在 shadow 内存中标记这 8 字节内存的使用情况。64 位系统中，地址 p对应的 shallow 内存的地址为(p >> 3) + 0x7fff8000。
因为 malloc 分配的内存必然是 8 字节对齐的。这样的话只有 9种情况：
例如 malloc(11) 分配 11字节内存的情况，如下图所示。第一个 8 字节都不在红区，对应的 shadow内存值为 0；第二个 8 字节前 3 字节不在红区，后 5 字节在红区，对应的shadow 内存值为 3。第三个 8 字节都在红区，对应的 shadow内存值为负数。
这样，整个地址空间被分为 5 个部分。HighMem 对应 HighShadow，LowMem对应 LowShadow。如果一个地址对应的 shallow 内存在 ShadowGap区域，则这个地址不可访问。因为 64位机器的虚拟内存地址空间很大，这样划分后地址仍然很够用。
| 地址区间 | 区域 |
|---|---|
| [0x10007fff8000, 0x7fffffffffff] | HighMem |
| [0x02008fff7000, 0x10007fff7fff] | HighShadow |
| [0x00008fff7000, 0x02008fff6fff] | ShadowGap |
| [0x00007fff8000, 0x00008fff6fff] | LowShadow |
| [0x000000000000, 0x00007fff7fff] | LowMem |
这样，每当程序要访问内存时，ASan 都会做如下检查：
1 |
|
假设某 8 字节内存后 3 字节在红区，程序要从第 4字节开始访问两字节，如下图所示。那么有 address % 8 = 4，last = 4 + 2 - 1= 5 >= shadow，因此这次访问是越界访问，ASan 就会报错。
了解了 ASan 原理之后就能更好地理解 ASan 的报错信息。ASan报错时会打印出报错位置的 shadow 内存情况：
1 |
|
程序试图在 0x602000000014 写入 4 字节数据。 0x602000000014 对应的shadow 内存地址为 (0x602000000014 >> 3) + 0x7fff8000 =0x0c047fff8002，也就是上面 [04] 的位置。0x602000000014 % 8= 4，从这 8 字节的第 4 字节开始访问四字节。而这 8字节后四字节都在红区，因此访问越界。
参考资料:
2024-06-14 00:00:00
协程与线程（进程）
线程切换由操作系统负责，而协程切换通常由程序员直接控制。程序员通过resume/yield 操作控制协程切换。resume 操作唤醒一个指定协程；yield操作挂起当前协程，切换回唤醒它的协程。如果你用过 Lua的协程，就会很熟悉这套流程。不过 Lua 是基于 Lua虚拟机（LVM）的脚本语言，它只需要 LVM中执行“虚拟的”上下文切换。本文介绍如何用 C 语言（和一点点汇编）实现一个native 协程，执行真正的上下文切换。这个实现非常简单，总共不到 200行代码。我参考了 libco的实现。本文的完整代码见
所谓的上下文，就是一段程序之前做了什么，接下来要做什么，以及做事情过程的中间产物。例如我们有函数f。f需要知道下一个指令是什么才能接着往下执行，便是“接下来要做什么”。f函数还需要知道之前是谁调用了它，以便把结果返回给调用者，便是“之前做了什么”。在f函数执行过程中，局部变量要存好（不能被写坏），接下来的指令才能正确执行。这便是“过程的中间产物”。
在 x86-64 下，“之前做了什么” 存储在栈里。函数调用会执行call指令，把当前函数的下一个指令的地址压入栈顶，然后再跳转到被调用函数。被调用函数返回时执行ret指令，从栈顶取出调用者的返回点地址，然后跳转到返回点。因此栈上存有所有前序调用者的返回点地址。
函数的局部变量通常储存在 16个通用寄存器中，如果寄存器不够用，就存在栈里（只要在函数返回前将它们弹出，让栈顶是返回点地址即可）。函数调用的参数也是局部变量，存在约定的6 个通用寄存器里。如果不够用，也存在栈里。
至于“接下来要做什么”，其实也在栈里。上下文切换不过是调用一个函数，调用者在调用它之前已经把下一个指令的地址压栈了。当上下文切换函数返回，ret指令自然会跳转到接下来要执行的指令。所以上下文就是 16 个通用寄存器 +栈。
所有的协程共享同一个 CPU，也就共享同样的 16个通用寄存器。如果我们要把 A 协程切换成 B 协程，就要把当前 16个通用寄存器的值存在 A 协程的数据结构里；然后再从 B 协程的数据结构里取出B协程的寄存器的值，写回通用寄存器中。我们还要处理栈。不过栈与寄存器不同，x86-64规定 %rsp寄存器（也是通用寄存器之一）存的值便是栈顶的地址。不同的协程不必共享栈，它们可以分配各自的栈，上下文切换时将%rsp 指向各自的栈顶即可。
实际上我们不必存储全部的 16个通用寄存器，它们有些是暂存寄存器（ScratchRegisters），是允许被写坏的。这些寄存器的值可能在执行一次函数调用后就变了（被被调用函数写坏的）。编译器也不会在暂存寄存器里存储函数调用后还要用的值。参考libco 的实现，我们存储 13 个寄存器：
1 |
|
有些寄存器有特殊的用途。这里我们只需要知道这三个：
%rsp: 栈寄存器，指向栈顶。%rdi, %rsi:第一参数寄存器和第二参数寄存器，调用函数前将第一个参数存在%rdi 里，第二个存在 %rsi 里（剩下的四个依次是%rdx, %rcx, %r8,%r9, 不过这里我们用不上），然后执行 call指令。接着我们定义一个函数做上下文切换，把当前通用寄存器的值保存在curr 中，再把 next中保存的寄存器的值写回各个通用寄存器。
1 |
|
Emm，这个函数没法用 C语言实现，我们得用到一点点汇编了。其实非常简单，我们只需要用movq 指令存取寄存器。代码如下：
1 |
|
不懂汇编没关系（其实我也不是很懂），只需要知道 movq指令将第一个操作数的值复制到第二个操作数中。%开头的标识符为寄存器。%rsp这样不带括号的，表示存取寄存器的值。(%rdi)这种带括号的，表示去内存里存取地址为 %rdi的数据。如果括号前面有数字几，就表示这个地址要加几。movq存取数据的长度为 8 字节，寄存器的长度也是 8 字节。
还记得前面说过，%rdi 是第一个参数，%rsi是第二个参数吗？所以 %rdi 就是struct co_context *curr。96(%rdi) 就是curr->regs[12]，88(%rdi) 就是curr->regs[11]，……，(%rdi) 就是curr->regs[0]。上半部分把 13 个通用寄存器的值全部存到了curr 里。同理 %rsi 就是struct co_context *next。(%rsi) 就是next->regs[0]、8(%rsi) 就是next->regs[1]，依次类推。于是下半部分把next 中保存的寄存器的值写回寄存器中。最后执行ret 指令返回。
注意 29 行写入 %rsp 的值就是上次挂起时第 4行保存的值，这个值我们原封未动，也没有做任何栈操作。因此最后ret 返回时，栈顶就是 co_ctx_swap的调用者设置的返回点地址。一个协程调用 co_ctx_swap将自己挂起，便陷入沉睡。当 co_ctx_swap返回之时，便是其它协程调用 co_ctx_swap将它唤醒之时。此时寄存器被还原、栈被还原、也回到了返回点。它便知道自己之前做了什么、接下来要做什么、中间产物是怎样的。
struct co_context仅存储协程的上下文。我们还需要维护给协程分配的栈空间、记录入口函数地址等。我们定义struct coroutine 表示协程对象。
1 |
|
co_new 创建一个新协程，接受两个参数：start协程入口函数指针，和 stack_size 栈大小；这类似于pthread_create。co_new分配协程的栈空间并设置好各个字段。
要把主线程切换到我们新创建的协程，这里有两个问题。一是主线程并不是一个协程，新协程跟谁交换上下文呢？二是新创建的协程的上下文是空的（19行），切换过去肯定跑不起来。
第一个问题很简单：创建一个就行。因为主线程已经跑起来了，要切换到新协程，主线程只需要一个“容器”把它的上下文装进去。直接执行main = co_new(NULL, 0) 创建主协程，调用co_ctx_swap(&main->ctx, &new->ctx)便可切换到新协程。此时主线（协）程的上下文保存在 main中，当新协程反向调用co_ctx_swap(&new->ctx, &main->ctx)，便又切换回主协程了。
为了解决第二个问题，我们需要对新协程初始化。co_ctx_swap将新协程的上下文复制到 CPU 后，执行 ret返回栈顶记录的地址。因此我们要将栈顶置为协程入口函数的地址，这样在co_ctx_swap 返回后便跳转到协程入口函数了。
1 |
|
因为 x86 的栈是从高地址向低地址增长的，初始栈为空，所以栈顶应该指向co->stack 的最末尾。又因为 x86 的栈必须 16字节对齐，所以执行 (intptr_t)sp & -16LL（-16 低 4 位为0，其它都为 1）得到栈顶地址。然后将栈顶置为co->start，也就是入口函数的地址。最后我们把保存的 rsp寄存器的值设置为栈顶地址，这个值会在 co_ctx_swap被复制到寄存器 %rsp 中。
现在我们的协程已经可以跑起来了。写一个简单的例子试试：
1 |
|
把上面所有的 C 代码复制到文件 co.c，汇编代码存为co.S，然后执行 gcc -o co co.c co.S编译，运行试试！
现在的协程虽然可以跑，但是使用起来很不方便，需要手动交换上下文，也容易出错。我们需要实现resume/yield 操作。resume操作唤醒指定协程，也就是当前协程与指定协程交换。yield挂起当前协程，将当前协程与上次唤醒它的协程交换。因此我们需要记录当前运行的协程；而对于每个协程，要保存唤醒它的协程的指针。
协程切换要遵循这几条规则：
基于此，我们给协程定义五个状态：
1 |
|
我们使用全局变量 g_curr_co记录当前协程。每个协程还要记录当前状态和唤醒自己的协程。
1 |
|
接着实现 resume 操作和 yield操作。根据上面描述的思路，实现起来很容易。
1 |
|
除主协程外的协程结束运行时一定要执行 yield操作将自己切出，否则它不知道该返回到哪儿。为了不让使用者手动执行这个操作，我们将协程入口函数封装一层。
1 |
|
这样我们的协程用起来就更方便了:
1 |
|
resume/yield 可以用于传递参数。运行上面的例子，我们发现co_yield 返回之时便是其它协程调用 co_resume之时；而 co_resume 返回之时又是其它协程调用co_yield 之时。因此 resume 操作接受参数，传递给 yield返回；yield 操作接受参数，传递给 resume返回。这样方便在协程之间传递数据。
我们在 struct coroutine 中新增一个 data字段用于传递参数。协程切换时，如果要给目标协程传递参数，就对目标协程的data 字段赋值。协程切换后，就能从 data字段中取出上一个协程传递的参数。
1 |
|
我们重新定义协程入口函数，让它接受参数和返回值。第一次 resume的参数传给入口函数；入口函数的返回值在最后一次 yield 时传出去。
1 |
|
现在，我们的协程库已经完全实现了。我们可以写一些例子测试一下。比如说我们可以创建一个源源不断生成以n 开头的自然数的协程：
1 |
|
运行结果就是
1 |
|
这个协程就是一个无限流。我们还可以写一个将两个无限流逐项相加的协程：
1 |
|
然后将 0 开头的自然数流与 1 开头的自然数流逐项相加，得到奇数无限流（0+ 1 = 1, 1 + 2 = 3, 2 + 3 = 5, …）
1 |
|
运行结果就是
1 |
|
当然还有更好玩的。我们可以实现一个斐波那契数列生成器。斐波那契数列可以自我定义：令f(i) 是以第 i 项开头的斐波那契数列，f(a) + f(b)表示将两个数列逐项相加，那么如下所示，f(2) = f(0) + f(1)。
1 |
|
所以我们可以这样做
1 |
|
运行结果便是斐波那契数列：
1 |
|
不过这种写法会创建大量协程，性能很低。仅供演示（炫技）。
2024-06-08 00:00:00
我最近读完了《理想国》。这本书为古希腊哲学先贤柏拉图所著，是哲学经典之作、奠基之作，内容晦涩深奥，比较难懂。本人才疏学浅，以我的贫乏的哲学素养，难以完全领会其中深邃的思想。然而读完之后，仍然对我的价值观造成了不小的冲击。这里斗胆分享两点我的体会。
中国有句古话，叫做成王败寇。胜者为正义，败者为邪恶。蒙古铁蹄南下，击败南宋，占据中原，成为正统王朝，自然是正义。元末朱元璋起兵驱逐鞑虏，恢复中华，自然也是正义。但如果朱元璋失败了会怎样？自然是和其它千千万万失败农民起义一样，被列为乱臣贼子，成为邪恶的化身。正义与邪恶似乎是相对的概念，胜利者定义的价值即为正义。“邪不压正”不是规律，而是结果：正是因为甲战胜了乙，甲便是“正”；如果“邪”压住了“正”，“邪”就变成了正。
我曾经一度相信这种观点。然而柏拉图全然否定了这个观点。因为如果把胜利者定义为正义，反对胜利者定义为邪恶，我们可以作出这样的推导：
胜利者是正义的，所以胜利者制定的法律也是正义的。因此遵纪守法是正义的，违法犯罪是不正义的。
那么按照现行法律，谋杀是不正义的、抢劫是不正义的、盗窃是不正义的、贪污是不正义的、诈骗是不正义的。
与这些行为相关的品质也是不正义的。所以伤害他人是不正义的、损人利己是不正义的、贪婪是不正义的、奸诈狡猾是不正义的。
我们说一个贪婪、损人利己、奸诈狡猾的人是坏人，他会做坏事。个人的力量有限，他能做的坏事相对较小。我们试图让一群这样的坏人聚在一起，看看他们能不能做一件更大的坏事，甚至是最大的坏事：把正义——当前的胜利者——推翻？
然而他们会让我们失望的：一群贪婪、损人利己、奸诈狡猾的人，无论如何不能团结起来。越是不正义的个人，越不能团结成不正义的群体。因此不正义的人终究无法完成任何伟业。书中原话是这么说的：
我们看到正义的人的确更聪明能干更好，而不正义的人根本不能合作。当我们说不正义者可以有坚强一致的行动，我们实在说得有点不对头。因为他们要是绝对违反正义，结果非内讧不可。他们残害敌人，而不至于自相残杀，还是因为他们之间多少还有点正义。就凭这么一点儿正义，才使他们做事好歹有点成果；而他们之间的不正义对他们的作恶也有相当的妨碍。因为绝对不正义的真正坏人，也就绝对做不出任何事情来。
因此我们发现，即使是黑帮，也要讲究道义，要求遵守纪律。他们能在一定程度上团结在一起，正是因为他们还有一些正义。蒙古能灭南宋，因为蒙古有一定的正义；而南宋，却冤杀岳飞，昏庸腐败，致使生灵涂炭，怎能说它没有不正义。而元朝末年亦是“人心离叛，天下兵起，使我中国之民，死者肝脑涂地，生者骨肉不相保”，也是它的不正义导致了灭亡。
所以无论怎么改朝换代，无论谁是胜利者，法律永远禁止谋杀、抢劫、盗窃、贪污和诈骗。所以邪不压正，是因为邪本来就不压正，这是规律，不是结果。
社会上流行这样的观点：好人和坏人是相对的，只是立场不同；小孩子才讲对错，大人只看利弊。但这种善恶相对的观点很危险。如果认为正义与邪恶是相对的概念，就不会相信真正的良善是存在的。人就可能会走邪路，成为自私自利、损人利己、为达目的不择手段的人。
为了探寻什么是正义，柏拉图构想了一个理想的城邦，一个“理想国”。在这个城邦里，不同的人分工合作，每个人在国家里执行一种最适合他天性的职务。工匠制作工具，农民种田，皮匠做鞋，以及“爱智慧的人
柏拉图将人与城邦类比。一个城邦有形形色色的人，一个人内心也有不同的部分。一个人内心有受理性控制的部分，也有受欲望控制的非理性的部分，也有受激情控制的部分。柏拉图认为在这三部分中，理性的部分应该担任“领导者”，就像理性的人在应当在城邦担任领导者一样。
理智既然是智慧的，是为整个心灵的利益而谋划的，还不应该由它起领导作用吗？激情不应该服从它和协助它吗？
正义的人不许可自己灵魂里的各个部分相互干涉，起别的部分的作用。他应当安排好真正自己的事情，首先达到自己主宰自己，自身内秩序井然，对自己友善。
不正义应该就是三种部分之间的争斗不和、相互间管闲事和相互干涉，灵魂的一个部分起而反对整个灵魂，企图在内部取得领导地位——它天生就不应该领导的而是应该像奴隶一样为统治部分服务的，——不是吗？我觉得我们要说的正是这种东西。
我们常说“做自己的主人”，柏拉图说人怎么才能做自己的主人呢？因为如果说一个人是自己的主人，那他同时也是自己的奴隶。他认为这句话的意思是，一个人内心理性的部分要做非理性部分的主人。理性会让人追求智慧，会在必要时抑制欲望与激情；在他需要战斗时，又会释放激情。这样，这个人便是智慧的、理性的、勇敢的、节制的。这样的人便是正义的人。
我曾经认为，人的快乐不取决于人拥有多少物质，而取决于拥有的物质的变化。例如，假设你在路上捡到一千块钱，你会快乐，但仅限于得到这些钱的这一刻。你不会因为资产增加了一千元而一直开心。再比如年收入只有10 万的时候会想，要是我一年能赚 20 万就好了。然而当收入真的变为 20万时，他会发现快乐只存在于收入变化的这一小段时间，之后便开始追求更高的收入了。痛苦便与之相反：当人失去物质时，会感受到痛苦，但痛苦也仅存在于失去的这一刻。我甚至提出了一个“快乐公式”：函数\(f(t)\) 表示
然而柏拉图全然否定了这个观点。柏拉图认为世界上有快乐，也有痛苦；还有一种介于快乐和痛苦之间的平静的状态。把快乐、平静、痛苦比喻为上、中、下三级。但人在受到痛苦时会把摆脱痛苦称为快乐，然而摆脱痛苦实际是中间的平静的状态，并不是什么享受。例如生病的人会说，没有什么比健康更快乐的了。然而他们在生病之前并不曾觉得那是最大的快乐。同样，当一个人正在享乐，让他突然停止享乐，进入平静的状态，也是痛苦的。然而平静怎么可以既是快乐又是痛苦呢？这便推导出矛盾了。因此柏拉图认为这种对比出来的快乐不是真的快乐，只是快乐的影像。
和痛苦对比的快乐以及和快乐对比的痛苦都是平静，不是真实的快乐和痛苦，而只是似乎快乐或痛苦。这些快乐的影像和真正的快乐毫无关系，都只是一种欺骗。
柏拉图认为，通过肉体上的享受得到的快乐，大多数属于“快乐的影像”，是某种意义上的脱离痛苦。例如人饥饿时吃食物会觉得无比的美味，这种快乐实际上是脱离痛苦。更进一步地，因欲望的满足而得到的快乐，大多属于“快乐的影像”。人对某事物有了欲望，求而不得，感到痛苦。欲望越强，越求而不得，就越痛苦，得到它时就越“快乐”。然而这种“快乐”某种意义上是痛苦的脱离，只是“快乐的影像”，不是真正的快乐。
柏拉图认为有一种真正的快乐，得到它之前不会感到痛苦，出现的时候能感受到强烈的快乐；停止之后也不留下痛苦。例如当你坚持学习，头脑变得越来越充实的时候；领悟了某个真理时那种”朝闻道，夕死可矣”的满足感。我还记得当时理解了Y-Combinator，学会了用 CPS 变换实现 call/cc的时候的那种兴奋感，真的能让人快乐好几天。柏拉图认为，用理性的部分追求智慧、美德得到的是实在的东西，而肉体上的享受是不实在的东西。让实在的东西填充内心才能得到可靠的真实的快乐。
那么，没有经验过真实的人，他们对快乐、痛苦及这两者之中间状态的看法应该是不正确的，正如他们对许多别的事物的看法不正确那样。因此，当他们遭遇到痛苦时，他们就会认为自己处于痛苦之中，认为他们的痛苦是真实的。他们会深信，从痛苦转变到中间状态就能带来满足和快乐。而事实上，由于没有经验过真正的快乐，他们是错误地对比了痛苦和无痛苦。正如一个从未见过白色的人把灰色和黑色相比那样。
因此，那些没有智慧和美德经验的人，只知聚在一起寻欢作乐，终身往返于我们所比喻的中下两级之间，从未再向上攀登看见和到达真正的最高一级境界，或为任何实在所满足，或体验到过任何可靠的纯粹的快乐。他们头向下眼睛看着宴席，就像牲畜俯首牧场只知吃草，雌雄交配一样。须知，他们想用这些不实在的东西满足心灵的那个不实在的无法满足的部分是完全徒劳的。由于不能满足，他们还像牲畜用犄角和蹄爪互相踢打顶撞一样地用铁的武器互相残杀。
柏拉图称肉体上的享受为不实在的东西，认为内心的欲望是不实在的无法满足的部分。现代科学在一定程度上支持柏拉图的观点。肉体上的享受得到的快乐来源于多巴胺。多巴胺能给人带来快乐，然而代价是当多巴胺消退时，人会感觉到空虚和痛苦，需要更大剂量的多巴胺才能弥补这些痛苦。于是人对多巴胺的追求永远不会满足，这个过程最终会变成一种折磨。而人在节制、自律的时候会分泌内啡肽，它给人带来的快乐是缓慢持续的；当它消退时也不会感到痛苦。自律和节制能给人带来更高级的快乐。这也是罗翔所说的，低级的快乐来自放纵，高级的快乐来自克制。
我过去提出的那个“快乐公式”只适用于通过多巴胺获取的快乐。也就是柏拉图所说的，往返于中下两级之间，从平静和痛苦之间感受快乐的影像。
最后柏拉图认为正义的人是真正快乐的，因为他们是理性的、节制的。他们会追求智慧，追求真理，这其中得到的快乐要胜与满足欲望得到的快乐。一个极端不正义的人欲望会无限膨胀，理性成为欲望的奴隶，他永远无法满足，给他再多的物质也得不到快乐。
2024-04-19 00:00:00
我们知道，不同于 Windows 将软件的所有文件安装在一个目录，一个 Linux软件的不同部分会被安装在不同路径。例如，可执行文件安装在/usr/bin 下；库文件安装在 /usr/lib下；文档、脚本等资源文件通常安装在 /usr/share下等。这是因为 Linux认为软件包之间会相互依赖，不同的软件可能依赖于同一个库，那么这个库就只应该存在一份。例如curl, ssh 和 nginx 都依赖于 libcrypt.so 这个共享库，其为 openssl的一部分。当我们使用 apt 安装 nginx 时，先会检测 openssl是否已经安装。如果没有，就先安装 openssl；否则直接安装 nginx。
这样做的好处是可以节省磁盘：所有软件依赖的相同的库只存在一份。因此安装一个Linux 系统通常只需要几 G 的磁盘空间，而 Windows 通常需要几十G。同时可以节省内存，因为共享库的加载方式是mmap，同一个共享库在内存中也只有一份。
但是这么做是有代价的。假设 A, B 软件都依赖于库 L，那么 A 和 B就只能依赖于同一个版本的库L。一台机器上有这么多软件，意味着整个依赖网络让他们相互钳制，版本号被限制，不能随意升级。一个发行版会确定各种软件包的版本（确定主次版本号，补丁号通常不做限制），组成软件库，确保它们相互兼容，没有依赖冲突。也就是说apt 安装的软件版本由当前 Ubuntu 版本决定的。这也是为什么Linux 发行版通常每年都要发布一个新版本，否则软件库会落后于时代。
如果你在用一个较老的发行版，想安装一些新软件，通常需要自己编译。自己编译的软件通常安装在/usr/local/* 下，与 /usr/*区分开。但是我公司用的开发环境的发行版太老了，g++ 版本 4.8，只支持 C++11，无法编译要求支持 C++ 17 的新软件。更糟糕的是这个发行版的 glibc版本也非常老，新软件即使在新系统中编译出来，也无法在这个老系统上运行。而gcc 工具链（包括 glibc）是操作系统的一部分，不能随意升级。
要是能像 Windows 一样将软件的依赖的各种 DLL 都打包到一起就好了！Linux有类似的解决方案，AppImage 就是其中一种。它可以将软件打包成一个二进制AppImage 文件，这是一个标准的 ELF 可执行文件。用户下载 AppImage文件后，直接 chmod +x 后就可以直接运行，非常方便。对于AppImage 来说，一个软件就是一个可执行文件。
1 |
|
AppImage 的原理是将软件和相关依赖归档成一个磁盘镜像，打包在 AppImage文件里。这个归档的目录称为 AppDir，它的结构大概是这样的：
1 |
|
运行 AppImage 文件时，其中的磁盘镜像会被挂载到/tmp/.mount_XXX.XXXXX 上，然后执行其中的 AppRun。AppRun可以是一个脚本，也可以是一个二进制，它负责做一些前序工作，设置各种环境变量（如LD_LIBRARY_PATH），然后启动目标程序。
接下来我们动手制作一个 AppImage。我们有一个 C 程序hello.c
1 |
|
然后编译它 gcc -o hello hello.c。接着我们创建一个AppDir 目录，将 hello 放到AppDir/usr/bin/ 中。
1 |
|
接着我们要将程序依赖的共享库也打包进去。我们用 ldd 查看hello 依赖的共享库：
1 |
|
hello 很简单，只依赖 libc。链接器/lib64/ld-linux-x86-64.so.2为程序加载各种共享库，是程序的解释器(interpreter)，也需要打包进去。我们把这两个 .so 文件复制到 AppDir的对应目录：
1 |
|
接下来我们创建 AppRun 脚本。这个脚本先设置LD_LIBRARY_PATH 环境变量，然后用 AppDir 中的链接器加载运行hello 程序：
1 |
|
AppImage 运行时环境变量 APPDIR 便是 AppDir挂载的路径（/tmp/.mount_XXX.XXXXX），我们可以直接在脚本中引用它。最后我们需要一个desktop 文件配置一些元数据，还要准备一个图标文件：
1 |
|
最终 AppDir 的目录结构是这样的：
1 |
|
要将 AppDir 打包成可执行文件，需要用到的工具是 appimagetool，可以到appimagetool AppDir 便可将 AppDir 打包成一个AppImage。运行它
1 |
|
因为它打包了程序所需的所有依赖，所以理论上它可以在任意一个同架构（这里是X86_64）的 Linux 系统上运行，无论这个系统的 libc版本是多少。你也可以修改这个程序，让它引用一些较新的 libc里才有的函数（如 gettid, glibc 2.30 被加入），打包成AppImage 后再发给一个老系统（如 CentOS 7），看看它能不能正常运行。
上面例子中的程序很简单，只依赖一个libc。而实际情况下程序通常依赖很多共享库，这些共享库有可能又依赖更多其它的共享库。手动找出来非常麻烦，我们可以使用工具。appimage-builder就是一个很方便的工具。它的原理是运行目标程序，分析它访问了哪些共享库；然后使用包管理器（如apt）获取依赖，并制作成 AppDir。此外它还提供了一个功能强大的AppRun，支持路径映射，通过 hook 程序的文件访问函数，将指定路径映射到AppDir 中。
appimage-builder 是一个 Python 工具，可以使用 pip 安装：
1 |
|
要用 appimage-builder 制作 AppImage，我们首先需要准备一个“基础版”的AppDir，包含软件的可执行文件和一些相关依赖。通常那些make install 复制到 /usr/local/下的文件就是基础 AppDir 应当包含的文件。上面例子的基础 AppDir结构如下:
1 |
|
appimage-builder 基于一个 yaml 配置文件制作 AppImage，称为recipe。我们不必手动创建 recipe，可以用appimage-builder --generate命令生成，然后再根据需要修改。generate命令是一个向导程序，会询问这个应用的基本信息。
1 |
|
接着 appimage-builder 会用 strace运行目标程序，分析它打开了哪些共享库文件；然后用包管理工具分析共享库属于哪个软件包。结束后就会生成recipe 文件 AppImageBuilder.yml。它的结构如下：
1 |
|
我们通常需要关注这些配置：
AppDir.apt 软件包相关信息，由 generate命令探测出，通常不用自行修改。include为要用到的软件包，sources 是这些软件包相关的软件源。AppDir.files 控制要包含哪些文件。支持使用 * 和 ** 通配符）匹配文件路径。include 为需要包含到 AppDir的文件的绝对路径列表，这些文件会被复制到 AppDir 中的对应位置。例如/usr/bin/bash 对应 $APPDIR/usr/bin/bash。exclude 则为需要在 AppDir中排除的文件路径列表，路径相对于 AppDir。AppDir.test 为测试环境。appimage-builder会拉取其中指定的 Docker 镜像，并在其中测试 AppDir。除这些自动生成的配置外，还有很实用的运行时配置。
1 |
|
env 指定运行时的环境变量。appimage-builder 自带的AppRun 程序还支持一些特殊的环境变量APPDIR_EXEC_ARGS 程序的命令行参数，默认为$@，即原样透传传给 AppRun 的参数。APPDIR_LIBRARY_PATH 共享库搜索路径，效果等同于LD_LIBRARY_PATH。path_mappings 设置路径映射。支持将一个绝对路径映射到AppDir 中的路径，格式为 源路径:目标路径。例如/bin/bash:$APPDIR/bin/bash，每当程序访问/bin/bash 都会实际访问 AppDir 中的bin/bash。准备好 recipe 文件后执行appimage-builder --recipe AppImageBuilder.yml 即可生成AppImage。也可以加上 --skip-tests 跳过测试。
ccls 是一个 C++ 的 language server。我想在公司的开发环境用上ccls，但是 ccls依赖的工具链和运行时环境都比较新，无法直接在公司的开发环境上编译、运行。因此我准备在Ubuntu 20.04 下编译 ccls 并制作成AppImage，让这个老系统也能用上新软件。
执行如下命令构建 ccls:
1 |
|
这样我们就有了基础 AppDir:
1 |
|
接着我们执行 appimage-builder --generate 生成recipe:
1 |
|
根据 ccls 的文档（和我的测试结果），ccls 运行时要访问 clang 的 lib目录。我的 clang 是用 apt 安装的，路径在/usr/lib/llvm-10/lib/clang/10.0.0。我们需要把这个路径打包进AppDir，并且将其映射到 AppDir 内。我们修改AppImageBuilder.yml:
1 |
|
然后我们还要创建个图标。虽然是命令行程序，但是 AppImage要求每个应用都要有个图标，所以没办法。这里我们就 touch一个空文件就好：
1 |
|
最后执行 appimage-builder --recipe AppImageBuilder.yml生成 AppImage。大功告成！
1 |
|
Linux的软件管理方式虽然节省了磁盘和内存空间，但是也增加了软件安装的难度。导致Linux的软件要么进入发行版使用包管理器安装；要么发布源码，编译安装。前者虽然安装方便，但是版本受限，不能随意升级；后者需要准备开发环境，安装较为麻烦。当编译依赖的工具链不满足要求时，软件安装会变得很棘手。
针对这个问题，Linux 有几种解决方案，例如 snap、容器，以及本文介绍的AppImage等。它们的解决思路其实差不多，都是将软件与其依赖一起打成包发布。它们各有优劣，对于AppImage 来说，优点就是使用方便，用户不需要安装任何环境，下载 AppImage即可执行；缺点是依赖于 AppRun 的前序处理，兼容性可能不如 snap和容器。个人感觉 Linux 桌面系统要想推广，软件安装还是要走 Windows 和macOS 这种形态，即打包软件依赖，降低安装门槛，提高兼容性。
参考资料：
2024-01-01 00:00:00
In 2023 I spent most of my time on work, learning
Let’s talk a little about professional skills over here. In the past,I focused most of my efforts on coding skill, rather than engineeringskills, or let’s say, the business skills. This is because I love thehacker spirit, and am fascinated by intricate program structures andalgorithms. But your boss just need one who solve problems, them don’tcare about computer science. To solve a problem, you have to considermany things other than the computer - namely, the people around you. Andthat’s exactly what software engineering does - to use some engineeringmethods to prevent or eliminate mistakes made by humans. So when I focuson hacking, I must keep an open mind on other skills, especially thosemethodologies for problem-solving.
I finished learning Structure and Interpretation of ComputerPrograms (SICP), an amazing book. Its content comprised offunctional programming, layering of program and data structure, OOP,infinite streams, the metacircular evaluator, lazy evaluation,compilation principle, etc. I have to say, SICP opened the gateof computer science for me. Before then, I don’t really comprehend theessential of computer science.
I kept on doing LeetCode like the past few years. The grid looks notbad.
Now I’ve solved 1182 problems. Last year it’s 912, so I solved 270problems in 2023.
I kept learning English in 2023, as I did in the past few years.After continuously learning vocabulary on the APP baicizhan for2024 days, I found it might not be a very effective way to memorize newwords for me at the moment. Therefore, In November, I started learningMerriam-Webster’s Vocabulary Builder. This book organizes wordsby their roots, besides telling you how to use a word, its history, andrelated knowledge.
I also read another amazing vocabulary builder, Word Power MadeEasy. To me, this book like an introduction to the etymology and atthe same time teaches you how to memorize over 3,000 words and continuebuilding your vocabulary.
In addition, I kept leaning Japanese on Duolingo as I did in2022.
I only wrote 6 posts on the blog.
I created a repo
Hiking and seeing the skyline of the city at the summit is quitehappy, especially with the one you love.
At the end of a year, I always feel time flies by quickly. But afterI wrote the annual review, I found that the time of a year is quitelong, because you can literally do many things in a year and grow quitea bit in certain aspects (say, I found my English writing skill is muchbetter than the last year). So in the new year, keep learning andgrowing, and I believe we’ll get a better result. Happy New Year toeverybody.
