The article doesn’t do it justice, so I decided to search for it on Wikipedia: https://en.wikipedia.org/wiki/Scientific_Linux. Basically it’s just a Red Hat Enterprise Linux derivative that’s consistent across computers to make maintenance useful. It also has a cute set of version names based on atomic number.
> It also has a cute set of version names based on atomic number.
This reminds me of my favorite lab numbering scheme. Each computer in the lab is assigned an element name, with the last byte of its assigned IPv4 address being its atomic number.
So if your machine were `cobalt` your IP would be 192.168.0.27, If it were `oxygen`, 192.168.0.16, etc.
Yeah. Scientific Linux was never particularly interesting as linux technology. It was held up as a success story for deploying a domain-customized Linux distribution at very large scales. And by all accounts (I never used it) it was very successful. But upstream has gotten better and app deployment in the modern world (c.f. Docker et. al.) has made strides in decoupling itself from OS weirdness. So they probably just don't see the need anymore.
I used it a few years ago when we realised Centos 6 had dropped support for some packages (can't remember which). They had stepped up and backported these, plus some other fixes.
I can see in the days of containers etc they wouldn't be needed, but they definitely filled a need back in the day and I thank them for it.
I have been to several synchrotrons, central facilities. Most had stock install of centos (whatever stable on that day). All user software was always installed in a nfs mounted /soft/+++
so that everyone could source it and use it. These days many of them are moving to 'xubuntu' (mainly avoiding the unity+gnome3 mess). Many of sci-devs are using ubuntu as their daily driver - so getting the latest python (bio), or math package, is newer in *ubuntu.
> These days many of them are moving to 'xubuntu' (mainly avoiding the unity+gnome3 mess).
Wouldn't Debian work a bit better and come with a better long-term stability policy? It seems strange to rely on the *buntus unless you're specifically relying either on proprietary software that's Ubuntu-targeted, or commercial support from Canonical. (But there are some spaces, e.g. GPGPU compute, where either of these might be relevant and Debian still has quite a bit of work to do before it can be relevant.)
In my experience scientific and enterprise organization don't use Linux for any given feature, but because it is available. In many ways they use Linux despite it being Linux. So whatever is the least obscure would be ideal.
I first learned how to operate and administer Linux-based operating systems with Scientific Linux 3 when I helped setup the tier II compute site for the WLCG (called LCG at the time) at my alma mater.
SL was, at the time, a thin-ish veneer around RHEL that included some additional packages to make using and installing some very common HEP tools (ROOT, GEANT, etc.) more palatable to academics that didn't have the time nor the fortitude to deal with the nightmares of installing raw RPMs.
It was my first foray into the world of linux, and it was both a nightmare and a blessing. I probably owe most of my current career to the hacking I did back then.
Much of the usefulness of SL (and most specialty/drivatives of RHEL) have faded over time, but I'll always be thankful for the people that put time and effort into a very thankless job so that HEP physicists around the world could have one less thing to worry about and focus just a bit more time on the science.
To me this looks like a success story: mainstream linux distros have caught up to where SL was, or close enough, so that the marginal benefit of maintaining SL is wearing thin. Maybe they are even surpassing SL in some areas.
CERN started transitioning to CentOS several years ago. SL was a Fermilab Computing product at this point. I also personally switched from SL to CentOS on my workstation years ago (partially because it took so long for SL7 to come out) .
Fedora is considerably upstream for all three. I expect the efforts are mainly repackaging, so instead of repacking RHEL into SL, they'll aid in the repackaging of RHEL into CentOS.
Fedora Scientific Spin is produced by the Fedora Project's Science and Technology special interest group (SIG). It's based on KDE.
I wondered this as well. It sounds like Scientific Linux was more just a convenient and consistent package of applications and interface than any significant changes to linux proper.
However, if the various particle labs who used to use Scientific Linux end up requiring any significant code changes for performance reasons, it seems like this change would mean sharing those changes upstream would face an easier path.
Even for scientific uses on Infiniband clusters, we used Rocks (which deploys CentOS or RHEL). There wasn't a compelling advantage to using SL, except the year or two about a decade ago when CentOS was in chaos.
I see SL quite widely used in research computing. People tend to stick to one of its point releases corresponding to RHEL initial releases plus security updates of some sort (e.g. 7.1 round here).
