服务器操作系统选 Debian、Ubuntu 还是 CentOS？

其实我觉得他的大部分说法都没有错。如果你需要装一个服务器，确实首选是RH系的。

但是。。。

其实你把回复从头看到尾，主要论点就一点：

哪个发行版，可以在长达7-10年的时间里，始终保持硬件稳定性的同时，又持续的升级补丁？

结论当然是RH！这是RH的主要卖点。

咳咳，今年上半年，蔽厂的运维碰到了这么一件尴尬事。

他们进货，去机房装系统，配置网络结构，加入运维管理系统，添加监控，交付。除去采购外，整个一套流程大概是一周。

我们在机房里面原本大约有10个机柜，那么一般扩充的时候，一次扩充一个机柜。

结果今年上半年的某一段时间，一周一个机柜的事情持续了两个月。运维同学辛辛苦苦装好一个机柜，周末打算轻松一下。被老大通知，又来客户了，机柜又不够用了，下周继续。

是的，我们现在20个机柜不止。机房有多少机柜我不知道，不过照这个趋势来看，我们快把机房包下来了。现在我们的带宽已经没有限制了，每个月月底按照合同秋后算账。

我们有一些有三年历史的服务器，台数不多。现在来看，性能已经远远不够。CPU不够快，也没有SSD，硬盘读写次数也太多。这些机器的下场，多数会被换下来折旧卖掉，或者作为测试服务器，搬去测试机房。而现在机房里面大半机器，都是两年以下历史的。而且至少一半服务器历史不超过半年（。。。）。从现状上看，把老服务器留在机房，其性价比并不合算。因为机房有机架密度问题，限制着我们的单机房极限，这相当于变相的租金。

如果考虑到这点，我们的线上服务器生命周期大概也就三年。最多。很多时候甚至还不到。

比我们更极端的是页游。他们的一组服务器生命周期一般是半年。半年内，要赚钱的也赚完了，不赚钱的也死完了。所以他们甚至不会新采购硬件服务器，而是直接使用虚拟机。

当然，虚拟机内的系统，支持时间是一年还是十年，对他们一点意义都没有。

RH系的提供10年级别的维护性，我换个说法，也就是最近的软件在RH的官方库里面找不到。当然，装最新的RH是有的，但是在安装了三年的一个系统上？肯定没戏。

怎么办？编译呗。

这大概就是国内谈到RH必编译的由来。

可是，我引用文内的一段话。

如果我今天告诉大家，我要做一个 http 的服务器，我不用 apache 不用 nginx，
为了性能我要用 xxx 为基础重写一套出来。我相信绝大多数人会问同样的问题，
“你觉得你写的能比 ng 好么？”
再回头看看那时候你们自己吧。

同样，自己编译的软件，补丁维护速度，能和新系统比么？而且我们还得扔一个人下去搞补丁维护。

所以，正解是什么？

装一套新的，把数据导过去用呗。

我们的”数据“，都是装载在磁盘上的。而换”系统“并不需要更新这些数据，只要把系统盘擦掉重部署一遍，然后配置好deploy系统就OK。在开发之初，”环境“，”程序“和”数据“分离，就是一项基本原则。而且即使是”数据“，丢掉一台机器上的所有”数据“也不会构成问题。这应当是运维基础中的基础。只有少数几台服务器，既不能直接更换也不能停机。这些机器我们做特别的管理。

很简单。因为最初的开发希望在Linux上进行。直接在Linux上开发和测试，对于startup的快速开发是非常重要的。而开发用什么版本，服务器跟什么版本，这是最省事和好办的。如果你硬要和我争，说开发在Mac上，跑在Linux上一点事都没有。或者说开发一个发行，服务器一个发行也OK。

我至少得说这对于golang和python都不是事实。除非不用cgo，也不用python的C扩展。

先不提Mac下和Linux下的差异。我们今年在升14.04的时候就发现，12.04和14.04的编译互不通行。所以现在12.04的编译可以程序员自己编译了本地测，14.04的就必须在测试环境里干。一帮程序员远程tcpdump出结果，拷回本地wireshark一把。。。

看看就蛋疼。

当然，这也有个问题。就是上面”我们不喜欢三年以上的系统“。所以呢。明年我们的系统大概会轮换重装，14.04。。。

