Last week I found out some interesting information when I took an initial look at two of the most popular RHEL-based Linux distributions, CentOS and Scientific Linux (SL). The next obvious step is to install the two, side by side, and continue this comparison. To be clear, I’m not running benchmarks of any sort on the two operating systems. I have no doubt that they will perform consistently enough to make that exercise un-interesting. What I’m looking for is what makes these distributions different, and anything that would make me particularly like or dislike one of these distributions.
The Setup
I set up downloads from public mirrors of both using their install DVD images. I was initially going to take all default settings, but their default settings turned out to be significantly different. So I picked the “Desktop” option for both setups, and took all other defaults.
I chose the Desktop version because I assumed it would provide the most “stuff”. A minimal runlevel 3 install, while more practical for my everyday life, would also be a short and boring talk.
They were both installed into VMWare Fusion 3 VM’s on my work-provided Macbook Pro. Each has a 20GB hard disk file and 1GB of memory.
Downloading the DVD Images
Downloading the DVD ISOs was relatively painless for both distributions. CentOS was a little faster, but I’m sure that fluctuates from mirror to mirror and over time.
Scientific Linux Installation
I installed SL first, and took all of its default settings, including installing the Desktop profile. It then prompted me that I’d require both DVD1 and DVD2 for installation. Odd, I thought. This didn’t sound familiar from the last time I installed RHEL6. So I tried other profiles, including “minimal”. It wanted both DVDs for all of them. So off I went to download another 1GB of data. Certainly not horrible but it seemed a little odd.
Installation looked identical to RHEL6, with different images, of course. The SL logo is a stylized Bohr-style atomic model. The graphics are simple and clean.
After reboot I got a black desktop with the atom logo large and on the right. The only immediately noticeable difference from the default RHEL desktop is that they’ve added a launcher button for the Gnome terminal app to the top Panel bar. While not Earth-shattering, it’s always task #3 I do to a Linux box with a GUI, so it’s a timesaver. They’ve also enabled the weather options on the Panel clock for me. While I like the idea and applaud the effort, it did make me wonder “What else are they doing to tweak the UI?”, and sent me off on a minor snipe hunt.
CentOS Installation
The CentOS install was also simple and clean. Their default install profile is “minimal”, so I picked Desktop to be consistent. Other than that the only difference were the graphics, and I took all default settings.
Oddly, CentOS never warned about nor asked me for the DVD number 2. It was happy to install only from the larger DVD image.
Rebooting after install landed me at a dark blue desktop with some stylized circle/bubble things. I like dark desktops, so this is fine with me. Clean and professional looking, it’s a huge improvement from the CentOS teal era. They don’t appear to have installed any desktop modifications, just like in previous CentOS installs.
Compare and Contrast
So how are these two distributions different? Well, those differences are few and far between at the levels I was looking into, but a few of them do make them distinctly different products.
The method I used to generate a way to figure out how they differed was to run a diff on a sorted list of their installed packages. While a little simplistic, this seemed like the way to get the most info for my buck. I’ve attached the raw sdiff at the bottom of this post.
Desktop Tweaks
SL installed SL_desktop_tweaks-6-3.noarch.rpm, which installs /usr/share/config/panel-default-setup.SL.entries. This is where my terminal shortcut, weather, and any other UI bits are coming from.
Automatic Bug Reporting Tool (ABRT)
SL doesn’t install this Fedora project at all. While I’m not a huge fan of this app, if I were newer to Linux, or not as comfortable with it as I am, I would certainly use this to push bugs into the RH bugzilla, generate error reports, etc. I really think excluding this app weakens the entire community, and I’d love to hear SL’s take on why they’ve left it out.
YUM differences
CentOS uses the fastestmirror YUM plugin, like it has in the past, to try and get you the fastest mirrors for your updates, etc. It’s not a perfect tool, but I applaud the effort, mainly because it means I’m not adding/removing mirrors to my config all the time as they come and go.
SL doesn’t use fastestmirror. Rather it hard-codes a list of ftp servers into its YUM repo configs:
This seems a little antiquated and static. I’d like to know why they haven’t moved to something more dynamic.
Also, for reasons I couldn’t quite put together, SL doesn’t include libtar as a default installation. It’s out there in its repositories, just not included on my test install. Why not?
The biggest difference, however, is that SL installs and ENABLES BY DEFAULT yum-autoupdate. Without an exclude statement of some sort (which they didn’t add in), this little gem will automatically update your, well, everything. If I were using this distribution in a production environment and didn’t notice this little guy was flipped on, it would be an almost guaranteed headache. Again, I’d like to know the rationale behind the decision. It has been mentioned on the SL forums, but as of my last reading no “why” answer or opinion has been offered by the team.
Conclusions
Well, this time I actually have a few. After digging a little deeper into these two RHEL-derived products (I won’t call them clones any more because neither truly clones RHEL), I find that they are both of high-quality, and their teams have put effort and thought into their creation. However, for me, right now, the edge still goes to CentOS. This is primarily because of what they do include (the ABRT, to help keep information flowing upstream) and what they don’t (auto-updating my system). I’d love to speak to people from both communities, and keep this conversation going on.
Raw sdiff output
Jamie-Duncans-MacBook-Pro-4:~ jduncan$ sdiff sl-list-sorted.txt cent-list-sorted.txt -s
SL_desktop_tweaks-6-3.noarch | abrt-1.1.13-4.el6.x86_64
> abrt-addon-ccpp-1.1.13-4.el6.x86_64
> abrt-addon-kerneloops-1.1.13-4.el6.x86_64
> abrt-addon-python-1.1.13-4.el6.x86_64
> abrt-cli-1.1.13-4.el6.x86_64
> abrt-desktop-1.1.13-4.el6.x86_64
> abrt-gui-1.1.13-4.el6.x86_64
> abrt-libs-1.1.13-4.el6.x86_64
> abrt-plugin-logger-1.1.13-4.el6.x86_64
> abrt-plugin-rhtsupport-1.1.13-4.el6.x86_64
> abrt-plugin-sosreport-1.1.13-4.el6.x86_64
> centos-indexhtml-6-1.el6.centos.noarch
> centos-release-6-0.el6.centos.5.x86_64
firefox-3.6.9-2.el6.x86_64 | firefox-3.6.9-2.el6.centos.x86_64
gnome-desktop-2.28.2-8.el6.x86_64 | gnome-desktop-2.28.2-8.el6.centos.x86_64
httpd-2.2.15-5.sl6.x86_64 | httpd-2.2.15-5.el6.centos.x86_64
httpd-tools-2.2.15-5.sl6.x86_64 | httpd-tools-2.2.15-5.el6.centos.x86_64
initscripts-9.03.17-1.el6.x86_64 | initscripts-9.03.17-1.el6.centos.x86_64
> libtar-1.2.11-16.el6.x86_64
nss-3.12.7-2.el6.0.sl6.x86_64 | nss-3.12.7-2.el6.x86_64
nss-sysinit-3.12.7-2.el6.0.sl6.x86_64 | nss-sysinit-3.12.7-2.el6.x86_64
opal-3.6.6-4.el6.0.sl6.x86_64 | opal-3.6.6-4.el6.x86_64
pilot-link-0.12.4-6.el6.0.sl6.x86_64 | pilot-link-0.12.4-6.el6.x86_64
plymouth-0.8.3-17.sl6.2.x86_64 | plymouth-0.8.3-17.el6.centos.x86_64
plymouth-core-libs-0.8.3-17.sl6.2.x86_64 | plymouth-core-libs-0.8.3-17.el6.centos.x86_64
plymouth-gdm-hooks-0.8.3-17.sl6.2.x86_64 | plymouth-gdm-hooks-0.8.3-17.el6.centos.x86_64
plymouth-graphics-libs-0.8.3-17.sl6.2.x86_64 | plymouth-graphics-libs-0.8.3-17.el6.centos.x86_64
plymouth-plugin-label-0.8.3-17.sl6.2.x86_64 | plymouth-plugin-label-0.8.3-17.el6.centos.x86_64
plymouth-plugin-two-step-0.8.3-17.sl6.2.x86_64 | plymouth-plugin-two-step-0.8.3-17.el6.centos.x86_64
plymouth-scripts-0.8.3-17.sl6.2.x86_64 | plymouth-scripts-0.8.3-17.el6.centos.x86_64
plymouth-system-theme-0.8.3-17.sl6.2.noarch | plymouth-system-theme-0.8.3-17.el6.centos.noarch
plymouth-theme-rings-0.8.3-17.sl6.2.noarch | plymouth-theme-rings-0.8.3-17.el6.centos.noarch
plymouth-utils-0.8.3-17.sl6.2.x86_64 | plymouth-utils-0.8.3-17.el6.centos.x86_64
redhat-logos-60.0.14-1.sl6.1.noarch | redhat-bookmarks-6-1.el6.centos.noarch
redhat-lsb-4.0-2.1.el6.x86_64 | redhat-logos-60.0.14-10.el6.noarch
redhat-lsb-graphics-4.0-2.1.el6.x86_64 | redhat-lsb-4.0-2.1.el6.centos.x86_64
redhat-lsb-printing-4.0-2.1.el6.x86_64 | redhat-lsb-graphics-4.0-2.1.el6.centos.x86_64
> redhat-lsb-printing-4.0-2.1.el6.centos.x86_64
report-0.18-7.sl6.x86_64 | report-0.18-7.el6.centos.x86_64
report-config-ftp-0.18-7.sl6.x86_64 | report-config-ftp-0.18-7.el6.centos.x86_64
report-config-localsave-0.18-7.sl6.x86_64 | report-config-localsave-0.18-7.el6.centos.x86_64
report-config-scp-0.18-7.sl6.x86_64 | report-config-scp-0.18-7.el6.centos.x86_64
report-gtk-0.18-7.sl6.x86_64 | report-gtk-0.18-7.el6.centos.x86_64
report-newt-0.18-7.sl6.x86_64 | report-newt-0.18-7.el6.centos.x86_64
report-plugin-ftp-0.18-7.sl6.x86_64 | report-plugin-ftp-0.18-7.el6.centos.x86_64
report-plugin-localsave-0.18-7.sl6.x86_64 | report-plugin-localsave-0.18-7.el6.centos.x86_64
report-plugin-scp-0.18-7.sl6.x86_64 | report-plugin-scp-0.18-7.el6.centos.x86_64
sl-bookmarks-6-1.sl6.noarch <
sl-indexhtml-6-1.sl6.noarch <
sl-release-6.0-6.0.1.x86_64 <
sl-release-notes-6.0-1.noarch <
xfsdump-3.0.4-2.el6.x86_64 <
xfsprogs-3.1.1-4.el6.x86_64 <
xulrunner-1.9.2.9-1.el6.x86_64 | xulrunner-1.9.2.9-1.el6.centos.x86_64
yum-3.2.27-14.el6.noarch | yum-3.2.27-14.el6.centos.noarch
yum-autoupdate-2-1.noarch <
> yum-plugin-fastestmirror-1.1.26-11.el6.noarch
Lost In Open Source 
Odd that, I’m quite sure I only needed DVD1 for the install right after SL6 came out, unless I’ve got amnesia.
I thought it was weird too. Haven’t installed a second time. Will do that sometime this weekend, but I didn’t click anything at all… 100% defaults on Scientific Linux.
I think you should explain why you don’t want to install security updates automatically and why you are willing to overlook CentOS’s history of no updates between releases.
I don’t think I said either of those things.
If you want to be part of the conversation, great.
If you want to be part of the community and help CentOS or SL or AscendOS or anything, even better.
If you want to make ignorant generalities with no support or actual knowledge, then bugger off. There are too many of you out there, already.
Ivan was just being pushy about the recent security patch lag time between SL and CentOS. SL has been faster with security updates lately, and they have a dedicated staff for it which CentOS lacks, but you are trying to be thorough and objective in your comparisons (nice effort here, by the way, its a useful read) and that would mean researching the RHEL patch dates and comparing the historical lags in a complete way instead of just making spot comparisons — and that’s something I doubt you have time for.
In other news, the install DVD issue is a funny one. The “Everything DVDs” are not really the perferred or standard method for SL6 (they are really intended to be quick repository/PXE boot drop-ins for networks isolated from the Internet) — the way to get a single disk install is through the “Install DVD” images. The labeling is perhaps a bit confusing here, maybe “Everything-DVD” 1 & 2 should be changed to “Insta-repository DVD” or something similar for clarity. A lot of people have made this mistake and installed from Everything instead of Install, so its not just you.
Part of the assumption in SL is that the heaviest use cases would be at places like the labs it was originally intended for, and those sort of places run their own local repositories. Having yum-autoupdate enabled by default assists this, as the admin can be confident that non-kickstart situations (like laptop dual installs, which are common in some places) won’t have to be manually tweaked to get updates: the updates will just happen when the local repo is updated.
Anyway, these are tailored use-case issues, and yum being what it is any of it is easy to adjust via kickstart (which is why this was considered a minor issue — and that pervades SL, by the way, there is very little hand holding, including inside the community).
Nice article. Keep it up. I’m interested to see what you have to say about 6.1 whenever CentOS gets that out for comparison.