PHP 开发者的 Docker 之旅

PHP 开发者的 Docker 之旅 用 PHP 作为我们「Docker 开发大礼包」开篇是带着一些朝圣的心情的。这是一门堪称「古老」的语言,这也是一门争议最多的语言,这更是一门不断涅槃的语言。「PHP 是最好的语言」这个流传已久的梗,或许正是对我国最有群众基础的编程语言描述里,最经典的注解。 就让我们一起回顾一下 PHP 的发展历程作为此系列文章的开篇。历史是最好的老师,他给每个未来提供启示。 谁创造了 PHP? Rasmus Lerdorf 在 1994 年创造了 PHP,Andi Gutmans 和 Zeev Suraski 之后于 1997 年重写了 PHP 的解析器,之后他们在以色列成立了著名的 Zend 公司来维护 PHP 的开发。 PHP 是什么的缩写? 起先的意思直白的有点近乎粗鲁「Personal Home Page」,后来改成了「PHP: Hypertext Preprocessor」即便用今天的眼光看也是很酷炫的命名。 PHP 最著名的版本? PHP 5 发布于 2004 年 7 月 13 日,距今正好第十一个年头。 下一个 PHP 版本? PHP 7 计划于 2015 年 11 月 12 日发布。 PHP 的形象代言人? 一只蓝色的大象,因为「elePHPant」(黄色的那头是 Hadoop)。 谁在主导 PHP 的方向? PHP Group 来维护其标准,Zend 作为商业公司提供参考实现。 HHVM 又是什么? HipHop Virtual Machine (HHVM) 是 Facebook 对 PHP 的一次革命性衍进,HHVM 采用实时编译进程,使得 PHP 的执行效率大幅提升。Facebook 在 2013 年全面采用 HHVM 运行 PHP,间接拉升了 PHP 生态的逼格,激发了整个 PHPer 群体的活力。 PHP 的包依赖怎么做? Composer PHP 的单元测试怎么做? PHPUnit 常见的 PHP 技术栈和应用场景? LAMP(Linux + Apache + MySQL + PHP)长期占据着我国互联网应用的主流架构。即便在今天,这也是电商和社区类互联网公司的主要技术栈。尤其在电商领域,说 PHP 托起半个中国的购物车都不为过。 为什么 ASP 和 JSP 都没有 PHP 受众广? 当年 FTP 比起 VPS 简直是白菜价。但这也间接养成了 PHP 开发重功能轻工程的通病,加上部署的随意性,上规模后运维虐成狗。 就这个运维问题,作者 Rasmus Lerdorf 怎么看? I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests. 翻译过来就是:「重启应该就有好运气」。 那怎么破的,能教教吗? 上 Docker! Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。容器几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

]]>

CentOS 安装swftools方法

1 需要更新centos的软件源 http://mirrors.163.com/.help/centos.html 按照说明更新就行了

首先备份/etc/yum.repos.d/CentOS-Base.repo
    mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
下载对应版本repo文件, 放入/etc/yum.repos.d/(操作前请做好相应备份) 运行以下命令生成缓存
    yum clean all
    yum makecache
2 安装swftools所需的各类开发包
yum install gcc* automake zlib-devel libjpeg-devel giflib-devel freetype-devel
3 编译安装swftools
wget http://www.swftools.org/swftools-0.9.2.tar.gz
tar vxzf swftools-0.9.2.tar.gz
cd swftools-0.9.2
./configure --prefix=/usr/local/swftools
make
make install
中间可能会出现:
jpeg2swf.o: In function `MovieAddFrame’: jpeg2swf.c:(.text+0xa1e): undefined reference to `swf_SetJPEGBits’ collect2: ld returned 1 exit status make[1]: *** [jpeg2swf] Error 1 make clean make  
 ]]>

60秒在Debian上安装Docker

echo deb http://get.docker.io/ubuntu docker main | sudo tee /etc/apt/sources.list.d/docker.list sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9 sudo apt-get update sudo apt-get install –y lxc-docker 按照这个方法已经成功安装了docker 1.4.0]]>

