Decisions.

A truly nasty rooter could still thwart that by faking things in either the C runtime library or the appropriate system calls.

I will have to drop dcc. Their licensing is no longer free enough to be distributed by Debian. That will slow more messages, but in practice anything dcc catches is also caught by spamassassin.

I'd like to add an adaptive whitelist out front to prevent false positives and give me a stream of known good messages for training the bogofilter. I haven't found one I like yet, but I keep looking. Maybe I'll have to write it.

Bogofilter is built with a single user in mind. I'm sure it works better when it has a single user's mail to think about and can rely on the human to tag the false positives and negatives.

In a 150 user common filter you can rely on exactly 0 of them to report their miscategorized spam. If you try to force them to comply you will find that 10% of them do it backwards and pollute your statistics so badly you have to erase everything and start again.

That said, it works quite well and is speedy and doesn't rely on external network servers so it makes a good first line of defense.

• fandango
• tatuazh

• SEX
• SEX
• SEX SEX SEX LOVE
• zubav1na-ps1h1chesk1e-bolezn1  except the digits 1 are supposed to be the letter 'i', I just didn't want to get indexed by it.

... but only if you are using GNU libc. I got burned when I used this in a daemon and then moved it to OpenWRT where they uses a different libc.

Many webcams are cheap webcams. Unfortunately some of them cost a lot of money. Logitech I have found to be a crap shoot. Some of their camera models are nice devices, others are utter crap sensors. The problem is you can't tell which is which without buying one. After getting burned with a 'pro' model that was built on a terrible imaging element I now buy web cams that are crap, know they are crap, and are priced like they are crap.

My current favorite is the Aiptek Mini PenCam 1.3, which is a 1.3Mpixel camera, maybe if you count the red, green, and blue elements separately and round up… a couple of times. 640x480 pixels, JPEG encoded, 10 frames per second using the gspca drivers in linux. Their autobrightness logic is insane and will drift off to unintelligible pictures over time, but thats ok, I do my own autobrightness. The gspca driver is wrong about how to set and retrieve the brightness, contrast, and saturation parameters, but I fix that. The nice part is that the cameras are $9.99, with a stand, cable, and a handy leatherette carrying pouch that you can throw in the trashcan.

I don't mind a crappy camera that is honest about it.

Worse, if thread A is in an fgets() on file F when it is phtread_canceled, then when thread B tries to fclose(F) it hangs. I suppose there is a lock inside the FILE *. I punted stdio and just did my input at the socket level. I was already doing output at the socket level to avoid a copy operation.

Now to add some comments, forget all about this code, and move on with the actual problem.

I thought going in that getting HTTP/1.1 pipelining right was going to be the trickiest part, but on further investigation none of the major browsers use it. Apparently enough web servers screw it up to prevent it.

In the absence of pipelining I decided to forgo keep-alive entirely in favor of simplicity. By careful use of TCP options I only need 3 outgoing packets for each request (up to 1.mumble kbytes). The SYN-ACK, an ACK-Data-FIN, and a FIN-ACK.

An interesting performance issue: Safari shotguns me with many simultaneous connections, to which my httpd responds quickly. If I were supporting keep-alive I think Safari would be encouraged to only use two connections and serialize the requests over them. I wonder which is faster? I may have to add keep-alive support just to answer this question.

Another interesting tidbit: Some people on the web maintain that TCP_QUICKACK and TCP_DEFER_ACCEPT are inherited from the listener socket to the accepted socket. I don't think so. At least the only way I can get QUICKACK turned off is to not use TCP_DEFER_ACCEPT on the listening socket  and slam TCP_QUICKACK off on the accepted socket before the first data arrives. Otherwise I end up sending an ACK before my first data packet.

And a last tidbit: You can keep your TCP_CORK in all the to shutdown(), that gets your FIN piggybacked on your last data packet.

The application where I was going to use libmicrohttpd requires me to crosscompile and after hours of thrashing about I still can't get it to build.

Back to the bit heap with it. I'll write my own httpd code.