    Patches?!?
    (We doan need no steenkin PATCHES!!!)

    Updated 09 March 2007

    The Principle

    My goal is to make Dead Souls the best, most kick-ass
    LPC lib ever. I interpret this to mean that when I
    see a flaw, or someone else points one out, I want
    it fixed. And, well, the fixing falls to me.

    Releasing updates lets people share in the cool new stuff,
    and it also helps me fix new problems.

    Previously, I felt that "my way" of releasing stuff
    was good enough. However, since making it convenient
    for people to upgrade makes it convenient for me to
    develop, I've changed my policy and worked on simple
    and convenient upgrading processes.

    The History

    1) Tarballs

    After a while of fixes accumulating, I declared it to be a
    new release and off it went, into the world. At first this
    caused a lot of grumbling, because it meant people had to
    reinstall from scratch every time I made a release,
    and this was a bit much for many people.

    It occurred to me that I could compile a package that
    had only the files that changed between releases. I
    put this together, and people seemed to really like
    being able to upgrade from one release to another,
    without a full reinstall. Over time, this system
    has been tweaked and refined somewhat, but in the
    end, it's roughly the same type of thing it was back
    when I produced the first one: a bunch of files.

    However, it's kind of a pain for me. Also, since
    people feel it's inconvenient to download the patch
    and uncompress it (?!?) they rarely upgrade, so it
    defeats the purpose.

    2) OOB Liveupgrade

    So I decided to set up an "in-mud" upgrade system.
    Rather than go on the web, download stuff, and install
    it, people would issue commands in the mud to update.

    The protocol I chose was I3 OOB, because I wanted to
    polish up on it, and because it seemed like it
    would be easy to maintain. Sure enough, it worked
    great and was easy to maintain. People would issue
    the "liveupgrade" command with the correct parameters,
    and they would pull updated files from a mud that
    worked as a liveupgrade server. Beauty!

    Problem was, it was dead slow. I mean, really slow.
    It was a line by line transfer with sanity checks
    throughout. On a fast system with large bandwidth,
    it could take 15 mminutes or more to upgrade to a
    new alpha release. On a slow machine sitting on a
    skinny pipe, it could take more than an hour.

    And on flaky connections, sometimes (rarely, but
    occasionally) the upgrade would stall.

    Since people don't really have the patience for that
    (and really, I know I don't have it), I figured a
    new way would make sense. Plus, with the development
    of IRN, using OOB for sensitive stuff like this
    stopped making sense, from a security standpoint.

    3) HTTP Liveupgrade

    So starting in 2.3a14, Dead Souls liveupgrades happen
    over http connection to dead-souls.net. It is
    insanely fast, with a complete upgrade taking around
    a minute on a fast machine.

    The drawback is that there are still kinks. It is
    possible to do a liveupgrade that pulls 404 files,
    if your connection is unstable. And, of course, this
    means you'd have to restore from backup.

    4) Back where we started

    If a liveupgrade error hoses things up, there's no
    need to panic. Just download the appropriate patch
    file from http://dead-souls.net/code/patches and
    install the old way. That will fix everything.

    The Mechanics
    The patching process is just as primitive as it
    sounds. You uncompress these files and copy them
    over your existing mud. Simple. Efficient.

    Player files, directories, and domains that are
    created by you are left untouched.

    For some people this system is problematic. Some folks
    are proficient at modifying lib code, and if they
    just overwrite their mud with the contents of a patch,
    they might find that their lib work has been clobbered. This
    would be bad. That is why my patch instructions
    strenuously remind people to back up the current mud
    before patching it.

    There is no practical solution for this problem that
    I can see. Because I am just one guy, and my goal
    is lib code, and not patch-process-design, I have
    decided to leave things as they are. In theory I could
    write code that would analyze and modify files as
    needed, rather than simply have the owner overwrite.
    However, this is a lot more complicated than it sounds
    to implement in LPC within the lib, and it is also
    non-trivial to implement this at the OS level, given
    that the process would have to work on multiple different
    platforms.

    It's my opinion that people sophisticated enough to
    need a more specialized patching system are
    sophisticated enough to work around my shortcomings
    in this area. Indeed, I've heard of folks who just
    download the complete new version, run diffs against the
    old one, and then pick and choose what to add.

    For now and the foreseeable future, patches are just
    a Big Dumb Ball of Files...with one exception.

    Each patch includes a file called /secure/daemon/update.c
    which carries out special functions that are not dealt
    with by just overwriting files. When you reboot the mud,
    update.c will do things like remove broken/dangerous files,
    rename files with incorrect names, and modify text in
    files (such as config.h) which should not be overwritten
    but need to be changed.

    The Philosophy and Controversy
    Believe it or not, I've had people become irrationally
    angry at how often I make releases. Not just "That darn
    Crat is driving me crazy", but actual, unhinged flaming
    well beyond any reasonable context.

    Don't believe me? Check it out for yourself:

    http://www.justrage.com/article.php?story=cratylus_dead_souls_mudlib

    It *is* true that I'm averaging a release every week
    or two. The person is correct in that there are a lot
    of bugs to fix, and that releases happen much, much
    more often than they do for other muds.

    I have no defense against this charge. All I can do
    is explain the reason for it, and hope it is justification
    enough.

    When someone tells me Dead Souls has a bug, I want to
    help them. I want to fix it. I feel responsible to the
    mud community to do what I can to fix whatever problems
    they've run into because they've adopted the lib I
    wanted them to. This is probably irrational on my part,
    and if I'm lucky, I'll stop feeling this way sometime
    soon. But until I do, I feel driven to be a responsive
    lib coder, and I fix stuff. And I release it.

    The question is, "If Dead Souls is so lame it needs
    constant patching, shouldn't you kill it?"

    The thing is, Dead Souls is the best LPmud lib out
    there that I know of, *right now*. If the standard is
    going to be perfection, then there's no lib out there
    that should be available. There's no LPC mudlib
    out there that you can download that is as featured,
    solid, widely adopted, and supported as Dead Souls. If
    the criteria for killing a lib is that it's not
    perfect, and if Dead Souls is among the libs to be killed,
    then just about everything needs a good flush.

    It should be noted that Dead Souls doesn't *need*
    constant patching. With the exception of security
    fixes, any patch, upgrade, or hotfix is entirely
    optional. You can stop patching and upgrading at
    any time, and strike out in your own direction with
    the lib. And as a matter of fact, I'd be tickled
    pink if you did. The sprouting of evolutionary branches
    off Dead Souls would delight me, because it would be
    good evidence that I have begun something that's
    going to continue beyond what I've done with my own
    little brain.

    Summary

    For what it's worth, the vast majority of patch
    tarball upgraders that follow the patch install instructions
    report nothing but a smooth process.

    Dead Souls Homepage