For all that we roll our eyes when people have only online backups or redundancy andsuffer data loss as a result of it, I don't think it's necessarilyas easy to do things the 'right' way as we make it sound, or evenfeasible at all in some situations.

Suppose that you are a modern, efficient Internet-based business, andso you are running your servers the smart way; instead of buildingyour own machine room in a corner of your office space and bringing in

By now, everyone knows that redundancy, for example RAIDed disks, isnot the same thing as backups (or at least I hope they do). But I thinkit's worthwhile to talk about why, and thus the fundamental differencebetween the two.

(Note that there are a lot of ways of getting redundancy, far beyondmere RAID. If you are a large operation like Google or a bank, you'reinterested in redundancy across systems and even data centers.)

The two are quite similar

Suppose that you are creating a service today. What can you reasonably andsensibly use email for, given modern email principles ?

My answer is that the only real use of email today is as a notificationsystem: you send your users email to tell them that there is somethingwaiting for them on your site (whether that is a message, a statechange, or whatever). This is a bit extreme, but I think it's thenecessary end result of the limits .

Since modern email is not reliable

We have a ssh keypair that's used to let an automated script have verylimited access to a remote system. As usual, we set up a whole hostof restrictions in the target account's authorized_keys ; we forcea specific command, we only accept the key from the host we expect itfrom, and we specify the whole raft of no-* options, including no-pty .The command that gets forced for this particular keypair reads variousthings that it needs from standard input (ie

Python generally has a great interface to Unix; through various modules(not just os , but also things like socket , select , and so on) itexposes almost all of the generally useful APIs and does so in a waythat is simultaneously Unixy and Pythonic. The best way of putting itis that everything just works, and just works the way you'd expect itto if you know the C-level API and Python.

(This is one reason that I have never been terribly energized aboutthe ctypes

CPython handles Unix signals somewhat oddly, or at least not in what youmight think of as a standard Unix way. I've covered part of this beforein SignalProblem and made side mentions in other entries, but I want towrite all of this down in one place (even if only as an index).

First, none of this applies if you set a signal's handler to SIG_IGN or SIG_DFL . Those get standard Unix semantics, because CPython justsets the signal to either of

In brief, the Python SIGCHLD problem is that while C-level SIGCHLD signal handlers are protected against reentrancy, your Python level SIGCHLD handler function is not, because it is not actually executedas a C-level signal handler. This winds up causing heartburn andpotential explosions if you do anything sophisticated when childprocesses exit. (See SIGCHLDVsPython for a longer discussion.)

In thinking about the problem, I've realized that signal.signal() is itself a peculiar but useful atomic operation. This is important,

Web servers and many web applications are quite insistent that URLs thatrepresent 'directories' have to end in a slash; if you request the URLwithout the trailing slash, they just give you a redirection to the sameURL with a slash on the end instead of the actual content. One mightwell wonder why they have this neurotic insistence, especially when it complicates URL rewriting for applications thatcan do whatever they want with incoming URLs anyways.

(The other side of this question is whether web applications have tocare about

Since I keep rediscovering this every so often, here's what I know aboutrewrite rules in .htaccess files so that I can just read it here thenext time around.

Some basics:

• you need a ' RewriteEngine on ' statement, even if the rewrite engineis already on in the main configuration.

• the 'URLs' that you match against in RewriteRule are relative tothe directory the .htaccess is in. However, Apache variables like %{REQUEST_FILENAME} that you use in RewriteCond are the full