这只是一个词汇问题，但它一直在我的脑海中盘旋。
它来自LPIC准备书中的练习考试。根据这本书的正确答案是这~/Documents是一个相对目录，因为它是相对于主目录的。
然而，这本书包含的错别字和错误比例很高，所以我不能认为那里写的所有东西都是理所当然的。在这里我不同意，因为对我来说，~它充当了由 shell 扩展为变量内容$HOME或当前用户主目录路径（参见man bash）的变量，因此实际路径/home/myuser/Documents确实是绝对目录。
甚至Wikipedia一次，在这个话题上对我来说似乎也没有帮助（即使它似乎证实这本书在这个问题上是错误的）：
无论当前工作目录如何，绝对路径或完整路径都指向文件系统中的相同位置。为此，它必须包含根目录。
相比之下，相对路径从某个给定的工作目录开始，无需提供完整的绝对路径。
在这里，我再次不同意：根据这个定义，/opt/kde3/bin/../lib不依赖于当前工作目录的路径应该是绝对路径，但是我目前对此的理解与本书作者将这条路径设为相对路径相符。
根据韦伯斯特词典，快速的网络搜索只会增加我的挫败感：
绝对路径- 相对于根目录的路径。它的第一个字符必须是路径名分隔符。
那么$HOME/Documents，甚至$HOME不会被视为绝对目录？或者这个定义是否意味着变量扩展？贝壳的~性格呢？我可以在某处找到相对目录与绝对目录的任何可靠定义，并且我一直都错了吗？
在 Unix 系统上，路径名通常几乎没有长度限制（Linux 上为 4096 个字符）...除了套接字文件路径限制为大约 100 个字符（Linux上为 107 个字符）。
我已经检查过是否可以通过更改当前工作目录并在各个目录中创建多个使用相同路径的套接字文件来解决此限制./myfile.sock：客户端应用程序似乎正确连接到预期的服务器进程，即使lsof显示所有他们在同一个套接字文件路径上侦听。
我目前正在gpg --genkeyLinux VM 上进行测试。不幸的是，这个软件似乎依赖于/dev/random收集熵，并礼貌地要求用户在加密随机输入的屏幕后手动输入屏幕，因此它最终可能会生成一个密钥，我发现没有命令行参数可以告诉它使用另一个文件作为熵源（这个视频中的那个人遇到了同样的问题......）。
但是，用户应该可以自由选择使用它，/dev/urandom因为它没有任何问题。它主要是为了回忆旧的 PRNG 算法，这些算法从密码学的角度来看较弱。例如，虽然NetBSD 联机帮助页承认这种区别在非常早的启动阶段可能仍然有用，但它将这种区别描述为“民间传说”和“仅防御幻想威胁模型的虚构理论”。没有人同意此命令所需的熵量，也没有人同意熵实际上是实际消耗的东西，如GPG 联机帮助页中所述（“请不要使用这个命令，除非你知道你在做什么，它可能会从系统中移除宝贵的熵！” ）。
我读过有关人们安装rngd守护程序并将其配置为/dev/urandom用作 feed 的熵源的信息/dev/random，但我发现这种做法非常肮脏。
我试图以 FreeBSD 的方式解决该问题，方法是/dev/random将其删除并将其链接到/dev/urandom：
rm /dev/random
ln -s /dev/urandom /dev/random
我认为这是一个告诉“我信任/dev/urandom作为熵源”的设置。
我担心我会遇到某种错误，但这似乎提供了预期的结果，因为命令现在立即成功返回。
我的问题是：在 Linux 系统上链接/dev/random到/dev/urandomFreeBSD 系统上是否有任何已知的、实际的和错误的副作用？或者可以设想在由于/dev/random锁定某些服务而出现重复问题的情况下永久设置它（例如在引导过程结束时的脚本中）？
我目前正在从安全角度比较 OpenBSD、FreeBSD 和 Linux 上的随机 PID 实现。
只要考虑到 OpenBSD 和 FreeBSD，我的工作就完成了。然而，虽然这里的答案指出仅通过sysctl设置就可以在 Linux 上启用随机 PID ，但我无法确定它是哪个设置。
网上的研究只导致主流Linux内核拒绝补丁和讨论，也没有出现在grsecurity特性中（很明显在我的Linux机器上PID到处都是增量的，sysctl似乎没有参数名称相关，并在其中搜索了一些内核源代码没有显示任何相关信息）。
PID 随机化真的可以在 Linux 上使用吗？
我打算使用 LXC 容器来隔离大部分面向网络的服务。
根据我的理解，我主要有两种方法来做到这一点：
创建 root 拥有的非特权容器。在这种情况下，root 将拥有一组大的 sub-UID 和 sub-GID，并且该范围的不同子集将影响到每个容器（没有容器会相互共享任何 sub-UID 或 sub-GID），
创建非特权系统帐户拥有的非特权容器。在这种情况下，每个帐户将拥有一个容器以及该容器所需的从属 UID 和 GID。
从可用性的角度来看，前者要好得多：更容易设置和维护。
但是，从安全的角度来看，两者之间有什么区别吗？
例如：
与属于不同用户并因此属于不同池（不同行）的 ID 相比，属于/etc/subuid和 中定义的同一池（同一行）的 ID 之间是否存在某种链接或水平关系/etc/subgid？
从属 ID 与其所有者帐户之间是否存在某种链接或垂直关系？root 拥有的从属 ID 是否可以获得比非特权用户拥有的从属 ID 更高的权限？从属 ID 是否可以比升级为任何其他任意 ID 更简单的方式升级为其所有者 ID？
由 root 拥有意味着所有管理容器的命令都将使用主机的 root 权限启动。这是否构成弱点，或者例如所有特权是否提前下降？
等等。
换句话说：root 拥有的非特权容器可能比标准帐户拥有的容器“更少非特权”吗？
我已经使用OpenSuse好几年了。我最喜欢这个发行版的一件事是处理 Plasma/KDE 问题的方式：有时可能会发生面板短暂消失并打开一个消息框，告诉我 Plasma 桌面已崩溃并已重新启动，如果我愿意，还建议将调试数据发送给开发团队。
现在几个月来，我已经切换到基于 Fedora 的发行版（Qubes OS，基于 Fedora 20）。默认情况下，此发行版似乎不提供此行为，因为：
十几年前，当我还是学生时，我所在的大学也在使用 Fedora 进行动手练习。当时，面对类似的冻结，我找到了通过 SSH 远程连接并杀死桌面管理器使其自动重新启动，解锁图形环境的解决方案。
遗憾的是，由于 Qubes OS¹ 的特定设计，这个快速而肮脏的 SSH 解决方案在这里不起作用。但是，我猜想 OpenSuse 的消息框工具可能会以适当的方式做类似的事情：在 Plasma/KDE 没有响应时实现某种看门狗检测，然后杀死并重新启动它。
所以我想知道的是：这个工具是 OpenSUSE² 的一个特定功能，还是我应该安装一些包或我应该更改一些配置以在我当前的安装中启用这种行为？
桌面冻结特别令人沮丧，当我知道应用程序本身很可能仍然正常工作并且简单地重新启动 Plasma 进程将使一切恢复正常时，甚至更令人沮丧......
¹：在 Qubes OS 中，网络连接在 Xen 域中被隔离，而 KDE 在无网络的 Dom0 中。出于安全原因，Qubes OS 的设计旨在避免从网络访问用户界面...
²：过去（如果现在不是这样的话）OpenSUSE 曾经有一个内部经过大量修改的 KDE，使它们成为第一个提出稳定 KDE4 的发行版，所以我担心这个工具只是这些糖果的一部分。 ..