利用Squid反向代理搭建CDN缓存服务器加快Web访问速度

http://520tom.blog.51cto.com/530608/1347098

案例: Web服务器:域名www.abc.com IP:192.168.21.129 电信单线路接入 访问用户:电信宽带用户、移动宽带用户 出现问题:电信用户打开www.abc.com正常,移动用户打开www.abc.com很慢,甚至打不开 解决方案:在移动机房放置一台CDN代理服务器,通过智能DNS解析,让电信用户直接访问Web服务器、让移动用户访问CDN代理服务器,解决移动用户访问Web服务器慢的问题 具体操作: CDN代理服务器: 系统:CentOS 5.5 主机名:cdn.abc.com IP:192.168.21.160 安装Squid软件,配置反向代理搭建CDN缓存服务器 安装前准备: 1、关闭SELinux vi /etc/selinux/config #SELINUX=enforcing     #注释掉 #SELINUXTYPE=targeted  #注释掉 SELINUX=disabled  #增加 :wq  保存,关闭。 shutdown -r now重启系统

2、开启防火墙80端口(后面配置squid的端口为80) vi /etc/sysconfig/iptables 添加下面的内容 -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT /etc/init.d/iptables restart  #重启防火墙使配置生效

3、修改主机的路由模式 vi /etc/sysctl.conf net.ipv4.ip_forward = 1    #0为关闭,1为开启路由 使用sysctl -p 命令查看 系统运维  www.osyunwei.com  温馨提醒:qihang01原创内容版权所有,转载请注明出处及原文链接 4、修改主机hosts文件,增加域名解析记录 vi /etc/hosts 192.168.21.129  www.abc.com    #添加解析记录

=========================================================================== 安装开始 1、安装Squid yum install squid   #安装(Squid 2.6) service squid start #启动 service squid restart #重启 chkconfig squid on  #设置开机启动

2、配置Squid cp /etc/squid/squid.conf /etc/squid/squid.confbak  #备份 vi  /etc/squid/squid.conf  #编辑文件 http_port 80 transparent  #设置squid端口,默认为3128,设置为80,客户端打开网站的时候不需要输入端口号 cache_mem 1024 MB   #分配内存大小 cache_dir ufs /var/spool/squid 4096 16 256 #设置缓存文件大小 cache_effective_user squid  #设置用户 cache_effective_group squid  #设置用户组 access_log /var/log/squid/access.log   #设置访问日志文件 cache_log /var/log/squid/cache.log  #设置缓存日志文件 cache_store_log /var/log/squid/store.log  #设置缓存记录文件 visible_hostname cdn.abc.com  #设置squid服务器主机名 cache_mgr root@abc.com  #设置管理员邮箱(设置为自己的邮箱地址) acl all src 0.0.0.0/0.0.0.0  #设置访问控制列表,默认开启 http_access allow all  #设置访问权限,默认注释掉的 cache_peer 192.168.21.129 parent 80 0 no-query originserver name=web  #用户访问web时,Squid向192.168.21.129的80端口发送请求 cache_peer_domain web www.abc.com  #设置web域名为www.abc.com cache_peer_access web allow all  #设置访问权限,允许所有外部客户端访问web :wq!  #保存退出 service squid stop  #停止 /usr/sbin/squid  -z  #初始化cache缓存目录 service squid start #启动 Squid反向代理服务器安装配置完成 ================================================================== 启用智能DNS解析: 如果是电信用户访问域名www.abc.com解析到192.168.21.128 如果是移动用户访问域名www.abc.com解析到192.168.21.160 CDN缓存服务器与Web服务器之间采用专线连接

]]>

关于Linux静态库和动态库的分析

