shoe

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.

An Essay of the LISNews Summer Series

I’m a conflicted person, it would seem. I regularly use, and encourage the use of, open source software. In some settings — public computing, thin client, and cloud environments — there isn’t, in my mind, any closed system that comes close to delivering what an open platform offers.

I believe heartily that open source code benefits both developers and end-users — in perpetuity. Open source development efforts can (and do) die — but the application, the code, the vital organs that sustained it during development live on. An abandoned open source software project is much like what the medical profession calls a beating heart cadaver. I learned this from Mary Roach’s book Stiff: The Curious Lives of Human Cadavers.

The fact that I read books about corpses that have more of a life than I do isn’t what makes me a conflicted soul. The fact that I read it on my second generation Kindle most certainly does.

An Essay of the LISNews Summer Series

I’m a conflicted person, it would seem. I regularly use, and encourage the use of, open source software. In some settings — public computing, thin client, and cloud environments — there isn’t, in my mind, any closed system that comes close to delivering what an open platform offers.

I believe heartily that open source code benefits both developers and end-users — in perpetuity. Open source development efforts can (and do) die — but the application, the code, the vital organs that sustained it during development live on. An abandoned open source software project is much like what the medical profession calls a beating heart cadaver. I learned this from Mary Roach’s book Stiff: The Curious Lives of Human Cadavers.

The fact that I read books about corpses that have more of a life than I do isn’t what makes me a conflicted soul. The fact that I read it on my second generation Kindle most certainly does.

There’d been a relatively low key skirmish surrounding the Kindle for some time. It only recently became a full-fledged battle in the eyes of the general public when pirated ebooks sold via Amazon were removed from the devices (the purchase price was refunded). Many people suddenly (finally?) began to wonder if they really owned the books on the device.

No, they don’t. While the reasons I decided to purchase a Kindle were varied (and surprisingly complex), it was partly because I was pleased in regards to how much I did own the content I bought.

Yes, it uses a closed file format (as well as copy protection software). To keep with our morbid metaphor: If closed software is a mortal entity, then closed formats are the “Not an organ donor” directive penned on a “Do not resuscitate” form. Closed formats are bad, kids. They are, and I say that without reservation. I say it feeling the appropriate amount of hypocrisy, guilt, and with the realization that admitting I know I don’t really own the books makes this all sound even more naive.

Amazon, though using a closed format of death, allows syncing to multiple Kindles (or iPhone/iPod Touch devices running the Kindle app) registered to my account. It allows me to register or de-register devices, delete, and re-download purchased content indefinitely. It is closed, it is copy protected, and it is most decidedly not ideal, but it is miles ahead of where the music industry was with DRM-protected MP3s only a few years ago.

I am hoping Amazon eventually does the right thing and opens the Kindle file format — not the firmware, not any little unique to the Kindle hardware features (it’d be nice, but is admittedly unrealistic). I believe it will happen, and that the technology has to progress through these restrictive, closed stages. It’s critical that this happen now, as content merges from the purely physical form into the “born digital” state.

Why? Simple. While a proprietary hardware/software vendor closing up shop means losing a device or application, a no-longer-supported proprietary file format means losing information. As new technologies take shape, catch on, and people experience this firsthand, vendors will be pressured to ensure content is available now — and in the future. If a device or application is lost to the ages, it may well have been inevitable. If the information produced by those using the device is lost — that is simply unconscionable.

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.