Karl Fogel's Producing open source software: how to run a successful free software project covers many of the important aspects of free software projects, and concentrates on the parts that are different from, say, traditional in-house development projects. The book covers technical aspects like mailing lists, bug trackers, version control systems, and other infrastructure necessary for a project to survive. It also covers more social aspects, such as how to deal with flames, forking, or how to employ developers for free software projects. The book is written well, and is a light, fairly quick read. Those of us who have participated in free software for a long time can find the book as a nice summary of things that have been learned over the years. Those newer to free software development may find many new things to learn. Most of us will find something to think about. Despite the level of detail Fogel gets into, the book obviously only scratches the surface. Free software development is such a vast new territory that it is not realistic for one book to cover all of it. For example, this book does not cover conferences and other face-to-face meetings, which are important for keeping the community of free software developers alive. With the caveat that it doesn't make further volumes on this topic unnecessary, Fogel's book really is worth the time it takes to read it. Recommended.

I dreamt that, I wanted that since ages, and W3C is finally agreeing to consider it: maybe one day in CSSv42 we will be able to specify a width in CSS as a combination of a percentage and a fixed width. That would just be sooooooo cool ! Through <Glazblog/>

As this year is going to be the year of computer science (or rather, Informatics) in Germany, and most of the money for it has already been spent (it all went to some PR agency AFAIK), some students are planning to organise a bit of a roadshow that will demonstrate simple topics to interested audiences. For example, we are going to show different sorting algorithms by ordering ten volunteers standing in a row by their first names, and talk a bit about complexity here, and I'm trying to rehash my crypto talk into something with more theory that is still less dry than it is currently (probably with a bigger focus on PKI).

We're 10 minutes late, most of the trains are cancelled, if we miss the next one, there will be a forty minute gap, and all the bus driver cares about is our tickets.

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

Today I've rewritten most of my "laySVN" layered subversion tool. Tests had shown that most of the time was spent calling the "status" command of the underlying subversion client. This is probably due to locking, and the workaround is pretty simple: avoid calling it on single files, instead run it on the whole repository at once. This of course requires major changes to the code, so I've started a rewrite. I've already applied for a alioth project for it, I'll make the source available via svn.debian.org soon. "Layered subversion" means that you basically checkout multiple subversion repositories on top of each other. A file found or ignored in an "upper" layer will not be checked out in lower layers; ignoring a file in a layer will effectively "hide" it if it were in lower layers. This is an interesting alternative to branching. In branches, you have to "carry forward" changes from one branch to other branches. The base case - merging changes from a "lower" layer into an "upper" layer is usually quite easy. The other direction can get quite messy however. Assuming that multiple files were modified in the checkout, how are you going to commit these changes to the correct branches? Basically you'll have to commit the files to the correct branches, then do the merging magic. Along comes laySVN, where this common usage pattern is much easier. Changes will automatically be committed to the highest "layer" the file is in. A checkout will update the file to the version of the "highest" layer. The only case which is a bit more complex is when you want to make changes to a file on a different layer. Then you actually have to "add" the file to the appropriate layer. Not really difficult either, is it? A different name for "layered subversion" would probably be "difference branches", which are very similar.

David writes that, while momentum is a very good way to keep flames away, it's really solidified by proper code of conduct. I don't disagree with either of these positions, but they're both characteristics of a good culture that enables things to get done in a productive atmosphere, rather than the causes themselves.

One of the problems is that you can't enshrine, 'don't be a tool' in a code of conduct. Yes, you can legislate away personal attacks, so there's no more Serious problems with Mr. Troup, but it's still entirely possible to completely subvert the development process while still remaining within the bounds of any particular code of conduct. The key here is that the code of conduct is just a rough guide to, and a method of enforcement of, any given culture that you wish to enforce.

If you want to change Debian's current developmental culture, you'll need more than just a document: you'll need a landslide mindshift within the entire developer base, which will be extremely difficult to achieve, given that some particular developers seem to champion their lack of social skills, delight in annoying others, and glorify petty arguments on mailing lists as being superior to actually achieving anything. When you get this, the code of conduct is really just fluff, because it becomes almost entirely self-enforcing. The general tone of the list and attitude of the developers discourages people from being idiots, and you don't have to point to the code of conduct except in serious cases.

So that's the really hard part. Debian has a destructive culture that has led to debian-devel and debian-private becoming the pointless landfill it is today. Which is no slight on Debian developers as a group, or any particular developers; it's just the way it is today. How it got that way is entirely unclear, but how it's going to move on from there is an equally perplexing question.