也很蛋疼。

那要看和谁比。这里有HeartBleed事件的统计。虽然不普遍，但是我觉得这种大漏洞比较有代表性。

我引用他的重点整理：

RedHat 修復的速度比 OpenSSL 官方還快。
RedHat 派系的修復時間，除了 RedHat 外都算慢，如 Fedora 及 CentOS、Scentific，
他們都比 RedHat 慢 16 小時以上。
Debian 派系的修復時間，如 Debian 及 Ubuntu，都比 RedHat 慢上至少 12 小時以上。
Scentific 是列表中修復最慢的。
若以資安黃金 6 小時來說，Fedora、CentOS、OpenSUSE、Gentoo
及 Scentific 都不及格。

如果和RH比，Debian的修复速度是不及格，但是和CentOS比。。。怎么说呢？6个小时对10个小时，有种五十步笑百步的味道？

换你你愿意走几步？

另外，我也不知道原文说的升级一大包是怎么回事。我在Debian stable上查询ssl：

$ dpkg -s libssl1.0.0
Version: 1.0.1e-2+deb7u12
Depends: libc6 (>= 2.7), zlib1g (>= 1:1.1.4), debconf (>= 0.5) | debconf-2.0

但是同时。

$ dpkg -l | grep libc6
ii  libc6:i386                           2.13-38+deb7u3                i386         Embedded GNU C Library: Shared libraries

libc的依赖早就满足到不能再满足了。直到今天为止，openssl在debian上的升级还不需要你强制跟随升级libc6。而kernel根本没有依赖。

Debian 是由社区维护、贡献的发行版本，其从选包、打包、都是由社区组织，分散行动的。
Debian 是没有真正意义的 release 概念的。Debian 有众多仓库，stable，testing，
unstable ,experimental. Debian 组织系统的方式是，一个软件先进入 experimental, 
放一段时间，有 bug 修 bug，没 bug 了，过段时间挪入 unstable,
如此循环最终挪到 stable 里面。
所以在这种情况下，Debian 的系统中，是没有一个稳定版本的概念。
今天你用 kernel 3.2.1-87 , 明天就给你更新到 kernel 3.3.2-5 。

Debian是由社区维护，这没错。但是选包并不是社区组织。Debian中，如果没有特定理由（例如dfsg）阻止你打一个包，那么只要有maintainer，就可以打包。哪怕这个包的用户其实不是很多（很多包甚至统计上只有1X个用户），这也是Debian那么一大堆包的原因。

Debian包的管理方式是，先进入unstable（是的，除了少数情况，一般不是进入experimental）。在一周后，看看没问题，就进入testing。没问题的指标是，这个包和依赖的包没有RC bug，就是致命性bug。

所以很多在unstable里面有的东西，testing里面反而没有。因为unstable里面的某个基础依赖包的RC bug并没有被修复。而且testing修漏洞的速度是最慢的。因为一出问题，unstable会直接引入新的版本。而stable会要求maintainer修复。可怜的testing只能等一个礼拜。。。

那什么时候进入stable？他不会随着你的循环进入stable。而是每1.5-2年（预期1.5年，但是RC冻结周期往往会超标，根据历史数据统计，一般两年）做一次发布，这个发布会冻结所有新包，并修正RC bug。等大家觉得差不多稳定了，OK，原本的testing就成为stable，而原本的unstable就fork出新的unstable和testing。

所以现在的testing代号就会成为下一个stable代号，而每次fork的时候，我们都是决定testing代号——就是下个发行的发行代号。

所以你看BTS的追踪，会发现每1.5年有一段时间，RC bug的数量会锐减，而新包的数量也锐减。这不是大家都冬眠了，只是新发行周期而已。

作为证据，下面是我的Packages overview。大家可以看到，python-snappy（这是我唯一维护的包了，python-formalchemy已经RFA了）在stable里面是0.4，而新的两个里面是0.5。我没有明确理由把stable里面的版本升级到0.5。

