Better Random Subject Lines
Earlier I talked about generating random Subject lines for emails. I settled on something that looked like Subject: Your email (1024) . Those were fine, but got dull quickly. By switching the procmail rules to look like:
:0 fhw * ^Subject:[\ ]*$ |formail -i "Subject: RANDOM: $(fortune -n 65 -s | perl -pe 's/\s+/ /g')" :0 fhw * !^Subject: |formail -i "Subject: RANDOM: $(fortune -n 65 -s | perl -pe 's/\s+/ /g')"
I'm now able to get random subject lines with a little more meat to them. They come out looking like: RANDOM: The coast was clear. -- Lope de Vega
However, given that the default fortune data files only provide 3371 sayings that are 65 characters or under the Birthday_paradox will cause a subject collision a lot sooner than with the 2:superscript:15 possible subject lines I had before.
Update: It's been a few weeks since I've had this in place and my principle subject-less correspondent has noticed how eerily often the random subject lines match the topic of the email.
Jetty with Large File Support
Jetty is a great Java servlet container and web server. It's fully embeddable and at OnionNetworks we've used it in many of our products. It, however, has the same 2GiB file size limit that a lot of software does. This limit comes from using a 32 bit wide value to store file size yeilding a 4GiB (unsigned) or 2GiB (signed) maximum, and represents a real design gaff on the part of the developers.
Here at OnionNetworks we needed that limit eliminated so last year I twiddled the fields and modified the accessors wherever necessary. After initially offering a fix and eventually posting the fix it looks like Greg is getting ready to include it thanks in part to external pressure. Now if only Sun would fix the root of the problem.
Adding a Subject with Procmail
Lately I've been corresponding a great deal with someone who doesn't elect to use the Subject: line in emails. When responding to this emails my mail application, mutt, uses the Subject line: re: your mail. Mutt also groups conversations into threads using (among other things) the Subject line. So every reply to every person who has sent a message with a blank subject line gets grouped into a single thread when they, in fact, have nothing to do with one another.
I decided to create Subject lines for incoming messages without them on the fly using the standard procmail tool. This pair of recipes does the trick:
:0 fhw * ^Subject:[\ ]*$ |formail -i "Subject: Your email ($$)" :0 fhw * !^Subject: |formail -i "Subject: Your email ($$)"
The $$ gets turned into a low number (the process id actually) which is unique enough to keep threads separate. The resulting Subject lines look like: Subject: Your email (1024) } and have been working quite well.
There's probably a way to use a single recipe to catch both cases (blank Subject and no Subject), but I hate procmail's almost egrep and just settled on this.
Comments
Test comment.
The girl who refuses to use subject lines is leaving a comment. -- Kate Bauer
I updated this idea in a later entry. -- Ry4an
2004 Email Response Patterns
Back in 2003 I started tracking some numbers on my email use patterns, especially related to replies. I ran those old scripts on my 2004 mail and the numbers look pretty similar:
- Of the 3236 emails I sent during 2004, 2094 of them were replies
- My five most common response times in minutes were:
- ten minutes: 40 times
- thireen minutes: 36 times
- sixteen minutes: 36 times
- twelve minutes: 35 times
- eleven minutes: 33 times
- My mean response times was 22.36 minutes
- My longest response time was 58.4 days.
The only really meaningful number there is the median response time and comparing it to 2003, I'm a lot faster in general.
My email volume by year is:
| Year | Emails Sent |
|---|---|
| 2000 | 1920 |
| 2001 | 1799 |
| 2002 | 1920 |
| 2003 | 3136 |
| 2004 | 3236 |
Looking at that table it's pretty easy to tell when I started working from home again.
Here's the histogram for 2004:
New UnBlog System
I've switched from a mailing list driven system to a wiki based one for this UnBlog. It's less weird than the mailing list setup was, but it's not exactly moveable type either. It offers RSS feeds and subscriptions, though through entirely different mechanisms than the list did. I think I've moved everything over well enough that there are no dead links into the old space. I ended up using my WikiChump thing modified to handle attachments and create comment pages to populate the data.
Brute Forcing My Own Password
I try to maintain good password practices -- total random gibberish, never use the same password for two things, change them monthly --, and the EBP lite from http://mandylionlabs.com/ certainly helps.
Last night, at about 3am I was doing my monthly password change and somehow I typed one password wrong in exactly the same way three times. Today when I tried to add my ssh private key it just wouldn't unlock. I tried the "right" password 10 or so times and no luck. I then started trying slight variants on the password: fingers shifted, missed shift key, similar looking characters, etc. After 30 or so of those tries with no luck it was time to script.
Ten minutes later I had a list of 27,648 (4 * 3 * 4 * 3 * 3 * 4 * 4 * 4) possibilities and ten seconds later permutation number 2308 proved correct. Whew. One would think this would teach me to be more careful, but really it's shown me that so long as one has strong script-fu close-enough is good-enough.
Oldenburg Survey Results Released
I went ahead and aggregated the survey results related to this previous entry about starting a social club:
http://ry4an.org/unblog/msg00076.html
The results can be found at:
http://ry4an.org/oldenburg/survey/
Sadly, I've been forced to conclude that there's just no way to start something like I'd hoped for without a good year's worth of operating expenses in the bank. You need members to gather dues, need dues to open the club, and need the club to gather members.
I still believe the basic idea is tenable, and that operating finances wouldn't be out of line with expected revenues, but barring a grant of some sort I just don't see a way to do it.
Time For Another Key Signing
It's time once again for that marriage of mathematics and paranoia that is a cryptographic key signing. I'm organizing another for Thursday, January 20th, 2005. Details can be found at: http://ry4an.org/keysigning/ Results from my last key signing can be found at: http://ry4an.org/keysigning/visualize/
If all that's gibberish to you, check you my much better explanation last time I did one of these: http://ry4an.org/unblog/msg00026.html
Thanks once again to the ACM for letting us use their room.
Comments
glad to see a new posting. i was getting concerned your new non-geek pursuits were interfering with your true purpose. -- Kate Bauer
Dead Pool Update
I've got the entries and current scores posted for the Dead Pool at http://sarinity.com/deadpool/ . Thanks to those who entered. I was planning on hitting everyone up to join at the Halloween party, but then I got distracted and forgot. O'well six people, two of whom already have points, is good enough.
Best of luck to the entrants,
The Hierarchy of Pretzel Sins
I eat pretzels like Darwin would have. It's a constant survival of the fittest competition. I select two pretzels, eat whichever is most flawed, select another, re-test, and just keep going from there. At the end I've got the best pretzel of the whole bag left, which I then eat.
Admittedly it's not an actual test of the pretzels' fitness to survive -- the pretzels with inferior qualities aren't dying off due to failure to feed themselves and attract mates. Really it's just their ability to conform to my invented notion of the master pretzel, but if you go around saying you eat pretzels like Hitler people back away slowly.
Here then is my criteria for the most fit pretzel presented by defining what makes a pretzel bad. Earlier sins are more severe than the later sins, and the pretzel with the most severe sin gets eaten first.
THE HIERARCHY OF PRETZEL SINS
- broken - pretzels must be closed figures with no open ends
- bad connectivity graph - pretzels must have 3 distinct, conjoined regions
- asymmetric - pretzels must exhibit symmetry about the vertical access
- inconsistent thickness - pretzel lines should be uniform in width
- overly tall/wide - pretzels should be roughly the same in width and height
- flawed skin - pretzels must exhibit unbroken golden-brown skin
- bad salting - salt should be neither too heavy, to light, nor uneven
There, now it's published. If no one refutes it in the next 24 hours I'll assume the world accepts the inverse of that list as the definition of a perfect pretzel.
Comments
Well, that sounds like a challenge!
I disagree with your overly tall/wide, in my mind the perfect pretzel should be wider than it is tall, though not too wide!
-- Louis Duhon
Tags
- funny
- java
- people
- python
- mongodb
- scala
- perl
- meta
- mercurial
- home
- security
- ideas-built
- ideas-unbuilt
- software
Contact
Google+Content License
This work is licensed under a
Creative Commons Attribution-NonCommercial 3.0 Generic License.