[DGD] Melville under the Kernel Lib

Bart van Leeuwen bart at wotf.org
Fri Feb 6 14:47:30 CET 2004



On Thu, 5 Feb 2004, Michael McKiel wrote:

> In the past archives, Steven has stated if he were to "do it again" he'd
> prolly choose to go on top of the kernel. Yet in quite a few posting's also
> has stated a 'distaste'(?) for the directory depth's of such.
>
> Yet there doesn't seem to be any way to accomodate (what we've been calling)
> the Klib without "breaking" its directory requirements, and making it innured
> to any future patches from the experimental line of DGD.
>
> So a question for Mr.moby and others that are either building ontop of the
> Kernel and/or "breaking" the kernel. How doable would changing that spec
> around be to something like:
> /lib/kernel/
> /obj/kernel/
> /sys/kernel/

Well, that would mean 3 instead of 1 security check whenever I need to
know if somethign was called from kernel code or not..

>
> and if we look at Noah's additional usr's like "common"
> /lib/common/ etc...
> and perhaps putting "/usr/System/" into non-subdirectoried
> /lib/, /obj/, /sys/
>
> For the purposes of "file Security/inheritance/clone/update/et al" I think
> that would work. What I'm not sure about atm, would be the feasibility of
> "resource management" which for coders themselves in a /home/<username>,
> would be easy enough to follow the current Klib design. But not sure about
> resource management of non Coder/wizard's under this route.
>
> Would it be worth the restructuring? Or should one just bite the bullet and
> work under the Nazi Klib file regime ;)
>
> The few posts of Skoto's that referred a filepath would seem to indicate a
> non-KernelLib obeying structure.  So what have others done in this regard?
> And how might you structure Steven?
> I didn't much care for the Klib design, but least I understand it more now,
> but the other admin is fairly adamantly against it, which is leaving us at a
> bit of an impass I'm not sure how to resolve without possibly too much
> unneccessary work at 'breaking' the klib to bring in features we'd just like
> the "Melville-like" directory structure to support.
> Thanks,
> Zamadhi

I have not really looked at Melville, but I come from a very ancient
LPMUD, and attempting to port some area and lib code from there to DGD
strongly suggested to me that I have 2 choices:

- Go for the kernel lib and accept substantial changes to the area/lib
code, also accept that this means that most of our builders and coders
have to relearn many things from scratch

- Build our own kernel that provides a high level of compatibility with
our old environment while incorperating as many of the klib features as is
possible.


It is clear that the first will give the technically best solution, but
the 2nd is simply much more workable for us. We do have enough skilled
peopel to slowly but surely get a kernel done, we simply lack enough
skilled people to revamp all the area and remaining lib code and educate
the other coders and builders meanwhile.

The consequence is that there is a few things we wont have for a while,
and maybe will never have, but what we have will work exactly as we want
it.

Hope this helps a bit for making up your mind.
Bart
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list