主题：【原创】基于Linux内核的开放源代码操作系统的组成：第一篇 -- 请尽量

第三篇 图形界面（下）：GNOME

先补充一下上半部分遗漏的三点。

第一，X Window System不是Linux唯一可用的图形界面，虽然它是目前最完善、最稳定的。Linux有一个在内核里的图形设备子系统，称为framebuffer。其概念很简单，就是把一个特定分辨率的display上的内容（也就是一个frame）映射到内存中一段连续的内存地址（一个buffer），在屏幕上输出就是改变buffer内某些字节的值。所有符合VESA 2.0标准的显卡都可以使用framebuffer。Framebuffer虽然在2.4版上就出现了，到了2.6版依然是experimental。当然，对一些简单的的图形操作，例如用来在系统启动时显示splash screen和图形化的系统启动进度等，framebuffer还是足够胜任的。对于一两种特定的显卡，framebuffer有2D和3D的硬件加速。有人还把GDK移植到了framebuffer上，某些特殊的设备，如机顶盒等，可以利用framebuffer，省下了X Window System的overhead。

除了X11和framebuffer，还有一些专门针对需要图形显示的手持设备开发的图形环境，例如Nano-X（原来叫Microwindows）等。

第二，GTK+有一个值得说一下的特点，就是所谓的language bindings。虽然GTK+本身是用C语言写的，但是在设计API时，特别考虑了要方便其他“高级”编程语言使用GTK+。现在与C语言API保持同步的language bindings包括：C++、Java、Python、Perl。当然还有的编程语言接口，如Ada、C#、Ruby、Haskell等，虽然没有得到GTK+开发人员的“official blessing”，但也都基本保持与C语言API同步。其中值得特别提出的是C#的binding，GTK#，得到了越来越多的关注。

第三，X Window System和GTK+都有自己的输入方法机制用于多种字符集的输入。X Window System的输入方法一般简称统称为XIM，其协议或标准的历史大概和X Window System本身一样古老。目前大部分的中文输入法都是基于XIM的。GTK+自己的输入方法称为IMModule（大概可以翻译为输入方法模块），以共享库（Windows上的DLL）的形式安装到系统上，具体细节我就不得而知了。我正在使用的于明俭开发的SCIM对这两种协议或标准都支持。

好了，现在回到下半部分的正题上。在介绍了X Window System和GTK+后，我们来介绍一下桌面环境（desktop environment）。在早期（其实也就是五、六年前吧），Linux的桌面给用户的感觉就像个大杂烩，不多的几个应用程序，还各有各的风格：快捷键不统一，菜单条的安排也各不相同，一个对话框里的OK按钮在Cancel按钮的右边，另一个确跑到了左边。为了改变这种局面，给用户一个统一的观感（look and feeling），人们开始考虑“桌面环境”的概念，试图为应用程序员提供一个应用编程框架，即保证了整个系统范围内的统一风格，也简化了应用程序员的工作。当然，这个概念并不新奇，其他操作系统，如Windows和Mac都已经在这么做了。

首先出现在Linux操作系统上的桌面环境是基于Qt的K Desktop Environment，简称KDE。由于一开始Qt的软件许可不符合真正的自由软件的定义，人们开始担心Qt背后的公司TrollTech可能会影响甚至控制KDE，虽然KDE本身是用GPL发布的。在劝说KDE的主要开发人员改用其他toolkit失败后，GNU和一些具有同样顾虑的程序员开始了一个称为GNU Network Object Model Environment的项目，简称GNOME，目的就是取代并干掉KDE。后来TrollTech在Linux上用GPL重新发布了Qt，算是解决了一个困扰free software community多年，并引起了诸多纷争和骂战的问题。但是KDE和GNOME这时都已经达到了相当规模，并各自拥有了数量庞大的用户。这就是为什么Linux会有两个并行的桌面环境。当然，现在两个项目之间的关系已经变成了友好的竞争，两者设定标准等问题上也很合作。

一个典型的GNOME桌面环境包括了一个文件管理器（file manager）、一个窗口管理器（window manager）、一个panel程序和一个控制中心（control center）和一堆应用程序。GNOME同时还是一个应用程序开发平台，通过一系列的程序库，向应用程序员提供了一个编程框架（framework），除了对话框（dialog boxes）、菜单条（menu bars）、工具条（tool bars）、文档（document）等高层次的控件，还有对话管理（session management）、配置管理（类似Windows的registry）、打印机管理、虚拟文件系统（virtual file system）、拖放（drag and drop）等。更为重要的是，GNOME制订了一套Human Interface Guidelines（简称为HIG）。如果所有在GNOME环境下的应用程序都能够遵照HIG来设计实施用户界面，那么这个桌面环境就会有一个统一的风格和观感，极大地方便普通用户。GNOME的核心技术包括：GTK+（图形界面toolkit），CORBA（进程间通信机制，类似于Windows上的COM），XML等等。

由于Linux是个多用户操作系统，用户必须经过系统的认证（也就是通常所说的登录），才能进入系统，并访问系统的资源。在X11环境下，用户认证是由display manager完成的。X11常见的display manager有XDM、GDM和KDM。XDM用的是XLIB，功能简单、可靠，但是最“难看”。GDM使用GTK+，可以和GNOME的风格保持一致。KDM配合KDE，是用Qt开发的。其实display manager和接下来的session没有必然的联系，完全可以用GDM来启动一个KDE session，或者用KDM来启动一个GNOME session。

最新版本的GDM支持类似Window XP登录画面的所谓“全图形化”的界面。由于X11内置的对网络的支持，GDM不仅可以在本机上启动一个session，还可以与运行在其他机器上X服务器程序连接，在远端机器上启动一个session。当然，出于对安全性的顾虑，绝大部分Linux distros缺省情况下都不允许其他机器上的GDM连接到本机的X服务器程序上。

