I think it's time to start blogging more often about this topic, and fill this section a bit more. I mean, Mermaids was a long time ago... And debconf in Mexico with my first try on skirts, getting rid of my beard and dying my hairs red is history in the meantime, too. So, what has happened in between... Well, there was of course the Regenbogenparade which I attended and which was nice. I even ordered a special t-shirt from a shop in Australia that I totally love. In summer I met up in Bratislava with a longtime friend from a MUD I played way back, and enjoyed running around in a skirt there, too. Gladly it was a sunny day. It was though... people back here in Vienna looked more awkward at me than in Bratislava. At least that was my impression... Had been to Extremadura for the i18n meeting which was quite nice. It was quite productive, even though I have to admit that I haven't done much on that front since. Even in Spain people didn't look that strange at my skirt as over here in Austria... At our company's Christmas party I got into a talk with a work colleague about the topic and she informed me that a former working colleague of us is starting with hormone treatment after the year change and if I'd fancy a meeting with him. I was quite happy about that offer so we arranged a meeting on December 23rd. It was a bit strange at first to address him as he, and we didn't know how to start talking because said working colleague was late, but after a while we talked about various things and even were finished with the more interesting topics when she finally appeared. We arranged to visit the next Trans-X meeting after the year change.
I left them for leaving home, but I wasn't able to catch my bus on time—the subway had serious problems. Well, I thought I might spend the night in the Flex so I called another working colleague who usually hangs out there about what was going on that evening, and interestingly he told me it was Gay Heaven night. I stopped believing in coincidence long ago... Anyway, was a nice evening all in all, they had a Christmas rabbit handing out "I love you" stamps with pink ink-pads. :) The Trans-X meeting wasn't too bad. It was some discussions about various topics. After a while my first shyness dropped a bit and I started to join in the discussion at some points. After the first started to leave I had some more direct talks with two of the women from there, one of them had mostly the same trip home as me so we talked on in the subway. A week later they had set a transgender weekend—no wonder, it was the weekend of the Rosenball. They were meeting in a cafe on Friday and I joined them, a bit less shy now that I at least knew some of the faces. Maria was quite ill and was sitting in her jacket within the cafe, shivering like hell... But all in all it was a nice meeting too, got to know some more nice people. I was a bit lazy from there on, didn't join another meeting... But another working colleague did invite me to the carnival party of his sister. I thought I could try a bit more than before, in the disguise of the carnival party, so I used a bra my former wife left behind, filled it with some socks, and put up some eye makeup (quite discreet, I hate overdone makeup already on natural females...) The light there wasn't the best, so they just saw my tall body at first. It took them a while to even notice the skirt, and only after I put off my long-sleeve they haven't noticed my breast. But well, I don't really blame them, my working colleague has announced me as a he, and given the low lights it's not too bad. Though, after the host noticed my breasts he asked if he could touch them and I even received a quite nice kiss from him. :D I stumbled upon the Gaia TG Guild on Gaia Online—a quite interesting web-based community. In general Gaia is filled with mostly kids, many of them immature, not able to spell and considering that even cool, but there are some quite special guilds that are lots of fun. But still, when I stumbled upon the TG Guild I was in awe of that such a thing could exist there. What I read made me feel totally happy and more confident on the path I'm having ahead of me. Last week I finally had been to an Trans-X meeting again, and Maria showed some quite interesting reportages about transsexual people—including one that was on TV just the day before about a 14 year old girl who is already on hormone treatment and has the absolute support from her family since she was 4 and confronted them with cutting "it" off when they don't allow her to wear skirts when going out, too. All the best to you, Kim! I so envy your strength... I'm sorry about the length of this entry—but I'm sick of people who tell me that I'm only playing it, or that I would hide... And I also see it as a chance to document my path for myself. I promise—the next entries will be more often and thus shorter.

