At the moment it seems that about half the USB flash devices on sale are listed as “Vista ReadyBoost Ready“. I recently bought an 8G USB device that I returned because it could only sustain 4MB/s writes (not much fun for backing up 4G+ of data). So I’ve been wondering whether I should get a ReadyBoostReady device. ReadyBoostReady only means that it is faster than other devices in some ways, it has no inherent feature difference. After some searching I found a FAQ about ReadyBoost [1] which explains what it requires. It seems that ReadyBoost needs “2.5MB/sec throughput for 4K random reads and 1.75MB/sec throughput for 512K random writes“, which isn’t really a lot. About 5-6 years ago I was running some machines with 4 disk RAID-5 arrays that could sustain 3MB/s writes for significantly smaller block sizes (maybe 12K), given that random access is something that disks are really bad at (physical movement of the heads is required) and something that flash is good at) it gives an indication of how low the performance bar is for ReadyBoost. I’m sure that a device which meets the minimum specs would do some good if you have a single disk that’s not overly fast. But if you have a decent RAID array for swap then I doubt that the minimum requirements for ReadyBoost would give a benefit. As for doing bulk transfers, it seems that while ReadyBoost Ready devices will have consistent good performance across all their storage (apparently some devices perform better for the first blocks so that people who use FAT based filesystems can get good performance from their FAT) they won’t necessarily have particularly good performance for bulk IO (1.75MB/s is pitiful when you want to copy DVD images). There are some USB flash devices that are marketted as having high performance and which are supposed to sustain >20MB/s, but I’m unlikely to find them going cheap at my local electronics store. I had hoped that ReadyBoost would be demanding enough that the ReadyBoostReady devices (which aren’t the cheapest flash devices on sale but often aren’t too expensive) would satisfy my requirements.

• [1] http://blogs.msdn.com/tomarcher/archive/2006/06/02/615199.aspx

Share This

PTS again: LowThresholdNMU and Debian Maintainers As promised, the PTS is now able to show two new pieces of information about a given package:

• the fact that its maintainer has listed herself in the LowThresholdNmu list, pointing to the wiki page for more information or specific rules. (See gtkmathview for an example.)
• the fact that the package can be uploaded by Debian Maintainers, i.e. that the source package has a Dm-Upload-Allowed: yes field. (See debtorrent for an example.)