一个典型的GNOME session启动后运行的程序包括在屏幕顶部和屏幕底部各有一个panel，一个文件管理器（表现为桌面背景和背景上的图标）和一个窗口管理器。两个panel加起来类似于Windows屏幕底下的那个“启动”菜单条。在上方的panel的左边是系统菜单，右边是一系列的“小程序（applets）”，如所有窗口的列表、时钟和日历等。在中间通常是一些常用的应用程序的启动图标。在下面的panel上，一般有两个小程序。一个称为workspace switcher，显示所有工作空间（workspaces）和在各个工作空间内打开的窗口的微缩图标。另一个小程序把每一个当前工作空间内打开的窗口显示为一个按钮，点击某个按钮相当于激活对应的窗口并把该窗口置顶。其实，panel不是必须的，所有的小程序也是供挑选的。各人习惯不同，对panel的设置也不一样。我的桌面上只有一个panel，把所有的小程序都挤到了上方的panel里。

GNOME的文件管理器叫Nautilus，最早是由一个叫Eazel的公司开发的。Eazel的计划是用GPL作为软件许可，发布Nautilus的源代码，借助GNOME community加快开发，然后再靠卖某种subscription来挣钱。不幸的是，Eazel的商业计划没有成功。Nautilus 1.0版如期发布了，Eazel也用光了所有的资金。正巧赶上了dotcom bust，Eazel找不到第二轮投资，只好关门大吉。庆幸的是，由于Eazel选择了GPL，其他的GNOME开发人员尽可以在已经发布的Nautilus源代码基础上继续下去。

在设计上，Nautilus参考了Windows的Explorer和Mac的Finder。每个目录就是一个文件夹，可以有多种视图（views）。内置的视图有icon view和list view。Nautilus还可以通过插件（plugins）来增加其他视图，例如字体文件预览视图、CVS的checkout视图。Nautilus同时也是一个（图形化的）shell和application launcher，可以启动其他应用程序。对每一种文件类型的预览（preview），也可以通过第三方（通常是相应的应用程序）来完成，例如可以给每个音频和视频文件图标加上播放键，当用户点击后直接播放该音频或视频片段。

由于GNOME的虚拟文件系统隐藏了各种文件访问机制的区别，除了可以管理本地硬盘上的文件外，Nautilus还可以连接到文件服务器上，管理远端的共享文件系统。Nautilus支持的共享文件协议包括：CIFS（Windows和Samba）、FTP、WebDAV和SFTP等等。更多的共享文件协议还可以通过第三方插件来实现。无论是本地还是远端的文件系统，Nautilus都可以一致的方式来打开文件夹，进行各种文件操作。当然在某些情况下，远端文件系统会比本地文件系统慢。

Nautilus还有一个插件用于生成符合ISO9660标准的CD映像，并烧到CDR和CDRW上。在目前，Linux上CDR和CDRW的制作还主要依赖命令行程序来完成。现有的图形界面的程序实际上都是用命名管道等进程间通信机制，执行命令行程序实现的。2.6版的Linux内核增加了packet writing模式，使应用程序不必事先完全准备好CD映像再一次性地烧制到媒介上（disc-at-once或者track-at-once），这样应用程序可以象写普通硬盘一样的往媒介上添加内容。另外，在user space，一个更加完善的、主要针对图形环境的开放源代码的CD制作程序库项目已经取得了进展。

GNOME的窗口管理器叫Metacity。一般来说，普通用户不需要知道窗口管理器是什么，是怎样运行的。X Windows System的窗口管理器运行在“幕后”，自身没有实实在在的用户界面。但是，所有的窗口都受其管理。窗口管理器实际上影响着图形环境一部分重要的行为（behavior）表现。窗口管理器掌握着各个窗口在屏幕上的位置，以及相互之间的关系，例如，一个窗口的掩盖住了另一个窗口的一部分。如果某个应用程序更新了一个窗口的内容，或者用户移动某个窗口的位置，窗口管理器可以计算出哪些窗口的内容需要在屏幕上重新绘制。

类似于Windows的控制面板（control panel），GNOME的控制中心提供了对桌面环境各个方面的配置选项，如屏幕背景、菜单字体、控件和窗口的主题（themes）、键盘、鼠标、全局快捷键、屏保程序，等等。和控制面板不同的是，GNOME控制中心只对当前用户起作用。所有与整个系统有关的配置，如网络、时钟、用户等都需要由其他的程序完成。传统上，这样的工作都已经有相应的命令行工具，一定程度上满足了需求。但另一方面，由于在设计的时候并没有考虑到有朝一日会需要在图形界面下完成同样的工作，这些命令行工具很难被无缝地集成到图形界面中。至少对GNOME，情况开始有改善。一个称为“GNOME System Tools”的程序已经涵盖了很多这里提到的系统管理方面的工作，还有更多的模块正在开发中。

如果继续用在第一篇中的“同心圆”划分方法，以上介绍的几个GNOME核心程序（Nautilus/Metacity/Control Center）可以看作是和第二篇中的bash处在同一层，都提供了一个用户界面用以启动其他应用程序，X11、GTK+和GNOME的程序库则可以看作在libc和GNOME核心程序之间一个“亚层次”。接下来要介绍的应用程序就是最外面一层了。

首先要介绍的当然是web browsers。GNOME有三个浏览器：Galeon、Epiphany和Firefox。所有这些浏览器其实都是基于Mozilla的Gecko rendering engine，只是用户界面不同罢了。Galeon是第一个专门为GNOME开发的浏览器。在Mozilla 1.0版刚刚推出的时候，Mozilla自己的用户界面和GNOME的风格大相径庭。Galeon用GNOME自己的控件取代了Mozilla的XUL控件。在Galeon出现的时候，GNOME还没有确定自己的Human Interface Guidelines。当GNOME制订了HIG以后，Galeon的开发人员在发展方向上出现了分歧。于是，Epiphany出现了。在Galeon的基础上，Epiphany依然使用Gecko，但是用户界面严格遵循GNOME的HIG。严格来说，Firefox还不能算是GNOME程序，因为其用户界面并没有完全满足HIG的要求。但是，由于遵循HIG是Firefox在Linux操作系统上的一个目标，并且也取得了很大的进步，我们姑且认为Firefox是个GNOME程序吧。

一个高质量的电子邮件程序的重要性不亚于一个好的浏览器。所幸的是，GNOME的电子邮件程序完全可以称为“高质量”。Evolution最初是模拟微软的Outlook，包括了电子邮件、日历安排和地址簿的功能，也就是所谓的个人信息管理器（personal information manager）。Evolution有着Outlook所有的功能，但是没有Outlook上的病毒和蠕虫。最新版的Evolution把这几大部分功能又拆开来，这样每个用户可以只安装自己需要的部分。

GNU Image Manipulation Program（简称GIMP）可以说是Linux上最著名的一个应用程序了。GIMP的历史要比GNOME甚至GTK+还要久远。在上部分介绍GTK+时，我们就提到过GTK+名字中的字母“G”的来源就是“GIMP”中的“G”。和其他商业软件如Adobe Photoshop相比，GIMP还有差距，仍然欠缺某些功能，特别是针对专业用户的高级功能，如颜色管理等。但对于大部分的图片编辑工作，GIMP已经足够胜任了。由于GIMP的用户界面已经形成了自己独特的模式，GIMP并不完全遵循HIG。但是在尽可能的范围内，GIMP的开发人员还是在逐步地向HIG靠拢。GIMP有两种扩展功能的方式。一种是用C语言开发的插件，一般用于复杂的或计算量大的任务。另一种是用GIMP自身内置的scripting语言，一般用于完成高度重复性的任务。

在计算机上，各种图形、图像可以归为两大类：点阵（bitmap或raster）和向量（vector）。各种数字相机产生的数字照片就是最典型的点阵图像。常见的点阵图像格式包括JPEG、TIFF、PNG、GIF等。向量图形则一般是由线条构成的各种drawings。Adobe的Illustrator大概是最有名的向量图形编辑程序，W3制订的SVG标准大概是最有名的向量图形格式了。GIMP主要用于编辑点阵图像，例如校正照片的暴光、颜色等。在GNOME下向量图形编辑的首选应该是Inkscape。Inkscape的历史并不长，大概就两年。GNOME下最早出现的向量图形编辑程序叫Sodipodi。在发展到0.31或0.32版的时候，开发人员之间产生了分歧，一部分人以Sodipodi的0.33版为基础开始了Inkscape，所以Inkscape的历史是以0.34版开始的。需要特别提出来的是，Inkscape大概会成为GNOME下最出名的C++程序了（Firefox的Gecko engine是用C++开发的，但是Gecko在Linux上却是用的GTK+的C语言API来进行绘制的）。虽然Sodipodi是用C语言开发的，Inkscape的开发人员选择了GTK+的C++ binding，gtkmm（来自于GTK minus minus，也就是GTK--）。从0.34版到目前的0.41版，Inkscape在逐渐地用C++和gtkmm来替换从Sodipodi继承来的C和GTK+代码。

在说起播放DVD、VCD和MP3等数字化多媒体前，得先提一下Gstreamer，一个“野心勃勃的”多媒体流处理框架。Gstreamer开始于两个（或一个）大学生的研究课题，在体系机构上与第二篇中提到过的命令行管道很相似。对一个媒体文件的处理（播放、转换、合成、分解等）可以由一系列首尾相接的过滤器（filter）来完成，每个过滤器只负责完成一个特定的工作。比如，要播放一个MP3文件，一个“读文件”过滤器把该文件以流的方式从硬盘读入并传递给后面的过滤器。接下来的一个过滤器就是MP3的解码器，把MP3还原为（比方说）WAV格式，然后在继续传递。最后一个过滤器专门负责把WAV数据流转换为某种特定的声卡所支持的信号并写到声卡设备。如果把读文件过滤器换成从接收网络传输，那么就实现了MP3的Internet streaming。要播放其他格式的音频文件如微软的WMA，只需要把MP3解码器换成WMA解码器。甚至最后的过滤器也可以替换，比如换成从WAV到WMA的编码器，再加上一个写文件的过滤器，就可以完成从MP3到WMA的转换（当然，由于MP3是有损压缩，这样的转换在实际使用中不会多见）。

这样，对各种媒体格式的支持就与实现各种处理不相干了，由此实现了最大的灵活性。一个基于Gstreamer的应用程序的核心任务就简化为选择过滤器，并构建成合适的处理管道。Gstreamer使用C作为开发语言，利用了GLIB提供的面向对象机制、基础数据结构和其他utility routines。GNOME确定了以Gstreamer作为多媒体处理的核心机制，Gstreamer的核心部分和所有的过滤器都以共享程序库的形式正式成为了GNOME的一部分。

GNOME的DVD和VCD播放器叫Totem。Totem开始的时候只是为了一个叫Xine的开放源代码DVD/VCD播放器提供一个GNOME风格的用户界面。随着Gstreamer的成熟，Totem也增加了对Gstreamer的支持。当然，GNOME下还有其他的DVD和VCD播放器，但由于Totem是专门为GNOME开发的，其用户界面风格和观感也最符合GNOME的HIG，所以Totem就成了GNOME的正选DVD和VCD播放器了。

另一个使用Gstreamer的应用程序是Rhythmbox，一个数字化音乐播放器，支持管理和播放MP3、OGG、FLAC格式的音频文件。当然，支持Internet streaming对于使用Gstreamer的应用程序可以说是举手之劳，Rhythmbox自然也能播放由其他机器stream的音频流和Internet radio。这里要提一下，在Rhythmbox之前，GNOME的音乐播放器是XMMS。但是当GTK+的2.0版发布后，XMMS的开发人员拒绝把XMMS移植到新版本的GTK+下。另外，XMMS的用户界面也与GNOME的HIG相去甚远。再加上Gstreamer的日益成熟，Rhythmbox出现了并填补了XMMS留下的空间。

