One Tale of Two Scientific Distros
Several weeks ago, I was flying west past Chicago, watching the ground slide by below, when I spotted the signature figure eight of the Fermi National Accelerator Laboratory, better known as Fermilab. I shot some pictures, which I put up at the Linux Journal Flickr pool (Flickr also uses Linux).
I figured Fermilab naturally would use Linux, and found that Fermilab has its own distro: Fermi Linux. Its public site provides a nice window into a highly professional and focused usage of Linux. Within Fermi Linux, specific generations are known as Scientific Linux Fermi, each with version numbers and the code names Charm, Strange, Top, Bottom, Up, Feynmann, Wilson and Lederman.
Some also have LTS in their names. LTS stands for Long Term Support. It has a FAQ. The first Q is, "What is Fermi Linux LTS?" The A goes:
Fermi Linux LTS (Long Term Support) is, in essence, Red Hat Enterprise, recompiled.
What we have done is taken the source code from Red Hat Enterprise (in srpm form) and recompiled it. The resulting binaries (now in rpm form) are then ours to do with as we desire, as long as we follow the license from that original source code, which we are doing.
We are choosing to bundle all these binaries into a Linux distribution that is as close to Red Hat Enterprise as we can get it. The goal is to ensure that if a program runs and is certified on Red Hat Enterprise, then it will run on the corresponding Fermi Linux LTS release.
A follow-up Q goes, "I really don't want to get into legal trouble, please convince me that this is legal." The A says:
What we are doing is getting the source rpm of each Red Hat Enterprise package from a publicly available area. Each of these packages, except for a few, have the GPL license. This license states that we can freely distribute that package. We are recompiling those packages without any change. Hence, we can freely distribute those rpms that were built....And although these rpms are basically identical to Red Hat's Enterprise Linux, they were built by us and are freely distributable. We can do with them what we want....
Although it is basically identical to Red Hat Enterprise Linux, it is, in essence, a completely different release, just with the same programs, packaged the same way.
Fermilab supports its own users and directs others toward Scientific Linux, which was codeveloped by Fermilab, CERN and other laboratories and universities. Troy Dawson is the primary contact for both Fermi Linux and Scientific Linux. On his own site, he explains, "Fermilab uses what is called Fermi Linux. It is now based on Scientific Linux. It is actually a site modification, so technically it is Scientific Linux Fermi. But we call all of the releases we have made Fermi Linux.”"
While Fermi Linux's version history starts with 5.0x in 1998, Scientific Linux's history starts with 3.0.1 in 2004. Both sites' current distribution version pages have near-identical tables of releases, dates and notes. The latest version for both is 5.x.
In a comment to an on-line Linux Journal article, William Roddy wrote, "Scientific Linux will work in any environment Red Hat would, and even better. It's a work of art and genius, and in the field of high-energy physics, if this Linux didn't work, it wouldn't be used. Yet, it is useful to anyone. If you demand stability and security, you will not do better. It will always be there and it will always be free."
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide