Scientific Linux: A distribution you use because you have to.

Screenshot from 2017-06-08 11-18-11
The default desktop on Scientific Linux 7.3

I’ve sat down to write this post several times, and started over each time. Initially, it was going to be to express my frustrations with Scientific Linux and generally just put it down. I stopped, because I continued to play with it, and fixed some of those frustrations, but was still going to make the overall point that the distribution is pointless. Today, after having stepped away for a few days, I’ve softened my position a bit more after thinking about the reasons someone may use the distribution. So, I’m going to start with the punch line, and then present my case below: While there are possible reasons to use Scientific Linux, I would firmly recommend not using it on a personal computer, or for day-to-day use.

The reason I decided to take a look at Scientific Linux was that where I currently work as a postdoctoral fellow, many of the graduate and undergraduate students are quite reluctant to work on Linux workstations provided to them, and many seem to do this because they don’t really know how to use Linux. On top of that, the IT department here doesn’t seem to really know much about Linux, I’ve even heard one of the small staff tell a student they don’t know how to do something in Linux, and the same staff member say many things that are untrue about Linux. So, I decided that I might offer to hold a few informational sessions about using Linux. The distribution on the workstations here is Scientific Linux, so I wanted to be able to speak somewhat specifically about that distribution. I installed it on my old HP Pavilion dv6-6135dx which I keep around specifically to test different Linux distributions.

Screenshot from 2017-06-08 11-34-36
System details about the installation and the HP Pavilion dv6-6135dx used for testing.

Some details about the laptop that I was using:

  • CPU: AMD A8-3500M APU, Quad core 1.5 GHz (can go up to 2.4 GHz in Windows)
  • IGPU: AMD HD 6620G
  • DPGU: AMD HD 6750M 1 GB GDDR5
  • RAM: 16 GB DDR3 1333 MHz
  • Disk: 1 TB 5400 rpm HDD
  • Screen: 1366 x 768 pixels

This is a 6+ year old computer at this point, but that should be no hindrance to running Linux. In fact it was still in active use up until last summer when I decided to purchase a new laptop after a hard drive failure. Given the age of the computer and the fact that it’s been well traveled and somewhat abused, I feared that other components may fail soon. In the time that I’ve owned the computer, I have upgraded the RAM to the maximum of 16 GB, which certainly helps. The screen is pretty low resolution by today’s standards and that leads me to one of the issues I had with Scientific Linux. But, lets start with the install process.

Installation

My distribution of choice is Fedora, and Scientific Linux is a derivative of Red Hat Enterprise Linux, so the installation process was very familiar to me and was the same as just about every version of Fedora I had ever installed.

I downloaded the latest version of Scientific Linux, made a live USB stick, and booted up. I was greeted with the default desktop, which is not to my liking, but figured I would play around with tweaks after the install. The process is handled through Anaconda, just like Fedora, and I followed my usual steps. It was quick and painless with no issues at all. Unfortunately, that is one of the last things that I can describe as quick and painless.

First Impressions

After the install, I rebooted and started to try to get a feel for the desktop environment. Now, while I use Fedora, I’ve always gone with the KDE spin. This was initially due to the similarities with Windows and having only really used Windows up to that point. I figured that KDE would ease my transition to Linux, and it did. While I could have gone with a KDE based version of Scientific Linux, all the workstations around here use the Gnome based version. Since my whole reason for looking at the distribution in the first place was to help acclimate students, I wanted something as close as possible to what they would be using.

So, I’m not a big fan of Gnome. In brief, I find it to be more difficult to customize and minimalist to a fault, but since this isn’t a review of Gnome, let’s move on. For Scientific Linux, the system defaults to the Gnome classic session. This gives you a top bar and bottom bar that cannot be covered. Combine that with the low resolution of the laptop, and large title bars of windows in Gnome, and you wind of losing a lot of precious screen real estate. Of course one solution is to use a higher resolution display, but considering that most of the workstations here are hooked up to monitors that are even older than my HP laptop, that’s not necessarily an option.

Now, both myself and the students that I was going to be talking to would be using Scientific Linux to write code. I tend to use a text editor to write the code and have a terminal window open to compile and run. By losing space at both the top and bottom of your screen, you’re unable to view as much code at a single time as you might be able to other wise. Most of the students come from a IDE-centric background for coding and would want to use various IDE’s while coding, likely making the situation even worse. Of course, the pro of the classic Gnome session is that the bottom bar acts as a task manager and virtual desktop switcher, allowing you to quickly switch between windows even when one is covered by another. Also, the classic application menu is a big plus over the full screen abomination that is the “Activities” view, but again I’m not trying to focus too much on the many short-comings of Gnome.

Now, in most Gnome based distros, you’d fix these nuisances by finding extensions to customize your desktop environment. After switching to the regular Gnome session to get rid of the bottom bar, I decided to try this out. After all, if I could find ways that the students would be able to customize their desktop environment, they may begin to see the appeal of Linux. However, I found that I could not access a large majority of the available Gnome extensions. By default Scientific Linux comes with very little in its repositories. Not even some common scientific software and tools. After some updates, the Extra Packages for Enterprise Linux repository was enabled, which helped, and I tried enabling as many third party repositories as possible. When I tried to find extensions in those repositories, there were only around 8 or so.

