BSD for Linux Users 简译 3,4 / 11


原作者 Matt

原链接 BSD for Linux Users


BSD和Linux的不同源自他们不同的哲学。只要理解这点,其他的一切都顺理成章。

3. 设计:基本系统

我认为“基本系统”这个概念会让Linux用户最头疼。这很自然,因为“基本系统”这回事在Linux世界里不存在。

Linux最初仅仅是个kernel。 除了能用来和人争”操作系统到底包括什么”,单独的kernel没什么用。还需要各种用户态的程序才能做事。

Linux一直是个杂烩:拿来一个kernel,拿来一个ls,一个ps,vim,perl,gzip,tar,等等.

Linux从来没有“基本系统”和“额外程序”的划分。因为MySQL,ls,KDE,whois,dc,GnuCash等系统的每一部分都是“额外”。

BSD与此相反,开发一向是中心式的。始终有一个实体对整个系统负责。 BSD不用GNU ls或GNU libc。BSD用BSD ls和BSD libc。 它们直接来源于CSRG发布的BSD,从没被单独开发或打包。 没有一个地方给你下载“BSD libc”,因为在BSD世界中,单独的libc没用,单独的ls没用,单独的kernel没用。 系统是个整体,不是拼起来的很多块。

X不属于FreeBSD基本系统,X是额外的软件包。 既然X不是基本系统,xterm KDE Gnome Mozilla等跑在X下的显然也不是。 这些额外的软件受到不同的对待。最大的不同是它们的开发在哪进行。

因为X和控制台驱动的集成的关系,NetBSD和OpenBSD的基本系统中都含有一个X的实现。 这些X含有大量为BSD做的修改,所以不适合作为单独的软件包来开发。

整个基本系统是一起被开发的。 严格地讲,基本系统中确实有一些sendmail BIND tcpdump ssh之类分开来开发的软件。 Linux用户能一眼认出groff gcc gzip等GNU软件。 这些软件受到的对待是不同的,他们在做了一些修改后才融入BSD版本树。 很多现在独立的软件过去是BSD才有的。BIND和sendmail曾经是BSD的一部分,后来才分开。 我的FreeBSD自称用了gcc 3.2.2。 技术上来说这个其实不是真正的gcc 3.2.2,是一个基于gcc 3.2.2的FreeBSD编译器。 技术上来说,我用的也不是tcpdump 3.7.2,而是一个基于tcpdump 3.7.2的FreeBSD版tcpdump。

当然在大多数情况下,FreeBSD版本和原版没有明显区别。 为了让编译正常进行,往往会修改编译时的配置(Makefile等)。 有时会打补丁让编译和运行正常通过。有时会有更大的更改。 所有这些改动都是一起维护的,它们必须互相适应。 因此BSD从设计上就保证了基本系统里的各部分能相互配合。

把一个由外部维护的软件加入基本系统的原因一般是因为它的功能足够“基本”。 FreeBSD基本系统包括OpenSSH的ssh服务器端和客户端,因为这年头SSH太基本了。 gcc和binutils也是基本系统的一部分,因为编译基本系统需要用它们。 X和Gnome和PostgreSQL和Apache不是基本系统,可能永远都不会是。 因为它们不是系统必需的。

有必要强调“基本系统”这个东西。我认为它是BSD和Linux的开发方法论中最显著的不同。 Linux发行版是把各部分拼装起来,可能会在发布前测试,甚至可能有一些定制。 但是这远不同于BSD中的紧密集成。 BSD基本系统的组件不是来自”别的地方”, 它们一出生就是基本系统的一部分.

一些Linux发行版(我知道Debian和Gentoo)比较接近这种基本系统/额外组件的划分,在“系统运行所需”和其他东西之间有一条分隔线。 这仍然和BSD不同。 Linux的各软件只是被收入发行版,不存在像”Gentoo tftp”这样的东西。 BSD中的很多软件也来自外界,但基本系统由自己的开发者维护。BSD基本系统始终属于BSD。

基本系统有时也被称为“最小系统”,听起来就像维护者的目标是让它小而紧凑。 其实不是这样。我们确实想让它小和紧凑,那是因为我们想要一个“基本”的系统。 我从未在一台机器上只装BSD基本系统,可能永远都不会装。我也没听说谁装过这样的机器。 “基本系统”只需要让系统跑起来,让你可以更新或安装其他软件。 之后你根据需求,要用什么就装什么。