在GNOME下还有一个使用Gstreamer的应用程序叫Sound Juicer。这是个所谓的CD ripper，就是从音乐CD上把sound tracks“抓”出来，以WAV、MP3或其他的格式存放到硬盘上。这里卖给关子，大家可以想一下如果要把一张音乐CD变成一堆MP3文件，Sound Juicer应该怎样构建Gstreamer处理管道。

这里要提一下Linux内核最近为提高音乐播放质量所做的努力。播放数字音乐实际上是一种实时（realtime）应用，对处理器速度和系统的输入输出要求不高，但是对延迟（latency）和可预见性（predictability）非常敏感。对于多进程的操作系统来说，公平地在各个进程之间分配处理器时间是非常有挑战性的。有些程序对处理器要求高，有些应用更需要输入输出。过于频繁地切换进程，会影响系统的吞吐量。但如果容许某些进程长时间地占用处理器，会使系统对其他进程表现为延迟增加、可预见性降低。在播放音乐时，延迟超过一定限度就会出现人耳可辨的glitches。

在2.6版前，Linux的用户进程调度虽然是抢占式的（pre-emptive），但内核本身却不是。一个内核线程可能因为某种原因没有及时地让出（yield）处理器，其他等待处理器的进程虽然轮到了时间片，却没法“抢”过处理器。为了提高Linux在实时系统中的可用性，2.6版的内核也成了可抢占的。当然，这只是其中一个方面。2.6版的内核还引入了模块化的输入输出调度算法，用户可以在机器启动的时候选择适合系统典型应用的调度算法。内核中的“加锁（locking）”的粒度也在变得更精细（finer），使得内核线程需要等待其他线程释放系统资源的情况减少。此外还有其他很多的改进，例如更高效的内存管理，大幅度减少了对swap的使用，都直接或间接地改善了Linux对实时应用的支持。

说完了DVD、MP3，下面来说说相片管理。数字相机的普及意味着越来越多的数字相片需要操心：分类、加注释、备份、作幻灯展示（slide show），等等。gthumb就是GNOME下完成这些工作的相片管理程序。得益于Linux对hotplug和USB的支持，通过gphoto程序库，gthumb可以直接从数字相机中读取数字相片。gthumb还能从相片中读取EXIF信息。和其他商业软件相比，gthumb最欠缺的功能应该是对RAW格式的支持。但由于RAW格式是各家数字相机厂商自己专有的格式，没有公开的格式规范和许可，gthumb的开发人员无法完成这一任务。幸好眼下JPEG对普通的摄影爱好者已经足够了。

其他值得提出的应用程序有字处理程序Abiword和表格处理程序Gnumeric。由于微软Office的流行，这两个程序的开发人员都把对微软格式的兼容作为最重要的功能之一。但是，由于微软一直在与这样的第三方程序开发人员玩着“猫捉老鼠”的游戏，对于微软格式的兼容看起来会成为一项长期任务。和微软的Word相比，Abiword大概覆盖了80％到90％的功能，也完全可以胜任80％到90％的文字处理工作。当然，欠缺的那10％到20％是所谓的企业级应用，例如协作（collaboration）等，还有类似VBA那样的内置scripting语言。

经过几年的努力，Gnumeric已经实现了对所有Excel functions的完整支持。对数据的分析功能也日臻完善，包括了solver、goal seek、scenarios等。但是，对于类似pivotal table那样的复杂报表处理，in-cell formatting，还有图表（charting、plotting），Gnumeric还有很长的路要走。

OpenOffice.org的OpenOffice虽然可以运行在GNOME下，但并不能算作是GNOME程序，OpenOffice甚至没有用GTK+作为GUI的toolkit。

在GNOME下当然还有很多其他精彩的应用程序，例如可以画出函数坐标曲线的图形计算器、Linux内核网络防火墙的配置程序、类似微软的Project的项目规划程序，等等。篇幅所限，这里就不一一介绍了。有兴趣的话，可以在下面给出的网站gnomefiles.org找到更多的信息。

GNOME只是众多基于X11的图形环境中的一个，其他的图形环境包括KDE、Xfce、WindowMaker、AfterStep、Enlightenment等。KDE和GNOME一样是个完整的桌面环境，也有着众多的应用程序，基本上与GNOME在Linux distros中各持牛耳。其他图形环境的规模相对就要小一些，应用程序少，用户也少一些，但都有各自的特点。

最后，列出一些和X11、GNOME有关的网站地址：

x.org - X Window System的“新家”

freedesktop.org - 很多与图形界面有关的开放源代码项目以此为家

gtk.org - GTK+的官方网站，但是更多关于GTK+的信息可以在gnome.org找到

gnome.org - GNOME的官方网站

gnomefiles.org - 收集了几乎所有GNOME和GTK+程序发布的信息

第三篇 图形界面（上）：X Window System和GTK+

与Windows不同，Linux的图形界面是可选的（不知道Windows XP Embedded Edition是否可以配置成只有字符界面的），所以在嵌入式系统和服务器上，系统的资源如内存等可以节省下来。似乎是UNIX的一个传统，Linux也依赖于X协议（X Protocol）提供图形用户界面。X协议出现于上个世纪八十年代，其目的就是为UNIX操作系统提供对网络透明的（network transparent）图形用户界面。记得我第一次接触X是在大学的SUN工作站上，那也是我第一次看到计算机图形界面。那是个黑白灰度级（gray scale）的图形终端，通过X协议连接到空调机房里的SUN工作站上（不记得是SUN2还是SUN3了）。看着高年级的学长在用鼠标玩国际象棋，我想我的嘴当时一定是没有合拢的。

