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

不用开机箱了，并且以后也能用上。当然，使用IDE转换插头可以保证没有设备驱动的问题。各有利弊吧。

第一次听说。所有我以前接触过的资料都是有关用Linux做服务器的。

从硬盘安装.具体步骤忘记了,不过你可以查查帮助文件. 不知道debian 或 RH 可不可以.

今天试了试， 不错：）

第三篇 图形界面（上）：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的篇幅实在太长，就分成了上、下两部分。

X最早出现于mit，1984年，至少从名字上是一个叫W的图形界面的后续。X11是X的第11版，87年出的。后来就没有大改动，所以没有X12，而只是X11R*。

XFree86是X11R5在i386上的衍生产品。X11R6是X的最后大改版（major revision），由mit的X组织发布。后来96年该组织解散，由其后继者如open group, Xorg出的就只叫X11R6.*，算小改版，加些小的功能，改改bug什么的。

90年代中期的时候，X真是很牛啊。sun, hp，dec各种workstation都用X。x toolkit, motif, 还有sgi的一套东西都很热门。客户服务器分开的好处微软直到win2000server的terminal server才算能提供，期间空当还成就了一些如humingbird之类的软件。

现在sun又在卖它那套thin client的东西，说到底还是在吃X。

练武之人选兵器。假如Debian是刀，RedHat是剑，练什么，一要看自身（例如，自己是不是对命令行比较惧怕，了不了解硬件），二要看老师（比方说，周围有没有别人用同样的distro，资料好不好找）。

选了刀，弄通前，没有必要，最好别去碰剑。否则把两个搅到一起，全乱了。等把刀玩儿的纯熟了，拿上剑就容易了。触类旁通么。当然，如果觉得刀好用，也不一定要再去练剑。一直用下去，也能成个大家。

第三篇 图形界面（下）：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+程序发布的信息

SuSE也是IBM推荐的Mainframe Linux

发言权了，从来没有见过S390，连照片都没见过。

第四篇：网络服务器

但凡说起Linux在服务器上的应用，都要从LAMP开始。LAMP是四个软件系统“Linux、Apache、MySQL和PHP（巧了，另外两种常用于Web的编程语言Perl、Python也是P打头）”的缩写。这四个软件系统放在一起，可以说是开发网站的黄金组合。Linux做操作系统，提供了一个坚实的基础：Linux内核拥有号称是最完整的IPv4、zero-copy和sendfile最大限度地减少了在核心态与用户态之间的上下文切换、2.6版的内核进程调度算法更是优化了对大数目并发用户的支持。

在Linux上，Apache的HTTPD是当之无愧的第一选则，虽然不是唯一的选择。作为自由软件的旗帜之一，Apache HTTPD源自于美国National Center for Supercomputing Applications开发的public domain HTTP daemon。1995年4月，在NCSA HTTPD 1.3版的基础上，Apache HTTPD的第一个正式版发行了。在不到一年的时间里，Apache HTTPD就成了最流行的HTTP服务器。这个殊荣从那时一直保持到了现在。

和其他HTTP服务器相比，Apache最大的特点可能就是其非常优异的可扩展性（extensibility）。可以从两个方面对Apache HTTPD进行扩展。Apache把处理HTTP请求的过程分解为一系列的步骤，如URL到路径名的映射、认证、授权、送出应答、logging等。所有这些步骤都定义了一个“钩子”，服务器端的应用程序可以往上挂自己的函数，对这个过程特殊处理。与CGI相比，这些钩子函数的效率要高很多。标准的CGI程序必须运行在另外一个进程里，启动进程和在进程间通信的代价都很大。而钩子函数就在HTTPD的进程内，不需要启动新进程，调用函数的成本几乎可以忽略不计。

在另一个方面，Apache定义了非常清晰的程序模块（module）接口，所有的扩展程序都可以编译成模块，并根据配置动态加载。一个模块通常包含针对某个或某些特定步骤的钩子函数，例如根据URL的pattern进行特殊的映射，或者专门处理用户的认证，或者对从硬盘上读取文件进行caching，甚至可以是把log放到数据库中，等等。

模块和钩子函数的接口都是C语言，意味着模块必须用C语言来完成。但是用C语言开发应用程序的最大缺点是内存管理繁复易错、调试过程耗时费力。于是人们想到了如果能把scripting语言的解释器嵌入到模块里，只要把这一个模块写清楚了、调试好了，那么所有人就都可以用scripting语言来进行服务器端的应用程序开发。即有scripting语言易于编程的优点，又不需要为CGI付出代价。Perl是最早被嵌入到Apache HTTPD模块中的scripting语言。mod_perl的出现可以说是轰动性的。紧随其后的是PHP和Python，分别出现以mod_php和mod_python出现。其他的scripting语言也陆续加入到这个行列中，如ruby、tcl、pike等，但最流行的还是PHP、Perl和Python。

