If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'. To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.
And, last but not least:
10. Take all of the above too seriously. No, really. It's only a joke.

Clint, Please get some way to contact you up on your site. Having to reply through Planet isn't ideal. Anyway. I'm not familiar with employment law across all of Europe, but the claim that you have to employ them for a certain period after you actually fired them, or even that you can't fire someone without due process, is simply false—at least in Belgium, though I expect the same is true for most other member states of the European union. First, there's the fact that every employment contract starts off with a "test period" which can take up to six months, depending on the type of employment (it is longer for hotshot management than it is for hand labour) and the length of the contract, if appropriate. During this period, an employer can fire someone without further explanation and without any process. This is to make sure that you can get rid of people who managed to sell skills on themselves they don't end up having. Second, an employer can fire anyone right away for what is called 'urgent reasons'—things like employees stealing from the employer; basically anything that makes the employer lose trust in the employee (though this is strictly regulated, for obvious reasons). Third, if you fire someone not during their testing period and not for urgent reasons, you do not have to keep them at your place; it is legal to tell someone that as of tomorrow, they no longer have to come to work -- you just have to give them a pay check for those three months (or whatever) you would have to employ them otherwise. Finally, the thing also works in the other direction; if some important employee (say, the only guy with the root password) decides to quit, an employer can require that they stay at work for up to (IIRC) two weeks, so as to ensure continuity. But I understand you knew that part already...

Just killed all the remaining comment spams (I hope) and implemented a simple regexp based blacklist which should get most medicaments, potence pills, casinos, lotteries and other frequently posted junk. I hope, it does not hit too many valid posts. If you have problems posting comments, feel free to contact me by e-mail or on IRC. In other news, I installed the blosxom plugin comments_recent and adapted the mail feature of writeback notify to my (in the meanwhile heavily modified) instance of the comments plugin v0.6. I also made it symlink-safe for use with multcat.

Since the demand for blosxom anti-comment-spam solutions respective appropriate blosxom plugins seems to be really high, I’ve decided to polish up my apparently quite well working although still in beta state being anti-spam enhanced version of the comments plugin (ZIP) by putting the blacklist outside in an external file and writing some (still short) docs. I use it since 11th of January this year and got only two spam comments and many more normal comments since then, so it should work. Although: I also got a question if my trackback doesn’t work. Hmmm. So no warranties, just an offer for help fighting against comment spam. ;-) Another feature which is basically ported from the writeback notify plugin is notification of the blog owner about new comments by mail. Since on the server on which my blog runs the used Perl module Mail::Sendmail was not available, I used Mail::Send instead for my version. For installation you first need to download the ZIP file of the original comments plugin, install it’s templates and then install my anti-spam enhanced version of the plugin itself.

Now playing: Rockapella — Come on Eileen

Mike Hearn's 'Linux Problems' page has some interesting assertions on how to 'fix' Linux and make it 'enterprise-supportable' (which seem to boil down to: distributions suck, so avoid them; Python sucks, so avoid it; C++ sucks, so avoid that too; glibc, gcc and headers suck, so they need fixing; shared libraries, too, are hard for us, so we'd like other people to avoid dealing with them because autopackage is king).

The Debian bit is just flat-out wrong:

Debians dependency scanner is broken anyway, as there's no way to tell what version of a library is actually needed. Only the developers know that. It works around that problem by assuming that the binary requires whatever version it was built against (which as we see elsewhere may be true or may not be).

Cute, but no. Packagers can specify in shlibs files, the last ABI break. So if your library adds a new interface in 2.1.3-1, then you can put:
libfoo 1 libfoo1 (>= 2.1.3-1)
in your shlibs file, and wham, anything built against libfoo now gets that dependency. Of course, if the downstream packages are really ninjastupid, they can hardcode in their library deps.

Why should the convenience of Debian packagers, who number in the low 2s, outweigh the convenience of people who download autopackaged binaries from the website, who number in the high 200s/day?

Actually, last I checked, there were close on 1000 registered Debian developers, who had gone through the long process. I don't know how long the New Maintainer queue is (except: really long). There are millions and millions of users of Debian and its derivatives (Ubuntu, Knoppix, Maemo, et al). If you're going to be a condescending twat, could you at least please try to be accurate, instead of picking on Debian for being insignificant compared to your hundreds of downloads per day?

