Today I was unpleasantly surprised to discover that Postfix defaults tohaving a 50 megabyte size limit on user mailboxes, after which emailbounces. This default limit is apparently sufficiently unimportant tonot be mentioned in the 'basic' or 'standard' general configurationdocumentation.

Perhaps this will strike people as a petty reason for disliking Postfix;after all, it's just one configuration option. But it is the symptom ofa deeper problem.

Since Postfix people have made one dangerous random arbitrary default(and not drawn attention

In the process of looking at my program's code again to write the lastentry , I think I may have solved the mystery ofhow my impossible exception gets generated.

My program does a lot of forking and thus cleanups of now-dead children.The code that it generally dies on is:

def _delip(pid, ip):  del ipmap[ip][pid]  if len(ipmap[ip]) == 0:    del ipmap[ip]

It takes a KeyError on the len

For a conceptually simple program, dd has a number of dark corners.One of them (at least for me) is how it deals with input and outputblock sizes, and how the various blocking arguments change thingsaround.

• ibs= sets the input block size, the size of the read() s that dd will make. Since you can get partial reads in varioussituations, this is really the maximum size that dd will everread at once.
• obs= sets the output block size and makes dd '

I have a heavily threaded Python program that dies every now and thenwith a mysterious exception (that as far as I can see just shouldn'thappen, which means that I don't completely understand my code).

My off and on attempts to debug this have pointed out a frustratingproblem in Python's (lack of) support for debugging threaded Pythonprograms: there's no such thing as a global exception, something thatwill freeze, backtrace, and terminate all threads when an erroroccurs.