The next release of DebTorrent is now available. This release includes new functionality for communicating with APT using a new transport method specifically designed for debtorrent, and many bug fixes. The major changes in this release are all in the communication between APT and DebTorrent. The HTTP server in DebTorrent that listens for APT requests has been upgraded to support HTTP/1.1 persistent connections and pipelining, which allows APT to have multiple outstanding requests for files. This is useful as DebTorrent suffers from the typical bittorrent slow start, so requesting multiple files at a time helps to speed up the download considerably. Though better, HTTP/1.1 is not ideal for DebTorrent however, as a maximum of 10 outstanding requests is maintained by APT's http method, and files must still be returned in the order they were requested (which is not ideal for bittorrent-type downloading since downloads occur randomly). To further improve the APT communication I have modified APT's http method to create a debtorrent method. This new debtorrent transport for APT is packaged separately as apt-transport-debtorrent, and once installed APT can be told to use it by replacing "http://" with "debtorrent://" in your sources.list file. This method sends all requests it receives immediately to DebTorrent, and will receive responses from DebTorrent in any order. You can find this new method on the Alioth project, or in my personal repository (only amd64 and i386 versions are currently available). Unfortunately, the story doesn't end here. The APT code responsible for sending requests to the method also limits the maximum number of outstanding requests that it will send to the method to 10, which is not really necessary since all existing methods limit the requests they send out themselves. I have therefore patched the current APT code to increase this limit to 1000 (a one line change), and released this patched version as 0.7.6-0.1. You can find this patched version in my personal repository (again, only for i386 and amd64). I have tested it with the other methods available and it causes no problems, and I hope to get the change included in the regular APT code soon. To sum up:

• new DebTorrent over HTTP = fast
• new DebTorrent with new apt-transport-debtorrent = faster
• new DebTorrent with new apt-transport-debtorrent and a patched APT = fastest

The last DebTorrent version (0.1.3.1) is currently in the NEW queue, and judging by the length of it, will be there for about another week. After DebTorrent is added to the archive, I will be upgrading it to this new version. I also hope to get the new apt-transport-debtorrent package into the NEW queue soon. This brings to an end the Google Summer of Code (which this project was created as a part of), but development of DebTorrent will of course continue (probably a little slower). The next major change will be the addition of unique piece numbers, which is almost complete but needs to be extensively tested. I'd like to thank Anthony Towns, Steve McIntyre, and Michael Vogt for their help over the last 4 months, and also the many others who sent me encouraging emails or engaged in interesting discussions about this project. It's the people who make a project like this a fun and memorable thing to do. Here's the changelog for the new DebTorrent release:

• APT communication supports HTTP/1.1 connections, including persistent connections and pipelining
• Add support for the new debtorrent APT transport method (see the new apt-transport-debtorrent package)
• Make the Packages decompression and torrent creation threaded
• Improve the startup initialization of files
• Add init and configuration files for the tracker
• bug fixes:
  • restarts would fail when downloaded files have been modified
  • deleting old cached data would fail
  • small tracker bug causing exceptions
  • prevent enabling files before the initialization is complete
  • only connect to unique peers from the tracker that are not already connected
  • tracker would return all torrents' peers for every request

The next release of DebTorrent is now available. This release includes new functionality for communicating with APT using a new transport method specifically designed for debtorrent, and many bug fixes. The major changes in this release are all in the communication between APT and DebTorrent. The HTTP server in DebTorrent that listens for APT requests has been upgraded to support HTTP/1.1 persistent connections and pipelining, which allows APT to have multiple outstanding requests for files. This is useful as DebTorrent suffers from the typical bittorrent slow start, so requesting multiple files at a time helps to speed up the download considerably. Though better, HTTP/1.1 is not ideal for DebTorrent however, as a maximum of 10 outstanding requests is maintained by APT's http method, and files must still be returned in the order they were requested (which is not ideal for bittorrent-type downloading since downloads occur randomly). To further improve the APT communication I have modified APT's http method to create a debtorrent method. This new debtorrent transport for APT is packaged separately as apt-transport-debtorrent, and once installed APT can be told to use it by replacing "http://" with "debtorrent://" in your sources.list file. This method sends all requests it receives immediately to DebTorrent, and will receive responses from DebTorrent in any order. You can find this new method on the Alioth project, or in my personal repository (only amd64 and i386 versions are currently available). Unfortunately, the story doesn't end here. The APT code responsible for sending requests to the method also limits the maximum number of outstanding requests that it will send to the method to 10, which is not really necessary since all existing methods limit the requests they send out themselves. I have therefore patched the current APT code to increase this limit to 1000 (a one line change), and released this patched version as 0.7.6-0.1. You can find this patched version in my personal repository (again, only for i386 and amd64). I have tested it with the other methods available and it causes no problems, and I hope to get the change included in the regular APT code soon. To sum up:

