Yesterday I bought a laptop for a friend, who also asked me to install Linux on it. Since she's not computer-savvy at all, I opted for an Ubuntu. I provide here a short description of the hardware and what to expect regarding compatibility for anyone about to buy one of these. Hardware description

Model	HP 530
Part No.	GU322AA
CPU	Intel(R) Core(TM) Duo CPU T2300 @ 1.66GHz (stepping 12) - 2 MiB cache
CPU flags	fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr
Screen	330 mm x 250 mm viewable area, "glossy" wide-screen. 1280x800 pixels.
Video	Intel Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller
Audio	Intel 82801G (ICH7 Family) HDA
USB	Intel 82801G (ICH7 Family) USB2 EHCI Controller
Ethernet	Intel 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller Mobile
WiFi	Intel Corporation PRO/Wireless 3945ABG Network Connection
Optical media	Optiarc DVD RW AD-7560A
Hard disk	Fujitsu MHY2120BH, 112GiB, max UDMA/100

Problems The only problems I had with the hardware were related to the sound card and the lid. The sound card had exactly the same problem as my Dell Inspiron 6400: it won't turn off the internal speakers when you plug something in the audio output jack. This is easily solved adding the following to /etc/modprobe.d/options: options snd-hda-intel enable=yes model=laptop The problem with the lid is that the screen didn't turn off when the lid closed. Just one time it did work, and stopped doing so after a reboot. Looking with acpi_listen, it seems that the acpi event isn't even generated. I don't know if this is a hardware or software problem. Also, some not very nice things should be noted about it: it has no independent media buttons for volume, suspend, etc.; only the WiFi transmitter kill and the power button, the rest needed a key chord. It has only two USB ports, which nowadays is incredibly few. No LEDs for hard dist, scroll lock or num lock. The audio jacks are on the front, which makes them very unsuitable for any straight plug. Although seldom used, it is nice to have the ability to turn the screen 180 , but this one can't do it. Finally, the battery is tiny: only four cells amounting 2 Ah of capacity. The power consumption seems a little better than my Dell: running on batteries, with low brightness, an idle GNOME desktop gave a reading of 820mA. Watching a movie from optical media in full screen ranged from 1 A to 1.3 A depending on the spinning of the media and the codec. Burning a DVD at 2x took 1.15 A The good After installing a Ubuntu 7.10, almost everything Just Worked . Of course it warned me about the non-free ipw3945 driver, but in seconds network-manager had connected to my home WLAN. Network manager could be a little more smart and turn off the WiFi transmitter when it's disabled by the user, but I guess that's not only an Ubuntu problem :). Most media keys worked out of the box, the WiFi kill switch worked OK, as did suspend to ram and to disk. Video acceleration and obligatory eye candy worked automatically. No problems either with burning a DVD, listening to music, watching a movie or connecting to my home network. The external aspect is not bad, the screen looks good, and the touch pad is very nice: just a matrix of dots over a surface that doesn't show any other sign of being an input method. In conclusion, it shows that it is a very cheap machine, but the drawbacks seem very few comparing to the good price. Tags: Planet Lugfi, Planet Debian, Tecnolog a

I don't have the BTS handy right now, but bug #450000 was reported this week. At the current rate, it means that bug #500000 should come out around Oct 21st 2008. So, who will win the 500000th bug contest?