http://www.cnblogs.com/hzh1024n/archive/2009/09/17/1568357.html 1.什么是库 在windows平台和linux平台下都大量存在着库。 本质上来说库是一种可执行代码的二进制形式,可以被操作系统载入内存执行。 由于windows和linux的本质不同,因此二者库的二进制是不兼容的。 本文仅限于介绍linux下的库。 2.库的种类 linux下的库有两种:静态库和共享库(动态库)。 二者的不同点在于代码被载入的时刻不同。 静态库的代码在编译过程中已经被载入可执行程序,因此体积较大。 共享库的代码是在可执行程序运行时才载入内存的,在编译过程中仅简单的引用,因此代码体积较小。 3.库存在的意义 库是别人写好的现有的,成熟的,可以复用的代码,你可以使用但要记得遵守许可协议。 现实中每个程序都要依赖很多基础的底层库,不可能每个人的代码都从零开始,因此库的存在意义非同寻常。 共享库的好处是,不同的应用程序如果调用相同的库,那么在内存里只需要有一份该共享库的实例。 4.库文件是如何产生的在linux下 静态库的后缀是.a,它的产生分两步 Step 1.由源文件编译生成一堆.o,每个.o里都包含这个编译单元的符号表 Step 2.ar命令将很多.o转换成.a,成文静态库 动态库的后缀是.so,它由gcc加特定参数编译产生。 例如:

$ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname, libfoo.so.1 -o libfoo.so.1.0 *.
5.库文件是如何命名的,有没有什么规范 在linux下,库文件一般放在/usr/lib /lib下, 静态库的名字一般为libxxxx.a,其中xxxx是该lib的名称 动态库的名字一般为libxxxx.so.major.minor,xxxx是该lib的名称,major是主版本号, minor是副版本号 6.如何知道一个可执行程序依赖哪些库 ldd命令可以查看一个可执行程序依赖的共享库, 例如
# ldd /bin/lnlibc.so.6 => /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2 => /lib/ld- linux.so.2 (0×40000000)
可以看到ln命令依赖于libc库和ld-linux库 7.可执行程序在执行的时候如何定位共享库文件 当系统加载可执行代码时候,能够知道其所依赖的库的名字,但是还需要知道绝对路径 此时就需要系统动态载入器(dynamic linker/loader) 对于elf格式的可执行程序,是由ld-linux.so*来完成的,它先后搜索elf文件的 DT_RPATH段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache文件列表—/lib/,/usr/lib目录找到库文件后将其载入内存 8.在新安装一个库之后如何让系统能够找到他 如果安装在/lib或者/usr/lib下,那么ld默认能够找到,无需其他操作。 如果安装在其他目录,需要将其添加到/etc/ld.so.cache文件中,步骤如下 1.编辑/etc/ld.so.conf文件,加入库文件所在目录的路径 2.运行ldconfig,该命令会重建/etc/ld.so.cache文件 我们通常把一些公用函数制作成函数库,供其它程序使用。函数库分为静态库和动态库两种。静态库在程序编译时会被连接到目标代码中,程序运行时将不再需要该静态库。动态库在程序编译时并不会被连接到目标代码中,而是在程序运行是才被载入,因此在程序运行时还需要动态库存在。本文主要通过举例来说明在Linux中如何创建静态库和动态库,以及使用它们。在创建函数库前,我们先来准备举例用的源程序,并将函数库的源程序编译成.o文件。 第1步:编辑得到举例的程序–hello.h、hello.c和main.c; hello.h(见程序1)为该函数库的头文件。 hello.c(见程序2)是函数库的源程序,其中包含公用函数hello,该函数将在屏幕上输出”Hello XXX!”。 main.c(见程序3)为测试库文件的主程序,在主程序中调用了公用函数hello。 程序1: hello.h
#ifndef HELLO_H #define HELLO_H void hello(const char *name); #endif //HELLO_H
程序2: hello.c
#include <stdio.h> void hello(const char *name) { printf(“Hello %s!\n”, name); }
程序3: main.c
#include “hello.h” int main() { hello(“everyone”); return 0; }
第2步:将hello.c编译成.o文件; 无论静态库,还是动态库,都是由.o文件创建的。因此,我们必须将源程序hello.c通过gcc先编译成.o文件。 在系统提示符下键入以下命令得到hello.o文件。
# gcc -c hello.c #
(注1:本文不介绍各命令使用和其参数功能,若希望详细了解它们,请参考其他文档。) (注2:首字符”#”是系统提示符,不需要键入,下文相同。) 我们运行ls命令看看是否生存了hello.o文件。
# ls hello.c hello.h hello.o main.c #
(注3:首字符不是”#”为系统运行结果,下文相同。) 在ls命令结果中,我们看到了hello.o文件,本步操作完成。 下面我们先来看看如何创建静态库,以及使用它。 第3步:由.o文件创建静态库; 静态库文件名的命名规范是以lib为前缀,紧接着跟静态库名,扩展名为.a。例如:我们将创建的静态库名为myhello,则静态库文件名就是libmyhello.a。在创建和使用静态库时,需要注意这点。创建静态库用ar命令。 在系统提示符下键入以下命令将创建静态库文件libmyhello.a。
# ar cr libmyhello.a hello.o #
我们同样运行ls命令查看结果:
# ls hello.c hello.h hello.o libmyhello.a main.c #
ls命令结果中有libmyhello.a。 第4步:在程序中使用静态库; 静态库制作完了,如何使用它内部的函数呢?只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明静态库名,gcc将会从静态库中将公用函数连接到目标文件中。注意,gcc会在静态库名前加上前缀lib,然后追加扩展名.a得到的静态库文件名来查找静态库文件。 在程序3:main.c中,我们包含了静态库的头文件hello.h,然后在主程序main中直接调用公用函数hello。下面先生成目标程序hello,然后运行hello程序看看结果如何。
# gcc -o hello main.c -L. -lmyhello # ./hello Hello everyone! #
我们删除静态库文件试试公用函数hello是否真的连接到目标文件 hello中了。
# rm libmyhello.a rm: remove regular file `libmyhello.a’? y # ./hello Hello everyone! #
程序照常运行,静态库中的公用函数已经连接到目标文件中了。 我们继续看看如何在Linux中创建动态库。我们还是从.o文件开始。 第5步:由.o文件创建动态库文件; 动态库文件名命名规范和静态库文件名命名规范类似,也是在动态库名增加前缀lib,但其文件扩展名为.so。例如:我们将创建的动态库名为myhello,则动态库文件名就是libmyhello.so。用gcc来创建动态库。 在系统提示符下键入以下命令得到动态库文件libmyhello.so。
# gcc -shared -fPCI -o libmyhello.so hello.o #
我们照样使用ls命令看看动态库文件是否生成。
# ls hello.c hello.h hello.o libmyhello.so main.c #
第6步:在程序中使用动态库; 在程序中使用动态库和使用静态库完全一样,也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明动态库名进行编译。我们先运行gcc命令生成目标文件,再运行它看看结果。
# gcc -o hello main.c -L. -lmyhello # ./hello ./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory #
哦!出错了。快看看错误提示,原来是找不到动态库文件libmyhello.so。程序在运行时,会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到,则载入动态库,否则将提示类似上述错误而终止程序运行。我们将文件libmyhello.so复制到目录/usr/lib中,再试试。
# mv libmyhello.so /usr/lib # ./hello ./hello: error while loading shared libraries: /usr/lib/libhello.so: cannot restore segment prot after reloc: Permission denied
由于SELinux引起,
# chcon -t texrel_shlib_t /usr/lib/libhello.so # ./hello Hello everyone! #
成功了。这也进一步说明了动态库在程序运行时是需要的。 我们回过头看看,发现使用静态库和使用动态库编译成目标程序使用的gcc命令完全一样,那当静态库和动态库同名时,gcc命令会使用哪个库文件呢?抱着对问题必究到底的心情,来试试看。 先删除 除.c和.h外的 所有文件,恢复成我们刚刚编辑完举例程序状态。
# rm -f hello hello.o /usr/lib/libmyhello.so # ls hello.c hello.h main.c #
在来创建静态库文件libmyhello.a和动态库文件libmyhello.so。
# gcc -c hello.c # ar cr libmyhello.a hello.o # gcc -shared -fPCI -o libmyhello.so hello.o # ls hello.c hello.h hello.o libmyhello.a libmyhello.so main.c #
通过上述最后一条ls命令,可以发现静态库文件libmyhello.a和动态库文件libmyhello.so都已经生成,并都在当前目录中。然后,我们运行gcc命令来使用函数库myhello生成目标文件hello,并运行程序 hello。
# gcc -o hello main.c -L. -lmyhello # ./hello ./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory #
从程序hello运行的结果中很容易知道,当静态库和动态库同名时, gcc命令将优先使用动态库。 基本概念 库有动态与静态两种,动态通常用.so为后缀,静态用.a为后缀。 例如:libhello.so libhello.a 为了在同一系统中使用不同版本的库,可以在库文件名后加上版本号为后缀,例如: libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库,通常使用建立符号连接的方式。
ln -s libhello.so.1.0 libhello.so.1 ln -s libhello.so.1 libhello.so
1、使用库 当要使用静态的程序库时,连接器会找出程序所需的函数,然后将它们拷贝到执行文件,由于这种拷贝是完整的,所以一旦连接成功,静态程序库也就不再需要了。然 而,对动态库而言,就不是这样。动态库会在执行程序内留下一个标记指明当程序执行时,首先必须载入这个库。由于动态库节省空间,linux下进行连接的缺省操作是首先连接动态库,也就是说,如果同时存在静态和动态库,不特别指定的话,将与动态库相连接。 现在假设有一个叫hello的程序开发包,它提供一个静态库libhello.a 一个动态库libhello.so,一个头文件hello.h,头文件中提供sayhello()这个函数 /* hello.h */ void sayhello(); 另外还有一些说明文档。 这一个典型的程序开发包结构 与动态库连接 linux默认的就是与动态库连接,下面这段程序testlib.c使用hello库中的sayhello()函数
/*testlib.c*/ #include <hello.h> #include <testlib.h> int main() { sayhello(); return 0; }
使用如下命令进行编译 $gcc -c testlib.c -o testlib.o 用如下命令连接: $gcc testlib.o -lhello -o testlib 连接时要注意,假设libhello.o 和libhello.a都在缺省的库搜索路径下/usr/lib下,如果在其它位置要加上-L参数 与与静态库连接麻烦一些,主要是参数问题。还是上面的例子:
$gcc testlib.o -o testlib -WI,-Bstatic -lhello
注:这个特别的”-WI,-Bstatic”参数,实际上是传给了连接器ld。指示它与静态库连接,如果系统中只有静态库当然就不需要这个参数了。 如果要和多个库相连接,而每个库的连接方式不一样,比如上面的程序既要和libhello进行静态连接,又要和libbye进行动态连接,其命令应为:
$gcc testlib.o -o testlib -WI,-Bstatic -lhello -WI,-Bdynamic -lbye
2、动态库的路径问题 为了让执行程序顺利找到动态库,有三种方法: (1)把库拷贝到/usr/lib和/lib目录下。 (2)在LD_LIBRARY_PATH环境变量中加上库所在路径。 例如动态库libhello.so在/home/ting/lib目录下,以bash为例,使用命令:
$export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ting/lib
(3) 修改/etc/ld.so.conf文件,把库所在的路径加到文件末尾,并执行ldconfig刷新。这样,加入的目录下的所有库文件都可见。 3、查看库中的符号 有时候可能需要查看一个库中到底有哪些函数,nm命令可以打印出库中的涉及到的所有符号。库既可以是静态的也可以是动态的。nm列出的符号有很多,常见的有三种: 一种是在库中被调用,但并没有在库中定义(表明需要其他库支持),用U表示; 一种是库中定义的函数,用T表示,这是最常见的; 另外一种是所谓的“弱 态”符号,它们虽然在库中被定义,但是可能被其他库中的同名符号覆盖,用W表示。 例如,假设开发者希望知道上文提到的hello库中是否定义了 printf():
$nm libhello.so |grep printf U
其中printf U表示符号printf被引用,但是并没有在函数内定义,由此可以推断,要正常使用hello库,必须有其它库支持,再使用ldd命令查看hello依赖于哪些库:
$ldd hello libc.so.6=>/lib/libc.so.6(0x400la000) /lib/ld-linux.so.2=>/lib/ld-linux.so.2 (0x40000000)
从上面的结果可以继续查看printf最终在哪里被定义,有兴趣可以go on 4、生成库 第一步要把源代码编绎成目标代码。 以下面的代码为例,生成上面用到的hello库:
/* hello.c */ #include <stdio.h> void sayhello() { printf(“hello,world “); }
用gcc编绎该文件,在编绎时可以使用任何全法的编绎参数,例如-g加入调试代码等: gcc -c hello.c -o hello.o (1)连接成静态库 连接成静态库使用ar命令,其实ar是archive的意思
$ar cqs libhello.a hello.o
(2)连接成动态库 生成动态库用gcc来完成,由于可能存在多个版本,因此通常指定版本号:
$gcc -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 hello.o
另外再建立两个符号连接:
$ln -s libhello.so.1.0 libhello.so.1 $ln -s libhello.so.1 libhello.so
这样一个libhello的动态连接库就生成了。最重要的是传gcc -shared 参数使其生成是动态库而不是普通执行程序。 -Wl 表示后面的参数也就是-soname,libhello.so.1直接传给连接器ld进行处理。实际上,每一个库都有一个soname,当连接器发现它正在查找的程序库中有这样一个名称,连接器便会将soname嵌入连结中的二进制文件内,而不是它正在运行的实际文件名,在程序执行期间,程序会查找拥有 soname名字的文件,而不是库的文件名,换句话说,soname是库的区分标志。 这样做的目的主要是允许系统中多个版本的库文件共存,习惯上在命名库文件的时候通常与soname相同 libxxxx.so.major.minor 其中,xxxx是库的名字,major是主版本号,minor 是次版本号]]>

