Went to a step class at the new gym last night. As usual, I was the only boy in the class. The teacher refered to me as "young man" a couple times, since it was the easiest way to do so. =) I enjoy taking step classes and am surprised to not find other guys in there. It seems to me that if the women I see at the gym manage to look really good and have decent strength and endurance by doing hour-long cardio and pilates/yoga classes, that they are probably better to follow than the weight room full of generally out of shape guys who look like they're risking a hernia when they exercise.<br /><br />The interesting part was that the class was in French. While my French is quite good, it seems that my parsing is a bit slower than the teacher's ability to hand it out. It took me several times hearing pas de base , before I realised the teacher wasn't telling me *not* to do something, but was in fact asking us to do the basic step. Other things which I understood quickly enough simply made no sense like carr e .<br /><br />Afterwards I came home and had a snack of some Soya Nova Westcoast Smoked Tofu. It tastes quite good, and I've had several people who still eat cheese tell me that it tastes much like Gouda. When I was in Vancouver recently, I picked up several blocks of it. I phoned them today and spoke to the owner. It seems that the Metro stores here might carry it. If not, they're expecting them to in several months as part of a deal with Sunrise Tofu.<br /><br />I remember when we first moved to Toronto, that few of the stores carried the vegan treats that <span class='ljuser' style='white-space: nowrap;'><a href='http://auzure-skies.livejournal.com/profile'><img src='http://stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0;' /></a><a href='http://auzure-skies.livejournal.com/'><b>auzure_skies</b></a></span> and I are used to eating. Places slowly acquired them until there was a whole range of products that we were eating in Toronto that we hadn't seen when we were living in Vancouver. Despite the fact that there's a few large chains of health food stores here, we're still having trouble finding a number of them. Some companies like Toffuti Canada refuse to return phone calls. Many others, like Tofurki, don't get information on which chains carry their products, or beleive that their products are being sold in stores like Provigo even though they're not.<br /><br />Perhaps one of these days I'll have spare hours in the day to contribute to the Association V g tarien de Montr al / Montreal Vegetarian Assocation.

My too-long absence from writing much here can be ascribed to two, differently pleasant, activities. First, a fantastic vacation in Cuba, and second, the redesign and launch of the XTech web site. Of the first, come to my place for dinner and I'll bore you at length about how amazing it was. Of the second, I'd like to bore you right now! Thanks to Ruby on Rails and a few late nights, the XTech site now has these new features:

• Full conference schedule (apart from 6 Mozilla talks I'm still nailing down)
• A blog. With go-faster Atom 1.0 stripes and everything!
• Details on the newly-added Ajax Developers' Day.

A few more details on the Ajax Developers' Day. As I mentioned before, when putting together the schedule we felt there was a lot of excellent content still missed out (I'm still feeling guilty at having rejected proposals from many good friends and excellent speakers). So, we put together an extra day at the beginning of the conference where we could go further into detail on Ajax technologies. This day, featuring speakers such as Simon Willison from Yahoo!, XML expert Kurt Cagle and OpenLaszlo's Max Carlson, will allow those working on Ajax projects--either deployment or toolkits--to meet, discuss best practice and move forward on new ideas. Although it's a day-long event, we didn't want to make the price tag as high as a full-day tutorial, so you can register for the cost of a half-day tutorial. A few implementation details If that all sounded a little like advertising, here are some technical details worth sharing. The site's CMS is built on Ruby on Rails. Development was done on Linux, with the help of WINE to check out the view from Internet Explorer. The newsletter is managed by the absurdly wonderful CampaignMonitor. This conference not for sale Before I went on vacation, there was some debate in various quarters about paid-for plenary and keynote slots in conferences. Though I hope it is obvious, I wanted to state where I, and thus the XTech conference, stand on this issue. It has always been my policy to maintain a strict separation between the commercial and editorial aspects of XTech. Although each year there's always a company who thinks they can buy a speaking slot, I never let this happen. The content of the conference is formed by editorial selection by the programme committee, who take the scores from the peer review panel as their primary guide. Aside from what I hope shows in the excellent quality of the talks and generally interesting keynotes (yes, we get it wrong occasionally!), there are two effects on the conference.

• Sponsors are that much more respected. When a sponsor respects the delegates' time and intelligence, but still attends, you know they're serious about engagement with attendees.
  
• A higher portion of the conference cost is in the registration fees than for some other conferences. We're still trying to keep the costs as low as we can, but we're not prepared to compromise the quality of the schedule by letting vendors buy talk time.

