I recently changed my spam filter from spamassassin to dspam and have spent the past couple days training it. It’s been working well until this morning, when I found that it had falsely tagged 3 mails as spam. I found this quite alarming, since false positives are a very bad thing. Even worse, the messages didn’t look spammy at all. When I looked closer, I realized that all 3 had been sent to the NM Front Desk, new-maintainer@debian.org. So I thought to myself, “Why would dspam think any mail sent to new-maintainer@.d.o is spam?” Well, like any other Debian role address, it’s basically a giant spam trap and receives a gazillion spams a day. Since up to that point, not a single mail sent to that address had been valid, so dspam must have decided that all email sent to new-maintainer@d.o was spam. It must have been sorely disappointed to learn that new-maintainer@d.o actually receives a valid mail every once in a great while.

Eric, I think you misunderstood what I actually said. I am in no way opposed to watch files, nor do I dislike them. In fact, I think they're quite nifty, and useful for many people. I dislike the repeated complaints that so few people put them in their packages. I proposed a way to solve that, once and for all, without getting a thousand people to do something. I also dislike putting information that can and does get out of date into places where it is hard to find and fix, instead of a centralized location. The copyright file contains information about where the package was downloaded from; the watch file tells where the current upstream version is. The latter needs updates, even when the package otherwise does not. Here's a quick plan, for those who want better watch file coverage: start an Alioth project, with a Subversion repository for watch files missing from packages; make a patch to qa.debian.org/developer.php to use a watch file from the centralized repository if the package itself doesn't contain one; and finally advertise the new stuff and ask for interested volunteers to start submitting them, via Subversion or by e-mail. For Alioth and Subversion feel free to substitute anything else you prefer, of course. If someone does that, I'd be quite happy to write and submit watch files for all my own packages.

Eric Dorland writes about watch files, which are a way to keep track of whether there are new upstream versions of a package. He urges everyone to add them to their packages. I don't want to do that. First, I'm also the upstream of most of my packages, so my need of them is small. When I'm not upstream, I keep track of what upstream does anyway, so I'm informed of new releases that way. I realize that watch files are not useful only for the package maintainer, but also other interested parties, but, hey, I'm lazy, so I need some incentive apart from "some people think they're cool" before I take on a duty to maintain yet another aspect related to packaging. Second, I don't think watch files belong in the package. If upstream moves to a new domain, for example, the watch file needs to be updated. If it is in the package, that needs the package needs to be updated. I'd rather see watch files kept in a central server so that the package doesn't need to be changed in this situation. This would also avoid the need of having the package maintainer co-operate. Thus, I propose that those seriously interested in watch files create a "watch.debian.net" service, which keeps watch files in a centralized location, and allows them to be maintained in a wiki-like fashion.

Yes, I have decide to give up in using bazaar to keep packages that I do not maintain in any of those Alioth teams. While I think that allowing people to branch your package if needed, I believe after having tried it that bazaar is a bit too much what a developer needs to keep his own packages in a SCM repo. Smokeping has been actually co-maintained using bazaar. Tough that allowed Niko to make his own packages and then send me back a point in his repo to merge when some changes were done, that made to some confussion when both were working on the same issue, and the work needed to merge his branch usually meant some delays in having a new version ready and uploaded to the archive. Thus, I have switched to SVN as my SCM to keep my packages repo. You can wonder why that change from a distributed SCM to a centralized one. I could have used mercurial or any other distributed SCM, but I wanted to know when a person is making changes to one of my packages. So if I have another co-maintainer for any other of my packages I can easily add him to the list of people allowed to make commits. Also, being SVN allows anyone wanting to make changes branching from my software to use SVK, as a distributed SCM which keeps pretty well integration with SVN. I have yet to make websvn package to work in order to provide a link to my repo, but it is taking a bit longer than expected, and I am sure that is because of something quite stupid is being left out in its configuration.

Joey mentioned a few unix utilities and started collecting them. I create utilities for my work but usually they are too specialized and mostly fall into the "process my unique file format" category. I have however a few more generally usable utilities which haven't seen the world outside my computer and thought I'd make them more accessible.

todist

Input is a list of numbers, one on a line. Output is their distribution, a value and how many time it occurs in the input. Useful for my statistics and performance work.

tostats

Input is a list of numbers, one on a line. Output is some statistics about the numbers: average, stddev, min, max, mid point.