Linux创始人曾经小看 Mac OS X

img201106201216580 1997年,Steve Jobs回归,开发下一代操作系统的工作被提上日程。此刻的时代背景是像Linux这样的开源软件大行其道。随着网络的发展,使得像Red Hat、VA Linux之类的企业成为爆发户,把泡沫越吹越大。Steve Jobs承认Linux的好处,甚至在若干年后介绍Mac OS X底层的Darwin时还不忘在幻灯片上写道:Darwin是类似Linux的系统。而当时精明的Steve Job在考虑下面几个问题。 第一,NeXTSTEP的内核和外围工具中,BSD代码维护起来需要大量人力,而且各分支的BSD发展显然不如Linux快。很多功能都没有,需要Apple自己做。 第二,像Apple这样的小公司,需要借力打力。Apple的主要竞争对手是Microsoft,而开源软件的矛头也是Microsoft,如果联合起来干革命,不但能让自己得到一个好名声(Apple事后一直自称是最大的开源软件公司),也可以获得可观利益,从而对Microsoft造成压力。 第三,也是最重要的,联合各开源组织能够推动Mac OS的发展。毕竟开源软件中像GCC之类都是很成熟的项目,Apple用起来省时省力,投点钱就有大效益,多好。 所以,把Linux内核作为Mac OS X的重要组成部分的想法被这位伟大的智者想了出来。Apple之前也有开发Linux的经验,比如在Steve Jobs回归之前,Apple就和OSF合作开始把Mach内核移植到PowerPC上(Apple是最大的PowerPC玩家,而OSF是最大的 Mach玩家),并把Linux作为服务跑在Mach上。这个系统就是MkLinux,我们在后续的连载中还会提到这个系统,因为它不但对Linux的移植性作出了重要的贡献,也对后来的Mac OS X的XNU内核技术起到了相当重要的作用。 如果可以采用Linux作为系统重要组成部分,并且这个构想能够取得在开源软件界呼风唤雨的Linus Torvalds的认同,就能靠他在社区鼓动一大群开发者皈依Apple麾下,这是Apple很想看到的给力结局。有了这个指导思想,他便让秘书给 Linux的开发者Linus Torvalds发了一个邮件,问他是不是有一到两小时的时间和Steve Jobs会面。不明真相的Linus Torvalds收到邮件后相当高兴,因为这是他第一次有机会去硅谷观摩。 无果而终的会面 Apple 总部Infinity Loop终于迎来了这位稀客,Steve Jobs亲自接见,而先前任NeXT技术总监的Avie Tevanian也参加了这次会谈。不用多说,这次讨论的内容自然是还处于未知状态的Mac OS X。讨论算不上正式,但Linus Torvalds的愤青个性,却让谈判陷入僵局。 Steve Jobs自然搬出他1997年回归之际在MacWorld讲话时的那套理论,Apple虽然很颓,但骨子里是个牛逼的公司。全世界桌面领域的真正玩家就两个,一个是Apple,另一个是Microsoft,两者加起来,构成百分之百的桌面用户群。所以,Linus同学,你就从了我们吧,如果你从了我们,让我们把Mac架在Linux上,一大批桌面用户就是Linux用户啦,前景可是一片大好! 而Linus Torvalds那时候牛啊,诸多大公司如IBM、Red Hat都围着他转。他可是企业家中的大红人,像Apple这样的企业根本就不在他眼里。作为一个开源软件的革命家,在他的想象中Linux的潜在用户应该比Apple还多。他始终相信,按照目前开源软件的发展态势,自己很快就能在桌面领域分到一杯羹。而且这个命题在他这种古怪性格下的直接推论是,即使我能占领桌面领域,我也要摆出一副不在乎这个领域的态度来。所以实际上Steve Jobs的开场白就失败了。 接着,Avie Tevanian向Linus Torvalds介绍了整个计划。他们想把Mach和Linux内核合并起来作为Mac OS X的基础,我估计Linus Torvalds是听错了(因为Avie Tevanian很早就意识到相比于微内核,混合内核有明显优势),他以为Apple想把Linux作为Mach的一个服务来跑(当然我个人认为,即使是合并Mach和Linux成为混合内核,依Linus Torvalds的愤青性格,依然是不可能接受的),这正让他回想到先前和Tanenbaum教授的笔战。并且,他也知道Apple和IBM合搞的失败项目Taligent正是用Mach的。 Linus Torvalds对于微内核有他自己的看法,之前也曾在不同的地方表述过。若把关于微内核的笔战去掉限制级敏感词的话可概括成两方面。一方面,设计一个微内核和相关的服务,可能造成各种设计上的灾难。GNU/Hurd早在八十年代末就考虑尝试在Mach上写一系列Unix的服务层,结果他们始终无法搞明白到底是让这些服务先发消息到另几个服务呢,还是考虑其他方案。所以直到2011年我写这篇文章时,Hurd项目依然处于半死不活的状态。而另一方面,微内核的效率无法和传统内核相比,最简单的系统调用会涉及一系列底层服务的互相通信。所以很多研究者着手研究如何把微内核的效率提上去,结果就导致微内核变得更加复杂。能提高微内核效率的很多研究成果都已在Mach项目中实现了。而在Linus Torvalds看来这恰使Mach成为了一个非常复杂的项目,并且效率也不怎么高。 会谈时坐一旁的Avie Tevanian事实上是Mach最早的开发者之一,他热情地给Linus讲述Mac OS X系统蓝图。而Linus实际上早就不耐烦了。比如,Mac OS X中,有一个模拟层,可让用户使用经典的Mac OS程序。这个技术极类似于现在跑在Unix系统上执行Windows程序的Wine。Apple当时的考虑是这样,因为老的Mac OS在设计API时,就没有考虑到类似内存保护之类的问题,所以这层API必须废掉,Mac OS X中所有的新程序必须采用NeXT的那套更先进的API(根据我的考证,当时还没有Carbon这样的想法,而且事实上Carbon不管在API还是 ABI上都和经典Mac OS不兼容)。而短期内已有的软件又不可能快速重写迁移至Mac OS X。所以,如果用户需要使用老版Mac OS的第三方应用程序,就可以使用Apple提供的这个兼容层。但是由于刚才提到的原因,老版程序并不享受新版程序的待遇,因为模拟器本身运行多个老 Mac OS任务时,和原先老版Mac OS一样,实际上只有一个进程,没有内存保护。这样做的好处是明显的,因为一方面老的程序在Mac OS X发布之初还能用,另一方面Apple又和老技术划清了界限,逼着开发者使用新技术,技术方面的原因是最重要的。但这个看似很正确的技术在Linus Torvalds看来是古怪的,他想当然地认为,完全可以运行多个不同的模拟器进程,来执行不同的任务,使得每个任务都可以享受内存保护。这种浪漫主义情调让他无比鄙视Apple员工的智商。而事后当笔者使用早期版本的Mac OS X时,发现Linus Torvalds的想法完全是不切实际的。因为这个模拟层本来就要占用不少的内存和CPU,在处理器速度不及今日手机、内存无比精贵的90年代末,跑一堆模拟器进程无异于是和自己过不去。 Steve Jobs考虑到Linus Torvalds是开源软件的领军人物,便继续以开源为话题,动之以情,晓之以理。他告诉Linus Torvalds,我们这个系统做出来后呢,所有的Unix层(非图形界面层),都会开源,所以事实上你加入我们,也是在给开源做贡献啊!而由于在开源圈子混久了,Linus Torvalds对此丝亳不领情,他认为,有谁会想用一个底层是开源而图形界面是不开源的系统呢?所以,像笔者这样的用户被“代表”了。 Mac OS X与Linux分道扬镳 总之,这次会面完全谈崩,两人站在不同的角度去看问题,加上Steve Jobs和Linus Torvalds都是个性鲜明、唯我独尊的人,技术和商业上的考虑都不同,所以会谈中双方简直就是鸡同鸭讲。这次讨论也使得Apple放弃Linux,转而采用FreeBSD技术,并在2001年任命FreeBSD的发起者、领军人物Jordan Hubbard为BSD技术小组的经理,并在后来升为Unix技术总监。至于Apple的内核技术后来走向何方,我们下期再讲。 笔者认为,Apple和Linus Torvarlds的商谈破裂,以今天的眼光来看,是因Linus Torvarlds的自命清高和短视造成的。他不懂得尊重其他开发者的意见,并且不断抬扛。包括后来关于C++的论战。Mac OS X发布后,Linus Torvalds又数次嘲笑Mac的技术落后,并说这些他在当年和Steve Jobs开会时就预料到了。直到最近,他终于有些成熟,对Mac OS X的观点开始缓合,但还是不忘批评Mac的文件系统就是垃圾(事实上,Linux的也没好到哪去,至少Apple还搞过一阵ZFS)。这种性格最终导致在 Mac OS X和iOS大行其道的时候,Linus Torvalds连兔子汤都不曾分到。 而事实上这对Apple也是件好事。Apple重要的是利益而不是折腾,即使是开源也是利益驱动。像类似Linux开发组那样自以为是但代码又写得差的开源项目,Apple事后也遇到不少,比如GCC编译器项目组。虽然大把钞票扔进去,在先期能够解决一些问题,但时间长了这群人总和Apple过不去,并以自己在开源世界的地位恫吓之,最终Apple由于受不了这些项目组人员的态度、协议、代码质量,觉得还不如自己造轮子来得方便,因此Apple推动了类似LLVM这样宏伟的项目,并且在短短几年内,使其成为最领先的开源软件技术。这无异于扇了Linux小组、GCC小组一记响亮的耳光。]]>