LISNews: Librarian News

An Essay of the LISNews Summer Series

There are some obvious similarities between the quintessential Linux user and the classical image of the librarian, covering the gamut of good, bad and indifferent. Librarians foster the curiosity and intellectual growth of diverse patrons, connecting them with reliable sources of information and suggesting entertaining books, music and movies. The Linux community encourages users to examine, change, and take the operating system further -- regardless of whether "further" works out as modifying a kernel module or creating a new scalable vector graphic icon set for the desktop.

Linux users, when faced with a question that's been asked millions of times throughout the ages -- one with an easily discovered answer, if the soul asking had only taken a few seconds -- often respond with a resounding "RTFM" (read the f****** manual). Sometimes this response will be shaken up with a stray "Google is your friend." Librarians, by matter of course, prefer to teach a man to fish rather than feed him -- and sometimes patrons, quite capable of fishing when pointed towards the appropriate body of water, would really prefer to be fed their fish, with a couple side dishes, butter, lemon, dessert, and valet parking for good measure. That's when they tend to be greeted with the response, "Look it up." And yes, sometimes this response will be shaken up with a stray "Google is your friend."

By and large, the quintessential Linux user and classical librarian persona are stereotypes. Stereotypes generally have a grain of truth buried in there somewhere. I think what's most awe-inspiring about these two demographics -- similar, yet simultaneously so utterly different -- isn't the kindred philosophies or the occasionally pointed terms used to encourage others to seek answers on their own. It's the shocking way that skills learned in one setting (librarianship, fooling around with Linux in nearly any capacity) are so complementary and transferable.

In its elemental form: These settings are complementary because neither places high value on knowing the answer right from the start -- the value, the knowledge, the ability arises from understanding what question actually needs an answer, and then knowing how to track that answer down.

Think of troubleshooting an error as a reference interview. Think of a reference interview as troubleshooting an error. It works reasonably well both ways.

I've not transformed any Linux users I know into librarians, but I've found there's a healthy appreciation of the skills required in the stacks. The library just isn't where they see themselves seeking employment. That's fine. I know many librarians who use Linux in some capacity -- to play around and learn, to develop applications, or some mix of the two. I know many librarians who appreciate the skills required in software development (or general system maintenance). They don't pursue it, it's not their thing. And that, too, is fine. But there's a response encountered just a little too frequently to sit right, "I could never do that. It's too [insert phrase that thinly veils the notion that computers are magical and completely undocumented creations]."

Troubleshooting is a reference interview. In many ways, it's the easiest reference interview you'll ever conduct. While Linux error messages and logs seem cryptic, or complete to the point of superfluity, it doesn't take long to narrow down the log files and specific lines that'll help identify the source of the problem. Yes, you'll likely get more information than you need from this interview, but you're going to get the information needed to find an answer and believe me, the system won't question why the hell you're asking all these follow up questions and not just providing a solution to the question raised.

The best part is, of course, you don't have to know what the error really means. In a general sense, perhaps, but that can also be rooted out fairly quickly by searching help files. Not knowing exactly what wlan0: disassociating by local choice (reason=3) means isn't a problem. If the time of a system glitch (say, a lost wireless connection) corresponds to the message, it's a fine place to start searching the most suspect looking phrases. We're librarians. We do this all the time.

And by the way, my wireless card doesn't have a superiority complex. The error was the product of a dodgy driver update.

Kristin Shoemaker ("shoe") is the collective effort of the Simmons GSLIS development project. Constantly in need of either a warm reboot (or at least a Ctrl-Alt-Bksp and restart of the graphical server), she is a contributor at OStatic, the GigaOM network's open source portal.

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.