这个看maintainer。一般的原则是，如果不是无法保持版本，一般直接打补丁升级。这也是原文的一点理解错误。如果用的真的是Debian stable，没有特殊理由的话，内核是不会升级到3.3的。作为证据，大家可以看一下现在stable的官配内核版本号。目前是linux-image-amd64 (3.2+46)，依赖应该是linux-image-3.2.0-4-amd64 (3.2.60-1+deb7u3)。也就是说，版本号应该是3.2.60-1+deb7u3。而3.2在kernel.org上的longterm对应版本号是62。

原作者这个理解，怎么说呢。我怀疑他要么没仔细用过debian，要么用的是testing。

但是如果新老版本差异太大，老版本又拒绝提供补丁，那么逼不得已的情况下，需要评估是不是能升。例如某一段时间，mysql的版本号是5.0XXreal5.5XXX（这个是听本厂DD说的）。至于原本的兼容性问题，我也不知道他们是怎么想的，大概是认为mysql server没啥依赖性问题吧。

但是这种情况下，RH一般也没办法吧——除非他们自己出程序员给老版本做一遍补丁。不过如果这样的话，oracle一般会merge back回去，debian就跟着沾光了。

Ubuntu 8.04 LTS April 24, 2008
Ubuntu 8.04.4 LTS January 28, 2010
1年9个月
你说好的 LTS 呢？？？
Ubuntu 10.04 LTS April 29, 2010
Ubuntu 10.04.4 LTS February 16, 2012
说好的 LTS 呢？
说 End of the Date 是3年整就是一个笑话，
只要下个 release 一出，上个 release 收到的更新数量就可怜。

作者大概是RH用多了，没搞明白Ubuntu“维护”的本质。

Debian和Debian基础的系统，主要的发行方式是网络。光盘只是给你个安装的机会。这点debian更加明显——他有种光盘叫做netinst。里面只有基础包的安装包。在不联网的情况下，你只能装出一个用于联网升级的系统。没有gui，没有openssh，啥都没有。

所以，LTS归LTS，修改不够多是不够打新光盘的。

谁会持续5年，一年给你弄张新光盘出来啊——尤其是里面没几个包改了。

而LTS的维护怎么样？我们来看usn的维护情况。

在2014年6-7月，总共有26个USN涉及ubuntu lucid。

所以装好ubuntu，第一件事是去repository上面打一遍安全补丁!

上面说了半天，根本问题是，”维护“是个什么东西？

主要就是bug修复。尤其是一类特殊bug修复——安全补丁。

一旦一个程序基本成型，就一定会形成”接口“。API是接口，调用的程序，参数，顺序，环境变量，一样是接口。有接口就有接口兼容性。如果不考虑兼容性，一律使用最新版本的话。。。

bang。不知哪天程序就跑不动了。因为作者改了接口。

不要以为这很扯，我在实际里多次碰到这种问题。python-mongo多次修改接口，sqlalchemy0.6时写的程序，经我反复修改终于上到了0.7，却死也上不到0.8。至于docker，也是个版本号刚刚过1.0的家伙。在1.0前面，我们就作大死的做了二次开发。结果惨不忍睹。

所以我们用一种被称为“发行”的方案。即一段时间，将稳定的代码固定下来，形成某个版本的发行。例如linux-kernel-3.2.0。而后新功能在3.3上面渐进，原本使用3.2的并不受到干扰。

这本来挺完美，可惜有一个问题。bug并不一定出在最新版上面，他有可能在14年前就已经存在了。这样会使得bug横跨多个版本。而这个bug又不能不修的时候——例如安全漏洞。

这时候就蛋疼了。

上游会修多少个发行的漏洞？如果上游不修，这个发行的漏洞怎么办？大部分漏洞只是几行就可以完成修正，但是有些发行甚至要动架构，怎么办？

没有研发力量，是不能保证修复的。

在代码里面，主要有三件事情，功能发展性，接口稳定性，代码安全性。

如果我们可以去掉一件事情，那么世界很完美。

1. 去掉接口稳定性，每次都用最新的就好了，bug肯定修光的。

2. 去掉功能发展性，软件不再推进就好了，就修修bug。

3. 去掉代码安全性，单纯发行就好了，发了就不用管了。

可惜，三者一般都需要。有些很古典的程序已经进入了2的情况，例如TeX。至于大部分互联网公司线上系统，则比较偏向1。但是大部分发行版内的包，可是要三者都满足的。