I dislike writing CGI crap so much that it's really amusing that I'm writing a wiki. Today I did most of the CGI parts of ikiwiki -- page editing in a web browser (with commit back via svn) and RecentChanges (pulling the logs out of svn). Still have to add logins to avoid spam, and after that I think I'll be done with the CGI side for now. It is nice to have the web-based editing interface for minor fixes to a wiki, though I've also found it very nice to be able to edit pages in vim for longer writing sessions. I did come up with something interesting today when I wasn't doing all this CGI stuff. Since ikiwiki often needs to run with different privs than its invoker (to rebuild a wiki in a post-commit hook, or to check in a wiki page from CGI), I came up with an interesting way to securely run it setuid. Pass ikiwiki --wrapper along with any other parameters, and it will emit a wrapper binry that is hardcoded to only run ikiwiki with those parameters. Dynamically programmed in C and compiled on the fly of course. The wrapper is designed to be completly safe to make setuid, and can be dropped into a post-commit hook, or cgi-bin, or whatever. You can also regenerate a wrapper with ikiwiki $(./wrapper --params) --wrapper, which is useful for changing a param. So the wrappers have sort of turned into ikiwiki's equivilant of a configuration file, which it otherwise lacks. I suppose I might as well put publish ikiwiki's documentation wiki already.

It’s only seven weeks to the most important vintage computing event in Europe, the Vintage Computer Festival Europe (VCFe), which for the first time will be three days this year because of May the 1st being a Monday this year and an official holiday in Germany and some of the swiss cantons (at least Zürich). So the VCFe 7.0 will take place from April the 29th to May the 1st 2006 in Munich and it’s focus this year is:

Home Made Brains
Kit-Computers and Individual Designs I’m currently thinking about which old hardware I’ll present at this year’s VCFe. There are a few ideas flowing around in my head:

• Old x86 laptops (1989-1996). This was my exhibition last year, but ayca, my i486 Toshiba laptop is broke (probably the display controller) and the “new” Compaq LTE pony hasn’t been setup yet. Nevertheless, I’ll bring my (nearly) everyday ThinkPad bijou with me since it’s now 10 years old and therefore ontopic now. Yeah!
• The HP 9000 Apollo Series 400 I got from dwalin and dyfa, if I manage to get a NetBSD installed on that box.
• Buying a tux case but installing some old hardware in it instead of the current FOX board. On the other hand: There should be at least a Linux running on that box.

Anyway, I’ll be there, many other Symlinker (at least dino and Venty) also will be there. And I hope to see you there, too. :-) Oh, and btw: One wish to the Debian community regarding the VCFe: Perhaps someone who’s familiar with the Debian m68k Port could give a talk about how Debian plans to save this port although the old hardware isn’t fast enough to fit the requirements for inclusion in a Debian release. This would give a really interesting talk about old and new hardware. Talks can be held at least in German or Englisch IIRC. TIA. :-) Update 16:26h: I thought of this mail by Wouter Verhelst about how modern ColdFire computers could run buildds for a hybrid m68k and ColdFire port when writing this paragraph. See also this Symlink story [German] about that topic.

As I see it, there are three positions:

• Those who think that everybody except their candidate is a teletubbie
• Those who think everyone has a chance to win except the teletubbie
• Those who don’t care about teletubbies and would rather vote for Power Rangers

Yes, someone already told it: is that time of the year again. This small and insignificant fact (the DPL election) can shock the entire Debian Community. This kind of stuff makes us the fun, social and rewarding Debian Community some people claim we should be. The people who only cares about developing will keep working disregarding all the social conflicts. So most people won’t take much care about the Election, pick up a candidate, vote and keep working
It says: Welcome - Bolivarian Revolutionary Government of the Merida State David has more than one week in Venezuela. I’m gladly offering him accomodation in my house, bandwidth and all the support he needs for the next twenty years. We spent a weekend in Merida (which is in the Venezuelan Andes) in some Free Software Workshops and the rest of the week we have been working in several migration projects in the Company I’m working with. We have setup g33k!, a small server in my room running Debian (and Cherokee and Jaws) just for fun and testing. He’s leaving to San Crist bal (the capital of a state in the border with Colombia) on Friday and I should be finishing my semester as well. The next big Free Software event in Venezuela is the Latin American Infest. See you there!

