<转>谁写了Linux

作者:admin 发布时间:May 12, 2011 分类:DELL1520



原文地址:http://coolshell.cn/articles/1360.html

2009年8月,Linux软件基金会发布了一份叫《Who Writes Linux and Who Supports It》(PDF)的报告。这份报告主要对Linux 2.6.x的开发进行了全方位的统计。看了以后才知道,原来Linux的开发的生产率竟是这样的惊人,而且相当的的令人振奋,所以,在第一时间转过来给大家看看。让人不得不惊叹,这不可思议的具有非凡活力的社区。(注意,我们这里说的是Linux,不是GNU的那些东西,所谓Linux就是Linux的Kernel)
logo.bmp

下面是一个导读,希望每一个看到这篇文章的朋友都能看看原文的报告:《Who Writes Linux and Who Supports It》(PDF)这份报告的一开始就对Linux的开发进行了总结:

每2-3个月一个release
最近的每一次release都超过10000个补丁
有超过1000个开发人员进行开发,他们来自200个公司或组织。
自2005年以来,超过5000个来自500个不同公司的开发人员为Linux内核做过贡献。
自2008年以来,每次release,都大约增加了10%左右的开发人员,而且,代码码达到了2.7百万行。
是的,这样的生产率真是太疯狂了。下面是这份文档中所涉及的一些介绍和一些具体的统计数据。

Linux开发模式
Linux的开发采用的是一种宽松的,基于时间的开发模式。每一个新的主要版本的release基本上会发生在2-3个月之内。这个开发模式是在2005年形成的,因为任何人都可以修改其内核的代码,所以,很多补丁进入内核的时间非常的快。

其中一个有意义的事是,他们有一个叫Linux-Next的服务器,这个服务器一般来说会是下一个版本的staging,比如,如果目前的稳定版本是2.6.31,那么Linux-Next上就会运行2.6.32。这样,所有的developer都能看到下一个版本总体的样子,而且,这更容易发现一些集成性的问题。

在2.6的mainline代码库上(mailline是代码库的主线),有一个叫做“stable team”的团队,他们会做短期的维护工作,他们确保所有的重要的补丁或更改都会被放入mailline中,这样就能滚入下一个release。

然后,这份文档中给出了大量的开发编译数据。

统计数据
下面的统计数据是从版本2.6.11开始的,我把源文件中的表格合并成一个大表,如下所示。
1-1.bmp

从上图我们可以看到下面这些东西:

Linux Kernel开发的速度越来越快,看看每个release的补丁数,每天文件增、删、改就可以知道。
Linux Kernel开发的团队是越来越大,包括人员和参与的公司。
下面是几个统计图表:
1-2.bmp

平均每天的修改
1-3.bmp

代码修改统计
1-4.bmp

开发人员
1-5.bmp
谁写了Linux
最后我们进入主题——谁写了Linux,首先,我们先来看一下进入代码修改的Top 30的开发人员列表:
1-6.bmp

我们可以看到,Linus Torvalds (729 总修改,自2.6.24版来254 修改)无法进入前30名。当然,对Linux的贡献绝对不能通过代码行来表示,Linus对Linux就算是在今天也是至关紧要的。

好,让我们再来看看那些公司对Linux的贡献。根据这份报告所说,知道每个developer所在的公司,主要是通过了下面的几种方法:

使用的邮件地址有公司的名字。
由赞助者提交的代码。
直接询问得到的。
所以,这些数据只能算得上的近似,不过也能看到一个总体的样子了。下图中“None”代表没有职业无业游民,“Unknown”代表无名氏或是英雄不知出处。

我们可以看到,Top 10公司,为Linux贡献了近70%的代码。包括了None和Unknown,而且,那些是拿着公司报酬给Linux作开发的程序员。

那么,为什么这些公司要支持Linux的内核开发呢?