其实还是很大的。RH的开发是真的开发。Debian的”Developer”，其实只管开发debian打包用脚本，维护版本，补丁，仓库。而RH的开发，别的不说，你就看内核补丁贡献数吧。

这也是社区和公司不同取向的差别。社区不管商业能处理的一些问题，而且他们也管不了。先不提RH有多少人，Debian社区有多少人。我就吐槽一下中国DD数量吧。我查询了一下，总共8个（db）。其中我认识5个，超过一半。某次emfox来开会，lidaobing和zigo也在。我们开玩笑说，这次会议集中了中国近一半的DD。。。其实整个会场里面人数都没超过20。。。

也只有RH这种级别的公司，才有大量人力去折腾内核，驱动之类的事情。因为debian就算想折腾，也折腾不动啊。从某种意义上说，所有linux发行的蓬勃发展，都得益于RH的大量收入。

所以真想支持开源的，不全买，买一套RHEL也好啊。别老叫着CentOS免费，免费还说个JB的支持开源。

虽然在上面数了原作者的一堆问题，但是我得说，他的结论没啥错误。

除非你明白自己在干什么，否则RHEL一定是你的第一选择。

这是废话。出钱让人帮你解决问题，和你自己解决问题，哪个更专业？

凡是你干了这活，打算三五年内就上去升级升级安全补丁，此外啥都不想干的。用RHEL准没错。

如果上面这种情况会让你失业的，换Gentoo准没错。

至于什么叫做“明白自己在干什么”，其实没一个统一的标准。很多时候选择开发版有点“如人饮水，冷暖自知”。例如我们选Ubuntu，解决了发布同环境问题，却引入了运维滚动升级问题。但是经过权衡，发布和调试环境不同会导致研发效率的大幅下降，而我们的研发是不能靠花钱招的（广告：长期招聘靠谱golang研发），但是我们的运维是可以靠花钱招的。这个时候痛苦也得滚动着上了。当然，也许若干年后，发现其实我们错了。可是错的理由我们现在看不到也想不到。当然，像我们，或者页游这种奇葩公司，也不总是出现。所以大部分情况下，用RHEL都是对的（当然，原作者说的太绝对化了一点）。

Debian是非常强调dfsg的，具有非常强的开源原教旨主义的味道。

传统的开源认为，如果只有商业公司掌握发行，那么他们就会扼住我们的命脉，并以此作恶。

不得不说，老外对垄断和权威的恶和理解一点都不比我们差。

所以debian的衍生发行一点都不比RH逊色（Linux发行版列表）。最大的就是得益于dfsg规定，凡是允许进入debian的，不能仅仅授权给debian——而是必须授权给整个公有领域。因此对debian的衍生是非常安全而没有法律风险的——DD们在这个领域的专业程度非常高。

而且，由于强调自由，因此debian内所有非核心包，都具有非二进制定制性。简单来说，就是除了核心包和打包参数，其他大部分结构都是可以更改而且应当是自己更改配置的。

想用lxde换掉gnome，可以。搭配着kde的软件使？也可以。上面用什么输入法？自己配。

这是debian的强大和灵活所在，也是debian非常高的一个门槛。相比起来，Ubuntu更强调“开箱即用”。所以里面的随附配置是最完备的。但是要用lxde，推荐就是Lubuntu了。

我上面提到的RH，大部分指的都是RHEL。至于Cent——他也是社区系统，只是背靠RH，胳膊更粗一些而已。这不代表Cent因此就靠谱了。

例如这个维基页面CentOS，里面提到说。

In July 2009, it was reported[by whom?] that CentOS's founder,
Lance Davis, had disappeared in 2008. Davis had ceased contribution
to the project, but continued to hold the registration for
the CentOS domain and PayPal account. In August 2009,
the CentOS team reportedly made contact with Davis and
obtained the centos.info and centos.org domains.[12]

那哥们直接失踪了近一年，而且捏着域名和PayPal账户不放。我记得当年这事直接导致CentOS的其他开发者出来放话，再不出来把你丫按照失踪申报。

这也直接导致我上家公司的基系统选择从CentOS改成了Scentific（是的，就是上面修复最慢的那家）。

其次，CentOS是不签合同的，所以出了事是运维自己兜着。