Several people's blogs have appeared recently in the planet with the different points of view on the different candidates and various rants regarding the DPL office - Well... This time I have not yet been able even to read the platforms of the different candidates (of course, I plan on doing it quite soon), but I follow the posts on the subject with interest. The most interesting post so far is Martin Michlmayr's - Of course, being an ex-DPL, there are important experiences he has that few people do.
A couple of days ago I was talking with one of the candidates with whom I have talked and worked in the past. My main gripe with the whole process is that, although as a project we need a leader, an easily identifiable single contact person who knows the teams, knows the people and can speak on the project's behalf, I have not seen much being done by the past DPLs towards the inside of the project. Of course, it's easy to bitch around when I sit in the comfortable silent majority most of the time - Currently I am devoting quite less time and effort to Debian than what I should, although it is true that setting up Debconf6 in Oaxtepec takes a _lot_ of time and that it will facilitate much more interaction between Debian people (which is good for the project) than me working more and better on my packages and on doing interesting team work.
Maybe something that would make me to vote for somebody, more than the most coherent and best written platforms, is for the candidate to admit the lack of importance of the role to most of the project - or to defend how to make it again a leadership position.
Following Martin's post, maybe we do need a Bruce-like leader who tells us what to do and drives the project. Or maybe not, maybe we could do better with reducing the importance of the post towards the inside and emphasizing it's mostly a confidence vote for somebody to speak on behalf of us all. And even this would be difficult, as a sad flame in debian-private some months ago reminds us that nobody can speak on behalf os the whole project because somebody might be offended by the viewpoint taken by the official?
I am no big believer in democracies. I do think that sticking to much to a democratic constitution (where democracies are very scarce in the Free Software world, where projects tend to have benevolent dictators grown by meritocracy instead of democratically elected) and allowing everybody to voice too much the same opinion in our regular flamewars has lead Debian to the communications swamp it is right now. We do have very effective small teams (quoting Andreas Schuldei' term for the phenomenon that seems to work best and appear naturally in our project), integration between teams is quite good... But having 1000+ people sitting in a big room and shouting at each other is plainly not fun. Maybe we should stop pretending that there is no cabal (forgod'ssake...) and admit that there is and it works, and we (the drones) implement Their decisions? Nah... That sounds it would only create more flamewars.
But seriously: Towards the inside, do we need a leader? Have we ever used it?

FOSDEM is one of the events I really enjoy. Unfortunately, I couldn't attend last year because I was at a conference in China. However, this year I was back, and the event was bigger than ever. There's so much going on that it's really hard to keep up. There are a number of people I'd really like to have talked to more but there just wasn't time in those two days which were fully packed. It was nice to meet a number of people again, though, in particular the usual suspects, including Michi Banck (aka Hurd illusionist, "it supports two wireless cards now"), Guillem Jover (Spanish mafia boss living in exile), and Jordi Mallach ("World Domination for Catalan^WValencian"). I also hung around the Spanish free software research people with whom I'm going to spend a few months soon. Crazy Spaniards... I've no idea how I'm going to survive there. Oh, and Neal Walfield, who still stinks, and who thinks I have a British accent now (which he thinks is a bad thing while I took it as a compliment). Regarding new people, I had the great pleasure to meet and talk to Lennert Buytenhek. I talked to him on IRC a bit recently because he's involved in the big-endian ARM port and I've been hacking on the ARM based NSLU2 device. Lennert is quite frustrated because joining Debian is so hard. As it turns out, there's currently a six month wait to be assigned an Application Manager. I haven't really followed NM recently, but when I acted as Front Desk I tried to keep it less than approximately six weeks. Unfortunately, a great number of AMs resigned in the last few months and years, and it has been quite hard to find good new people as AMs. Lennert is the kind of person we really want to have in Debian since he's extremely kind, smart and productive. Given that the current situation seems really bad I decided to act as Application Manager again, but I only intend to do that temporarily. I'm sure I forgot lots of other things. But the summary is that it was a great weekend, with way too much stuff going on at the same time. And while I wish I could have devoted more time to my research, I gained some important insights and did one interview which was really informative.

