In Improving simple charts, Dirk Eddelbuettel wrote a nice little summary how to produce “nicer” charts using R. However, in my opinion, the charts he provided as alternate options to the original, purely linear graph are less readable for the average person. If anything, using a logarithmic scale on the original Y axis (number of packages not built after a specific date) would be of use, but the other graphs only hide the original point of the post Dirk replied to (How old are our (Debian’s) packages?). The point was that 94% of all packages had been rebuilt since the release of Sarge or, if you want to put it the other way around, 1264 (6%) were built before Sarge was released. This relationship is hidden from immediate recognition by the reader of the graphs. I admit though, that Dirk’s second graph (Number of packages against age in days with the age being on y logarithmic scale) is also insightful. The other two graphs he presents might make sense in a scientific publication if some point in the “more detailed” areas of the graph needs proving, but for this specific problem, they really don’t make sense to me. Actually, I would question their use even in scientific publications, since they distort the original data a lot. Scientists are pretty much used to logarithmic scales these days, but I couldn’t work out how the scales work on those two graphs. And another note on the second graph (logarithmic age): The way the X axis is labeled (10, 20, 50, 100,..) is also pretty non-intuitive to me. I’m much more used to something like 5, 10, 20, 40, 80, 160 and so on, which gives the same distance between each label and seems a lot more usable to me.. (edit: Fix spelling of Dirk’s surname)

Share This

I’ve just watched the video of Stewart Smith’s LCA talk Eat My Data about writing applications to store data reliably and not lose it. The reason I watched it was not to learn about how to correctly write such programs, but so that I could recommend it to other people. Recently I have had problems with a system (that I won’t name) which used fwrite() to write data to disk and then used fflush() to commit it! Below is a section from the fflush(3) man page:

NOTES

       Note that fflush() only flushes the user space buffers provided by  the

       C  library.   To  ensure that the data is physically stored on disk the

       kernel buffers must be flushed too, e.g. with sync(2) or fsync(2).

Does no-one read the man pages for library calls that they use? Then recently I discovered (after losing some data) that both dpkg and rpm do not call fsync() after writing package files to disk. The vast majority of Linux systems use either dpkg or rpm to manage their packages. All those systems are vulnerable to data loss if the power fails, a cluster STONITH event occurs, or any other unexpected reboot happens shortly after a package is installed. This means that you can use the distribution defined interface for installing a package, be told that the package was successfully installed, have a crash or power failure, and then find that only some parts of the package were installed. So far I have agreement from Jeff Johnson that RPM 5 will use fsync(), no agreement from Debian people that this would be a good idea, and I have not yet reported it as a bug in SUSE and Red Hat (I’d rather get it fixed upstream first). During his talk Stewart says sarcastically “everyone uses the same filesystem because it’s the one true way“. Unfortunately I’m getting this reaction from many people when reporting data consistency issues that arise on XFS. The fact that Ext3 by default will delay writes by up to 5 seconds for performance (which can be changed by a mount option) and that XFS will default to delaying up to 30 seconds means that some race conditions will be more likely to occur on XFS than in the default configuration of Ext3. This doesn’t mean that they won’t occur on Ext3, and certainly doesn’t mean that you can rely on such programs working on Ext3. Ext3 does however have the data=ordered mount option (which seems to be the default configuration on Debian and on Red Hat systems), this means that meta-data is committed to disk after the data blocks that it referrs to. This means that an operation of writing to a temporary file and then renaming it should give the desired result. Of course it’s bad luck for dpkg and rpm users who use Ext3 but decided to use data=writeback as they get better performance but significantly less reliability. Also we have to consider the range of filesystems that may be used. Debian supports Linux and HURD kernels as main projects and there are less supported sub-projects for the NetBSD, FreeBSD, and OpenBSD kernels as well as Solaris. Each of these kernels has different implementations of the filesystems that are in common and some have native filesystems that are not supported on Linux at all. It is not reasonable to assume that all of these filesystems have the same caching algorithms as Ext3 or that they are unlike XFS. The RPM tool is mainly known for being used on Red Hat distributions (Fedora and RHEL) and on SuSE - these distributions include support for Ext2/3, ReiserFS, and XFS as root filesystems. RPM is also used on BSD Unix and on other platforms that have different filesystems and different caching algorithms. One objection that was made to using fsync() was the fact that cheap and nasty hard drives have write-back caches that are volatile (their contents dissappear on power loss). As with such drives reliable operation will be impossible so why not just give up! Pity about the people with good hard drives that don’t do such foolishness, maybe they are expected to lose data as an expression of solidarity with people who buy the cheap and nasty hardware. Package installation would be expected to be slower if all files are sync’d. One method of mitigating this is to write a large number of files (EG up to a maximum of 900) and then call fsync() on each of them in a loop. After the last file has been written the first file may have been entirely committed to disk, and calling fsync() on one file may result in other files being synchronised too. Another issue is that the only time package installation speed really matters is during an initial OS install. It should not be difficult to provide an option to not call fsync() for use during the OS install (where any error would result in aborting the install anyway).

