From: jess@gn.ecn.purdue.edu (Jess M Holle)
Subject: Re: YA Mac horror story
Organization: Purdue University Engineering Computer Network
Date: Tue, 26 Jan 93 21:52:58 GMT

[details of a horribly implemented in-house Pascal environment deleted]

This sounds like a mess of programmer's faults and failings, not the Macs.
Think Pascal would not put you through such turmoil, I assume, since Think
C is the easiest, most usable C programming environment I've ever used.

[details of locking a system by mistaking close for quit deleted]

Actually, the fact that the application does not quit when you close its
last menu is a BIG advantage.  You mentioned Mathematica.  It is a slow,
loading pig, but otherwise nice.  If you load the wrong file, then close
it to use the Finder to find the correct one, you only have to wait a
split second for the file to be loaded.  If the program quit when the
last window was shut, you'd have to go through that long program loading/
initialization wait again.

This is just one example.  The system lockup that you mentioned due to
the number of programs hogging memory has been fixed in the System 7
Tuneup 1.1.1 and System 7.1 (if you don't use these, don't complain).
These systems simply inform the user that they need to quit a program
that is still running before continuing AND make a suggestion as to
which one to quit first.  If the user clicks quit, the program in
question will be quit.  Programs with no open windows are mentioned
first.

The fact that other systems quit when the last window is closed is in
many cases a limitation in the GUI code.  On many systems, you cannot
use any calls from the GUI libraries without an open window.  This is
annoying.  Also, the Mac system is nice when compared to the OS/2
problem I recently mentioned where novices start 5 INSTANCES of each
program and wonder why thrashing and eventually crashes occur.  This
is due to the poor distinction between iconizing and quitting under OS/2.
NEW users cannot tell the difference.

>The stupid cluster people disabled cntrl-openapple-reset, so I had to
>turn it off and on.  No big deal, but why they did it is still beyond me.

This is indeed unfortunate, BUT many system administrators do this to
prevent you from breaking out of virus checks and various file access
protection programs.  This is STUPID, but oh well.

>Okay, I traverse the server till I get to my class section.  Wow, Mac's
>built in network is slower than my NFS connection across the country;
>hmmm.  After 1 minute of no usage time, I get to use the system again. 

This is most likely due to: (1) lack of adequate server power for the
number of nodes that are running off of it AND/OR, more likely, (2) the
fact that you are running over RS-422 localtalk, rather than Ethernet,
Appletalk CAN run over Ethernet.

[more whining related to the above paragraph deleted]

>I ftp everything to my computer, so I can do my work on my system
>instead.  So, I ftp to my ftp server on my computer.  I transfer
>everything, again noting that transfer rates were only about 8k per
>second.  I attribute that to the Mac of course.  I also try transferring
>something from my computer to the Mac.  I then realize that Macs have a
>limit of 32 characters on filenames.  Much smaller than 256.

First, I have only once ever wanted to name something with more than 31
characters.  Second, I experience much better rates than those that you
mention, ftping on the Mac over an Appletalk network, through a gateway,
to ftp sites around the world.

>ps- that was mostly true.  the exaggerated parts weren't exaggerated
>that much, at least no more than 10%.  BTW, I'm not that stupid, I'm
>just making obvious remarks.  Just to piss off some Mac owners.  I had
>to wake you up to the fact that Macs aren't the ultimate computer. 
>There are some nice things about the system.  Generally however, I don't
>like it.  It may be easy to use, in fact, I'll personally vouch for the
>fact that it's probably the easiest computer to use to date.

See my recent grousings about novices attempting to use OS/2.


Jess Holle