One of the things that my sinkhole SMTP server does that's new on my workstationis that it supports TLS, unlike my old real mail server there (whichdates from a very, very long time ago). This has given me the chanceto see how much of my incoming spam is delivered with TLS, which in turnhas sparked some thoughts about the spread of SMTP TLS.

The starting point is that a surprising amount of my incoming spamis actually delivered with TLS; right now about 30%

PGP and similar technologies have been in the news lately, and asa result of this I added the Enigmail extension to my testingThunderbird instance. Dealing with PGP through Enigmail remindedme of why I'm not fond of PGP. I'm aware that people have allsorts of good reasons and that PGP itself has decent reasons for working the way it does,but for me the real strain point is not the interface but fundamentallyhow PGP wants me to work. Today I want to talk just about signed email

When I've written before about my extensions,I've said that I didn't bother with any sort of Flash blockingbecause NoScript handledthat for me. The reality turns out to be that I was sort of livinga charmed life, one that has recently stopped working the way Iwant it and forced me into a series of attempts at workarounds.

How I want Flash and video to work is that no Flash or video contentactivates automatically (autoplay is evil, among other things) butthat I

Yesterday I wrote about how our performance problem with amandad were caused by amandad doing IOmultiplexing wrong by only polling forwhether it could read from its input file descriptors and assumingit could always write to its network sockets. But let's ask a question:suppose that amandad was also polling for writability on those networksockets. Would it work fine?

The answer is no, not without even more code changes, because amandad 's network sockets aren't set to be non-blocking . Theproblem here is

Every so often I have a belated slow-motion realization about what'sprobably wrong with an otherwise mysterious problem. Sometimes thisis even sparked by remembering an apparently unrelated thing I readin passing. As it happens, that happened the other day.

Let's rewind to this entry , whereI wrote about what I'd discovered while looking into our slowAmanda backups . Specificallythis was a dump of amandad handling multiple streams of backupsat once, which we determined is the source of our slowness . In

A while back I wrote about the challenges in diagnosing slow(Amanda) backups . It's time for a followupentry on that, because we found what I can call 'the problem' andalong with it a workaround. To start with, I need to talk abouthow we had configured our Amanda clients.

In order to back up our fileservers in a sensible amount of time, we run multiple backups on each themat once. We don't really try to do anything sophisticated to balancethe load

Sure, init has historically done some sortof daemon supervision (or at least starting and stopping them) andI listed it as one of init's jobs . But doesit actually need to do this? This is really two questions and thustwo answers.

Init itself, PID 1, clearly does not have to be the process thatdoes daemon supervision. We have a clear proof of this in Solaris,where SMF moves daemon supervision to a separate set of processes. SMF is not a good init system but

I've talked before about what init does historically , but that's not the same thing as what aninit system actually needs to do, considered abstractly and divorcedfrom the historical paths that got us here and still influence howwe think about init systems. So, what does a modern init system ina modern Unix need to do?

At the abstract level, I think a modern init system has three jobs:

1. Being the central process on the system. This is both the modestjob of being PID 1

Here is a kernel message that one of my machines logged recently:

sit: Src spoofed 98.247.192.43/2002:4d4d:4d07::4d4d:4d07 -> 128.100.3.51/2002:8064:333::1

Did I say 'a message'? Actually, no, I