Linux 反对Windows注册表的主要原因是什么？

如果我想为Linux开发一个类似注册表的系统，我应该避免哪些Windows注册表设计失败？
哪些功能是绝对必要的？
主要关注点是什么（安全性、易配置性等）

我认为Windows注册表不是一个坏主意，只是实现没有兑现承诺。为配置（例如apache配置、数据库配置或邮件服务器配置）提供一个公共位置并不是一个坏主意，而且可能会提高可维护性，特别是当它具有（受保护的）远程访问选项时

---

我曾经研究过一个基于内核的解决方案，但后来停止了，因为其他人说注册表是无用的（因为windows注册表是。。。你觉得怎么样？

我想到的第一个问题是，你需要避免使用孤立的注册表项。当您删除程序时，您也在删除某些目录下的配置文件，但在拥有注册表系统后，您需要确保删除程序时，注册表中的配置也应删除。

如果您必须有一个存储库，至少要使用一个合适的数据库，这样你就有了恢复、备份、恢复等工具，你就可以在没有一套新的自定义API的情况下与之交互

我曾经研究过一个基于内核的解决方案，但后来停止了，因为其他人说注册表是无用的（因为windows注册表是。。。你觉得怎么样

基于内核的注册表？为什么？为什么？一千次，为什么？可能还需要一张基于内核的音乐明信片或

inetd

，以了解它所包含的所有要点。如果它不需要在内核中，它就不应该在内核中。有许多其他的方法来实现一个特权进程，而不需要像这样的深度黑客攻击

如果我想为Linux开发一个类似注册表的系统，我应该避免哪些Windows注册表设计失败

• 确保应用程序可以以原子方式一次更改多个条目
• 确保有简单的命令行工具来操作它
• 确保系统的任何关键部分都不需要它，以便始终能够引导到可以修复问题的位置
• 确保备份程序正确备份它
• 不要让可执行数据块存储在注册表中

---

IMHO，windows注册表的主要问题是：

• 二进制格式。这使您失去了各种非常有用的工具的可用性。在二进制格式中，诸如diff、search、version control等工具必须专门实现，而不是使用能够在文本的公共基底上操作的同类最佳工具。文本还提供了简单嵌入的文档/注释（也可以使用greppable）的优势，并且可以通过外部工具轻松地进行编程创建和解析。它也更灵活——有时，使用完整的图灵完整语言来表达配置比将其硬塞进键和子键的结构更好

• 铁板一块。将应用程序X的所有内容都包含在一个地方是一个很大的优势。移动到一台新计算机并保留您的设置吗？只需复制文件。虽然这在理论上对于注册表是可能的，但只要所有内容都在一个键下，实际上这是不可能的。设置往往分散在不同的地方，通常很难找到位置。这通常被视为注册中心的一种优势，但“所有东西都放在一个地方”通常会转移到“所有东西都放在一个巨大的地方”

• 太宽了。它很容易被认为只是一个用户设置的地方，但事实上，注册表变成了所有东西的倾倒场。其中90%的内容不是为用户阅读或修改而设计的，而是一个由各种结构的序列化形式组成的数据库，这些结构由希望持久保存信息的程序使用。这包括整个COM注册系统、已安装的应用程序等。现在这是需要存储的内容，但事实上，它与用户可配置设置和您可能想要阅读的内容混合在一起，大大降低了它的价值

---

完全正确。如果您的数据结构的大小是单调增加的（如Windows注册表），那么整个操作系统将需要偶尔重新安装，以清除垃圾。这是一个相当蹩脚的设计。好吧，我看到了问题，并同意它确实是一个问题。有必要更改包管理器，以便在删除时删除密钥树，否则我必须添加一个到期日期（密钥在30天后到期，除非同时访问），如HTTP cookies。很好。配置文件将如何解决这个问题？当然，软件包管理器可以删除系统范围内的文件，但用户的主目录中将保留大量垃圾文件。是的，主目录中的配置文件无法解决此问题。我服务器上的主页（更像是一个远程开发和实验系统）包括目录和文件，如.irssi、.tmp、.sqlite_history、.usermin、.wapi、.cpan，我甚至记不起我何时使用这些程序（时间戳大约2年前）或文件夹的用途（.tmp？.wapi？）。一半的程序甚至不再安装。注册可能会使情况恶化，但问题已经存在。有趣的是，你现在应该问这个问题，还是受我这里的问题启发？不管是哪种方式，一定要仔细查看答案。里面有很多好东西。听起来有点像你在尝试实现gconf的系统级版本？@Thomas:是的，这确实是受你的问题启发的@ZoogieZork：是的，系统级和更通用。基于内核，因为这将允许：1。基于文件系统的访问（如/proc或/sys）。2.在启动时读取配置，以便允许基于操作系统的设置。3.更严格的安全控制（A/f）