依云's Blog

缘起

我就是买了个4K显示器，咋这么多事呢……（有两篇文章还在路上）

第一个问题是，我的显卡 vGPU 最高只支持 1920x1200 的分辨率。行吧，我缩放成了吧？嘿嘿，-display gtk 的缩放不会保持比例，我只好算了算最大保持比例的大小，然后窗口切成浮动，再调用命令调整到指定的大小：

sleep 1 && xdotool getactivewindow windowsize 3280 2122

然后还要居中放置一下。多麻烦！

第二个问题是，我想在虚拟机里试试 i3，但是我的按键总是会被外边捕获。Super 键基本上是 Awesome 在用，而 Alt 键会撞上这个 GTK 窗口菜单栏的快捷键。

配置

经过多番尝试和摸索之后，确定了如下的参数：

  -display egl-headless,gl=on,rendernode=/dev/dri/renderD128
  -spice unix,addr=/run/user/1000/qemu/ArchKDE/spice.sock,disable-ticketing
  -device virtio-serial-pci
  -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0
  -chardev spicevmc,id=spicechannel0,name=vdagent

当然要gl=on啦，不然我怎么玩特效，我还不如回到 vbox 去呢（啊不，我的 vbox 不喜欢 btrfs，经常出错然后只读挂载，所以已经被删掉了）。要指定rendernode，不然它会 fallback 到 llvmpipe，然后还段错误崩掉……这也是我不-display spice-app的原因。

后边三行是从这个 QEMU + Spice with Copy & Paste 抄来的。搜索问题时不小心遇见，然后解决了这个我一直没有处理的问题。SPICE 不但能共享剪贴板，而且还支持 PRIMARY 选择区呢～虚拟机里要安装 spice-vdagent 并启动相应的服务。

然后是客户端的选择。一个很神奇的地方是，virt-viewer 看上去轻量，实际上只是选项少而已。它不光拖进来个 gtk-vnc 依赖，还把 libvirt 都给我带上了……然后 GNOME 的 vinagre，我不知道为啥，它就是连不上我的 spice+unix 地址。哦对了，virt-viewer 直接敲命令调用也是连不上，只能用 xdg-open 才能正常打开。

virt-viewer 有个依赖叫 spice-gtk。我试着 pacman -Ql 了一下，还真找到个 spicy 工具。比 virt-viewer 轻量多了，选项也更为丰富，比如可以选择不 grab 键盘。

一点额外的东西

在群里听说了 virtio-fs 共享方案，听说比 virtio + 9p 更高效。然后我用它成功取代了之前用的 NFS 方案（反正我的 vbox 虚拟机已经被删掉啦）。NFS 的服务也可以卸载啦（开放一堆端口到公网，看着有点怕怕的，虽然是 IPv6 地址不太会被扫到，但知道我的地址的咋办呢）。

virtio-fs 相比 virtio + 9p 的另一个优点是，和 NFS 一样，virtiofsd 是以 root 权限运行的，所以可以写入我的 pacman 缓存。qemu 那个 9p 似乎没有办法。至于启动嘛，用 systemd abstract socket 触发一下就好了。

另外，我使用 GVT-g 和 virtio 输出视频信号时，均遇到了声音在视频画面变化时声音卡顿的情况。一个绕过的办法是，通过设置 PULSE_SERVER 环境变量以及加载 module-native-protocol-tcp 模块，将音频信号直接通过网络发送到宿主机上，一点也不卡！

Arch Linux 就是要追新！要追新自然要选择一个更新及时的软件仓库镜像啦，比如国内的 TUNA、USTC 同步都很及时。但是呢，这俩难兄难弟最近一段时间有些吃不消了，导致下载包的时候很慢，甚至超时失败，使用体验真糟糕。如果直接用上游镜像，比如 pkgbuild.com，漂洋过海的，也挺慢的。

而国内另一些镜像，比如网易、腾讯云、阿里云、华为云，他们要么有 CDN，要么线路很好，下载速度飞快。但是呢，他们基本上每天才同步一次，阿里云还时不时连续数天都没能同步成功，这让喜欢追新的 Arch Linux 用户多不舒服呀。当群里的小伙伴们都用上了最新版本的软件，体会到了让人心痒痒的新特性和 bug 时，你 -Syu 却是「今日无事可做」，真是扫兴呢。