For a new project, I'm looking for wiki software with the following characteristics:

• Supports SubPages and relative linking from a page to its subpages and between subpages of a page works like regular wiki linking with no special syntax. MoinMoin supports subpages but to link to them without giving the whole path is ugly: "['/SubPage']" I want to just be able to link to SubPage from page FooBar and get /FooBar/SubPage if it exists, and /SubPage otherwise.
• Doesn't require special markup to make words that are not WikiWords, but that exist as pages, show up as links in other pages. Probably limiting this to capitalised words, and supporting turning off the feature for a blacklist of words in case of trouble.
• Can subscribe to changes for sets of pages or the whole wiki by rss.
• Can subscribe to be informed of new pages by rss.
• Uses some standard plain text markup language, like markdown or restructured text, and not some obscure thing specific to that wiki. Adding special syntax for wiki links is ok, and removing features like markdown's support for arbitrary inline html is ok.
• Keeps full history of changes to the wiki using a standard version control system like subversion. Ideally it would be possible to browse past states of the wiki at any point in time and even edit them to create branches, but UI for that is not a requirement.
• Allows direct commits to the wiki without using a stupid web form, using a standard version control system, like subversion.
• Supports images.
• Supports WikiName based logins and can limit edits to logged in users (although anonymous svn commits would be ok at least until wiki spammers learn how to spam via svn).
• Addendum: Cannot be written in PHP, thanks anyway.

At one point I had a half written wiki that supported a cvs backend (this was before svn) and supported browsing historical versions, but it got bogged down in trying to use html as the standard markup language, which diverted too much energy to writing code to sanitise html, and stalled out before it was usable. Writing one again doesn't seem wise, there are already too many. So I'm looking for pointers to anything that meets at least some of these requirements. Update: Subwiki uses subversion but is developing slowly and may be non-DFSG free. There's discussion about making TWiki support a svn backend, but it appears not to yet; it would probably meet all my other needs then some. GW uses subversion, but seems to be a java based academic research project. trac uses subversion, though it's not just a wiki and it might not use it for the wiki. Rather than tight subversion bindings, I'd be happy enough with a wiki that used flat text files and was flexibe enough so I could store them in svn. I'd even be happy to use viewsvn as the history browser for the wiki. Small and minimal, building blocks, like blosxom blogs, is good.

Since I find the DPL position increasingly uninteresting except as a position of technical leadership, I will probably use the following simple metric (which I think of as the "degrees from Bruce Perens" metric) to rank my choices for Debian Project Leader in this year's elections:

1. Order the candidates based on the perceived solidity of actual technical changes they propose to make to Debian.
2. Rank "further discussion" above the first candidate whom I could not bear to see as DPL.

I won't bother listing the result, it's pretty predictable. But I will here excerpt all the at least vaguely technical content from the candidate's platforms:

• Jeroen "Debian needs to focus on technical excellence with free software" "I will encourage more use of the official wiki"
• Ari / Zeke "I propose that all software in Debian be relicensed" "Also, we should remove all pictures taken by cameras with non-free firmware from the Debian Project." "I'd like to introduce a new Debian GNU/Plan 9 port"
• Steve (Steve wrote mikmod. Amazed I never connected those two dots before.) "more documentation on best-practice packaging and testing methods" "considering the impact of changes on the release schedule"
• Aj "The most important thing that I think would benefit Debian is increasing its tempo." "And sometimes doing it fast helps you to do it right" "getting updates accepted into the archive more frequently than once a day" "having frequent beta releases of etch/testing that we can legitimately call a release (benefiting from the ongoing work of the installer and testing-security teams)" "having reliably quick resolution of RC bugs in unstable" "automated testing efforts"
• Andreas "having more frequent and regular releases." "We have a good, realistic timetable for the release of Etch, and this should be made a priority," "Becoming More Purpose-Driven"
• Johnathan "When projects like Ubuntu and Progeny come along and pay people to do the boring parts of the work, we should be ecstatic." "a life-size statue on the grounds of Rensselaer Polytechnic Institute"
• Bill "Be strict in what you send, liberal in what you accept." "One of the problem of Debian is that too few developers consider the distribution globally rather than a collection of packages."

