From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.mud.lp
Subject: Re: The horrors of native mode (Was: Re: Gamedriver survey [LONG])
Date: 13 Oct 92 15:45:32 GMT
	<14928@chalmers.se> <1992Oct13.043137.4367@rhrk.uni-kl.de>
Organization: Chalmers University of Technology, Sweden
In-reply-to: behrends@arctecws-12.dfki.uni-kl.de's message of 13 Oct 92 04:31:37 GMT

In article <1992Oct13.043137.4367@rhrk.uni-kl.de> behrends@arctecws-12.dfki.uni-kl.de (Karl Reimer Behrends) writes:

Better many small articles than one large :-)

> |> That we now and then fail to make our code understandable is hardly an
> |> excuse to accept it generally. Only an indication that we at CD are not
> |> perfect, big surprise...
>
> Of course not. I just wanted to point out that difficult code isn't solely
> written by Amylaar. And the CDlib suffers heavily from overmodularization.

I have never ever stated that only Amylaar writes code that is hard to
understand, my main objection is the fact that he sees no fault in doing so.

> |> > [... security within CDlib ...]
> |> >
>
> Sure, I didn't intend to post any security leaks that were really dangerous.
> My intention was to show why uids are too weak a concept for security, given
> this code as an example.
> 
> Again, I just wanted to demonstrate that export_uid() is inherently
> dangerous. The security of the CDlib isn't the point under discussion
> (although I could probably find some nice security leaks ;-).
>
I could serve you a platefull and then Felix Croes (aka Dworkin) could 
serve you a big dessert :-) I agree, the use of the uid system in diverse
mudlibs are not the point here.

I think the uid system is much better than the old 2.4.5 way of relying
on a logged in wizard. Especially as each of a wizards object now can
have his rights, without him being logged in. The reliance on the wizard
being logged in was one of the main reasons for the design of the uid
system. Increased security was a secondary motive together with the
deletion of a lot of hardcoded crap in the GD.

> My main concern lies with key concepts of native
> mode, namely the design flaws in create()/reset(), move() and uids.
>
I dont claim them to be perfect, but they are IMO a lot better than
the old 2.4.5 concepts. 

> Considering them to be a step backwards and showing that we don't need
> to switch to native mode to use its presumed benefits I just asked:
> Why have native mode at all if
> there are essentially only drawbacks associated with it?
>
Well, I'd say most experienced LPmud wizards simply disagree with you.

Native mode is simply much better than compat-mode. It is so because
it was designed to take away all the garbage and inconsistencies in
the prior version. All the known crap in the old version was corrected
or deleted. This does not mean that new garbage hasn't turned up later.

> I also think that a total overhaul can help cleaning up the code and
> removing unnecessary kludges due to design problems. But the
> specifications and the interface shouldn't be altered radically.
>
The problem of course being that there hardly were any specification
to start with. The GD grew on the demand from LPC coders. It was and
still is, a patchwork. This is also true of the 'interface', just
consider filenames and leading '/' in the older versions.

When we at CD started with the new version we expressly ignored the 
demands of backwards compatibility. It was our opinion that the entire
GD and mudlib needed a new design, a total overhaul.

> Just consider what would happen if some manufacturer of UNIX made
> the argument of malloc() the number of ints instead of the number of
> chars to be allocated.
>
Isnt this what AIX did, hmm not exactly perhaps :-)
I'd expect something like this in AIX or ULTRIX though.

> He wouldn't be able to sell a single copy. Changing
> specifications radically just doesn't work in the real world -
> especially if you've got a user base to support.
>
Well, we make no money on LPmud, we have no obligations, we do what we
like and we do it because we think its the right thing to do and
as long as it keeps us happy. If you dont like it make your own thing.

/Johan

--
Johan Andersson           | "You don`t have conversations with microprocessors
Chalmers, Sweden          | you tell them what to do, and then you helplessly
Email:                    | watch the disaster when they take you literally."
d8andjo@dtek.chalmers.se  |	Sah`ot in David Brins "Startide Rising"
Newsgroups: rec.games.mud.lp