和最新的镜像同步，从最快的镜像下载，真的不可兼得吗？

非也。只需要稍微配置一下，用上我的 pacsync 脚本，就可以啦～

配置方式是，为 /etc/pacman.d 下的镜像列表文件创建一个.sync后缀的同名文件，里边指定用于同步的镜像，而不带.sync后缀的文件里按优先级列出多个镜像。pacman 在下载文件时，会按顺序依次尝试列出的镜像，如果遇到更新不及时 404 的时候，就会尝试另一个。这样，可以仅在下载快的镜像里还没有需要的包文件时，才转而从比较慢的镜像下载。

而需要同步 pacman 数据库的时候，使用pacsync脚本取代pacman -Sy。脚本会使用 bind mount 用.sync文件取代不.sync的版本，就能同步到最新的数据库了。原来的pacman -Syu命令要拆开来用，先pacsync再pacman -Su了。

脚本里使用了单独的挂载空间并且将挂载改为了私有，所以并不会影响到外边。

一次系统升级之后，我的许多 Python 程序突然开始报错：

[...]
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2762, in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1415, in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1405, in get_metadata
    value = self._get(path)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1609, in _get
    with open(path, 'rb') as stream:
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO'

WTF 滚坏了！立即回滚！

回滚完之后，我开始调查这个事件——因为 [archlinuxcn] 的这个包是我管的呀。而且我记得之前也遇到过一次类似的情况，当时没有深究。

检查一下软件包里的文件的权限：

>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep PKG-INFO
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
>>> tar tvf python-telethon-1.17.4-1-any.pkg.tar.zst | grep -- ----
-rw------- root/root      3659 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/PKG-INFO
-rw------- root/root     12078 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/SOURCES.txt
-rw------- root/root         1 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/dependency_links.txt
-rw------- root/root        27 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/requires.txt
-rw------- root/root        15 2020-10-24 10:05 usr/lib/python3.8/site-packages/Telethon-1.17.4-py3.8.egg-info/top_level.txt

好奇怪，Telethon 这些包信息文件怎么只让 root 读了呢？

从 PyPI 上下载 Telethon 的原始 tar 归档回来看看，发现最近几个版本里，文件权限全部只有自己可以读（-rw-------），而所有者是 u0_a167/10167。开发者突然在 Android 系统上打包了呢……安装的时候，部分文件的权限被保留了下来（Arch Linux 打包时强烈反对使用 root 权限执行，因此我用 devtools 打包，解包部分自然是普通用户操作的，所有者无法被保留）。

然后我又看了一下之前的版本，哦豁，所有者成开发者的 id 了，但是有三个版本的 pyc 文件，还有好几个 pyc 文件都是 -rwxrwxrwx。大概系统上的低权限用户可以去改改，然后看谁跑 Telegram 机器人就拿谁的权限？

经过跟开发者的讨论，最终干掉了 pyc 文件，也不在 Android 上打包了。777 权限问题还待解决。不过我更在意的是，为什么会发生这种状况呢？setuptools 干嘛不修一修呢？别的工具创建的用于发布的 tar 归档会不会有类似的问题呢？

结果找了找，发现 setuptools 前年就有人报告这个问题，但是并没有解决。行吧，我打包时统一修正一下权限好了……

下一个 GitHub 生成的 tar 归档看看？咦，-rw-rw-r-- root/root，是处理过了么？啊对，git archive 生成的包是怎么样的？去试了试，原来一样的啊。看来 git 想到了这个问题并且处理了，只是 002 的 umask 有点意外。

Arch Linux 为了普通用户打出文件为 root 所有的 tar 归档使用了 fakeroot，那么 git 是怎么实现的呢？翻了翻代码，git 是自己生成 tar 文件的，写死了所有者是 root/root，但是权限位还是有专门的 umask，默认是 002。可以配置，比如git config --global tar.umask user一下，就会取当前 umask 作为 tar 归档里文件的 umask 了。

至于传统的 GNU autotools 构建系统创建的 tar 归档，我也创建了一个看了一下，并没有特殊处理，跟手动跑 tar 一样。

序