X协议采用了客户/服务器的体系结构。各个应用程序就是客户端，发出作图请求。服务器端（又称为display）收到作图请求后，把绘制好的图形输出到屏幕上，另外还把来自键盘、鼠标、数字化仪等设备的输入传递给应用程序。在X协议刚刚出现的时代，计算机的处理能力和图形终端都是稀有的资源。为了充分利用这些计算资源，X协议的体系结构使得图形应用程序可以在具有强大计算能力的工作站上运行，通过网络把作图请求发送到图形终端上输出。这样，各种应用程序，图形或字符界面，都可以在工作站上运行，利用其计算能力。同时，有限的图形终端也可以为多个工作站共享。

在客户端，X协议的底层被抽象、概括为一个程序库，通常称为XLIB。XLIB向应用程序提供了各种的绘制原语（drawing primitives），并将来自于鼠标、键盘等设备的输入映射为事件（events）。大体上说，应用程序在一个事件循环（event loop）中接收并处理自己感兴趣的事件，调用作图原语函数进行作图。在一个统一的应用编程接口（Application Programming Interface）下面，异步网络通信、输入和输出设备的差异等都被XLIB巧妙地隐藏起来了，这样不仅简化了应用程序，还有较高的可移植性。

实现X协议的软件系统，包括客户端的XLIB和服务器端的设备驱动程序，统称为X窗口系统（X Window System）。大概由于是微软的Windows的普及，很多人，包括一些IT从业人员，都错误地把X Window System叫成了X Windows System。

当强大的计算能力和图形显示成了每个PC都必须具有的卖点后，X协议并没有落后于时代。首先，服务器端，包括图形控制卡、键盘、鼠标等设备驱动程序，从独立的图形终端上移到了PC上，成为了运行在本机上的一个服务器程序，而不再是一个实实在在的机器。而应用程序依然向以前一样，通过XLIB向服务器端发出作图原语。由于现在服务器和客户都在同一个操作系统上，各自作为一个进程运行，XLIB使用UNIX socket而不是TCP socket在两者间进行作图原语和事件的传输。也就是说，应用程序并不用修改，只要在启动时指定运行在本机上的X服务器进程作为自己的display就可以了。

当然，XLIB仍然可以继续使用网络来传输作图请求和输入事件。两个安装了X的PC在连上网络后，一个可以成为另一个的display。这个feature在某些特定的场合非常handy。例如，结合netboot和NFS，把廉价的或淘汰的PC改造为无盘图形终端，用在图书馆、学校等预算有限，又需要严格控制的公共场合。

在2004年以前，XFree86（）是Linux和其他开放源代码操作系统的首选X Window System。由于这是唯一的一个成熟稳定的采用开放源代码许可的X Window System，几乎所有的Linux distors都使用XFree86，直到其4.3版。在很长一段以来，XFree86的用户对于xfree86.org的自我任命的Board of Directors抱怨甚多。认为他们与现实脱节，保守僵化，在开发管理中独断专行，没有积极相应用户的要求，事实上阻碍了XFree86的发展。很多Linux distros更是认为XFree86的种种不足成了Linux向桌面系统进军路上的绊脚石。在2003年，xfree86.org内部对于产品发展方向、开发管理等问题产生了分歧，一部分开发人员和积极分子（active contributors）分裂了出去。在2004年初，xfree86.org的Board of Directors在发布4.4版前对其软件许可做了修改，给开放源代码操作系统再发行（redistribute）XFree86的4.4和以后版本造成了很大困难。绝大部分的Linux distors决定了将不使用4.4和以后版本的XFree86软件。

XFree86的异见分子们（dissidents）最终加入了X.Org。在HP、SUN、IBM的赞助下，X.Org以原来的XFree86版本4.3为基础开发了X.Org版本6.8.0。由于X.Org保持了XFree86原来的软件许可，并且在开发管理中更加开放，对于采纳新技术、新思想也更为主动、积极，各个Linux distros几乎是立即投入了X.Org的阵营。

在经过了二十多年的发展，X协议目前的版本是11R6.8。因为这个原因，人们经常又把X Window System简称为X11（由于介绍的是开放源代码的X Window System，下面出现的X11都指XFree86或X.Org）。一个符合目前这个版本的X Window System包括了在客户端的XLIB、在服务器端的输入输出设备驱动程序、管理display上各个window的windowing manager、和各种各样的extensions。现在X11系统的发展，基本集中在增加新的extensions和完善对各种显卡的支持上。比如，对TrueType字体的支持、对全屏幕视频播放的支持、对双显示器的支持、对direct rendering infrastructure（简称DRI）的支持等等。DRI提供了对显卡图形硬件的直接存取，可以大大提高2D和3D的绘图速度（Linux内核专门增加了设备驱动程序用于支持DRI）。

和其他硬件设备的开放源代码驱动程序一样，X11的显卡设备驱动程序也面临着硬件厂商不愿意或无法（受限于所采用的第三方零部件的许可协议）披露硬件设备接口规范的问题。各个厂商最新型的显卡往往都无法立即得到支持，或者是只有部分的支持，比如，没有3D的硬件加速（意味着无法玩最新的video games）。一种解决办法是当这个问题不存在，宣称自己不是gamer。另一种办法是使用厂商发布的closed source的设备驱动程序。两种办法其实都没有彻底解决问题。第一种办法是回避。意味着花几百美元买来的显卡却不能完全发挥作用。由于硬件厂商，特别是ATI和NVIDIA都把Linux当作二等公民对待，尽管时不时地发布closed source的Linux设备驱动程序，当无论稳定性、速度还是功都总是比不上Windows和Mac版的设备驱动程序。

X11对除了显卡外的其他设备的支持还算可以，比如USB鼠标、所谓的多媒体键盘、手写板（tablet，不是tablet电脑）等都基本支持。当然，和显卡一样，X11对这些设备支持也需要Linux内核的相应设备驱动程序，比如USB、串行口等等。

因为直接使用XLIB进行编程非常繁琐，于是人们为常见的图形用户接口编程工作开发了GUI toolkit。在Linux上，最流行的两个GUI toolkit是TrollTech的Qt和GNU的GTK+。由于我一直以来用的都是基于GTK+的GNOME，对Qt和基于Qt的KDE无甚了解，这里就着重讲一下GTK+。

