zoukankan      html  css  js  c++  java
  • 服务器操作系统应该选择Debian/Ubuntu还是CentOS?

    任何 Linux 发行版本,在理论上都是一样的。只不过操作有的方便,有的麻烦!yum 是比 apt 弱(这就是企业维护和社区维护的区别,企业自己维护不需要这么多功能)但是任何能在 A 发行版本上实现的效果,一定是能在 B 上实现的。

     


    首先,我想请各位玩家,你们不要自己最近新玩上什么就觉得什么好,然后大肆的推荐什么好不好!负点责任好不好!人家是服务器,有些时候选错一个发行版本会痛苦死一批人!

    是,你现在终于发现有个版本叫 Ubuntu 了,好爽啊,那么多包,随便 apt-get , 3万个包躺在仓库里面不用编译。好爽啊!几乎所有软件都有最新版本用!唉?过两天你发现 Ubuntu 原来是从 Debian 来的,Debian 才叫牛啊,完全社区运作,包的数量一点都不少啊。再过两天发现 Gentoo 啦,哇塞,牛啊!性能的极致优化,编译编译再编译,configure , configure 再 configure ,精简到极致。再过两天 Gentoo 玩腻了,不就是编译么~ 唉? 原来还有 Arch 啊,这个不错啊,想编译的编译,不想编译的也有默认包。然后2个月没 pacman 更新过的系统,更新一下全挂了。

    你的意识形态,走在任何一个阶段都认为这个阶段是最好的选择。但事实并不是这样的,这只是你的兴趣而已。

    要讨论这个问题,先要知道两大发行版本的区别在哪里。RedHat 和 Debian。

    一、版本定义

    RedHat 是由红帽公司维护的发行版本。其 RedHat 9 是最后一个以 RedHat 为名的发行版本。在 RH9 之后,版本开始分为社区维护的 Fedora 和 企业使用的 EL。而我们所说的 CentOS X 就是从 RHEL X 编译过来的。所以本质上,CentOS 的目标用户,就是企业的服务器。

    CentOS 是有 release 概念的,何为 release 概念?当某个版本定下时,其绝大多数软件包,包括 Kernel 在内,都已经确定了版本。在该 release 下,没有特殊情况,大版本号不发生变化。

    举例,CentOS 6 某个 Kernel 版本:

    2.6.32-358.el6.x86_64

    2.6.32 为 kernel 版本号,358 为打包版本号,打包版本表示该包第几次打包。对于 RHEL 来说,一个 kernel 打包个 500 700 次是很正常的事情。

    再比如一些软件,1.1.3 是版本,如果该软件自身的定义,最后一位是 bugfix 版本,倒数第二位是功能版本,那么你在 RHEL 里面,很少会看到功能更新!通常只会看到 bugfix 更新!也就是只会看到小版本号更新。

    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 。

    -------- 补充内容 -------

    我觉得我已经把我所谓的 release 概念解释的很清楚了,但是评论里面还有人在和我说 Debian 是有 release。我说的 release 不是那种自己划个时间线,叫个名字的概念。而是版本维护的概念。

    @刘世伟 说 Debian 也是这样的,那好吧,我证明给你看一下。

    你从这里 Debian -- 在 wheezy 中的 linux-image-3.2.0-4-amd64 软件包详细信息 可以拿到现在 Debian stable 的 Linux kernel 打包,下载下来,解压缩,在

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

    1. grep wheezy changelog.Debian   
    2. linux (3.2.57-3) wheezy; urgency=medium 
    3. linux (3.2.57-2) wheezy; urgency=medium 
    4. linux (3.2.57-1) wheezy; urgency=medium 
    5. linux (3.2.54-2) wheezy; urgency=high 
    6. linux (3.2.54-1) wheezy; urgency=high 
    7. linux (3.2.53-2) wheezy; urgency=high 
    8. linux (3.2.53-1) wheezy; urgency=medium 
    9. linux (3.2.51-1) wheezy; urgency=low 
    10. linux (3.2.46-1+deb7u1) wheezy-security; urgency=low 
    11. linux (3.2.46-1) wheezy; urgency=low 
    12. linux (3.2.41-2+deb7u2) wheezy-security; urgency=high 
    13. 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

    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 。

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

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

    而其继承者 Ubuntu,他是有 release 概念的,比如 9.04 ,10.06 等等,当他确定了 release 之后,他也不会在这个版本中做太大的版本变化。

    但是问题是,他学到了 CentOS 的形,没有学到 CentOS 的精华。为什么?因为他又想追求新(一年两个版本),又想学人家吃服务器市场。这是完全相互矛盾的一件事情。

    新,好办,只要跟着 Debian 走,experimental 仓库里面永远是最新的东西。拿过来,测试测试,重打包,发布!

    稳定?(Ubuntu-Server) 这就难了,这需要不断的人力投入,Debian 自然不会帮你做这件事。自己做?Ubuntu 尝试了几次,目前我没看到成功。几乎都是草草放弃。

    二、维护的力量

    你们知道什么叫维护一个服务器用的发行版本么?

    CentOS 4.0 2005-03-09

    CentOS 4.9 2011-03-02

    6年

    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 收到的更新数量就可怜。

    这才是 RedHat 的实力!你只要用我的发行版本,你不用有后顾之忧!Ubuntu 呢?开玩笑,即使是 LTS,在新版本出来以后 LTS 几乎不更新好么。补丁?从来没见过!也就是 LTS 的真正寿命也就 6个月-1年。你敢用?你敢给你们公司用?

    某天某个软件爆出类似最近 openssl 的漏洞,用 CentOS 5 的用户第二天拿到了升级的 rpm。用 Debian 的用户收到了一个大版本更新,同时由于依赖关系必须更新 glibc, kernel 等等包。用 Ubuntu 的用户收到官方回复:“apt-get dist-upgrade”

    这就是这几种发行版本在维护上的区别。

    我们再说回 RHEL,很多人不懂,以为 Ubuntu “新”,RHEL “老” 。

    你的服务器上有一块 Broadcom 的网卡,CentOS 6(2.6.32-358.el6.x86_64) 用户 modinfo 了一下

    1. filename: /lib/modules/2.6.32-358.6.1.el6.x86_64/kernel/drivers/net/tg3.ko  
    2. firmware: tigon/tg3_tso5.bin  
    3. firmware: tigon/tg3_tso.bin  
    4. firmware: tigon/tg3.bin  
    5. version: 3.124 

    Debian testing(3.12-1) 用户 modinfo 了一下

    1. filename: /lib/modules/3.12-1-amd64/kernel/drivers/net/ethernet/broadcom/tg3.ko  
    2. firmware: tigon/tg3_tso5.bin  
    3. firmware: tigon/tg3_tso.bin  
    4. firmware: tigon/tg3.bin  
    5. version: 3.133 

    你知道  的最新的 2.6.32 带的是哪个版本的 tg3 驱动么?

    1. #define DRV_MODULE_VERSION "3.102"  
    2. #define DRV_MODULE_RELDATE "September 1, 2009" 

    CentOS “老”么?谁在将最新的驱动打入老的 kernel?谁在测试新驱动与老 kernel 的兼容性?RH啊!!这些都是人力啊,这些都是财力啊。

    RH 在保证稳定、兼容的同时,尽可能的给服务器用户最全的设备匹配,最新的驱动支持。而这一切!你都不用担心稳定性、兼容性,因为 RH 没有更新大版本,没有带来 庞大 feature 的更新。

    还有一个例子:

    google RFS patch in linux kernel Linux 2.6.35 中的 RPS 功能。

    这简直就是 Linux 服务器用户梦寐以求的功能好不好,你不用再担心多核CPU被浪费,你不用花很多钱买昂贵的多 irq 网卡。但是要 2.6.35 才有哦~

    但是你不用担心,CentOS 6 (2.6.32) 已经将RPS整合进 2.6.32 的内核中了。

    你看到Ubuntu做这种事情了?Ubuntu 在忙什么?在忙着今年再发一个版本啊!

    RHEL 为什么做?因为他的用户是服务器!RPS 这种事情PC根本就用不到好不好。

    我回到最开头。我也用 Ubuntu 做过产品,虽然不是服务器。但是最后的结果并不好。我听说过一个同事的上家公司用 Ubuntu 做服务器,千级别的量。聊了一下发现和我预测的差不多,痛苦不堪。

    基本的痛苦流程是这样的

    遇到一个问题->发现只有更新软件版本才能解决->这个自己当前的版本已经不提供该软件版本->发现自己编译不过,依赖太重->决定 dist-upgrade -> 发现需要跨度N个 release -> 测试 dist-upgrade -> 10台机器,2台成功,8台失败,失败的现象不同 -> 痛苦的解决各种问题-> 成功 dist-upgrade -> 发现公司业务程序需要重新编译->与开发人员沟通 解释升级的重要性 -> 开发人员重新调试、测试一些列用到的库的新版本->交付新版本

    CentOS 用户基本是这样的:以下是最近真实对话

    “xxx,新闻你看到了么 openssl 爆漏洞了”

    “啊?不知道啊,我看看去”

    ----

    puppet 操作一下 10分钟以后

    “老板,补丁已经出来了,更新了,有 ssl 的 apache 都已经自动重启过了”

    结束~

    本文来自:http://www.zhihu.com/question/19599986

  • 相关阅读:
    RHEL6.x 删除Oracle11g
    通过IPV6上QQ及自建IPV6代理的方法
    Carrier frequency and EARFCN
    FDD LTE frequency band allocations
    Cmake参考资料
    sigal & mq_notify
    哈夫曼编码与解码
    哈夫曼数与哈夫曼编码
    算法做题顺序
    我的大学
  • 原文地址:https://www.cnblogs.com/jinhengyu/p/7669826.html
Copyright © 2011-2022 走看看