Verizon has apparently decided that BOTH of my forwarding addresses, dburrows@debian.org and Daniel_Burrows@alumni.brown.edu, are actually spammers, and is randomly rejecting some emails sent to them. I have given Verizon as large a piece of my mind as they allow: they do not provide an email address, and instead put up a form where they graciously allow you to type a 70-character (!) message. This will presumably go straight into the bitbucket, but we'll see.

If you want to email me, please send mail directly to Daniel_Burrows@verizon.net.

Does anyone know of a broadband ISP serving Redmond that doesn't suck? As far as I know, my only alternative to the telephone monopoly is the cable monopoly.

[Note: I wrote this more than three weeks ago, but due to me being lazy again (yeah right) I’m just publishing this now. Well, here goes:] Due to a project working on (in Perl,) I’m asking the great Lazyweb for their great insight into the problem of sending outgoing mails. It all started when I was trying to set up my own mail system on my laptop perlis. After months of doing most of my mails under GMail and finding it impressive, but not quite adequate for my needs, I decided to go back to my old desktop workflow of downloading all my mails using ESR’s fetchmail over IMAP, and using my preferred MUA (Gnus, in this case to write my replies/posts/spam and send them using an MTA. However, since the time I’ve been checking my mails on revan, the amount of mail that I have been receiving has gone up to less than manageable proportions for my old system, so I had to revise my way of getting my email fix. Ultimately, I went on to use John Goerzen’s offlineimap to synchronize my IMAP Maildirs locally and do my mail stuff from there. No problem at the receiving front. On the sending of emails, I ran to a slight problem. I used to use an MTA to relay my mails to a smarthost for delivery, but since things have changed a bit (new ISP that blocks port 25, for one I have to find some other means. Although I could probably configure my MTA to use (and authenticate to) a smarthost, I found that approach to be too heavy for comfort (even when using a special-purpose MTA such as masqmail.) Furthermore, I’d like to have more control on how I send my mails (like which mails using one of my email addresses should go to a particular smarthost.) So, here is my attempt to solve my problem: a small, user-configurable mail submission agent. It small because it is written in Perl, and makes the most out of it (being a Perl user means you gotta love CPAN It’s user-configurable, involving a small INI-style file in the user’s home directory (I would prefer, however, to do away with tinkering with config-files altogether and do all configuration via some friendly interface.) It’s not much, but it works. And it’s working for the past three weeks or so now. I call it kartero because its the Spanish-Filipino word for postman (and yes, that’s exactly what my program does. It’s not much, but you can pick it up and try it yourself. Complaints; violent reactions: you know where to send them.

Today my dad send me an nice email :) So… yes Linux is sexy ;-) I have only one problem with this:

Today my dad send me an nice email :) So… yes Linux is sexy ;-) I have only one problem with this:

Life sometimes goes in a funny direction, like a full circle d j vu: 20 years ago, I was studying Technology of Computerized Systems (a combination of electronics and programming). Now, 20 years later, I'm starting a dream job as the Business Development Manager of Artec Group and their core business is you guessed it exactly that. The really cool thing about Artec, from a Free Software advocate's point of view, is that they contribute firmware and drivers for their products to LinuxBIOS and the Linux kernel. At this point, my initial tasks will focus on marketing and selling Artec's flagship OEM product, the ThinCan. What is the ThinCan? Actually, you're already familiar with one iteration of the product: the Linutop is a branded ThinCan, delivered with a custom hardware configuration, plus custom casing artwork designed by Fr d ric Baille of Linutop SARL and loaded with Fred's favorite Xubuntu configuration. In the Linutop's case, their business model is to fill the market niche for a simple Internet surfing platform that fits 80% of average people's daily computing needs, so the hardware configuration they ordered reflects that. Still, as several readers of this blog noticed, the "Linutop" could make a fantastic thin client and, sure enough, that was the main purpose behind the ThinCan's original design; it sells well in the Fortune-500 market as an RDP client running under Windows CE. However, until recently, there simply wasn't much demand for a contemporary X11 terminal solution based on the ThinCan. That is, until LTSP took off, thanks to the contributions of Edubuntu and similar educational Linux distributions. Sure enough, someone spotted the opportunity and contacted Artec to order a branded ThinCan iteration with Etherboot and PXE support, which they call the Linuterm. By the way, for those who need a really cheap OEM thin client, I've got a great spring clearance offer for you:

