[DGD] Where did all the players go?

[bart at wotf.org]

Updating kernel or system will almost always result in having to recompile
part of the user code. Layerung won't really prevent that. 

In all fairness, unless you have been running a persistent mud for quite a
while, or done live database conversions on a running system or such, its very
difficult to realize what really needs to happen.

Bart
On Tue, 12 Dec 2017 03:53:45 -0600, Blain wrote
> 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
> >
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/