From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 26 Aug 1992 23:47:19 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu
Summary: TMI founder ranting about it all!
Keywords: compat-mode, MudOS, CD, standardization, etc.


In article <1992Aug26.005902.829@engage.pko.dec.com> oakley@contra.enet.dec.com (The Zeeker) writes:
>
>	As far as I can see, 2.4.5 IS a standard.  Nice, it works, not
>	very buggy.  I have yet to see a 3.0 Mudlib in vanilla state
>	that ACTUALLY WORKS !!  That was the great thing about 2.4.5
>	Mudlib, you could do whatever you wanted with it.  BUG-FREE!
>

	I just sat down and wrote two programs that will run on most
2.4.5 mudlibs and bring the mud down.  The only thing they need is to be
loaded.  The first will ask the person who loaded it for the name of
an admin, then move itself to the admin and use the admin's permissions
in order to remove player.c, the master object, and all traces of itself.
The second uses its own security system, and handily bypasses the regular
one by starting a heartbeat and removing all the files in /obj, /room,
/secure, and any other subdirectories of "/", one directory per heartbeat.

	I haven't tested these yet but I'm pretty confident they should work.
They basically show that the 2.4.5 standard is totally insecure unless you
can trust EVERY SINGLE WIZARD on the mud not to write this sort of thing.
Since I'm generally a nice person until I get stepped on or insulted,
I'll refrain from posting them (which I was going to do) because I'm sure
there's a lot of very nice, well-meaning admins of 2.4.5 muds whose work
I would hate to see go down the drain.

	As far as the mudlib situation goes, you're absolutely right.
I certainly wouldn't call the TMI mudlib bug-free, and I don't feel 
qualified to rate any of the others available.  This is a very odd point
in the evolution of LPmuds.  For those who want simplicity, stick with
2.4.5.  But your work may never be ported to a newer, better mud in the
future.  That's the way it goes.  For those of you who are fed up with
the silly hacks in the internals of 2.4.5, but feel ready for something
a bit more complicated, powerful, and flexible... there's no doubt that
3.0 is the way to go, and here is the bold new frontier...

	I don't know who would be qualified to make a 3.1.3 driver
release, let's watch everyone who's made driver mods jump up and offer to
be the one who puts out an "official" release.  When we select one everyone
can start mailing diffs to this poor soul and we'll see what happens. ;-)

	I'll personally vouch for the MudOS driver as being the best,
although I really haven't examined the CD driver or amylaar's driver that
closely for comparison... nor have I seen anything of BatMUD's.  But
there is no standardization committee, there is no real agreement.
Lars isn't a player in this field anymore; his last driver will be a 
standard for people who are happy with it.  It's stable, and supports
both compat-mode and native-mode.  MudOS, while still certainly an LP driver,
(look, we post in rec.games.mud.lp about it!) is an *evolution* of
Lars' work.  We saw that Lars was slowing down and starting to refuse
diffs that were being sent to him, and at some point around 3.0.47 or 
so we just plain gave up sending him our fixes and improvements.

	We basically had no intention of supporting compat-mode right
from the start, and eventually we decided to rip it out so that nobody
would even try to run in compat mode with it and pester us when it didn't work.
When you're trying to break new ground and make a new system, then
backwards compatibility is a real handicap; ask the folks at genesis,
they threw out all their 2.4.5 code and wrote things from scratch just
as TMI has done.

	Now... I'm not going to plug the mudlib I'm working on.
It's a terrible hack with lousy documentation and none of your code will 
run on it without some serious changes, but it does support a few 
nifty things like intermud mail, finger, and tell, virtual rooms (not like
the ones on MOOs, see below for a description), a really nice mail system in 
general, rn (not connected to the real USENET *yet*), a basic guild
system, TMI's excellent multiple channel system (great for guild shouts, etc),
and soon we may be transferring objects from MudOS to MudOS via tcp sockets.
There's also a brand new standard object and standard room that uses
much less memory than the old ones and has quite a lot of nifty features.
It's a hack.  It's lousy.  You won't want it.  It *will* run smoothly
with MudOS and be easy to install, however... unlike the last TMI mudlib
release (*kick Sulam* ;-) ...  I'm also not telling when I'm releasing it
because then I'll kick back until right before then, and either release
a *terrible* hack or have to apologize for it taking extra time (hi 
Fordan and Gunther! ;-)

	BTW, our "virtual rooms" and "virtual objects" are special objects that
don't really map to a file in the filesystem directly; we have some basic
object description languages and object daemons that produce these "virtual
objects" whenever needed.  This is great for large, spread out areas, also the
object description languages can make things much easier for people to build.
We've had these for a few months now, so I'm a littled peeved that the MOO
folks haved coined this term for something totally different they've hacked
up...

	Anyhow, there's quite a lot of interesting work being done at TMI
and on some secret developmental counterparts to TMI.... (shhhh!)  As the
remaining founder of TMI who's still in charge of things on the day-to-day
level, I'd like to thank all of the people who have helped to make TMI
happen.  It's been a fantastic place to work on, and if we don't find
a usable new home before the 31st, then rest assured that while TMI
as we know it may cease to exist, it shall live on.

	If we don't find a site that can handle the main mud and allow us
to give coding directories to most anyone, then you can rest assured that
the MudOS team and the TMI mudlib development team will continue to develop
code destined for eventual release; we do have other places running MudOS
and we most likely do still have a place for me to run a small mudlib
development mud.

	Regardless of whether TMI or MudOS or CDlib/Genesis or BatMUD or any
of these primitive virtual realities stay alive forever, let's cherish them 
and respect them for the paths that they are taking; let's not argue about
whether one is "meeting the spirit" of LPs or deviating.  I think TMI
has been deviating for quite some time now and I'm pretty happy with it.
If it dies... remember... "Muds come and go. They are born and they die.
From the ashes of one another may rise."


-Adam Beeman
Buddha@TMI

P.S. If you are a system administrator of a fast, powerful machine on 
the net with lots of disk space, and would like to be the home of one
of the most controversial LPmuds on the network, mail me.  There can be
only one.

-- 
#include <std_disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
Newsgroups: rec.games.mud.lp