Artec has about 500 pieces left of their older DBE60 ThinCan model, based on the AMD Geode SC2200, and we're selling them at 100 euro / piece, plus VAT and shipping.

The DBE60 is configured with three USB 1.1 ports, one parallel printer port, one 100baseT Ethernet port, one VGA port (up to 1024x768 @ 16bpp 60-85Hz or 1280x1024 @ 8bpp 60-75Hz) and one 1/8" stereo audio output jack. Its BIOS provides Etherboot support and its motherboard is populated with 64MB of RAM and 32MB of Stratoflash. It comes delivered with a European AC adapter. The Geode SC2200 is fully supported by the Linux kernel with the sole exception of a missing ALSA snd-scx200, but this could easily be ported from AMD's deprecated OSS driver and X.org support is provided by the "nsc" driver.

Minimum order size is 10 pieces. Contact me via my full name (unaccented, with one hyphen and one dot) at artecgroup.com quoting this special offer.

PS: someone was asking if that DBE60 special is also available in the aforementioned Fortune-500 configuration. It indeed is: add 16 euro / piece for the Windows CE 4.1 license with an RDP client.

I took this photograph last weekend at Consuegra where we went to observe the night sky, just for fun, as we used to do. I'm sure you don't need to be told that Polaris and Ursa Major are the start on the left and the constellation on the right side. And that's why I am not telling you ;-)

Anyway, the interesting thing for me here is the effect of the Earth rotation movement. Polaris is said to be in the Earth rotation axis prolongation (it is also said this will change with time, a lot of time indeed). But, by now, for us, it can be considered a fixed point in the sky: the north point which remains a point in the picture regardless of rotation. Every other star appears as rotating around Polaris, despite the truth is we are the ones rotating. I almost can imagine I see the Earth from outside.

• My “travel” talk suggestion is accepted for Debian Day at Debconf7. See you there!
• How many DDs eat 150 emails for breakfast? Some people on this HTML WG are hilarious.
• Wordpress should be in etch. Thanks for everyone’s input on this.
• The Debian live based Webconverger “browser live system” is BETA! See about Webconverger for more information.
• My Cornwall house sitting days are over and now I need to find a (hopefully debian) contract (my CV) so I can one day afford more travel adventures.

