From: garnett@gestalt.austin.tx.us (John Garnett)
Newsgroups: rec.games.mud.lp
Subject: Re: MudOS a ripoff?
Date: 27 Aug 92 07:03:17 GMT
Organization: none

In article <geoff.714882644@bruce.cs.monash.edu.au> geoff@cs.monash.edu.au (Geoff Wong) writes:
>jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>
>
>>Our own version of mappings, mainly snagged from Perl
>>Wrappers around malloc(), realloc(), and free() which allow keeping
>>  track of memory (for a small overhead)
>
>Hot stuff! Catching up with the Joneses.

Catching up with what Joneses?  Mappings have been in MudOS since
0.8.14 or before which I believe is right about the time the first driver
to have mappings came out with them.

Regarding the malloc wrappers, sure they aren't any big deal but they do
allow machines like the NeXT and RS/6000 to more closely monitor
memory usage (since these machines can't use the smalloc.c file from
3.1.2 because smalloc.c redefines system calls like malloc(),
free(), etc which cannot (easily if at all) be redefined on the
NeXT, RS/6000 and probably other machines as well).

[btw, actually only a small part of the MudOS mapping implementation
was taken from Perl -- the extensible hash table scheme and the names
for the various mapping-related operators.]

>>When the name changed to MudOS, I was of the opinion that it was a
>>bit premature.  As things stand now, though, I think it is undoubtedly
>>a wholly different driver. 
>
>I doubt it - still uses the same string hashing, same backend, 
>same chained hash tables for objects etc.

You seem quite confident in your assertions.  Funny how that doesn't
have much bearing on the correctness of what you say.  Fairly
extensive work has been done on each of the areas you mention except
for the chained object hash table (and what pray tell does the
structure of the chained object hash table have to do with the underlying
structure of the driver?  They could change the driver so that objects
are stored in a B+tree instead of a hash table... so what?  That doesn't
change the basic structure of the driver).

Of course, the basic structure of much of MudOS is the same as LPmud.
That is why the README file calls MudOS an enhanced LPmud driver.  As I
recall, the main reason for giving the MudOS driver the name it now has, is
that the MudOS team didn't want to have to deal with people complaining when it
didn't run mudlib.n (or whatever other 3.1.2 mudlib they might have).  Names
such as LPmud-xyz should be reserved from drivers that can run unmodified
3.1.2 mudlibs (as an aside, just how many vanilla 3.1.2 (native) publicly
available mudlibs are there if you don't count mudlib.n?).  MudOS doesn't
do that and doesn't claim to (although the required modifications to the
mudlib aren't many).  Another good reason for changing the name is that MudOS
doesn't have 2.4.5 compat mode in it.  The MudOS team simply wasn't
interested in maintaining the strict compatibility with vanilla 3.1.2
that an LPmud-prefixed name should imply.

>Simply your arrogance in thinking you've produced a new

If like is indeed good at recognizing like, then perhaps the MudOS team
has some cause to pay attention to your accusation of arrogance.

>product has caused you to change it's name. I doubt whether
>your changes are particularily significant. Certainly not
>a "new" mud started from scratch - hence it doesn't really deserve
>a name change.

Regardless of whether or not the name change was a reasonable thing
to do, many of the changes that the MudOS team has made to LPmud are
worthwhile and do consititute the end result of considerable effort
and time.  If you'll take the time to ftp MudOS, you'll see that all
of Lars' copyright is included and that no attempt has been made to
claim original authorship of any code in LPmud 3.1.2. Argue about the
name all that you like.  Who cares...  It's the actual _thing_ being
named that matters.

>Ho Hum.
>The vorpal blade went snicker-snack.

...and evidently snicked a little close to the seat of your ability to make
a reasoned argument.

--john
-- 
John Garnett                   John.Garnett@gestalt.austin.tx.us (NeXT Mail ok)
                               garnett@gestalt.austin.tx.us (NeXT Mail ok)
                               gestalt!garnett@cs.utexas.edu (NeXT Mail ok)
                               garnett@cs.utexas.edu (non-NeXT Mail only)