Share This

Earlier today and via Planet Debian, Lucas blogged about the 'age distribution' of Debian packages, defined as the time since the last (re-)compilation. He illustrated his findings with an, umm, rather ugly chart. Having climbed onto the soap box once before, I would like to point out how easy it can be to create simple, informative, and, at to least to me, prettier charts using R. Lucas included a URL to the data. The first nice thing to note that we can read the data directly from the URL -- no need to copy the file:

pkgAge <- read.table(file="http://people.debian.org/~lucas/arch-age/arch-age.log", col.names=c("pkg","yyyymmdd"))

read the data into a data.frame which we have given two column names.

pkgAge[,"date"] <- as.Date(as.character(pkgAge[,"yyyymmdd"]), "%Y%m%d")
pkgAge[,"age"] <- as.numeric(difftime(Sys.Date(), pkgAge[,"date"], units="day"))
pkgAge[,"prop"] <- (1:nrow(pkgAge)) / nrow(pkgAge) * 100

We then create three new columns. First is a date, by parsing the (integer) dates (after first casting them into characters) by supplying the format in standard C notation: "%Y%m%d" for year, date and month without any separators or formatters. Now, having the date as an actual date object inside a real data analysis language we can do things as e.g. computing date differences. The difftime function does just that, using the current date as other point. We ask for the return to be in days, and cast this down to a purely numeric vector (instead of datediff object). Lastly, we quickly compute the date proportion in percentages. We can then view the date. Before we plot,

png("packageAges.png", quality=100, width=640, height=480, pointsize=10)
oldpar <- par(mfrow=c(2,2), mar=c(2.5,2.5,3,1))

we direct the charts to a png file of given dimensions, and ask for all plots in one figure (using mfrow with two rows by two) with somewhat smaller figure margins using the mar argument to par. The first chart shows again proportion over date:

with(pkgAge, plot(date, prop, type='l', main="Standard Plot"))

(The with() function simply allows us to refer to the columns by their names without explicit subsetting. plot(pkgAge[,"date",], pkgAge[,"prop"]) is equivalent, but more cumbersome.) As it clear that the data has a fairly long tail in the older dates, we can also try to plot the plot over logarithmic time differences. This doesn't work for dates, but it works for our (positive-valued) age variable:

with(pkgAge, plot(age, prop, type='l', log="x", main="More linear as log(age in days)"))

The very far left tail below 0.5 percent is interesting as the one very old package is clearly an outlier within an outlier region. We use the subset function to take just one portion of the data, use logs, and explicit plotting symbols '+' in a points-and-lines plot:

with(subset(pkgAge, prop0.5), plot(date, prop, type='b', log="y", pch="+", main="Detail in left tail, up to 0.5%"))

Lastly, the upper quartile is fairly linear.

with(subset(pkgAge, prop>75), plot(date, prop, type='l', pch=".", main="Yet fairly linear in top 25%"))

At the end

oldpar <- par(mfrow=c(2,3))
dev.off()

we restore the graphics paramters and close the device (here the file). All this then yields the following chart: Updated to correctly display the assignment operator <-