There were quite a lot of small changes in my personal e-mail, web server and DNS infrastructure during the last months. While for more than ten years all my mails came together on a Linux account at the Students Representatives of Computer Science (German: Fachschaftsrat Informatik, short: FS Info) at the University of Saarland and all but one domain was hosted at my former employer, now nearly everything (including this blog) has moved to a Hetzner root server run by me and some friends and running Debian Sarge for AMD64. Most of these moves happend divided in small steps during January and February this year. Only one move happend a little earlier than expected: Without any notice all external mail to my FS Info account got lost in a black hole one hop in front of the FS Info mail server. It looks like the RBG of the Dept. of CS at the University of Saarland didn’t like my face —eh— mails anymore and just dropped them. No bounces, no notices. Not that I knew them as friendly and kind, but blackholing active e-mail accounts without notice leads to dismissal at other places. They should really go and hear alphascorpii’s BOFH talk. So my long-time e-mail address abe@fsinfo.cs.uni-sb.de is no more valid and any mail there won’t get read or answered. But I don’t mind if you send any junk there, it’s not my job anymore. For luck the hoster of my deuxchevaux.org domain, Internett, which I used for all non-university e-mail, changed the forward within a good hour, so I only lost incoming mails of about one and a half day (which was the time until I noticed the blackholing), namely most mails written to all of my addresses at 30th and 31st of January 2007. If you wrote me around that time and miss the answers, you now know why. The few people I expected mail from, already have been contacted. So for the future, write emails only to abe@ either deuxchevaux.org or — if you can’t remember how to spell that (no, you’re not the only one ;-) — noone.org (“no one” as in “nobody”, not “no. one” as in “the best” ;-) And so since then none of my coworkers can make fun of me because I don’t have root on the box where my mail is received. ;-) One of the moves also gave me the possibility to get “my own” Jabber server, so the time with those two jabber addresses (abe@jabber.noxa.de and abe@amessage.de), where usually at least one had some problems with some gateways are also over. If you want to contact me using Jabber, use abe@noone.org, equal to my easier to remember e-mail address. ;-) So there’s still left to move: web, mail and DNS of deuxchevaux.org and beckert.at (domain of my parents) and my old web pages on fsinfo.cs.uni-sb.de as well as Planet Symlink. And of course the redesign of my web pages, which I’ve planned since more than a half decade… ;-) The infrastructure in my real-life home also changed: My gateway to the world is now a 266 MHz MIPS based ASUS WL500g Premium (which I named “pluriel” after the multifunctional Citroën C3 Pluriel) running FreeWRT 1.0.1 which replaced tryane, an as noisy (power supply fan) as compact Unisys Aquanta CP mini-desktop with a passively cooled 200 MHz Pentium MMX.

The Children’s Online Protection Act, or COPA, requires website operators who provide commercial material that could be “harmful to minors” to verify their users’ age, for example, with a credit card. The statute was immediately challenged as unconstitutional under the First Amendment. A preliminary injunction against enforcement of the law was upheld by the Supreme Court, which remanded the matter for factual development as to whether filters could accomplish the same purpose while interfering less with free speech. (Ironically, the ACLU found itself in the unusual position of arguing for Internet filters in this case.) It was just about one year ago that the Government sought to enforce a subpoena against Google for records of user queries and URLs stored in Google’s database. The court granted the motion with respect to stored URLs but not queries in Gonzales v. Google. It was never quite clear what the Government would really do with the data or why they pushed so hard to get it after receiving what they needed from other search providers. (The U.S. apparently argued Google’s search results would “add luster” to its analysis). In any case, the statute has now finally been held unconstitutional. As Ed Felten insightfully points out, unlike in previous instances where courts have struck down Internet speech regulation, in his opinion, Judge Reed did not provide a roadmap for Congress to try yet again to enact a law that would pass First Amendmend muster. Maybe Congress will leave the issue alone for a while:

Two things make the judge s ruling relatively roadmap-free. First, it is based heavily on factual findings that Congress cannot change things like the relative effectiveness of filtering and the amount of HTM material that originates overseas beyond the effective reach of U.S. law. (Filtering operates on all material, while COPA s requirements could have been ignored by many overseas sites.) Second, the alternative it offers requires only voluntary private action, not legislation. Congress has already passed laws requiring schools and libraries to use content filters, as a condition of getting Federal funding and with certain safeguards that are supposed to protect adult access. The courts have upheld such laws. It s not clear what more Congress can do. Judge Reed s filtering alternative is less restrictive because it is voluntary, so that computers that aren t used by kids, or on which parents have other ways of protecting kids against HTM material, can get unfiltered access. An adult who wants to get HTM material will be able to get it. Doubtless Congress will make noise about this issue in the upcoming election year. Protecting kids from the nasty Internet is too attractive politically to pass up. Expect hearings to be held and bills to be introduced; but the odds that we ll get a new law that makes much difference seem pretty low.

