Re: Randy's inherent hate of Apple IIs

[toddpw@ugcs.caltech.edu (Todd P. Whitesel)]

nathan@visi.com (Nathan Mates) writes:

>random lockups. I've been told by others that my quick hack of
>Segfaulter finds *more* problems than Apple's own inhouse memory
>utilities (Scrambler, etc).

Including me.

For six years, on July 4th weekend, there has been Anime Expo, a convention
for fans of Japanese animation and related entertainment. Its registration
system was run entirely on IIgs's until 1997, where the sheer number of
walk-in registrations required us to use a more scalable system based on
terminals plus free unix. (We got a new department head with SQL experience
and that had a lot to do with it too.) Due to a last minute printer death,
however, the previous years' IIgs system was hastily adapted to accept
ASCII data from the freebsd (chosen because it supported the surplus 8-port
terminal interface that had been scrounged) box and print it.

During all the time we used the IIgs's, there were only a few crashes under
fire. Because of the robust design I had used, we never lost any important
data. But one year we did discover a memory leak.

When we were done for the day, we set up a couple IIgs's in our hotel
room and Nathan went after the leak with Segfaulter. Later that night he
had located the culprit in part of Pointless.

>   This is why I like things like the unix variants distributed with
>full source included-- if something's wrong, YOU CAN FIX IT. It's

Yep, but the mythical FST spec is not source code. It's an API that other
source code depends on. Apple knows that if they published it, it would have
to be adequate for someone to use without changes, or they would have to be
willing to change it. Both options were rejected, so they opted not to
release it. This happens a lot with crappy "standards" (HP/UX a.out format
is one I can think of pretty quick).

If you created something that worked, but sucked, wouldn't you prefer to
keep it under wraps so that it doesn't become a standard you no longer have
control over until you have a chance to fix it? Sure you would. It's naive
to think that by "setting it free" the world will generously correct its
flaws for you. No. If it's not useful as is, no one uses it. If it _is_
useful as is, then it will become a de facto standard for something and
everyone will rail on how crappy yet entrenched it is. One word:

uuencode.

> [That's kinda why I *like* working on console
>videogames-- no chance in hell of patching, so you gotta do it right
>the first time]

Ah, but there's a lot in video games that is well known, thus feasible to get
right. Games that push the edge are buggy, so you test them a lot and pray.
That is also what is done with most cutting edge software. It is certainly
true that a lot of programmers have gone lazy, but there are plenty of
reasons why the current climate in the industry lets them get away with
it, in true Dilbert fashion. I don't like it either, but it is the present
state of things.

Todd Whitesel
toddpw @ ugcs.caltech.edu