• new DebTorrent over HTTP = fast
• new DebTorrent with new apt-transport-debtorrent = faster
• new DebTorrent with new apt-transport-debtorrent and a patched APT = fastest

The last DebTorrent version (0.1.3.1) is currently in the NEW queue, and judging by the length of it, will be there for about another week. After DebTorrent is added to the archive, I will be upgrading it to this new version. I also hope to get the new apt-transport-debtorrent package into the NEW queue soon. This brings to an end the Google Summer of Code (which this project was created as a part of), but development of DebTorrent will of course continue (probably a little slower). The next major change will be the addition of unique piece numbers, which is almost complete but needs to be extensively tested. I'd like to thank Anthony Towns, Steve McIntyre, and Michael Vogt for their help over the last 4 months, and also the many others who sent me encouraging emails or engaged in interesting discussions about this project. It's the people who make a project like this a fun and memorable thing to do. Here's the changelog for the new DebTorrent release:

• APT communication supports HTTP/1.1 connections, including persistent connections and pipelining
• Add support for the new debtorrent APT transport method (see the new apt-transport-debtorrent package)
• Make the Packages decompression and torrent creation threaded
• Improve the startup initialization of files
• Add init and configuration files for the tracker
• bug fixes:
  • restarts would fail when downloaded files have been modified
  • deleting old cached data would fail
  • small tracker bug causing exceptions
  • prevent enabling files before the initialization is complete
  • only connect to unique peers from the tracker that are not already connected
  • tracker would return all torrents' peers for every request

During my previous adventures with the Debian archive, I found that two packages in the archive use bzip2 compression inside the .deb instead of the traditional gzip compression, so I decided to try it out on emacs-snapshot (one of my larger packages). The combined size of the deb files goes from 36764KB to 33880KB, a 2884KB (7.8%) difference. It also makes both lintian and linda unhappy, the former gives me the following error:

E: emacs-snapshot-nox: deb-data-member-wrongly-compressed
N:
N:   The binary package contains a data member not compressed with gzip.
N:   From dpkg-dev 1.11 on, you can configure the way the data tarball is
N:   compressed. Though this is possible, you are not allowed to use it
N:   before dpkg 1.11 (or later) enters stable.

and linda just bombs:

E: emacs-snapshot-common; Package uses a newer feature of dpkg.
 This package uses a data.tar, or data.tar.bz2 member of the .deb. This
 was introduced in dpkg 1.11, but is not allowed to be used until dpkg
 1.11 or later hits stable.
File ...3_all.deb failed to process: Level 2 unpacking failed:
Could not unpack data tarball

Etch was released with dpkg 1.13.25, so bzip2 compression is probably allowed now. But is a 7.8% saving worth the incompatibility price? I'm not sure.

Bernhard R. Link blogs about LDAP addressbooks in Thunderb^WIcedove, and mentions:

Also don't be confused by no records shown in the new addressbook. I guess that is some measure against always loading a possibly large remote addressbook. To test just enter anything in the search field, and the matching records should show up nicely. (I'm not sure if all versions allow searching for substrings. If they do, try searching for the at sign, to get a full list.)

Actually, the reason is that an LDAP server is not a database, and it is not required to return the full list of matching items of a search, if that list is sufficiently large (I believe the RFC suggests a minimum of 100 items to be returned); this is to avoid people DoSsing the LDAP server by accident. It also means that the suggestion to search for the at sign to get all items in the directory may not work.

As many readers of this blog know, I tend not to shy away from writing about my mother s struggle with Alzheimers. But in the last 6 months and especially since I paid my last visit to my mother, I have found it much harder to sit and write about her current state of affairs. If we think of Alzheimers as a journey to a new place, she is almost at the point of reaching that place of great loneliness and inhospitality, which is not only new and different both for her and those around her but is a virtual prison, for it rarely allows you to leave and visit the places of your past. More than ever, her memory and understanding of her life as she (as I and many others), once knew it, is fading fast; Of course, this was to be expected but it is quite difficult to imagine what it will be like until the actual experience unmistakably knocks on the door of present time and unfortunately, when it knocks, you can t do anything but open the door and let it in. Unsurprisingly, it is incredibly difficult to witness and interact with a person who is losing most all recollections, the stuff of which, you come to realize, is what defines a person and allows you to more or less have the opportunity to seamlessly interact with him or her. In the last number of months, I have perhaps been more silent than usual because there is only so much I can and want to think about when it comes to my mother s decline. I talk to her nearly every day and I have decided for now, that is enough. But I am retreating out of my silence after reading a refreshingly honest, though still somewhat timid piece on Alzheimer in the NYTimes, entitled Zen and the Art of Coping With Alzheimer s
The piece is striking because it offers a more realistic portrayal of the disease than most mainstream media accounts and it provides some really sound advice about the importance of just letting go and going with the flow when interacting with those with Alzheimers. At the same time, it lacks a certain window into just how disheartening and hard it can be to witness the decline, and how hard it can be to manage those conversations and interactions. On the whole, I try to go with the flow. For example, I recently returned from a visit and soon after I left, my mother forgot I was even there. She started to ask me over and over again when I was coming home for a visit and when I told her I was just there, her semi-humorous reaction was well, why didn t anyone tell me? (and then proceeded to castigate her caretaker for not telling her!!). Perhaps I did not stay long enough, or perhaps her lack of recall would happen no matter what. To hear she forgot shook me hard and deeply. The first time I realized she could not remember I had just visited, I was able to jog her memory by listing off all that we did together. Finally, when I mentioned that I bought a new refrigerator while in PR, something clicked. She is still worried about money, so buying a refrigerator was enough to remind her I had spent a lot of money. But after it was clear that she felt quite bad about not remembering, I knew that was the first and last time I would try to jog her memory. Instead, I will merge and mold my reality to her reality, as much as I can and assure her that I will soon visit.
(more…)