CentOS出了问题你能和领导交代么？这得看你们领导的SB程度。反正要是有人告诉我，他用CentOS出了事。我的第一反应都是，RHEL是不是可以避免。可以的，那就是决定用的人自己找事。

我们没有用RHEL，都买了RH的订阅。RH的订阅非常有指导意义。

早期，我们使用 Debian 作为服务器软件，后来转向了CentOS，主要原因如下：

1、CentOS/RHEL的生命周期是7年，基本上可以覆盖硬件的生命周期，也就意味着一个新硬件安装以后，不用再次安装操作系统。要知道重新折腾一个生产机是很麻烦而且有风险的事情。

[2012.2.1]今天刚刚收到红帽子的通知邮件，RedHat 5, RedHat 6的生命周期，延长到10年，太牛叉了。这个对企业用户很重要。

而Debian的生命周期是不固定的，一般新版本发布以后，上个版本再维护18个月。而Debian的版本发布时间间隔不稳定，经常会延期。综合起来一个版本的生命周期一般在3～4年。

[2014.4.24]Debian 宣布对Squeeze(6.0)，提供5年的LTS长期支持。

Ubuntu的LTS版生命周期是5年。

如果你选用了 Debian 或者 Ubuntu作为服务器，等生命周期过了以后，就没有安全补丁，你的服务器就会裸奔或者需要重新安装系统。

• Alan Cox - Core developer, numerous contributions

• Ingo Molnar - x86 subsystem maintainer

• Al Viro - VFS subsystem maintainer,  linux内核贡献第二多的个人

• David Miller - Sparc Port maintainer, linux网络部分开发者， linux内核贡献最多的个人

• Jeff Garzik - Sata subsystem maintainer

• John Linville - Wireless subsystem maintainer

• Stephen Tweedie - Ext3 filesystem developer

• Eric Sandeen - XFS, Ext4 filesystem developer

• Josef Bacik - Btrfs filesystem developer

• Rik Van Riel - VM developer

• Ric Wheeler - Filesystem developer

• Val Henson - Filesystem developer

• Dave Jones - Fedora kernel maintainer

• Kyle McMartin - Fedora kernel maintainer

• Chuck Ebbert - Fedora kernel maintainer

• Eric Paris - LSM/SELinux/Audit/Capabilities maintainer

• Eugene Teo - Security Response

• Kay Sievers - Hotplug

3、CentOS/RHEL对硬件的支持很好，主流硬件厂商早就将服务器拿过去测试，一般不存在硬件的兼容性问题。

而Debian就麻烦了，由于有版权上的考虑和代码纯洁性上的洁癖，一些硬件驱动和软件被删掉了，导致安装过程有问题。比如 Dell 服务器上，大量使用的网卡 BroadCom，就驱动不了，安装了以后，网络起不来。

4、大量商业软件，比如 Oracle ，都是针对 Redhat认证的，有大量的帮助文档和使用说明，有良好的技术支持。出了问题，也容易在网上找到类似的答案和经验。

5、CentOS 是RedHat的克隆版，如果需要可以随时平滑切换到 RedHat，从而享受RedHat的服务支持。要知道厂商的服务，是最后一道防火墙，如果你给一个大客户做方案，他们一般会倾向选用商业服务。万一出了什么问题，还有Redhat可以求助，或者有一个RedHat可以承担责任 :-)

6、如果你是一个工程师，熟悉了 CentOS/RedHat ，找工作更加容易。如果你是一个企业老板，相对也容易招聘到熟悉CentOS/RedHat的工程师。RHCE的培训，也相对较完善，认同程度高。

7、CentOS/RHEL 的批量安装更加方便

在机房，使用kickstart + PXE安装，给客户，使用定制的kickstart光盘，一键安装，一般在5分钟左右就可以安装完。

上述3，4，5，6几点中，都说明CentOS/RHEL相对于其他Linux操作系统，有相对完整的生态环境，很多公司在CentOS/RHEL投入了大量资源，积累了大量经验，绑定了自己的利益，这个是CentOS/RHEL得以长期良好发展的保证。

=============
补充对评论的一些回复

