随着时间的推移，系统上的内存可能会变得越来越碎片化，从而难以找到连续的 RAM 块来满足持续的分配请求。

在具有许多 CPU 的系统上，启动时间可能会变慢，部分原因是启动所有 RAM 芯片需要时间。 Mel Gorman 最近提交了一些补丁，以并行而不是一个接一个地启动 RAM 芯片。

Linus Torvalds 报告了一些他认为不必要的 GCC 编译器警告，并给出了他对它们应该如何工作的看法。 具体来说，GCC 5.1 会发出警告，反对使用带有布尔变量的 switch 语句，大概是因为布尔值最好由一个简单的 if 语句来处理。

一项缓慢的努力正在进行中，允许将内核的几乎任何部分提取到其自己的共享库中，从而使用户能够使用他们喜欢的任何替代子系统。 这有着悠久的历史，可以追溯到微内核和单内核之间的争论。

当你以 setuid 身份运行一个程序时，它会以该用户的所有权限运行。 如果该程序产生新的进程，它们将继承相同的权限。 文件系统能力并非如此。 当你运行一个具有一组能力的程序时，它产生的进程默认情况下不具有这些能力； 必须明确地赋予它们。

Linux 在设计时考虑到了安全性。 事实上，最基本的安全机制直接构建在内核本身中，这使得恶意代码极难绕过。

内核开发人员面临的一个持续问题是删除数据的最佳方式，以便其他人无法恢复它。 通常有一些简单的工具可以取消删除意外删除的文件，尽管某些文件系统使此操作比其他文件系统更容易。

最近，人们讨论了一些减轻内核维护者疲惫的方法。 显然，合并窗口是劳动密集型时期，有些人希望提醒贡献者注意一些较好的代码提交习惯。

Nicolas Dichtel 和 Thierry Herbelot 指出，/proc 文件系统中的目录使用链表来标识它们的文件。 但是，当 /proc 目录开始有很多文件时，这将很慢，例如，当系统需要大量网络套接字时，可能会发生这种情况。

David Drysdale 在注意到 FreeBSD 已经支持 Capsicum 后，希望将 Capsicum 安全功能添加到 Linux 中。 Capsicum 定义了细粒度的安全权限，与文件系统能力非常相似。 但正如 David 发现的那样，Capsicum 也存在一些争议。

容器的实现非常棘手。 尝试完全隔离彼此的资源集，以便它们看起来像一个离散的系统，并以安全的方式进行隔离，必须在每个功能的基础上解决，并有许多注意事项和不确定性。

硬件错误很难编码。 在某些情况下，它们不可能进行编码。 一种特殊的硬件错误是机器检查异常 (MCE)，这意味着 CPU 存在问题。 在 Windows 系统上，它是蓝屏死机的原因之一。

多年来，随着新驱动程序、新硬件和特定用途可能需要的特定行为的激增，内核配置变得越来越复杂。 它已经达到了大约 3,000 个配置选项，而且这个数字只会增加。

有时，一段新的代码最终比其作者预期的更有用。 Alejandra Morales 最近发布了低温项目，作为他在 Christian Grothoff 指导下的硕士论文的一部分。 其想法是通过批量调度输入/输出操作来降低能耗。

Linux 的一个问题是它对系统调用的实现。 正如 Andy Lutomirski 最近指出的那样，它非常混乱。

有时会有人指出 Linux 中违反 POSIX 的行为。 通常的答案是修复违规行为，但有时 Linus Torvalds 认为 POSIX 行为已损坏，在这种情况下，他们会保留 Linux 行为，但他们可能会构建一个额外的 POSIX 兼容层，即使该层速度较慢且效率较低。

Linux 内核测试理念 测试是任何软件开发周期（无论开放还是封闭）不可或缺的重要组成部分，Linux 内核也不例外。

David Herrmann 希望禁用虚拟终端子系统，以便在不需要 VT 的内核上节省空间。 但是，他仍然希望看到内核 oops 输出以进行调试。 问题是只有 VT 子系统会显示 oops 输出——而他刚刚禁用了它。

我将在本文中报告过去两个月的 Linux 项目活动。 责怪我埋头苦干完成一些开发工作。 事不宜迟，让我们开始追赶吧。

主线版本（Linus 的树）新闻 2013 年的最后一个 3.13 候选版本于 12 月 29 日发布。 这个 3.13-rc6 版本很小，除了少数小的文件系统修复和 ARM SoC 相关更改外，只有 81 个提交到 infiniband、gpu、cpufreq、libata 和块驱动程序。