Who of us, computer literate people, is not used to multitasking when working? We are bombed with information from different sources when in front of computer and we try to get the info as soon as it is produced. But this is no the only environment when you made things in a multitask way: I am sure you have tried to cook while you clean or you read Slashdot at the same time, however not the way your mother does (it is not that my mother reads Slashdot, though), who puts on the fire something that is long to be cooked, and then goes for house cleaning. You try to do that almost at the same time in realtime: pity you don't have a core duo brain and body. The problem is that all we think that this way we perform more: "hey! we are doing a lot of stuff at the same time!" You reply the email as soon as it arrives, though you were writing that report your boss asked you in about that issue, and at the same time you can even drink a coffee, and IM your friend about which movie are you going to watch tonight. But this article in New York Times can help you to see that this is not true. As any CPU out there is penalized when multitasking, as it has to change context, the same happens to us, but for our brain that gap is longer. It is not a good idea to try to multitask and at the end not achieve any of the goals we made. Perhaps this is the reason that can explain Debian Etch release delay. Stop multitasking!

Well, obviously this one needs a shorter name. The problem I'm trying to solve here is that SONAMEs, or rather the way they are used today, only handle the issue of a single, fully contained library changing ABI as one of its header files changes. However, libraries do not exist in a vacuum; as a bare minimum, they use definitions for types and alignment requirements built into the compiler, and if any of these changes, so does the library ABI. Hence, the idea of using a single number to denote the ABI is not really sufficient. The correct solution would be to embed all ABI information into the soname (libapt-pkg, for example, uses "libapt-pkg-libc6.3-6.so.3.11" on amd64, which is better but still not perfect). Obviously, this would require massive changes to the build scripts in all libraries and educating all library authors, so it is not going to happen (soon). So, what other options are there? As the kernel ABI (the syscall interface) is supposed to be really stable, we probably do not have to worry about that. So, we only have a problem if there are libraries with different assumptions about each others' ABI in the same userspace program. This can happen in two ways: The compiler changed (as in the case with the recent C++ transitions), or a library that is an indirect dependency of something that also has another dependency (direct or indirect) changes ABI. I've talked (briefly) about the former in an earlier post already. To illustrate the latter, a small example: There is a library, libuseful.so.0 that provides a number of functions, among these: struct complex_number

  float real;
  float imaginary;

 
void complex_multiply(
  struct complex_number *result,
  struct complex_number const *lhs,
  struct complex_number const *rhs); Now another library, libresourceful.so.0, comes along and implements complex_divide on top of complex_multiply. Since the definition for complex numbers from libuseful makes a lot of sense, the include file for libresourceful reads #include "libuseful.h"
 
void complex_divide(
  struct complex_number *result,
  struct complex_number const *lhs,
  struct complex_number const *rhs); Now one of the more serious people in Debian decides to write pointless 1.0, which takes two complex numbers and calculates (a*b)/a, using both complex_multiply and complex_divide, and links against libresourceful.so.0 and libuseful.so.0. Some time passes, and shortly before Debian freezes, libuseful's author decides that she needs more precision, so she changes the floats to doubles, bumps the SONAME and releases the new version. Shortly thereafter, someone notices that libresourceful is now using an outdated version of libuseful, and recompiles libresourceful. Since the header of libresourceful did not change, noone thinks of changing the SONAME, after all, changing it would render us incompatible with other distributions. Now, pointless 1.0 depends on libuseful.so.0 and libresourceful.so.0, which in turn uses libuseful.so.1. It still believes complex numbers are made from floats, however libresourceful now disagrees. The (a*b) expression is calculated correctly, using floats, however the result is then passed to the complex_divide function which expects a pair of doubles. Not good. Obviously, there is a number of things people have done wrong in this example. First of all, if you inherit type definitions or anything else from another library, your ABI becomes bound to theirs. As you cannot know statically what version your library will be linked against, you need a script that computes your ABI version at build time. If you do not want that, you need to repeat the type definitions in your header and (deep-)copy the data from one of your structures into one provided by the library you are using (I can already hear the screams of the performance fetishists). The assumption that, just because a dependency changed, there is not necessarily a need to bump the soname is not fundamentally incorrect; if no interfaces are being propagated, it is certainly correct, and most libraries do not really do this (for example, a HTTP library uses the resolver, but never passes the hostent structures upwards). Detecting this is difficult to do, although Sun has a few tools to help here. So where does that leave us? In my opinion, the most sensible thing a distribution can do is to make sure such a constellation never gets installed to an user's system. If there is any doubt, we need to err on the side of caution (aka use a bigger hammer). This is a "wacky ideas" post, so I also need to propose a totally untested thing that might work (or not), but at least has passed the stage of me sleeping a night over it. Ideally, dpkg would enforce that. In order to do that, it needs appropriate metadata that tells it that a certain constellation is probably wrong. The thing we want to avoid is an application using multiple versions of the same library at the same time, where "use" is denoted by a dependency relationship. So what we need is a way for a library package to declare that it is wrong to (indirectly) depend on this package and a package out of a certain group at the same time. I can see two ways of doing that, each with its own advantages and disadvantages: The "explicit" way is to add a new dependency relationship (that is where the subject "Conflicts-If-in-Same-Dependency-Tree" comes from), where you would conflict in this way with a virtual package that is named after your library without the SONAME version, and at the same time provide that virtual package (which is a technique that should not be unfamiliar to Debian people). The hypothetical libuseful above would then state Package: libuseful0