Both information are shown as unary "tags" (i.e. they can either exists or not, but they don't have any associated value) in a new field in the general information section of the page called "Maintenance info". Now both tags are implemented as "acronym" HTML elements, but if you are good at graphics don't hesitate to contact me, that would be the right place for two fancy icons!

The economics of programming languages point to Rails being significantly better than what went before it. I got to thinking about this when reading a comment on a site I like to read, which said:

Rails in itself is, to me, not that impressive. It does a lot of things right, but it does probably just as many wrong. Not the least of which is scaling.

It seems that these sorts of "after the fact" "I know better" comments are a dime a dozen in the world of programming discussions. It's easy to come along after something's been built and puff yourself up by pointing to defects in existing systems and show that, therefore, by comparison, you're a clever fellow. That's not my point, though - what I wish to explain is that yes, Rails really was that much better than what was around before it came onto the scene: "Switching costs" between languages are high. Less so for really sharp programmers, but for the masses that use one or two languages, learning a new language, tools, deployment, etc... is a big step to take, with potentially high risks. Even most A-list programmers I know use a few languages at a time - it's simply easier if you're not tripping over your own feet by switching to a different system every day. "Flow" is easier to attain when you're ensconced in the thinking of one language. For companies, this effect is magnified, and switching to something new is not done lightly. Since companies are beginning to explore Rails, successfully, I might add, you have to conclude that the big step into the unknown was worth it for some reason. Especially considering that a number of other languages rushed to copy various nice aspects of Rails, lessening the need for users of those systems to consider taking the leap. Of course, that's not to say it's a perfect system, without reproach, or has no negative aspects, but in the spirit of honesty, and credit where credit is due, Rails really did move things a step forward, and the willingness of people to incur high switching costs to obtain its benefits is strong evidence of that.

The topic of a groupware with SyncML support is still bothering me. What are people using, and with how many users? Please tell me (I'll update this article.) Looking around, it seems there aren't that many open source (or even commercial) projects if it should be usable on Linux (Clients, too) and be reasonable priced (which pretty much kills Lotus and similar big enterprise solutions AFAIK.). Oh, and a web frontend is an absolute necessity, too, but that's usually not a problem.

• Open-Xchange, our current solution. The community seems to be quite dead (judging by the mailing list), and what'll happen on with the commercial variants is unclear to me, but at least there's some activity. We're moving away from OX because there are too many bugs both in the groupware itself and in the SyncML part.
• eGroupWare: The top candidate to replace OX. Looks quite good, there is a very active community, recently an additional developer has joined who will focus on the SyncML part. Most of the development is, however, done by only very few people, and apparently the project is about to fork because these people do not agree. (It's not yet clear if it will come to a fork or if egw 2.0 will properly replace the 1.x branch.)

There are some other groupware projects out there, and I might do them injustice, but on a first glance development seemed to either have stalled as a whole or at least regarding their SyncML support. I know of OpenGroupware.org (last news of SyncML support from 2005), Kolab (No production quality Web frontend, and I can't find much about SyncML either), Horde (Hmm. I didn't like the classical horde webmail very much, but "Horde Groupware" might be worth another look. The status of the SyncML part is not clear, judging from the website.) and phpGroupWare (egw's ancestor, when I last looked development seemed to stall, and the information I found about its SyncML support is somewhat scant.) The open direcory project lists some more, but I haven't looked at these.

With Kel Modderman’s help, we now have a working atl2 driver for the Eee PC. This brings the Debian-eeepc project one step closer to providing a pure Debian replacement for the Xandros OS that ships with the unit. Now that Asus has released the GPLed source that was missing before, we now just have to ensure both the atl2 and asus_acpi modules get merged upstream. The driver for the wifi in the Eee isn’t under the GPL, however, and therefore only works on the Xandros kernel provided with the default OS. Since I really can’t live without wifi and it is not my first choice to buy replacement hardware, in the interim, I’m living with using the Xandros kernel and modules on Debian. I can learn from studying the Xandros components in action, but it’s not a solution I’m happy with in the long term. The Debian-eeepc project’s goal is to produce a pure Debian solution, at least as far as that is possible given the hardware present in an unmodified system. On that front, I think the best bet is for ath5k to support the particular Atheros chip in the Eee. (Yes, I know about ndiswrapper, but for both technical and philosophical reasons I won’t use it.)

I fully expect to be told that this is Evil, Bad and Wrong, but what are the drawbacks of moving a MakeMaker tarball into the local cpan download tree and using CPAN::install on it like this? Other than the usual hackiness-problems with that early draft, I can't see a blocking problem with it. The CPAN shell handles the dependencies. (Don't worry, the eventual debian package will use dpkg to install the dependencies.) (2007-11-29: 1 comment)

Shintaro wrote an interesting post about Rakugo (a form of story-telling) and Mottainai (a particular form of gratitude that is now becoming an English word in reference to environmentalism) [1]. My definitions of the two words are poor, I encourage interested readers to read Shintaro’s post for the links. Recently I had been considering which jobs are most like a senior programmer position in terms of skills and the work environment. It occurred to me that a chess-master has a job that bears some similarities to that of a senior programmer. A chess master might play a Simul [2] which compares to a programmer or sys-admin fixing lots of small bugs at the same time. In a serious chess tournament up to seven hours may be on the time clocks - not an uncommon amount of time taken to find a subtle bug in a program. For quick chess games as little as three minutes may be on the clock for all your moves - similar to the situation where the network goes down and the CEO is watching you fix it. The intellectual abilities for playing chess and programming have many obvious similarities, memorising significant patterns to avoid re-calculation, having a large mental register set to allow considering complex situations or multiple possibilities at the same time, and being able to spend many hours thinking about a problem. With that in mind one thing that particularly interested me in Shintaro’s post was the reference to a Japanese apprentice system where “They are trained at his masters house from early years maybe after junior-high, living and caring his boss every day life, like Go or Shogi players“. I wonder how this could be used in other cultures and career paths (such as English-speaking countries and computer programming). Probably the “every day life” part wouldn’t be well accepted. When comparing with the high-school experiences that seem typical of people in the computer industry an apprentice program has a lot to offer. A small amount of pay (as opposed to school-fees) and an environment where laws apply (IE almost no bullying) are both significant benefits. Anyone who is reasonably intelligent is most likely to find that they can’t learn anything from the teachers in the final years of high-school because most teachers don’t know much about the subjects that they teach and in the instances where the teacher does know more the class environment doesn’t permit teaching more advanced material. Someone of average intelligence who has worked for 5+ years in an industry can always teach a beginner some useful things so there is some obvious potential to learn. There is a meme that apprentice programs only apply to trades not intellectual work. This meme is probably correct when applied to many categories of office work but seems obviously wrong when applied to computer work. My observation is that at most places where I have worked there has been a significant amount of time from the most productive, skilled, and highly paid people spent on tasks that are way below their skill level - and often requiring skills that they don’t have. One example is when I was working for an ISP in a senior sys-admin position, when things really went wrong on the network I was usually the person to fix them - but I spent moderate amounts of time fixing hardware problems with desktop PCs and some time fixing Windows networking issues (of which I know little). Some of the problems I fixed could have been fixed by a 16yo apprentice who would probably have taken less time to fix them while also having a much lower hourly rate - and in some cases may have done a better job). I’m not sure that having an apprentice assigned to an individual programmer would work well, but having one per team should. I have previously written about how to get the benefits of a university education without attending university [3] so I don’t think that the inability of such apprentices to attend university would necessarily be a problem.

• [1] http://intrajp.no-ip.com/nucleus/index.php?itemid=707


• [2] http://en.wikipedia.org/wiki/Simultaneous_exhibition


• [3] http://etbe.coker.com.au/2007/10/04/ideas-for-a-home-university/

Share This

Sooner or later, I will conduct a series of interviews as well as a community survey among Debian package maintainers as part of my research. The motivation for my research is to improve the workflows in the Debian project. How could I make you take part in such a survey? A key challenge and necessity of a survey is to ensure a high degree of participation, or else the responses cannot be read as descriptive of the entire group. Well-formulated questions and a smart way to present them are prerequisites. For instance, I'd consider it quite counter-productive (somewhat ironic even) to ask Debian package maintainers to hit radio buttons on a web form. Instead, participation should require the use of tools with which we are familiar. Another way to get people to respond is by showing how their time will help the project. This assumes that the research hypothesis is tangible and the whole endeavour plausible. And that people care. A third means of motivation is to reward participants. Commonly, this is done by way of a draw among all participants at the end of the survey, and a price given out to the (random) winner. Obviously, the individual's chances get slimmer with every additional participant, but if the price is right, it's still worth a try. I've been pondering for a few days on what a right price would be. Previously, Nokia Internet tablets have been hip, but would you dedicate your time to a survey where you could win one of those? Or a Neo1973 (thanks Lo-lan-do)? Or would a game console, such as the PS3 or the Wii be more exciting? Or is there something (in the same price range) out there you want and would, uh, fill for fill out the survey I mean Please take a moment and let me know which price you could not resist. Don't hesitate to provide me with a list I could just as well let the winner of the draw chose her/his favourite NP: The Pineapple Thief: 8 Days Later Update: Gaudenz Steinlin suggested a Thecus N2100.

As I wrote before, I tried to use Ubuntu Personal Package Archive for distributing up to date Gammu, python-gammu and Wammu packages. For first time I failed because I expected it to behave more like OpenSUSE build service than like Debian archives, but I was wrong, so I have to upload different version to each Ubuntu suite. Well that sounds like a work which should be automated. So I hacked a little shell script, which takes current version from unstable, updates changelog and injects it into my PPA. The hacky script is called deb2ppa. It requires dput to be configured for ppa same way as I have it and maybe has some other tricky dependencies which I do not realize right now. Anyway you can now use current Wammu/Gammu versions even on older Ubuntu releases if you wish :-). (Well you have to wait till it is rebuild, but I hope it will not take much time.)

emsource/emdebuild machine variants

Extending the customisation support in Emdebian so that the Emdebian package now becomes the source package for a machine specific variant build. Using the same principles as the machine variant handling in emsandbox, customised builds would apply patches over the Emdebian source to modify dependency chains, remove unwanted binaries etc.. emsource would use the existing Emdebian package (i.e. the package must have been cross built for Emdebian already) as the source, providing an unpacked package with the Emdebian patches already applied. emsource would use the ../machine/$machine/$variant directory instead of trunk/. Patches from the machine/$machine/$variant/f/foo/ subdirectory of your Emdebian work directory would then be applied. emdebuild would update those patches because the relevant $foo.old directory would contain the Emdebian source. The Debian source would always be available in trunk/ for comparison. Using the Emdebian package as source means that the variant build tree will not contain any .svn/ or CVS/ directories so machine/variant builds can use your preferred RCS. Expected in emdebian-tools >> 0.7.0.

langupdate and tdeb packages

The current Emdebian package search script will be adapted to handle the buildd.emdebian.org/locale repository and omit locale packages (tdebs) from the default search and package count. locale packages will be migrated into the locale repository with a cron task, removing them from the main repository at the same time. This way, uploads proceed as normal, no modifications are needed for the .changes file and the main repository apt cache is kept as small as possible. langupdate itself will use apt options to direct apt to the langupdate cache of locale packages. Unlike the main apt cache, this cache is removed after each langupdate run (actually it will probably be removed just before the packages are unpacked). langupdate will call apt to do the download and actual installation. Whilst this does mean that the installed tdebs will show up in the apt and dpkg cache data, it does prevent the other 90% of locale packages from also ending up in the main apt cache. Besides, the user should be able to see which tdeb packages are installed using the normal dpkg -l queries. tdeb packages are very small but hopefully apt-get autoclean will clean up the downloaded package files. langupdate will also automatically remove any tdebs and translation files for unsupported locales. Finally, langupdate will be run for the first time by the eventual Emdebian installer - as soon as the user has selected a timezone and set of supported locales. langupdate may well be extended in future to support handling the zoneinfo data from tzdata and the gconv data from glibc. langupdate currently uses libglib2.0-0 (because I like using it) but if anyone fancies developing it in plain C (or probably C++ to fit in better with apt), let me know. Code is in Emdebian SVN.

As last Wednesday was the second anniversary of me joining Google, I thought it an opportune time to reflect on how I've found learning Python. It's no big secret that Google is a Python shop. I'd been meaning to learn it a for a while prior to joining Google, but never found enough reason to other than because it seemed to be the cool new language. If I had a task that required me to write a script, I could do it in Perl in 30 minutes, or spend a day trying to wrap my head around how to do it Python. I think I'd known and been writing Perl in some form or other for about 9 years. I've hardly written any in the last two, which is a bit sad. I even bought Perl Best Practices shortly after moving over here, and haven't gotten around to reading it. The only Perl I write these days is for personal tasks to try and stop myself from going totally rusty. Anyway, I thought I'd write down some of my observations of Python, from a "veteran" Perl programmer's perspective. Not that I consider myself to be a shit-hot Perl coder by any stretch of the imagination... No punctuation I really like the lack of punctuation. It makes the code look a lot cleaner. I go back to Perl and my eyes bleed after trying to dereference a reference to a scalar, or something like that. It's just ugly in Perl. No curly braces/indentation for blocks The indentation thing isn't so bad. If you're using vi, you really need something along the lines of

set shiftwidth=2
set smarttab
set autoindent
set expandtab

in your ~/.vimrc What I do miss is being able to bounce on the % key to find the beginning and ending of a block. I've heard rumours of a way to configure vi to do something similar for Python code, but I haven't gotten around to finding out. There seems to a general opinion that if you're writing a block that is so big you can't find the beginning and end of it, you're probably doing something wrong. String concatenation It's always struck me as bizarre how the most obvious way to concatenate a string in Python is also one of the least efficient. In fact, there's whole studies been done into different methods of string concatenation and their efficiencies. Prototyping is easy Now I may just be ignorant of some Perl shell here, but the number of times I've written a quick Perl script in /tmp to do some proof-of-concept thing is immeasurable. The fact that you can just fire up a Python interpreter and try something quick and dirty to see if it's syntactically sane, or does what you expect is fantastic time saver. ipython makes it an even more pleasant an experience. No CPAN I was initially a bit disappointed that there wasn't something like CPAN for Python modules. In practice, using Debian, I haven't found this to be that big a problem though. List joining is wacky I still find it weird that you don't join a list by a method of the list, you do it by a method of the string you want to use to join the list together with, that is, I think it should be mylist.join(" ") when it's really " ".join(mylist). That's just always struck me as unintuitive. urllib2 doesn't hold a candle to libwww-perl I think even last time I checked with Python 2.5, it's impossible to make a HEAD request. The mind boggles. No setuid support I can't complain too much, I think I heard somewhere it's going away in Perl as well, but it was certainly very convenient to be able to write setuid Perl scripts. I miss that convenience in Python. Not that one has to write setuid scripts all that often. Regular expression handling is painful It's about on a par with Java. You just can't beat Perl's =~ operator. "There's more than one way to do it" versus only one way to do it Perl's always had the adage of there being more than one way to do things. I think that has been its downfall in terms of readability. Heck, I've written some monstrosities that I've looked back on in a month's time and wondered what on earth I was thinking at the time. I think it's far easier to write readable Python than it is to write readable Perl. I think that's about everything. I never did any real object-oriented programming in Perl, and so I tend to take a procedural approach to things in Python as well. I haven't written any massive bodies of code in Python (although I did help maintain one for about 18 months). I like Python. It's become my first choice for writing random scripts now. Now I look at Ruby like I used to look at Python when I knew Perl quite well. Ruby has some nice things (like Perlish regular expression handling), but it brings back all that punctuation noise again. I'm not in a huge rush to learn it, even though there's a lot of hype around Ruby on Rails. I think I'd rather investigate Django or Pylons

The web site www.CheatNeutral.com offers cheaters the possibility of paying single or monogamous people to offset their cheating. It’s an interesting spin on the carbon trading schemes that are on offer. www.greenmaven.com - a Google search site for Green related information. www.greenerbuildings.com - information on designing buildings to be “Green”. Binary adding machine using marbles and wood-work [1]. I’ve just been reading Accelerando by Charles Stross [2], in that book he describes the Pentagon using Babbage machines to avoid the potential of electronic surveillance. Alan Robertson has just started a blog [3]. He is a lead developer in the Linux-HA (Heartbeat) [4] project (which incidentally lists SGI as a friend due to the work that Anibal and I did [5]). Here is an interesting article about light pollution [6]. It covers the issues of observing the stars, saving energy, and reducing crime through effective lighting.

• [1] http://woodgears.ca/marbleadd/index.html


• [2] http://www.accelerando.org/


• [3] http://techthoughts.typepad.com/


• [4] http://www.linux-ha.org/


• [5] http://www.linux-ha.org/ProjectFriends


• [6] http://www.newyorker.com/reporting/2007/08/20/070820fa_fact_owen

Share This

We had a nice trip the rest of the way home from our Thanksgiving in New Jersey today. This morning we had breakfast in the Holiday Inn Express that we stayed in (very nice, new, clean, good pool and exercise room -- a good value for $109/night dual queens). We then spent the rest of our morning shopping at the Whole Foods Market. It's the closest Whole Foods to our house in Montreal -- hold it, no, it looks like the one in Portland (Maine) is closer. Who knew? We picked up a lot of hippy-dippy personal hygiene items that we can't seem to find in Montreal, and I also got a few bottles of wine to take across the border. I got a bottle of 2003 Andrew Will Cellars Champoux Vineyard -- an interesting Columbia Valley red blend, mostly Cabernet Sauvignon that I think will cellar nicely for a couple of years, but not too urgent. And I also picked up a 2004 Hanzell Vineyards Chardonnay, Sonoma Valley, which I also think will sit nicely for a year or so. We'll see -- I'm not really big on cellaring yet, but I'd like to give a few wines a try. We stopped in Amherst (Massachusetts) for lunch at the Amherst Brewing Company, which has good pub grub, generous portions, and really nice house brews available. We also dropped into a few bookstores. Books are a great cross-border purchase for Canadian residents, since their cover price is usually ridiculously skewed. For example: I got a Paul Auster hardback that was labeled at $22 US, $28 Canada. That's with the loonie trading at US$1.01! Our drive up to Montreal was pretty decent, although we had a ton of rain and snow that made the actual driving kind of sucky. We stopped in a cruddy gas station in Sharon, Vermont that didn't have a bathroom (doh!) and didn't stop much afterwards until Burlington. We got dinner at a great place in downtown Burlington, Burlington Hearth (AKA American Flatbread). Great oven-fired pizza, organic ingredients, nice atmosphere, more microbrew. Fabulous. We got across the border all right, although I needed some time to get my new work permit for 2008. Then a long snowy drive back home, where my friend Damien from Austin is staying with us for this week during MIGS. Should be a fun week -- we have lots to catch up on. tags: travel massachusetts wine vermont burlington amherst montreal

I recently was giving away some old P3 and P4 machines and was surprised by the level of interest in P4 machines. As you can see from my page on computer power use [1] the power use from a P4 system is significantly greater than that of a P3. The conventional wisdom is that the P4 takes 1.5 times as many clock cycles to perform an instruction as a P3, the old SPEC CPU2000 results [2] seem to indicate that a 1.5GHz P4 will be about 20% faster than a 1GHz P3, but as the P4 has significantly higher memory bandwidth the benefit may be significantly greater for memory intensive applications. But generally as a rule of thumb I would not expect a low-end P4 desktop system (EG 1.5GHz) to give much benefit over a high-end P3 desktop system (1GHz for a desktop), and a 2GHz P4 server system probably won’t give any real benefit over a 1.4GHz P3 server system. So in terms of CPU use a P4 doesn’t really offer much. One significant limitation of many P3 systems (and most name-brand P3 desktop systems) is the fact that the Intel chipsets limited the system to 512M of RAM. This really causes problems when you want to run Xen or similar technologies. I have a few P4 1.5GHz systems that have three PC-133 DIMM sockets allowing up to 768M of RAM (it seems that PC-133 DIMMs only go up to 256M in size - at least the ones that cost less than the value of the machine). Another issue is USB 2.0 which seems to be supported on most of the early P4 systems but none of the P3 systems. 512M of RAM is plenty for light desktop use and small servers, my Thinkpad (my main machine) had only 768M of RAM until very recently and it was only Xen that compelled me to upgrade. The extra power use of a P4 is significant, my 1.5GHz P4 desktop systems use significantly more power than a Celeron 2.4GHz (which is a much faster machine and supports more RAM etc). Low-end P4 systems have little going for them except for 50% more RAM (maybe - depends on how many sockets are on the motherboard) and USB 2.0. So it seems strange that people want to upgrade from a P3 system to a P4.

• [1] http://doc.coker.com.au/environment/computer-power-use/


• [2] http://www.spec.org/cgi-bin/osgresults?conf=cpu2000

Share This

Gkismet is a GTK GUI fontend for Kismet wireless sniffer. It is helpful because it allows you to display more data to the screen at once than the curses client shipped with kismet itself, and is conveniently useful to connect to multiple instances of kismet. There are however additional system requirements and a graphical environment in order to run it. I needed gkismet for myself, so I decided to properly package it. I’m not sure if I want to put it into Debian, as it seems to be unmaintained upstream (“Rather than trying to fix the problem with unbalanced quotes in Kismet data I am going to wait and see if I can re-write the whole thing in Java.”). In any case, I thought it might be useful for someone else, so there it goes.

We got home from our week in Arizona late last night. We decided to drive non-stop yesterday, and get home in a day, rather than split it over two days like we did getting there. It ended up taking around 15 hours (we had an unexpected delay at Lost Hills because we found a stray dog (we initially thought it to be injured to boot) and Sarah was trying to get hold of some local animal control people to do something about it), otherwise it'd have taken closer to 14 hours. The drive to Phoenix was pretty uneventful. We took our time leaving Mountain View on Sunday (we had an early Thanksgiving dinner with all of our neighbours on Saturday night), and decided to call it a night at Cabazon. For about the same price that we stayed in a crappy motel last time we went this way, we stayed at the Morongo Casino, which was really nice. We were in a "Canyon View" room, and, well this is what the view looked like... We arrived at Craig and Sarah's place at about 5pm on Monday afternoon. Their new place is really nice. It's huge, with a huge yard, and a nice view of the hills. I've found suburban Phoenix (well Peoria to be precise) to be the closest looking thing to what I consider "normal Australian suburbia" that I've seen so far in the US. Granted, Peoria's a bit upmarket (at least the part that Craig and Sarah live in). So we spent a day and a half vegging out at Craig and Sarah's place, then on Wednesday afternoon, we headed off to Woods Canyon Lake, in the Sitgreaves National Forests. I rode most of the way with Craig in their new motor home, and then swapped to drive our car after we got close to our destination. It turns out that the headlights in RVs are universally crap, so it was better for the Prius to be out front lighting the way on the gravel road. I'd always associated Arizona with cacti and sand, but as it turns out, the majority of the state is forest. We arrived at the campsite after nightfall, and set up shop. We met some of Craig and Sarah's friends that night, who were all very friendly towards us. It was ridiculously cold that night. We went to bed rather under-dressed for the temperature, and absolutely froze. The next day (Thursday), we all drove from the campsite (Craig towed their Jeep behind the RV) to Woods Canyon Lake itself, and went fishing. Arizona fishing licences for non-Arizona residents were a bit on the expensive side, so Sarah and I just hung out on the rocks and chatted to people and took photos. The collective haul of trout from about 5 hours fishing was pretty impressive. I'm not quite sure why, but Friday was the group Thanksgiving dinner. Everyone pitched in, and cooked up a storm. They deep-fried three turkeys (which came out very nice and looking much less like KFC than I expected), and we had way more food than we needed. We all ate outdoors at around 3:30pm, and it was about 33°F (0.55°C). The only downside of this (aside from it being bloody cold) was the leftovers went cold almost instantly, so going back for seconds was a bit of a disappointment. Everyone gravitated back to the fire pretty quickly afterwards. It got pretty cold that night. I think it was down around -4°C when we went to bed that night. We left a bit before 8am the next morning, and the car thought it was -7°C outside. One of the other campers told Sarah his thermometer was reading something closer to -14°C. I'm not sure how cold it was when we were in New York in January, but I didn't think it was that cold. It was a good week away. The mix of camping and not camping was about just right. Now it's back to work for two weeks before we head off to Australia. Photos from the trip are here.

The idea of replacing the auto tools with GNU make code could be a good thing. I tend to just write simple Makefiles, and avoid using autofoo in new projects at all. That's not good for portability, but it's excellent for sanity. But, what caused the auto tools to become such a mess in the first place? Part of it was the design, which from 30,000 feet is to write a code generator for some not ideal, but lowest common denominator language, and ship a copy of the (generated) code with every project. The new design is to write an include file in some not ideal, but almost lowest common denominator language, and ship a copy of that with every project. This avoids many of the pitfalls in the original design, such as having to deal with, and avoid editing, thousands of lines of nasty generated code when a build fails. I'm afraid it doesn't avoid other pitfalls we've seen with the auto tools. One being that all these copies of code need to be kept up to date. Another being that the interfaces between such an include file and the Makefile that would use it tend to be very broad, and, if not very well defined, can make upgrading the include file break things. As happens when you try to use the wrong version of the auto tools on a project that was written for an earlier version. Maybe smarter people than I can get around these problems. And there's probably, sadly, truth to the idea that to get a system like this really widely adopted, it needs to distribute build code that uses only lowest common denominator tools. (I was going to talk about how I started off using a similar include file but redesigned and sidestepped these problems while still getting wide acceptance for a build tool in the Debian community, but I see I already blogged about that earlier, in debhelper autoconf grudge match.)

Long weekend of travel and family, and now we're back on our way to Montreal. I spent most of Thanksgiving weekend with my father's family in New Jersey, where he and my mom both grew up and where 4 of his brothers and sisters still live (and their kids, and so on). We left Montreal on Tuesday afternoon, had dinner in Albany, and got down to Newburg (New York) in the early evening. The next morning we spent several hours at the nearby Woodbury Common Premium Outlets, which was about as crass and consumeristic as it sounds. But the loonie is still strong, and it's nice to buy some clothes. I especially like buying things a few sizes smaller than what I had to get a few months ago. Wednesday night we got into Hillsborough, NJ, where my Aunt Barbara lives, and visited with her and her family. Barb has four great kids -- Phillip (16?), Maddy and Vicky (14?), and Nick (13?), who are all my cousins despite being at least 20 years younger than me. When Amita June was too tired to move we hit the hay for the night, and in the morning we all hung around playing Wii sports (even AJ!), and had a hearty dinner in the early afternoon. Then we went to my Uncle Paul's for dessert, coffee, and a nice 2003 Ramos Pinto Vintage Port that we brought along. Friday and Saturday we spent at my Aunt Helen and Uncle Marty's house in Highland Park (New Jersey). They have a great 100-year-old house right by the Raritan River, and it was really nice seeing them. We had dinner with Paul and his wife Eileen on Friday night, and we saw the lighting of the Christmas tree in Princeton. Today we started the two-day trip home. It's not really that long a drive -- about 6-10 hours, depending on the route and kind of weather -- but we like to split it up into two days, since we have a 2-year-old aboard. We stopped in New York (city)/Queens to see our friend Jen for brunch at a nice place called Quaint, where I got a good house-cured salmon and Maj had an excellent bowl of granola. Amita got some nice challah french toast, which she wolfed down with the help of her kind parents. Tonight we stopped in the Pioneer Valley in Massachusetts to sleep over. I like this part of MA, and the New York Times had a recent article about its bookish culture, called In the Valley of the Literate. We had a nice quick dinner at Bueno Y Sano in Northampton, and we'll stick around tomorrow for more shopping (books! Whole Foods!) and a little site-seeing before we head home. It'll be good to be back in MTL, though. I miss my bed, and we only have a few weeks there before we're off again to California for Christmas time. tags: travel thanksgiving newjersey amitajune shopping pioneervalley

Montreal SantaCon Speaking of Christmas, one of the things we'll be shopping for tomorrow is santa costumes. Friday, November 30th is SantaCon Montreal 2007. SantaCon is a world-wide anarchic cluster-together of goofballs and lunatics who go rampaging around their town from bar to mall to bar in full Santa costume (or Mrs. Santa, or elves, or reindeer, or something similar). Everyone's invited, nobody's in charge, and a fun time is had by all. SantaCon started in the 90s in San Francisco (like everything), but I never managed to go. I finally went to SantaCon in Austin in 2001, and had an amazingly good time. My pals at The Ministry of Truth have photo evidence here and here and here. There's nothing like overflowing a bar with 100 of your new best friends, all dressed like Santa, dancing and goofing off and having a good time. It brightens up everyone's day. Anyways, we'll be picking up Maj the beginnings of an outfit here on the US side of the border, so she'll be able to accessorize with her own bits and pieces. I'll probably pick up a couple of spares for friends in Montreal, too. I'm really looking forward to the event -- it should be a good time. There's a Facebook event for people who go for that kind of thing. tags: santacon montreal cacophony santarchy santacon2007 santaconmontreal2007

le Sans Fil to go municipal I was excited to read (via Steve Faguy) that our beloved local community wireless group, le Sans Fil will be providing wireless to many parks and open spaces around Montreal. This is great news for Montrealers -- the city had previous vowed up the street and back that it would never have a municipal wireless program of any sort. So good deal. It sounds like it's going to be a tough job -- I don't think wiring up outdoor spaces for wireless is anywhere near as easy as doing caf s or homes. And I think it's going to be tough to show value -- after all, people are only outdoors in parks in great numbers during the few warm months of the year here. And when people are out in parks, they're not usually checking their email -- they tend to do more outdoorsy things. But my guess is that park culture will adapt to the new resource pretty well. Congrats to SF -- I think they're a great organization that's up to this new challenge. tags: montreal ilesansfil muniwifi

Now as anyone who knows me knows, I love Git. I find it gives a very productive and comfortable workflow. One of my favourite new(ish) features is git rebase --interactive, which along with cheap’n'fast branching gives a great way to hack and commit as you go and then later on refactor your work into sets of nice orthogonal patches. However, there I do still find a good few things wrong with git, so I’d like to discuss these problems and possible solutions:

1. Error Messages In general git has some terrible cryptic error messages. My favourite example is if you modify a file and then pull a change that modifies that file before you commit it: Updating beb8c37..b953e6f
test: needs update
fatal: Entry 'test' not uptodate. Cannot merge. WTF? what does uptodate mean? why isn’t it up to date? whats gone wrong? what should i do?
   Surely something like: Cancelling pull as 'test' has changes that would be overwritten by this pull. Please commit your changes or force an overwrite using the '--force' flag would be a lot better? I leave it as a reader excercise to repeat this process for most error messages…
2. The index Why oh why oh why is it called the index? It does no indexing as far as the user is concerned. Its name gives you no clue to what it is, you don’t know when or how you’re supposed to use it. git add and git rm modify it and it’s used all over the place by the obscure low-level git helpers that you stumble over. How about commit staging area, that being what it actually is. You could have nice commands like git stage and git unstage and git stage --interactive. That’d make more sense, right? Then git add and git rm would be a lot more meaningful, being only used when you actually want add or remove a file.
3. Remotes With git remote this is a lot better than it used to be - having to use cryptic refspecs (see git-pull manpage for the gory details). Unfortunately refspecs are still scattered all over the documentation just to confuse you… That should almost certainly be moved out to less user-visible documentation. The main issues I have now are:
   • Remote branches don’t always behave like local branches when they should. In particular git pull . <remote branch name> doesn’t work (and gives an obscure error) but git merge <remote branch name> does. remote branches should act just like local branches you can’t modify.
   • I’m not sure I like git branch -r to list remote branches, maybe git remote branches would be nicer and more obvious, or even git branch --remote
4. Lots of git-* commands that confuse people This is a common complaint, and I have to say that I agree. Why not put all the low-level commands in libexec? People who really use them often (which can’t be many!) can always add it to their path.
5. No bug tracker! For such a user-facing tool, a bug tracker would be very useful for users who lack the experience or time to get their hands dirty in the codebase. It certainly seems that just taking bugs to the mailinglist without a patch isn’t generally useful.

So, what do people think? What other bugbears do beginners and experienced git users see? Are these useful ideas? After some discussion, I’ll happily take these to the git mailing list and come up with some patches! Update:
Looks like people had some problems with my OpenID based login. Comments are now open.

It seems the Wordpress developers have made some wrong decisions in their use of MD5. Full details are in this announcement. In summary, the hash in the cookie for authentication contains MD5(MD5(password)) and the database MD5(password). This means that anyone with access to the hash from the database can pretend to be this user. Whoops. This shows that once again that security is hard as people consistently make the same mistakes. More details and background on the Security Group blog.