Why Unix Sucks (yes, that includes GNU/Linux) by Rob Swindell

The high and mighty Unix users can only pretend their OS doesn't suck because
no one else wants to use it to prove them wrong. Once anyone actually starts to
really try to "use" it, they either give up in frustration, or they take pride
in the challenges they've overcome and begin to defend Unix and its dubious
merits. Or, if they've never used anything else (poor University students),
they simply assume that computers are supposed to be that difficult to use.

I first started using Unix in 1991. I was working for a software company
writing medical billing software for DOS/NetWare/Btrieve in C/C++ and was asked
to move over to the data acquisition business unit and take over a GPIB device
driver project for TC/IX (Control Data's real-time Unix). At first, I was
excited at the challenge. I had heard quite a bit about Unix from a programmer
friend of mine and was prepared to use the things I'd learned from my friend
and more. I jumped in head first (I didn't really have much of a choice), using
vi and rebuilding the kernel daily, customizing my xterm .rc files, creating
shell macros and scripts for every day tasks, etc. I even learned to use cool
Unix colloquialisms like "bang" (!) and "splat" (*). :-)

I also wrote my first GUI applications while working for that company, using
the X/Motif framework. I'd never written more repetitive, tedious, wordy source
code, before or since. And the results were only mildly impressive. It really
soured me on GUI development for a number of years. When I left that job and
started coding and selling Synchronet professionally, I never really missed
those Unix days. I kept printouts of my X/Motif code for a number of years as
a joke I liked to shared with some of my programming friends.

I didn't touch a Unix command line for three or four years until I got my first
personal Internet access (shell) account with netcom. I did a little
experimentation, used gopher and irc a little (web browsing was not "in vogue"
yet). But the main reason for the account was so I could receive Internet
e-mail and to have a place where users could get Synchronet files via FTP. I
have a pretty good memory, so I didn't have much of a problem navigating around
and such, but I purposely avoided trying to remember how to use vi and found
pico much more to my liking (for the small editing tasks I needed to perform at
the time).

Over the past five years, I've had several different ISP and web hosting
accounts and have accessed various Unix-based systems for fun or work
(occasionally, I have to do development on Solaris at my current job, but I
avoid it until absolutely necessary), but it wasn't until I installed
GNU/Linux at home a few months ago that I really started using Unix again on a
daily basis.

So the point of this background information is, my observations here are not
necessarily from a total newbie prospective, nor that of a Unix-veteran. I
consider myself technically proficient, and a quick learner. I've used several
operating systems extensively, from CPM and Apple DOS to OS/2 and Windows 2000.
None has left me quite as frustrated or perplexed as Unix.

So, here's my list (just off the top of my head):

o Shell scripts (which are merely text files), by convention, go in /usr/bin.
  "bin" stands for "binary". Really, what they MEAN, is that EXECUTABLE files
  should go in /bin or /usr/bin. If everyone agrees this is a lame naming
  convention, isn't it about time to change it? Wouldn't /usr/exec make more
  sense? Oh, but then you'd have to go and change all those scripts that start
  with "#!/bin/sh" - what a kludge that is!

o /etc stands for "etcetera", but it contains some of the most important files
  on the system. Are you kidding me? Shouldn't this be /sys or something more
  indicative of the content? The argument that you can't change the name of the
  directory now because it is hard-coded into programs, is just another example
  of how much Unix sucks. You don't find "C:\WINDOWS" hard-coded into Windows
  programs (Windows has API calls to retrieve the paths of important system
  directories should a programmer need them).

o Hidden filenames start with a '.'? Oh, that's not a kludge.

o There are some really cute command names (like "less" and "yacc"), but come
  on guys, it's only cute for a little while and then you have to live with
  using a command name that makes no logical sense. Cryptic command names like
  "cat" or "as" are no better.

o What is the justification for using such obfuscated command names (like
  "df" or "as") for incredibly infrequently used commands? Shouldn't two letter
  commands have been reserved for things you have to type every day? You might
  have better luck remembering those less-frequently used command names if they
  made more sense.

o The default options for "ls" are useless. As a matter of fact, the default
  options for most Unix commands and utils are pretty useless. What is the
  point in "as" (an ASSEMBLER) reading from stdin by default? How many times
  are you really going to need that feature? Wouldn't "--help" be a more
  intelligent default command?

o "--help" command argument tells me that I can get help, but only if I know
  the commands I need help with (if I knew that I wouldn't have typed
  "--help"), or I can type "--help-commands" to get a list of commands. That's
  intuitive and convenient. I really enjoy typing "--help-commands" all the
  time!

o The available GUIs suck rocks. Have you ever tried to use a Unix GUI app
  without a mouse? Forget it. Why can't I hit 'Y' instead of grabbing the mouse
  and clicking the "Yes" button? Why don't the shift-arrow keys on the numeric
  keypad act like the other shift-arrow keys? What if you don't HAVE any other
  arrow keys? How then do you select a text region with the keyboard? Why can't
  I copy and paste text to/from an xterm session?

o I've never seen so many required steps and caveats to get things running
  (take IP Masquerading for example, PLEASE). It's like everything was
  developed to just "get it working" and leave configurability and usability to
  last, and then they never really got around to finishing it. Is this just a
  symptom of Open Source, or is it part of the Unix development mentality?
  "It's okay if it's really difficult to get working, they're using Unix,
  they're used to it".

o Why on earth are filenames still case-sensitive? When would you EVER want two
  files in the same directory with the exact same filename, only differing in
  case? That is not a "feature", it's just a problem waiting to happen! Not to
  mention the headaches of porting from other platforms. Or the joy of
  wondering: "Was that .Xdefaults or .xdefaults?", ".Xinitrc or .xinitrc?".
  A design decision like this one is just indefensible.

In general, I get the impression the developers were purposely trying to
confuse the user (this can't be true, can it?). It's like, if it's too obvious
and logical, then it'll be too easy to use and administer, and that would go
against the principle of requiring users and sysadmins to take years to really
learn how to completely use and administer the system. That would go against
the mentality of "If I spent years familiarizing myself with this system and
learning its quirks, you shouldn't have it any easier". Job security maybe?

I understand there is a "legacy" or a "heritage" in a lot of the ways Unix
works. But if Unix (or any Unix-like OS) is to be the operating system of the
future (or even the present, as far as I'm concerned), it needs to remake
itself into a more intelligent and intuitive user/sysadmin experience.

A few months ago I had to go on-site to a very large company in the UK (okay,
it was Nortel), and they use Solaris solely (albeit via Windows NT workstations
configured as "X terminals"). The "administrator" of the development project
had a problem building our portable source product (a file appeared to be
missing). I asked her to simply search the disk for the file to make sure it
wasn't already there, but in some other directory. She had no idea how to do
that. Racking my brain back to the TC/IX days, I remembered creating a macro
for something like "find -print | blah bla". After some fiddling, I gave up. I
couldn't remember the sequence. None of the other "developers" around us knew
either. Now, these are professional every-day Unix users. If the "find file"
command were more logical and intuitive, I would've remembered it. After some
tedious fumbling around the system, I found the misplaced file. THAT IS TYPICAL
UNIX: What should've taken seconds, took at least fifteen minutes of
aggravation.

I wouldn't have been inspired to write this essay if it weren't for the Unix
big-mouths that are always putting down all non-Unix OSs (in particular,
Windows) and their users. The fact they fail to recognize, is that Microsoft
got a lot of things right that the Unix developers failed to. Not everyone
wants to spend significant portions of their lives learning how to use and
administer an OS. Microsoft has demonstrated that it's not afraid to admit it
has made bad design decisions and change its approach in a future version. Unix
developers needs to learn that Unix too has bad designs and as time goes on,
they are just going to become more and more glaring. The time is NOW to fix
those bad designs.

If Unix had a singular iconic figure representing it (like Bill Gates or Steve
Jobs), I wouldn't go so far as to question his relationship with Satan, or
suggest he should be shot on sight. But I bet a lot of people would...
.