Provides: libuseful
Conflicts-If-in-Same-Dependency-Tree: libuseful So installing pointless_1.0 would pull in libuseful0 and libuseful1, dpkg would see the conflict and refuse. For upgrades, it would refuse the libresourceful0 upgrade, as that would create an inconsistent situation. The only way out of there is to recompile pointless. The advantage is that the modifications to dpkg would be manageable (at least compared with the other option, which I will introduce shortly), the obvious disadvantage is the massive number of virtual packages introduced. The "implicit" way of doing that is moving the SONAME into its own field in the control file, and teaching dpkg that two packages with the same name and different SONAME fields can be installed at the same time, although not depended on by the same package. This is a really nasty change to dpkg and also requires a syntax for dependencies that includes the desired SONAME version, but it gives us a lot of other advantages. The one immediately visible is that it does not bloat the Packages file too much, and does not introduce lots of virtual packages, although the net effect inside apt and dpkg is probably going to be the same. A really cool side effect though would be that the soname is no longer part of the Package: field, and thus it becomes possible to insert it using substvars. This, of course, is a cool thing when library authors come to their senses and include ABI information for dependent libraries into their SONAMEs. Since this has gotten lengthy, thanks for reading this far. Of course, questions and comments are requested, and if you are interested in pursuing this, please get in touch, either via email or if you can wait that long, at the "Wacky Ideas" BoF at DebConf. The last thing for me to do here is to welcome Joachim to the "post your ideas" "meme".

Debian as a Linux distrubtion is all about integration and ease of management, which includes init-scripts. I d like to propose a feature that might be helpful to quite a few system administrators while being non-disruptive to all others.For a lot of daemons there are use-cases that require more than one instance of the daemon to be running. With instance I mean a separate process with it s own configuration files, but on the same system, which rules out virtualisation or changeroots. Examples are copies of the main server running on a different port, to test new settings, different servers on different IPs, a HTTP-Server-Split into a slick static-and-proxying server and a heavy backend server, a mail server split with a virus scanner in between etc.So as an administrator I currently not only have to write the configuration for the additional instances, but also write my own init scripts and modify them, never being sure if I did it good or whether it will cause problems on package upgrade or similar things. I d rather see the functionality built-in to the package s init script directly.There is a package in Debian that already provides this: The OpenVPN package maintained by Alberto Gonzalez Iniesta allows the user to define new instances of OpenVPN simply by adding a new file to /etc/openvpn/. The file /etc/default/openvpn defines which of these instances are to be started when I or the system start runs /etc/init.d/openvpn start. /etc/init.d/openvpn stop stops all running instances and /etc/init.d/openvpn restart also restarts just the currently running servers. I can easily control a specific instance by adding it s name (which is the configuration file s basename) after the command to the init script.I think these semantics are clear, sensible and non-disruptive and should be available with every Debian package where the administrator might want to run several instances at once: web server, mail server, ftp servers, name servers etc.In those cases where the daemon is not configured by a single file alone, one directory with the configuration for one instance is needed. Otherwise, I don t see why this should be a problem. For backwards compatibility, the normal configuration file locaction could be an implicit instance called default and all additional instances go to their own directory (e.g /etc/ntpd.conf is instance default , and /etc/ntpd/public.conf is instance public ).Comments welcome.

