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.
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.
The Scientific 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:
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. ]
openSUSEencouraged to vote on the openSUSE strategy proposal. "We're not asking everyone if they think it is a perfect fit for themselves — we're a diverse community and we'll never fully agree on anything. But this proposal has seen lots of thought, discussion, revision, input — it is arguably the best we could come up with to describe who we are and where we want to go. So the question is — do we agree this describes us? Is it good enough for us to support? Can we move on with this?"
Newsletters and articles of interest
After talking to Pat Volkerding, I announced on the KDE packager mailing list that we are considering the same solution as was chosen for GNOME in the past: remove KDE from Slackware if it proves to become a maintenance burden. I can not yet say anything final about this. For the time being, I have decided not to create Slackware packages for the KDE Software Compilation 4.7.x.
Page editor: Rebecca Sobol
Next page: Development>>
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds