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

On Mon, 2003-09-15 at 12:07, Andreas Fuchs wrote:
> Today, Lawrence MacIntyre <[email protected]> wrote:
> >> 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:-)
> 
> No, I would prefer to not do any post-mortem program debugging at all,
> and instead fix the error as it appears. Not-so-modern-anymore operating
> systems managed to pop up a debugger when an error (most any error, with
> the exception of errors in the debugger (-:) happened. "Segmentation
> Fault" makes me want to smash the screen, really.
> 
> I once saw a talk which presented one of the machines in the videos I
> linked below; the guy who talked about it said that he tried to hook the
> machine on to an old VAX box over ChaosNet. His Lisp machine didn't
> recognize the ChaosNet packet that came in, so it popped up the debugger
> and he could update the version of the entire network stack, without
> rebooting or even dropping this single packet! I'll say that again: He
> hacked around in the network code, and the environment didn't break. He
> fixed a few case statements, hacked this and that, and after a few hours
> of hacking, he had a working ChaosNet (version 4, I think he said it
> was) implementation on this machine.

That would be cool if I cared about that ChaosNet packet.  But I'd
probably be writing some code that was totally irrelevant to it and I'd
be really annoyed by having the debugger pop up right then.  I'd really
prefer that it just drop the dopey thing;-(

> Now imagine implementing a network driver in linux. You'd first write a
> userspace program that talks over a "raw" socket, then you'd try to make
> it work inside the kernel, and after a few 10 reboots and a few times of
> cursing about the lack of debug support in the kernel, you'd have a
> mostly-working solution that is still thought of as likely to produce
> crashes of the machine, until extensively tested for a few months if not
> years. Hmm.

But if you want it to be __fast__, it's got to be in the kernel...

> >> 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:-)) 
> 
> I didn't, but I learned enough about unix to look up "grep etymology"
> in google first (-;
> 
> http://www.faqs.org/docs/jargon/G/grep.html speaks of: g/re/p, "Globally
> search for Regular Expression and Print", which Dennis Ritchie seems to
> confirm (-:

OK.  I learned a new thing today.  Thanks. 

> > tar is Tape ARchiver.  sed is Stream EDitor.  cut and paste are easy.
> > I'll leave that as an exercise for the reader...
> 
> Right, in good UNIX tradition, tar stands for Tape ARchiver, but doesn't
> compress files, leaving the job to gzip. This makes it the Garbling Tape
> ARchiver or somesuch. Whenever a bit on this tape is corrupted, you can
> throw away the whole tgz archive on the tape; gzip won't read it because
> the checksum is wrong - how's that for archival?

The reason tar didn't compress is because it didn't have to.  Of course,
gnu tar (the only tar to use) has alternate compression techniques (gzip
or bzip2) built in.  Back when tar didn't compress, you just piped tar
through gzip to your tape.  Your point about bad blocks on the tape is
REALLY valid.  Having XOR blocks on the tape would be great.  I've been
tempted to add that to tar for at least 10 years.  However, I simply
copy my code to a couple of other systems instead of making backups...

> And, be honest: have you ever used "paste" for anything? I have, but
> it's embarrassing. (-:

Never used it, never will...

> >> 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.
> 
> Availability of source code doesn't mean that you'll be able to fix all
> the bugs. It's a requirement, but not sufficient. A useful means of
> debugging the kernel would be a good thing to have in linux/any unix
> implementations.

It's useful, I bet you really meant EASY.  And you're right.

> >> 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!  
> 
> Sorry, this paragraph gives me the impression that you're suffering from
> User's Second System Effect. (-:

Sorry, I don't know what that means.  What I wrote was __supposed__ to
have been funny.  I'll try harder next time.

> C++ is just C with classes. The development cycle is the same. Except
> that you get to draw all these fancy UML diagrams.
> 
> And never would I suggest that you go develop software in Microsoft
> Windows. Really, what were you thinking?

Good.  I like you better already!

> > 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.
> 
> I'd be happy with programs that, when they exhibit errors, don't crash
> instantly and that are dynamically extensible.

If I'm editting code and the editor dies, I don't want it to pop up a
debugger.  I just want it to die and let me choose another one.  Now if
the code I'm working on dies, then I'm already running it with a
debugger or I'll simply feed the core file (remember them?) to the
debugger and debug it from there.

> >> 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, 
> 
> Then you haven't been looking too hard (-:
> 
> http://sbcl.sf.net/
> http://cmucl.cons.org/cmucl
> 
> are both free Lisp Environments which compile to very efficient native
> machine code on a variety of platforms. If you're not opposed to
> commercial software, also try LispWorks from Xanalysis. This one has a
> really nice development environment, too.

I'll check them out, but really, I hate parentheses...

  LISP - Lots of Idiotic, Stupid, Parentheses.

> > and I'd really rather not have to write network protocol code in lisp.
> 
> Does code speed matter when you're talking over a network?  Hm. I'd
> think that network latency was the speed killer. If not, why are there so many
> network applications in perl and TCL...

Because most people writing interactive network applications only care
about latency, not speed...  I work on high-speed stuff.  f.ex. I've got
a pair of machines that can talk to each other at about 915 Mb/sec.  You
can't do that in perl OR TCL...

> Anyway, take a look at http://www.cliki.net/Etiquette. It allows easy
> definition of network protocols in lisp. Nice stuff.

Yeah, if only you could get rid of those ()s :-)

> And, really, watch those movies. This is 1980's hardware these demos are
> conducted on. My make-of-1992 286 gave me another impression of
> "extremely slow" (-:

I'll try.  really.

> >> 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.
> 
> The OS controls the inter-process communication (IPC). When the only
> accessible means of IPC is the pipe, the socket and the file descriptor
> (which carry a stream of bytes), then that is what the applications are
> limited to. They can invent as many cool data structures as they want,
> but to pass them on to other programs, they still have to use streams of
> single characters - efficient in programmer time or program run time? I
> don't think so.

What about shared memory?

> >> 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.
> 
> Hah. Thank the Heavens that we don't have to.
>  
> Anyway, Emacs already was in existence when the Unix Hater's Handbook
> was written, and people still complained; so I don't count the
> continuing existence of Emacs as too much of an improvement (-;

I never cared for it either.

> >> [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...
> 
> Hah. If you can't find a rational reason for it, it's not a feature (-:

How about just because, or it is simply formatting?  I never thought
about it.

> Good luck and keep your sanity,

to you as well...
-- 
    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/ZgVHCNjP8rawCW4RAm27AJ9x1LzN1urOZ5yyllNs6N6jASyfqgCcDgqu
W40TDV2CsCgz0femIgIhiI4=
=Abg7
-----END PGP SIGNATURE-----