Im currently looking if a UMTS data connection (flatrate) is something for me. Looking around it seems Vodafone has the best network for UMTS with that HSDPA technology (3.6MBit/s max. instead of only 384kbit/s). Especially the area I am most interested in - my way to work, is only available with HSDPA from Vodafone, all other telcos dont seem to be able to get UMTS there. Some days ago I sat besides someone in a train back home who was using UMTS connection. And didnt seem to have any problems. When I asked he told me that its fairly stable, on the whole way he only knows two points where the card seems to switch to the slower GPRS way. And looking at his screen he was using some weird webchat thingie, so nothing that likes too huge lags. (Ah, btw - how can anyone seriously chat in such a weird way? I mean - we have IRC, WTF are people dumb enough to use their webbrowser to chat? Thats so silly) My main usage would be to be online on the way to work / back home, which is about 1.5h each, so 3hours on days where I go to work (using ICEs, so at least there are repeaters for the mobile stuff in the trains). Most of my online usage is ssh based, usually via (Open)VPNs, then some mail sync runs and various small things. Moobicent does offer a flatrate (a real one, not such a “customers are dumb and dont see it is trafficlimited just because we named it flat”one) using the Vodafone network. The hardware I need for it costs 99EUR when I order there. Its some PC Express Card that comes with a PCMCIA Adapter. Now, has anyone out there reading this blog experiences to share? Using google there is Marcs blog which suggests it shouldn’t be too hard to get it all running, but maybe there is something I missed to take into account? Comments? Suggestions? Anything? Email me or catch me on IRC, (no, my blog doesnt have comments), and I summarize the results later. Update:UMTS == 3G; 2 People already told me that the Vodafone net is the right selection in Germany, one said the same for UK.

It&aposs been some time since I got this working, but I decided to now also blog about it here now, as I was just asked it.

The main magic to get thunderbird/icedove use your ldap server as addressbook, is to include the proper schema. Search the web for mozillaAbPersonObsolete and you should find it. You do not have to use any of it&aposs new fields, not even the object class in it is needed. Your slap only have to know about the field names, then thunderbird will be able to show the normal inetorgperson&aposs mail attribute.

Some caveats, though:

You might think you might test your settings in thunderbirds by using that button to download everything and store it locally. In my experience that never works but strangly asks for a password, while the addressbook is already nicely working and needs no password at all.

Also don&apost be confused by no records shown in the new addressbook. I guess that is some measure against always loading a possibly large remote addressbook. To test just enter anything in the search field, and the matching records should show up nicely. (I&aposm not sure if all versions allow searching for substrings. If they do, try searching for the at sign, to get a full list.)

The shown fields seem also a bit strange, and differ with the different mozilla messenger/thunderbird/icedove versions. In some versions the field the primary name is extracted from can be changed, but directive to set that seems to change even more often.

Finaly, some snippet for your /etc/icedove/global-config.js, which causes all newly created users to have an addressbook as default. I forgot if all are needed or why I added them, but those that are unnecessary at least do not seem to harm. (Last tested version is the one in etch, though. Newer version might again have something changed).

   /* ldap-Server for FOOBAR */
   pref("ldap_2.autoComplete.useDirectory", true);
   pref("ldap_2.prefs_migrated", true);
   pref("ldap_2.servers.mathematik.attrmap.DisplayName", "displayName");
   pref("ldap_2.servers.default.attrmap.DisplayName", "displayName");
   pref("ldap_2.servers.mathematik.auth.savePassword", true);
   pref("ldap_2.servers.mathematik.description", "FOOBAR");
   pref("ldap_2.servers.mathematik.filename", "foobar.mab");
   pref("ldap_2.servers.mathematik.maxHits", 500);
   pref("ldap_2.servers.mathematik.uri", "ldap://HOSTNAME:389/ou=People,dc=FOOBAR,dc=TLD??sub?(mail=*)");
   

