I read an article on Slashdot the other day about an newly released open source application. I read a few of the comments, and I found this one (slightly paraphrased):
$ apt-get fooapp "You have searched for packages named fooapp in all distributions....Can't find that package." Sorry, I'm not interested.
The comment suggested that since he can’t try the software in a pre-built distribution then it isn’t worth trying.
Unlike a few years ago when every Linux user ran configure by hand, the speed and convenience of installing packages has put the compiler on the back burner. Packages aren’t a bad thing, but I think it’s a poor reflection of an administrator’s skill set if they shun the development tools that are available for every Unix environment.
I’m not saying that packages should be avoided. I build them myself for software that I have compiled and tested manually. Once packaged, they’re pushed out during the remote installation process. After that, I am considered the distributor for certain applications in the infrastructure, and the primary support contact. I’ll also concede that it doesn’t make much sense to recompile Gnome or KDE if my OS vendor provides a pre-built package, along with support and regular upgrades. I won’t be too optimistic about installing packages that aren’t built or approved by the author of the software.
When I interview an administrator, I usually throw in a couple of programming interview questions, such as, “How do you determine which shared libraries a program requires?” or “What steps would you take to compile the Apache webserver?”. I don’t expect them to be a full fledged C programmer, but I think it’s important to know how to build software. The candidates that have demonstrated these skills have also been more proficient in debugging, tracing system calls, and identifying performance problems ahead of time.
Since I'm not a sysadmin, what would be the expected answer to those questions?
n00b - the answer to the first question is "ldd" - this lists the shared library dependencies for a given executable (or library).
If I was asked the second question in an interview I'd expect it to be one of those where you need to be able to describe/discuss the process in enough detail to show that you understand what's involved, not a question which has a single "correct" answer.
Although a short answer would be "configure; make && make install", or perhaps even just "RTFM". ;) The manual in this case is at http://httpd.apache.org/docs/2.0/install.html (if you're building the 2.0 series). The reality is that if you're building Apache by hand these days you're generally doing so for a specific purpose, so you'd need to understand how to make decisions about which modules to install, where to find the dependencies for compiling them, how to add external/third-party modules, etc.
I hope this helps!
>The comment suggested that since he can't try the software
>in a pre-built distribution then it isn't worth trying.
Because as we all know, requiring Linux users who want to try new software to be able to use compilers and edit make files is a great way to promote desktop Linux for the masses.
This smacks of Richard Stallman's possition. Did you buy a laptop with hardware for which there are no open source drivers? Bad user, you must be puinished. No binary drivers (even if they are freely available) and complete hardware support for you!
> This smacks of Richard Stallman's possition
I never said packages were bad. My point was over-reliance on packages compared to understanding how the source code works is bad.
I also never said I was trying to bring Linux to the masses. My more immediate concerns were skill sets in Unix and Linux administrators.
This is not a position regarding source distribution vs. binary only distribution. In all the cases I was considering, I was discussing applications that fall under various accepted open source licenses. The administrator has the option of using either a package or building from source.
If you're only option is to use a binary driver, go ahead.
You're right, I overreacted to your post and I appologise. Yes learning to compile from source is an important skill for any Linux admin, and on that count your post is perfectly reasonable.
I am wary of elitism in the Linux, and indeed the wider open source community and perhaps tend to over-react against it.
No problem.
I look forward eagerly to the day where I never need to know or care about any of these problems, and it can't come soon enough. I don't think about registers any more, I don't recompile kernels any more, and if I don't ever type './configure' again, I'll be incredibly stoked.
I consider it a failure of the industry that people have had to do this for so long, and I'm thankful that Debian has shown the world a reasonable way to interact with your software. I say this as a developer, too - a big part of what I do is work with users to help them maintain packages for different platforms.
As a sysadmin, I absolutely shun compilers and linkers and all that, and I hope I can one day train a competent sysadmin who has no need for any of that knowledge, just like these days I don't bother talking much about hardware details, because we horizontally scale and don't need to eek 100% from every I/O channel. To me, having to manually compile an application is like a personal failure, just like having to log into a machine and doing work manually.
I completely agree with your opinion Chris. One of the things I like best about Linux and the apps installed in it is if something doesn't work I can mentally break apart the application to fuller understand how it works by looking through its log files, configuration files, start-up scripts, etc.
I do install as much as possible via packages, but certain things will never be readily available in Linux distros, such as scientific applications, at least not in their latest version. For example, if I want all of my work stations running the same version of openmpi, I need to install from a tarball. This leads to a uniform openmpi install across Ubuntu, Caos2, and RHEL. Otherwise I have to wait for each distro to have the same version of something.
Over the years I also switch my installations to different distros of Linux. I started with Mandrake several years ago, then Gentoo, and more recently Ubuntu. If you just rely on packages, you won't learn where to look for supporting files such as images, documentation, configuration files, libraries, etc. I suppose you can learn how the packaging works and work backwards, but building from source is a valuable skill.
To answer the interview questions:
1) I'll admit that I would probably just read the README, the INSTALL, and then run ./configure and see what errors pop up.
2) To compile an apache webserver, I would download the latest version, and the md5, verify I have a clean copy, extract, ./configure, make, make install. If I needed PHP, SSL, etc, I would just read would build them in as well and enable them. Most of my apache servers have been installed from packages in the last few years however. Its quick, easy, and none of them are publicly exposed or highly used so I'm not too worried about performance or security.
-Brian H.
I agree with your main point. It's very important for administrators to be able to compile software apart from the packaging system.
Still, I really have to want a piece of software if I have to maintain it outside of my packaging system. At the moment, the only software that applies is software to which I contribute.
To follow up with n00b , John, and Brian the answers for those questions would be:
1. The ldd command. I'll also be impressed if the candidate discusses the difference between LD_LIBRARY_PATH and LD_RUN_PATH, and how to repair possible shared library conflicts.
2. Compiling apache is pretty flexible, and almost any answer will do as long as the command invocations are pretty accurate. The particular things I would look for would include additional module choices, differences between static and dynamic libraries, and pathing decisions when setting --prefix, --sysconfdir, and --localstatedir.
Thanks for the informative responses!
Bit of a red herring Chris. The point of computer is to do repetitive tasks in an automated fashion, hence packaging. Plus packaging makes for more secure code since presumably upstream and distro level people have looked at it. Compiling from source leads you to the Gentoo problem, yeah you have the system exactly as you want it, but you spend all your time compiling software and living in dependency hell. I don't think compiling from source leads to sysadmin productivity, even if it does teach your more about the system.
I've run into the compiler averse sysadmin a few times. It usually happens when you get a sysadmin who is new to Linux (usually with a Windows background). Think about it, a Microsoft sysadmin would never even think of compiling something from source. They'd laugh at you and then go rifling through some 1600 page Windows admin book to tel you that they'd need to purchase Visual Studio to do that.
But, the problem is when one of these post-Microsoft admins becomes responsible for an array Linux servers that need to run something like Apache or Ruby on Rails. Once they realize that they can't run the latest Rails on CentOS 4 or the latest Apache on CentOS, you start talking about compiling from source. "Egad! No!, that's crazy. We'd lose support...."
And, yes, it is true, the minute you compile Apache from source, is the minute you then become responsible for keeping up to date with security patches, but, I'd prefer a sysadmin that has to pay attention to one that believes that a distribution is keeping up to date with packages.
Ugh. I hate this particular tendency, IMO, it is a recent development.
And to read the comment responses from jeremiah and Luke, I think this is insane. Anyone who thinks they are going to run a Linux system in production and not have to fire up the compiler for at least one component hasn't had sysadmin responsibilities in any production system.
For one, I'd recommend that *anyone* running Apache in production immediately get familiar with compiling Apache from source. We're not talking about rocket science, and "keeping up with the patches" is something you should be doing anyway.
@ Tim: Actually I have had the responsibility of running Sweden's fastest growing eCommerce web site and transitioning from FreeBSD 4.4 to Ubuntu. I can tell you that dependency hell is a real productivity killer.
Apache 2.2 runs incredibly well on Ubuntu and one gets to use debian's a2enmod tool which makes adding mod_perl, and any other module a snap. Plus it is fully supported by debian's security updates - no wonder debian is one of the fastest growing operating systems running web servers on the web.
Compare that to trying to get the latest version of PHP 5 to run FreeBSD, not going to cut it. Especially when you have to upgrade all the other tools just to get PHP 5 to compile!
Personally I never touch Windows machines, I have no idea how to administer one, and I was trained at BU on Red Hat 6.1, SCO UNIX and Tru64 at Harvard, so I have spent many an hour tracking down missing libs. What an utter waste of time. Compiling is what developers should do, integrating and maintaining is what sysadmins do.
I've got to admit, I'm pretty surprised by all the "anti-compiling" responses to this post. Chris said himself that he's "not saying that packages should be avoided." - but there's a big difference between knowing when to use the vendor packages versus compiling from scratch, and not even being capable of compiling from scratch.
It's not even something that you'll necessarily have to do - but knowing how to do it indicates a degree of understanding that will make you a better sysadmin anyway.
Besides, there are certainly environments in which these skills are essential, whatever some of the respondents may think. I'm working in the High-Performance Computing field at the moment, and with the exception of basic system utilities pretty much all our software is compiled from scratch. Our users bring along source code to scientific models they want to run on our system, and they frequently need our help to get it up and running. Somebody with no knowledge of compiling software just isn't employable as a sysadmin in this sort of environment - end of story.
There's a big difference between what a sysadmin needs to know and what a desktop user needs to know - but after all, this is the O'Reilly Sysadmin blog. ;)
Chris's post prompted me to write about this topic myself, where I've said that Sysadmins must be able to use a compiler.
On a releated note. The distribution packages are usually built with all possible options. Compiling yourself allows you to pick options and dependancies.
Example. OpeenSSL package on RHEL deviants is built with an unnecessary dependancy on Kerberos.
Knowing how to compile software is important, but it's a lot easier and nicer to be able to download and install a package that someone else has already done the work to get right, especially if you're talking about something that you've just heard about and sounds vaguely cool, but isn't mission critical.
I package software when I have to (for work), and on the side (for Debian), but building software packages isn't the best use of my time, nor is it likely to be the best use of any sysadmin's time.
In my experience (at least in the case of a seasoned sysadmin) it is not compilation itself which brings aversion (I have to compile "something" for a wide variety of "something" almost every day, and I find myself tweaking Makefiles at least once monthly... always on testing boxes) but what happens after the fact. Now you can lose vendor support and you will need to be the package maintainer/integrator yourself. It is not that I can't do it, I surely can and even maintain a select bunch of apps that way, but it is I better am damn sure it worths the effort/risks involved, both from a company perspective (I think about myself I'm quite good on the trade or at least good enough, but surely a hundred eyes see more that just two) and for a job-security one (I'm absolutly covered from a, say, Red Hat security update going nuts, but it's my ass at risk when upgrading some Postfix patched and compiled from sources if anything fails).
So, the context is important, but given the proper context, I find answering "there's no packaged version, therefor I'm not so interested" is quite a reasonable output (i.e.: I were quite knowledgeable about Qmail on a past life coming from Sendmail but now I'm a satisfied Postfix user by default, so if someone came now telling me "you must test this MTA, it's great" and it's not already packaged on my testing distribution of choice it's better it offers something I *really* am looking for or I probably will answer "it's not packaged, sorry I'm not that interesed" both because it would mean an effort I don't have the time nor the will to go through and because then it can't be so popular or widely used and then it's a risk I prefer to leave to the youngsters among the audience).
By the way, ldd -v /path/to/executable and ./configure --with-apxs2 --enable-module=so --enable(whatever)... && make && make test && make install of course.