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

点评Linux难称完美的几大命门作者: CNetNews, 　出处:CNetNews,　责任编辑: 罗丽艳,　2008-12-31 09:34　　从1991年到2008年，Linux已经走过了17个春秋，但它依然是一个正在发展中的作品，依然难称完美，还有好多方面需要完善，虽然不是致命缺陷，但是要想让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，并且不会成为造成潜在兼容性问题的老鼠窝。
　　原生文件版本管理(Native File Versioning )
　　原生文件版本管理是另一个可以加入到Linux的功能，但是至今为止还没有被默认加入到Linux中。其概念非常简单：在一个文件当前版本被覆盖或破坏的情况下，用户可根据需要恢复到早期的任何一个版本。Windows用户现在通过影子复制的形式可以体验这个功能，但是在标准的Linux文件系统中目前还没有该功能的具体体现。当然，它不能取代文件备份，但是可以把一个文件回滚到过去某个时刻的功能还是有它的用武之地的。
　　现在你可以手动的向Linux中增加这个功能。有些不同项目也已经使用略有不同的方式来实现了这个功能，诸如Wayback、ext3cow、copyfs和Tux3等等。尽管有人称这个功能可以通过非内核插件来实现，但是如果能有一个标准的、“内核安全的”方法来实现版本控制，无疑是更好的选择。
　　我认为，未来的Linux文件系统(或许是即将到来的BTRFS)将完全解决这个问题，但是目前还没有直接的解决方案开始解决这个问题。
　　音频应用程序编程接口(API)
　　厨师太多可能熬坏一锅好汤，用这个例子来说明Linux音频实现的现状再恰当不过了。多个音频API和子系统意味着，你可以随便选择一个来满足自己的需要，但是它也同时意味着，你将面临兼容性的问题。
　　内核级的音频API，也就是ALSA，是多数情况下应用程序的首选。但是除了它之外，还有很多其它音频API，例如最初的PulseAudio，主要用于混合来自多个应用程序的音频;还有JACK，用于实现低延时的专业音频。在今年9月份的Linux Plumber大会上Don Marti很好的总结了该问题所带来的冲突，他表示，“如果有人来问我，‘我想编写一个音频应用程序，我应该使用哪一个API?’我无法给出一个很好的答案。”
　　简而言之，音频API问题困扰着编程者，也困扰着用户。或者说，任何影响程序员的问题从长期来看也将影响终端用户。PulseAudio或许是最通用的解决方案，其应用范围也最广。但是从长期来看，应用程序开发者需要的是一个内核级的音频访问方式。
　　图形用户界面问题
　　对于内核来说，需要增加什么功能自然是Linus和内核开发者说了算。但是对于Linux桌面来说，却没有什么规定可言。
　　在进一步阐述前，我要首先解释清楚一个概念。“桌面”不仅仅指那些让非技术用户更轻松使用Linux/FOSS的任何图形化用户界面，而是指一个可以让你更轻松使用和管理系统的图形化用户界面，不管你的技术能力处于哪一级别。
　　这不是一个将图形化用户界面完全与系统整合在一起的问题。Linux中的内核和桌面开发是以高度并行的方式进行的，它以一个单向引导的方式进行。没有人保证内核开发者会实现对桌面开发者有用的功能，但是桌面开发却必须根据内核功能来修改自己。
　　这样，就需要一个指导委员会对所有运行在Linux上的图形化用户界面进行指导，无论创建任何图形化用户界面，不管它们是GNOME，还是KDE或其它尚未发明的桌面，它们都必须具有对后端内核功能的一致性实现，使它们能够紧密结合内核的功能。内核应该发布一个图形化用户界面可以使用的功能列表，然后图形化用户界面可以通过不同的方式来将其展现给用户。
　　Linux需要做的另一件重要的事情是，需要有一个清晰的规则来指导如何使默认桌面设置更符合用户习惯，这需要设计者具有用户界面设计经验。这并不是说用户界面要“简单化”：通常需要的不是更简单的控制，而是这些控制更好的默认处理方式，这样用户无需进行麻烦的调整就可以获得最方便的设置。
　　X11与应用程序的集成
　　大多数人用过Linux一段时间后，可能会遇到这样一个问题：一个X11应用，或X11自身，会出现不响应的现象，唯一的办法就是关闭并重启X11。尽管这个操作并不复杂，但是关闭X11就意味着每一个其它X11应用都会受牵连，也会被关闭。
如果可以选择保留运行在X下的应用，那么当X需要被关掉和重启时，你就不会丢失你的整个用户会话了。如果不能实现这一点，也可以通过一个窗口管理API来允许轻松存储和恢复崩溃事件中的会话，这也是非常有用的一个功能。
　　商业化备份恢复解决方案支持
　　如果Linux希望继续吸引普通的PC用户从Windows转向自己，它需要具有Windows中的许多类似功能。其中包括支持Linux客户端的付费网络服务，诸如远程备份等。
　　Windows和Mac用户具有众多选择：这两个系统中的本地文件和系统级别的备份和恢复都可以通过众多商业化备份解决方案所实现。诸如Mozy和Carbonite之类的服务可以进行安静、加密的差异化备份到远程主机，因此用户的数据可以被连续保护并离线保存。但是这些服务都不支持Linux客户端。
　　Linux用户如果希望执行离线备份，通常要借助于本地Linux应用程序，诸如Ubuntu中的简单备份工具，来备份到一个并非专门用于数据保护的远程服务器。实际上并不缺少可以与远端服务器进行会话的Linux备份客户端，例如在Ubuntu中就有简单备份套件，但是对普通用户来说，却缺少一个与商业化备份提供商整合的应用。
　　一种可能发生的事情是，随着一切变得与平台无关，所有数据的备份都将可以通过特定Web浏览器来实现。另一种更可能发生的事情是，专门支持Linux客户端的完整状态备份服务将会出现。
　　结论
　　本文中所提到的所有Linux缺陷都不是致命的，否则Linux就不会取得今天的成绩。但是毫无疑问，这些问题都需要被改进，这可能需要改变某些传统的Linux功能设计思路，只有保持不断革新、去伪存真，才能让Linux真正成为一件完美的产品。