[DGD] Where did all the players go?

[Blain]

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