Rapha l Hertzog writes about the Condorcet voting system that we use in Debian. He then goes on to consider whether we could use the system to help us elsewhere - could we track MIA developers by checking their voting records? This strikes a chord with another idea I've heard recently: make voting in the DPL election mandatory for active DDs. I expect that even suggesting such a thing may appal some of us - forcing volunteer DDs to do anything is not likely to be popular, and I admit I have misgivings about it myself on that front. However, I can also see the attraction of the idea. The DPL election is a very(!) well publicised event that happens regularly every year, and is something that most DDs are likely to care about. Asking the project secretary after the polls close for a list of DDs that have not voted might be a good way of picking up on those who have stopped paying attention to Debian issues. Comments? :-)

I'm really not liking the way things are going at the moment.

• the Legislative and Regulatory Reform Bill ... gives ministers power to alter any law passed by Parliament
• [South Dakota] has signed into law a bill banning most abortions
• Vice President Dick Cheney said Tuesday that Iran will not be allowed to have a nuclear weapon and warned the United States is keeping all options on the table in addressing the irresponsible conduct of the regime.

NP: Ambient Mix, DJ krill.minima

Once upon a time, I had a blog in Engr^Hlish. I installed blosxom on my rental server and it was pretty cool. Simple and nifty. For a while everything went quite well.

Soon I abandoned it. After registering Planet Debian, my old blog was heavily spammed by those bastards somewhere around the world. I don't need Viagra (at least for now) and I don't have any relatives in Nigeria. And at that time I couldn't figure out how to fight with them efficiently. Even now I can't. I don't want to disable comments or trackbacks, since that's almost the only reason I wanted to have a blog. Also my rental server was so poor that always memory space was running out. And suddenly I became very busy after all. So I just threw it away and forgot about it.

Now I need an English blog again. And this time I don't want to hustle so much into just setting up the blog system itself instead of writing actual blog entries. This LiveJournal seems to be good enough for me, so I'm gonna just giving it a try. Logjam is neat, btw.

Warning: Very long post ahead. You have been warned! What? Tor is a Free Software project (revised BSD license), developed by Roger Dingledine and Nick Mathewson, which creates an infrastructure for anonymous TCP communication. From the project website:

Tor is a toolset for a wide range of organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features. Tor aims to defend against traffic analysis, a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security. Communications are bounced around a distributed network of servers called onion routers, protecting you from websites that build profiles of your interests, local eavesdroppers that read your data or learn what sites you visit, and even the onion routers themselves.