最近，Arch Linux 的 pam 包将更新到 1.4.0，然后因为一个字符的变化，不少中文用户都开始避难了：pam_env 将默认不读取用户的环境变量设置。许多中文用户使用~/.pam_environment文件来配置 fcitx 输入法所需要的那三个环境变量。更新之后，这些配置将不再生效，意味着他们可能无法输入中文了，于是大家热烈讨论现在要在哪里配置环境变量比较好。

当然了，在 pam 的配置文件里加上user_readenv=1就可以恢复原先的行为。只是，pam 的开发者这么改当然是有原因的：CVE-2010-4708。简单地说，就是在鉴权模块里设置用户指定的环境变量不安全，怕被提权。

2020年08月20日更新：Arch Linux 打包时添加了以上这个配置。

当然啦，桌面用户完全可以去改系统级的环境变量设置，只要你愿意让你个人的配置信息跑到系统配置那边去的话。

正文

用户经常需要设置一些环境变量，比如输入法，比如语言和地区选项，比如自定义的 PATH，等等。然而 Linux 的环境变量又不像 Windows 那样有一个专门设置所谓「系统环境变量」的地方，而是所有环境变量全部由子进程继承父进程获得，这么一路继承下来的。于是，想要给所有想设置上的进程都设置上，就不是一件简单的事情了。

这里关注的是桌面用户，自然首先从图形界面说起。

使用 X11 的桌面环境，通常通过 display manager 来登录，比如 lightdm 和 sddm。这俩都支持 ~/.xprofile。这个文件会在启动过程中被 source，使用的 shell 是由 dm 自己确定的。lightdm 和 sddm 都是用的 /bin/sh（分别位于 /etc/lightdm/Xsession 和 /usr/share/sddm/scripts/Xsession 文件里）。可以看到，除了读取 .xprofile 外，lightdm 也会读取 .profile。sddm 甚至连 bash、zsh、tcsh、fish 的启动配置脚本都给读了。

对于 Wayland，我这儿只有 sddm，类似的，也是各种 shell 的都给你读了。（当然就不读 X11 相关的东西了。）

而对于手动 startx 的用户，~/.xinitrc 里自己写上呗。还有 VNC 啥的，也都可以自己看启动脚本找到方法。

没有图形界面的登录，通常是从 tty 或者 ssh 登录。这两者都是登录到命令行 shell。写在 shell 配置里就可以了。具体到 zsh，我是写到 ~/.zprofile，这样不管是否交互，只要是登录 shell 就执行，不登录的大概已经继承到了。另外有些情况可能写这儿也没有用，比如 cron 调用的时候。非要搞的话其实可以写到 ~/.zshenv，这个基本上所有的 zsh 都会读，只能被系统级设置或者命令行参数禁用掉。而如果是 bash 用户，.bash_profile .bash_login .profile 这仨，会读找到的第一个（sddm 也会按这个顺序找，但是 lightdm 只会找 .profile）。Arch Linux 现在默认会给新用户建立 .bash_profile，我建议 bash 用户把它改名成 .profile。这里有个图 ，大致上说明了 bash 和 zsh 不同情况下会读取的配置文件。

systemd 用户实例也有一份环境变量，用于通过 systemd 启动的用户级服务，通过 systemctl --user 的子命令可以查看和更新。D-Bus 也有一份，可以通过 dbus-update-activation-environment 命令来更新。这俩通常不需要用户操心，桌面环境应该会维护好。

如果你用 tmux 的话，那么 tmux 还有一份，用于新创建的窗格。tmux 会在被连接时更新 update-environment 选项指定的环境变量。当然你也可以用 tmux setenv 子命令去更新。这个尤其值得注意，因为 tmux 可能在不同的环境中被连接，导致环境变量混乱（比如 X11 下没有 DISPLAY 变量）。

要注意的一点是，不同的登录过程并不是只会读取自己专属的配置文件，尽管大家都在努力，也并没有完全统一好用的配置文件。所以有些环境变量，你可能想尽量避免重复设置（比如冗长重复的 PATH 项就很讨厌）。好在这些都是 shell 脚本，不光能设置环境变量，也能做条件判断。