Ted Ts'o had an interesting post about git recently. He has a lot of good thoughts on the subject. He comments that he wound up using git because it's so Unixy (with its small commands to do things), that he sees the git community developing innovations faster than Mercurial, and that they are working to improve the documentation and user interface problems.

The being so Unixy is a double-edged sword. On the one hand, it can make it easy to write shell scripts to extend Git. That itself can be a double-edged sword (think filename quoting and the like). But one doesn't have to use the shell. The other downside is that being Unixy makes it hard to run on platforms that aren't, such as Windows. So if one is working on Unix-only software (X, the kernel, e2fsprogs, etc.), there's no need to care about it. But if you're a person like me, who has Windows users using my software, or a large organization like Mozilla, it's maybe a showstopper. Of course, workarounds exist (cygwin, git-cvsserver), but none of them are particularly nice.

I think that both Git and Mercurial are working to address their shortcomings. I've chosen hg for now because it does what I need now. And because there are very nice tools to convert hg to git, and vice-versa. So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now

So following up on my bzr post, here are the things that Mercurial is great at right now:

1. Performance. Approximately even with git, occasionally faster. Nobody else can compete with these two right now.
2. Simplicity. It's almost as easy to get started as with darcs, and with recent patches, will be even closer in the future.
3. Lots of ways to interact. You can send hg bundles, which preserve all metadata (parents, hash, authors, etc), or you can send git-format email patches, or you can push and pull between repos. The email tools will shortly be able to automatically detect what patches to send. Your choice. git doesn't seem to support lossless emailing of bundles like this, and bzr doesn't make emailing of anything easy by default.
4. Merging. hg seems to be able to automatically resolve more merge conflicts than anything else, and when it can't automatically resolve them, has a nicely configurable system to let you use your choice of tool to manually resolve them.
5. Community. The Mercurial community is open and inviting, and open to new/different ideas. It seems similar to Darcs in that respect, and somewhat dissimilar to git.
6. Rebase does not trash history like it does (barring undocumented manual intervention) in git.

I've written before about Darcs, so I won't duplicate that here.

Dear Lazyweb, I was asked if I could easily setup a system with the following characteristics for a sport club:

• A server in the office room (= locked) hosts the music library
• Two clients (for the two training rooms) are connected to the server
• Each rooms' client can select it's own music (preferrably using a touch screen), pause, play and pitch.
• Trainers can create, save and recall playlists for their class
• It should be possible to associate additional metadata to the music, such as measures-per-minute speed information.
• If possible trainers should be able to generate playlists remotely using a VPN connection; however it needs to be ensured that they cannot download the music this way (the sport club has a license for music use in training classes, but obviously not for anything else)

Two setups I was considering:

• NSLU2 and some USB disks as storage
• DAAP on the NSLU2 for music serving
• Rythmbox, Banshee or maybe even iTunes as client

This would likely require the least effort. It doesn't offer the playlist features I wanted (or only partially), and there are some access control limitations. No remote access. But for example the clients could even be Windows boxes I wouldn't have to deal with myself.

• Full linux server, maybe NSLU2 would be fast enough?
• Two MPD instances running there, streaming the audio to the clients
• Clients with a small GTK or Web UI to control MPD instances on server

