Re: Re: Learning from history - The UNIX-Hater's Handbook (Peter Quirk)

> To: [email protected]
> From: Andreas Fuchs <[email protected]>
> Date: Mon, 15 Sep 2003 08:14:19 +0000 (UTC)
> Subject: [Annoyances] Re: Learning from history - The 
> UNIX-Hater's Handbook (Peter Quirk)
> Reply-To: [email protected]
> 
> On 2003-09-14, David Utidjian <[email protected]> wrote:
> >> You will find a wealth of material in the UNIX-Hater's Handbook at 
> >> http://web.mit.edu/~simsong/www/ugh.pdf. This work was 
> published in 
> >> 1994, just as Dee-Ann was getting interested in computers. 
> Little has 
> >> been done to correct the deficiencies described therein 
> except POSIX 
> >> standardization of the shell and some APIs.
> > 
> > I disagree. On what do you base your assertion that little has been 
> > done?
> 
> Facts. Opinions. (-:
> 
> a) applications crash, leaving core dump files lying around 
> (or not). No debugger pops up. If you had unsaved state, it is lost 
> unless you can pry it from the core file, which is nicely named
"core", 
> without any indication of which program left it (BSD names them 
> "program.core", which is a little better)

This is annoying when working with text based programs.  Some Window
Managers are a little better about giving the error report to screen
with an option to send the error report to the appropriate party (if
configured). None are perfect, though.  

If someone has a fix, please share it.

All operating systems could do better in this regard... though I would
be happy with the BSD functionality at least.

> b) Command syntax is garbled (think also shell quoting rules). Nasty
>    command names abound. For which command is "grep" an abbreviation?
>    "sed"? "tar"? "cut"? "paste"?? Are these programs still used for
>    these purposes?

The problem with longer and "understandable" names on the command line
is that you have to type them out.  Save us all from having to type so
much, please don't make the names "friendly."  

You have to admit that typing "tar" is preferrable to typing
"tapearchive," especially if it comes on the heels of having to type
other longer "friendlier" names.

If you want friendlier names, you can create a .bashrc file in your home
directory and make a bunch of alias statements to handle those and then
make sure that your .bash_profile (different if you don't use bash as
your shell) file in your home directory reads through and assigns those
names when you login.

So you would have something like this in your .bash_profile:

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

Then your .bashrc file would have something like:
alias backup='tar'
alias copyfile='cp'
alias renamefile='mv'
alias movefile='mv'
alias ...
... 
...

You see what I mean.  If you don't believe me.  Try working in DOS
copying files for a day.  There is not much of a difference between "cp"
in Linux and "copy" in DOS (only two letters in fact), or even between
"ls" in Linux and "dir" in DOS (only one letter) but you do FEEL the
difference after typing them all day.

As far as switches go, same thing.  The "-" single letter combos can be
a pain, no argument.  Most, but not all, commands have "--" options as
well.  These are usually followed by full words that generally describe
what they do and the are great.  But typing them often could be a pain.

A handy trick that I teach all Linux/Unix newbies is the -h or --help
trick.  Virtually all, but not all commands support it.  These switches
will show you the syntax of the program you are working with and a brief
description of the switches that it can handle.  It can be a lifesaver.

Try it with the "ls" command sometime.  If one doesn't work, try the
other. Some of what "ls --help" brings up includes:

Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuSUX nor --sort.

Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not hide entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               print the author of each file
  -d, --directory            list directory entries instead of contents

Again for single commands or for jarring the memory, the full words are
great.  

ls --almost-all --directory 

is a great command and, except for the "ls" (which could be solved with
an alias, alias directory_list='ls',) is completely readable.
Unfortunately, especially with the alias substitution, it is carpal
tunnel waiting to happen.

directory_list --almost-all --directory

UGH!  I prefer "ls" your mileage may vary.

> c) When you encounter a kernel bug (and subsequent crash), you have
>    lost.

This needs to be fixed in all programs as well.  If you haven't
experienced an "infinite loop" kernel crash in Windows NT/2000/XP where
is reboots to bluescreen over and over and over, you should count
yourself blessed.  I don't know of a fix other than reporting as much
information as you can to your distribution's Bug database and hopefully
they can work with you to find a fix... in a way this is a unique and
wonderful thing.

> d) You get to write programs in languages such as C, which 
> force you to
>    go through a cycle of
>    write-compile(&fix-errors)-run-crash-debug-(&fix-errors). This
>    development cycle, I'm sure, is responsible for "good enough" tools
>    such as make[1] and other berkeley abominations.

This cycle is actually key to finding a lot of bugs.  An programmer's
IDE can help show syntax problems but it can't fix problems with
incomplete programming logic and misplaced assumptions.  Only a rapid
development cycle can.  The write-compile-run-debug-write cycle is a
rapid development cycle in miniature.

I wonder if there is imperical evidence to show any of this?  Does
anyone know?  I bet a case could be made anicdotally for either side.

Better tools are needed all around.  Might I suggest Kylix as an IDE for
Linux to help with some of these tasks... or EMACS or Kdevelop.  I am
sure there are a host of others out there.


> e) The entire Unix Hater's Handbook chapter on X window with the
>    exception of speed issues still holds. As an addition, there is now
>    XAuth and SSH forwarding to worry about.
>    
> And some others. Life does not have to be like this; and it 
> wasn't, for some users of machines, even back in the 1980s. 
> See the amazing videos made by Rainer Joswig (on 
> http://lemonodor.com/archives/000441.html#000441
> - be sure to follow all the links). Also, see 
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-i
nfo/symbolics.html
> for more resources.
> 

There was a project written in Pascal (I can't remember the name) that
was pretty amazing (considering the time) a while back.  Be was also
great.  Greatness doesn't always necessitate success however... look at
batamax

> Unix or Linux is by far not the last word in User Interface 
> Design. People have gotten it right (or at least, more right) 
> before. And, amazingly, this "getting right" wasn't done in 
> UNIX. There are amazingly useful data structures out there. 
> Why then do we need to use tools that were written in the 
> 1970s, to fix 1970s issues, operating on One data structure, 
> the stream of bytes without structure, most of which focus on 
> working around the issues arising from the use of exactly 
> this data structure?
>

Unix has proven itself over time.  It is incredibly stable (compared to
other OSes and is virsatile enough to allow for graphical systems (many
different ones) to be placed on top of this solid foundation.  Given
that it has taken 30 years to get to a system this stable, most people
are reluctant to work with an OS that may take another 30 years to reach
the same state.  The thinking is to improve that which has been shown to
work already.

That could be faulty thinking... but it exists.  Computer Science is
still a relatively young discipline, as I am sure you know.  It may take
a while for the next great breakthrough to take hold.  LISP machines
are/were amazing.  I am sad to see Be and Amiga go (for the most part)
the way of the dodo.  I don't know what it will take to make things
better AND different.

I understand where you are coming from.

<snip> 

> Andreas Fuchs, <[email protected]>, [email protected], antifuchs
> 
> 
> --__--__--
>