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

On Mon, 2003-09-15 at 04:14, Andreas Fuchs wrote:
> 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)

Would you prefer that they crash, leaving nothing?  The file command can
tell you where it came from.  If I had any core files on my system, I'd
give you an example:-)

> 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?

grep is the General Regular Expression Parser.  I'll bet that you didn't
go to the School that Peter Quirk wrote about, you'd know that:-))  tar
is Tape ARchiver.  sed is Stream EDitor.  cut and paste are easy.  I'll
leave that as an exercise for the reader...

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

You should get an oops which will tell you what happened and allow you
to use the kernel debugger to figure out what happened.  After all, you
DO have the source code for the OS.

> 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.

We all know that using MS VC++ allows you to write bug-free code the
first time with no crashes ever.  That's why there are no bugs in
Windows XP!  And we're all jealous that Linux isn't that way... 
Creating complex bug-free code (that actually does something) without
debugging is, sadly, beyond the state of the art.  I know that there is
all sorts of research into clean-room design, but the methods they use
are far less efficient than the afore-mentioned cycle.

> 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-info/symbolics.html
> for more resources.

You obviously have a great love of parentheses:-)  Lisp is neat, but all
of the implementations that I've seen are extremely slow, and I'd really
rather not have to write network protocol code in lisp.

> 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?

While the OS doesn't enforce data structures on the applications, they
applications DO have data structures.

> Hmpf. Back to your question above, much has changed. Much has been
> done. But not much (save for its speed) in UNIX nor Linux has changed to
> the better.

I think that it's better.  For instance, we don't have to use vi to
write code anymore.

> [1] the author of `make' was reputed to not have fixed an early bug in
>     the file syntax (you have to prefix every "command" line with a TAB
>     character; it will barf when it encounters things like 8 spaces)
>     because he already had a few 10 users. This bug is still present in
>     "modern" make implementations.

I thought that was a feature...
-- 
    Lawrence MacIntyre     865.574.8696     [email protected]
               Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA/Zcn0CNjP8rawCW4RAiQxAJwIQZkWj+08kY/vuVGD4Q9sltV+FQCeP0XB
97xhNOeNPPpma5jtQhmc5I0=
=ntUL
-----END PGP SIGNATURE-----