When I tried to install them through extensions.gnome.org, I couldn’t get the plugins to work in either Firefox or Chrome. Since I’m used to a highly configurable desktop right out of the box with built in tools to browse and install more themes and widgets, this was quite annoying. I did much Googling, but could only find information about fixes for the plugin issue for CentOS, and those didn’t seem to work with Scientific Linux.

It was these experiences that led to my gut reaction of just completely trashing the distro. One of the greatest things about Linux is the ability to customize. Now, I know Scientific Linux was developed at Fermi Lab and  probably used by many people who fondly remember the days of Gnome 2, but that’s not a good reason for forcing all your users to have that desktop experience, especially when younger users will want something with a more modern feel.

Programming with Scientific Linux

The major reason for developing Scientific Linux was to provide a common Linux distribution for all high energy physics labs to use to ensure that code could be compiled and run at any of the sites. Effectively, there was a time when all the labs used different Linux distros, and sometimes code from one site wouldn’t compile on the systems at a different site. So, instead of coming together at a meeting and agreeing upon one of the already numerous Linux distributions to become the defacto standard at all the labs, they decided to make a “new” distribution.

Apparently the creators of Scientific Linux intended people to write code with the distribution. This is a process that I didn’t find quite as smooth as on Fedora. For one thing, the GNU Compiler Collection (gcc) is still at 4.8.5 and Python seems to be stuck at version 2.7.5, meaning that you cannot access the latest features of Python 3.

Combine that with the inability to create text files by right clicking in the “Files” app, my usual method of creating source files, the lackluster experience of editing with gedit, I usually use KWrite so I felt the comparison to be apt, and the squeezed screen, and you’re left with a very poor coding experience. I probably could have found a better text editor, and there may be ways to enable creating files by right clicking. However, I wanted to show the students how to program without IDE’s, and how on Linux you can just program out of the box without installing tools. The lack of right-click file creation meant introducing more command line instructions to create their source files. The poor experience with gedit meant that you’d have to tell the students to install more software or learn to use Emacs . Both of those undermined my goal of showing them the ease of Linux.

Why use Scientific Linux at all?

There are reasons for using Scientific Linux, or at least something similar to it, in an institutional setting. Since Scientific Linux is based on RHEL, it has long term support. This means that you won’t have to do major version upgrades of the operating system once or twice every year. Since most academic institutions have budget constraints, they’d rather not spend more than necessary on IT. So, a version of Linux that only uses well tested, relatively bug free software that only has to be upgraded every few years is appealing. Also, so long as all labs are actually using it, or at least have some workstations that have it, you can be sure that your code will run on Scientific Linux, making it easier to share.

Unfortunately, that’s about it for reasons to actually use Scientific Linux. Otherwise you just have a version of CentOS which is less configurable. For all my dislike of Gnome, if I could have gotten the Dash-to-Panel extension to install, and done some more searching for other extensions, I probably would have been able to get a very usable desktop environment (of course KDE Plasma 5 is essentially already configured the way I want right out of the box). The fact that Scientific Linux seems to have been intentionally hobbled in terms of customization is disappointing.

Because of the lack of customization, there is little I can do to contend with all the screen real estate lost with top and bottom bar. The modern Gnome session gets rid of the bottom bar in favor of the “Activities” view to switch applications which is slowed by many pointless animations. The top bar feels like a waste of space seeing as how usually about two-thirds of it is empty.

Lastly, if Scientific Linux wanted to be a platform for scientists, then all things a scientist could want should be in the default repositories, including updated versions of gcc. It basically seems like the Scientific Linux team took RHEL, set the default to the classic Gnome session, added their limited repository, and called it a day. There’s seemingly no effort to package any software themselves for their distribution.

Conclusion

At the end of the day, Scientific Linux is a usable Linux distribution. If you have to use it because it’s what’s provided on your institutional computer, then you can probably get something put together that works for you. However, it seems to take all of the joy out of using Linux. Everything you try to change so that you can be more productive leads you straight into a wall. Even if I had installed KDE, they’re still stuck with Plasma 4, and at this point I’d argue that Plasma 5 may be even more stable.

Now, I’ve only been using Linux since around 2012, so my initial impressions are still relatively clear in my mind. I remember slowly discovering how customize-able KDE Plasma 4 was. I remember how little frustration I had with the initial switch. Sure, at first it was difficult to install the proprietary NVidia drivers so that I could use CUDA without paying for Visual Studio, which was one of my main reasons for switching. Once I found the RPMFusion repo, that wasn’t a problem. I remember clearly that I was never annoyed by updates like I was in Windows. All of these things made me fall in love with Linux and adopt it as my everyday OS. I can honestly say that had my first experience with Linux been Scientific Linux, I would have never switched. Linux would have been an operating system I used because I had to, not because I wanted to.

So, for the above reasons, I have to strongly recommend against Scientific Linux as a day-to-day OS. Use one of the more up-to-date distributions with more flexibility for customization. I think at some point I may do a comparison with CentOS, possibly even testing binary compatibility. If your only experience with Linux thus far has been Scientific Linux, I urge you to keep an open mind and try a different distribution. I haven’t personally tested enough to make a firm recommendation, but Fedora does have spins with pretty much all of the major desktop environments, and tends to get the latest versions of compilers and libraries a bit sooner than some other distributions.

What are your thoughts about Scientific Linux? Do you think my review is full of… well… you know what? Let me know in the comments!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s