[DGD] Where did all the players go?

[Raymond Jennings]

This runtime thing can get even hairier when you have user-end code
that depends on inheritables that may or may not need upgraded

On Tue, Dec 12, 2017 at 1: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
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd