Author: Andrew Montalenti

I was just looking at my strange contact page, where I list my e-mail address using a sort of obfuscated string with _ and * characters mixed in. And then I saw someone’s e-mail address listed on the web with the following format:

user () domain ! com.

At that point, I started to think about all the other variations of this spam-protection trend I’ve seen, like user ///at\\\ domain ///dot\\\ com, and I realized that many of us are taking the wrong approach. Myself included. For example, the one above could easily be found by knowing the common TLDs and working backwards from there. If I find a “com”, “org” or “net,” and then look at the string tokens which occur before, I can assume any string of valid characters (say, alphanumeric characters) which is followed by whitespace or invalid chars (like parentheses and exclamation points) can be taken as a valid part of the address. From there, we can easily split user () domain ! com into its proper parts, and construct the e-mail. This same approach works for say, user ///at\\\ domain ///dot\\\ com.

So what I realized is perhaps it would be better to insert other e-mail addresses in there that might get picked up as part of an e-mail address, even in a heuristic scan. For example,

user __at__ domain :: NOT [email protected] :: __dot__ com

That seems more secure to me 😉 Another approach is just to prevent the TLD from being a complete token. This is the approach I took. Turn com into c_o__m or something, and you’re less likely to get picked up in a scan that is searching for “com”.

This /. article has responses from Microsoft Linux Lab manager Bill Hilf. I responded to this post from a Microsoft employee. My response follows. Continue reading Microsoft’s anti-competitive behavior

I wrote a pretty sweet script tonight. It parallelizes the getmail retrieval process, while still printing prefixes so I know which accounts download which messages. This means that instead of my mail fetching process taking sum(i₁,…,i_n), where i is the length of time for a given mail retrieval, my fetching process now takes max(i₁,…,i_n).

#!/bin/sh
GETMAIL='python2.3 -Wignore /usr/bin/getmail'
unwanted() {
  grep -E -v '(Copyright|getmail|Simple)';
}

echo "N-WAY GETMAIL RETRIEVER SCRIPT:"
$GETMAIL \
  --rcfile=/etc/getmail/account1 \
  2>&1 | sed -e \
  's/.*/account1................: &/g' \
  | unwanted &

$GETMAIL \
  --rcfile=/etc/getmail/account2 \
  2>&1 | sed -e \
  's/.*/account2................: &/g' \
  | unwanted &

...

$GETMAIL \
  --rcfile=/etc/getmail/accountN \
  2>&1 | sed -e \
  's/.*/accountN................: &/g' \
  | unwanted &

wait

This is why I love Wikipedia.

PIDA 0.2.2 was released recently. This is truly a novel development in the Python/OSS world. What PIDA provides is a nice plugin system and the “makings” of an IDE. So, in a nice IDE you have a class browser, an integrated debugger, a profiler, maybe even a RAD-like GUI builder, an interpreter console, etc. The one piece that tends to be most controversial in every IDE is the text editor. This is one-part because UNIX people are really crazy about their text editors, but two-parts because text editors are very important programmer tools, and no one wants to learn a different text editor for every language one uses.

vim happens to be awesome for C programming, which is probably why a lot of UNIX hackers use it. But for Python, more advanced support would be nice. PIDA can run and connect to a vim server instance in order to allow you to have an “add-on IDE” for vim.

But even more interesting to me is the culebra plugin, which provides a code-completion-savvy GtkSourceView inheritor, which has the initial support for fancy Intellisense-like features.

I’ve already spoken to the developers of PIDA, and they said they would very much be interested in seeing Python Intellisense features brought to VIM. When I started thinking about different approaches to doing this, I realized that the whole OSS community could benefit from a general Python module that enhances the Python introspection features (and perhaps combines them with source code parsing) to make available nice productivity-enhancing features. I was thinking of calling this beast “Pyductivity.”

More on that later. For now, check out PIDA.

This is exciting news. A Trolltech developer has modified KAA, the acceleration architecture used in Keith Packard’s experimental “kdrive” Xserver, to work with the traditional Xorg tree. He announced this new development in an e-mail that makes it clear it is extremely easy to get drivers to use Exa to gain Apple/Windows-like graphics performance.

I know that the unichrome project generally doesn’t bother itself with these very desktop-oriented features (their focuses are more on MediaPCs, etc.), but I think this may be an excellent way for me to begin hacking the new modular Xorg tree I mentioned last time. If I added Exa support to the unichrome driver, would that mean transparency and full-on graphics acceleration for my X desktop, what I’ve long been waiting for? We’ll see.

It seems that Xorg, as of the 7.0 release, has been split into monolithic and modular development trees. The modular model allows you to compile individual components related to Xorg separately from the whole X server, so that you don’t need to do a two-hour compilation just to work on this or that driver or this or that library.

This is good news for me. My biggest craving lately was to put my C skills to use by diving into a big project that has effects on the Linux desktop, and Xorg is certainly the biggest in that sense. However, in the past I was always put off by the huge amount of groking one needs to do just to understand the Xorg compilation process. After class is over, I’m gonna start diving in.