我们可以看到像IBM, Intel, SGI, MIPS, Freescale, HP, Fujitsu这样的大公司,他们的目的当然是为了确保Linux能够在他们的硬件上工作得更好。
我们也可以看到像Red Hat, Novell, 和MontaVista这些Linux的Distribution公司,他们是Linux的主力,主要是为了提供给他们的客户更好的服务。
同样,我们还能看到像Sony, Nokia, 和Samsung这样的公司,这些公司主要是用Linux来开发数码产品,如摄像机、手机或是电视,他们使用Linux做一些嵌入式开发,以保证他们的产品工作得更好。
还有一些和IT都没有关系的,例如:Volkswagen公司在v21.6.25中为Linux加入了PF_CAN网络实现的协议。Quantum Controls BV公司在2.6.30时加入了一个航海导航的补丁,这些公司都会使用Linux来完善他们的产品。
看来,Linux的势头是越来越无法阻挡了,你也想加入这个阵营吗?点下面的链接吧:http://ldn.linuxfoundation.org/book/how-participate-linux-community
(全文完)

php 的 imagick 扩展安装

作者:admin 发布时间:May 10, 2011 分类:DELL1520

今天安装 zenphoto (一款开源相册软件 php编写的) 需要用到 imagick 扩展,于是上网找了下,原来不是使用--with-imagick在编译php的时候静态编译进php ,而是 类似memcache的方式,编译成so模块动态加载的

首先安装 ImageMagick-6.6.5-10.tar.gz
cd ImageMagick-6.6.5-10
./configure --prefix=to/your/path
make
make install

在安装 imagick-3.0.1.tgz 去pecl.php.net
tar zxvf imagick-3.0.1.tgz
cd imagick-3.0.1
/your/php/bin/phpize
./configure --with-php-config=/your/php/bin/php-config --with-imgaick=/your/imagemagick/
make
make test
make install

然后修改php.ini增加
extension=imagick.so

重启php,检查phpinfo,看是否加载成功,即可。

几款开源相册使用感受

作者:admin 发布时间:May 10, 2011 分类:DELL1520

今天突然想把旅游的照片都整理一下,放到一个相册系统上来,但是苦于没有用过,于是开始找寻

第一款 plogger
这个是比格勇同学在博客上使用的,于是马上从官方网站上下了包测试一下

优点:
安装简单,按照操作步骤来就可以了

缺点:
需要MYSQL支持
点击链接执行过程太慢,可能是我的测试机得问题,破台式机

第二款 gallory3
这个是网上介绍的一款

优点:
安装也很简单,按照步骤操作即可

缺点:
安装过程出现问题,无法安装完成

第三款:phpwind
这是一个国内的相册工具

优点:还没看到
缺点:需要SQLITE,完蛋去吧!

第四款:zenphoto
这是国外一款,清凉型相册工具,功能足够用了

优点:安装简单

缺点:需要安装imagick扩展,点击页面第一次访问会生成缩略图,可能会有点慢。

最后我选择了zenphoto,安装时我用的php5.2.8发现总是502很慢,我重装了php到5.3.4问题解决了,除了还要多装一个imagick扩展让我头疼了会儿,其他都还OK,目前使用正常,批量导入很强大

[Nginx] fastcgi proxy keeplive参数可配置到location中

作者:admin 发布时间:May 9, 2011 分类:DELL1520

今天发现了3组参数可以配置到location中,之前一直都错误理解了

核心模块中keepalive_timeout
keepalive_timeout
syntax: keepalive_timeout [ time ]
default: keepalive_timeout 75
context: http, server, location

大部分proxy部分的参数都可以在location里面用
proxy_buffer_size
syntax: proxy_buffer_size the_size;
default: proxy_buffer_size 4k/8k;
context: http, server, location

proxy_buffers
syntax: proxy_buffers the_number is_size;
default: proxy_buffers 8 4k/8k;
context: http, server, location

fastcgi部分的模块也是
fastcgi_buffer_size
syntax: fastcgi_buffer_size the_size
default: fastcgi_buffer_size 4k/8k
context: http, server, location

fastcgi_buffers
syntax: fastcgi_buffers the_number is_size
default: fastcgi_buffers 8 4k/8k
context: http, server, location

fastcgi_connect_timeout
syntax: fastcgi_connect_timeout time
default: fastcgi_connect_timeout 60
context: http, server, location

fastcgi_read_timeout
syntax: fastcgi_read_timeout time
default: fastcgi_read_timeout 60
context: http, server, location

fastcgi_send_timeout
syntax: fastcgi_send_timeout time
default: fastcgi_send_timeout 60
context: http, server, location