I also have a few non-unix-style utils that are useful (to me), It's a fairly simple multiple machine synchronization by using multicast messages. It's also useful to synchronize on a single machine, running it at the end of one command sequence and running the receiver to wait for it to end and do some other commands. It enables the equivalent of: cmd && othercmd && thirdcmd for multiple branches, so I can run two or more command chains when one ends.

Today I went to see the doctor for the first time in the US. I went for a few different reasons, there was a mole on my back that Sarah was worried about having changed, my wrist still hurts from that bike crash a few months ago, and I thought I'd see if I could get a 'flu shot. The first thing that's different is when you make the appointment, the receptionist asks why. I wouldn't necessarily feel comfortable explaining what ails me to a receptionist from the comfort of my office cubicle shared with three other people within earshot. Besides, it's between me and my doctor. I was a bit taken aback by this level of questioning, just to make an appointment, and hid behind a "general checkup". The second thing is each doctor seems to have their own personal nurse to do the pre-consultation blood-pressure taking and examination room setup. The third thing is the prescription seems to go straight from the doctor to the dispensing pharmacy of your choice. Pretty cool. So today I had my "general checkup". Hoo boy. Let's just say an hour later, I was feeling very poked, prodded, and squeezed, and emerged with a tetanus booster, a blood test, and an order for an x-ray. I certainly felt like I got my ten dollars' worth.

Since Joey Hess posted a short conversation we had on IRC today about the role of the DPL, I thought it's a good time to express some of my thoughts. Basically, I think that most people have a bad understanding of which tasks are really involved in being DPL (e.g. much more purely administrative crap that nobody else wants to do) and that they're quite naive about what the DPL can achieve, at least in the current climate. Let's just look at the current discussions on the -vote list. It's this time of the year when everyone pretends that its Christmas, expresses their feelings of what's wrong with Debian and where Santa Claus^W^Wthe candidates reassure them that everything will be fine. "Will you fix NM? Fix or replace ftp-master? etc." "Oh, sure I will, all of that (and more)." Honestly, would you elect someone if they told you they won't or can't? The strange thing is that the same questions get asked every year, and yet people don't get the hint and look for other solutions. I'm not overly happy with any of the candidates this year, and I was seriously considering running again, not next year but possibly later. However, this Christmas wankfest reminded me again why that may not be such a good idea after all. I remember how much time I spent answering questions on -vote myself, and while I'm all for transparency, many of the questions were just a waste of time. This year, the questions were relatively sane in the beginning but now it's just a waste of time most questions are posed in a way that it's clear what kind of answer people want to hear. I spent hours and hours answering questions, but at some point I thought "cannot we just stop talking for hours about what I'd do if elected and actually start doing all that stuff?". That would have been so much more productive. Instead of asking the DPL what they'll do to solve All The Problems In Debian, why don't you ask yourself what you can do to improve the situation? There's a bottleneck with the DAM, you say. Right, the chances that you'll be added as DAM are relatively small. But have you ever considered helping the DAM and to make their life easier? How about signing up as an Application Manager and producing such good reports that it'll be a piece of cake for the DAM to approve people based on your reports? Right, it won't fix the bottleneck, but it will make the situation so much better. Instead of bitching about the security team, why don't you prepare a package, write the text for the DSA and get everything ready in a way that a DSA member can simply take your work, recompile the package and issue the advisory? Now I'm sure some people will say that they've tried that and failed. Yes, not every upload for DSA will be accepted as it is, but how hard have you tried? And people always complain about the cabal and how hard it is to join teams. And while I agree that this is partly true, there are so many counter examples too. Look at me as an example. In 2.5 years, I became the most productive Application Manager, joined (and took over) the NM Front Desk, became a "senior" Quality Assurance member, and got elected as project leader. Am I special? No, in no way I just put in a lot of effort. Look at Jeroen van Wolffelaar, who joined at the end of 2004, and who is involved in QA (especially MIA) and lintian, is the co-author of the new packages.d.o code and an ftp assistant. Andi Barth (who got an account in January 2004) has done important QA work (bts2ldap), is a maintainer of the developers reference and a release manager. So it's not possible to join a team, you say? Maybe you're just not trying hard enough (and the right way!). (Hint: "make me a DAM/ftp-master/whatever" doesn't work as well as "how can I make your job easier?"). What I'm trying to say is that people should stop believing that the DPL will fix everything and that they should actually help out themselves. If we all work together and put effort into the areas that need work we might actually achieve something. People have been asking for a strong leader and this urge got stronger over the last few years. But, face it, we currently don't have a culture which accepts a strong leader. Joey Hess mentioned that he wants to see a DPL who pushes technical changes. I did that too, to some degree (mostly in private since that works much better than on a mailing list where a big flamewar is guaranteed). For example, I kindly asked Joey to lower the priority of the non-free question so it would not get asked in a default installation. And he did because Joey is a reasonable guy. (He also told me that me making this request made it easier for him to justify.) However, unfortunately, not everyone is like Joey. And what are you going to do if a maintainer refuses to listen, as many do? I mean, seriously, what can you do? Some are increasingly talking about the good old times of Bruce Perens who would tell people what to do and make decisions. The urge for a strong leader increased over the last years. I think that's partly a reason why Branden got elected last year people expected him to completely shake things up. I haven't talked to him and I wasn't part of the leadership team, so I don't really know what happened, but from what (little) I've heard, it seems that he tried, quickly realized just how rigid some of the structures are and gave up. You have to see things in a historical perspective (and I can only recommend that people who have access to the debian-private archives take the time to read through them). There's a reason we have had "weak" leaders since Bruce. While now a large number of people think that Bruce was the best thing since sliced bread, lots of people were really pissed off back then with him commanding people around. And what was the result? A constitution that would ensure that no leader would ever have such power again. And that's what we're currently stuck with. I think that one of the biggest problems Debian is currently facing is the inability to make decisions. There are so many endless, completely futile (and repetitive) discussions going on. We need someone who comes in, tells people to shut up and makes a decision on behalf of the project. A decision people will follow, even if they personally disagree with it. But seriously, do you think our culture would currently accept such a leader? I can tell you from experience that even people who have been asking for a "strong" leader won't actually follow a leader who tells them to take a certain course of action. We really need to fix this problem, and the problem is in our culture. And since our culture is defined by who we are, you should start with yourself first. Start by asking yourself a few questions. Do you think before posting something to our lists, and ask yourself twice whether it really adds value to the discussion? If there's an area that is problematic, will you try to help out? If asked to do something you're not particularly interested in but which is good for the project will you do it? And most importantly, will you contribute to make our culture something that is fun? The project leader is important, but don't wait for them to fix all of our problems. If there's a problem, try to figure out a way how you can solve it!

