点评Linux难称完美的几大命门

　　从1991年到2008年，Linux已经走过了17个春秋，但它依然是一个正在发展中的作品，依然难称完美，还有好多方面需要完善，虽然不是致命缺陷，但是要想让Linux巩固现在取得的成就，并取得进一步发展，这些都需要得以解决。

　　软件包管理各自为政

　　在Linux中，软件通过“包”形式进行管理，包可以指整个应用程序、应用程序的支持库、编程工具等等，举例来说，在多数Linux操作系统中，火狐浏览器和办公软件OpenOffice.org都是以包形式体现在其软件库中。

　　不同Linux厂商的包管理方式也有所不同。红帽使用它自己的RPM系统，Debian有自己的。DEB格式。如果你只使用某一个厂商的Linux，这或许不是一个问题；但是当你需要跨厂商的时候，就会发现这很不方便。

　　这也是为什么很多商用软件厂商难于提供其产品Linux版的原因，没有一种统一的包格式能够克服跨厂商的问题。

　　面临这种情况，潜在应用软件厂商具有三种选择：一是把时间、精力和金钱用在不同Linux系统上，例如让自己的应用可以在红帽、SUSE和Ubuntu上安装和运行；二是只针对某一特定厂商Linux提供其应用；三是提供源代码包，这样用户可以在任何目标平台上自己编译代码。

　　第三个办法肯定不会被任何专有软件厂商所考虑。第一个办法则大大加重了应用软件厂商的工作量，基本也不可行。这样就仅仅剩下了第二个办法，既可以让用户能够迅速使用其应用程序，也降低了用户安装应用程序的工作量。

　　目前来看，Linux系统上的商用软件需求还相对较少，解决这一问题的重要性还不是那么明显。但是从长远来看，当商用软件越来越多的进军Linux市场的时候，这无疑是Linux的一个很大的缺陷。一个可能的解决办法是，采用一种元包（meta-package）格式，用户下载了这种格式的文件后，使用本地软件将其处理成可以在指定系统上安装的包。目前BitRock有一个类似的工具，可以将一个开源应用打包成一个可在多平台上安装的程序，其中也包括对Linux的支持。

　　另一个解决此问题的主要方法是通过Linux标准库（Linux Standards Base，LSB）。为了兼容LSB，Linux厂商必须同时使用或支持红帽的RPM.由于目前最流行的Linux系统是基于Debian的Ubuntu，它对RPM的支持并不好，因此业界人士批评LSB过于以红帽为中心。

　　配置文件语法混乱

　　任何一个Linux都是多个组件和模块聚合起来的，这些软件来自成千上万个不同的程序员、项目和设计机构。这种情况导致了所有Linux系统都没有或很少集中配置功能，系统中的每一个模块都是通过一些杂乱无章的文件来进行设置，没有什么规定来约束和指导配置文件的语法。

　　如果你在工作仅仅用到少数几个配置文件，并熟悉它们的内部格式，或许不会明显的感觉到这个问题，但是这并非一个可以让人接受的解决方案。造成该问题根源是，多数应用希望保持与老的UNIX应用的兼容。

　　从内核到用户工具和应用程序，Linux整个系统内需要一个一致的配置系统。除了便于用户（以及程序员）易于使用外，还可以简化集中管理的问题。

　　仅仅通过规定实现这样的事情几乎是不可能的；更好的方法是，普及推广一个可以让应用程序配置更简单的工具，从而实现统一的配置方式。GNOME项目的Gconf就是这样的一个工具；尽管目前该工具的设置对象只是用户习惯设置，而并非系统范围内的配置选项，它依然为我们解决配置文件问题带来了很好的启示。

　　内核应用二进制接口

　　一直以来，在Linux开发领域，人们对内核应用二进制接口（Application Binary Interface，ABI）抱怨甚多。

　　Linux内核设计的思路是，在内核内部可以修改很多内容，但是用户应用一定不要通过ABI去修改内核。这个问题不仅仅是理论性的，在实际开发中也是切实存在的：内核接口范围的存在意味着，违背其规定的某些操作完全有可能发生，有时候即使通过非常严谨的代码查阅也无法发现问题所在。

　　这样，当违背规定的事情发生时，它将带来两个问题：它可能让你无法确认一个问题的真正导致原因（例如它是一个内核的问题还是一个用户应用的问题？）；另外你需要花费时间和精力来修复它。

　　目前有一些方法来临时解决这个问题。对于某些项目来说最迅速有效的办法之一就是用户空间文件系统（Filesystem in Userspace，FUSE），它是Linux系统平台上可加载的内核模块，允许非特权用户创建功能完备的文件系统，而不需要重新编译内核。FUSE模块仅仅提供内核模块的接入口，本身的主要实现代码位于用户空间中。但是，从长期来看，Linux需要一个既稳定又能满足长期增长需要的ABI，并且不会成为造成潜在兼容性问题的老鼠窝。