现代 Linux 是不是太复杂了？

linux| 2015-08-19

多年来，我习惯于在我的个人机器上运行 Debian sid (不稳定版)。笔记本、工作站，有时甚至我的个人服务器几年前也运行 sid。顾名思义，Sid 是不稳定的，有时会出现问题。但这没什么，因为无论是什么问题，我总能发现并很快修复它们。这同时也是我为最新最酷系统所付出的代价。

过去的几个月，我解决了 Jessie 中一个很小但却恼人的问题：Nautilus、Thunar 以及 digikam（是的，这代表Gnome，XFCE和KDE）均不能挂载我插入的USB设备。仅提示“没有执行权限。”当然，我仍然可以使用 mount -o uid=1000 /dev/sdc1 /mnt指令挂载，但这样做很不方便。

为解决该问题，我特地将一个 jessie 系统切换至 systemd。确实有效，但我不知道原因。我还没有时间去更新我的工作站，坦白地说，我对此很担忧。

问题的关键在于：我甚至不知道要从何处开始着手。我在 google 上搜索了该问题，发现所有答案均指向 polkit，或者 dbus，或者 systemd-shim，或者 cgmanager，或者 lightdm，或者 XFCE，或者… 我找到该问题的一份具体 bug 报告 — Debian #760281，但标注为已修复，而我描述自己仍旧遇到的问题的相关评论，却无人问津。

没有任何地方备注 Digikam 挂载问题应该查看 polkit ，更别提 cgmanager。甚至当我找到那些安装包时，却发现其文档患有不良 Unix 文档诟病：谈论一些细枝末节的观点，而没有将其放到上下文中。下面是 cgmanager 帮助文档中令人困惑的内容提要。

cgmanager 是管理 cgroup 的守护进程。程序和用户可以根据自己的特权发出管理 cgroups 的 D-Bus 请求。为确保用户在操纵 cgroups 时不超出指定权限，cgroup 管理器只接受来自自身进程标识和用户命名空间内任务的常规 D-Bus 请求。对于私有命名空间的任务（例如容器），可使用 SCM 增强型 D-Bus 调用。不建议主动使用这些调用。相反，建议每个容器都运行 cgproxy，它将普通 D-Bus 请求作为增强型 SCM D-Bus 请求转发至主机 cgmanager 。

这对我来说就像 Vogon 诗歌一样难以理解。cgmanager 如何启动的？“ SCM 增强型”是什么意思？我甚至不知道 cgroup 是什么。

这种情况持续了几个月，让我很困惑：只有我是这样吗？（Google 结果表明并非如此，有很多发行版都存在这种具体问题，除此之外还存在一些非常可怕的建议。）如果不是，为何如此基础和明显的情况持续了这么久？我们是不是创造了一些难以理解和调试的复杂事物。

在我看来，这与 systemd 问题密切相关。过去我常常会说 Linux 是干净的、条理分明的、组织合理的、安排有序的。但我现在真的不能这样说了。用户和群组实际上并没有绝对的权限，因为系统中有类似 polkit 的程序在运行。（是的，顺便说一下，我是 plugdev 的成员之一。）错误信息是无用的（为什么我没有权限？）并且找不到日志信息。通常，一个人可以指定谁能通过 /etc/fstab 行信息或者某些sudo规则挂载设备。当然，你必须知道去哪里查找，这貌似很简单，只要将这两个地方组合起来，但是我甚至花费了大量时间都想弄不明白应该去哪里查找。

systemd 也许能够解决其中部分问题，也许会带来一些新的问题。但在我看来，问题不仅仅是具体的桌面环境问题，而是脱离对实际含义的思考去添加特性的理念问题。

当然，在我写这篇文章时，我的笔记本坚持要求用 root 密码来执行挂起操作，并且 systemd 仍在运行中，于是另一个梦魇又诞生了……