Something in apt-cacher did always suck... I adopted the package short before the Sarge release and tried to make it work better. At that time the package was not in the best state, too many changes have done without big design (or any design?) in mind. I made some changes on the cache structure to make it easier maintainable, introduced a basic signaling mechanism and consistency checks, so it should not get stuck or deliver wrong data any longer. However, there was the one big flaw, and Bug 354925 brought it to daylight. Storing all files in a flat directory was a very cheap way to merge multiple mirror contents and allow users choosing just any valid mirror. But it had also some costs: file collisions on identical names, happening more often since Ubuntu's is out there. The more I looked trough the code to find a good solution, the more I realized a need for a complete overhaul of the internal structure. For example, the simpliest change would be just putting the files into a nested directory structure. Great. But you will have duplicated files everywhere. They can still be re-unified using hardlinks, but that should be done offline since lookups with checksummng cause too much delay. And there was still the problem with persistent connections and forks, LWP does not allow connection reusing in forked clients so you get too many server connections. And the logging has been done synchronously and required flock'ing. Acceptable and not very memory-expensive but causes delays on filesystems with some load. So, the final software architecture for apt-cacher that I came up can be described with few characteristics:

• using perl threads (separate threads for logging, connection dispatcher, connection handlers, download agents)
• not spawning too many threads, putting agent threads into a pool of available threads. That would even reuse the connection if the next apt-get client tries to access the same server
• no direct access via CGI or stdin/stdout (inetd) anymore. Instead, connection can be done via Unix Domain Sockets, so small wrappers will provide access to the daemon. That should be even more efficient.
• the problem with file duplicates will be solved with sqlite3 - apt-cacher will extract the data from Packages/Sources/Index files and track the paths/filesizes/checksums. When a client requests a file and a stored one (with the same size/basename/checksum) exits, it will be returned instead.
• the bunch of "header", "complete" and "notify" files will disappear too. They just eat space and inodes and are not needed anymore. The header files will be replaced with self-generated ones, using file data from the database. .complete and .notify existed basically for IPC and storage of origin download path and will be replaced with internal thread communication and directory path.
• integration of pdiff files - if the package index files are processesed in a background thread anyway, the more fresh pdiff files can be used to rebuild the index files in an efficient way. Trigering this rebuild action periodicaly would also allow old apt-get clients to use the benefits of the patch transport.