Im currently looking if a UMTS data connection (flatrate) is something for me. Looking around it seems Vodafone has the best network for UMTS with that HSDPA technology (3.6MBit/s max. instead of only 384kbit/s). Especially the area I am most interested in - my way to work, is only available with HSDPA from Vodafone, all other telcos dont seem to be able to get UMTS there. Some days ago I sat besides someone in a train back home who was using UMTS connection. And didnt seem to have any problems. When I asked he told me that its fairly stable, on the whole way he only knows two points where the card seems to switch to the slower GPRS way. And looking at his screen he was using some weird webchat thingie, so nothing that likes too huge lags. (Ah, btw - how can anyone seriously chat in such a weird way? I mean - we have IRC, WTF are people dumb enough to use their webbrowser to chat? Thats so silly) My main usage would be to be online on the way to work / back home, which is about 1.5h each, so 3hours on days where I go to work (using ICEs, so at least there are repeaters for the mobile stuff in the trains). Most of my online usage is ssh based, usually via (Open)VPNs, then some mail sync runs and various small things. Moobicent does offer a flatrate (a real one, not such a “customers are dumb and dont see it is trafficlimited just because we named it flat”one) using the Vodafone network. The hardware I need for it costs 99EUR when I order there. Its some PC Express Card that comes with a PCMCIA Adapter. Now, has anyone out there reading this blog experiences to share? Using google there is Marcs blog which suggests it shouldn’t be too hard to get it all running, but maybe there is something I missed to take into account? Comments? Suggestions? Anything? Email me or catch me on IRC, (no, my blog doesnt have comments), and I summarize the results later.

How to get rid of most spam on Alioth mailing lists.

Until some Debian developer implements this idea in the BTS, the mailing list and in PTS, the quantities of spam that people get on the mail addresses they expose in the Debian world, the spam will keep on coming in huge quantities. I don't care that there will always be spam, I care that the amount of spam would be lower or probably nonexistent for one time sending (I sent just one mail to the BTS from two different mail addresses and it was enough to get huge amounts of spam on them).


The Debian Games Team's ML has suffered for a while, back in 2006, from spam bombing.
We thought that the easiest method to get rid of spam is to requires registration in order to be able to send mails to the list.

That was a big mistake because, as some people suspect, mails from the BTS needed to be allowed in and the reporters got an automated reply saying that the mail is waiting for approval, etc, etc - plain rude, people send you bug reports and you say "You are not listed, bla, bla bla". We changed the setting not to send any automatic reply and people were more content.

But still, we had to hand approve or white list valid mails/addresses. That worked for a while, but once the mail ended up on spammer lists, the thing blew out of proportions. We were desperate. We tweaked the settings of the lists in different ways, but in the end we ended up in having such a broken setup that we had to approve white listed addresses.

That did for me. I had to do something. So I started working on the ML setup and basically I did the following things to get rid of spam:

• anything coming from white listed mail addresses was approved
• black listed mails (bellsouth is one of those) is rejected (or should be)
• anything that came from the BTS (there are some nice headers that the BTS puts) and was evaluated as ham with a score of 0 (there is a field for that, too - some field has Spam=No, Score=...) was allowed
• anything that came from the BTS that was Spam=No with a score above 0 was held for moderation
• anything else is held for moderation

This solution allowed us to lighten the burden of manually white listing every email address that ever sent valid mails to the BTS and to focus only on real spam.

Try it your self on your lists, you'll be pleasantly surprised.

debcheckout: some new bits Some new bits about debcheckout (talk is cheap, code here):

• authenticated mode. Consider svn (similar arguments stand for other VCS). When checking out alioth repositories using the svn:// prefix, the resulting local copy can't be committed to, since it would require (assuming you have an alioth account and the needed permissions) a svn+ssh:// access. "authenticated mode" is precisely for that: when checking out well-known repositories (only alioth's ATM) you can specify an extra "-a" argument, with an optional "-u" to specify your user name, and debcheckout will rewrite the repository URL so that the resulting local copy can be committed to. ATM authenticated mode works for svn, hg, bzr, git.
• destination dir. It is now possible to specify where do you want to check out a package repository (so that we avoid ending up with tons of anonymous "trunk" directories). The syntax is the common "debcheckout PKG DESTDIR" idiom and DESTDIR, if not provided, defaults to the package name. (Thanks to JoeyH for the idea and the initial patch.)
• sorry about arch, but ATM it's almost non-functioning, and I'm not willing to lose time on it, since among all the VCSs supported by debcheckout it's the only one I've never used. If you want support for it, please provide code!

(Perl) Tip of the day: Switch.pm With "use Switch;" you will win a switch statement for your Perl programs, which can be used as follows:

switch ($repo_type)  
  case "cvs"    my $module = pop @cmd; push @cmd, ("-d", $destdir, $module);  
  case /^(bzr darcs git hg svn)$/
                push @cmd, $destdir;  
  else   die "sorry, don't know how to set the destination directory for $repo_type repositories (patches welcome!)\n";  
 