...at least, in my opinion (which is obviously biased, let's admit that). There are several reasons for this loss:

• Strategic choices: Bernard Laporte deliberately chose to use the same tactic against England and New Zealand. However, the tactic that worked against New Zealand failed against England, mostly because that tactic...is just the play of the English team. So, as we say in French, "les Bleus" entered the game of England and therefore made the task easier for them.
• The choice of players. This is the result of the previous item. Reconducting the entire team that won against NZ was IMHO a bad idea. It is not a scoop that I dislike Rapha l Ibanez or Fabien Pelous and I would rather have seen the punch of Dimitri Szarzewski or, for once, S bastien Chabal beginning the game (actually, he entered pretty quickly because of Pelous' injury).
• Several failures to occupy the English side with kick play. In many occasions, kick shots by either Beauxis, Traille or Jauzion missed their target. This is IMHO the main reason for the defeat.
• Too many drop tentatives. When they were in the English side, why the hell did they choose to kick drops several times instead of just play. That sounds like a fear of not scoring and the French lost several key balls with that miserable tactic.
• Too many lost balls in mauls. That is not only a failure by the French but also good defense play by the English team.
• Discipline. It happened only once (high tackle by Dimitri Szarzewski) but that was *the* moment where no error was possible and it offered an ideal penalty kick to Wilkinson.
• Bad luck. We can't rule out that one. The difference is 5 points: this stupid 1st minute try....and the missing 50 centimeters on Chabal's action in the last minutes.

Some *bad* reasons for the English victory:

• Johnny Wilkinson influence: this is untrue. Apart from his drop goal, he missed penalty kick tentatives and his kick play was not brilliant during the same. I much preferred Andy Gomarsall during that game.
• Scrums. They didn't crush the French scrum which is one of the satisfactions of that game. The English team even had to cheat slightly during 1st half time to win their scrums.
• Good play. No. Watching the game again, there was as many bad choices in the English side than in French side. I can only enhance their defense, not their attack. So, as I wrote immediately after the game, that one was one of the worst matches in the entire WC.
• The referee. Before the game, some French newspapers were doubting of Mr. Kaplan because he's South-African (funnily, some English newspapers were also doubting because he was supposed to advantage England's opponents in the past). He was indeed perfect. Anyway, everybody knows I never blame referees in sports.

After Argentina-France on the first day, that one was planned to be one of the few big matches of first round. Of course, after the game won by South Africa (36-0), that seems pretty silly to say... The Springboks were definitely better than England, in all parts of the game. What stunned me, particularly after watching South Africa live , is their complete control on the game, which is a great improvement over their match against Samoa. South Africa scored three tries all of them great examples or organized attacks by the rear lines. Two tries for JP Pietersen, after 3 by Habana on first game: the South-African wing players rock. Despite this, the player of the game was definitely Jason Du Preez, the scrum half (hope this is the correct term in English) who organised all attacks from RSA. England was missing too many key players (several injured) to be able to be a menace for South Africa. They never were really dangerous, except maybe when the magic Jason Robinson has the ball in his hands (what a player!). I was particularly disappointed by their center back players, and even more particularly by Farrel. Ditto for Andy Gomarsall as scrum half. So, South Africa is now probably qualified with two quite easy games against USA and Tonga. England will have to fight to qualify and noone can tell if Samoa or Tonga can surprise them. Watching Samoa-Tonga on Sunday will be interesting and Samoa-England or Tonga-England are already key matches. A great rugby week-end is about to begin, again. Today, Wales-Australia is the match of the day, for sure, with wales playing home (some matches are not in France, but in Cardiff and Edinburgh). New Zealand-Portugal will be...interesting, though the only incertainty is the number of scored tries. And finally, Ireland-Georgia is of some interest for the French. Tomorrow, France could have hard times against Namibia. Of course, the challenge here is winning *and* scoring the bonus point. That match is 5 days before a key France-Ireland, so the challenge is also not wasting too much energy. Of course, tomorrow's top match for me is Samoa-Tonga while I whileprobably skip Fidji-Canada (too bad, I haven't seen those playing yet). BTW, if someone has a recording of the most intense match as of now (Japan-Fidji), I'd be delighted. Rugbystiquement v tre,

Keeping /etc in git and other version control systems has been talked about and attempted by lots of people. I tried it with CVS, but that was a joke, with svn, but it sucked, now with git I actually have something I think I'm happy enough about to use. There's already a tool to do this, but I was not really impressed with isisetup. After considerable pain to find the source code (download links that resolve to 192.168. addresses are niice), I found that it was pretty old and had lots of weird hardcoded things like server names, and it wants to be a git porcelin with its own set of commands for manipulating the /etc repository. I don't want that, I just want a simple setup procedure that lets me use regular git commands to manage the repo. So instead I followed the lead of these blogs combined with David H rdeman's metastore for solving the metadata storage problem. I also hacked in a solution to the empty directory storage problem, and a few other issues with trying to use git for this thing that it was not really designed for. I'm very happy with the way it works, you just run "etckeeper init" and then can commit etc as usual with the file permissions etc included in the commits. Clone the same repo to elsewhere and again "etckeeper init" is all you need to restore those permissions (be sure to not clone the repo to a world readable directory, as there is a window when files would be readable). Automatically committing changes at the end of apt runs is also a handy feature. :-) etckeeper is currently only available from git. ftp-master is down so I can't upload packages, but both it and metastore can be built from git easily enough:

git clone git://git.hardeman.nu/metastore.git; cd metastore; dpkg-buildpackage
git clone git://git.kitenet.net/etckeeper; cd etckeeper; dpkg-buildpackage

If you use a firefox-based browser, bookmark http://mid.gmane.org/%s then right-click it in your bookmarks menu, pick Properties and enter "message-id:" in the Keywords field. Then you can paste Message-Id lines from email headers (or some debian list posts) into your browser window and it will search gmane for it. Handy. (2007-10-31: 1 comment)