1. 所谓的“centos稳定性非常差”，不知道你指的是什么？能否举一些CentOS不稳定的例子？至少我们用了这么多年CentOS，稳定性上可以说是坚如磐石的。如果是你说的由于yum升级造成的混乱，那只能说明你对centos不熟悉。
2、RHEL/centos 对于一些新的软件的支持，采用 SCL的方式支持，比如ruby193，python27, python 33, PHP 54, nodejs 0.10, mariadb55, postgresql 9.2
AdditionalResources/Repositories/SCL
3、debian/ubuntu 同样存在版本稳定和程序太老的矛盾，比如他们的LTS版本，一般是两年多更新一次。squeeze是2011年2月发布，wheezy是2013年5月发布，如果你在2013年4月使用Debian，你会发觉好多软件太老，比如：
内核：2.6.32，和Centos 6  一样的
glibc 还是使用的2.11.2
mysql使用的5.1.49
openjdk使用的是 6
php使用的是 5.3.3
python使用的是2.6.6

下一个版本的Deiban，至少要到 2015年下半年才能发布，而RHEL7/CentOS7的正式版发布在即，里面用到的不少软件，都比wheezy的要新。按照你的逻辑，在接下来较长的时间里，是否CentOS比起Debian更加前卫？

再看看Rio的回复：“之前我用了很长一段时间的 Debian，但它的更新实在太慢了（好几年啊有木有！）”，呵呵

4、“debian的支持时间也非常长期”，这个最近确实有了改善，Debian刚刚宣布对 Debian 6.0 有了5年的LTS长期支持。可以这么说，Debian也看到了LTS的重要性，向CentOS学习了一把。
Debian -- News -- Long term support for Debian 6.0 Announced

但Debian做得还不够，因为Debian的LTS在后续版本，比如 Debian 7 (wheezy)， Debian 8 (jessie) 里的支持政策还不明朗：
Debian -- Security Information -- DSA-2907-1

Debian的LTS支持，也不是Debian 官方安全团队维护的，而是由其他志愿者维护的，工作效率和质量是否有保证还不知道。相比RHEL明晰的发展策略和安全更新策略，有10年的安全补丁保证，还有不少差距。

其实你把回复从头看到尾，主要论点就一点：
哪个发行版，可以在长达7-10年的时间里，始终保持硬件稳定性的同时，又持续的升级补丁？
结论当然是RH！这是RH的主要卖点。

usr/share/doc/linux-image-3.2.0-4-amd64 目录下面有一个 changelog.Debian ，grep 一下：

grep wheezy changelog.Debian

linux (3.2.57-3) wheezy; urgency=medium

linux (3.2.57-2) wheezy; urgency=medium

linux (3.2.57-1) wheezy; urgency=medium

linux (3.2.54-2) wheezy; urgency=high

linux (3.2.54-1) wheezy; urgency=high

linux (3.2.53-2) wheezy; urgency=high

linux (3.2.53-1) wheezy; urgency=medium

linux (3.2.51-1) wheezy; urgency=low

linux (3.2.46-1+deb7u1) wheezy-security; urgency=low

linux (3.2.46-1) wheezy; urgency=low

linux (3.2.41-2+deb7u2) wheezy-security; urgency=high

linux (3.2.41-2+deb7u1) wheezy-security; urgency=high

起码在 wheezy 里面(stable) 里面，他从 3.2.41 走到了 3.2.57 , 同时…… 你们可以看到 每个版本也就打包 1-2 次，1-2次啊！而且 Debian 的 unstable 走到 stable 真的就是随便走走的。

linux (3.2.41-2+deb7u1)  是第一个 stable 版本，他的上一个版本是

linux (3.2.41-2) unstable ，好，3.2.41 第二次打包，加了一次 patch 就变成 stable 了

linux (3.2.41-1) unstable ， 得，41 就打了一次

linux (3.2.39-2) unstable ， 39 也就打两次。

从这个过程，你可以看出，Debian 总体上，还是在跟着 Kernel Source 的，为啥？没人啊！靠零散的人打 patch 还不如依赖 Kernel 本身的小版本更新。

RedHat 呢？

放一个 RHEL 6.4 的 Release Note

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html

RHEL , 是不跟 kernel source 的小版本号的，自己整合 bugfix ，主要是安全相关的补丁。

