依云's Blog

磁盘碎片其实有两种：文件碎了，和空闲空间碎了。使用 FIEMAP 命令可以获取到文件在磁盘（的逻辑地址上）的分布情况。也是 filefrag -v 命令输出的东西。比如我的 pacman.log 就很碎：

Filesystem type is: 58465342
File size of /var/log/pacman.log is 11052443 (2699 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..    2015:  170210423.. 170212438:   2016:
   1:     2016..    2017:  170567879.. 170567880:      2:  170212439:
   2:     2018..    2027:  170569969.. 170569978:     10:  170567881:
   3:     2028..    2030:  170574582.. 170574584:      3:  170569979:
   4:     2031..    2031:  170574631.. 170574631:      1:  170574585:
   5:     2032..    2033:  170592662.. 170592663:      2:  170574632:
....
 123:     2683..    2687:   56903805..  56903809:      5:   56906403:
 124:     2688..    2698:   56903011..  56903021:     11:   56903810: last,eof
/var/log/pacman.log: 125 extents found

整理的办法也很简单，复制一下，基本上就好了。只要剩余空间足够，小文件会变成一整块，大文件也是少数几块。如果非要弄一整块大的，比如我存放 pacman 数据库的那个小文件系统，可以用 fallocate -l 200M pacman.fs2 这样子的命令分配空间，然后把数据 dd 进去（cp 不行，因为它会先截断文件再写入，之前分配的空间就释放掉了）。

介绍完毕，重点来了：怎么找到那些被写得很碎很碎的文件呢？

对每个文件调用 filefrag 肯定太慢了，所以我写了个库和工具 fiemap-rs 直接调用 FIEMAP。它提供两个工具。一个是 fraghist，统计碎片数量分布直方图，用来了解一下某群文件有多碎。另一个是 fragmorethan，用来寻找碎到一定程度的文件。运行起来是这样子的：

/var/log:
# Number of samples = 712
# Min = 1
# Max = 297
#
# Mean = 11.338483146067423
# Standard deviation = 40.138129228003045
# Variance = 1611.0694179238724
#
# Each ∎ is a count of 13
#
  1 ..  31 [ 658 ]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
 31 ..  61 [  11 ]:
 61 ..  91 [   9 ]:
 91 .. 121 [  10 ]:
121 .. 151 [   6 ]:
151 .. 181 [   5 ]:
181 .. 211 [   3 ]:
211 .. 241 [   2 ]:
241 .. 271 [   3 ]:
271 .. 301 [   5 ]:

/var/log/journal/00000000000000000000000000000000/system@xxx.journal: 271
/var/log/journal/00000000000000000000000000000000/system@xxx.journal: 277
/var/log/journal/00000000000000000000000000000000/system.journal: 274
/var/log/journal/00000000000000000000000000000000/system@xxx.journal: 297
/var/log/journal/00000000000000000000000000000000/system@xxx.journal: 274

我系统上最碎的两群文件是 journal 日志和 python2-carbon 的数据文件。carbon 优化做得挺不好的，明明是预分配的固定大小文件啊，不知道怎么的就弄得很碎了。部分程序的日志（如 pacman、getmail）和火狐的 SQLite 数据库也挺碎的。后边这些我已经处理掉了所以示例输出只好用 journal 的啦。

找到想要整理的过碎的文件之后，复制一下就好啦：

for f in $(<list); do sudo cp -a $f $f.new; sudo mv $f.new $f; done

啊对了，工具的编译方法是，获取源码并安装 Rust 之后，在项目根目录里 cargo build --release 然后就可以在 target/release 下找到新鲜的可执行文件了～顺便说一下，这东西是支持 Android 的哦。

首先说明一下，这是一位 docker 新手对于 docker 的粗浅理解。如有不对还请谅解。我很早之前就尝试过使用 docker，然而由于术语的差异，导致我每次运行东西时都傻乎乎地创建了一个新的容器……现在感觉用法终于是弄对了，所以整理一下，将其类比到 Linux 上的普通软件的概念上。

image

相当于软件分发中的软件（安装）包。

Dockerfile

跟 PKGBUILD 类似，是用于制作一个 image 的打包脚本。用 docker build -t name:tag . 就可以制作。

container（容器）

一个容器就像是一个安装好了的软件包。该软件已经准备好，随时可以运行了。

docker run

「安装」指定的 image。也就是从 image 制作出容器来，顺带着进行首次运行。如果反复使用，会把同一个软件给安装多次。

docker start

就像是「运行」一个已经安装好的软件，容器跑起来了。之前容器的状态（文件的修改）也会生效。

docker ps

列出运行中或者已安装（带 -a 参数）的软件们。前者和 UNIX 命令 ps 类似，后者则没什么相似之处了。

docker exec

在正在运行的软件的环境内执行命令。有点类似于 ssh。

repository

跟 Linux 的包含众多软件的软件源并不一样。这个东西跟软件名类似，用于标识为特定功能的 image 集。发布出来的 repository 名的格式通常是 `owner/name`，跟 GitHub 差不多的。

tag

软件的版本，跟什么 lite、pro、beta 之类区分类似。它并不是用于分类的标签，也不是 git 中对于指定版本的不变的称呼。它更像是 git 的分支在某些情况下的作用，比如 latest tag 就跟 git 仓库的 master 分支一样，总是指向最新的版本。

我经过以上这样的映射之后，docker 理解起来就容易多了，行为也更符合预期。

首先 iw list 看是否支持。如果支持，那就

iw dev wlan0 interface add p2p0 type __p2pdev

这样其实并不会多出一个叫 p2p0 的网络接口。iw dev 能看到多了个「Unnamed/non-netdev」设备。不执行这个也可以连接上 WLAN Direct，但是当前的 managed Wi-Fi 连接会断掉。执行之后再连接，managed 连接会持续，iw dev 里会有两个 Unnamed，不知道何故。另外这个 type __p2pdev 加上去了我就不知道怎么删除了。试了几个命令，结果搞得内核 oops 了……

然后是 wpa_supplicant 配置文件：

ctrl_interface=/run/wpa_supplicant_p2p
ap_scan=1

device_name=起一个名字
device_type=1-0050F204-1

driver_param=use_p2p_group_interface=1

wpa_supplicant 跑起来。注意这里的接口名还是那个 managed 接口的。

wpa_supplicant -i wlan0 -c p2p_config.conf

然后 wpa_cli 连过去操作：

wpa_cli -p /run/wpa_supplicant_p2p

首先用 p2p_find 开启搜索。这时候对端设备能够看到自己了。使用 p2p_connect 对端MAC pbc go_intent=0 连接，在对端接受连接即可。go_intent=0 是让对方作为 group owner，这样对端 Android 才会提供 DHCP 服务（否则要本地提供了）。

然后就可以给自己添加 IP 地址了。此时是可以用 dhcpcd 的，然而直接跑的话它会抢走默认路由，所以知道地址范围之后手动加一个好了：

ip a add 192.168.49.22/24 dev p2p-wlan0-1

Android 设备的地址是 192.168.49.1。

之后就可以用 adb connect 然后 scrcpy 了。

PS: Android 很喜欢四十几的 IP 段呢。USB 网络共享是 192.168.42.129/24，Wi-Fi 网络共享是 192.168.43.1/24，而 WLAN Direct 是 192.168.49.1/24。不知道蓝牙网络共享是多少呢。

PPS: scrcpy 在我的 XZ2C 上运行完美，但是在 MIUI 10 上需要去开发者选项里开启选项「USB 调试（安全设置）」，否则会是「只读模式」，只能看，所有交互操作无效。

参考资料

• en:developers:p2p:howto [Linux Wireless]
• OMAP Wireless Connectivity NLCP WiFi Direct Configuration Scripts - Texas Instruments Wiki

运维同事为了收集日志，配置程序将日志写入一个命名管道。然后他在外边拿 tail -f 去读，结果发生了灵异事件。通过 strace 可以看到，tail 进程读取了日志，但是却并没有再输出来。但是如果不启动输出日志的程序，而是在实例启动之后再进去往管道里写数据，却又是可以立即得到 tail 的输出的。

很奇怪的行为，一群人在那里研究半天，猜测是不是环境变量造成的啊，是不是放后台组执行造成的啊，是不是 XYZ 啊。——典型的「霰弹枪式」除错法。

我当时也被带沟里了。于是跑去尝试复现，接着去读 tail 的源码。花了好久才明白这是一个很简单的问题：tail -f 的语义首先是 tail 这个词本身——先读文件最末尾的数据（默认是十行），然后再是 -f 选项的语义，即在文件更新时接着读取数据并输出。所以，当程序往里边写日志时，管道写端一直没关闭，tail 就一直读不到文件结束，也就无法确定最后十行是什么。当他们测试的时候，因为使用的是 echo shell 命令，打开文件、写入数据、关闭。这样 tail 一下子就读取到了文件末尾，然后把数据输出来了。接下来就是边读边输出了。

其实这种使用方法本身就很奇怪了，以至于这个执行流是兼容许多系统的 tail 的各种分支里，最最不常规、无可奈何的那一个分支。你都用管道了，cat 一下嘛。如果怕遇到管道被 reopen 的情况，就在 while true 里 cat 就好。

这个事件中，我也是见识了很多人解决问题的奇怪思路：「我猜猜猜。猜对了哦耶，猜错了，哎呀编程好难啊，Linux 系统好难啊……」猜你妹啊！你长的是大脑又不是骰子，用逻辑一步一步地取得结果不好吗！

有一个小游戏——猜数字。比如甲确定一个 1 到 1000 之内的整数，然后乙来猜。每当乙给出一个猜测时，甲回应猜对了，还是过大或者过小。如果乙知道什么叫二进制的话，乙可以保证在十次之内猜中的。

计算机系统和编程世界里，最棒的一点是确定性和逻辑性。虽然经常也不是像上例那样完全确定的，但至少比起人类社会要容易确定得多。特别是在有源码的时候。所以解决问题的路线也很简单，顺着问题的症状一路回溯，确认然后排除那些没有问题的部分，逐步缩小问题所在的范围，直接你看见它。就跟上边的猜数字游戏或者地毯式搜索一样。每一次猜测都是带着排除一部分没有问题的地方而去，而不是明明有证据表明某个地方不可能有问题，你还偏偏怀疑问题在那里，做无用功。

就像调查一个凶案，这些人放着有作案嫌疑的人不管，非要费劲地去调查那些有相当好的不在场证明的人。

Arch Linux 中文社区这边也有很多这种人。出了问题描述不清楚症状。新手嘛，没经验也没学习过如何描述事实，讲不清楚也没什么，引导对方获取截屏、日志，逐步排查问题就好了嘛。可就是有些热心人，喜欢提出自己的猜测。重点是：都不尝试证实猜测是否属实，就急着上解决方案。结果就是，我询问细节事实的消息没人理，求助者试试这个，试试那个，最终问题能否解决，就跟买彩票能否中奖一样，全凭运气。

前两天我又看到了基于子序列匹配的字符串过滤工具 fzf 的绚丽效果了。实际上我很早就听说了这个工具，只是懒得动手配置。此次提及，我发现 fzf 已经在官方软件源里了，而我也正好有时间，所以打算试一试。

然后呢，Arch Linux CN 群组里艾穎初提到 skim 这么一个工具。了解了一下，这个就是 Rust 版本的 fzf，并且在 archlinuxcn 源里也有（git 版本，即 skim-git）。这太好了，就是它了！

skim 的操作很简单。文章开头的链接里已经有效果演示了。常用的也就是输入子序列去过滤，然后再输入一个进一步过滤，直到看到想要的。使用 ! 前缀可以反向过滤，^ 匹配开头 $ 匹配结尾。Ctrl-p/n 来上下移动。提示符那里也支持通常的行编辑。

到现在为止，我自行实现了 sk-cd、sk-search-history、sk-vim-mru 三个功能。另外使用了自带的 completion.zsh 文件。由于各种不满意，没有使用自带的 key-bindings.zsh 文件（也就包含 cd 和历史命令搜索功能啦）。

completion.zsh 里目前有两个功能。kill 时通过 ps 补全进程 pid。这个想法很好，以后我可能专门做一个通用的方便 strace 啊 lsof 啊 gdb 啊之类的用。

另一个是遇到两个星号（**）时按 Tab 补全，查找并替换成当前目录下的文件。

我实现的 sk-cd 是从 autojump 取目录列表，然后喂给 skim。于是就成了交互式的 autojump～这是一个我很需要的功能。原来我都是通过 Tab 补全列出可能的项，然后再 Tab 过去选的，有些慢也有些麻烦。

sk-search-history 就是在历史命令里找东西。因为遇到特殊字符时无法正确地加载预览，我并没有开启预览功能。反正找到的命令只会放在命令行上，并不会自动执行的，选错了可以及时取消。

以上两个功能分别绑定到 Alt-s d 和 Alt-s r 上。我使用 Alt-s 作为 skim 快捷键的开头，以便保留 zsh 原本的快捷键，避免冲突，特别是以后可能会有更多功能被加入。我在 Vim 里，也是类似的做法，Alt-q 是 easymotion 的开头快捷键，Alt-d 是 denite 的开头快捷键。

sk-vim-mru 仅仅是个命令了。使用的数据是 mru.vim 的历史记录文件。然后做了两个函数：vim-mru 使用 Vim 编辑文件，vv-mru 使用我自己的 vv 命令在已有的 gVim 里编辑文件。

我做的版本和 skim 自带版本，最大的差别在于，我的版本会尽量使用全部的窗口空间，而 skim 自带的总是会使用 40% 窗口高度。（所以我有个函数用来获取当前光标位置，有需要的可以自己拿去用。）

如果你想用我的配置，可以 wget https://github.com/lilydjwg/dotzsh/raw/master/plugins/sk-tools.zsh 回去，然后 source 一下就好。有需要的话（比如数据来源、键绑定等）可以自行修改。

2018年09月17日更新：我尝试了一下把 sk-search-history 映射到 Ctrl-r 上，然后很快就放弃了。因为 skim 的结果是不可预测的，而默认的 Ctrl-r 的结果是完全可预测的（只要还记得；当然你不能开（那个让我在服务器上误杀过进程的）实时历史共享）。可预测性对提高效率非常关键，因为你不需要中断思维，停下来等结果。

很早之前，我在《Linux「真」全局 HTTP 代理方案》中介绍了 redsocks 方案。不过它只处理了 TCP，并没有处理 UDP，DNS 也是采用强制 TCP 的方式来处理的，再加上它本身还要将请求转发到真正的代理客户端，延迟比较高。然后，还可以结合 Wi-Fi 分享 或者网络命令空间，玩点更有趣的。

首先要有支持的代理客户端，比如 ss-redir。这个就不用多介绍了，配置好、跑起来即可。以下假设此代理跑在 127.0.0.1 的 $PPROT 端口上。

然后，TCP 的代理设置。使用的是和 redoscks 一样的方案。这个比较简单，除了有一点需要注意：DNAT 到 127.0.0.1 时，需要设置内核选项net.ipv4.conf.all.route_localnet=1。

最麻烦的是 UDP 的代理，使用的是 TPROXY。首先，需要把要走代理的数据包路由到本地。以下假设我们给要代理的数据包打上标签 1。那么执行：

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

那个 100 是路由表的编号，可以自己选一个喜欢的。

然后，对于转发流量（来自局域网或者另外的网络命名空间），直接把需要代理的数据包扔给 TPROXY 目标，并且打上对应的标签即可。而对于本地产生的流量，不仅要带有对应的标签，而且需要在 OUTPUT 链打上一个（与之前不同的）标签，触发 reroute check 才行。

最后，对需要代理的数据包设置 iptables 规则：

比如来自网络命名空间或者局域网的 IP 段 192.168.57.0/24 全部走代理：

iptables -t nat -A PREROUTING -p tcp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j DNAT --to-destination 127.0.0.1:$PPROT
iptables -t mangle -A PREROUTING -p udp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j TPROXY --on-port $PPROT --on-ip 127.0.0.1 --tproxy-mark 1/1

其实 Linux 是支持文件的创建时间的呢。不过不是所有文件系统都支持，比如 ext4、xfs、btrfs 都支持，zfs、vfat、ntfs 不支持。

但是呢，用户基本上是看不到的。文件系统有记录，但是没有 API 可以获取到这个数据。所以你用 stat 命令的话，会看到「创建时间」一行总是「-」。用 debugfs 搞 ext4 是可以的，但是那个需要 root 权限，并且一不小心会搞坏文件系统。

最近，我阅读内核源码时，忽然发现内核已经通过 4.11 版本引入的 statx 系统调用支持获取创建时间了。字段名里用的是 btime（birth time），没有用 crtime（creation time），也没有用大写的 Btime 呢。

但是 glibc 并没有支持，所以要用 syscall 函数来调用。也不是很复杂。不过我正着手用 Rust 实现的时候，却在内核源码树里找到了 samples/statx/test-statx.c 这么个文件。原来有现成的啊！

gcc 编译一下，还真好用：

>>> statx /
statx(/) = 0
results=fff
  Size: 224             Blocks: 0          IO Block: 4096    directory
Device: fe:01           Inode: 96          Links: 17
Access: (0755/drwxr-xr-x)  Uid:     0   Gid:     0
Access: 2018-07-11 13:33:08.659477830+0800
Modify: 2018-03-30 15:06:02.645864827+0800
Change: 2018-03-30 15:06:02.645864827+0800
 Birth: 2017-06-19 21:07:53.653467000+0800

2019年09月03日更新：现在（coreutils 8.31）stat 命令已经支持创建时间了。

VBox 可以从一个指向本地硬盘的 vmdk 文件启动虚拟机。

首先，为了避免使用 root 运行 VBox，我们需要给自己访问磁盘的权限。我即将启动的是位于 sda5 上的 openSUSE。它使用 UEFI 启动，所以 UEFI 分区的权限也是需要的。创建 vmdk 文件的时候需要读取分区表，因此，还需要 sda 的权限：

sudo setfacl -m u:${USER}:rw /dev/sda{,1,5}

然后我们创建 vmdk 文件。使用-partitions 1,5选项的话，只有这两个分区能在虚拟机里访问，别的分区读的时候是全零，写入操作会被忽略。-relative选择使用分区设备名（sda1、sda5），这样创建好之后 VBox 不再需要对整块硬盘 sda 的权限了。另外会附带创建一个名字以 -pt.vmdk 结尾的文件。它是单独的分区表。如果是 MBR 启动的话，是可以直接在虚拟机系统里更新引导器的，不影响外边的系统。不过我这次是使用 UEFI 启动，所以用不上了。

VBoxManage internalcommands createrawvmdk -filename hostdisk.vmdk -rawdisk /dev/sda -partitions 1,5 -relative

创建好之后就可以撤销对 sda 的权限了：

sudo setfacl -b /dev/sda

然后去 VirtualBox 界面那边创建新虚拟机，并「启用 EFI」。另外，可以在存储设置里，把「控制器: SATA」的「使用主机输入输出 (I/O) 缓存」启用，似乎这样 I/O 会快一点。

VBox 的 EFI 并不像电脑的那样，按 F12 可以选择启动项。因此，它会启动默认的那个，也就是 /EFI/Boot/bootx64.efi。如果你想启动的系统不是这个的话，就把它的 efi 文件复制过来覆盖它。比如我是这么做的：

cd /boot/EFI/Boot
sudo cp ../opensuse/grubx64.efi bootx64.efi

如果是 Windows 10 并使用 MBR 启动的话，可以在虚拟机里用如下命令更新 MBR，干掉原来用于多启动的 grub：

bootsect /nt60 c: /mbr

做好之后就可以启动啦～

对于设备的权限设置，重启之后会丢失的。需要的时候再加上好了。

PS: openSUSE 自带了 VBox 的驱动啊，不过剪贴板共享不能用，大概只有显示驱动没带上服务。

PPS: 启动没一会儿就通知我更新出现错误，一看软件源设置，果然是 HTTP 的，被垃圾鹏博士劫持了。

刚听说就已心动，无奈当时并不支持 Linux。后来由于一些事情耽搁到现在，终于到手了～

显示器整体尺寸是31cm×27cm，其中显示屏尺寸不到26cm×21cm（请注意：手工测量有误差）。分辨率是2200x1650。也就是200dpi多，和我的 Kindle Paperwhite 一代差不多的。

显示器下方是两个纸盒，里边是Y形线（照片中没有）、简易支架（那根根子）、螺丝和仅几百M的驱动U盘。

Y形线是附加了USB电源线的HDMI线。信号走HDMI，电源走USB，所以需要额外占用一个USB口。当然接充电器上也是可以的，只是在电脑边接个充电器更不方便。

工作时，USB端口的电流为30～50mA左右，并不像说明书上说的需要2A那么多，挺省电的。对比之下，我的罗技鼠标接收器也需要15mA左右的电流呢。

线都接上之后，屏幕会闪几下，然后就可以用了。只是每隔几分钟会弹出提示信息，要求安装并运行所谓的「驱动」。下图是默认的 floyd 模式：

为了更多的模式，以及最重要的，别显示那个提示信息，需要安装并运行大上提供的软件。

软件是为 Ubuntu 提供的，但是 Arch 下也可以使用。下载并解包，将得到的三个文件「PaperLikeHD」、「ResChange」、「DS.ico」放到/usr/local/sbin/下，然后sudo PaperLikeHD 运行，会弹出一个包含一列按钮的窗口。不给 root 权限是不行的，会什么也不做就退出。

但是这样还不够。我使用的时候它总是报告找不到显示器。客服不肯告诉我它到底使用什么机制检测的，所以我 strace 又反汇编看了一下，最后发现它在找 /dev/i2c-* 设备文件，而我的系统上没有它们。看了一下一堆以 i2c 开头的内核模块，最后发现只要加载 i2c-dev 模块就好了。大上的软件需要一些时间来检测，等一会儿它就会在终端打开出「setting...50」这样的文字，这时就好了。

过程中我还专门启动到 Ubuntu live 系统里测试来着。后来才知道原来是自己的手速太快，软件还没检测到，其实等等就好 (╯‵□′)╯︵┻━┻

从图片中可以看到，floyd 模式的显示很粗糙。这是因为它实际上只有二阶灰阶，通过不同密度的点来近似不同的灰度。虽然显示有很严重的颗粒感，但是它响应飞快，常规打字操作时几乎感觉不到延迟，很适合写作和阅读文本。而真正的二阶灰阶模式 A2，只有黑白两色，虽然依旧反应快速，但是因为非黑即白，只能用来读纯文本，任何阴影或者灰色的字都不好处理。

16灰阶的 A16 模式，显示清晰、层次丰富，但是响应速度非常慢。也不是非常啦，除了屏幕大小外，无论显示效果还是响应速度都跟我的 Kindle 一样的。而与 Kindle 不同的是，它会在更新时将更新区域变黑再显示，造成闪烁。在此模式下使用鼠标非常非常费力，任何非静止的元素（比如火狐载入中的动画、时钟、光标移动）都挺分散注意力的。

以上都是所谓的「可变分辨率模式」。另外有个「固定1100x825模式」，也就是使用一半的分辨率。至于另一半去了哪里，看看它所支持的模式就能猜到了：

• A5，也就是五灰阶。这是用四个墨滴来显示一个像素，每个墨滴只有黑与白两种状态。
• A61，所谓的61灰阶。也是用四个墨滴来显示一个像素。不过每个墨滴竭尽所能有16种状态，也不知道大上是怎么组合出这61灰阶的。

也不知道大上为什么把这两种墨滴用法叫作「可变分辨率模式」和「固定1100x825模式」。哪里可变了，又哪里固定了呢？这两种模式切换时，会调用「ResChange」程序，它会影响当前的显示器布局，需要重新使用 xrandr 进行设置。

以下是各种模式显示这个灰阶测试网页的照片：

A2 模式：

A16 模式：

floyd 模式：

A5 模式：

A61 模式：

半分辨率下，清晰度做出了很大的牺牲。以下是 A16 和 A61 模式显示 PaperLikeHD 软件自身界面的效果对比：

在 A2、A5、floyd 模式下，可以调节对比度，也就是墨滴到底显示为黑还是为白的阈值，以在显示不同的页面时都能将文本与背景良好区分开。

和 Kindle Paperwhite 不同的是，它没有背光。在晚上的时候，屏幕偏暗，附加一个台灯光源比较好。不过它的屏幕也不像 Kindle 那样偏黄。

这篇文章最终定稿，就是在 PaperLikeHD 上完成的，使用的是 floyd 模式。我个人觉得半分辨率的几个模式很鸡肋。目前觉得，写作用 floyd 模式，文本阅读使用 A2 模式，网页阅读使用 A16 模式，这样最好了～

floyd 模式还有个问题：在显示某些图片时（比如我的 Awesome 桌面壁纸），那些墨滴颗粒会不断地抖动，就像风在吹沙粒一样……

最后，这里是大上的官网链接。

最近学 wzyboy 搭了一套 collectd + Graphite + Grafana 监控。collectd 和 Grafana 都比较好搞，Arch 官方源里有。但是 Graphite 就没有了。

我没有使用 Python 2 版、带 Web 前端的 Graphite 包，而是使用 graphite-api 提供 Web API，python2-carbon 存储数据。它们在 AUR 上有，其中 python2-carbon 是相当危险的（现在已经改了）。

为什么危险呢？

首先，最明显的，carbon 服务以 root 用户运行。它本身没有任何使用 root 权限的必要，所以专门创建一个 carbon 用户更好。

其次，它运行起来之后，我发现是监听 0.0.0.0 的。这个也无必要：我的 collectd 就在本地呢。

最后，也是最吓人的：它默认开启了接收 pickle 数据的端口。Python pickle 模块的文档一打开，就能看到红色的警告，告诉人们不能接收不信任来源的 pickle 数据。而我曾经工作过的公司也发生过通过 pickle 注入代码的事情：攻击者发现了一个对外网开放的 Redis 服务，刚好那个 Redis 是给 Celery 用的。攻击者于是往里边写了条自己构造的 pickle，在解析时调用 curl 命令向其服务器报告IP、端口和当前UNIX用户的信息。

这接口，开在外网，就是远程代码招行；开在本地，就是本地提权。很危险的。

为了防止各种漏洞被利用，一个未雨绸缪的办法就是：权限最小化。本来这是件比较麻烦的事情，好在 systemd 提供了许多现成的配置项，使得给 carbon 这种服务加固简单易行。

首先创建用户，写一个 sysusers 文件就可以了：

u carbon - "carbon service" /var/lib/carbon

然后，它需要使用文件系统的某些部分。那么别的就用不着访问了，比如 /home。而 /dev、/tmp 这些，自己用自己的就好。连 / 也不让写，也不允许获取任何新特权了。其实使用 carbon 用户它本来就写不了 / 也没有任何特权了，但以防万一嘛，要是哪里来个本地提权漏洞呢？

[Unit]
Description=Graphite/Carbon
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/carbon-cache.py --config=/etc/carbon/carbon.conf start
User=carbon

PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
CapabilityBoundingSet=

ReadOnlyPaths=/
ReadWritePaths=/run
ReadWritePaths=/var/log/carbon
ReadWritePaths=/var/lib/carbon

[Install]
WantedBy=multi-user.target

限制文件系统的访问，systemd 配置起来很方便，我打包的时候喜欢尽量加上。

完整的 python2-carbon 服务配置和打包脚本在这里。

以及，这里是 Arch Linux 中文社区的编译机的 Grafana。