Tor also allows you to set up and/or use a so-called Tor hidden service, i.e., a server which offers some service (a website, ssh access, or similar) without revealing its IP to its users. Why? Why would you want to use Tor? Well, because you probably don't want anybody (neither state agencies, nor companies, nor "hackers", nor any other individuals or groups) to be able to record, analyze, and (ab)use information about your web browsing habits, or any other communication habits. For instance, you don't want Google to have a complete search-profile of you, which — even worse — might some day get in the hands of other parties. In the days of massive data retention you don't want all your electronic traces to be recorded, stored for ages, analyzed, and data-mined for dubious reasons and with even more dubious results and false conclusions drawn which might negatively affect you. If you're a human rights activist in China, you want anonymous communication. If you're a whistleblower, you want anonymous communication. The list is endless. For securing your communications, so that nobody is able to sniff your emails, your chat messages, your passwords, your private documents and conversations, you use encryption. For communicating anonymously you can use Tor. Combine both, and you have secure and anonymous communication. In case you're wondering whether criminals might abuse Tor, read the Tor Abuse FAQ. Short answer: yes, but if you're willing to break the law, you already have anonymity (open access points, stolen/prepaid mobile phones, etc.). You don't need Tor to do bad things if you're a criminal. If you're one of those horrible "oh, but I don't have anything to hide" guys, consider this: Say you have a drug/alcohol problem and want to visit an anti-drugs/anti-alcohol website or forum for help. Would you want the whole world, your neighbors, your co-workers, your boss, to know that, or would you rather want to keep that a secret? Say you have AIDS and want to get information on the web? Or, to make the example even more dramatic: Would you want some random guys to be able to watch you while you fuck your wife? No? So you have something to hide after all, right? My point is: Everyone has something to hide, even more, it is a basic human right to have the ability to hide something. It's called privacy. How? Tor implements a form of onion routing to, basically, push encrypted data through multiple Tor nodes (servers), before it reaches the final destination (e.g. a website). The result is that neither the website owner, nor a local eavesdropper, nor any single Tor server knows who requested that specific website, hence you are communicating anonymously. For more technical details, read the Tor overview and the Tor documentation pages. In order to use Tor, you have to install and run a local Tor client/daemon (this is not necessarily a Tor server!). On Debian, type apt-get install tor, on other systems you can get the respective binary packages or download the sources and compile Tor yourself. Usually Tor is used together with Privoxy, a configurable HTTP proxy which sanitizes your web-browsing experience by removing nasty banner ads, pop-ups, JavaScript, webbugs, cookies etc. etc. So: apt-get install privoxy. After installing and starting Tor and Privoxy, you can now configure your webbrowser to use Privoxy as an HTTP proxy (see below), and Privoxy will in turn use Tor to anonymize your communication if you add "forward-socks4a / localhost:9050 ." to your /etc/privoxy/config. Anonymizing various applications Most (but not all) of the following information is also covered in the very useful Torify HOWTO in the Tor wiki (I will add the missing information there, ASAP). As I'm pretty paranoid, I have checked every single of these configurations with Ethereal to ensure that the traffic is really anonymized. However, if you are paranoid, you shouldn't trust me, but rather test this stuff for yourself! Warning: DNS Leaks:
The biggest problem with many applications is that they leak DNS requests. That is, although they use Tor to anonymize the traffic, they first send a DNS request untorified in order to get the IP address of the target system. Then they communicate "anonymously" with that target. The problem: any eavesdropper with more than three brain cells can conclude what website you visited, if they see that you send a DNS request for rsf.org, followed by some "anonymous" Tor traffic. The solution: use Tor together with Privoxy, that prevents DNS leaks. Many non-HTTP-based applications are usually torified using a small tool called torify (e.g. by typing torify fetchmail), but often this approach has DNS leaking problems, see below.

• Webbrowser: Firefox, Mozilla, Galeon, Konqueror, ...:
  Most browsers can be torified by using Privoxy as an HTTP(S) proxy, i.e. using 127.0.0.1 as proxy host and 8118 as proxy port.
  For example, to torify Firefox go to Edit -> Preferences -> General -> Connection Settings -> Manual proxy configuration and configure:
  HTTP Proxy: 127.0.0.1 port 8118
SSL Proxy: 127.0.0.1 port 8118
FTP Proxy: 127.0.0.1 port 8118
SOCKS v5

  For Konqueror, go to Settings -> Configure Konqueror -> Proxy -> Manually Specify the proxy settings -> Setup and configure:
  HTTP Proxy: 127.0.0.1 port 8118
HTTPS Proxy: 127.0.0.1 port 8118
FTP Proxy: 127.0.0.1 port 8118

  Warning: Although Privoxy doesn't support FTP, you should configure the browser to use Tor + Privoxy for FTP. By doing that, you get an error message when you try to access ftp:// URLs, but at least you don't send untorified traffic without noticing.
  Warning: Firefox's "Live Bookmarks" (RSS feeds) are a problem if you switch from a torified to an untorified state sometimes (by switching or enabling/disabling the proxy). Firefox periodically requests all the feeds you're subscribed to. If you turn off Tor + Privoxy usage, they will be requested non-anonymously, and you won't even notice it! Solution: remove all "Live Bookmarks", or never switch to untorified browsing.
• HTTP-based tools: lynx, links, w3m, wget, curl, ...:
  Most other HTTP tools, such as wget, can be torified by setting the respective values for the http_proxy and HTTP_PROXY environment variables. Applications which don't honor http_proxy probably have a configuration option to set the HTTP proxy.
  Add this to your ~/.bashrc or similar config-file:
  http_proxy=http://127.0.0.1:8118/
