被低估的和被高估的

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

Ubuntu

Fedora

CentOS

中文资源站

网易开源镜像站

这是一个创建于 4389 天前的主题，其中的信息可能已经有所发展或是发生改变。

看过 SUSE Linux Enterprise Server 的 Release Notes， Red Hat Enterprise Linux 的 Release Notes 和 Technical Notes 后去看 Debian 的 Release Notes，差距是非常大的。企业版 Linux 高出社区版太多。

SLES 11 SP3 Release Notes
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/

RHEL 6.5 Release Notes
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.5_Release_Notes/index.html

RHEL 6.5 Technical Notes
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.5_Technical_Notes/index.html

Debian Wheezy Release Notes
http://www.debian.org/releases/stable/amd64/release-notes/

我觉得 Google 在 GCE 上用 Debian 这件事没有参考价值，这个撸出 Chrome OS （Chromium OS 的 Security Overview http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview ）的公司用的 Debian 肯定和我在 VPS 上用的完全不是同一款。

第 1 条附言 2014 年 1 月 22 日

我经常会想，如果使用 SLES 和 RHEL 的开发者和运帷能把官方文档完整看一遍，同时读一遍 Max RPM 学会打 RPM 包的话，抱怨被折腾死的人是否会减少 90%

Notes

release

Linux

14 条回复 1970-01-01 08:00:00 +08:00

9hills

2014 年 1 月 22 日 via iPad

文档写得好就是高出很多么。。

你可以看着Rhel的文档用者centos啊。。

Comphuse

2014 年 1 月 22 日 via iPhone

@9hills
...... 我想说的是，SLES 和 RHEL 是工业品，你看一下Release Notes 就知道了

Comphuse

2014 年 1 月 22 日 via iPhone

@9hills 这是我读过三者的文档，中度使用过他们或者其等价体之后的感想。

virushuo

2014 年 1 月 22 日

http://blog.devep.net/virushuo/2014/01/21/delllinux_kernel_bugcpu.html

昨天我碰上这个事情之后最大的感触就是，企业版虽然保守，但在关键时刻会更靠谱点。

msg7086

2014 年 1 月 22 日

@Comphuse 嘛RHEL和SLES本来就是企业级的产品嘛。

就像大公司如果要买服务器的话，无非是像dell啊sun啊ibm啊这种服务器。但是小公司或者是个人/组织用的话，随便堆一台兼容机都可以。

像这些企业级产品，比如RHEL这样的，更多的是关注系统的稳定运行。比如我以前一个人口较多的公司，跑PHP还在用4.4，跑MySQL还在用3.x，一台机器5、6年了不换。后来换了别的地方，经常急于比较新的平台做开发，PHP5 MySQL5 nginx各种。上ror的话ruby2 rails4各种。这你就得老老实实依赖更新更快的系统，而像Debian这样的就比较适合了。

归根结底还是看应用环境吧

efi

2014 年 1 月 22 日 via Android

区别体现在支持上。支持就是保险。企业版拿人钱财替人消灾。社区版免费产品责任自负。文档也是一种支持。没有文档用户就只能去看源码。

至于最新特性。企业版是伸手则有私人定制，社区版囫囵吞枣照单全收。

est

2014 年 1 月 22 日

这得看你是最求最新最潮最快升级的东西还是稳定保守的东西。比如docker要求内核支持cgroup，不过后来rh看不惯了就顺手backport了。

xiaket

2014 年 1 月 22 日

@virushuo 这种驱动问题Debian官方修得也挺快的, 话说昨天读了你这篇后最大的收获是用bc压CPU那段, 很漂亮~

virushuo

2014 年 1 月 22 日

@xiaket 至少到现在，别家都没修（也有可能是修了我没找到）。。。bc那个是很常见的办法，不是我发明的，惭愧。。。

Moods

2014 年 1 月 22 日

还是看使用环境和侧重点。

9hills

2014 年 1 月 22 日

@Comphuse 你能告诉我RHEL和CENTOS的区别么。。

RHEL更多的是系统支持，但是如果你的公司大到一定程度，比如我厂就不需要RHEL的支持，自己雇人，开个系统部就好

efi

2014 年 1 月 22 日

@xiaket 这样一个内核级的bug，RHEL的处理方式就是用户去bugzilla开一个bug，PM跟进标上优先级，催自家养的上游开发来看，上游开发又可以拿到lkml跟其他上游讨论，问题查得差不多了出path，出完给QE验证，然后测一遍regression，再做出rpm，发advisory推送给伙伴和用户。

Debian的处理方式就是先用户四处胡乱报bug，然后没人管，等上游出了patch，过了两周进了mainline，再过了两周进了gregkh的stable内核，再过了两周Ben Hutchings编出新deb传到sid，再过一周没有听说什么大面积崩溃就进了testing，用户一更新，也不知道什么时候修复了。

Comphuse

2014 年 1 月 22 日 via iPhone

@9hills 前一段时间 CentOS 出过一次内核更新后无法启动的 Bug，提示缺少签名密钥，然后当天官方重新编译了一下内核解决。这不是上游 bug。你可以去 CentOS Bugzilla 搜一下。

se77en

2014 年 1 月 22 日

每次 CentOS 编译完 Redhat 给的源码发现性能就是要跟 Redhat 差一大截，没办法，商业公司肯定会用一点黑魔方的