Without Linux, it’s doubtful the open source idea would have had as much impact as it has, with even conservative businesses like banks shifting away from closed-source software.
A quick glance at the internet news feeds show that Linux is where the action is. In today’s funds-starved environment, Linux projects are receiving money. There are jobs advertised today that require Linux experience and qualifications.
Using Linux as shorthand for everything open source can, however, lead to an unfortunate reality truncation. Despite all the publicity, it seems lots of people and organisations still haven’t understood that Linux is only an operating system kernel.
There’s a whole raft of other components required to operate a "Linux server". Many of these are large and complex pieces of software that take a long time to master in their own right. I get the impression that this fact is often overlooked by non-technical management and, of course, sales droids.
Recently, I was called in to do a spot of "Linux administration" at a firm that’s overwhelmingly a Windows shop. The Linux systems had been put in at the edge of the network, facing the internet, and had been installed by an unnamed "Linux consultant".
As I suspected, the job had very little to do with Linux per se; that is, there was no kernel hacking or similar tasks involved. Instead, I was asked to install new versions of BIND 9 and Sendmail 8.12, and configure those.
For that job, I relied on what I’d learnt about shell usage and scripting, the package manager and file system layout for the distribution in question and the excellent Vim editor, not to mention the applications themselves.
However, the tasks would’ve been very similar on a non-Linux operating system like FreeBSD, or even commercial Unix variants like Sun Solaris.
In other words, if I hadn’t had Sendmail and BIND 9 experience, I would have been the wrong person for the job. Granted, these two packages are close to ubiquitous on any Unix-y operating system so they’re not the best to illustrate my point, but I hope you get my drift: the job could have ended up as a waste of time and money for both parties.
So, next time your organisation is looking for a "Linux administrator", step back and think about what you really need: most likely, the right person will be someone who is familiar with the Linux distribution that your organisation uses. That’s really the key issue: each distribution is set up in a sometimes radically different fashion from others, depending on the philosophy of the packagers. Although Distribution A and B are running the same Linux kernels, just about everything else could be different, and it takes time to figure out how things work.
Look for someone who knows where things are on the file system, how the init scripts work, what tools the distribution comes with, how its package manager works and whether or not there are any compiler and library gotchas that could put spanners in the works of your implementation.
Otherwise, for the vast majority of deployments, having someone who understands the application(s) you’re using and comes with all-round Unix systems administration experience is a better choice than a Linux kernel hacker.
It’s easy to see why, too: as long as you install on supported hardware, there’s little need to delve into kernel internals nowadays; furthermore, Linux-based systems are getting deployed in more advanced scenarios than in the past, serving applications and files in heterogeneous IT environments to Windows, Macintosh and other proprietary clients.
Considering the increasingly complex environments that Linux-based solutions are dropped into, a greater understanding of the "Linux" task at hand and the person required to solve it could pay off. Otherwise, you might be unintentionally paying for someone to learn "Linux administration".