The fundamental Unix development that enabled modern shared librariesis shared copy-on-write mmap() . That's not necessarily obvious, solet me walk through the logic of this.

There are two problems with shared libraries, with the second stemmingfrom the first. The first problem is how to get them loaded into theprocess's address space at all, and it has many possible solutions. Theeasiest solution is actually to have the kernel do it, since after allthe kernel is already mapping code

We recently had an overnight, building-wide power shutdown in thebuilding with our machine room . As youcan imagine, a total machine room shutdown (and later restart) is aninteresting time. We made checklists for both the shutdown and therestart, and for the most part things went fine (although they tooklonger than expected). But still, there are a few things that I will dodifferently the next time that this happens:

• make a list of all of our machines and then go through the

This is programming war story.

Once, a long time ago, I worked on an Amiga program . The program had a bug. Well, it had many bugs, butit had one particularly frustrating one where the program had erraticcrashes that we couldn't reproduce or track down. One day we werestarting to give an internal demonstration of the program and bang, itcrashed. We tried again, and it crashed again. I immediately said 'don'ttouch anything ' and we sat down with this

One of things that commentators brought up in response to my entry onwhy we don't use a trouble ticketing system is thattrouble tickets have multiple uses; for example, they can be used laterto look up what you did to solve a problem, and the user can use them tosee how their issue is progressing. I expect that this is a common thingto say as a virtue of a ticketing system. However, I don't think thatthis is as easy as it sounds.

First,

Not quite a year ago, I wrote about our use of virtualization here in OurVirtualizationUse . That entry is now what we call 'inoperable',because we have just finished de-virtualizing; reverting back fromvirtual machines to running those machines directly on real hardware.We did this ultimately because we think that it's less of a hassle torun machines on real hardware than virtualized.

In retrospect, I think that part of the problem is that our virtualhost machine was underconfigured in terms of RAM and disk space

A while back I wrote about how I had realized that a lot of mysyndication feeds were only for casual reading andhow I thus wanted to reduce their impact on my time. I suspect that I'mnot alone in this pattern of having periods of initial enchantment withservices and then winding up less interested in them, which leads me toa corollary for designers of services.

There are a lot of services where it's easy to move from just startingout to really immersing yourself in the service; sometimes

As I wrote yesterday , one of the reasons that I don'tthink we need a trouble ticketing system here is that we are not allthat busy with requests; in fact, the average number of open requests isgenerally zero. I think that this is a good thing, and that frequentlyhaving more open requests than sysadmins or even having all of yoursysadmins busy dealing with requests is an important danger sign.

It's a danger sign because it means that your sysadmins are too busy todo long-

I've recently come to a (belated) realization about WSGI.

Looked at from the right perspective, WSGI is a simple protocol hidinginside a complex one (or you could say that it's designed to make simplethings relatively simple and complex things possible). Almost all WSGIapplications are written to the simple protocol and I think that manyserver implementations effectively are as well, especially ones writtenin specialized circumstances for private use.

This is great for application writers; most application writers onlyneed to do simple

In an aside in this entry I mentioned that wedon't use a trouble ticketing system here, and a commentator asked theobvious question of why not. The short answer is that we don't thinkmoving from our current approach to a trouble ticketing system would beuseful enough to justify the amount of extra work and annoyance it wouldtake.

For the long answer, I am going to make up a hierarchy of approachesto tracking your work, especially the work that people ask you to do:

• level 0