I hope this explains a little of my position. As a stance, it often creates more issues for me than it solves, but I believe it preserves XTech's reputation as a conference where you can hear some of the best no-fluff presentations on web technology.

The State Services Commission (SSC) (the NZ government body that oversees NZ government departments) released a guide to legal issues in using Open Source Software recently. The publication of this guide has caused a certain amount of consternation in the open source community and even manged to make it to Slashdot and Groklaw as well as spawning a fairly active thread on the NZ Open Source Society’s openchat mailing list. Through all of this I’ve found myself very much on the opposite side of opinion to most other people commenting on it. My initial thoughts on the document are quite nicely summarised by the Groklaw comment that Stuart points out. While the document uses some unfortunate language, there is nothing in it that is actually untrue. In fact my initial feelings towards the document (without having read it thoroughly) were that it was good to see the SSC taking enough notice of open source to feel the need to advise departments on the particular issues that it can bring up. Particularly dissapointing to me are the conspiracy theories that have been flying around. Groklaw surmises that the paper is a Microsoft hatchet job simply because it was authored by Chapman Tripp (a large NZ law firm) who happen to also represent Microsoft NZ on a range of intellectual property issues. I’ve yet to hear a single shred of evidence to back up this assertion and I find it quite ridiculous. Large firms working in a small market such as NZ will often run into conflict of interest issues and have well established procedures for dealing with them. Without seeing evidence to the contrary I cannot accept that a reputable firm like Chapman Tripp would risk their reputation by trying to intentionally mislead the goverment in a report like this. A far more like scenario, to my mind, is simply that the author(s) of the report are not very familiar with open source issues and didn’t do quite as much research as they should have to bring themselves up to speed with the unique IP features of open source licenses. Having read the document more thoroughly now, I can agree that it is far from perfect. I think the single most glaring problem is that it focusses only on open source software and doesn’t mention that many of the risks also exist when using proprietary software. This could leave an uneducated reader completely scared off open source due to a mistaken belief that it is far too risky. On the other hand we shouldn’t completely dismiss the document either as it does raise a number of clear risks that a department will face in adding open source software to their IT environment. We’re not going to do ourselves any favours by pretending that open source is a panacea to all the worlds software ills and can just be dropped in to any IT environment to make things better! It’s worth pointing out at this point that previous evidence from the SSC indicates that they are open source friendly. They have a very clear policy stating that Departments are encouraged to consider open source software alongside proprietary software and use it in cases where it wins on the basis of cost, functionality, interoperability, and security. Given this history, I am alarmed at the hostile reactions many participants on the NZOSS open-chat mailing list had to the document. Quite frankly I think some people are responding far too emotively to the language in the document (which is problematic - but not that bad) and missing the chance to evaluate the rest of it in an objective manner. We have a SSC that has indicated a friendliness towards open source in the past, and I don’t think that they would turn around and reverse their position in this manner. This report is intended to support their overall policy after all. Rather than jumping down their throats and shouting about how poor the document is we need to engage in a civil dialog, point out the issues with the document and offer constructive suggestions for how the document can be improved. To that end, Peter Harrisson has started some pages on the NZOSS wiki where we are going to co-ordinate our impressions and responses to the document so we can present a consistent NZOSS position to the SSC in response. I’d encourage everyone with an interest in the document to read and contribute to those pages. As for exactly what I form our response should take and what it should consist of? I’ll follow up with another post on that later in the weekend when I’ve had a bit more time to reflect.
What I do know (if you haven’t guessed already) is that I think we should be very careful not to respond in a hostile and emotive manner that will result in our relationship with the SSC becoming worse. That means we should take time to consider the document objectively, evaluate its propositions and provide a well researched and substantiated list of suggested improvements to the SSC.

#!/bin/bash
modprobe cpufreq_userspace
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
while true
do
	if expr $(uptime cut -d',' -f3 cut -d':' -f2) '>' 0.75 > /dev/null
	then
		echo 1333333 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
	else
		if expr $(uptime   cut -d',' -f4) '<' 0.75 > /dev/null
		then
			echo 666666 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
		fi
	fi
	sleep 10
done