虽然各种scripting语言的语法大不相同，作为HTTP模块，大致的构成是相同的。首先，要告诉HTTPD什么样的HTTP请求（比方根据URL、或者MIME类型等）需要转交给这个模块处理。在拿到从硬盘上读出的代码后，嵌入在模块中的解释器就开始执行代码。执行的结果再作为HTTP应答发送给客户端。

PHP是一种专门针对在HTTP服务器端开发应用程序而发明的编程语言。PHP脱胎于HTTP服务器上常见的server side inclusion，即所谓的SSI，增加了过程式语言的控制机制和面向对象语言的抽象与封装机制。和Perl、Python等“常规的”编程语言不同的是，PHP的代码用特殊的tag直接嵌入在HTML页面中的，必须转换为浏览器能识别的HTML或JavaScript代码才能当作HTTP应答发给客户端。这与JSP有些相似。由于PHP直观、易于上手，很快就成了在服务器端开发web应用的首选。

在这将近十年的时间里，Apache HTTPD从0.6.2走到了2.0。在2.0之前的1.3版说非常成功，以至于人们认为没有必要升级到2.0版。当然，2.0版带来的变化也是很大的。不仅核心部分从单一的多进程结构发展到多进程、多线程等多种结构，连模块和钩子函数的接口都变了。这就意味着所有的模块必须重写。1.3版的模块不用考虑多线程的安全性，但是由于2.0版的核心可以配置为运行多个线程，模块必须是符合多线程安全性的要求。由于这些原因，一些模块的开发人员对于向2.0版移植的积极性就不是那么高。PHP就是其中最突出的一个。为此在PHP和Apache HTTPD的开发人员间还出现了一些不愉快的争论和猜疑。

MySQL在LAMP之前的名气并不大。对SQL的支持不完整、没有transaction、只能在表一级加锁，MySQL的这些缺陷曾经被广为诟病。但是仗着速度快，对系统资源要求低、易于管理，MySQL很快成了低成本网站的中坚。首先，网站的静态内容不需要实时更新，数据库可以是只读的，又要求非常高的速度，正好可以让MySQL扬长避短。而对于大量的论坛网站，由于对数据库的主要操作是添加记录，并不涉及对数目众多的表进行同时修改，加上MySQL的速度也快，减弱了其粗粒度加锁可能对并发性能的影响。

对于那些暴露在整个Internet前的Web服务器，和速度与稳定性同样重要的是安全性。除了Apache HTTPD、PHP和MySQL的安全性外，操作系统，也就是Linux自身的安全性也非常重要。作为最后一道防线，Linux提供了一种称为chroot jail的机制。chroot代表change root，是内核提供的一个系统调用，可以改变呼叫进程的根目录。由于调用chroot需要超级用户的权限，只要应用程序在从chroot返回后立即放弃超级用户的权限（这也是所有Internet服务器程序应该做的），当前进程就无法通过再次调用chroot回到真正的根目录去。也就是说，chroot可以把有潜在安全漏洞的应用程序的运行限制在一个特定的目录下，就好像被放进了监狱里一样。这样，即使hacker找到应用程序中的安全漏洞，例如buffer overflow，控制了当前用户进程，也无法从监狱里逃出来，进而危害整个系统。

当然，chroot jail只能作为众多损害控制手段中的一个，远远不是整个系统安全防线的全部。即使chroot起了作用，防止了整个系统的陷落，由于hacker至少已经攻破了一个应用程序，仍然对业务的正常运作造成了影响。另外，由于应用程序进程的根目录发生了变化，对于应用程序的设计和编写，以及整个系统的配置都有特殊的要求。

除了Linux外，由BSD派生出来的操作系统如FreeBSD、OpenBSD等也都提供chroot。现在chroot已经成了注重安全性的系统管理员必备的工具之一。

后记：本来这一篇还要介绍Email、FTP、Samba等其他服务器程序。但尝试了几次后，发现自己的经验和理论知识都不够，连班门弄斧的资格都没有，所以只好在写完LAMP后住手，以免让大家久等。

• 【原创】gentoo linux文件共享samba经验点

chroot是一种机制还是一种工具？也就是说，是内核直接支持chroot，还是像应用软件一样需要每次去运行，才能提供保护？