This is far better than a chain of if/elsif statements and has even a sane semantics (e.g. no need of explicit breaks, possibility to have higher-case branches, ...). Unfortunately, it is not possible (using a simple syntax) to match a scalar value against an array case branch. Therefore the only way to factorize branches is (when possible) to rely on regexp alternative branches, as it is done in the code snippet above.

Sorry, but I can't see how to make this post anything but a bit negative: Along with a few million others, I own some food shops. I usually try to shop there. I go away for a few weeks and the picture shows what's happened to my nearest food shop... It's closed! Well, that's one less store for the rebranding project, [Cambridge Co-operator] but it's a bit of a pain in the backside. There's no sign on the closed shop and I saw no sign when I last visited it. There's nothing on the membership web news and there was nothing in the last magazines. I've called the regional office to find out what's happening and left a voicemail. I might email one of our committee too, as I think they decide on closures. I'm a bit unhappy about this. Now we're down to two medium/small food shops that have really bizarre stock policies (for example, they sell filter coffee, but no coffee filters) and are unable to order key ethical products. (2007-08-17: 1 comment)

Eurosport are broadcasting the Vuelta a Burgos at 19 east until Saturday. This can be an interesting race for seeing how well the ProTour teams are recovering from the Tour de France, ready for the Vuelta a Espa a. Barloworld's TdF revelation Juan Mauricio Soler has a 17-second lead into tomorrow's individual time trial. The 69th Volta a Portugal finished yesterday with an ~50-minute individual time trial that saw the lead change hands and Xavier Tondo of LA/MSS take the General Classification by a little under a minute. RTP's coverage was strangely subdued. It seemed like they only had cameras around the finish line, not on motorbikes following the riders. The bad weather may have caused that, though. Meanwhile, the Deutschland-Tour 2007 is broadcast to Europe until Saturday on ARD at 19 east and 13 east. Gerald Ciolek of T-Mobile won his second stage in a row today, while CSC's ever-popular Jens Voigt remains in yellow. Individual time trial there too tomorrow. ARD's coverage has been very swish so far this year. Widescreen with informative graphics, although the commentary is still a bit subdued for my taste. Overall, it's a shame there's not more airtime given to it.

Two weeks ago I started my new job at the Formal Methods research group of the Department of Mathematics of Computer Science at the Eindhoven University of Technology. So, what have I been up to until now? Well, as you can imagine it takes some time to settle down. I got a room with two other PhD students. I have installed my new (and fast!) computer with Debian Sid and am very happy about it. I have created my academic website using Webgen (like I do with all my sites), attempting to have it look the same as the main university site. I think I have succeeded. Next to the settling down I have been meeting all the people of our group and reading a lot of papers in my future area of research. What will I be doing the next few weeks then? For the moment I’ll continue to do a lot of reading. My research is in the area of the automata theory and the process algebra and ways to combine them. Besides reading up on that I will be continuing upon my master project and try to get the result published. Also, my first conference has been planned! Yay! From September 2 till September 8 I will be in Lisbon to attend the CONCUR 2007 conference and also have a look around town, of course.

As I said previously, abydos was dead. I bought new hardware some days after, mainly a new Enermax Liberty ELT 500 W power supply (ATX 2.2 compliant, sick, my old Enermax ATX 1.2 could not work with new mainboards), an Asus P5K, 2 GB of G.Skill DDR2 PC6400, an Intel Core 2 Duo E6750 and a GeForce 8400 GS 512 MB. At that time, I just switched the hard drives without reinstalling the box. However, I had to reinstall some days because my old was an old Intel Pentium 4 (i386) and the new is 64 bits-ready. Before that, I played with some kind of stuff. First, installing cpufrequtils is just magic, because now my processor is set at 2 GHz instead of 2.66 GHz, and rise to 2.66 GHz on demand. Just cool: less power, less warm, less noise. I tried to tweak my SATA drives. I did something very wrong: hdparm -s. Kids, don't do this at home, it killed my hard drives! Yes, you're warned if you read the hdparm manual and you have to force the command, but I'm mad anyway. After that, the drives were no more detected at boot time by the buggy BIOS. Why buggy? Because after some googling, I found that they were NOT dead, just sleeping. And the fucking BIOSes around never try to wake them up. Fortunately, hdparm people distribute an bootable ISO that will wake your drives... It saved me. The Asus P5K is not well supported by the 2.6.18 kernel, so you won't have network during install of etch (or lenny beta 1), and when you will reboot you won't be able to boot correctly because initrd is stuck with hard drive detection. Furthermore 2.6.18 on this mainboard is fucking slow anyway. Fortunately, I just added another NIC in the box, boot on the CD, mount disks, chrooted and dist-upgrade to sid with a 2.6.22 kernel which work perfectly. So now, everything's ready and set up, I can play!