GTK+源自于GIMP，GNU Image Manipulator Program，一个可以媲美Adobe Photoshop的开放源代码图象编辑程序。GIMP可以说是Linux上的第一个，可能还是最著名的killer application。GTK是GIMP Tool Kit的简称。和Qt不同，GTK+是用C写的。虽然C语言不是一种面向对象的编程语言，但GTK+的开发人员利用结构、函数指针和强制类型转换，把GTK+弄成了一个面向对象的应用程序库。GTK+由三个部分构成。第一部分是GLIB，提供了某种程度上的面向对象支持，如封装、继承等。GLIB提供的类包括常用的数据结构，如list、hash table、stack、queue，还有常见的其他类型如string、file、thread、date and time等。由于没有编译器的直接支持，GLIB的类其实就是C语言的结构（struct），加上类似于“g_list_append(GList*, gpointer*)”这样的“方法”函数。C++或Java开发人员需要花一些时间来习惯这种“半截”的面向对象编程。第二部分称为GDK，把操作系统提供的图形界面的实现细节隐藏起来，使得基于GTK+的应用程序可以独立于具体的图形界面，比方说X11和WIN32。第三部分就是GTK，提供了常见的GUI控件，如窗口、对话框、按钮、滚动条、下拉菜单等等。用GTK+编程要大量地使用callback。每个GUI控件响应用户的动作，如按下按钮，产生相应的事件，如“clicked”，然后调用应用程序注册的callback。GDK和GTK都使用了GLIB提供的facilities。在具体的组成上，GLIB单独是一个程序库，GDK和GTK通常放在一起，构成另一个程序库。

为了进一步简化应用程序的编程，GTK+的开发人员又提供了一个称为glade的interface builder和相应的程序库。使用glade，应用程序开发人员可以用GTK+所支持的控件在屏幕上“画”出用户界面，并存放在XML文件里。glade的程序库提供了函数可以根据XML文件直接构造出所有的控件，生成用户界面。应用程序因而可以专注于business logic和事件处理机制（callbacks）。

后记：本来这篇还应该介绍一些常用的图形界面的应用程序的。但有关X和GTK的篇幅实在太长，就分成了上、下两部分。

第二篇：命令行界面

以前一提到UNIX，大家自然就会想到命令行界面和那些稀奇古怪的命令名：ls、rm、fsck、dd、ln、tar、more、less、cpio、grep、sed、man等等。基于Linux的操作系统无一例外地继承并发扬光大了这个feature（或是bug，取决于你站在线的那边）。

在进一步深入讨论命令行之前，我们先来看一下Linux的几个核心概念：文件、目录树和文件系统。在Linux看来，几乎所有的操作系统资源都表达为一个一个的文件。每个文件都有一个名字。你的简历是一个叫“resume.txt”的普通文件（regular file），其所在的“Documents”文件夹是一个目录文件（directory），你那个用了三年的IBM硬盘是个块设备文件（block device），上面的每个分区也都是块设备文件，你的PS/2鼠标是个字符设备文件（character device），你刚刚买的USB外接硬盘在连上以后，也是一个块设备文件。除此之外，你可以产生命名管道文件（named pipe）用于进程间通信，还可以生成（symbolic link）或（hard link）指向另一个文件名。除了类型外，每个文件还有一个属性表，包括文件的字节数、其的所有者（用户和组各一个）、存取权限（记住Linux是个多用户系统）、最后一次修改的时间、最后一次访问的时间等等。这些称作“传统”的文件属性。近来，Linux又从SGI等处借鉴了“extended attributes（简称为EA）”这么个概念。在支持EA的文件系统上，每个文件可以有的属性类型和数量都是近乎无限的。比方说，你可以给你的相片加上长长的注解，甚至配上语音的解说。当然，内核不关心具体各个EA的名字和类型，具体的解释留给了各个应用软件。内核只提供一套API用于存取这些EA。

目录在其中最为特殊，因为除了一个文件外，所有的文件（包括目录），必须存在于某个目录中。这样，所有的文件就组成了一个目录树。这棵树的根，就是那个搞特殊化的唯一不存在于任何一个目录中的文件，按惯例称作根目录（root directory），用一个斜线（/）表示。一个文件在这棵树上的位置，可以表达为从根开始所经过的所有目录，又称为该文件的绝对路径名。例如，“/home/qingjinliang/Documents/resume.txt”就是一个绝对路径名，其中，“/home/qingjinliang/Documents”是dirname部分，resume.txt是basename部分。该绝对路径表示在经过根（/）、/home、/home/qingjinliang、/home/qingjingliang/Documents四级目录后，有一个名为resume.txt的文件。由树这种数据结构的特点，我们可以知道：如果要使两个文件具有相同的绝对路径名，那么它们必续存在于同一个目录中，并且有相同的文件名。所以，只要保证在同一个目录下没有相同的文件名，那么我们就可以保证每一个文件都可以由其绝对路径名唯一确定。另外，树上的任何一个目录和这个目录下的内容，也可以看成一个以该目录为根的目录树。

经过这样的抽象，对这些系统资源的操作，可以统一为对文件的操作：产生（creat）、打开（open）、读（read）、写（write）、定位（lseek）、上锁（flock）、关闭（close）、删除（unlink）、改变存取权限（chmod）、改变所有者（chown）等等。当然，每一种具体的文件类型并不支持所有的操作，另外还可以有其特殊的操作。例如，symbolic link没有内容，当然也无法进行读和写操作，但是可以读出其指向的文件名（readlink）。

由于用户大部分的时间都是在与文件打交道，必须在任何时间都清楚自己在目录树上的位置。Linux的每一个用户进程都有一个当前工作目录的属性，可以通过系统调用getcwd得到。方便起见，访问在当前工作目录下的文件不需要使用绝对路径。自然的，如果当前工作目录下包含另一个目录，那么从当前目录访问那个目录下的文件也不需要绝对路径。这样推广开去，我们就有了相对路径的概念，也就是任何由当前工作目录出发的路径。Linux用“.”代表当前工作目录，“..”代表当前工作目录的上一级。