I tried using some of the standard cpufreq stuff that's in the archive, but none of them seem to work for me; they all make my laptop work at full speed, all the time. Which is silly. Also, the kernel ondemand and conservative governors don't seem to work—when I write "ondemand" to /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor, it comes back with write error: invalid argument, or some such. So, I hacked up the above script. It sets the speed at full (1.3Ghz powerpc here) when the load rises above 0.75 for the last minute, and sets it at the low speed again when the load drops below 0.75 for both one and five minutes. Using the system load average as a metric to decide what speed you run your processor at isn't terribly state of the art, but it Works For Me(tm); my processor isn't put to full speed when some short cpu-intensive job comes up for three seconds, but if something decides to use it for a bit longer, it does turn it up after approximately 30 seconds. Once it reaches that, it stays there until (on average) a few minutes after the cpu-intensive job has finished. I like it that way.

I finally replaced my aging SCSI scanner over the weekend. It was making really odd noises while scanning, and had somehow upset my SCSI chain such that the BIOS could load GRUB ok, but GRUB then couldn't load the kernel. I have better things to do with my time than sacrifice goats, so I went looking for a cheap 'n cheerful replacement. Oddly enough PC World provided an acceptable option. They have a system whereby you can reserve an item on the web for pickup from your local store, and get a reduction off the in store price. I have no idea why they don't just reduce in store prices anyway. I ended up with a Canon LiDE 60 for £44.82, slightly less than ebuyer charge before P&P and with the added advantage that I could go and pick it up on Saturday. I had, of course, done some research beforehand to ensure this was a supported scanner, however it turned out I'd misread. I thought the version of SANE in Debian was a little old; turned out the versions for sane-frontends and sane-backends differ and I'd looked at the former instead of the latter. Plus I thought I was going to need to pull a CVS or snapshot copy to get the support I needed. So I unwrapped the scanner, plugged it into a spare USB port and checked lsusb showed it up. Then, just to see what would happen, I tried scanimage -L and was rewarded with device genesys:libusb:004:009' is a Canon LiDE 60 flatbed scanner. Rock. scanimage just worked and produced a nice PNM of my Electric Six CD inlay. I don't think installation could have got any easier than that. Admittedly I already had SANE installed as I'd had a previous scanner, but if I hadn't the only addition would have been aptitude install sane-utils.

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

Linux/glibc/ELF shared library function calls are said to be slower than static library function calls, because function calls a redirected through plt/got section, which jumps to addresses specified by the offset in GOT.The background for this indirection is that ELF specification implies that load address of a shared library is not pre-determined, and addresses are decided after load.To make this happen, allowing write to the whole text segment (where all the code is, includingjump addresses and other things) will disallow read-only mmap of executable binary.That means backing store is required in terms of swap space.To minimise the effect of modified jump instructions, the modifiable jump instructions are split off into another section, which is writable all the time, called GOT.(this is my understanding, if you find any corrections, please send me a mail, so I can secretly update this page).Anyway, there's an extra jump instruction involved for shared library function calls.I made a short micro-benchmark and measured the time required to make sure that was the case.I called function call for 1G times on a 500MHz powerpc.Apparently, it takes 2 clock-cycles of overhead.

<span class='ljuser' style='white-space: nowrap;'><a href='http://auzure-skies.livejournal.com/profile'><img src='http://stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0;' /></a><a href='http://auzure-skies.livejournal.com/'><b>auzure_skies</b></a></span> and I just passed our 4th year wedding aniversary. We went away and had a good time enjoying one another's company. This partly because we managed to pick a town to visit that had little else to do on a Saturday night. The main attraction in the city is a large catherdral that seems to take up most of "downtown". <div style="float: right; margin-left: 10px; margin-bottom: 10px;"> <a href="http://www.flickr.com/photos/91538913@N00/111678841/" title="Cathedral in St. Jerome"><img src="http://static.flickr.com/34/111678841_d75a5acdec_m.jpg" alt="" style="border: solid 2px #000000;" /></a> <br /> <span style="font-size: 0.9em; margin-top: 0px;"> <a href="http://www.flickr.com/photos/91538913@N00/111678841/">DSC00030</a> <br /> Originally uploaded by <a href="http://www.flickr.com/people/91538913@N00/">jbailey</a>. </span>.<br /><br /><div style="float: left; margin-left: 10px; margin-bottom: 10px;"> <a href="http://photos/jbailey/111678837/"><img src="http://static.flickr.com/35/111678837_0b3cd503b8_m.jpg"></a></div><br />Had a good time, though. It's nice to get out of the city for the weekend.<br /><br />Meh. This entry was going to be longer. Took too long to figure out how to do redeye reduction in the gimp and how to work <a href="http://www.flickr.com/">flickr</a>.</div>