HTTP_PROXY=$http_proxy
export http_proxy HTTP_PROXY

  Warning: links is a notable exception here. It does not honor the http_proxy environment variable! However, you can add http_proxy 127.0.0.1:8118 to your /etc/links.cfg and/or to your ~/.links/links.cfg. Or go to Setup -> Network Options and do the same there. Or use the -http-proxy 127.0.0.1:8118 command line option.
• Instant Messaging: Gaim:
  Go to Preferences -> Network -> Proxy and configure this:
  Proxy type: Socks 5
Host: 127.0.0.1
Port: 9050

  Gaim doesn't seem to leak DNS requests.
• Debian: Apt:
  Setting http_proxy is enough, as apt-get honors the http_proxy environment variable. But you can also add this line to your /etc/apt/apt-conf:
  Acquire::http::Proxy "http://127.0.0.1:8118/";

  apt-get doesn't seem to leak DNS requests.
  Warning: This will only work for deb/deb-src lines in /etc/apt/sources.list which use HTTP, because Privoxy does not support FTP.
• RSS-Reader: Akregator:
  Which RSS feeds you are reading tells quite a lot about you, and it's probably an information some people or organizations would be very interested in, I imagine. So anonymizing your feed-reader is quite important, IMHO. Akregator (a KDE RSS-reader application) uses Konqueror internally, so if you have set Konqueror to use Tor + Privoxy as HTTP-proxy, Akregator is safe, too.
  Akregator doesn't seem to leak DNS requests.
• Podcast Client: iPodder/Juice:
  Got to File -> Preferences -> Network settings and configure this:
  Use a proxy server: enable
Address: http://127.0.0.1
Port: 8118

  iPodder/Juice doesn't seem to leak DNS requests.
• Secure login: ssh:
  In order to torify all your ssh communications (ssh, slogin, sftp, etc.), edit your /etc/ssh/ssh_config and/or ~/.ssh/config and add:
  Host *
ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

  This requires socat, so: apt-get install socat.
  ssh doesn't seem to leak DNS requests.
  Warning: Simply using torify ssh does not suffice, it leaks DNS requests!
• Email: fetchmail:
  Properly torifying fetchmail is pretty ugly. Basically, torify fetchmail should be enough (one would think), but that leaks DNS requests! All tips offered in the Torify HOWTO suffer from this problem. The ideal solution would be to use tor-resolve (a small utility which resolves DNS requests via the Tor network, and hence anonymously) before fetching the emails, but I haven't found a good and simple solution for that. What I do right now is to hardcode IP addresses in my ~/.fetchmailrc config-file and then use torify fetchmail, which doesn't leak DNS requests. However, it leads to some ugly "fetchmail: Server CommonName mismatch: foo.bar.com != xxx.xxx.xxx.xxx" warnings.
  I always start fetchmail manually, often by clicking an icon in my IceWM toolbar. So I use the following line in my ~/.icewm/toolbar config-file:
  prog Fetchmail fetchmail xterm -e torify fetchmail

  Sometimes I invoke fetchmail from the command-line, too, so I have this alias in my ~/.bashrc:
  alias fetchmail='torify fetchmail'
Warning: Just for the record: torify fetchmail alone (i.e. used with hostnames in ~/.fetchmailrc) does not suffice, it leaks DNS requests!
• IRC: XChat:
  Go to Settings-> Preferences -> Network -> Network setup -> Proxy server and configure:
  Hostname: 127.0.0.1
Port: 9050
Type: Socks5

  Then make sure you check the "Use a proxy server" checkbox in the preferences dialog of the IRC server you want to use.
  XChat doesn't leak DNS requests.

You might also want to check out toraliases, a small shell script you can source from your ~/.bashrc file. It defines some functions and aliases which transparently direct the traffic of some (but not all!) programs through Tor. Applications which cannot easily be torified Anything not using TCP usually cannot be torified, as Tor only works for TCP.