I have previously posted about the difference between using a chroot and using SE Linux [1]. Theo de Raadt claims that virtualisation does not provide security benefits [2] based on the idea that the Xen hypervisor may have security related bugs. From my understanding of Xen a successful exploit of a Xen system with a Dom0 that is strictly used for running the DomU’s would usually start by gaining local root on one of the DomU instances. From there it is possible to launch an attack on the Xen Dom0. One example of this is the recent Xen exploit (CVE-2007-4993) [3] where hostile data in a grub.conf in a DomU could be used to execute privileged commands in the Dom0. Another possibility would be to gain root access to a DomU and then exploit a bug in the Xen API to take over the hypervisor (I am not aware of an example of this being implemented). A final possibility is available when using QEMU code to provide virtual hardware where an attacker could exploit QEMU bugs, an example of this is CVE-2007-0998 where a local user in a guest VM could read arbitrary files in the host [4] - it’s not clear from the advisory what level of access is required to exploit it (DomU-user, DomU-root, or remote VNC access). VNC is different from other virtual hardware in that the sys-admin of the virtual machine (who might be untrusted) needs to access it. Virtual block devices etc are only accessed by the DomU and Xen manages the back-end. The best reference in regard to these issues seems to be Tavis Ormandy’s paper about hostile virtualised environments [5]. Tavis found some vulnerabilities in the QEMU hardware emulation, and as QEMU code is used for a fully virtualised Xen installation it seems likely that Xen has some vulnerabilities in this regard. I think that it is generally recommended that for best security you don’t run fully virtualised systems. The remote-console type management tools are another potential avenue of attack for virtualised servers in the case where multiple users run virtual machines on the same host (hardware). I don’t think that this is an inherent weakness of virtualisation systems. When security is most important you have one sys-admin running all virtual machines - which incidentally seems to be the case for most implementations of Xen at the moment (although for management not security reasons). In ISP hosting type environments I doubt that a remote console system based on managing Xen DomU’s is going to be inherently any less secure than a typical remote console system for managing multiple discrete computers or blades. I have just scanned the Xen hypervisor source, the file include/asm-x86/hypercall.h has 18 entries for AMD64 and 17 for i386 while include/xen/hypercall.h has 18 entries. So it seems that there are 35 or 36 entry points to call the hypervisor, compared to 296 system calls on the i386 version of Linux (which includes the sys_socketcall system call which expands to many system calls). This seems to be one clear indication that the Linux kernel is inherently more complex (and therefore likely to have a higher incidence of security flaws) than the Xen hypervisor. Theo’s main claim seems to be that Xen is written by people who aren’t OpenBSD developers and who therefore aren’t able to write secure code. While I don’t agree with his strong position I have to note the fact that OpenBSD seems to have a better security history than any other multi-user kernel for which data is available. But consider a system running Xen with Linux in Dom0 and multiple para-virtualised OpenBSD DomU’s. If the Linux Dom0 has OpenSSH as the only service being run then the risk of compromise would be from OpenSSH, IP based bugs in the Linux kernel (either through the IP address used for SSH connections or for routing/bridging to the OpenBSD instances), and from someone who has cracked root on one of the OpenBSD instances and is attacking the hypervisor directly. Given that OpenSSH comes from the OpenBSD project it seems that the above scenario would only add the additional risk of an IP based Linux kernel attack. While a root compromise of an OpenBSD instance (consider that a typical OpenBSD system will run a lot of software that doesn’t come from the OpenBSD project - much of which won’t have a great security history) would only lose that instance unless the attacker can also exploit the hypervisor (which would be a much more difficult task than merely cracking some random daemon running as root that the sys-admin is forced to install). Is the benefit of having only one instance of OpenBSD cracked due to a bad daemon enough to outweigh the risk of a Linux IP stack? I’m sure that the OpenBSD people would consider that a better option would be OpenBSD in the Dom0 and in the DomU. In which case the risk of damage from a root compromise due to one badly written daemon that didn’t come from OpenBSD is limited to a single DomU unless the attacker also compromises the hypervisor. When working as a sys-admin I have been forced by management to install some daemons as root which were great risks to the security of the system, if I had the ability to install them in separate DomU’s I would have been able to significantly improve the security of the system. Another flaw in Theo’s position is that he seems to consider running a virtual machine as the replacement of multiple machines - which would be an obvious decrease in security. However in many cases the situation is that no more or less hardware is purchased, it is just used differently. If instead of a single server running several complex applications you have a Xen server running multiple DomU’s which each have a single application then things become much simpler and more secure. Upgrades can be performed on one DomU at a time which decreases the scope of failure (which often means that you only need one business unit to sign-off on the upgrade) and upgrades can be performed on an LVM snapshot (and rolled back with ease if they don’t succeed). A major problem with computer security is when managers fear problems caused by upgrades and prohibit their staff from applying security fixes. This combined with the fact that on a multiple DomU installation one application can be compromised without immediate loss of the others (which run in different DomU’s and require further effort by the attacker for a Xen compromise) provides a significant security benefit. It would be nice for security if every application could run on separate hardware, but even with blades this is not economically viable - not even for the biggest companies. I have converted several installations from a single overloaded and badly managed server to a Xen installation with multiple DomU’s. In all cases the DomU’s were easier to upgrade (and were upgraded more often) and the different applications and users were more isolated. Finally there is the possibility of using virtualisation to monitor the integrity of the system, Bill Broadley’s presentation from the 2007 IT Security Symposium [6] provides some interesting ideas about what can be done. It seems that having a single OpenBSD DomU running under a hypervisor (maybe Xen audited by the OpenBSD people) with an OpenBSD Dom0 would offer some significant benefits over a single OpenBSD instance.

• [1] http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot/


• [2] http://kerneltrap.org/OpenBSD/Virtualization_Security


