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