现在回到主题，命令行界面。从上一篇我们知道如果在字符界面下登录进系统后，系统会运行一个shell程序作为用户和系统的接口。这个shell程序接受用户的输入作为命令来执行，并将命令的输出反馈给用户。

在Linux系统下可供选择的shell有bash、ksh、csh等。在桌面系统和服务器上，bash因为功能强大，容易扩展，一般是首选。但缺点是体积庞大、速度较慢。bash最让人称道的一个功能是tab completion。类似于IDE编辑器中的auto completion，在用户按下tab键后，bash可以根据当前命令行的context（上下文环境？来龙去脉？），尝试complete正在编辑的命令或命令的参数。比方说，系统上安装了一个非常fancy的HTML编辑器，你用它来编辑所有的HTML文件。但是该程序的名字很不幸地被安装程序弄成了“cool-html-editor”。如果使用bash，那么你不用每次都输入那么长的程序名。当你在提示符后输入“cool”后，就可以用tab建来提示bash进行completion了。如果在你的程序搜索路径下只有一个可执行文件是以“cool”起头的，bash会自动把“-html-editor”补在“cool”后，给你一个完整的名字“cool-html-editor”。

别急，事儿还没完呢。如果你要编辑一个已有的文件，你可以接着使用tab completion。现在，bash知道你是要一个文件名，而不是一个程序名。bash会在你的当前工作目录下根据你给出的提示进行匹配。比方说，你要编辑的文件名是“Linux-intro.html”，那么在“cool-html-editor”后输入一个空格，跟着“Linux”，然后再用tab。bash会找出当前工作目录下所有的以“Linux”起头的文件名，如果只有一个文件，那么bash会自动在命令行把“-intro.html”补上。如果有多个文件，bash会列出所有的候选。只要输入足够长的起头字符串，再使用tab，如此反复，最终可以得到你所要的文件名。

在两次使用tab completion时，bash正确地从命令行的上下文环境中判断出第一次需要一个程序名，第二次需要一个文件名，然后去相应的地方搜索、匹配。更妙的是，bash的这个功能可以通过plugins进行扩展。比方说，在“cool-html-editor”后紧接着输入tab，bash知道这个程序需要一个HTML文件名，会相应地进行筛选，列出当前工作目录下所有的HTML文件作为候选。在安装了所需要的plugins之后，tab completion还可用来完成特定程序的命令行选项及参数。

除了tab completion，bash的命令行还支持完整的编辑功能。基本上，在bash下输入命令行就象在一个只有一行高的窗口中编辑文本，用左右光标键可以在命令行上左右移动。bash也支持命令行历史，可以用上下光标键浏览以前执行过的命令行。你甚至还可以在命令行中以起头字符串进行查找。

在Linux系统的命令行上，一个命令的执行可以被放到后台。比方说，你估计压缩一个庞大的文件需要十分钟，那么在命令行的最后加上一个“&”再按下回车键。这样，bash在把压缩程序放到后台运行后就立刻返回，又可以接受你的下一个命令了。当那个压缩程序运行完以后，bash会自动在屏幕上打印出提示，提醒你可以去检查其运行结果了。

另一个非常有用的功能是命令行管道。在Linux系统下，一个命令的输出可以作为另一个命令的输入，把两个命令用“|”相连，就构成了一个管道。如果把一个管道看作是一个命令，那么这个管道可以通过另一个“|”延长，直到超出命令行的编辑长度限制。管道中的每个命令就象一个过滤器，对自己的输入（也就是上一个命令的输出）进行处理。要注意这里的“上一个”和“下一个”是指的命令在管道中的位置，不是命令行历史中时间上的概念。命令行管道的存在使得很多程序只需要做一件事，简单，但是可以做得尽善尽美，并且这些简单的命令可以灵活组合构成满足各种需要的命令行管道。这简直就是“分而治之”的一个完美的运用。用命令行管道组合多个简单的命令完成复杂的工作已经成了UNIX命令行的一个标志性的特点。

bash不仅仅在命令提示符后接受命令。如果需要反复执行一系列命令以完成一件工作，那么这些命令可以存在一个文件里，然后让bash去执行这个文件。bash不仅支持顺序执行命令，还有分支、循环等程序控制逻辑，加上变量（无类型）、数组、函数（过程）和递归，就有了一个功能强大的解释型scripting language。事实上，bash的程序功能是如此的强大，基于Linux的操作系统的很多对性能要求不高的部分都是用bash scripts实现的。

上面我们提到用户在使用命令行时，大部分的时间都是在和文件打交道。由于文件是由绝对和相对路径名来确定的，绝大部分的命令行程序都接受路径名作为命令行参数，当对多个文件进行操作的时候，模式匹配（pattern matching，又称globbing）提供了很大的方便：“*”匹配任何字符串，包括空串，“?”匹配任意一个字符，“[0-9]”匹配从“0”到“9”的任意一个数字，“[ch]”匹配字母“c”或“h”。举个例子：“ch*[1-8].[hH]tml”匹配“ch1.html”、“ch1.Html”、“chapter8.html”、“ch18.html”，...

最后，要注意Linux常用的文件系统都是对大小写敏感的。也就是说，文件名“file.txt”、“File.txt”、“FILE.TXT”是各不相同的。另外，大部分的文件系统都支持UTF-8作为文件名的编码。所以，可以给文件起个中文名。最后，Linux的文件名没有后缀的概念，虽然习惯上人们还是会给文件名加上表示格式的后缀。Linux有另外的办法区别文件内容的格式。

作为Linux的“标准”配置，常用的命令行程序包括：

＊ 列出指定目录下的文件：ls

