<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://www.jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://www.jackxiang.com/post//</link>
<title><![CDATA[[转]服务器操作系统应该选择 Debian/Ubuntu 还是 CentOS？]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[Unix/LinuxC技术]]></category>
<pubDate>Tue, 10 Jan 2017 14:21:28 +0000</pubDate> 
<guid>http://www.jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	<br/>首先的首先，我想请各位玩家，你们不要自己最近新玩上什么就觉得什么好，然后大肆的推荐什么好不好！负点责任好不好！人家是服务器，有些时候选错一个发行版本会痛苦死一批人！<br/><br/>是，你现在终于发现有个版本叫 Ubuntu 了，好爽啊，那么多包，随便 apt-get , 3万个包躺在仓库里面不用编译。好爽啊！几乎所有软件都有最新版本用！唉？过两天你发现 Ubuntu 原来是从 Debian 来的，Debian 才叫牛啊，完全社区运作，包的数量一点都不少啊。再过两天发现 Gentoo 啦，哇塞，牛啊！性能的极致优化，编译编译再编译，configure , configure 再 configure ，精简到极致。再过两天 Gentoo 玩腻了，不就是编译么～ 唉？ 原来还有 Arch 啊，这个不错啊，想编译的编译，不想编译的也有默认包。然后2个月没 pacman 更新过的系统，更新一下全挂了。<br/><br/>你的意识形态，走在任何一个阶段都认为这个阶段是最好的选择。但事实并不是这样的，这只是你的兴趣而已。<br/><br/><br/><br/>要讨论这个问题，先要知道两大发行版本的区别在哪里。RedHat 和 Debian。<br/><br/>一、版本定义<br/>RedHat 是由红帽公司维护的发行版本。其 RedHat 9 是最后一个以 RedHat 为名的发行版本。在 RH9 之后，版本开始分为社区维护的 Fedora 和 企业使用的 EL。而我们所说的 CentOS X 就是从 RHEL X 编译过来的。所以本质上，CentOS 的目标用户，就是企业的服务器。<br/><br/>CentOS 是有 release 概念的，何为 release 概念？当某个版本定下时，其绝大多数软件包，包括 Kernel 在内，都已经确定了版本。在该 release 下，没有特殊情况，大版本号不发生变化。<br/><br/>举例，CentOS 6 某个 Kernel 版本：<br/><br/>2.6.32-358.el6.x86_64 <br/><br/>2.6.32 为 kernel 版本号，358 为打包版本号，打包版本表示该包第几次打包。对于 RHEL 来说，一个 kernel 打包个 500 700 次是很正常的事情。<br/><br/>再比如一些软件，1.1.3 是版本，如果该软件自身的定义，最后一位是 bugfix 版本，倒数第二位是功能版本，那么你在 RHEL 里面，很少会看到功能更新！通常只会看到 bugfix 更新！也就是只会看到小版本号更新。<br/><br/>Debian 是由社区维护、贡献的发行版本，其从选包、打包、都是由社区组织，分散行动的。<br/><br/>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 。<br/><br/>-------- 补充内容 -------<br/><br/>我觉得我已经把我所谓的 release 概念解释的很清楚了，但是评论里面还有人在和我说 Debian 是有 release。我说的 release 不是那种自己划个时间线，叫个名字的概念。而是版本维护的概念。<br/><br/>@刘世伟 说 Debian 也是这样的，那好吧，我证明给你看一下。<br/><br/>你从这里 Debian -- 在 wheezy 中的 linux-image-3.2.0-4-amd64 软件包详细信息 可以拿到现在 Debian stable 的 Linux kernel 打包，下载下来，解压缩，在<br/><br/>usr/share/doc/linux-image-3.2.0-4-amd64 目录下面有一个 changelog.Debian ，grep 一下：<br/><br/>grep wheezy changelog.Debian<br/>linux (3.2.57-3) wheezy; urgency=medium<br/>linux (3.2.57-2) wheezy; urgency=medium<br/>linux (3.2.57-1) wheezy; urgency=medium<br/>linux (3.2.54-2) wheezy; urgency=high<br/>linux (3.2.54-1) wheezy; urgency=high<br/>linux (3.2.53-2) wheezy; urgency=high<br/>linux (3.2.53-1) wheezy; urgency=medium<br/>linux (3.2.51-1) wheezy; urgency=low<br/>linux (3.2.46-1+deb7u1) wheezy-security; urgency=low<br/>linux (3.2.46-1) wheezy; urgency=low<br/>linux (3.2.41-2+deb7u2) wheezy-security; urgency=high<br/>linux (3.2.41-2+deb7u1) wheezy-security; urgency=high<br/>起码在 wheezy 里面(stable) 里面，他从 3.2.41 走到了 3.2.57 , 同时…… 你们可以看到 每个版本也就打包 1-2 次，1-2次啊！而且 Debian 的 unstable 走到 stable 真的就是随便走走的。<br/><br/>linux (3.2.41-2+deb7u1) 是第一个 stable 版本，他的上一个版本是<br/><br/>linux (3.2.41-2) unstable ，好，3.2.41 第二次打包，加了一次 patch 就变成 stable 了<br/><br/>linux (3.2.41-1) unstable ， 得，41 就打了一次<br/><br/>linux (3.2.39-2) unstable ， 39 也就打两次。<br/><br/>从这个过程，你可以看出，Debian 总体上，还是在跟着 Kernel Source 的，为啥？没人啊！靠零散的人打 patch 还不如依赖 Kernel 本身的小版本更新。<br/><br/>RedHat 呢？<br/><br/>放一个 RHEL 6.4 的 Release Note<br/><br/>https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html<br/><br/>RHEL , 是不跟 kernel source 的小版本号的，自己整合 bugfix ，主要是安全相关的补丁。<br/><br/>为什么不跟 kernel source 呢？<br/><br/>主要还是目标用户的不同，就像我下面驱动这块要解释的。RHEL 的目标用户，是企业的 Server 的，他的 Kernel 里面，已经太多的东西被替换掉了。磁盘、网卡、各种各样的驱动。而 Kernel source 尽管只走小版本号，还是不太靠谱的。频繁的拿过来风险也大。<br/><br/>kernel 其实走到 2.6 以后，就没有一个真正稳定的概念了。反正就是一路往前走。当然 2.6.32.xx 的确是以 bugfix 为主的。但是这个量太大了，各种各样鸡毛蒜皮，RHEL 不是全都拿进来的。<br/><br/>你们一定要和我争论版本的问题，行，我不和你们争，Debian Stable 是有版本的～ 你们满意了？这种一个 kernel 打包 2次的状态，你们爱用就用好了。无所谓的。<br/><br/>但是有 版本的也只是 stable，testing 我可从来没见过。<br/><br/>说实话，我真的花了心思想多找一点 Debian 的信息，<br/><br/>11年进入 stable 的 6.0 , 最近确实还有一个更新，在 08 Apr 2014 。<br/><br/>http://metadata.ftp-master.debian.org/changelogs//main/l/linux-2.6/linux-2.6_2.6.32-48squeeze5_changelog<br/><br/>09年发布的 lenny 也就是 5.0 ，根本已经连信息都很难找了。如果谁能找到 lenny 麻烦给一个 kernel 的 changelog<br/><br/>----- 补充结束 -------<br/><br/>而其继承者 Ubuntu，他是有 release 概念的，比如 9.04 ,10.06 等等，当他确定了 release 之后，他也不会在这个版本中做太大的版本变化。<br/><br/>但是问题是，他学到了 CentOS 的形，没有学到 CentOS 的精华。为什么？因为他又想追求新（一年两个版本），又想学人家吃服务器市场。这是完全相互矛盾的一件事情。<br/>新，好办，只要跟着 Debian 走，experimental 仓库里面永远是最新的东西。拿过来，测试测试，重打包，发布！<br/><br/>稳定？(Ubuntu-Server) 这就难了，这需要不断的人力投入，Debian 自然不会帮你做这件事。自己做？Ubuntu 尝试了几次，目前我没看到成功。几乎都是草草放弃。<br/><br/>二、维护的力量<br/>你们知道什么叫维护一个服务器用的发行版本么？<br/><br/>CentOS 4.0 2005-03-09<br/><br/>CentOS 4.9 2011-03-02<br/><br/>6年<br/><br/>Ubuntu 8.04 LTS April 24, 2008<br/><br/>Ubuntu 8.04.4 LTS January 28, 2010<br/><br/>1年9个月<br/><br/>你说好的 LTS 呢？？？<br/><br/>Ubuntu 10.04 LTS April 29, 2010<br/><br/>Ubuntu 10.04.4 LTS February 16, 2012<br/><br/>说好的 LTS 呢？<br/><br/>说 End of the Date 是3年整就是一个笑话，只要下个 release 一出，上个 release 收到的更新数量就可怜。<br/><br/>这才是 RedHat 的实力！你只要用我的发行版本，你不用有后顾之忧！Ubuntu 呢？开玩笑，即使是 LTS，在新版本出来以后 LTS 几乎不更新好么。补丁？从来没见过！也就是 LTS 的真正寿命也就 6个月-1年。你敢用？你敢给你们公司用？<br/><br/>某天某个软件爆出类似最近 openssl 的漏洞，用 CentOS 5 的用户第二天拿到了升级的 rpm。用 Debian 的用户收到了一个大版本更新，同时由于依赖关系必须更新 glibc， kernel 等等包。用 Ubuntu 的用户收到官方回复：“apt-get dist-upgrade”<br/><br/>这就是这几种发行版本在维护上的区别。<br/><br/>我们再说回 RHEL，很多人不懂，以为 Ubuntu “新”，RHEL “老” 。<br/>你的服务器上有一块 Broadcom 的网卡，CentOS 6（2.6.32-358.el6.x86_64） 用户 modinfo 了一下<br/><br/>filename: /lib/modules/2.6.32-358.6.1.el6.x86_64/kernel/drivers/net/tg3.ko<br/>firmware: tigon/tg3_tso5.bin<br/>firmware: tigon/tg3_tso.bin<br/>firmware: tigon/tg3.bin<br/>version: 3.124<br/>Debian testing（3.12-1） 用户 modinfo 了一下<br/><br/>filename: /lib/modules/3.12-1-amd64/kernel/drivers/net/ethernet/broadcom/tg3.ko<br/>firmware: tigon/tg3_tso5.bin<br/>firmware: tigon/tg3_tso.bin<br/>firmware: tigon/tg3.bin<br/>version: 3.133<br/>你知道 http://kernel.org 的最新的 2.6.32 带的是哪个版本的 tg3 驱动么？<br/><br/>#define DRV_MODULE_VERSION &quot;3.102&quot;<br/>#define DRV_MODULE_RELDATE &quot;September 1, 2009&quot;<br/>CentOS “老”么？谁在将最新的驱动打入老的 kernel？谁在测试新驱动与老 kernel 的兼容性？RH啊！！这些都是人力啊，这些都是财力啊。<br/><br/>RH 在保证稳定、兼容的同时，尽可能的给服务器用户最全的设备匹配，最新的驱动支持。而这一切！你都不用担心稳定性、兼容性，因为 RH 没有更新大版本，没有带来 庞大 feature 的更新。<br/><br/>还有一个例子：<br/>google RFS patch in linux kernel Linux 2.6.35 中的 RPS 功能。<br/><br/>这简直就是 Linux 服务器用户梦寐以求的功能好不好，你不用再担心多核CPU被浪费，你不用花很多钱买昂贵的多 irq 网卡。但是要 2.6.35 才有哦～<br/><br/>但是你不用担心，CentOS 6 (2.6.32) 已经将RPS整合进 2.6.32 的内核中了。<br/><br/>你看到Ubuntu做这种事情了？Ubuntu 在忙什么？在忙着今年再发一个版本啊！<br/><br/>RHEL 为什么做？因为他的用户是服务器！RPS 这种事情PC根本就用不到好不好。<br/><br/>我回到最开头。我也用 Ubuntu 做过产品，虽然不是服务器。但是最后的结果并不好。我听说过一个同事的上家公司用 Ubuntu 做服务器，千级别的量。聊了一下发现和我预测的差不多，痛苦不堪。<br/><br/>基本的痛苦流程是这样的<br/><br/>遇到一个问题-&gt;发现只有更新软件版本才能解决-&gt;这个自己当前的版本已经不提供该软件版本-&gt;发现自己编译不过，依赖太重-&gt;决定 dist-upgrade -&gt; 发现需要跨度N个 release -&gt; 测试 dist-upgrade -&gt; 10台机器，2台成功，8台失败，失败的现象不同 -&gt; 痛苦的解决各种问题-&gt; 成功 dist-upgrade -&gt; 发现公司业务程序需要重新编译-&gt;与开发人员沟通 解释升级的重要性 -&gt; 开发人员重新调试、测试一些列用到的库的新版本-&gt;交付新版本<br/><br/>CentOS 用户基本是这样的：以下是最近真实对话<br/><br/>“xxx，新闻你看到了么 openssl 爆漏洞了”<br/><br/>“啊？不知道啊，我看看去”<br/><br/>----<br/><br/>puppet 操作一下 10分钟以后<br/><br/>“老板，补丁已经出来了，更新了，有 ssl 的 apache 都已经自动重启过了”<br/><br/>结束～<br/><br/> <br/><br/>最后再解释一下，我之前的评论<br/><br/>“不会用就别怪系统不好。推荐 Debian/Ubuntu 跑 Server 是一件很不负责的事情。”<br/><br/>任何 Linux 发行版本，在理论上都是一样的。只不过操作有的方便，有的麻烦！是，yum 是比 apt 弱（这就是企业维护和社区维护的区别，企业自己维护不需要这么多功能）但是任何能在 A 发行版本上实现的效果，一定是能在 B 上实现的。你甚至可以按照玩 Gentoo 的思路玩 CentOS，编译么！你自己打 RPM 啊，你自己缩减依赖关系啊，你可以说麻烦，但是你不可能说不能实现。<br/><br/>所以，我还是要重说一遍：“不会用就别怪系统不好”！这不是歧视，这不是嘲讽，这是让你认清事实之后能把时间花在更加有用的地方！<br/><br/>第二句！“推荐 Debian/Ubuntu 跑 Server 是一件很不负责的事情。” 这是血和泪的教训！你不想听无所谓，但是总有一些人冒着要被戴“不友善”的帽子，也要告诉你这个事实！<br/><br/>我再来补充一句，没有不尊敬的意思。但是大多数圈内用 Gentoo -- 类似豆瓣还是 VeryCD 这样的公司，你们当时做出这个决策的人基本上都是把自己的 兴趣 &gt; 公司 利益了。潜在的，这其实是一种不负责任的行为，会直接的导致公司的维护成本的增加。<br/><br/>你真的以为你用 Gentoo 做到的性能，CentOS 做不到么？<br/><br/>你真的以为你们一个小 team 打包的质量会一定比 RH 一家公司的工作人员要牛么？<br/><br/>如果你当时真的这么以为，只能证明你当时还不会用罢了。<br/><br/>如果我今天告诉大家，我要做一个 http 的服务器，我不用 apache 不用 nginx，为了性能我要用 xxx 为基础重写一套出来。我相信绝大多数人会问同样的问题，“你觉得你写的能比 ng 好么？”<br/><br/>再回头看看那时候你们自己吧。<br/><br/>我不希望，把这个回答变成用各个版本的人的之间的争执，其实没有意义。我只是说，在现在的状态下首推的依旧是 CentOS。我个人在 PC vm 上，用 Gentoo，家里的 HomeServer 用 Debian，公司自然都是 CentOS<br/><br/>至于 Debian 上服务器，你们要是喜欢也 OK，不会有太大的问题。但真心不如 CentOS 省心。<br/><br/>Ubuntu ....... 真的很惨<br/><br/>Gentoo ....... no zuo no die<br/><br/>关于 Debian 的补充：<br/><br/>评论1：<br/>Debian 其实在很多不是那么重要的环境中是很好的选择方案。[不是那么重要的意思是，即使宕机十几分钟、半小时老板也不会和你数钞票的损失。]<br/><br/>为什么？<br/><br/>1. 足够数量的包。<br/><br/>2. testing 具有可以接受的可靠性。(与 Arch 相比) 3. testing 具有非常好的软件更新速度。<br/><br/>3. testing 不具有 release 特性，永远平滑升级（与 Arch Gentoo 一样）。<br/><br/>而 Fedora 与 Ubuntu 类似，具有 release 特性，但一旦新版本出来，老版本维护很少。同时 dist-upgrade 过程并不友好，体验很糟糕。所以如果让我个人选择，学校机房我也会用 Debian。我回答中，也提到我的 HomeServer 是用 Debian 的。其实以前是用 Arch 的，但是 Arch 稳定性真的很差，一个 pacman -Syu 玩死你。在尝过痛苦以后，切换到 Debian Testing，跑了2年左右了，感觉还是很可靠的。<br/><br/><br/>@戴云杰 回答下的评论：<br/><br/>Gentoo 能够激起情怀-&gt;于是工作效率大增-&gt;公司利益得到保障。哈哈哈，你赢了。还是要分场合的，60 还过得去 6000呢？我也用 Gentoo 做过产品啦，不过不是服务器。TVU networks 的 x86 产品就是我决定转移到 Gentoo 的。在这个产品上，很好的利用了 Gentoo 定制方便，平滑更新的特性，因为 TVUPACK 需要适配最新的 USB Modem。唯一遗憾的是，我没有来得及给它一套二进制分发系统。如果下次还有机会，我一定会想办法做一套。在 Server 上编译，不是我的风格，太脏。我曾经把 CentOS 5 精简到 96 个 RPM 依旧可以开机。CentOS 6 只能做到 100 以上了。<br/><br/>但是，还是要分事情的。我也会花很多时间调试 VIM 写 bash 写 python，但是我开始写 Cocoa 了，我果断放弃 VIM，必须 xcode。<br/><br/>我猜测很多新手（好吧，show B ge 的时候到了）觉得发行版本之间的讨论会类似于早期各种开发语言之间的类似宗教性的讨论[抨击]。<br/><br/>其实并不是这样的，因为熟悉使用一个发行版本的代价远小于熟悉一门开发语言。5-10年的时间，足够你熟悉主流的发行版本。足够让一个高手做到物尽其用，适宜即可。<br/><br/>我不是任何发行版本的粉，我在公司服务器用 CentOS，我在 HomeServer 用 Debian，我在 CubieBoard 用 Debian，我在路由器上用 openwrt ，我在 PC 上用 OSX，我在 PC VM 上用 Gentoo。因地制宜，此乃最高境界。<br/><br/>其实戴云杰是把个人利益＝＝公司利益了哈，我给了个赞，赞是赞这份情怀。有很多事情，你喜欢就够了，我尊重每一个人的喜欢，你其实不需要太多理由的，当初我干这行也仅仅是为了“喜欢”。<br/><br/>再说了，戴云杰老板都出来给点赞了，我还有啥好说的，哈哈。<br/><br/>@素包子 下的评论：<br/><br/>我能够理解你，但是我不赞同你。为什么？<br/><br/>因为我也有把用 XXX 当魄力的年纪，我觉得这样很有趣，很Cool，很特别，我希望自己与众不同，或者我告诉自己我能学到更多的东西(是的，的确可以)。<br/><br/>但是当我经历了这个阶段，回头看的时候。我知道了两点，1. 这个过程是有价值的，没有这个过程，不会成为今天的我。2. 这个过程太花时间了。我投入了比别人多 100% 的经历，来获取比别人多 30% 的知识。可能还有更好的路可以走？<br/><br/>今天我的同事来告诉我，他要自己编译 apache 放到线上，我告诉他。你不要这么做，用 CentOS 自带的就可以了，节约下来的时间你可以真的搞清楚 apache 各种性能相关的参数（相信我，很多人都搞不清），你还可以研究一下如何让开发人员在受控的环境下自由的发布新的版本，且同时具有良好的回退功能而不用让运维介入。你还可以写一套系统每周验证一次备份的数据库是否能够正常加载。<br/><br/>相信我，实际的运维工作中，有太多值得做而没有人做的工作了。他们都比你在那里 configure 来的有意义的多。<br/><br/>嗯，论年龄，应该是前辈了，RH 6 啊？查了一下 1999 年的东西，我还在念初中呢。<br/>@纸糊<br/><br/>1.“RedHat系列好使我没意见，可是你给用户付钱啊？” <br/><br/>所以我们在谈 CentOS 啊？你不知道他们之间的关系？去看看吧。<br/><br/>2. “关于支持时间的问题，支持时间短一点也是已经告诉你的，这个不至于成为喷点吧” 啊？“Ubuntu 尝试了几次，目前我没看到成功。几乎都是草草放弃。”<br/><br/>Ubuntu 说 LTS 是 3年，可以从历史的维护时间看，很少维护到三年。<br/><br/>这是我要表达的。你不知道 LTS 是 3年？<br/><br/>3. “某天某个软件爆出类似最近 openssl 的漏洞“ <br/><br/>嗯，你引用了我的原话，请注意我想说的是 ”类似“。而并不是就是这次的 openssl。<br/><br/>说道 openssl 的修复，你的表述是不正确的。<br/><br/>这次的 openssl 修复有两个方式，其一是更新至 openssl 小版本，其二是重新编译将引发问题的功能关闭。并不只是上游修复这一种方式。 <br/><br/>RedHat 应该是采用了第二种，因为他更新的是 1.0.1e-16 只是打包号增加了。（注意 RedHat 还是尽可能的维护版本，我不知道 Debian 是不是这么做的，还是升级到了 1.0.1f？可能答主知道？）<br/><br/>这是题外话…… 我在这里想表达的是，Debian 的组织方式，可能会受到连带更新，尤其是在 Testing 环境中，因为 Debian 在Testing中是不断往前走的。比如 A 依赖 B，B 在不断的往前走，A 遇到了 Bug，于是在下次更新中 A 和 B 有可能会被同时更新。在 Testing 中这种现象是存在的。Stable 中应该不会。 <br/><br/>同时我已经在某些评论中认可，我对 Debian 的描述有夸张的成分。<br/><br/>4. 你想用 squeeze、wheezy 是你的事情，因为你这么用了，所以我不这么用，就体现出了我不懂？我BB？你太抬举你自己了，好歹给点理由吧。<br/><br/>而且我答题的最后也已经说了 ，你用 Debian 做服务器，没什么大问题。<br/><br/>我不推荐的原因我已经描述的很清楚了，kernel 上比 RedHat 弱很多，你们想有反驳意见冲着这个来。<br/><br/>这这么短的针对我的答案评论的答题中，至少体现了三点你”不懂“的东西，我觉得你还是多看看再说吧。<br/><br/>另外，礼貌一点，没有人会把你当傻子。 有很多人都会陷入一种境地，通过攻击别人来体现自己的高大。其实真正内心强大的人，根本不需要这样做。<br/><br/>就像一个评论 Gentoo 的主，一定要说我在攻击 Gentoo，但是其实评论中，尽一切机会显示他有多么多么懂 Gentoo，自己多么多么会用。至于么？你体现自己能力的方式一定是先要将别人放置在你的对立面？low……<br/><br/>我建议大家看看《河南人惹谁了》这本书，里面提到，地域歧视的深层心里，其实是通过歧视别人来提高自己的地位。就像一个美国街头流浪人，跑来歧视中国人，当他说出、做出歧视性的语言、行为的时候，其实潜在的内心是利用这样的机会来提高自己心里的优越感。<br/><br/>而这样的心里状态，在我们生活中是无处不在的。“我必须贬低你！才能体现我的正确性。”
]]>
</description>
</item><item>
<link>http://www.jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] [转]服务器操作系统应该选择 Debian/Ubuntu 还是 CentOS？]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://www.jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>