We've started using Review Board for code reviews at work. It's pretty nice: setting it up is trivial (it's built on top of Django), it's fast enough (using mod_python), email notifications Just Work, and the user interface is sexy, even if it has a few quirks. It even does syntax highlighting in diffs, which is convenient. The only nit is that our workflow sometimes requires reviews of code that has already been committed in the repository, so having a revision browser in the request form would be a plus. But in any case, it's much more convenient than using email for review!

Update: fixed link.

Regular readers may remember that I'm a vocal critic of some search engines and the unreliability of their fast-changing algorithms. One day you're top ten and the next you're gone. If you're building your business on search engine referrals, you're building your castle on shifting sands. SEOBook: Website Sustainability: What Percent of Your Traffic Comes From Search Engines? has good advice:-

"one of the best moves you can make for the sustainability of that site is to lower the percentage of traffic that comes from search"

That's one reason why I'm glad to see the suggestion of etbe: Advertising Free Software Projects - nearly every free software project would be better off improving their web sites, adding cross-links and building more sustainable traffic, instead of wasting resources competing in the Google-ad Games. Unless you've got the thousands of pounds a year that successful AdWords marketers spend, your Google-ad success will probably be short-lived, as people with more money will outbid you for keywords that work. It's even less sustainable than search result traffic, because it's consuming your financial resources as well as your vounteer time. Meanwhile, most free software project webmasters I know are over-stretched, but many wannabe-contributors seem to want to nuke the entire site to rebuild it with their pet tool. Those offers are really about their ego more than helping the project, in my opinion. They want to Get Themslves Noticed, but I've seen far too many unfinished site rebuilds to like those offers. In fact, I don't think any good webmaster would offer a rebuild without the site owner asking for it - even in the rare cases where I really strongly want to restart a site, I explain why and ask permission first, not just wade in with an offer to nuke-and-rebuild. If the site owner says no, I move on: there's no shortage of work here, after all and very few free software projects pay their webmasters. So, if you want to help a free software project, ask their webmasters for suggestions and access to the site source code.

Debian’s binary packages are only built when they are uploaded (or when a binNMU is requested, but that doesn’t happen frequently). They are never rebuilt later. This means that some binary packages in etch weren’t build in an up-to-date etch environment, but possibly in a much older environment. Is this a problem? It depends. Old packages don’t benefit from the improvements introduced in Debian after they were built. Like new compiler optimizations, or other changes in the toolchain that could induce changes in binary packages. For example, some files used to be at some place, but are now put at another place. Also, some parts of maintainers scripts are automatically generated, and would be different if the package was rebuilt today. But is it really a problem? Are our packages _that_ old? Also, when a big change is made in the way we generate our binary packages (like Raphael Hertzog’s new dpkg-shlibdeps), when can we expect that the change will be effective in all packages? I went through all binary packages in unstable (as on 24/06/2007) (both main, contrib and non-free packages) on i386. Using dpkg-deb –contents, I extracted the most recent date of each package (which can reasonably be taken as the date of the package’s creation). And here are the results. Most packages are actually quite recent. 9008 packages (43%) were built after the release of etch. And 19857 packages (94%) were built after the release of sarge. But that still leaves us with 1265 packages that were built before sarge was released, and even one package (exim-doc-html) that was built before the release of woody! (the removal of this package has been requested, so we will soon be woody-clean :-) Now, what could we do with this data? We could review the older packages, to determine if:

• They would benefit from a rebuild (by comparing them the result of a fresh build) = I'm planning to work on that
• Integrate that data with other sources of data (popcon, for example), to see if the package should be removed. Such old packages are probably good candidates for removal.

Here is the full sorted list of packages.

I came down with a serious case of Not Invented Here, and created a wiki of my own. Before you look, consider that:

• It doesn't have a lot of the features that I want.
• It may be broken (I didn't dedicate a lot of time to writing tests).
• Indeed, unless you're the kind of person who likes to hack on things, you'll probably seriously injure yourself if you so much as glance at it!

That said, I'd love to have a collaborator or two: DedaWiki It will eventually replace the wiki engine utilized over at http://www.leenooks.com, which is showing its age, and not as fun to work with as Rails at this point in time.

I am finally catching up with the remarkably thick goulash of email and blogs entries that comes from traveling for well over a month and today I read one in particular When is Open Source not Open Source? that captivated my interest for it compellingly addresses the dangers that follow from diluting, or one might say hijacking, the term open source. When people learn that I study “free software” one of the most common questions I get asked is: why did I chose free software over open source? The answer is quite simple: given that the bread and butter of my research covers ethics, freedom, and liberalism, free software is the obvious path to follow, yet I also feel like a lot of my work is still relevant to the open source camp because of the affinities between the two. I have long maintained that the ideological gulf between open source and free software is not so great nor impassable, but more modest. As most know, both share a certain strong commitment to access and in a strict technical sense they refer to the same set of licenses. Philosophically there is agreement that openness and, especially, non-discrimination are essential for the quality of software and often by close extension, the vibrancy of community responsible for the software. Of course, when pontificating the ramifications and implications of openness, they do part company and enter into different territories. Free software tends to flag rights and freedoms, while open source meanders into a discussion of markets, business, and competition and in this regard they do craft different visions of the social world and human behavior, etc. But the case that Karl Fogel writes about, where OSI is strongly opposing the use of the term open source for licenses that don’t adhere to the definition demonstrates where the two positions join. As Michael Tiemann from the OSI succinctly put it:

The FSF may have got the orthodoxy wrong, and the OSI may have got the interpretation wrong, but we both agree that prohibition of commercial use without special permission is antithetical to both positions.

There is a unmistakable kernel of agreement and it is great to see the OSI taking such a strong stance in this regard. Now, David Richard’s response, who seeks, I think, to essentially dilute the term open source, is as (or perhaps even more) fascinating for in a nut shell, and using a lot of florid religious imagery, it accuses the OSI of being too rigid! In his own words:

I believe the OSI has a wonderful opportunity to continue being relevant and helping to lead the movement forward. If, however, y’all choose to define your denomination of this religion in a way that we don’t fit in, that’s fine. No hard feelings. It’s your choice. You’ll ultimately be excluding a large congregation and we for one will continue trying to build a church made up of others like ourselves.

In response, I would say that the goal of F/OSS is not to be inclusive of anyone who wants to release bits of source code, but to create the conditions under which software, as it has been defined by the community, can be created. Join the church if you would like to make free/open source software as defined and you can go elsewhere (i.e., create a different term) if you are creating something different, even if it is only slightly different. Integrity matters. And again inclusiveness, if it comes at the expense of the main goal, is not a boon but a danger to F/OSS. The OSI will remain relevant by halting the dilution of the term OSI, not by expanding the definition so that it is left with no substance. And in contradistinction to what David Richard maintains, however, there is a great degree of flexibility within this domain but it does not lie in the strict definition of F/OSS but in the realm of interpretation. You are also free, as Mako and I have argued elsewhere to interpret the significance of F/OSS in multiple ways. And I think this is where the political strength of free software lies. There is interplay between a well-defined goal (in this case for creating free software) and a more flexible realm of interpreting the significance of these technical practice. And we wold lose and I might add, a lot if we became flexible about the strict definition of F/OSS and inflexible about its political significance. I get irked with folks like David Richards who would like to bend open source rules to meet their (often commercial) interests and I find it pretty na ve when folks say the political significance of F/OSS is just x (or worse should be x) for in reality its political significance lies in the fact that it has spawned multiple types of political and economic projects. And there is something almost playfully ironic, (or at least it makes me smile) in this fact. Though there is strict definition contained withing F/OSS, this strictness has, at least to some extent, encouraged by an extreme and very healthy form of political proliferation and promiscuity. More than anyone else I know, Mako has most passionately and thoughtfully argued for the importance of what I would call political clarity and integrity. That is, the importance of having a well articulated definition for social movements, for they act, as he says a rallying point to realize a social movement. Urging the Creative Commons to learn from F/OSS and dare to simultaneously narrow and more clearly define their goals, he states it quite nicely in the following terms:

Free software advocates have been able to use the free software definition as the rallying point for a powerful social movement. Free software, like the concept of freedom in any freedom movement, is something that one can demand, something that one can protest for, and something that one can work toward. Working toward these goals, free and open source software movements have created the GNU/Linux operating system and billions of lines of freely available computer code.

In essence, a definition that people can abide by, respect, and perhaps eventually cherish is the condition of possibility to make working political code. And given how hard it is to make social change happen (at least in comparison to build computer code), we should learn from what F/OSS has to offer. And at the same time there is another lesson embedded in F/OSS. The Free Software Definition is well defined; but it must be emphasized, narrowly so. It does not try to do everything and have everyone pledge allegiance to an inordinately complex set of commitments. Clarity, narrowness, and well-defined goals –> these three attributes have powered it far and wide and I hope it remains so. Now, since the term open source is not trademarked, we are left with the problem of how to challenge the current hijacking of the term. For the solution, I will leave you with Karl Fogel, who I think proposes a good solution:

Note that the OSI s objection is not to the Zimbra license per se. The objection is just to Zimbra s calling that license open source . They can use any license they want, but they shouldn t call it open source unless it actually is. Freedom is freedom, and no amount of spin will change that. So what should we do about this? The term open source isn t trademarked. Years ago, the OSI tried to register it, but it was apparently too generic. …But there is public opinion. What Danese and Michael are proposing doing is organizing a lot of open source developers (and I mean open source according to the traditional definition, the one the OSI and I and most other open source developers I know adhere to) to stand up and, basically, say All of us agree on what the definition of open source is, and we reject as non-open source any license that does not comply with the letter and spirit of the Open Source Definition.

Alex Hudson commented:

"Similar comments about another W3C WG: http://ln.hixie.ch/?start=1181118077&order=-1&count=1 W3C should be about authoring material for the web. It seems at the moment, they're more concerned with the stuff that happens after authoring - e.g., how stuff relates in "the semantic web". IMHO we still don't have any powerful tools for authoring either, so the idea that authoring tools will automate many of the "bolt on accessibility" tasks is pretty naive."

After implementing pingback, I have some respect for hixie. It's disappointing but not surprising to read those comments. Not sure what is meant by powerful authoring tools there. My tools are powerful, but I know they're not easy for new users. As I'm getting old and cynical, I'm not sure whether power tools can ever be correct and truly easy - just look at the pigswill spewing out of some Web 2.0 sites. niq sent me a link to the WCAG Samurai Errata and commented:

"The problem with WCAG 2, as with WCAG 1, is precisely that it's a Work of Committee, and seeks to represent too many irreconcilable viewpoints and egos. In some cases, even the ideas behind it are inconsistent. Many (myself included) regard accessibility as being about ensuring a reader with a physical disability can make use of a site (think Steven Hawking). That's also what HTML is designed to support. Others are concerned with the mentally impaired, also a worthy cause, but one that becomes counterproductive when its advocates fail to distinguish between a site that's inherently inaccessible because it presents a complex and challenging subject, and one that's unnecessarily difficult due to poor presentation. Add the two together, blend in some stupidity, and you get "accessible" sites full of classic "friendly" little illustrations like a "helpful" government booklet, and a horribly intrusive "alt" to explain each pointless "ethnic mummy and child" picture."

I think a Work of Committee could be useful, as long as you have the right committee. Thinking about that, I found the group membership list and I'm not sure that's the right committee. For example, I think the ex-Adobe Google-worker must surely have an irreconcilable conflict of interest (inappropriate use of Adobe's Flash and PDF formats and Google's Web Apps have done more than many to harm accessibility in the past IMO), yet is a leading light of WCAG 2.0 - maybe that's why it's gone so dark? Update: Thijs Kinkhorst comments:

"As I read in the draft, suggestions are still possible until the 29th, not the 27th of June."

I'm sure that's different to the email which started me writing this, but please go comment and see if we can make WCAG-2.0 useful.

If you’ve received email from an attorney in the last five years, you’ve probably seen some version of a boilerplate warning/disclaimer in the message footer, indicating that the message may be privileged (or in some cases, asserting that the message is privileged!) and telling the receiver to destroy and/or return all copies if they are not the proper recipient. In the last couple of years, almost everyone has also added a statement to the effect that this email does not contain illegal tax advice (or if it does contain such advice, you shouldn’t use it!) Cumulatively, I’m sure we’ve used gigabytes if not terabytes of bandwidth attaching this text to every email sent. My question to the world: is anyone aware of such an email disclaimer ever being enforced or held enforceable?

Share This

Leiden Lammenschans
Tiel Passewaaij
Capelle Schollevaar
Hoorn Kersenboogerd
Houten Castellum

It's like this. I've got this very fine computer, only it's about four years old. Contrary to popular belief, that doesn't mean it's too slow for today's computing, so I don't feel any particular need to change it or upgrade it (I've been known to use an 8-year-old computer as my main server up till recently). The problem is that its main processor is an Athlon XP 2200+, and that's not the "mobile" version. So there's no frequency scaling, no power-saving CPU states, and so on. And since I moved from a hot place (the French Riviera) to an even hotter place (near Montpellier), summer is likely going to cause frequent crashes as temperature rises. Oh, and my office/computer room is now right under the roof, so it does get hot rather fast. So, something has to be done. First solution (rather blunt): open up the computer case and point a large fan at it. It worked last summer, but it's hardly elegant, and it's noisy. Second solution: try to emulate the CPU frequency utilities with what's available. In this case, the CPU throttling feature accessible through /proc/acpi/processor/CPU1/throttling. I had a look around, but the usual suspects (cpufrequtils, powernowd and so on) didn't seem to be able to help. Hence the following script:

#! /bin/sh
high=55
low=50
minload=1
delay=60
sensorbus=w83697hf-isa-0290
sensor=temp2
maxlevel=15
while sleep $delay ; do
    temp=$(sensors $sensorbus \
          awk "/^$sensor:/  print \$2 " \
          sed s/^\+// \
          sed s/\\..*// )
    cur=$(cat /proc/acpi/processor/CPU1/throttling \
          awk '/^active state:/  print $3 ' \
          sed s/T// )
    load=$(awk ' print $2 ' /proc/loadavg   sed s/\\..*//)
    if [ $temp -ge $high ] && [ $cur -lt $maxlevel ] ; then
        next=$(( $cur + 1 ))
        logger "Temp $temp, load $load, throttling down from $cur to $next"
        echo $next > /proc/acpi/processor/CPU1/throttling
    elif [ $temp -le $low ] && [ $load -ge $minload ]  && [ $cur -gt 0 ] ; then
        next=$(( $cur - 1 ))
        logger "Temp $temp, load $load, throttling up from $cur to $next"
        echo $next > /proc/acpi/processor/CPU1/throttling
    fi
done

You'll notice that it unconditionnally throttles the CPU if the temperature is too high, and releases some of the power if the temperature is acceptably low and the system load seems to demand more power (no need to have the box running at full speed if it's idle). Feel free to re-use, comment, tweak, and so on.

>> Thank you for your message to the Adaptec Customer Service department.
>> Your case # is 000000000005432. (NB: not the real number.)

*ROTFL*  Exactly how many customer requests do they expect to handle?

If the answer is "about 100/day", which sounds somewhat high to me given the above number, then space will last roughly three times as long as the time until this nice planet will die a fiery death in its expanding sun's outer heliosphere.

Maybe somebody was afraid of the Year-100-Billion problem

We had a great weekend this last weekend here in Montreal. Yesterday, June 24, was Saint-Jean-Baptiste Day here in Quebec -- the national holiday of this cool and fun nation. St. Jean Baptiste is important to me in a lot of ways. Of course, it's cool that it's the national holiday of our adopted new home. But John the Baptist, the patron saint of Quebec, is also our family's name saint. ''Prodromos'' means "forerunner" in Greek, and it's one of the titles of St. John. Most of all, it's the day that Maj and I moved to Montreal. We came in on St. Jean Baptiste Day, 2003, and we've been here ever since. We drove my beautiful 1972 Citro n DS from San Francisco, where my niece Elena had just been born, all the way out here. We arrives on June 24th and wandered around the McGill Ghetto looking for our sight-unseen sublet. It's hard to believe it's only been 4 years -- it seems like so much longer. We had a good day yesterday. The three of us went to Piknic in the afternoon and hung out with our friends Jeremy and Lina and their two great kids Clea and Sylvie. We had a lot of hummus and pasta salad and bread and cheese and generally had a great time. Meg and Catherine came and hung out for a while, and also our friend Kristen, who's 7 months pregnant and has a 10-month-old. Good luck on that one. Most of all a pretty day enjoying the outdoors in our new home town, as well as fun dancing to house under a big Calder statue. How great is that? tags: montreal quebec stjeanbaptiste prodromou piknic jeremy lina

72 hours from Flickr I forgot to mention that we had a really nice time on Friday evening going to the 24 Hours of Flickr party at the SAT. Heather Champ, community leader at Flickr and welcomer to partiers, put it well: "We have three requirements for Flickr parties: the food must be good, the drinks must be copious, and the schwag must be ample." And that's exactly what happened. All the usual Montreal suspects were out in force: YULblog types, Web entrepreneurs, Web pranksters. It was great seeing m-c and c-c, who wore their awesome Flickr Socks -- although they each had a matching pair. I also talked to Allen Morris, which was really fun. He's a developer living now in Saranac Lake, one of the towns in the Adirondacks I find strangely compelling. We exchanged GPG key signatures and talked a lot about the Bay Area (California), where we both once lived. Probably my best talk was with Heather Champ and Derek Powazek. We talked about their joys of creation of JPG Magazine, the despair of leaving it, and looking forward to the future. We also chatted a lot about print on demand technologies, which we're evaluating for Wikitravel. Heather took the photo of my friend Ben Cerveny at Burning Man that's become his avatar icon on about every social software platform I know of. It must be good to capture someone in the way they want to think of themselves. I took my own self-concept picture by putting the camera on the dashboard of my Citroen. Heh. All in all a good party. One thing I was interested to find out was that there's a Yahoo! Quebec, which launched last month and I guess just slipped by me. Sadly, if you click on the "English" button, it takes you to... Yahoo! Canada. Hey, Yahoo! There are actually a lot of anglophones here! Just in case you were wondering. tags: yahooquebec 24heuresflickrmontreal 24hoursflickrmontreal flickr montreal party

Montreal Web Development Book Club Montreal Web scene stalwart Heri Rakotomalala -- the man with the magic name, originally from Madagascar, along with Montevideo and Marfa, one of the M-places on my travel wishlist -- recently started a Montreal Web Development Book Club. It's a meeting for people interested in the practical side of the Web to talk about the books they read and let that drift into talk about the work we do and ideas we have. I think the book club is an awesome idea. Book clubs are a great grass-roots intellectual meetup that we don't often celebrate in the post-flash mob BarCamp-ized world. The great thing about a book club, for Web people, is that it filters out the bullshitters and dilettantes. If you're going to a book club, you're going to have to know what you're talking about, and you're going to have to care about the subject. The book gives focus that keeps the conversation from drifting to tangential topics. Flakes and hangers-on just don't have the stamina for it. Also, we met at La ka, so it was nice to have some beers in a good place on a hot night. Why not? We managed to talk about a lot of good books, too. Jean-Fran ois <something> (I didn't get his last name) talked about In Search of Stupidity, a look at the last 25 years of marketing and business blunders in the high-tech realm. Our industry is subject to a lot of decisions that seem absolutely self-defeating in hindsight, and the book goes in-depth on 15 case studies -- like Wordstar, Ashton-Tate and Borland. It sounds like a great cautionary tale for Web 2.0 startup mavens. Heri talked about the book Information Architecture for the World Wide Web -- the infamous "Polar Bear Book". It sounds like a really good book for doing initial planning for a Web site, but I'm really interested in tools for profiling an IA effort. We get about 2 million unique visitors a month at Wikitravel, for example, which is a huge amount of usability data I could be mining. But I don't really have the tools for it, so I don't do it much. I'd love to know, for example, about people who land on a Wikitravel page from a search engine and then leave. What were they looking for? Why couldn't they find it? Also, users who browse through our pages clicking on links, then resort to a full-text search. What did they think they were clicking on, and what were they looking for instead? Did they find it? How can we put that in front of them in the first place? Most of all, I want to know how and why people start editing Wikitravel pages, and why they stop. Of people who click the "edit" button, only 1 in 17 click "save". (That is one bit of clickpath analysis I've done.) Why? I've often been tempted to put a survey up when someone navigates away from our edit page. "Why didn't you save? Tell us so we can fix it for other people." I talked about the book I just finished reading a few weeks ago, Everything is Miscellaneous. It's the latest book by Dave Weinberger about how we impose order on information to make it easy to understand and retrieve. It's an awesome book -- really fun -- especially for someone married to a knowledge management expert. I don't think I gave a good enough description of the book to ignite the club's interest, but I hope they check it out, because it's really readable and good. At the end of the meeting Heri took a poll and decided that we'll continue doing the book club on the last Monday of the month. I've already picked out my book for next month: RESTful Web Services. I've heard good things about this book (admittedly mostly from the co-author Leonard Richardson) and I want to give it a look-see. So book-club fodder it is. ''Update: Heri has his own book club report here.'' tags: bookclub montreal heri webdev montrealwebdevbookclub

And so DebConf7 is over.. And as always it was quite an experience.
In the two weeks I’ve pushed my alcohol limit to a new level, invaded Edinburgh castle at 5AM, mounted a plastic cow, had pancakes at the Scott monument also at roughly 5AM, roamed the city, seen the awful clubs UK has to offer, tasted some wonderful beers and whiskies, survived the food, met interesting people, fucked up a talk, driven all the way from Edinburgh to Norwich, and here I am. With a wonderful set of videos and photos.
Thanks to everyone who attended DebConf and organized this wonderful event for making it yet an experience I couldn’t dream of being without.
SEE YOU ALL IN ARGENTINA!!

Partly because of a lack of funding for debconf, partly because of bad organisation (long story, may be told later) and partly to get back to work (got a new contract on Thursday, so it was worth it), I left debconf on Wednesday, the day of the day trip. Those of you who were there may have noticed it rained pretty damn hard. After I checked out, I sat in the lobby and lined all my luggage with plastic, to make really sure it was waterproof. I left a few things which didn't matter, like bottles, in the side pockets, outside the plastic. I headed out with the intention of visiting Teviot one last time, to pick up things from the Front Desk which arrived after I did, but as I waded uphill, I changed my plan and headed straight for Waverley station. There I sat, snacking and drip-drying until my train left. I watched the day trippers leave, but I don't think they looked up to the bridge where I sat. There was a very strange sign fragment on the ground on the far side of the train tracks at Waverley platform 7: it said

"How many assassins does it take to kill one man?"

How debconf-coincidence is that? I tried to get a picture, but my camera wasn't happy about the light levels. Anyone else see it? Is it still there? I met some very nice people on the train to Manchester. Sat at the same table as me were a young web designer and someone who was stationed in London (during World War 2, IIRC). Both had interesting stories and both had connections to France. A fourth person got on in Lancashire and just sat quietly, reading the University of Lancaster Travel Plan 2004. Manchester city centre was fascinating. I travelled through it quite a few times more than 10 years ago, but it has poshed up since then. Most buildings seem relentlessly gothic, like someone took London St Pancras as the inspiration for an entire city, but there's the occasional classical and modernist building punctuating things. I'll put the photos up soon. After a quick walk around, I felt it was about to rain again and I didn't fancy a second soaking in one day, so I headed into a pretty good cafe called "Java" by Oxford Road station and waited for my train. The rest of the journey back was pretty uneventful, as far as I can recall. Unfortunately, once I got home, I discovered that some of my hardware was outside the plastic lining and was soaked by the first rainstorm... these posts have been delayed while I got some of it working again, but it seems that the infernal Samsung YP-U2 audio player is totally dead.

Parents and educators should be aware about what kind of games their children play. In the current state, this means that the parents must be gamers themselves to know about that, because there’s no way of knowing whether a game includes sex, violence, sexism, etc. until you play it. The idea is to provide a way of classifying games so that parents can know in advance whether the game involves certain culture-dependent controversial stuff, and being able to use that when considering what games they want their children to play, or what games they want to play themselves. Not that I’m the proper one to make the classification myself, but it should be done by teachers and educators, who I think are the best suited for this kind of task. In any case I’m willing to lead and coordinate the project, with the support of just some Spanish teachers for the moment. I hope that in the future teachers of other cultures will like to get involved too and the system can evolve to a multicultural one. The result should be as culturally independent as possible, but that would only be possible if members of different cultures help. There’s no way to provide a totally objective classification of moral stuff, so instead of trying to make the classification as aseptic as possible, it might make more sense to make it the other way round: trying to have all the different possible points of view, even when some of them might not even fit my own beliefs. Links:

• TIGRS , The Independent Game Rating System (Wikipedia)
• PEGI, Pan European Game Information (Wikipedia)
• ESRB, Entertainment Software Rating Board (Wikipedia)
• DebTags, Debian Package Tags (Categories for Debian packages)
• Previous discussion about this in the Debian Games Team Mailing List: 1, 2. 3

DebConf7 finished today. This was my first DebConf, and probably not my last one :-) I had a really interesting time in Edinburgh, despite the weather (but at least we are prepared for DebConf8 now!). The organization team really did a fantastic work, the venue was gorgeous, etc, etc, etc. Again, I was positively surprised by how nice everybody was at DebConf. It’s weird to think that the same people are part of the regular flames on the mailing lists. Which proves that most flames are just caused by people being passionate about Debian, and looking for the best for the project, and not by people trying to be annoying, like one could think :) I gave a talk about the usual QA stuff I’m doing: archive-wide rebuilds, piuparts runs, and how to make all this more efficient by working inside the collab-qa project. So far, it’s not like a lot of people have been joining the project, which is kind of a failure. But at least everybody seem to think that the idea is good. I also gave a lightning talk about Debian Package of the Day, which I didn’t plan to give originally (I think I never prepared slides in such a short time). I think it was well received, and we even got a new submission half an hour after the talk. I even managed to clear some tasks on my TODO list during Debconf, the most visible one being the “automated monthly mails to maintainers of packages with serious problems”. I was quite afraid of being flamed, but I sent 250 mails, and only one person replied aggressively. I also got a lot of positive feedback, so the next batch will probably use slightly less strict criterias. And of course, the most important result of debconf was the numerous discussions, that resulted in a lot of good and interesting ideas.