But first I need to get past my exams period :-( And I hope the final implementation will not become a memory monster, I didn't have the impression that Perl threads are really memory-efficient in the few first tests.

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."

Since everyone else seems to give their opinion on DPL candidates over at Planet Debian, I'll join the chorus. Since I've met and know most of the candidates, I'll focus on what cannot be in their platform: their personality.

• Jeroen Van Wolffelaar: I've met him in person a few times (at FOSDEM, and at DebConf5 in Helsinki), and his dedication to and passion about Debian is... wonderful. His experience with being in the DPL team last year and his infrastructural involvement in the FTP team should mean that he's quite up to date on Debian's big picture.
That being said, I'm not entirely sure he'd be the perfect DPL candidate. All his passion and dedication aside, he's rather new(ish) to the project (having received his Debian account only one or two years ago, IIRC), and might not have the experience one would expect from someone who's been with Debian for a longer time. That's not a fatal flaw, but it does mean I'm a bit... reserved as to his candidacy. I'll still rank him pretty high, but not as number one.
• Ari Pollak: ha. ha. hah.
• Steve McIntyre: Also someone I know from both previous FOSDEMs and DebConf5. The impression I have from Steve is that he's someone who has a very (very) clear view on how Free Software in general, and the Debian project specifically, works. He's a very nice guy, easy to work with in the encounters I've had with him, and has the sort of calm but focussed attitude you'd expect from someone who's done a lot of things in his time, and therefore isn't all that easily impressed by new but short-lived manies anymore. Which, I think, is a virtue for a leader; a leader should be focused on the long-term benefits, not on the short-term fun. I expect him to be able to disconnect himself from immediate issues, instead having a look at the big picture when required.
I think the message is clear: Steve is going to get my #1 vote.
• Anthony Towns: a difficult one to form an opinion about. Aj has been a long-time valuable and dedicated contributor to the project; for that, he deserves (and receives) my respect and praise. He can be expected to know the project inside out, which is something very helpful for a DPL.
However, I don't think it's a secret that aj and I disagree on certain issues of the social aspects of the Debian project. Since his platform specifically mentions those things, I don't think I'll be ranking him very high on my list. I won't object to him becoming DPL, however, and I'll still be happy should he be our DPL. Just not as much as if it were Steve. Additionally, Anthony has a bit of a tendency to be imposing his view on others, which I think is a bad quality for a DPL. He's aware of that, however, and claimed he'll try to avoid making that mistake, which is helpful. Oh, and what's with the singing? ;-)
• Andreas Schuldei: When Andreas mentions in his platform that he's got great leadership capabilities, he isn't lying, as everyone looking at how DebConf is organized can see. However, the few times that I met him in person, there was something subconsciously that now makes me think twice to vote for him. I don't know what it is. I'll still rank him pretty high, but not as number 1.
• Jonathan Walther: This guy needs a reality check. No, really.
• Bill Allombert: Also someone whom I've met a number of times at FOSDEM. Bill is a bit of a modest, timid guy with a passion for Debian and Free Software. Though I respect him as a person and for the work he does in Debian, I don't think he has the perfect personality to become a DPL. No offense, Bill; but you'll end up rather low on my list.

It's that time time of the year again when the Debian Project gathers to elect a new leader. This year there are a record seven candidates. I just spent a couple of hours reading their platforms and a lot (not all, my eyes glazed over after a bit) of the discussions on debian-vote and these are my initial impressions. Jeroen Van Wolffelaar: Jeroen seems to have a good grasp of where the bottlenecks in the Debian system are. He supports the project Scud idea which has not really worked well so far (as far as I can see) but claims he knows what is wrong and how to fix it. He is young and still a student which might hamper his ability to travel which is a big part of being DPL. Astutely notes that Debian needs to stand out from the crowd more. Zeke the Cat: Does he have the balls to be an effective leader? Steve McIntyre: Not really high profile within the project as far as I can tell. Will he be able to "herd cats"? His platform is mainly about reforming Debians' social structure so this is a real concern. The idea of imposing some level of performance standard on developers is intriguing but he is rather short of details on how it is supposed to happen. Anthony Towns: Anthony is heavily involved in such roles as ftpmaster and release manager. It would be a shame if being DPL actually meant he would have less time for that sort of thing. He claims to be running mainly to introduce some new ideas. So hopefully he won't mind if we keep him in the boiler room instead of, um, athwart the foc'sle? Andreas Schuldei I like the idea of frequent face to face meetings. Andreas is a good fundraiser so if anyone can make this happen, he can. But in the absence of support from an eccentric billionaire is this really feasible? Also a member of project Scud. Johnathan 'Ted' Walther: Retar-ted. Bill Allombert: Also suffers from being relatively unknown (IMO.) A bit low on ideas and basically wants to maintain the status quo as far as social issues go. I can't consider him a viable contender. At the moment I'm leaning towards voting for Jeroen but Andreas and Anthony are still in the running. The IRC debate should be interesting.

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).