Protx, a payment service, installed a major update on 1 August. They'd warned us about this in newsletters and we were prepared. We paid a bit towards another company's development of the protx_form module for OSCommerce to meet the updates and generally clean it up. This went slightly wrong in three ways. Firstly, protx went down for longer than expected, ultimately generating an apology from the MD. Not much we could do about that. Secondly, protx started rejecting commas in amounts. GB uses commas in between thousands, so this meant none of our British-localised shops could process orders over 1000. Ow. The Protx VSP Form docs still shows commas in the Amount examples, so I suspect that change was unintented. I've sent Protx Support an email to ask. I was offline, but Paul installed a fix before I got back. Finally, the mainline protx_form module has updated to v1.17 to include these changes and more (see Payment Modules forum threads), but our developer hasn't uploaded their work yet, so we're stuck up a branch and someone needs to merge. I hope it won't be us, as I can already see conflicting changes. What should I have done differently? Is it time to find a new payment provider? Should I insist that we publish paid developments ourselves as soon as possible? (2007-08-16: 1 comment)

When are two identical changes the same, and when aren't they? Theres a little bit of debate started by Andrew Cowie posting about unmixing the paint. Matt Palmer followed up with a claim that a particular technique used by Andrew is dangerous, and finally Andrew Bennetts makes the point that text conflicts are a small subset of merge conflicts. That said, one critical task for a version control system is the merge command. Lets define merge at a human level as "reproduce the changes made in branch A in my branch B". There are a lot of taste choices that can be made without breaking this definition. For instance, merge that combines all the individual changes into one - losing the individual commit deltas meets this description. So does a merge which requires all text conflicts to be resolved during the merge commands execution, or one that does not give a human a chance to review the merged tree before recording it as a commit. So if the goal of merge is to reproduce these other changes, then we are essentially trying to infer what the *change* was. For example, in an ideal world, merging a branch that changes all "log messages of floating points to 6 digit scale." would know enough to catch all new log messages added in my branch, regardless of language, actual api used etc etc. But that is fantasy at the moment. The best we can do today depends on how we capture the change. For instance, Darcs allows some changes to be captured as symbol changing patches, and others as regular textual diffs. So the problem about whether arriving at the same result can be rephrased 'when is arriving at the same result correct or incorrect'. For instance, if I write a patch and put it up as plain text on a website, then two people developing $foo download it and apply it, they have duplicate changes but its clearly correct that a merge between them should not error on this. On the other hand, the example Andrew Bennetts quotes in his post is a valid example of two people making the same change, but the line needing a change during the merge to remain correct. Here's another, example though. If I commit something faulty to my branch, and you pull from me before I fix it. Then while I fix the bug, you also fix it - the same way. That is another example of no-conflict being correct. If its possible for either answer - conflict, or do not conflict - to be correct, then what should a VCS author do? There are several choices here:

• Always conflict
• Never conflict conflict
• Conflict based on a heuristic

I think that our job is to assess what the maximum harm from choosing the wrong default is, and the likely hood of that occuring, and then make a choice. Short of fantasy no merge is, in general, definately good or bad - your QA process (such as an automatic test suite) needs to run regardless of the VCS's logic. The risk of a bad merge is relatively low, because you should be testing, and if the merge is wrong you can just not commit it, or roll it back. So our job in merge is to make it likely as possible that your test suite will pass when you have done the merge, without further human work. This is very different to trying to always conflict whenever we cannot be 100% sure that the text is what a human would have created. Its actually harder to take this approach than conflicting - conflicting is easy.

I read an interesting post on Advogato about IT recruiting agencies (along with an interesting preface about medical treatment for broken ribs). Their report closely mirrored my experience in many ways. Here are what I consider to be the main points for a job applicant dealing with recruiters:

1. Ask more than you believe that you are worth - the worst they can do is say “no” (and you will feel like a fool if the agency pays you less than half what the client pays because you didn’t ask for enough).


2. Put lots of terms in your CV that will work for grep or other searches. A human who reads your CV will know that if you describe 3 years of Linux sys-admin experience that you can do BASH shell scripting and sys-admin work on other versions of Unix. But if a search doesn’t match it then the typical recruiting agent won’t offer you the position. I have idly considered saying things like “Perl (not Pearl) experience” to catch mis-spelled grep operations.


3. Recruiting agents will frequently demand that you re-write your CV to match a position that they have open, they will say things such as “you claim 3 years of shell scripting and Perl experience but I don’t see that on your CV” and insist that you re-write it to give more emphasis to that area.


4. Most recruiting agents are compulsive liars and don’t understand computers, you have to deal with the fact that to get most of the better paying positions you need to have an incompetent liar represent you. Avoid the stupid liars though. For example I once refused to deal with an agent who told me about his plans for stealing the CV database from the agency he worked for and selling it to another agency - not because he was shifty in every possible way, but because he was so stupid as to boast about such things immediately after meeting me on a train.


