<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>Patches?!?</title> <link rel="icon" href="./favicon.ico" type="image/x-icon"> <link rel="shortcut icon" href="./favicon.ico" type="image/x-icon"> </head> <body> <pre style="font-family: courier new,courier,monospace;"><big><big><big style="font-weight: bold;">Patches?!?<br></big></big></big><font size="+1"><span class="sb_messagebody">(We doan need no steenkin PATCHES!!!)<br><br>Updated 09 March 2007<br><br><br><span style="font-weight: bold; text-decoration: underline;">The Principle</span><br><br>My goal is to make Dead Souls the best, most kick-ass<br>LPC lib ever. I interpret this to mean that when I<br>see a flaw, or someone else points one out, I want<br>it fixed. And, well, the fixing falls to me.<br><br>Releasing updates lets people share in the cool new stuff,<br>and it also helps me fix new problems.<br><br>Previously, I felt that "my way" of releasing stuff<br>was good enough. However, since making it convenient<br>for people to upgrade makes it convenient for me to<br>develop, I've changed my policy and worked on simple<br>and convenient upgrading processes.<br><br><br><span style="font-weight: bold; text-decoration: underline;">The History</span><br><br><br><span style="text-decoration: underline;">1) Tarballs</span><br><br>After a while of fixes accumulating, I declared it to be a <br>new release and off it went, into the world. At first this <br>caused a lot of grumbling, because it meant people had to<br>reinstall from scratch every time I made a release,<br>and this was a bit much for many people.<br><br>It occurred to me that I could compile a package that<br>had only the files that changed between releases. I<br>put this together, and people seemed to really like<br>being able to upgrade from one release to another,<br>without a full reinstall. Over time, this system<br>has been tweaked and refined somewhat, but in the<br>end, it's roughly the same type of thing it was back<br>when I produced the first one: a bunch of files.<br><br>However, it's kind of a pain for me. Also, since<br>people feel it's inconvenient to download the patch<br>and uncompress it (?!?) they rarely upgrade, so it<br>defeats the purpose. <br><br><br><span style="text-decoration: underline;">2) OOB Liveupgrade</span><br><br>So I decided to set up an "in-mud" upgrade system.<br>Rather than go on the web, download stuff, and install<br>it, people would issue commands in the mud to update.<br><br>The protocol I chose was I3 OOB, because I wanted to<br>polish up on it, and because it seemed like it<br>would be easy to maintain. Sure enough, it worked<br>great and was easy to maintain. People would issue<br>the "liveupgrade" command with the correct parameters,<br>and they would pull updated files from a mud that<br>worked as a liveupgrade server. Beauty!<br><br>Problem was, it was dead slow. I mean, really slow.<br>It was a line by line transfer with sanity checks<br>throughout. On a fast system with large bandwidth,<br>it could take 15 mminutes or more to upgrade to a<br>new alpha release. On a slow machine sitting on a<br>skinny pipe, it could take more than an hour. <br><br>And on flaky connections, sometimes (rarely, but<br>occasionally) the upgrade would stall.<br><br>Since people don't really have the patience for that<br>(and really, I know I don't have it), I figured a<br>new way would make sense. Plus, with the development<br>of IRN, using OOB for sensitive stuff like this<br>stopped making sense, from a security standpoint.<br><br><br><span style="text-decoration: underline;">3) HTTP Liveupgrade</span><br><br>So starting in 2.3a14, Dead Souls liveupgrades happen<br>over http connection to dead-souls.net. It is <br>insanely fast, with a complete upgrade taking around<br>a minute on a fast machine. <br><br>The drawback is that there are still kinks. It is <br>possible to do a liveupgrade that pulls 404 files,<br>if your connection is unstable. And, of course, this<br>means you'd have to restore from backup.<br><br><br><span style="text-decoration: underline;">4) Back where we started</span><br><br>If a liveupgrade error hoses things up, there's no<br>need to panic. Just download the appropriate patch<br>file from <a href="http://dead-souls.net/code/patches">http://dead-souls.net/code/patches</a> and<br>install the old way. That will fix everything.<br><br><br><br><span style="font-weight: bold; text-decoration: underline;">The Mechanics</span><br>The patching process is just as primitive as it<br>sounds. You uncompress these files and copy them<br>over your existing mud. Simple. Efficient.<br><br>Player files, directories, and domains that are<br>created by you are left untouched.<br><br>For some people this system is problematic. Some folks<br>are proficient at modifying lib code, and if they<br>just overwrite their mud with the contents of a patch,<br>they might find that their lib work has been clobbered. This<br>would be bad. That is why my patch instructions<br>strenuously remind people to back up the current mud<br>before patching it.<br><br>There is no practical solution for this problem that<br>I can see. Because I am just one guy, and my goal<br>is lib code, and not patch-process-design, I have<br>decided to leave things as they are. In theory I could<br>write code that would analyze and modify files as<br>needed, rather than simply have the owner overwrite.<br>However, this is a lot more complicated than it sounds<br>to implement in LPC within the lib, and it is also<br>non-trivial to implement this at the OS level, given<br>that the process would have to work on multiple different<br>platforms.<br><br>It's my opinion that people sophisticated enough to<br>need a more specialized patching system are<br>sophisticated enough to work around my shortcomings<br>in this area. Indeed, I've heard of folks who just<br>download the complete new version, run diffs against the<br>old one, and then pick and choose what to add.<br><br>For now and the foreseeable future, patches are just<br>a Big Dumb Ball of Files...with one exception.<br><br>Each patch includes a file called /secure/daemon/update.c<br>which carries out special functions that are not dealt<br>with by just overwriting files. When you reboot the mud,<br>update.c will do things like remove broken/dangerous files,<br>rename files with incorrect names, and modify text in<br>files (such as config.h) which should not be overwritten<br>but need to be changed.<br><br><br><span style="font-weight: bold; text-decoration: underline;">The Philosophy and Controversy</span><br>Believe it or not, I've had people become irrationally<br>angry at how often I make releases. Not just "That darn<br>Crat is driving me crazy", but actual, unhinged flaming<br>well beyond any reasonable context.<br><br>Don't believe me? Check it out for yourself:<br><br><a href="http://www.justrage.com/article.php?story=cratylus_dead_souls_mudlib">http://www.justrage.com/article.php?story=cratylus_dead_souls_mudlib</a><br><br><br>It *is* true that I'm averaging a release every week<br>or two. The person is correct in that there are a lot<br>of bugs to fix, and that releases happen much, much<br>more often than they do for other muds.<br><br>I have no defense against this charge. All I can do<br>is explain the reason for it, and hope it is justification<br>enough.<br><br>When someone tells me Dead Souls has a bug, I want to<br>help them. I want to fix it. I feel responsible to the<br>mud community to do what I can to fix whatever problems<br>they've run into because they've adopted the lib I<br>wanted them to. This is probably irrational on my part,<br>and if I'm lucky, I'll stop feeling this way sometime<br>soon. But until I do, I feel driven to be a responsive<br>lib coder, and I fix stuff. And I release it.<br><br>The question is, "If Dead Souls is so lame it needs<br>constant patching, shouldn't you kill it?"<br><br>The thing is, Dead Souls is the best LPmud lib out<br>there that I know of, *right now*. If the standard is<br>going to be perfection, then there's no lib out there<br>that should be available. There's no LPC mudlib<br>out there that you can download that is as featured,<br>solid, widely adopted, and supported as Dead Souls. If<br>the criteria for killing a lib is that it's not<br>perfect, and if Dead Souls is among the libs to be killed,<br>then just about everything needs a good flush.<br><br>It should be noted that Dead Souls doesn't *need*<br>constant patching. With the exception of security<br>fixes, any patch, upgrade, or hotfix is entirely<br>optional. You can stop patching and upgrading at<br>any time, and strike out in your own direction with<br>the lib. And as a matter of fact, I'd be tickled<br>pink if you did. The sprouting of evolutionary branches<br>off Dead Souls would delight me, because it would be<br>good evidence that I have begun something that's<br>going to continue beyond what I've done with my own<br>little brain.<br><br><br><span style="font-weight: bold; text-decoration: underline;">Summary</span><br><br>For what it's worth, the vast majority of patch<br>tarball upgraders that follow the patch install instructions <br>report nothing but a smooth process.<br><br></span> </font><big> <br><a href="../index.html">Dead Souls Homepage</a><br><br></big></pre> </body> </html>