要查看当前进程的环境变量，可以用 env 命令。要查看别的进程的，去读它的 /proc/PID/environ 文件，或者开个 htop 然后在进程上按 e 键。要看看某个环境变量在不同进程里是什么情况，可以用我写的小工具 compare-env。

跋

Linux 软件生态的特点就是这样，没有谁规定一定要用怎样的方式做一件事情，所以大家的想法总会有些出入，就导致设置个环境变量还有这么一大群配置文件（systemd 还有一份呢，我还没读没试所以没说）。但另一方面，理解它们也是十分容易的：不用猜测，不用撞大运般地耗费时间去尝试，顺着代码摸过去，总能弄明白软件的行事逻辑。即使文档像 pam_env 那样前后矛盾，也有源代码这条路可以精确刻画软件的行为。

序

终端转义序列里有一个 SGR 代码用于表示「粗体或者增加强度」的字体渲染。相当多的终端将其实现作更明亮的颜色而非粗体字，也有很多终端应用程序如此（比如 mutt 中的 brightXXX 颜色使用此代码；新一点的 mutt 支持使用 lightXXX 来表示亮色了）。

然而最近，GNOME 终端决定将这个「或」字去掉，让 SGR 代码 1 表示粗体，亮色使用另外的颜色代码来表示。这无疑导致了我看到的许多软件里出现粗体字。有时候看着还行（比如 systemd、htop 中的），有时候会让人觉得很不舒服（比如 zsh 里打着命令，字体一会儿变粗一会儿变普通粗细）。我就认真去查了一下相关信息，作出相应的配置更改，顺便做个总结笔记好了。

转义序列

「选择图形展现」（Select Graphic Rendition; SGR）序列用于设置字体的渲染方式。其格式为CSI (code ";")* code m。CSI 就是 ESC "["。一个序列里可以给出多个代码，使用分号分隔。如果一个都不给出，当作代码 0 解释。

八色

这是最基础的八种颜色，代码 30-37 设置前景色，40-47 设置背景色。

16色

这就是大多数终端设置里，那个14色的调色板所指定的色彩了。为什么只有14色呢？因为默认的前景色和背景色是单独的设置项。

如序言中所说，相当多的终端将代码 1 解释为亮色，也就是上述八色再加上对应的明亮版本。

自 GNOME 终端此次改革之后，代码 1 只管粗体。要亮色，使用代码 90-97 设置前景色，100-107 设置背景色。除了 GNOME 终端外，也有一些其它终端跟进，比如 alacritty。有些终端保留了将代码 1 解释为亮色的选项，而 GNOME 终端最近去掉了这个选项（但是还有一个将粗体字显示为亮色的选项）。

256色

16色怎么够？于是出现了256色。