5. Expect that recruiting agents won’t understand the technology. If you politely and subtly offer to assist them in writing a letter to a client recommending you then they will often accept. Why would they go to the effort of assessing your skills and writing a short letter to the client describing how good you are when you can do that for them? On one particularly amusing occasion I was applying for a position with IBM and the recruiting agent had been supplied with a short quiz of technical skills to assess all applicants - they gave me the answer sheet and asked me to self-assess (I got 100% - but it was an easy test and I would have got the same result anyway).


6. Some levels of stupidity are so great that you should avoid dealing with the agent (and possibly the agency that employs them). Being unable to view a HTML file is one criteria I have used since 1999 (every OS since about 1998 came with a web browser built in). Another example is an agent who tried to convince me that “.au” is not a valid suffix for an email address (I was applying for a sys-admin job with an ISP). Job adverts that mis-spell terms (such as Perl spelled at Pearl) are also a warning sign.


7. Gossip is important to your business! Some agencies will pay you what you earn and merely terminate your contract when things go wrong. Other agencies will refuse to pay you when things go bad, or even demand that paid money be returned and threaten legal action. Talk to other contract workers in your region and learn the goss about the bad agencies. Also track agency name changes, when a bad agency changes name don’t be fooled.

When applying for a position advertised by an agency you will ideally start by seeing an advert with a phone number and an email address. The best strategy in that case seems to be to send your CV with a brief cover letter and then about 5 minutes after your mail server sends the message to their mail server you phone them. I found that I got a significantly higher success rate (in terms of having the agent send my CV to the client) if I phoned them when my CV arrived. Sometimes a fax number is advertised, unless there is some problem that prevents sending a document via email (such as the agency having a broken mail server) then do not FAX them. A faxed document will have to be faxed on to the client and will look bad after the double-fax operation and will prevent the agent from grepping it. Rumor has it that agents will often post fake adverts for the purpose of collecting CVs (so that they can boast to clients In most situations a recruiting agent should insist on meeting you for an interview before sending your CV to a client. The only exception is if you are applying for a job in another country. Meeting an agent at a restaurant or other public place is not uncommon (often they want to meet you while travelling between other locations and sometimes their main office is not in a good location). I suspect that some agencies start with a “virtual office” and perform all their interviews in public places (this doesn’t mean that they will do a worse job than the more established agencies). If an agent is prepared to recommend you to a client without meeting you then they are not doing their job properly. It used to be that there were enough agencies pretending to do their job that you could ignore the agencies that will recommend any unseen candidate. But now an increasing number of agencies do this and if you want a contract you may have to deal with them. When an agency has a fancy office keep in mind that they paid for it by taking money from people like you! For contract work a recruiting agent is not your friend, they make their money by getting you to accept less money than the client pays them - the less they pay you the more money they make. A common claim is “we only take a fixed percentage of what the client pays”, but when you ask what that percentage is they refuse to answer - I guess that the fixed percentage is 50% or as close to it as they can manage.

Share This

I read an interesting post on Advogato about IT recruiting agencies (along with an interesting preface about medical treatment for broken ribs). Their report closely mirrored my experience in many ways. Here are what I consider to be the main points for a job applicant dealing with recruiters:

1. Ask more than you believe that you are worth - the worst they can do is say “no” (and you will feel like a fool if the agency pays you less than half what the client pays because you didn’t ask for enough).


2. Put lots of terms in your CV that will work for grep or other searches. A human who reads your CV will know that if you describe 3 years of Linux sys-admin experience that you can do BASH shell scripting and sys-admin work on other versions of Unix. But if a search doesn’t match it then the typical recruiting agent won’t offer you the position. I have idly considered saying things like “Perl (not Pearl) experience” to catch mis-spelled grep operations.


3. Recruiting agents will frequently demand that you re-write your CV to match a position that they have open, they will say things such as “you claim 3 years of shell scripting and Perl experience but I don’t see that on your CV” and insist that you re-write it to give more emphasis to that area.


4. Most recruiting agents are compulsive liars and don’t understand computers, you have to deal with the fact that to get most of the better paying positions you need to have an incompetent liar represent you. Avoid the stupid liars though. For example I once refused to deal with an agent who told me about his plans for stealing the CV database from the agency he worked for and selling it to another agency - not because he was shifty in every possible way, but because he was so stupid as to boast about such things immediately after meeting me on a train.


5. Expect that recruiting agents won’t understand the technology. If you politely and subtly offer to assist them in writing a letter to a client recommending you then they will often accept. Why would they go to the effort of assessing your skills and writing a short letter to the client describing how good you are when you can do that for them? On one particularly amusing occasion I was applying for a position with IBM and the recruiting agent had been supplied with a short quiz of technical skills to assess all applicants - they gave me the answer sheet and asked me to self-assess (I got 100% - but it was an easy test and I would have got the same result anyway).


6. Some levels of stupidity are so great that you should avoid dealing with the agent (and possibly the agency that employs them). Being unable to view a HTML file is one criteria I have used since 1999 (every OS since about 1998 came with a web browser built in). Another example is an agent who tried to convince me that “.au” is not a valid suffix for an email address (I was applying for a sys-admin job with an ISP). Job adverts that mis-spell terms (such as Perl spelled at Pearl) are also a warning sign.


7. Gossip is important to your business! Some agencies will pay you what you earn and merely terminate your contract when things go wrong. Other agencies will refuse to pay you when things go bad, or even demand that paid money be returned and threaten legal action. Talk to other contract workers in your region and learn the goss about the bad agencies. Also track agency name changes, when a bad agency changes name don’t be fooled.

When applying for a position advertised by an agency you will ideally start by seeing an advert with a phone number and an email address. The best strategy in that case seems to be to send your CV with a brief cover letter and then about 5 minutes after your mail server sends the message to their mail server you phone them. I found that I got a significantly higher success rate (in terms of having the agent send my CV to the client) if I phoned them when my CV arrived. Sometimes a fax number is advertised, unless there is some problem that prevents sending a document via email (such as the agency having a broken mail server) then do not FAX them. A faxed document will have to be faxed on to the client and will look bad after the double-fax operation and will prevent the agent from grepping it. Rumor has it that agents will often post fake adverts for the purpose of collecting CVs (so that they can boast to clients In most situations a recruiting agent should insist on meeting you for an interview before sending your CV to a client. The only exception is if you are applying for a job in another country. Meeting an agent at a restaurant or other public place is not uncommon (often they want to meet you while travelling between other locations and sometimes their main office is not in a good location). I suspect that some agencies start with a “virtual office” and perform all their interviews in public places (this doesn’t mean that they will do a worse job than the more established agencies). If an agent is prepared to recommend you to a client without meeting you then they are not doing their job properly. It used to be that there were enough agencies pretending to do their job that you could ignore the agencies that will recommend any unseen candidate. But now an increasing number of agencies do this and if you want a contract you may have to deal with them. When an agency has a fancy office keep in mind that they paid for it by taking money from people like you! For contract work a recruiting agent is not your friend, they make their money by getting you to accept less money than the client pays them - the less they pay you the more money they make. A common claim is “we only take a fixed percentage of what the client pays”, but when you ask what that percentage is they refuse to answer - I guess that the fixed percentage is 50% or as close to it as they can manage.

Share This

There was a time that a small-ish (ca. 70 office workplaces) company bought almost all of its IT products from Dell, with 3 year on-site warranty to be on the safe side. There was a time when all was well and, in the rare cases that something needed to be replaced, a gentlemen would arrive and magically fix all that needed fixing. There was also a time, a bit later, when this enterprise wishes it could get rid of all the remaining Dell devices immediately (but of course you don't buy 100-odd desktops, servers and printers just because you no longer like the vendor.) One, if I buy a 4h-reaction-time warranty contract and tell them that I have a problem and that probably a part needs replacing, I don't expect to have to play ticket ping pong for a whole week until they agree that there even is a problem. Two, if there is a problem with a range of computers (leaking condensers) and more than half of our workstations are affected, I'd expect Dell to care about this and be at least ready to discuss mass-replacing the faulty motherboards in one go instead of having to send a tech every three days for yet another case of this problem. I'd think it's cheaper for them as well.... Three, not that I really care, since it's covered under warranty so I don't pay for it, but if I have two defective computers at the same site I'd expect one tech to fix them both, not two techs to come out (missing each other by 5 min) to fix one computer each. Again, you'd think they'd do the maths on how much these techs cost. Four, wouldn't it be nice if you could buy two laser printers and the toner cartridges would even be the same? HP, for example, manages to use the same toner cartridges for a whole range of printer models. Dell apparently can't do this. (Admittedly, I've only seen it in the case of the 5100cn/5110cn printers, and sometimes there are reasons to change the toner cartridges. But then I'd expect the printer model to be significantly different. Those two printers look exactly the same from outside, and the innards also look identical at first glance, including the toner cartridges, except for some coded plastic pieces ensuring that the cartridges don't match.) Five, wouldn't it be nice if toner cartridges could be bought at your regular office supply store, where we buy every other brand of cartridges? No, of course nobody but Dell themselves sells Dell supplies. Since supplies are not dealt with by IT stuff, this is really annoying. Especially beacuse Dell has repeatedly, for unclear reasons, disabled our login to the Dell online store (and we can't just create a new login as we have special discounts, so our account needs some special handling.) Six, how long is the usual life expectancy of a Laptop battery? For the Inspiron 9300 80Wh and the 53Wh battery, it's apparently 18 months, after which the battery doesn't charge anymore or only holds power for 2 minutes. Dell customer support confirms this is normal behaviour for these batteries and this is not covered under warranty accordingly. What now? Printers: HP. Desktops, Displays and Laptops: Lenovo. Servers: IBM. Network Switches: D-Link. Not sure if these choices are ok, but so far we've had less problems than with Dell. But of course the Dell stuff is older and so more prone to failure, so probably we'll just have to re-evaluate 3 years from now.