[DGD] Where did all the players go?

[Blain]

I guess we can also contribute various stock mudlibs.  I've been working on
a bare bones lib that offers a lot of utility in a small package.

I think it should be based on the kernel, but should have a System wrapper
around the kernel, perhaps.  Or a combined version where all code outside
the kernel can be very customized.  It could have a lot of ifdefs to turn
features on and off, like many of the MudOS distros I used to tinker with.
I have been implementing various LPMUD-esque things in my bare lib, such as
reset/clean_up, heartbeat, etc.  A fully functional object database with
fill automatic upgrade capability is also a must.  These things can be in a
kernel, possibly, and not specific to any one mudlib distro.

I'm also working on a scalable 3D coordinate map system which can handle a
medieval/fantasy flat earth as well as a vast, expansive space game with
planets.

On Dec 12, 2017 3:45 AM, "Blain" <blain20 at gmail.com> wrote:

> apt-get install kernel-dworkin
>
> On Dec 12, 2017 3:41 AM, "Felix A. Croes" <felix at dworkin.nl> wrote:
>
>> bart at wotf.org wrote:
>>
>> >[...]
>> > As you mention, keeping the mudlib uptodate this way is more difficult
>> because
>> > of user changes to that lib. I tried to do a few things to reduce this
>> issue:
>> >
>> > - Make things 'pluggable', ie: Gurbalib's safun setup allowed for
>> adding and
>> > overriding afuns in a way that should not conflict with updates to the
>> lib
>> > (this is no longer the case in the current version)
>> > - Strictly dividing the lib in a 'kernel', 'lib' and 'user' part. Only
>> touch
>> > the 'user' part (which included the safun dir)? You should be fine.
>> > - Modified the 'lib' part? This should still be relatively easy, but
>> requires
>> > work for merging changes
>> > - Modified the 'kernel' part? You are on your own.
>>
>> This dovetails with my own experience.  I came to the conclusion that you
>> need a kind of package manager for inside the persistent mud, and that the
>> OS-level package manager can only mess things up; that is another reason
>> for desiring the isolation of a container.
>>
>> What a persistent mud needs goes further than a traditional package
>> manager,
>> because of runtime upgrading.  I have not yet settled on any particular
>> solution.
>>
>>
>> > This worked somewhat, but, people find enough reason to modify the lib
>> part to
>> > still make this a lot of work for both the maintainer of the core
>> > distribution, and the users. Additionally, it also meant a fair bit of
>> extra
>> > work to ensure lib upgrades always worked, or in cases where that was
>> not
>> > possible, at least ensure they pointed at the proper way to upgrade
>> (requiring
>> > specific inbetween versions for migrating data).
>> >
>> > At any rate, keeping a mudlib distribution uptodate and facilitating
>> in-place
>> > upgrades of muds using it is a pretty big challenge due to data
>> conversion and
>> > having to provide ways to upgrade user data, even when people do not
>> modify
>> > the core lib.
>> >
>> > Part of the issue here is this being a somewhat unusual approach for
>> most
>> > people. Understanding the in-place recompilation of code is already a
>> bit of a
>> > challenge, doing proper data conversion seems a bridge too far until
>> people
>> > gained significant experience with the system.
>>
>> This is true even for non-mud database professionals.  Mention runtime
>> upgrading, and they will insist that bringing the database down for
>> maintenance is a better solution.  Mention hotbooting, and eyes start
>> to glaze over.
>>
>> Regards,
>> Felix Croes
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>
>