• [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4993


• [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0998


• [5] http://taviso.decsystem.org/virtsec.pdf


• [6] http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf

Share This

In the last few days, I have replaced the two 20 inch CRT monitors that I have hardly used the last years with two 20 inch TFT displays, and my company (finally) gave me a 19 inch TFT display to accompany my notebook display at work. Maybe I should take that as a hint that they want to see me in the office more frequently rather than in my home office which I generously use these days. At home, I built a “new” computer from mainly used parts to drive the two 20 inchers. I have learned a lot about X in the last days, but spent too much time with it. I have been running my Desktop with older X and two CRTs for quite some time, but I hardly ever used it due to the setup of my now ex-flat. Back then, I learned that the “two monitors, one display, one screen, one desktop” option of X was called Xinerama and statically configured: You write down your display layout in xorg.conf and it uses it. Configuration changes mean restarting the X server. KDE notices Xinerama automatically, designates one monitor the “main monitor” and displays its panel there. You can move windows from one monitor to the other one, but changing virtual desktops always changes what both monitors display. This is not really what I want, since I often have “static” contents (news reader, mail reader, chat windows, help screens etc) on one monitor while I do my normal work on the other monitor, which involves changing virtual desktops. So I was rather happy when I learned upon the arrival of the external TFT display for the notebook that you can work without Xinerama. In that case, the X server comes up with one display and two screens, which KDE uses to display two independent desktops which can be independently configured, but can both be accessed with one mouse and one keyboard. For me, this means that I finally can independently change virtual desktops on both monitors, but pay the price that I cannot display a certain virtual desktop on monitor 1 now, and on monitor 2 in five minutes, and that a window opened on monitor 1 is never going to be shown on monitor 2 without serious interference. This looked ok for me. Additionally, you can use different font sizes on the different monitors as defaults, which comes in handy if both monitors are blatantly different in size (which is the case with the notebook and its external monitor). However, with that setup, KDE seems to be challenged when it comes to saving the configuration. Some things (such as desktop background and panel config) seem to save fine, desktop independent, other things (such as open windows and their position) are lost when the session exitst. My daily visit to Kevin&Kell (which used to be in a browser window that was saved with my session) has badly suffered since then. Then, a few weeks ago, somebody talked me into trying the X server from experimental. Which is when my dual-desktop setup ceased working. The nice people on #debian-x told me that Xinerama is a thing of the past, and is currently in the process of being replaced by Xrandr 1.2. The removal of “my” two monitor, two screens, two desktop setup is collateral damage, and if I still want that behavior, the X.org upstream considers this an issue to be handled by the Window Manager / Desktop Environment now. Gee, thanks. That’s what I call a regression. After spending half a day cursing and ranting, and even considering to go back to lenny’s (or even etch’s) X.org, I finally settled on going with the “new” way as I was going to lose my independent desktops sooner or later anyway. Again, with the friendly help of the people on #debian-x, I found out about a lot of advantages of the latest X servers. In most basic cases, the latest X server does not need a configuration file any more. It autodetects your hardware and chooses whatever modes it finds optimal. It does a pretty decent job in doing so. If one wants to influence how the X system comes up, once can always write an Xorg.conf file - the configfileless server even writes the “virtual config file” it uses to the log as a starting point. Additionally, almost everything regarding screen layout can be reconfigured at run time using the xrandr binary from a command line. Even a hardware change (such a new monitor plugged into the powered on notebook) is correctly detected. Cute. This allows me to reconfigure my notebook depending on where it currently is and which external monitor (or projector) is connected. This can be perfected if I find out whether X offers a hook to plug a reconfiguration script into that is called when the X server starts or when the system is waking up from standby or hibernation with the X server running. A lot to do, and great potential for elegant stuff. However, while I am talking about hibernation, this is a downside of the new driver: When the system wakes up from hibernation, the X server sometimes confuses itself enough to become nearly unuseable: I had it become psychotic when plugging in the external monitor (which can do 1600x1200 points) after waking it up from hibernation at the office. The internal display can only do 1400x1050, and the box thought that the external monitor only had 1050 y axis pixels, displaying bit garbage in the lower part of the big monitor, and showing a useable, but unintelligible panel. When opening any browser or any other application with considerable text amounts in the window, all fonts become unreadable once one scrolls down. Restarting the X server helps and everyting is fine. But I do not use hibernation to force myself to log out of X after waking up. After going back to the “one monitor mode”, the X server now thinks that my virtual desktop is 1600x1200 and only shows 1400x1050, with dead space at the right and lower side of the virtual desktop. xrandr does not allow me to reisize the FB below 1600x1200. No idea what’s going on here. In most of the cases, calling xrandr --auto for each output will fix the issues at run time, but sometimes a session restart is needed. Code needs to stabilize quite a bit before becoming useable in production. There are a few disadvantages that will remain: Both monitors will change their contents when the virtual desktop is changed, and both displays will use the same default font size (which might be inappropriate if both displays are of different size). But I think, when the issues are cleared up, that I can live with these disadvantages. The “new” desktop system that I built has a Matrox G450 dual head graphics card, and unfortunately, the Xrandr 1.2 enabled X server from experiemental has shown to be unuseable: Upon some mode changes, the X server goes into an endless loop and proves itself to be unkillable short of SIGKILL. And if it dies, it sometimes pulls the entire system with it. There is a corresponding bug in the upstream BTS, but it hasn’t received any noticeable attention by the upstream developers. So I might find myself configuring one last Xinerama config before I can finally completly migrate to Xrandr 1.2 on the desktop as well. Then I’ll probably need to bug the KDE upstream people to implement a two-desktops-on-a-single-screen feature in one of their future versions so that I can get my independent-desktop-things back. But that’s a far far away future.

On Saturday I turned into Mr. Handy Man. Our CD collection is getting rather large (~270 CDs), and the current CD rack is filled to capacity, with a 3 foot tall tower of CDs next to it. I decided to build a new one myself, there being no decent and cheap CD racks designed for this many CDs. I measured and planned and drew, and eventually had a design for a rack nearly 6 feet high, and more than a foot wide [1]. My Dad and me went down the local timber yard, bought the pine (which they cut for us) for a mere £10, and set about building it. The building went very well. My Dad is pretty damn good at DIY so we had all of the tools we needed, and a few hours later we had our new CD rack, and Vicky had caught the sun [2]. We did have a few minor problems -- one shelf was sticking slightly out (five minutes with a chisel sorted that), and the MDF back was put on backwards, showing the huge price sticker to the world, but on the whole its a damn fine and solid CD rack, which holds a grand total of 350 CDs, for £15. We have two and bit shelves free, so have space for another 80 or so CDs... shouldn't take long to fill that. Of course, we then spend much of Sunday afternoon filling the damn thing... To celebrate we bought Solid Bronze, the Best of Beautiful South, and a Black Sunday by Cyprus Hill. [1] The exact measurements for anyone wanting to build their own: 1700mm x 370mm x 150mm, in 15mm pine.
[2] That's a polite phrase for having a pink nose and arms.

...at least, in my opinion (which is obviously biased, let's admit that). There are several reasons for this loss:

• Strategic choices: Bernard Laporte deliberately chose to use the same tactic against England and New Zealand. However, the tactic that worked against New Zealand failed against England, mostly because that tactic...is just the play of the English team. So, as we say in French, "les Bleus" entered the game of England and therefore made the task easier for them.
• The choice of players. This is the result of the previous item. Reconducting the entire team that won against NZ was IMHO a bad idea. It is not a scoop that I dislike Rapha l Ibanez or Fabien Pelous and I would rather have seen the punch of Dimitri Szarzewski or, for once, S bastien Chabal beginning the game (actually, he entered pretty quickly because of Pelous' injury).
• Several failures to occupy the English side with kick play. In many occasions, kick shots by either Beauxis, Traille or Jauzion missed their target. This is IMHO the main reason for the defeat.
• Too many drop tentatives. When they were in the English side, why the hell did they choose to kick drops several times instead of just play. That sounds like a fear of not scoring and the French lost several key balls with that miserable tactic.
• Too many lost balls in mauls. That is not only a failure by the French but also good defense play by the English team.
• Discipline. It happened only once (high tackle by Dimitri Szarzewski) but that was *the* moment where no error was possible and it offered an ideal penalty kick to Wilkinson.
• Bad luck. We can't rule out that one. The difference is 5 points: this stupid 1st minute try....and the missing 50 centimeters on Chabal's action in the last minutes.

Some *bad* reasons for the English victory:

• Johnny Wilkinson influence: this is untrue. Apart from his drop goal, he missed penalty kick tentatives and his kick play was not brilliant during the same. I much preferred Andy Gomarsall during that game.
• Scrums. They didn't crush the French scrum which is one of the satisfactions of that game. The English team even had to cheat slightly during 1st half time to win their scrums.
• Good play. No. Watching the game again, there was as many bad choices in the English side than in French side. I can only enhance their defense, not their attack. So, as I wrote immediately after the game, that one was one of the worst matches in the entire WC.
• The referee. Before the game, some French newspapers were doubting of Mr. Kaplan because he's South-African (funnily, some English newspapers were also doubting because he was supposed to advantage England's opponents in the past). He was indeed perfect. Anyway, everybody knows I never blame referees in sports.

I've hacked a lot of handy features into mr. Some more examples follow. I've ommitted noisy output from the various revision control systems. Registering existing repos:

joey@kodama:~/tmp/scratch> git clone git://git.kitenet.net/mr
joey@kodama:~/tmp/scratch> svn co svn://svn.kitenet.net/joey/trunk/src/packages/alien
joey@kodama:~/tmp/scratch> mr register mr
Registering git url: git://git.kitenet.net/mr
joey@kodama:~/tmp/scratch> mr register alien
Registering svn url: svn://svn.kitenet.net/joey/trunk/src/packages/alien
joey@kodama:~/tmp/scratch> mr up
mr update: /home/joey/tmp/scratch/alien
At revision 13492.
mr update: /home/joey/tmp/scratch/mr
Already up-to-date.
mr update: finished (2 successful)

Command-line modification of the ~/.mrconfig file, and the ability to skip a repo based on an arbitrary shell test:

joey@kodama:~/tmp/scratch> mr config tmp/scratch/alien skip='[ $(hostname) != foo]'
joey@kodama:~/tmp/scratch> mr up
mr update: /home/joey/tmp/scratch/mr
Already up-to-date.
mr update: finished (1 successful; 1 skipped)

Tracking and warning about deleted repositories. Useful if, like me, you have dozens of repos checked out on dozens of machines:

joey@kodama:~/tmp/scratch> mr config tmp/scratch/mr deleted=true 
joey@kodama:~/tmp/scratch> mr up
mr error: /home/joey/tmp/scratch/mr/ should be deleted yet still exists
mr update: finished (1 failed; 1 skipped)
joey@kodama:~/tmp/scratch> rm -rf mr
joey@kodama:~/tmp/scratch> mr up
mr update: finished (1 skipped)

(Tracking of repo moving is still TODO.) Running mr from inside a repo operates on only that repo. Useful when you can't be bothered to remember what revision control system a particular repo uses. ;-)

joey@kodama:~/src/mr/debian> mr commit -m "bugfixes developed while writing blog post"
mr commit: /home/joey/src/mr (in subdir /home/joey/src/mr/debian)
Created commit 2f861a4: bugfixes developed while writing blog post

It also supports cvs and bzr now.

I got a little older yesterday. I'm 26 now. It was a fun day. It started out by going to the Federal Police to get my temporary id. The agents who register foreigners are on strike for the last week or so, but there was someone there dealing with the registration. So my name got put in a big book and I've got a piece of paper that will let me back into the country next week.

Now for the actual birthday. A bunch of use went out to a place called Pinguin (yes, Penguin in Portuguese). We had some chopp, some very good garlic bread. Then since it was my birthday we got a cotton candy cake, and a nice little Penguin!

Just a note on the 2038 overflow post, libqof1 has had this support since v0.7.0 which was included in the Etch release.
pilot-qof (>=0.1.1) uses 64bit times from libqof1 and also made the Etch release so dates on all devices supported by pilot-link in Etch can be handled as true 64bit values already, as long as the relevant date is part of the main 4 Palm applets, calendar (datebook/appointments), expenses, tasks and contacts(addresses).
Note that although the Palm 'contacts' applet supports birthday reminders, this extension of the contacts database is not supported by pilot-link because it has yet to be reverse engineered. All dates entered into tasks, expenses and calendar are supported so if you create genuine appointments for each birthday (instead of using the Palm reminder support in Contacts), these appointment dates will be safe from overflow until long after our Sun has died, at which point dates based on the rotation of the Earth become irrelevant anyway.

(Sometimes, it would have been handy to have 48bit systems - if everyone adopts 64bit time, someone is going to have to come up with a calendar *not* based on the rotation of a planet or any other object as all physical matter - even the universe as we know it - becomes temporary on a 64bit timescale. It is hard enough to grasp geological time, let alone 64bit time.)

The latest version of mergeant, a GNOME GUI for database manipulation, has finally reached the Debian archives, closing all bugs which were open against the previous one. Thanks, Lo c, for the sponsorship.

As a side note, this version of mergeant has got an implicit pointer conversion bug due to missing includes in two different files. This was my first chance to test the bug forwarding feature of the Bug Triaging and Forwarding Tool (my project in Google's Summer of Code 2007). It isn't as comprehensible as I would like due to limitations on bugzilla, but was pretty handy nevertheless.

From time to time the question comes up on Debian mailing lists of whether debian directories in upstream tarballs are harmful and what do do about them. I tend hide from such threads, since all upstream tarballs I create contain debian directories. But I realised tonight that the common wisdom from those discussions is wrong, or at least incomplete. Here's why. First, it's important the notice that this is not a problem in the rpm world. Putting an rpm spec file in an upstream tarball is considered good practice. There's no downside; if a packager needs to change how the package is put together, they can replace the spec file. And users can run rpmbuild on the tarball and get an rpm spit out. Handy. So, then, why is the equivilant practice a problem in the debian world? Three intertwined reasons:

1. The tools assume all files in debian/ are good. There's no way to make debhelper not install a debian/init script, or any similar file. Note that this problem only affects helper tools like debhelper; the core deb building tools only care about a few files that are in every debian directory. Effectively, debhelper, and (possibly) cdbs are the only tools with the problem currently.
2. The source package format doesn't support removing files from the upstream tarball. This is a pretty silly limitation that any source format better than the current one should override. If wig and pen was ever implemented, it should support some means of deleting files.
3. Package maintainers fear that they can't get upstream to make changes, or not fast enough, so worry about getting into a mess with files in an upstream debian/ that can't easily be fixed.

I feel that if any of these three problems is solved, an upstream debian directory is ok. #3 can be solved to some extent for some packages, though these solutions will always be the least satisfying. It's tempting to try to solve #1 in debhelper. I could add an --ignore switch, to make debhelper commands not act on a given file in the debian directory. (Update: done in version 5.0.57!) The best place to solve it, though, would be in the source package format. I'd be happy to see wig and pen be implemented, but would be happier to see us moving toward using a distributed revision control system as a source package format. Consider a source format that replaces .diff.gz with .git.tar.gz.

Scott, I would have expected a little more from you than your previous post on why you chose bazaar! Update: my initial post was offensive towards Scott, so I edited it a little, following a good discussion with Scott via Email. Even though his post didn't make it explicit, his post was meant to be a reaction to someone else praising Git above everything else. Or, in his words:

You're responding with a defence of git because I posted a defence of bzr in response to championing of git.

I decided to leave most of the original post untouched, nevertheless, but please read it in this context. I guess the sensible conclusion is (as always): to each their own. Inline updates are enclosed in [brackets].

---

Git is less of a version control system than it is a filesystem and a means to communicate among developers, and when used in that sense, it's extremely powerful and intuitive to use. And it is also a version control system, like Bazaar. It's blazing speed isn't the only killer feature. By no means, however, is it "heavily optimised for the 'I only apply patches' development model, at the expense of ordinary development models" [anymore]. It also supports centralised workflows just as well as it supports distributed approaches, and you can switch between them [this is not really true when compared to how Bazaar mimiques CVS/SVN behaviour; Git cannot do that]. Here are the git commands needed to do the same things Scott showed off in your post:

$ cd myproject
$ git init
$ editor .gitignore
$ git add .    # git rm ...

Let's branch before we commit. checkout -b is a shortcut to create a branch (git branch myproject-foo) and immediately switch to it (git checkout myproject-foo):

$ git checkout -b myproject-foo
$ git commit

Git keeps all branches within the same repository and lets you switch between them. Now, that is a killer feature: whether I'm versioning code or stuff like webpages, I often have external pointers to my code. For instance, I may have libfoo as a sibling of foo-ng and the latter refers to libfoo in the Makefile. If I wanted to try a new approach in libfoo, I'd have to change foo-ng's Makefile to point to libfoo-newbranch instead, or juggle directories around. That sucks. With git, I just checkout a different branch in the same space:

$ git checkout master

And even better: if you don't like it, you could just as well copy the repository to create a separate (remote) branch from which you can later pull or cherry-pick changes to the main branch:

$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master

Now back to your steps, and I'll stick to the git way of branching. Note how git does not differentiate between pulling and merging in the sense that you do. If there are no local modifications, git just fast-forwards the branch with the commits on the master:

$ git merge myproject-foo

Even better, say you don't want the last two commits:

$ git merge myproject-foo~2

Unless git can fast-forward, it also treats a merge as a single commit and the ancestry information allows you to inspect its component commits just like you would. gitk is another killer feature, which I believe bazaar copied from git, just like the bazaar folks adopted the concept of rebasing, which basically lets you rewrite history quite freely, another killer feature (which can be quite badly abused if you don't know what you're doing). And then there is git bisect and git-svn and git filter-branch and git describe and git stash and gitweb and, and, and So if I compare the git commands I used to the way you used bazaar, I fail to see much of a difference. Do you? It is true that git comes with an astounding number of additional commands, most of which you never have to use, but which are available to the user [but its interface is a huge improvement over GNU arch, nevertheless, and if only because the commands are named more logically and revisions and branches do not have to adhere to one of the strangest syntaxes ever]. I don't deny that their sheer abundance is overwhelming and confusing at first (a general rule for Git for beginners seems to be just to ignore ever command with a hyphen in it). But once you get out of the newbie stage (it took me about two weeks, the duration of Debconf7 to become an acquainted git user; in fact, David Nusinow placed me among the ranks of real git wizards Pierre and Keith before the conference was over) arghs, I hate long remarks in parenthesis; once you leave the newbie stage, you'll appreciate all these commands, which make it really easy to script complex tools with git, making any plugin architecture pretty obsolete. Finally, I found myself trusting git way more than any other version control system I've tried simply because it's so transparent and you are allowed to edit stuff under .git, which is mostly plan text files (and objects, which you [could but] don't have to touch). It's transparent, and it stays true to the Unix way of letting small tools do their jobs instead of the monolithic approach. NP: Enchant: Tug of War Update: Carl Worth has a similar beef with people thinking that Git is too complicated and has ported a chapter from a book on Mercurial to Git to show how that's not the case. It's a good read. Update: Scott replied (quoted with permission), and I include my replies inline:

"I can tell you why you chose bazaar: because you had to, because you are being paid to use it."

Sorry, that just isn't true. I'm paid to lead the Ubuntu Desktop Team; this has nothing to do with version control, except that the various upstreams and packages use different systems.

I am sorry about this accusation. It was low.

You appear to miss my point about Git, or maybe I didn't make it strong enough. It's not that I don't understand it; it's that I had to take time and effort to understand it. And I've noticed that every reply to my post misses out the fact that with Git, you have to take action to ensure your changes are actually incorporated into the commit; either with git add or commit -a. This exactly the kind of anti-social behaviour that I have issues with.

Well, Git people call this a feature and it is very handy, but I see your point. There is no way to configure git-commit to always include -a, so you'll have to work around it:

git config alias.ci 'commit -a'

This creates git ci to do exactly what you want. You cannot overwrite commit that way though. But it could be trivial to add a configuration option to git-commit, if you think that the way that Git exposes the index is an adoption-stopper:

$ file -L =git-commit
/usr/local/bin/git-commit: POSIX shell script text executable

Your post also introduces yet more over-complication by demonstrating about making a branch (in an empty branch) before you commit.

Your post does the same ("A common operation is realising that the commit you re about to make should really go on a new branch for now"), which is why I did it. You don't have to do that at all.

(Side-bar: bzr's design also permits multiple branches within the same repository.)

So I read the manpage and found bzr init-repository, but no way to add a branch to an existing clone, and also no way to switch between branches within a clone. In your original post, you claimed: " Bazaar s command set works the way you do." Well, the way I work is by "switching" between or "checking out" a new branch in-place, but I could not trivially find the command to do this. This is probably because I have not invested enough time into understanding Bazaar, but isn't that what your claim is all about: that "[you] had to take time and effort to understand [Git]" and that Bazaar just works for you?

My post was why I choose bazaar, and why I have rejected other revision control systems that I have attempted to use.

So why did you post it? Surely because you wanted to express your preference over Git. In doing so, you made a couple of claims about Git which are simply untrue, which is why I replied. And the reason I replied is simply because other people who try to make a choice between Git and Bazaar may find your post and take away from it the information that Bazaar is superior to Git, which it is not.

I'm glad that you prefer a different system; but please don't insult me by suggesting that I'm being paid to use the one I prefer, or that I haven't bothered to learn one I'm "slagging off".

But you did slag Git in that you basically present its shortcomings side-by-side to Bazaar's greatness, which is a common PR/marketing thing to do. So just like I failed to create an in-place branch above because I did not bother to learn Bazaar, you did not bother to learn how to do with Git what you showed off with Bazaar, or else I'll have to assume you would not have written up the comparison as you did.

I have to use git as much as I use bzr, and I simply prefer bzr.

That was not the message I took from your original post.

My job involves working on other peoples scientific codes, and recently I've been experimenting with using GIT as a VCS. Its very handy for making a quick repository while you change one or two files, nice and lightweight. What distinguishes science codes from other software projects, both open-source and proprietary, is the comparative lack of formal releases. Often the developers are the users, making changes for their own use. They make a model, write a paper, done. They'll take their old code and edit it to add features, but don't plan on "releasing" it in any formal way. So, often you get a tarball from a fellow researcher with the name 'astro.tar.gz', and beyond the paper describing the science, you'll be lucky to find a changelog. Online repositories, test suites, etc. are a rarity. So I've been wondering how to improve on this, in terms of refactoring, etc. and how GIT and other Distributed VCS's can best be used in science. Some ideas:

• Keep a separate cleanup branch. When working on a code to add new functionality, keep a branch for simple bugfixes to the original code. Git makes it easy to merge branches, so develop features on a per-feature branch, and keep fixes to a dedicated 'cleanup' branch that the original developer could pull from.
• Tag or label the changes in the Git Changelog. Current labels (the word tag is overloaded) I've been using are:
  • BUGFIX: for fixes.
  • RF: for refactorings
  • DOC: for when adding comments to code I didn't understand.
  • NEW: new functionality
  This makes it easy for someone to see if they want to pull these patches into their version of the code.

Has anyone else seen similar techniques or tags in use, particularly for science ? Tags debian, git, coding

The UCI Road World Masters are showing on Eurosport and BBCi.
BBC have posted the BBCi schedule in a handy form. (Thanks BBC!) Most BBCi video channels are visible to most of Western Europe at 28 east (instead of the UK-centric beam that is used for BBC Two and the other national channels). Eurosport’s site still won’t give simple listings, so here’s their schedule for the free-to-air channel at 19 east as far as I can make out: Wed 26.09.2007 - ITT Women 16:00-17:30 CET Thu 27.09.2007 - ITT Men Under 23 11:30-12:30 CET, highlights? 12:30-14:00 CET, ITT Men 16:00-17:00 CET Fri 28.09.2007 - ITT Men 13:15-14:00 CET Sat 29.09.2007 - highlights? 09:00-12:45 CET, Men U23 16:15-18:00 CET Sun 30.09.2007 - Women 09:00-0930 CET, Men 10:30-14:00 CET, Men (highlights?) 16:00-17:30 CET Mon 01.10.2007 - highlights? 15:15-16:15 CET I think it will also be on RAI Tre at 13 east, but I don’t know if that will be free-to-air. Show times should appear here the day before broadcast. Which other free-to-air satellite broadcasters are showing this?

I know this post probably won't make it to anybody applicable but the company where I work, Webacom Media Corp. in Nanaimo BC, has an opening for an experienced web designer. Contact me at randy@webacom.com if you are interested.