据说上面这些更符合FreeBSD的情况。 NetBSD和OpenBSD选择”基本系统”的条件要宽松一些。 实际装时,你还是应当rtfm。

既然已经讲了基本系统,下面我们来讲ports tree。


4. 设计:ports系统

下面讲第二类:额外的软件。 在BSD世界中,这些一般叫做“ports”系统。这名字背后有一段故事。

传统上,如果想在自己的机器上运行某个软件,首先要编译它。为了能编译它,你需要调节它。 你的系统可能需要不同的头文件,不同的常量。部分代码可能需要重写,因为一些基础假设未必适用于你的机器。

换句话说,你需要把它“移植”到你的的OS,可能还移植到具体的系统. ports系统被设计来做”移植”的。 虽然从名字上看不出,ports也负责编译,安装,打包(为了反安装)。

但是和其他很多东西一样,在ports的成长中,这个名字逐渐变得名不副实。 目前FreeBSD ports包括了超过10,000种软件,这个数字很快就会不准。 ports最大的特征是所有东西都是从源代码编译出来,而不是安装编译好的二进制包。 这又是一个会卡住Linux用户的显著差别。 从代码编译只是个副作用,不是主要的目的。 有时BSD也提供二进制包,但其实这些二进制包也是用ports tree编译出来的。

确实大部分Linux用户安装binary包,大部分BSD用户从代码编译。这是因为工具的不同。 设计ports的主要目的就是从源代码编译。make和安装不是主要功能。 而Linux包管理器, 比如RPM和dpkg, 是被设计来安装binary包. 从代码编译不是第一选择. 这是历史原因. 我提到过Unix一向不重视binary包. 软件包管理也是近期才出现. 传统上像删除软件包这种事是需要手动解决的.

有个著名的Linux发行版叫Gentoo. Gentoo的portage系统是个大卖点,很多人认为这个和BSD的ports非常像。 最明显的相似之处是portage也从代码编译。从代码编译能避免binary包的很多问题。 我没用过portage,但是听说portage综合了各种方案的优点。我想看它几年后会发展成怎样。 它仍然像Linux多过像BSD,但可能是主要Linux发行版中最像BSD的。

安装binary包省时而且省空间。 从头编译也有优点,比如能避免各种lib版本问题 (我最受不了binary这点)。 在Linux和BSD上都可以安装binary包,都可以从代码编译。但是Linux和BSD用户各有所好。 用户的偏好是因为系统的偏好,系统的偏好又是因为用户的偏好。

要认识到ports和RPM的区别不仅是“ports编译,RPM安装”。 ports的设计目的是涵盖安装中的各种阶段: 依赖关系,打包,安装,反安装等。 RPM只是个binary包。如果要管理依赖关系,就需要更高级的工具如urpmi,apt-get。 因为它是binary包,你就要处理lib的版本冲突,缺少的编译选项,以及其他不亲自编译导致的种种问题。

ports像BSD的其他东西一样, 是中心化的。 “ports tree”是一个分类好的大目录。 每个项目会含有Makefile,checksum文件,文件列表 等东西。 每个这样的小目录代表一个软件. 当你运行make时,黑魔法会为你做好各种事。如下载源代码,打需要的补丁,递归地安装好依赖项,并且用正确的选项开始编译。

这个大目录里的所有文件由FreeBSD项目维护。 如果有人写了一个KDE,KDE不会自动出现在ports tree中。 需要有什么人把这些“胶水”文件写出来 然后提交到FreeBSD的CVS版本库。 这提供了某种程度的“保险”,保证每个软件和ports的其他软件能兼容。 它还保证所有依赖项都能得到满足,因为一个软件不能依赖不在ports里的东西。

当然也有失败的时候。 依赖项的网站可能会down,导致无法下载代码。 第三方软件的新版本可能会使直接或间接依赖它的软件工作不正常。 ports不解决所有问题,但是“我需要A,A依赖B,我找不到B”这样的问题远少于RPM这样的无中心系统。

如果需要更详细的介绍,请参考FreeBSD手册中ports的部分。

我们已经介绍了对Linux用户比较难懂的“基本系统”和“ports tree”。 下面我们来讨论发布和升级。