为什么不跟 kernel source 呢？

主要还是目标用户的不同，就像我下面驱动这块要解释的。RHEL 的目标用户，是企业的 Server 的，他的 Kernel 里面，已经太多的东西被替换掉了。磁盘、网卡、各种各样的驱动。而 Kernel source 尽管只走小版本号，还是不太靠谱的。频繁的拿过来风险也大。

kernel 其实走到 2.6 以后，就没有一个真正稳定的概念了。反正就是一路往前走。当然 2.6.32.xx 的确是以 bugfix 为主的。但是这个量太大了，各种各样鸡毛蒜皮，RHEL 不是全都拿进来的。

你们一定要和我争论版本的问题，行，我不和你们争，Debian Stable 是有版本的～ 你们满意了？这种一个 kernel 打包 2次的状态，你们爱用就用好了。无所谓的。

但是有 版本的也只是 stable，testing  我可从来没见过。

说实话，我真的花了心思想多找一点 Debian 的信息，

11年进入 stable 的 6.0 , 最近确实还有一个更新，在 08 Apr 2014 。

http://metadata.ftp-master.debian.org/changelogs//main/l/linux-2.6/linux-2.6_2.6.32-48squeeze5_changelog

09年发布的 lenny 也就是 5.0 ，根本已经连信息都很难找了。如果谁能找到 lenny 麻烦给一个 kernel 的 changelog

----- 补充结束 -------

filename:       /lib/modules/2.6.32-358.6.1.el6.x86_64/kernel/drivers/net/tg3.ko

firmware:       tigon/tg3_tso5.bin

firmware:       tigon/tg3_tso.bin

firmware:       tigon/tg3.bin

version:        3.124

filename:       /lib/modules/3.12-1-amd64/kernel/drivers/net/ethernet/broadcom/tg3.ko

firmware:       tigon/tg3_tso5.bin

firmware:       tigon/tg3_tso.bin

firmware:       tigon/tg3.bin

version:        3.133

#define DRV_MODULE_VERSION      "3.102"

#define DRV_MODULE_RELDATE      "September 1, 2009"

评论1：
Debian 其实在很多不是那么重要的环境中是很好的选择方案。[不是那么重要的意思是，即使宕机十几分钟、半小时老板也不会和你数钞票的损失。] 为什么？1. 足够数量的包。2. testing 具有可以接受的可靠性。(与 Arch 相比) 3. testing 具有非常好的软件更新速度。 3. testing 不具有 release 特性，永远平滑升级（与 Arch Gentoo 一样）。而 Fedora 与 Ubuntu 类似，具有 release 特性，但一旦新版本出来，老版本维护很少。同时 dist-upgrade 过程并不友好，体验很糟糕。所以如果让我个人选择，学校机房我也会用 Debian。我回答中，也提到我的 HomeServer 是用 Debian 的。其实以前是用 Arch 的，但是 Arch 稳定性真的很差，一个 pacman -Syu 玩死你。在尝过痛苦以后，切换到 Debian Testing，跑了2年左右了，感觉还是很可靠的。

Gentoo 能够激起情怀->于是工作效率大增->公司利益得到保障。哈哈哈，你赢了。还是要分场合的，60 还过得去 6000呢？我也用 Gentoo 做过产品啦，不过不是服务器。TVU networks 的 x86 产品就是我决定转移到 Gentoo 的。在这个产品上，很好的利用了 Gentoo 定制方便，平滑更新的特性，因为 TVUPACK 需要适配最新的 USB Modem。唯一遗憾的是，我没有来得及给它一套二进制分发系统。如果下次还有机会，我一定会想办法做一套。在 Server 上编译，不是我的风格，太脏。我曾经把 CentOS 5 精简到 96 个 RPM 依旧可以开机。CentOS 6 只能做到 100 以上了。
但是，还是要分事情的。我也会花很多时间调试 VIM 写 bash 写 python，但是我开始写 Cocoa 了，我果断放弃 VIM，必须 xcode。
我猜测很多新手（好吧，show B ge 的时候到了）觉得发行版本之间的讨论会类似于早期各种开发语言之间的类似宗教性的讨论[抨击]。
其实并不是这样的，因为熟悉使用一个发行版本的代价远小于熟悉一门开发语言。5-10年的时间，足够你熟悉主流的发行版本。足够让一个高手做到物尽其用，适宜即可。
我不是任何发行版本的粉，我在公司服务器用 CentOS，我在 HomeServer 用 Debian，我在 CubieBoard 用 Debian，我在路由器上用 openwrt ，我在 PC 上用 OSX，我在 PC VM 上用 Gentoo。因地制宜，此乃最高境界。