I dropped my cell phone a few months ago, and it ended up with a large crack across the LCD, which to me became the perfect excuse to finally get that Blackberry I’ve always wanted. However, given the uncertainty about the outcome of NTP v. RIM, I decided to hold off on my purchase till after the hearing last week, which was widely expected to provide some closure one way or the other as to whether RIM would be allowed to continue its service in the U.S. Unfortunately, there was no such closure to be found. So, I have a quick question to those more in the know than I: When the media talks of a “Blackberry shutdown”, I assume they’re just talking about a shutdown of the push email service, not a shutdown of all access to the Blackberry network? In other words, if Blackberry is shutdown, I presume I’d still be able to access the web etc.? Or would my brand new Blackberry become little more than an expensive paperweight?

I just managed around to learn the very basics of autotools, and as a first execrise, used them on my "SSDDiff" xmldiff application. So you can now build it with the usual "./configure && make" command (if you have C++ STL and libxml2, that is, but these have been really standard for years now) So there is a new tarball on the Alioth project page which should be a lot easier to install. Get it while it's hot. ;-) A few words about ssddiff: SSDDiff is an "diff" application for XML files, which can output into a "merged" format, "xupdate" diffs or "marked" versions of the source files. The algorithm used is very good at dealing with structural changes, but it uses rather much memory and is not the fastest. So it's a good choice when you have a difficult case (one could say it tries to do a "semantic diff"). If you have CVS files or database tables dumped to XML, use other tools.

Well, the title might be a little too optimistic, s/victory/battle/ if you prefer. Surely the next battle against software patents (not only) in Europe is coming up.

In case you haven't heard about it yet, visit the nosoftwarepatents-awards. Each month five (software) patents will be presented, which were issued despite the law prohibiting software patents and despite (formal) protests against them.

This month features such highlights as a "centralized database" and a "context menu".