And, in response to Joss, the two go hand in hand. Once you've stopped arguing for the sake of it, you're infinitely more productive as a result. So I don't think calling people advocating change in Debian's social norms 'teletubbies' is at all useful: these people aren't advocating turning Debian into a sewing club where we all turn up and talk about how much we love each particular developer. What they're advocating is change of the current Debian social culture such that trainwreck threads full of personal attacks, mindless bitching, and argument for the sake of it, don't exist anymore. You can have robust debate within that framework, and you don't have to completely vet every statement you make so it's a glowing reflection on everyone and everything mentioned. If you have the right culture, you can simply tell trolls once to go away, and they get utterly ignored, instead of having their threads blown up into huge all-consuming flamewars by people who seem to love seeing their name in the mailing list index. I don't see how you conclude that any hypothetical code of conduct exists purely to facilitate trolling either, but maybe I'm missing something.

The current problems in Debian with people being unable to relate to fellow developers, so instead getting bored and flaming them into the ground instead, isn't a techincal problem in the least. It's a social problem. The entire point of this debate isn't, 'which MTA should we install by default, if any', but 'how do we fix Debian's current culture?'. I don't see how this is a technical problem, but it does have technical ramifications (e.g. releases take years of banging our collective head against a very large wall).

Josselin Mouette thinks name-calling makes his point. I quite disagree. His approach does nothing to make Debian better; in fact, it only serves to reduce many people's interest in working on Debian at all. David's point about development momentum is very good. I completely agree with it. I sort of started on this line of thought in my DPL platform draft, although David took it further and said it better. Momentum can only be increased if the people involved are having fun; they will have fun if momentum is increased. If something prevents development from gathering momentum, or saps the fun out of working on Debian in some other way, things fall apart. For quite a number of people, flame wars are fun suckers. "Stop energy" sounds like a good term to me. I'm talking about flame wars. I'm not talking about discussion, debate, or disagreement. It's perfectly possible to have those without getting actively aggressive, passively aggressive, repeating your opinion 75 times per day, resorting to name calling, or employing any of the other charming tricks that Debian mailing lists see. That's enough talk, and enough attention paid to bumps in the road. Time to enhance my tools so that I can find and fix all the remaining bugs in Debian.

Josselin, I agree with you in theory, but the problem is that heated technical discussions quickly turn personal. debian-x is one shining example of this, where the previous fighting was over whether to polish and bring out the best possible packages we could or to push hard to get the newest releases in, which while not being as well done would get people support for new hardware. Fundamentally, this is a technical debate, but it turned very personal over time and the team still bears these scars. This has also happened in incredibly ugly ways on debian-devel, with vile threads from the past like "Serious Problems With Mr. Troup", which is about as personal as you can get. The Vancouver thread also took very serious personal turns as well, despite it beginning as a necessary discussion about the release process.

Momentum is critical for minimizing these kinds of debates, but it's not foolproof. I think a code of conduct along with people who are trusted and willing to enforce it will provide an extra layer of protection against this problem. Yes, I definitely agree with you that technical solutions and hard work are the critical things. It's critical to have technical solutions to technical problems, and these should always be the first priority for Debian. But a social layer of a mailing list code of conduct, much like our social contract and the DFSG, will provide a non-technical solution that can help guide us when things get ugly. I, for one, never want to see another "Serious Problems With Mr. Troup" thread.

David, you are perfectly right: momentum is what makes the fun. However I completely disagree with your conclusions. Trolls won't stop if you tell them to stop; a code of conduct doesn't help more in this matter than arguing calmly with them. You have to show the code. If debian-x has been free of flamewars last year, just like is e.g. debian-gtk-gnome for a place that I know more, it is because it is now a place dedicated to make things better by actually getting the work done. When the software works, nobody is looking for stupid ways to get it to work better. In other words, when technical solutions come up for technical issues you don't have to look for social ones.

What I call a teletubby is a person who is repeatedly saying we should just be kind, and everything will be fine, and flowers will grow, and Debian 3.2 will rock. If you want to see what is a teletubby, just read Andreas' platform. But there's only one way to make our next release rock: to work on it. Harder and better. People promoting the code of conduct are just teletubbies as well. Having a code of conduct doesn't change the contents of a mailing list, only the wording ; and in Debian, we can be sure it will just serve as an excuse for more trolling. Trolling about the code of conduct itself, trolling about whether this or that person is going against the code of conduct.

In Debian, the winning solution isn't the one discussed on mailing lists; it's the one getting implemented and used. Coming up on a mailing list with advice, ideas, or telling other people what to do doesn't bring anywhere. In the end, the only thing that counts is the code. Mailing lists are for people looking up for advice to start with, or for information. Anything else is just troll. You can zap those threads and won't see any difference.