Has better playlist sharing capabilities, and the web UI could probably be used remotely, too. But MPD doesn't allow extra metadata such as BPM information, it would need to be modified. Much more work. Maybe some solution using XMMS2 or VLC would also be possible. And the ideal solution would allow some pitching. Do you have any recommendations for me? Please send them via EMail to erich AT debian DOT org. IMHO, the key factor will actually be the UI for the trainers. It should allow them to easily locate a song when needed, or put a couple of songs into a playlist to use during their class. Carzy DJ mixing capabilities aren't needed; party evens will likely have a real DJ around. This setup is solely meant to help the trainers getting their music ready in no time. Right now there are always issues with cables gone missing, CDs in the wrong covers, CD readers not reading certain CDs, etc. pp. And after all CDs have a pretty bad usability; you can't reorder songs easily according to your needs, and you'll often have to switch CDs. Having the music on a harddisk and using playlists can offer some good improvements here. So instead the UI should allow easy searching of tracks, easy access to a large number of playlists and such key functionality. Note that this is just an idea floating around so far; I don't know if it will become reality sometime. Adding some PCs to the rooms, eventually even with a touch screen, is some expenditure; that money might be better spent differently.

I've just got home after spending yesterday in London. I went along to a meeting of GLLUG, the Greater London Linux User Group, to give a talk about Debian. The slides are online (and remarkably similar to my last talk!) for those who may be interested. Then we adjourned to the pub; after all, GLLUG sounds rather like an incitement to drink (*grin*). I got caught up in some really good discussions at the meeting, and even found a couple more people who want to sponsor Debconf. Yay! I forgot to take my camera along, so I'm afraid I have no photos to share. Doh...

John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

(Title stolen from Holger Levsen) Whenever I see this image [mozilla open Standards], I want to make a spoof of it titled: Every time you make an Ajax app, god kills a firefox. But I would certainly be violating Mozilla trademarks by doing so (their artwork, logos and trademarks such as "firefox" are not OpenSource). Anyway: AJAX is a hackaround, in particular it is not an open standard. Please use it only where it's really needed. Granted, there is worse (e.g. Flash; prepare for incompability hell now that the first opensource plugin can playback youtube videos - as you might be aware, many Linux distributions can not ship Adobe Flash, so they'll likely start shipping this plugin as soon as it's somewhat working sufficiently; or ActiveX which only works with MSIE...), but that's not really a good excuse for this abuse of Javascript that is called AJAX. On a side note, since I already mentioned flash - I can really recommend the Flashblock mozilla extension. A must have: you can view any flash if you need to by just clicking on it, but they won't be loaded automatically anymore. So you can easily access youtube (just one extra click!), but won't be bothered by flash ads and such stuff. Oh, and Adobe. They're probably the biggest blocker for a widespread Linux adoption judging by this article [computerworld.com], which is already very positive on Linux ("Unlike many of the applications included on new Windows systems, these don't seem to come with annoying self-launching advertisements, such as the irony-challenged Trend Micro Anti-Spyware pop-up upgrade pleas that plagued my HP system at home."): maybe his biggest issue is that he couldn't just run his Adobe Photoshop Elements on Linux. Of course there are application trying to offer the same functionality; starting with Gimp, digiKam and Krita (and I'm not sure he tried Krita and digiKam as well; they are probably more similar to Adobes product), but I can understand his wish to be able to continue using the same applications. (My personal recommendation: start using Opensource applications on Windows, e.g. Firefox, Thunderbird, Inkscape (great vector graphics program!) (and it's using open standards: SVG), Gaim (multi-protocol instant messenger and tons of others. They're free, so even if you don't use them every day, you didn't waste money on them... and if you happen to like them: you can be sure that they'll be working the same if you do the switch to Linux at some point in the future. Be prepared for when Microsoft says you PC is too old.