• Non-TCP traffic from tools like ping, host, dig, nslookup, nmap, traceroute and lots more: as Tor only supports TCP, you're out of luck. However, you can safely use web-frontends such as dnsstuff.com over Tor + Privoxy (if they don't block Tor users, that is).
• whois: Although torify whois google.com leaks the DNS request for the whois-server (in this case whois.crsnic.net), it doesn't seem to leak the host you wanted to lookup. Can somebody confirm this? The safer method is to use a web-frontend, though.
• FTP: Although torify ncftp works, it leaks DNS requests! I haven't yet found a way to fix this (help is appreciated!). I also tried a few other FTP clients, without luck.
• GnuPG: Using gpg anonymously should work by using a proper http_proxy environment variable and by using a hidden Tor server as keyserver.
  Add this to your ~/.gnupg/gpg.conf:
  keyserver x-hkp://yod73zr3y6wnm2sw.onion
keyserver-options honor-http-proxy broken-http-proxy

  This works in theory. However, I noticed a problem: while gpg --recv-keys seems to work fine, gpg --refresh-keys leaks DNS requests! It seems GnuPG hard-codes the keyserver to keyserver.pgp.com in that case and leaks the DNS request for this domain name.
• Sending email (SMTP): Not sure how to do this with Tor. Many Tor nodes block SMTP per default. A better solution is probably Mixmaster/Mixminion.
• CVS, svn, Bittorrent/Azureus (untested HOWTO), usenet clients (pan, slrn), xmms: TODO. Haven't checked, yet.

Pitfalls to be aware of

• Rule #1: Don't spoil your anonymity by being stupid!
• IRC: Don't use nicks which hint at you, such as your real name, real-life nickname, acronyms which are known to "belong" to you or identify you. Don't use things like DCC which might reveal your real IP or real information about you. Disable all possibly "leaky" features/commands such as CTCP, VERSION requests, automatically accepting files from other IRC users, etc. etc.
• Don't accidentally access Tor hidden server URLs in an untorified browser. For example, if you would try to access the fictitious hidden server abc1234.onion, this request would travel over the net unencrypted and untorified. An eavesdropper could sniff that, enable Tor on his computer, go to abc1234.onion, and would know what you wanted to look at.
• Double-check that all applications you use don't leak DNS requests.
• Do not only configure your ~/.foobarrc config-files but also the config-files in /etc. Otherwise you might eventually use wget, ssh, lynx or other tools as root (instead of your normal, non-privileged user account) resulting in untorified traffic!
• Disable all "check for updates automatically", "notify upon new release" and similar "phoning home" features in all your applications. Most such features are probably not Tor-safe, i.e. will send/receive untorified traffic. Some candidates are Firefox, Adobe Acrobat reader, Gaim, and others.
• Never, never, think that Tor encrypts your traffic! It does not! The person who runs a Tor exit node can easily sniff all plain-text traffic! Tor only anonymizes your traffic, but it can still be sniffed plain-text at the beginning and at the end of the onion route! So don't do any HTTP-auth, or plain-text password sending for e.g. POP3, telnet, and so on. Always use encryption in addition to Tor!
• In general, spread only a minimum of information. Disable referrer sending (e.g. using Privoxy), disable cookies, kill webbugs (Privoxy), and so on.
• Watch your language, especially in public forums or IRC. A linguist can probably easily figure out which country/region you're from if you speak/write broken English or use certain idioms or false friends. This might or might not be a problem for you, but it's something you should bear in mind.
• If you're extra paranoid, you could set up your firewall to block all outgoing DNS traffic and force all applications to use Tor to resolve names. You could probably also block all outgoing non-Tor traffic...
• Another good idea is probably carrying an Anonym.OS LiveCD with you, so you can have a (more) anonymous communication wherever you go.

More information More information is available in the Tor documentation, the Tor wiki, and especially in the Tor FAQ. In addition, there's an IRC channel on Freenode (#tor), some slides and a video (torrent) about Tor you might find interesting. If you would like to help, you can run a Tor server, donate some money, or volunteer to do other things (code, debug, document, translate, and more). That's it for now. I'm very grateful for comments and suggestions, especially for hints on how to anonymize more applications. Also, if you notice any dumb mistakes I made, please leave a comment. Update 2006-03-07: Fixed typos, added link to the toraliases project (thanks Benjamin Schieder).