The idea is to show, that a.) software patents exists (despite patent advocators claiming they don't) and b.) what a sheer nonsense such are.

BTW, your webshop is also patented, in case you didn't know. Selling over the network, paying with credit cards, sending offers after requests ? All patented. Shut down your business now ;-)

It's been a little while since I wrote about Asterisk. It's about time to update the story. I've been using Asterisk at home for awhile, but now we're going to use it at work. The need We have approximately 150 internal extensions here, and they are being supported by a Nortel PBX. This PBX is being end-of-lifed, and it would cost well over $100,000 to replace it, once the cost of the two required Windows servers (!) was factored in. Not only that, but it still isn't as flexible as Asterisk. Along with that, we have a need for internal wireless phones. We have a large manufacturing area, and we have people that would like to be able to use a wireless phone anywhere on the shop floor or office areas. No single cellphone company provides a signal that is strong enough to reach everywhere in the building -- not to mention that there would be big airtime fees. So we are planning to deploy 802.11b wireless phones for this purpose. Hardware The decision was made to go ahead with Asterisk. We will be replacing all office phones with Polycom IP501 units. This means running about 90 new runs of CAT5 to people's desks. For our Asterisk server, we got a HP DL385 2U server with dual dual-core Opteron 2GHz CPUs. We've really had good luck with Linux on these DL385s, and with HP's support. We got redundant power supplies, disks, fans, etc. on that machine. The CPU on here is probably more than we need, but telephones are very important to us and we wanted to make sure that we don't have any issues down the road. We purchased two A104d quad-T1 interface cards with hardware echo cancellation. Very nice cards. The drivers have been a little troublesome. But Sangoma's tech support is awesome. They logged onto our box and I was watching as they were hacking on the kernel module right there. Tech support like that is rare. I highly recommend Sangoma. We really need only one of those cards, but they're the only component of the Asterisk server that isn't completely standard. So the second is on hand as a spare. For our analog phones, we are using two Adtran TA 750 channel banks. Each has a T1 interface and a 50-pin telco ("Amphenol") connector for a punch block. So we can run 24 channels off each of those. Our consultants (see below) suggested getting them used from Colspar Communications. We found them fully loaded with FXS cards for $250 each. We bought three -- two for production use and one for a hot spare. These are very solid and nice units. The only problem we had is that the voicemail indicator lamps (MWI lights) on our old analog phones wouldn't light up. Turns out that Asterisk with a T1 channel bank uses digital FSK lamp, whereas our older analog phones expected a certain line voltage to indicate messages waiting. After some Googling, I found add-on FSK lamps from American Science & Surplus for $1.50 each. Nice. In our other building, we have a gigabit fiber-optic link, so we purchased an AudioCodes MP124 SIP-analog gateway. It's working well so far, except it's not working with voicemail indicator lamps at all. It seems to be a firmware issue that is incompatible with Asterisk in some way. We're investigating now. For wireless phones, we're using the Hitachi IP5000. We're not terribly pleased with the quality of wifi phones in general, but this one seems pretty solid. And it doesn't crash every few minutes like the Zyxel model we tried. The Telco Our current phone system has about 23 analog lines for interaction with the outside world. We wanted to get a voice T1 with PRI channel for the Asterisk system. Our local telephone company is Sprint, and this has been the annoying part. First they tried to quote us an Internet connection. Then it took a very long time for them to even get us a quote for the voice T1. And now we have signed the contracts but are still waiting for an install date. Consultants While I had used Asterisk before, it was in a home setting. Not exactly business-critical, and not dealing with hundreds of extensions, T1 lines, and all the rest. So it seemed reasonable to get someone experienced with that sort of thing to help us out and make sure we weren't making mistakes that would cost us down the road. I posted on the asterisk-biz mailing list describing what we would like to do. I got a bunch of supplies from consultants, and we wound up selecting Asteria Solutions Group. At the beginning, we wanted some advice about server sizing, phones that work well in business settings, etc. I think that most consultants are not used to working with people that have significant Linux experience, and a good deal of Asterisk experience, already. Asteria was a little surprised with our situation at first, I think, but has been very helpful. They've educated us on the ins and outs of T1 technology, pointed us to Colspar (which saved us a ton of money on analog gateways), and helped us with some obscure questions. They were also fine to have a much smaller involvement with our project than they would probably normally have. I highly recommend them. Surprises You'll never believe just how hard it is to buy phones from Polycom. They won't sell directly to people, nor will they even list authorized retailers on their website. You have to call them, leave a message, and in a few days they'll let you know where to go. Some online retailers such as atacomm sell Polycom phones, but they're not authorized to do so, so you don't get any warranty or have the right to get firmware from Polycom. What's more, Polycom usually expects people to need configuration assistance with their phones. But I think that when I told them we need 90 IP-501s, had already configured 5 on our network, and needed no assistance, they were happy to work with us. Reactions We've deployed desk phones all over by now. So office workers have two phones on their desk right now (one from the old system, one from the new). We've heard a lot of positive comments from people about the new phones. And all the features of Asterisk -- music on hold, flexible queues, etc -- will be really helpful here. Cost Even with the cost of all new phones, new CAT5 runs and labor for that, consulting time, etc., we still expect Asterisk to be far cheaper than the latest Nortel PBX. Also... I recently wrote an article about Asterisk for Free Software Magazine. I'll let you know when/if it gets published.

Earlier this week, my cousin, who is a medical resident in New York City, came to visit my office in Downtown Boston after work. After giving him a quick tour of my office, we thought we’d chat over a cup of coffee. I’m not aware of any locally-owned downtown cafés or coffee shops, so we thought we’d have to settle for a Starbucks. The Starbucks across the street from my office, however, had just closed at 6pm. Although I’d been to the Peet’s Coffee around the corner dozens of times, it wasn’t until I actually tried to go there with my cousin that I realized that they don’t have any seating. We attempted to go to five other similar venues, and they were all either closed or without seating (including an Au Bon Pain right near Downtown Crossing that just has a walk-up counter). Finally, we settled for a Dunkin’ Donuts that had two tables and was open for another half hour. The staff were busy mopping up and listening to a loud radio that was half-tuned to pure FM static. I realize Downtown Boston isn’t the most residential area, but aren’t there other people who want to meet up after work at some place other than a bar? Isn’t this supposed to be a world class city? What about all the luxury condominiums that have been built recently in walking distance to the financial district… is it all a fiction? It’s times like this that I have to admit feelings of New York envy.