服务器上面不能科学上网。以前都是直接 用 ssh 做代理转发 的，但是现在在校外只能使用 rvpn，连接非常不稳定，也无法大流量传输文件，只能考虑在服务器上直接上网。
平时使用 Windows 上的 v2rayN 上网，考虑将其配置迁移到服务器上。由于服务器是多人共享，我有以下需求：
bin\srss 中包含大量 geo* 文件。将 srss 文件夹拷贝到服务器上的 sing-box 文件夹中。这一步下载了 sing-box 并且将一些公开配置复制到了服务器上。
一些在 Notion 上分享的内容现在可以从侧边栏的“发现”标签打开，这些内容比博客本身编辑起来更方便（指📱编辑），所以我也能更加频繁地创作。它们通常为较短的内容，可以当作周报来看！
本文是 实验室服务器 ssh 无法连接 的后续。
今天同学又告诉我发生了类似的情况，师兄已经在找人维修。
我连接上去看了服务器重启时间约 10 点。又看了几个信息：
sar 监控journalctl 日志sar 监控
之前设置的 sar 监控频率是默认的，即 10 分钟采样一次。sar 怎么安装和配置可以参考
安装 sysstat 获取 CPU/ 磁盘 / 网络统计日志。
今天发现很有意思的一件事情：配备 4090 显卡的服务器上安装 torch 之后，显示的架构并没有 sm_89，也没有 PTX（compute_xx）来支持 JIT。
(minimind) ➜ ~ python -c 'import torch;print(torch.cuda.get_arch_list())'
['sm_50', 'sm_60', 'sm_70', 'sm_75', 'sm_80', 'sm_86', 'sm_90']
(minimind) ➜ ~
sm_89 not listed in the torch.cuda.get_arch_list() - PyTorch Forums 这个讨论说明 sm_89 和 sm_86 是完全兼容的，除了 FP8 支持，这些 kernels 被专门处理。
首先，创建一个 docker 容器，其 entrypoint 不是可回收子进程（init-like）的命令，也不要加上 --init 选项。这样即便僵尸被 init 进程收养，也不会被马上回收，方便观察。
在容器内部进行以下操作：
// parent.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
int main() {
pid_t pid = fork();
if (pid < 0) {
perror("fork failed");
exit(1);
}
if (pid == 0) {
// 子进程
printf("Child process (PID: %d) exiting immediately.\n", getpid());
exit(0); // 快速退出，变成僵尸
} else {
// 父进程
printf("Parent process (PID: %d), child PID: %d\n", getpid(), pid);
printf("Sleeping 60 seconds without wait() to create zombie...\n");
sleep(60); // 不调用 wait()，让子进程变成僵尸
printf("Parent exiting.\n");
}
return 0;
}
编译运行，然后在另外一个窗口将父进程 kill 掉。
root@677e804cc08c:/workspace/zombie# gcc -o parent parent.c
root@677e804cc08c:/workspace/zombie# ./parent
Parent process (PID: 308506), child PID: 308507
Sleeping 60 seconds without wait() to create zombie...
Child process (PID: 308507) exiting immediately.
Terminated
TL;DR：大多是具体脚本的问题，不好处理。有的是没有及时 gc，有的是把所有数据全部载入内存之后（假设了内存足够大）才开始处理。
我是遇到了这样一个问题： megatron-lm huggingface 教程运行时资源占用大、有僵尸（2025/4/22 文章还在修改中，尚未公开）。
o4-mini 建议我调整启动方式：multiprocessing — Process-based parallelism — Python 3.13.3 documentation
| 方法 | 描述 | 特征 |
|---|---|---|
| spawn | 创建新的解释器并运行，干净但慢，是 Windows、macOS 的默认方法。 | 大量 python -c from multiprocessing.spawn import spawn_main; 进程 |
| fork | 直接 fork。除了 macOS 之外的 POSIX 的默认方法，Python 3.14 之后默认方法改成 forkserver。 | 大量命令参数（cmd）和启动命令相同的进程，例子 python tools/preprocess_data.py --input ... |
| forkserver | 首次用 forkserver 方法创建进程会启动一个单线程（除非 import 的库导致了多线程）的 server，每次调用 os.fork() 都是干净的，不会有冗余线程。 | 大量 python -c from multiprocessing.forkserver import ... 进程 |
Windows Terminal 的问题，换成 Alacritty 就好了。
不过 Alacritty 又有别的问题，在 vim 中粘贴文本的时候 \r\n 会被转换成 \n\n，导致换行数量加倍，每两行中间会多出来一个空行。参考 WSL + ConPTY + vim -> paste with blanks lines · Issue #2324 · alacritty/alacritty 在 vim 中 ：set term=ansi 可以工作。
今天在尝试 Microsoft Copilot 和 Windsurf。
参考 https://linux.do/t/topic/480869/ ，解读大模型官网和 IDE 的各种额度限制。里面提到了 Microsoft Copilot 使用了 GPT-4o 和 GPT-o3 mini，之前对 Microsoft Copilot 的感受是比较负面的，看到这个新消息后我也查找了对应的资料（有一说一，Microsoft Copilot 查资料还不如 Grok 做的好）：
Table: Summary of Models and Their Uses（来自 Grok3）
| Model | Primary Use | Confirmed By |
|---|---|---|
| GPT-4o | Standard chat functionality | |
| o3-mini high | Think Deeper feature for complex queries | Microsoft Copilot blog release notes, March 19, 2025 (Microsoft Copilot Blog: Release Notes - March 19, 2025) |
最后的感觉是，Microsoft Copilot 的模型其实是不如 ChatGPT 官网的，感觉会笨一点。Mircosoft Copilot 早期响应慢的情况现在也好了很多（不会是因为现在是白天吧）。智力在一众模型中算是垫底的，做点指令遵循任务还行。
从 Windows 的资源管理器拖动文件到连接到远程服务器的 VS Code 窗口，或者从 VS Code 文件目录下载文件，速度都比 scp 慢得多（3M/s VS 20M/s）。此文章尝试寻求其他替代方案。
参考 Remote Development Tips and Tricks，在 Linux/macOS 上面比较方便。
rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" .
在 Windows 上面比较麻烦，VS Code 给出的教程是：
wsl rsync -rlptzv --progress --delete --exclude=.git "user@hostname:/remote/source/code/path" "`$(wslpath -a '$PWD')"