大概是list的简写。如果没有给出目录名，就意味着是要当前工作目录， 这也是很多命令行程序的缺省行为。“.”在Linux的文件名中还有一个特殊的用途：ls会跳过以“.”起头的文件名，包括“.”和“..”。这相当于Windows下的隐含文件属性。如果你使用的终端设备或终端模拟程序支持彩色输出，ls还会使用不同的颜色显式不同类型的文件，让你做到一目了然。只要你的终端设备或终端模拟程序不是太旧，应该都支持彩色输出。

＊ 猜测文件内容格式：file

为什么说是猜呢？因为在Linux的文件系统下，无法从文件名上看出文件的内容格式，文件的属性表也没有内容格式一项。好在绝大部分的文件格式都会在文件开头的几个或几十个字节中存放一个独特的标志。但是由于文件的格式实在太多了，还有很多可能压根是垃圾的东西充斥其中，无法保证标志的“唯一”，那么，只好猜了。所幸的是，file这个命令猜得还是八九不离十的。

＊ 复制文件：cp

大概是copy的缩写。不仅可以复制普通文件，还复制目录和目录下的内容，也就是递归地把一个目录树复制下来。

＊ 搬动文件：mv

move的缩写。把一个文件从一个目录下搬到另一个目录下，或者，在同一个目录改变文件名。从上面对文件名、路径名和目录树的描述，我们可以知道这两种操作其实是一致的。不象DOS，Linux没有rename的概念。

＊ 删除文件：rm

remove的缩写。不仅可以删除单个的文件，这个命令还可以递归地删除整个目录树。要特别注意的是，在命令行下是不能undelete的。由于Linux是一个多用户多进程的操作系统，原来被那个删掉的文件所占用的硬盘存储空间有可能马上就被其他的用户，甚至是当前用户自己的其他进程给用掉了。When it's gone, it's gone, for ever。在一个繁忙的系统上，特别是当有些应用程序频繁写盘时，这种可能性是很大的。

＊打包和解包：tar

Tape ARchive的缩写。最早是用于写磁带设备的。现在基本上是标准的源代码发行格式。可以把一个或多个文件或目录树装进包里，再在需要的地方释放出来，重建目录树。由于在包里使用的是相对路径名，可以在临时目录下释放包的内容，而不用担心覆盖已有的文件。“tar -c”用于打包（create）,“tar -x”用于释放包里的内容（extract）,“tar -t”用于列出包里的内容。tar命令生成的包文件的后缀名通常是“.tar”。tar命令其实并不关心，你可以给任何文件名。

＊ 压缩：gzip、bzip2、zip

常用的几种压缩程序。gzip的压缩率不错，速度快，需要的内存少，支持流压缩（不需要把源数据全部读进来再压缩，也就是可以用在命令行管道的下游）。惯例上，经过gzip压缩的文件以“.gz”结尾。一个例外是如果压缩的文件是个tar文件，那么可以把后缀改为“.tgz”。大概主要是为了和Windows和CDROM的文件格式兼容吧。bzip2压缩率高，但是速度低，也支持流压缩，出现的时间不如gzip长因而不及gzip普遍。文件名后缀通常是“bz2”。zip的压缩率似乎最低，但是兼容Windows下最常见的WinZIP格式，所以也是一个常用的工具。

如果给gzip或bzip2一个“-d”选项，就变成了解压。解压也支持流操作，例如“gzip -d linux-2.6.9.tar.gz | tar -xf -”

＊ 在文件内容中匹配字符串：grep

这个怪怪的名字的来历也很怪：来自于一个行编辑器ed的命令“g/re/p”，表示“Globally search for the Regular Expression and Print”。基本上，grep在指定的文件中匹配所给的正则表达式，并把匹配的行输出。例如：“grep ‘[lL]inux’ *.html”在所有以“.html”结尾的文件中，找出包含“Linux”或“linux”的所有行。grep所支持非常强大的正则表达式匹配，是shell scripting常用的命令之一。

＊ 在目录树中找文件：find

这个命令在指定的目录树中，找出所有满足给出的文件名或其他属性条件的相对路径名。例如：命令“find /usr/lib -name 'libc*' -type f”会找出目录“/usr/lib”下所有的以“libc”起头的，类型是普通文件的路径名。

＊ 输出文件的内容：cat、more、less

cat是concatenate的简写。这个命令的用途之一是把多个文件“串联”输出到进程的标准输出（stdout）上，因而得到这么个名字。由于cat不管文件有多大，一古脑儿地把文件内容灌到屏幕上，让人目不暇接。所以在实际使用中cat一般只用来输出小文件。

more和cat的区别在于more会考虑到文件的行数，在输出占满一屏后会暂停下来，在屏幕的最底下打出一行“--More (16%)--”，等着用户按下空格键或回车键继续。这就是more这个名字的来源。less比more还要好。less还支持向后滚屏，这样你就不用担心错过了重要的部分。当然，由于less做得最多，需要的资源如内存等也最多。cat基本上没做什么，也基本上不用什么资源。

＊ 文档：man、info

“man”是manual的缩写。例如，要想知道ls命令的所有选项，用“man ls”。man会自动调用less来对输出分页、暂停。通常man的输出所包含的信息就足够了。但有些复杂的命令的完整的文档是用info格式写的。

＊ 编辑文本：vi

vi是“VIsual editor”的缩写，相对于上面所提到的命令行编辑器ed而言的。vi支持全屏幕的编辑。现在几乎所有的vi用户都在使用一个称为Vim（Vi IMproved）的程序。Vim相对vi做了很大的改进，有关vi和Vim的使用足够写很厚的一本书了。

当然，Linux还有很多其他的命令行程序，但是一个普通用户在命令行下每天要用到大概就是这些。每个人都有自己使用Linux的目的和习惯，所需要的工具当然也就不同了。

如果没有光驱也没有软驱，现在装的是WIN2K, 如何安装debian?

debian好象有7张安装盘，哪几张是必须的？

(我有一台ibm tp600e的笔记本，一直闲置着，看了你的文章，想装一个LINUX用用。)