The Linux‐using world has always had a bit of an image problem. Somehow the general public has got the impression that Linux is only meant for socially incompetent elitists. Part of the problem here is that software developers have a characteristic skill‐set with its own implicit value system, applicable to real‐life problems as well as programming, and feel a strong common bond with others of their kind; as a result, they have a hard time empathising with outsiders. (When people wearing ties do that, it's called a “professional attitude”.)
Now, I respect those skills and feel a great deal of gratitude to
that community; but I'm not a member, never will be, never want
to be, and never want to be told I should want to be.
I am not a programmer, and feel no more tempted to
become (for instance) a kernel‐hacker than to become a graphic
designer or forensic dentist. This idea that Linux has
ordinary mortal end‐users with no trace of a Computer Science
degree may come as a shock to the man in the street; the more
annoying thing from my point of view is that an awful lot of the
people writing and maintaining software for GNU/
In the hope that it might help developers get a feel for what
other kinds of people there might be in the wide world of Open
Source Software, let me introduce myself. I was never the
kind of kid who owned a home electronics kit, a ZX Spectrum,
or even a programmable calculator; my A‐levels were in Latin,
French, and English Literature, and my degree was an MA. I
just happen to have worked my way up from guest login to
commandline power‐user to Debian GNU/
- I can handle interpreted procedural languages, because I'm familiar with life on the Bash prompt. But I do not mess about with memory management; I know nothing of lexers, parsers, compilers, linkers, fluffers, profilers, or debuggers; and “inherently object oriented” means “bafflingly counterintuitive”!
If you WTFM, I'll
RTFM, but I do not
RTFS any more than
Any application that requires fluency in C should at the very
least be filed under “devel”. So “it behaves just like
getasdfghjkl” is not what I call documentation.
I'll happily spend hours faffing about with
~/.foorcin a text editor. (I don't want to have to do it in an IDE with code‐editing features;
emacs? A plague on both your houses!) However, if the config‐file's written in some esoteric syntax I can't get my head round, I won't dream of recompiling the binary, I'll probably just look for another package with better defaults.
- I do not need to know anything about libraries – that's the package management system's job. I do not leave copies of the unpacked kernel source lying around, and have little grasp of what header files might be.
I do not touch
makefiles, except when I'm using
make-kpkgto turn a
linux-sourceDebian package into a customised
linux-imageDebian package, and even then I handle the whole baffling ritual through a wrapper script.
I have no use for revision control. Not even when I'm
writing a Perl script – there are no code‐forks to
merge, it has no intricate compilation dependencies, and I keep
good backups; why would I want to have to pass things through a
repository before I can use them? And as for those
I'll concede that I'm something very like a programmer… I'm hairy enough, for a start. But when approached from the non‐CS‐degree side, the slope is nowhere near as slippery as my codehead friends all seem to assume.