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.

Nothing stunning, given my preferences. I would have expected Enterprise D, but well, I guess those two are just two similar. I never saw Babylon 5, Firefly, Farscape, Cowboy Bebop or Battlestar: Galactica, though. You scored as Nebuchadnezzar (The Matrix). You can change the world around you. You have a strong will and a high technical aptitude. Is it possible you are the one? Now if only Agent Smith would quit beating up your friends.

Enterprise D (Star Trek)		75%
Babylon 5 (Babylon 5)		75%
Nebuchadnezzar (The Matrix)		75%
Millennium Falcon (Star Wars)		75%
Deep Space Nine (Star Trek)		63%
Serenity (Firefly)		63%
FBI's X-Files Division (The X-Files)		63%
Andromeda Ascendant (Andromeda)		56%
Moya (Farscape)		56%
Bebop (Cowboy Bebop)		56%
Galactica (Battlestar: Galactica)		38%
SG-1 (Stargate)		38%

Your Ultimate Sci-Fi Profile II: which sci-fi crew would you best fit in?

In m³’s online pamphlete, I found a new quiz I immediately had to take:

Which sci-fi crew would you best fit in? Before taking the quiz I already wondered which possible answers it offers and what I’d expect as result. The only thing I knew so far was that The Matrix was featured in the quiz since m3 scored as Nebuchadnezzar. Farscape came to my mind. During the quiz some of the questions seemed quite obvious on which crew they would count resp. not count. Since I don’t like military, I knew that Star Trek crews won’t be on the top of my list… Well, it seems as if had guessed quite well:

Interestingly the Enterprise D from Star Trek TNG is also in the list and not that far down as I expected it. So there seems to be at least a slight correlation between what SciFi series/movies I like most (Farscape, Star Trek TNG and DS9, the early Star Wars movies, The Matrix, Babylon 5) and with which crew’s philosophy I agree most as well as which ships appeal most to me (Millennium Falcon, Moya and many ships from B5, TNG and DS9) and vice versa: I’m not that big fan of Battlestar Galactica nor Star Gate neither do I like the design of the ships showing up there. Another two things I noticed by this quiz: I should perhaps once have a look at Firefly which I haven’t seen yet nor do I know much about it. And I probably won’t find Cowboy Bebop that appealing if I would watch it once. BTW: Series I missed in the list: Star Trek TOS, SeaQuest DSV and Futurama.

From the Shared File Metadata Specification on freedesktop.org:

The only requirement for metadata names is that they are unique and do not overload or cause confusion with each other. To make this possible, all metadata is namespaced by an appropriate class based on the type of the file or the application name (if the metadata is application specific).

What isn't confusing about having all of the following metadata types:

• File.Description
• Audio.Comment
• Doc.Comments
• Image.Description
• Image.Comments

Another stroke of genius flaw is File.Accessed (and so on): Last access date in format "YYYY-MM-DD hh:mm:ss". What timezone is this in? EXIF made this mistake, and it hurts. Why this specification didn't soak up the years of work done by people on RDF, Dublin Core, EXIF-in-RDF and so on, I don't know. NP: Sounds From The Verve Hifi, Thievery Corporation

Well, the shiny new toy (toshiba portégé R200) is now working nicely - I've got toshset working (thanks to some pointers from Noodles and in particular his blog posting about the R200. Turned out that the ACPI patch still needs applying, even to 2.6.16rc2, but after doing that I can now turn on and off the bluetooth, and mess with the lcd brightness and all those type fun things. Whee! I suspect that I should get the Fn keys to work sometime too - ohh, at least one of them already works! The one that switches to an external display. Hmm. Would be nice if the brightness one worked, but it's not exactly hard to use toshset for it ;) Hmm, impressively, it's still quite readable with the brightness turned down to 1 of 7 :) *bounce* - loving the new toy - the only issue that I've had so far, really, is that \ is over to the right of the spacebar - otherwise things are more or less where I'd expect them to be, and now that I've got Synaptics configured, I have my scrolly touchpad of doom and the world is a good place.

It's maybe a little fashionable to use terms like "information overload" and that all our technology is making us less productive. I'm starting to buy into this theory a little more though. I'm having a lot of trouble keeping myself focused on any one task for an extended period of time. I constantly jump between task A to task B to check email C, making a little progress here and there, but I think I'm hurting myself with all these context switches. I can't seem to stop myself anytime I have to wait for something (even very briefly), my focus switches to something else.

The most problems are at work. Now I'm fairly sure the environment has a lot to do with it. It's an open concept type, with a few cubicle walls here and there. People are constantly interrupting me with questions and random conversations can break out frequently. For the most part I really like these aspects, but it can be very hard to concentrate on a task. Home isn't much better though. I have trouble just concentrating on one task, I almost always have a movie or TV going at the same time, and I can't seem to turn it off.