ESC[38;5;<n>m用于设置前景色，ESC[48;5;<n>m用于设置背景色。其中，n 是一个数，0-7 同代码 30-37，是那最初八种颜色。8-15 是它们的亮色变种。16-231 是216种彩色，在RGB空间构成了一个6x6x6的立方体。232-255 是24个灰阶色彩。

一些标准中，这中间的分隔符使用冒号。

真彩色

现代显示器普遍使用8位值表示RGB中每一个通道、共计24位了，终端也不能落后呀。于是有些终端也支持了这个被称为「真彩色」的24位色彩了。

代码格式是256色的扩充。ESC[38;2;<r>;<g>;<b>m来设置前景色，ESC[48;2;<r>;<g>;<b>m设置背景色。这里的 r、g、b 当然就是RGB色彩空间的值了，每一项的取值范围是 0-255。

测试脚本

整合了我从各处收集到的展示方式，写了一个脚本，可以直观地感受终端对各种色彩的支持情况：

colors.py

参考资料

• command line - How can I fix the dull colors I am getting in Ubuntu 19.04 Terminal? - Ask Ubuntu
• ANSI escape code § Colors - Wikipedia
• True Colour (16 million colours) support in various terminal applications and terminals

假设有一个程序叫 use-cpu，它运行的时候会一直消耗一个 CPU 核心。试问，如果我开两个终端窗口，分别执行以下两个进程，其 CPU 会如何分配？

$ taskset 2 ./use-cpu
$ taskset 2 nice -n 10 ./use-cpu

两个进程都在1号CPU上运行，意味着它们必定争抢时间片。第二个进程使用 nice 命令设置其 nice 为 10，那么，是不是第二个进程会占用比较少的 CPU 呢？

很合情合理的推理，然而答案是否定的。

呃，也不一定。cat /proc/sys/kernel/sched_autogroup_enabled 看一下，这个开了的话，CPU 调度会多一个层级。默认是开的，所以这两个进程会均分 CPU 时间。

首先说好了呀，这里只讨论普通进程（SCHED_OTHER）的调度。实时进程啥的不考虑。当然啦，CPU 分配只发生在 R（Runnable）状态的进程之间，暂时用不到 CPU 的进程不管。

最上面的层级是 cgroups 了。按照 cgroup 层级，每一层的子组或者进程间按权重分配。对于 cgroups v1，权重文件是 cpu.shares；cgroups v2 则是 cpu.weight。不管用哪个版本的 cgroups，systemd 默认都没有做特别的设置的。对于 v1，大家全在根组里；对于 v2，CPU 控制器都没有启用。如果你去设置 systemd 单元的 CPUWeight 属性（或者旧的 CPUShares 属性），那么 systemd 就会开始用 cgroups 来分配 CPU 了。一个意外的状况是，使用 cgroups v2 时，systemd-run 不会自动启用上层组的 CPU 控制器，以至于如果上层未手动启用的话，设置不起作用。在使用 cgroups v1 时，用 systemd 设置 CPUWeight 或者 CPUShares 也不太好用，因为它并不会自动把进程挪到相应的层级里去……

其次就是这个默认会开的 autogroup。这个特性是为了提升交互式的桌面系统的性能而引入的，会把同一 session 的进程放一个组里。每个 autogroup 作为一个整体进行调度，每个 autogroup 也有个 nice 值，在 /proc/PID/autogroup 里可以看到，也可以 echo 一个想要的 nice 值进去。至于这个 session，不是 systemd 的那个 session，而是传统 UNIX 的那个 session，也是 setsid(2) 的那个 session。我一直以为它没多大作用，没想到在这里用上了。基本上，同一群进程会在同一个 session 里（比如一群火狐进程，或者一群 make 进程），同一个终端里跑的进程也都在一个 session 里（除非你 setsid 了）。

最后才是轮到进程。其实准确地讲是线程。同一个 autogroup 里的时间片如何分配，就看里边这些线程的 nice 值的大小了。所以其实，我系统里的那些高 nice 值的进程，由于 autogroup 的存在而它们又没有去设置 autogroup 的 nice 值，其实调度起来没什么差别的。

参考资料

• man 7 sched
• man 7 cgroups

准备 GVT-g

把 kvmgt vfio-iommu-type1 vfio-mdev 这仨加到 /etc/mkinitcpio.conf 的 MODULES 数组里去。mkinitcpio -P 重新生成一下 initramfs。

添加内核参数 i915.enable_gvt=1。比如是 grub 引导就去改 /etc/default/grub 里的 GRUB_CMDLINE_LINUX 变量，然后 grub-mkconfig ...。

去把 /etc/systemd/system.conf 里的 DefaultLimitMEMLOCK 给改了。比如 DefaultLimitMEMLOCK=65536:1073741824。

重启。

这个时候应该已经有 /sys/devices/pciXXXX:XX/XXXX:XXXX.X/mdev_supported_types 这个目录了。里边有好几个选项呢。选择一下合适的（查看 description 文件），然后往里边的 create 文件里写一个 UUID 就创建了。

启动 KVM 虚拟机

呃，如果你还没有磁盘镜像就自己 qemu-img 创建一个，然后装机。如果你有别的虚拟机的，也可以用 qemu-img 去转格式。

另外准备一下网络。我早就有个网桥了，所以直接用它了。在 /etc/qemu/bridge.conf 里写一句 allow br0 不然不给用的，毕竟我是普通用户权限而网络接口是要 root 权限操作的，得明确允许一下。

我尽可能地使用了 virtio，据说性能好（VirtualBox 也支持一部分了呢）。如果用已有的虚拟机系统但以前没用过 virtio 的话，记得用 fallback 那个 initramfs 启动，然后进系统之后重新生成一个。

我给分配了四个逻辑 CPU 核，4G 内存。VGA 要关掉，不然两个显卡用起来麻烦。为了避免部分内容显示到别处去（如果关了 VGA 的话就看不到，否则能在默认的那个上看到），要加上 ramfb=on,driver=vfio-pci-nohotplug 选项。

声音当然是要的。添加个 PulseAudio 后端，一张 HDA 声卡。我不懂声卡型号所以找了个顺眼的，能用就好。

合起来是这样子的（那两个省略号，一个是磁盘镜像路径，一个是创建 vGPU 用的 UUID）：

#!/bin/bash -e

ulimit -l 1024000

exec qemu-system-x86_64 -enable-kvm \
       -name "ArchKDE" \
       -cpu host -smp 4 \
       -m 4G \
       -drive file=/.../ArchLinuxKDE.qcow2,if=virtio \
       -netdev bridge,id=eth0,br=br0 \
       -device virtio-net,netdev=eth0 \
       -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/...,display=on,x-igd-opregion=on,ramfb=on,driver=vfio-pci-nohotplug \
       -vga none \
       -display gtk,gl=on \
       -audiodev pa,id=pa0,server=/run/user/$UID/pulse/native -device intel-hda -device hda-output,audiodev=pa0 \
       "$@"

如果你使用 GVT-g 显卡的时候整个系统都卡卡卡的话，去看一下宿主的内核日志，是不是有 vfio_pin_page_external: Task qemu-system-x86 (257364) RLIMIT_MEMLOCK (104857600) exceeded 这样的提示，然后去把 RLIMIT_MEMLOCK 给调大，大到它不再报这个错为止。我最后给了1000M才终于不报错地把 KDE 给跑起来了（默认是64K）。

当然如果你没有 GVT-g 支持的话，去掉那行配置，然后 -vga virtio 也能用。

参考链接

• ArchWiki: Intel GVT-g
• [GUIDE] Running Windows via QEMU/KVM and Intel GVT-g on Arch Linux : VFIO

Python 3.8 发布有好多天了，Arch Linux 也早就重新打包了一千多个包（感谢辛勤的肥猫猫），隔天就从 [staging] 进入 [testing] 了，四天之后进入正式仓库（[extra] 和 [community]）。

Python 3.8 进入官方仓库的次日，我本地进行了更新。之所以要等一天，自然是等 [archlinuxcn] 的更新啦。然后那些需要人工干预而又暂时没人理的我本地重新打包了。使用 pacman -Qo /usr/lib/python3.7/site-packages 查询尚未更新的软件包，然后对着对应的 PKGBUILD 一顿改（基本上也就是 pkgrel 加 0.1 而已），makepkg -si 就好了。

但是这样还没完事哦。

先 sudo updatedb 更新一下 mlocate 的数据库。然后 locate -be python3.7 | grep -v /var/lib/lxc 找到一些残留的文件，主要是 ~/.local/lib 下的，以及散落在管理之外的 venv 里的。~/.local/lib 下的都是我自己的项目，删掉然后重新去项目里 python setup.py develop --user 就好了。venv 的话，直接删掉吧……

然后是 locate -be python-37 | grep -v /var/lib/lxc | grep -v /usr/lib/python3.7/site-packages。这个是为了查 Python 3.7 的 pyc 文件，所以这次也排除了 Python 3.7 的 site-packages，避免尚未更新的 Python 包的干扰（有些暂时用不到的包我就懒得自己 makepkg 了），等更新完之后整个目录删掉。有些软件包（比如 gdb-common）没有使用标准的 Python 安装流程（比如因为并不是标准的 Python 库），打包者（比如著名的 Allan McRae）没有或者拒绝在打包时编译 pyc 文件，造成 Python 自行创建不被管理的 pyc 文件，软件包卸载或者 Python 升级后就残留下来了。

确认没有问题之后（比如有些软件可能自带了个旧版本的 Python，或者有些并不是 pyc 的文件也包含这个字符串），执行 locate -be python-37 | grep -v /var/lib/lxc | grep -v /usr/lib/python3.7/site-packages | sudo xargs rm -v 删除这些文件。当然如果有需要保留的文件自行从文件列表中删掉先。

pyc 清理之后，接下来清理一下空的 __pycache__ 目录啦。locate -be __pycache__ | sudo xargs rmdir -v 2>/dev/null 就可以了，非空目录不会被删掉的。

哦对了，我现在在用 mypy 了，所以还要 locate -we .mypy_cache/3.7 一下。

我之所以现在记录这事儿，「现在」的原因是，我要在另一个系统上再测试一遍再发布出来，「记录」的原因是，下一次我就不用想要执行哪些命令了。

这是由 NVIDIA 官方提供的新的双显卡配置方案（官方文档），需要最新的驱动及 Xorg 支持。其中 nvidia 驱动已经位于 Arch Linux 官方仓库中（版本号 435.21）。相关 Xorg 补丁还在 git 上，并没有新版本放出，所以需要自行编译包含补丁的版本。这里有现成的 PKGBUILD。我打包好的版本也提供下载。

2019年11月25日更新：xorg-server 1.20.6 已经进入 Arch Linux 官方仓库，包含需要的补丁了。

2020年02月14日更新：现在也可以通过安装 nvidia-prime 直接配置好，就不用搞下边那些配置了。记得安装 nvidia（或者 nvidia-dkms 等）驱动包哦～

我的硬件是 ThinkPad T470p，Intel Corporation HD Graphics 630 核显和 GeForce 940MX 独显。核显的特点是：省电、支持视频编解码加速。独显的特点是：Minecraft 能开光影，FPS 也要高一点。用来跑火狐的话可以正确渲染 FishGL。

配置方法如下。

首先把 bbswitch 啥的都卸载了吧。虽然注意点不卸载也没事，但是毕竟装着没意义还容易出问题。然后看看 /etc/modprobe.d 下有没有黑名单 nvidia 的驱动，给它取消了。我有一个 options nvidia_drm modeset=1 的配置，不知道有没有影响。

Xorg 这边要加一段配置。就保存在 /etc/X11/xorg.conf.d/nvidia.conf 好了。

Section "ServerLayout"
  Identifier "layout"
  Screen 0 "iGPU"
  Option "AllowNVIDIAGPUScreens"
EndSection

Section "Device"
  Identifier "iGPU"
  Driver "modesetting"
  BusID "PCI:0:2:0"
EndSection

Section "Screen"
  Identifier "iGPU"
  Device "iGPU"
EndSection

Section "Device"
  Identifier "dGPU"
  Driver "nvidia"
EndSection

那个 BusID 的值要自己看着 lspci | grep VGA 来改。

如果你之前是用N卡跑 Xorg 的，需要把 xrandr --setprovideroutputsource modesetting NVIDIA-0 之类的设置去掉。

然后重启系统就可以了。请做好通过 tty 或者 ssh 修复配置的准备。

默认情况下，Xorg 及其上的程序运行于i卡。使用 __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia 环境变量来指定使用N卡。为了方便起见，做一个别名好了：

alias nvrun="__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia"

然后就可以 nvrun minecraft-launcher 啦～

对了，要注意一下的是，这两个环境变量对视频硬解也是有效的。比如我如果给 mpv 使用这两个环境变量的话，mpv 就会黑屏（我的N卡不支持硬解……

在之前的文章中介绍过，X Window 中有个很方便的名叫 PRIMARY 的「剪贴板」，选中即复制，中键即粘贴。

然而问题来了：我在输入的过程中需要之前选中的内容怎么办？又或者我的内容是通过 xsel、Vim 等程序以键盘的方式选中的，我还要继续打字，要怎么粘贴才比较流畅呢？

我之前的解决方案是 fcitx 自带的 fcitx-clipboard 扩展。启用之后可以按 Ctrl-; 来显示几条最近复制的内容。如果启用了的话，第一条、第三至最后，都来自常见的 CLIPBOARD 选区，而第二条（如果用了够久，第一条及本条有的话）是 PRIMARY 选区的内容。于是我只需要按 Ctrl-; 2 就可以粘贴了。

这么用了很久之后，我读到了一篇讲 X Window 选区是如何工作的文章。然后突然意识到一个问题：fcitx-clipboard 是什么时候请求选区内容的呢？

这里先科普一下好了。X Window 的每一个选区，是由某个窗口作为所有者持有的，并且在被请求时输出内容。「复制」的时候，内容并不会被存起来放在某处，而是窗口跟 X 服务器说，「我现在是这个选区的所有者了！」至于是哪个，取决于应用程序（及用户的操作）。通常用户明确的「复制」操作（Ctrl-C 快捷键、菜单项等）会使用 CLIPBOARD 选区，而只是选中内容的话，会使用 PRIMARY 选区。我还没有见到有程序使用别的选区的。

如果使用的是 PRIMARY 选区，这个时候，旧的所有者（如果存在的话）会失去选区。在 Vim / GVim 里，可视区域会由「Visual」高亮组变为「VIsualNOS」高亮组（在我的主题里就是变灰了），而多数终端，选中的区域会失去高亮。下一次，有程序想要「粘贴」PRIMARY 选区，就会跟 X 服务器讲，请把 PRIMARY 选区的内容，以某个指定的格式写到指定窗口的指定属性上。然后 X 服务器把请求传给选区所有者，选区所有者就去按要求写属性。当然选区所有者也可能会拒绝请求，比如它拥有的是文本而请求方想要图片。当然后来大家要粘贴的内容比较大了，于是就有了 INCR 机制来一点一点地传数据。

这样的流程，也可以解释，为什么我往 Telegram 里粘贴图片，GIMP 却莫名其妙地挂掉了……

所以啦，在一个程序里复制之后，退出那个程序，你就粘贴不出来东西啦。可这样岂不是很不方便？是啊，所以又有了剪贴板管理器。它们的工作原理我还没有研究，猜想是支持 SAVE_TARGETS 的话，就等着对方退出之前把内容传过来，不支持的话一复制就传过来。

fcitx-clipboard 是这么干的：选区一有变化，它就获取其纯文本格式的内容，符合一定条件的就存起来。所以，当我在 Vim 里用键盘不断进入可视模式选东西进行各种操作时，因为我设置了 clipboard=autoselect 选项，Vim 会不断地通告「我拥有 PRIMARY 选区啦！」「我这边的 PRIMARY 选区又更新啦！」结果就是，fcitx-clipboard 会不断地把我在 Vim 中选中的内容给拿过去。

就那么点数据，本地传来传去当然没啥问题。但是，当我通过 ssh 使用的时候，我发现我在 Vim 里每一次扩大可视区域都如此地艰难。不得已只好关了 autoselect 选项。当时我还以为就选点文本，怎么就这么慢呢，谁曾想到，每一次更新可视区域，fcitx-clipboard 都会把我选中的文本请求一份……

那么好吧，不用 fcitx-clipboard 了。于是问题又回到了原点：怎么通过键盘粘贴 PRIMARY 选区呢？用程序把鼠标移过去点中键是不行的，因为程序不会知道当前光标在哪里。通过 xdotool type 也行，但是这样一个个字地输入，而且还不仅仅是 ASCII，鬼晓得有多少程序跟 Minecraft 一样会处理不过来而丢字？而且，怎么判断当前是否是输入文本的状态也是个问题。所以我还是走输入法这条路了。

其实这事完成并不难，从肥猫的傲娇扩展开始改，照猫画虎地注册热键，然后请求选区，提交文本。可我遇到一个很奇怪的 bug：扩展加载了，但是热键不生效。为了调试这问题，我通过手机 termux ssh 连过来，tmux attach 上，然后用蓝牙键盘对着屏幕里那只由于 fcitx 被 gdb 停下来了因此从电脑收不到键盘事件的 tmux 调试好久，最终发现热键怎么没注册上，才找到配置文件里一处没有被更新到的 tsundere 字样……

这个扩展名叫 fcitx-paste-primary，源码放 GitHub 上了。Arch Linux 用户可以通过 AUR 或者 archlinuxcn 仓库安装 fcitx-paste-primary-git。

对了，差点忘了说，这个扩展「粘贴」的时候，只是把会被粘贴的文本提交给应用程序，程序并不会认为是真的粘贴，所以在一些需要区分的程序里会出现问题。比如 Vim 和 zsh，都会把来自 fcitx-paste-primary 的文本当作用户输入而非粘贴而可能造成问题。