我能够理解你，但是我不赞同你。为什么？
因为我也有把用 XXX 当魄力的年纪，我觉得这样很有趣，很Cool，很特别，我希望自己与众不同，或者我告诉自己我能学到更多的东西(是的，的确可以)。
但是当我经历了这个阶段，回头看的时候。我知道了两点，1. 这个过程是有价值的，没有这个过程，不会成为今天的我。2. 这个过程太花时间了。我投入了比别人多 100% 的经历，来获取比别人多 30% 的知识。可能还有更好的路可以走？
今天我的同事来告诉我，他要自己编译 apache 放到线上，我告诉他。你不要这么做，用 CentOS 自带的就可以了，节约下来的时间你可以真的搞清楚 apache 各种性能相关的参数（相信我，很多人都搞不清），你还可以研究一下如何让开发人员在受控的环境下自由的发布新的版本，且同时具有良好的回退功能而不用让运维介入。你还可以写一套系统每周验证一次备份的数据库是否能够正常加载。
相信我，实际的运维工作中，有太多值得做而没有人做的工作了。他们都比你在那里 configure 来的有意义的多。

1.“RedHat系列好使我没意见，可是你给用户付钱啊？”
所以我们在谈 CentOS 啊？你不知道他们之间的关系？去看看吧。

2. “关于支持时间的问题，支持时间短一点也是已经告诉你的，这个不至于成为喷点吧” 啊？“Ubuntu 尝试了几次，目前我没看到成功。几乎都是草草放弃。”
Ubuntu 说 LTS 是 3年，可以从历史的维护时间看，很少维护到三年。
这是我要表达的。你不知道 LTS 是 3年？

3. “某天某个软件爆出类似最近 openssl 的漏洞“
嗯，你引用了我的原话，请注意我想说的是 ”类似“。而并不是就是这次的 openssl。
说道 openssl 的修复，你的表述是不正确的。
这次的 openssl 修复有两个方式，其一是更新至 openssl 小版本，其二是重新编译将引发问题的功能关闭。并不只是上游修复这一种方式。

RedHat 应该是采用了第二种，因为他更新的是 1.0.1e-16 只是打包号增加了。（注意 RedHat 还是尽可能的维护版本，我不知道 Debian 是不是这么做的，还是升级到了 1.0.1f？可能答主知道？）
这是题外话…… 我在这里想表达的是，Debian 的组织方式，可能会受到连带更新，尤其是在 Testing 环境中，因为 Debian 在Testing中是不断往前走的。比如 A 依赖 B，B 在不断的往前走，A 遇到了 Bug，于是在下次更新中 A 和 B 有可能会被同时更新。在 Testing 中这种现象是存在的。Stable 中应该不会。

同时我已经在某些评论中认可，我对 Debian 的描述有夸张的成分。

4. 你想用 squeeze、wheezy 是你的事情，因为你这么用了，所以我不这么用，就体现出了我不懂？我BB？你太抬举你自己了，好歹给点理由吧。

而且我答题的最后也已经说了 ，你用 Debian 做服务器，没什么大问题。
我不推荐的原因我已经描述的很清楚了，kernel 上比 RedHat 弱很多，你们想有反驳意见冲着这个来。

这这么短的针对我的答案评论的答题中，至少体现了三点你”不懂“的东西，我觉得你还是多看看再说吧。
另外，礼貌一点，没有人会把你当傻子。 有很多人都会陷入一种境地，通过攻击别人来体现自己的高大。其实真正内心强大的人，根本不需要这样做。
就像一个评论 Gentoo 的主，一定要说我在攻击 Gentoo，但是其实评论中，尽一切机会显示他有多么多么懂 Gentoo，自己多么多么会用。至于么？你体现自己能力的方式一定是先要将别人放置在你的对立面？low……