"WTF, removal requests?" you may think now. There was Mono packages in Debian for architectures that don't work (not with Mono at least), it compiled at some time though. Whenever a package got build for an architecture, the debian/unstable -> debian/testing system will only add or update packages in testing when there are current versions of all build packages. This means the packages that should not be there must be removed from the archive by the ftp.debian.org crew via a removal request, to allow going in debian/testing. This happened for Mono with s390, sparc and alpha.
Short version: Mono can now enter debian/testing and should be in it, in the next days!

There's nothing more disturbing than a wrong monitor resolution setting. In my lack of understanding I chose 1280x1024 for use with my 19" CRT, as I was tired of the huge 1600x1200 workspace. (My vision got slightly worse over time and I hate wearing glasses when I am staring at a computer monitor.) So 1280x1024 is not really 4:3 and I only noticed it when I looked at something which should have been a circle but was an ellipse instead. Well, armed with a set square (oh, I would have written measuring triangle, but ok, this seems to be the technical term for it) I refit the image displayed by my CRT to have the same DPI setting on both the vertical and the horizontal direction. So circles are circles again and squares are squares. The world is looking nice again! It is still a bit unnatural, given the black borders on the left and the right side of the picture. But well, it's certinaly more room than 1280x960 would provide me.

Quite a while ago, the XFree86 people managed to finally piss off everyone with their license change to the XFree86 1.1 license, so that everyone upped and went back to X.org. After that, they released XFree86 4.5.0, but nobody's been looking. So, I wondered whether they'd still be active, and what would be going on. The X source is quite a lot, it'd be hard to manage that with just a couple of people. Would be interesting to see what they've been up to, I thought. So I went and had a look at their CVSweb server, to see what the recent commits were. If there were any. Well, there have been. The latest commit I saw was the one by David Dawes, all over the tree, done 11 days ago. It goes like this:

===================================================================
RCS file: /xf86/anoncvs/cvs/xc/lib/X11/ConnDis.c,v
retrieving revision 3.32
retrieving revision 3.33
diff -u -r3.32 -r3.33
--- xc/lib/X11/ConnDis.c	2004/06/24 02:21:15	3.32
+++ xc/lib/X11/ConnDis.c	2006/01/09 14:58:24	3.33
@@ -1,4 +1,3 @@
-/* $Xorg: ConnDis.c,v 1.8 2001/02/09 02:03:31 xorgcvs Exp $ */
 /*
  
 Copyright 1989, 1998  The Open Group
@@ -24,7 +23,7 @@
 in this Software without prior written authorization from The Open Group.
 
 */