I also have so many half finished projects and good ideas (or so I'd like to believe) that I never get around to getting anywhere with out. I'm really enjoying my classes, but I don't put in the time I should to improve (I'm jealous of mricon's dedication to ).

Do other people feel like this? Does anyone have tips to better allow one to concentrate on a single task at a time, and better follow through on tasks? I mean there are some obvious things I should be doing, but I'm having trouble with those even. Outside the box ideas?

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!

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.

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.

Short update today:

• After getting annoyed I’ve disabled comments on this blog. Sucks, but what can you do to avoid spam?
• I’m being head-hunted. Kinda. Neat.

Actually, "Ruby vs Tcl" is just a dramatic title. I like to think of myself as somewhat of a connoisseur of programming languages, which means I find something to like about most of them. Also, having put my toes in the water by creating my own, Hecl, I have way too much respect for the people that do the work to really pick on any language too much. However, comparing and contrasting is fun, as long as it stays productive! I'm a long time Tcl fan, having known the language for something like 7 or 8 years. Recently, I've started picking up Ruby, because I've decided to follow the herd and use Rails (which is every bit as pleasant as its made out to be, but more on that another time). Where Ruby shines Coming from Tcl, which has to be one of the most misunderstood languages out there, one of the things that I enjoy most about Ruby is all the buzz. It's a pleasant change from the "trying to hold the line" mentality in the Tcl world. Of course, marketing and the inclinations of 'the herd' are fickle things, and as the Python folks are discovering, what popularity giveth, popularity can take away. In any case, learning a new language is fun and not all that difficult with Ruby, so I'm enjoying riding the wave. Point in Ruby's favor, even though sometimes I'm left scratching my head that it took Rails to convince some of the Java guys that scripting languages really are that much more productive. The other thing that really sticks out about Ruby compared to Tcl is that it's Object Oriented (henceforth known as 'OO') through and through. At the low level, I don't really care too much (puts "hello world" is valid Ruby and valid Tcl), but Ruby's OO is nice for organizing more complex data structures. Tcl has OO as well. Actually, Tcl has several, competing OO systems, which is a classic case of "choice is not good" because none of them is standard and something you can count on being present. Also, most of the Tcl object systems don't do a great job of deleting unused objects. I don't suppose it would be that hard to add that if there were one good, standard one. Luckily, such a beast is on the horizon, but it's awfully late for a language that's more than 15 years old. Point goes to Ruby. Ruby also wins in the 'available libraries' department, although probably not by that much, being relatively new to popularity. What Ruby really has going for it is that: 1) The standard distribution is pretty big, with lots of good stuff, an approach that the Tcl world hasn't taken. This means that Ruby out of the box does a lot more than Tcl. 2) Via Ruby Forge and the gems system, Ruby is attempting to centralize and standardize the distribution of extras, something which Tcl has never really managed. Things they both do well In terms of community, both languages seem pretty well off. The Tcl newsgroup, comp.lang.tcl, is one of the friendliest, most helpful corners of usenet, and reflects very positively on Tcl. I'm newer to Ruby, but by and large, they seem to be handling the massive influx of new people with aplomb, and without much, if any, of the snotty "I was here way before you" attitude that sometimes crops up in these cases. I'd call it a tie. Both languages are very flexible, but in different ways. They both support 'eval', and let you do all kinds of nifty introspection. I fear I don't know Ruby well enough to come up with a definitive answer, but I Think I'd still give the edge to Tcl, just because of its ultra-simple syntax and command-based style lets you redefine Tcl commands in Tcl itself - and everything is a command, even if, while, and the lot. Like I said though, this is a vague enough requirement, and they are both very malleable languages that you could make a case for "everyone being a winner". In terms of syntax, de gustibus non disputandum est. Ruby has more of it, which can sometimes be helpful. For instance, foo[1] vs lindex $foo 1. On the other hand, Tcl's

array set hash  
    foo bar
    bee bop
 

Makes me reach for the shift key significantly less than

hash =   :foo => "bar", :bee => "bop"  

