When Red Hat discontinued the free Red Hat Linux and introduced Red Hat
Enterprise Linux (RHEL), demand for clones spawned a slew of clones based
on RHEL sources. Many of the projects — White Box Enterprise Linux,
Tao Linux, and Lineox — have since gone offline or simply gone
silent. Only CentOS and Scientific Linux have survived
the long haul, and only Scientific Linux has managed to put out a release
based on RHEL 6.0. It is also keeping pace with 6.1 as the Scientific Linux 6.1 alpha released less than two weeks after RHEL 6.1.
Scientific Linux is a distribution pulled together from the source of
RHEL. It started life as High Energy Physics Linux (HEPL), developed by Connie Sieh. After Sieh solicited input from other labs and universities, two things were clear — there was definitely interest in a lab-focused distribution from RHEL sources, and the name wasn't quite right for labs and universities not working with high energy physics.
The name was changed to Scientific Linux and the first release (3.0.1) came out on in May of 2004. Since then, the project has followed RHEL releases fairly closely — though there was a significant delay between the release of RHEL 6.0 (November 2010) and Scientific Linux 6.0 (March 2011). With the 6.1 release, Scientific Linux is closing the gap — RHEL 6.1 was released in mid-May, with the first alpha for Scientific Linux out on June 1st.
Scientific Linux 6.1 carries the same updates
as the upstream release, as well as a couple of minor tweaks. Specifically,
6.1 has a new graphical theme called "Edge of Space," and has moved some of SL's repositories (testing and fastbugs) to an optional package rather than enabling them by default.
Differences Between Scientific Linux and RHEL
Unlike other RHEL clones, Scientific Linux is not an attempt to produce
an exact duplicate of RHEL, minus branding. While Scientific Linux does try
to be as close as possible, changes are made. However, the delta between Scientific and RHEL is decreasing greatly over time.
Linux customizations page leads to information on added packages
between the upstream and the corresponding Scientific release. According to
core contributor Troy Dawson, the
6x series has the fewest changes from upstream. In the default install,
only yum-autoupdate (which does what the name suggests) is added to
upstream's package selection. Users can also choose to install IceWM, the OpenAFS distributed filesystem, a handful of yum repositories, and Scientific Linux's tools for creating "sites."
Sites, also known as spins, are custom configurations of Scientific Linux. Dawson says that the ability to create spins have required installer tweaks in SL3 through SL5, but it has required fewer changes from release to release — and no changes in SL6 (modulo branding, of course). A few spins for other labs are listed on the Scientific Linux Website, but none are based on SL6 yet.
According to Dawson, the reduction in changes and additional packages comes at the request of the community. "This was due to requests from the HEP community that we quit adding our own packages and start utilizing the other community based repositories, such as EPEL and RPMForge." In some cases, changes between upstream and Scientific are available as "tweak RPMs," which Dawson says "change something after the regular RPM is installed." Dawson says most of the tweak RPMs are not installed by default.
If users want to further customize Scientific Linux, they can use Revisor to create a site, assuming they have the full distribution mirrored. The project already has the documentation for creating sites for SL6 including RPMs that require special attention during builds. Sieh says that Scientific Linux is using Koji to do its building, and then Revisor to create the ISO images and network tree — and Scientific Linux does provide the config files necessary to replicate the build. In most cases, though, Sieh says that if a user simply wants minor changes the easiest way is to build the packages manually and use Revisor to create a custom distribution rather than trying to replicate an entire Koji build environment.
Scientific Linux seems to be gaining in popularity recently, no doubt in
part due to being first to deliver a release based on RHEL 6.0. According
to its statistics page (which only measures downloads from the main sites
— not mirrors) downloads
of 6.0 have had a bigger spike than previous SL releases, which seems to indicate that non-lab use of Scientific Linux is growing. For prior releases of Scientific, Dawson says that "I'm pretty sure about half our users were labs, universities, and other scientific and educational places" where Scientific Linux was primarily used on compute nodes. With the SL6 release Dawson says "I really don't know" who the average user is, but he does think that the profile has changed.
One thing that is attractive about Scientific Linux, aside from the obvious, is that the Scientific Linux team has been proactive in sending out status updates, and notifying its community of unavoidable delays.
Dawson says that the project does try to have security updates
"pushed out and announced within 24 hours of the upstream vendor
announcing" the updates. For non-security errata, updates are pushed
out once per week into the "fastbugs" repository — with a few
exceptions. According to Dawson, one exception is if the Scientific team
has problems building an RPM for one reason or another. He also says that
after a major release from Red Hat, updates are slowed while the team works
on that. Finally, Dawson says that they hold onto kernel changes for a few
days "just to make sure we don't see any yelling" on the Red
Hat mailing list about the new kernels. "It generally takes a couple
weeks to get their latest security errata built and tested to our
satisfaction. An example would be when RHEL 6.1 came out. We didn't
release any security updates for SL 6.0 until this week. So it took a week
and a half to get the security errata out."
The reason for the delay is that Scientific Linux is
backporting security fixes to 6.0. Dawson adds that he still has three
packages that are waiting on updates: sssd, qemu-kvm, and libguestfs.
The sssd package pulls in several dependencies from 6.1, so it's
getting extra testing. The qemu-kvm package hasn't passed the QA
tests, but Dawson says he's hoping to have it ready next week for
SL6.1 as well as SL6.0 security errata. Finally, libguestfs is delayed
because it depends on qemu-kvm.
In other words, the updates generally appear within a day for security releases and within a week for other errata. However, users should be aware that this is not an iron-clad guarantee that security updates or errata will be available in as timely a fashion as they might like. However, Scientific Linux has a fairly good track record. What's the secret to providing consistent updates over the long haul? It doesn't hurt that Scientific Linux has folks like Dawson and Sieh that are paid to work on Scientific Linux (at least in part) by Fermilab — and the entire development team is not allowed to go on vacation at the same time so at least one developer is always available.
Dawson says that Fermilab has reorganized recently, and added two more
developers to the team working on Scientific Linux (Jason Harrington and
Tyler Parsons), in addition to Dawson and Sieh. CERN also contributes
"a person here and there, usually Jaroslaw Polok" and Stephan
Wiesand from Deutsches Elektronen-Synchrotron (DESY) worked on the OpenAFS packages and a few others. But
nobody is paid to work full-time on Scientific Linux:
The Fermilab group is paid to work on Scientific Linux, although it's only
one part of our job description. If any of us are not working on Scientific
Linux, we would still have more work than we can do in a day. Both Connie
any myself put in as many after work hours as is needed during critical
times. I believe for all of the developers outside Fermilab it is the
same. The labs they work at allows them to work on their respective
projects during work, but they also do a lot of SL work after normal work
But the project is open to outside contribution as well. Dawson says that the best way to be involved is "find something you think you can do and do it. Many people point out 'you should do this' but very few actually do it." He noted that Urs Beyerle "just started making live CDs," and Shawn Thompson "thought he could do better on the artwork" so he redid the artwork for SL5 and SL6. The forum was the brainchild of John Outlan, who set it up and started moderating it for Scientific Linux. Dawson says "there are limits, but many people have found ways to contribute."
With the 6.1 release, Scientific Linux is looking very healthy and ready
for users who want a RHEL clone with reliable and timely updates. It's not
a perfect clone of RHEL, but for many purposes it is close enough to get
the job done and offer a suitable substitute.
[ Editor's note: We have added Scientific Linux to the list of security
updates that we follow, so you should see SL advisories in our daily
updates soon. ]
to post comments)