-/* $XFree86: xc/lib/X11/ConnDis.c,v 3.31tsi Exp $ */
+/* $XFree86: xc/lib/X11/ConnDis.c,v 3.32 2004/06/24 02:21:15 tsi Exp $ */
 
 /* 
  * This file contains operating system dependencies.

Yes, very crucial commit. Wait, it gets better: the commit message says 'Remove most foreign cvs keywords.' "Most"? You mean you've been slaving at all those files, carefully removing the Xorg headers, and you've left some behind? Are you kidding? But I'm not being very fair to them, obviously. There've been more commits over the last year, and most of those did not relate to comments in the code. They relate to the Imakefiles. They've been doing nothing but fixing the build system. Wonderful, isn't it? Those pesky Imakefiles... So that's it? Comment changes and build fixes? Nothing else? Well, no. I'm lying. There's also been this:

 161. Implement a major #include rework throughout the tree.  Also enforce it
      for all non-external builds (i.e. in-tree & SDK)  (Marc La France).
 160. Rework the building of hw/xfree86/parser to be more in line with the
      building of other server subdirectories (such as common/)
      (Marc La France).
 159. ANSIfy /xc/lib/font/builtins/, and fix warnings, whitespace & formatting
      (Marc La France).

A major #include rework? Wonderful. Must be some great new feature, right? Almost:

@@ -62,8 +61,8 @@
 
 #include "attributes.h"
 
-#include "Xlib.h"
-#include "Xresource.h"
+#include <X11/Xlib.h>
+#include <X11/Xresource.h>
 #include "Xrm.c"
 
 static XrmDatabase CopyDb(XrmDatabase inDb);

Yes, very useful. I didn't go through the entire tree (have better things to do) but, really; if this is the average quality of the commits they've been doing, one wonders why they don't just give up. Oh well...

Just killed all the remaining comment spams (I hope) and implemented a simple regexp based blacklist which should get most medicaments, potence pills, casinos, lotteries and other frequently posted junk. I hope, it does not hit too many valid posts. If you have problems posting comments, feel free to contact me by e-mail or on IRC. In other news, I installed the blosxom plugin comments_recent and adapted the mail feature of writeback notify to my (in the meanwhile heavily modified) instance of the comments plugin v0.6. I also made it symlink-safe for use with multcat.

Since the demand for blosxom anti-comment-spam solutions respective appropriate blosxom plugins seems to be really high, I’ve decided to polish up my apparently quite well working although still in beta state being anti-spam enhanced version of the comments plugin (ZIP) by putting the blacklist outside in an external file and writing some (still short) docs. I use it since 11th of January this year and got only two spam comments and many more normal comments since then, so it should work. Although: I also got a question if my trackback doesn’t work. Hmmm. So no warranties, just an offer for help fighting against comment spam. ;-) Another feature which is basically ported from the writeback notify plugin is notification of the blog owner about new comments by mail. Since on the server on which my blog runs the used Perl module Mail::Sendmail was not available, I used Mail::Send instead for my version. For installation you first need to download the ZIP file of the original comments plugin, install it’s templates and then install my anti-spam enhanced version of the plugin itself.

Now playing: Rockapella — Come on Eileen

I once decided not to have a blog, because I feared, the time I will spent blogging would vanishing from my Symlink time. But due to Symlink not being a real blog but rather a news and discussion website with a journalistic attitude and limited subjects, there are topics missing I would like to write about. And due to not wanting to spam my beloved IRC channels with all those uninteresting subjects, a blog seemed to be the right place: Nobody needs to read it, but anyone can read it. And since Blosxom (which I first noticed at zobel’s and at alphascorpii’s blog) is fully the way I would design a blog (technically), I installed it today, tweaked a little bit the httpd.conf of our Apache and there it is: My never wanted but inescapably closer coming weblog named Blogging is futile. And it will probably be mixed, German and English.

I voted "1243" in the current Debian GFDL vote. If you are a Debian developer who hasn't voted yet, please do so ASAP. Democracy lives from participation, so make up your mind. Debian should reject the GFDL for the pointed out issues. From what I've heard from others, this option will likely win. Accepting documents with no invariant sections (except the copyright part) is a compromise I could live with, changing the social contract is not, so I rated it second. I am aware of the other issues with the GFDL, but I hope that these could be sorted out somehow with the FSF. They aren't unreasonable people, after all. And there is a certain amount of interpretation in any legal document. Probably only the copyright holders can sue, and why should they as long as e.g. the DRM used doesn't really prevent access to the original documents, or the transparent copy restriction is fulfilled since the original documents are still online? But I'm really close to voting "1342" instead. But since I'm really expecting people to rank 1 first, I don't think it matters much.

One year ago, I uploaded shadow 4.0.3-31 with "New maintainer" in the changelog. During this year, the shadow maitenance team has been built with Alexander Gattin, Christine Spang, Martin Quinson and last but definitely not least Tomasz Kloczko, the upstream author and Nicolas Fran ois, the best non DD ever. In one year, this wonderful team built 35 releases, closed 214 bugs (according to the changelog), cleaned out the BTS which had about 300 opened issues at that time. There are now 35 opened bugs, 24 being fixed in upstream's CVS, 3 tagged "wontfix" and 1 fixed in experimental. In short, there is no reported issue that hasn't received attention. It took us six months before being able to resynchronize the Debian version of login and passwd with upstream. After achieving it and after dozens of exchanges with upstream, the size of the diff.gz file went down from over 1.5MB to about 120kb in the next release. Upstream changelog is now full of patches and rewards to Debian. We used 26 cheese names for naming releases in a tradition established after a famous Cheese Party held at Debconf 5. Be prepared for the Debconf 6 Cheese Party! I see this work as a good example of revival work for an essential package and good collaboration with upstream. I probably have my part in this, trying to keep the communication, sometimes making decisions and always revive work on forgotten issues. But, definitely, I have to deserve a special mention to Nicolas. He's definitely the one who understand the whole code and when he didn't knew, he just learned. Without him, we would never have been able to achieve this. Please, just give him direct DAM approval if he ever applies as a NM...:-) Again, happy birthday to the new shadow....