Tcl's spare syntax is one of the reasons it is so flexible, but for everyday use, sometimes it's nice to have a little bit more. In the end, it's a question of taste, so we'll call it even. Where Tcl is rock solid Here's where the "part 1" in the title comes in. The following are things I don't care for in Ruby, but since I'm new to it, there's the chance that I'm missing something in these observations. Interpreters. Tcl lets you handle multiple interpreters not only at the C API level, but in Tcl itself. This is really cool - you can juggle different people running different scripts in your application, without them stepping on one another's feet. If you want, you can let them share stuff, too. This capability has also been extended to provide safe interpreters for the execution of untrusted code. Ruby has safe evaluation too, but it's not in a completely separate context, so it's just a different way of doing things, but still, I like the idea of having and being able to manipulate multiple interpreters. Tcl wins hands down. Event oriented programming. Tcl really shines here, as it's possible to create simple, fast servers without actually having to muck about with select yourself. The python folks have caught on to this with Twisted, and I suspect that Ruby will too, if it hasn't already and I'm simply not aware of it. Note that Ruby has a select call as part of the language, but what I'm talking about is being able to whip up servers in a few lines, without even needing to require any external modules. Modularity is an area where both languages could do better (well, at least for some users/uses). Both languages might be interesting in the embedded arena, but it takes some effort to cut them down to size. In Ruby on the Mobile, Matz himself states that this isn't an easy operation. Tcl is notable in that it has some small footprint implementations like Jim, but the core language would require non-trivial hacking to remove some of the bits and pieces that are 'welded on'. A few nitpicks about Ruby: no deep copy - you have to marshal/unmarshal, which feels wonky to me. File.split functionality is just dirname/basename rehashed, rather that Tcl's more correct/useful splitting of a path into a list of all its components based on the current platform's directory separator. Threads are another area where Ruby, at first glance, at least, could probably use some work. Tcl has real, OS-level threads, which are very easy to work with because each one gets its own interpreter. Because of this, they almost feel like separate processes, but of course, if you need to, you can do all the sharing and mutexing and so on that you need. Conclusions So, what conclusions can you draw from this? Well, they're both fine languages, and are more than likely capable of doing most anything you need. Something else that I was pleasantly surprised by is the fact that Tcl, despite its age, and its lack of buzz and O'Reilly/Web 2.0/the hot new thingness, still has a lot to show the world, and does a lot of things right, out of the box. It's also worth noting that most of the problem areas for Tcl are social, rather than technical, and could have been resolved easily/avoided with the right leadership.

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.

I’m back from Chemnitzer Linux-Tage (CLT) which were really great. The CLT organizers really know how to make an event for the community without forgetting the business people. So, although Murphy hunted me with forgotten laptop power supplies, forgotten laptop power supply power cords (Thanks for the spare, Venty!), missed trains, late trains, unfitting train schedules, defective mobile phones (Hi Sven! :-), heavy snowing, addictive Play Station Portables and no time for attending a single talk except mine (I’m sorry, blindcoder), I held all three talks as planned — maybe except the duration — and had a lot of fun as expected. The slides for my commandline beginner’s talk on Sunday were finished the same day at about 2am and are online since then. It was too long, but except the next presenter (Hi Werner!), nobody told me. I even thought that all those people entering the room were late listeners. I just didn’t notice at all that time was flying by so fast, since there was a lot of interesting discussion with and in the audience, something I didn’t expect from a beginners talk. Thanks to all who already gave feedback to my talks. And thanks to Sven Kühnel and Hendrik Heigl with whom I could drive back to Frankfurt.

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.

A friend of mine with a 10 year old child wants his son to play less online Role Playing games and learn programming. In this kid’s free time, all he does is play computer games. At that age I was probably the same, though what made me a “programmer”? My friend is so frustrated with his son’s constant game playing, that he has limited his son to use the computer only in the weekends. I found this quite surprising, but I think I can understand his concern. I remember not coming down for dinner, because I wanted to play BRE (BBS door games) with my friends instead. Thankfully my Dad never threw out my computer out the window like he swore he would do at times. :) So now, my friend suggests that perhaps we could teach his child something about programming. Perhaps a whole group of kids. All armed with laptops. But, when I was that age, I don’t think I was very interested in programming for the most part. I had to be forced to write some logo and turbo pascal for school. And looking back at it, logo and turbo pascal seemed so much easier than the complex and multi-layered APIs (Web) I work with everyday. Ok, I do remember being enthused about:

• demoscene
• LAN parties with doom2 and quake

But both of these cultures seem to be on the decline. Or perhaps I am just out of touch? During boarding school I actually stopped having access to BBS/Internet so I didn’t really touch a computer throughout my A-levels. It was only at Bath University where I found myself, almost surprisingly, taking a Computer Science course I learnt about Unix et al. So I started learning Computer Science at University. I think people in Korea are surprised when I tell them I hardly knew about computers before I joined a Computer Science course! ;) Ok, so without driveling any more. Here are the questions for you to say your bit in the comments.

• Do you think it is worthwhile to teach programming (Computer Science) to a child?
• How can we get kids more excited / creative about computer science?
• And how should a parent deal with computer game addicted kid?

It would be great to teach on Plan9 or something simple, but I think kids would be more interested in graphics and sound. Bleh…

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

Google Blogsearch suffers a lot from having old or bad data (including spam) in it. I have the impression that they are waiting for new pings by blogs who have pinged them before - but when deleted, these blogs won't ping them any more. With pretty much any search term, I've found spam entries in there. :-(