I'm writing this from my shiny new Portégé laptop - it's currently just PXE booted with an NFS root from my other machine - but that will all soon change - now to backup the windows partition to something and then nuke it all and get debian on here properly! Wheeeeee!

I am a little disappointed with the new Thinkpad X40 I have from work. I wanted a MacBook Pro, but their availability and price in Korea is bad. Unplugging the mains leaves me about 2:30hrs. That’s almost the same as my personal T30 machine! My T30 has about 2 hours of battery life, although it also has about twice the CPU power (going by Bogomips)! If I do processor intensive stuff like compiling and watching videos then we can half those times… (!) My T30 also has better wireless performance after my little tests. I’m also wary of this little X40 keyboard. I don’t think it’s good for my RSI. Though it’s too early to tell. You can get a bigger battery pack for the X40. But it will probably be expensive. :/ The X40 is brand new and is branded IBM thinkpad. The build quality is excellent, just like my other thinkpads I’ve used. It does say “Lenovo” on all the copyright stickers. I whipped out the hard drive and I thought I might upgrade to a quieter Seagate Momentus. I was surprised to see a 2” drive that was about half the height. I didn’t know about this form factor! I’ll miss my T30’s roomy 100G. It was tricky installing Debian without a CDROM. I managed in the end with an external USB hard drive and my experiences are documented in debian-boot threads starting here and here. One major redeeming thing about the X40 is that I get 18371880.31 bytes/sec compared with the T30’s 959174.47 bytes/sec for USB throughput. That’s an amazing 20x speed up! So I’ll be using external USB drives to compensate for the tiny 30GB hard drive. I am giving away my old T30 to my sister. I just wish the X40 fealt a little more like an upgrade from the T30. The X40 is my workplace’s equipment after all. I think I will aim to get a Mac Pro still if I visit Japan in the next weeks for myself.

I've had the same mouse for probably 5 years, and I'm very happy with the result. Unfortunately, the batteries don't make good contact with the pins anymore and sometimes it takes ten minutes of delicate work to get it going again. So today, I went to buy a mouse, and surprise, surprise, I had forgotten how much it sucks to be a left-handed when purchasing certain objects. At the computer store, there were about 25 different mouse models, most of them featuring extra buttons, ergononic shape and other cool stuff. I was ready to buy something for even more than 20 if it was worth it, but due to the non-simmetrical shape of most of them, again I could only go for the cheapest models. I took a Creative optical mouse, and downgraded from a cordless mouse with 5 buttons + a wheel to a plain simple 3-button + wheel. At least it's USB... all the low end mice are still PS2. When I was looking for a laptop, one of the requirements was that the touchpad wasn't slightly displaced to the left. So right-handed-ish... I know there are shops with stuff for left-handed. Once, my mother bought me a pair of nail scissors designed for left-handed people. All that kind of stuff is generally very expensive and anecdotic, though. I wonder if we'll ever see laws that will force manufacturers to provide inverted items on demand. I want one of those cool mice.

Via Luis, I really like this article. Debian has become way too corporate in a lot of ways it seems, and many of us are forgetting what it's like to try and do something daring. It's one of the reasons I find aj's DPL platform compelling, even though he hasn't said how he's actually going to encourage a faster tempo. People got really excited when I simply updated Debian's X packages to the latest upstream version. Granted, this is cool, but it's far from the exciting stuff I'm looking to do once we're finally caught up with upstream for real (almost there!) It doesn't have to be revolutionary or anything, but I want the XSF to be a center for exciting things to happen. Unfortunately, the most exciting X stuff is happening everywhere but Debian right now, despite my best efforts to open it up further.

And while I share helix's hate for the term "stop energy", the vast and deep flamefests that periodically consume the project really do seem to slow down our development noticeably when I just look at daily changelogs in sid. Julien may call me a teletubby for this (a metaphor I loathe for its utter stupidity) but debian-x has been almost 100% free of flamewars for the past year or so since I came on, and we've gotten a remarkable amount done. Contrast that with the previous era in which the fighting seemed to sap the will of the most productive and capable members of the team, all of whom seemed to focus much of their energy elsewhere as a result. While I think a mailing list code of conduct will be an important step in achieving this effect project-wide, I think a more fundamental solution is for individuals to attempt to build momentum themselves. Momentum like what I've tried to build with X seems to stop these energy-sucking flamewars dead in their tracks, and makes the project seem like a lot more fun place to be. I know that with all the flames going on with ndiswrapper and such I've been able to retreat in to XSF-land and find my happy place and be productive.