Last week-end, I went very close to the 2/3 marathon mark by running 27 km again after I did one such run on Nov. 11th. So, indeed, I ran 27km twice with only 4 days in between (and I ran also 7km during two of these four days). That last 27km run was like a November dream: over 20km in woods, with muddy paths full of dead leaves, about 200 meters positive slope (in four climbing sections), and I didn't finish completely dead. The rate was 5'55"/km (9'37"/mile, Dirk). Tuesday, I didn't go under the 6'/km mark, so that's an improvement. Actually, this is mostly because this time, I wasn't originally imagining I would go for so long, but more an half-marathon. Ralf Treinen and No l K the (who ran together at Cologne marathon the week-end before) are trying to convince me to participate to the Paris marathon next April. It seems indeed more and more likely that I will. Other Debian runners, what about meeting next April in Paris and do it? I can host folks in my house, of course. All this, the very same week-end Bdale got his level 3 in rocketry. Great success for the 61 folks.... Cheers!

Australia has slow Internet access when compared to other first-world countries. The costs of hosting servers are larger and the cost of residential access is greater with smaller limits. I read news reports with people in other countries complaining about having their home net connection restricted after they transfer 300G in one month, I have two net connections at the moment and the big (expensive) one allows me 25G of downloads per month. I use Internode, here are their current prices [1] (which are typical for Australia - they weren’t the cheapest last time I compared but they offer a good service and I am quite happy with them). Most people in Australia don’t want to pay $70 per month for net access, I believe that the plans which have limits of 10G of download or less are considerably more popular. Last time I investigated hosting servers in Australia I found that it would be totally impractical. The prices offered for limits such as 10G per month (for a server!) were comparable to prices offered by Linode [2] (and other ISPs in the US) for hundreds of gigs of transfer per month. I have recently configured a DomU at Linode for a client, Linode conveniently offers a choice of server rooms around the US so I chose a server room that was in the same region as my client’s other servers - giving 7 hops according to traceroute and a ping time as low as 2.5ms! Currently I am hosting www.coker.com.au and my blog in Germany thanks to the generosity of a German friend. An amount of bandwidth that would be rather expensive for hosting in Australia is by German standards unused capacity in a standard hosting plan. So I get to host my blog in Germany with higher speeds than my previous Australian hosting (which was bottlenecked due to overuse of it’s capacity) and no bandwidth quotas that I am likely to hit in the near future. This also allows me to do new and bigger things, for example one of my future plans is to assemble a collection of Xen images of SE Linux installations - that will be a set of archives that are about 100MB in size. Even when using bittorrent transferring 100MB files from a server in Australia becomes unusable. Most Australians who access my blog and have reasonably fast net connections (cable or ADSL2+) will notice a performance improvement. Australians who use modems might notice a performance drop due to longer latencies of connections to Germany (an increase of about 350ms in ping times). But if I could have had a fast cheap server in Australia then all Australians would have benefited. People who access my blog and my web site from Europe (and to a slightly lesser extent from the US) should notice a massive performance increase, particularly when I start hosting big files. It seems to me that the disadvantages of hosting in Australia due to bandwidth costs are hurting the country in many ways. For example I run servers in the US (both physical and Xen DomUs) for clients. My clients pay the US companies for managing the servers, these companies employ skilled staff in the US (who pay US income tax). It seems that the career opportunities for system administrators in the US and Europe are better than for Australia - which is why so many Australians choose to work in the US and Europe. Not only does this cost the country the tax money that they might pay if employed here, but it also costs the training of other people. It is impossible to estimate the cost of having some of the most skilled and dedicated people (the ones who desire the career opportunities that they can’t get at home) working in another country, contributing to users’ groups and professional societies, and sharing their skills with citizens of the country where they work. Companies based in Europe and the US have an advantage in that they can pay for hosting in their own currency and not be subject to currency variations. People who run Australian based companies that rent servers in the US get anxious whenever the US dollar goes up in value. To quickly investigate the hosting options chosen for various blogs I used the command “traceroute -T -p80” to do SYN traces to port 80 for some of the blogs syndicated on Planet Linux Australia [3]. Of the blogs I checked there were 13 hosted in Australia, 11 hosted independently in the US, and 5 hosted with major US based blog hosting services (Wordpress.com, Blogspot, and LiveJournal). While this is a small fraction of the blogs syndicated on that Planet, and blog hosting is also a small fraction of the overall Internet traffic, I think it does give an indication of what choices people are making in terms of hosting. Currently the Australian government is planning to censor the Internet with the aim of stopping child porn. Their general plan is to spend huge amounts of money filtering HTTP traffic in the hope that pedophiles don’t realise that they can use encrypted email, HTTPS, or even a VPN to transfer files without them getting blocked. If someone wanted to bring serious amounts of data to Australia, getting a tourist to bring back a few terabyte hard disks in their luggage would probably be the easiest and cheapest way to do it. Posting DVDs is also a viable option. Given that the Internet censorship plan is doomed to failure, it would be best if they could spend the money on something useful. Getting a better Internet infrastructure in the country would be one option to consider. The cost of Internet connection to other countries is determined by the cost of the international cables - which can not be upgraded quickly or cheaply. But even within Australia bandwidth is not as cheap as it could be. If the Telstra monopoly on the local loop was broken and the highest possible ADSL speeds were offered to everyone then it would be a good start towards improving Australia’s Internet access. Australia and NZ seem to have a unique position on the Internet in terms of being first-world countries that are a long way from the nearest net connections and which therefore have slow net access to the rest of the world. It seems that the development of Content Delivery Network [4] technology could potentially provide more benefits for Australia than for most countries. CDN enabling some common applications (such as Wordpress) would not require a huge investment but has the potential to decrease international data transfer while improving the performance for everyone. For example if I could have a Wordpress slave server in Australia which directed all writes to my server in Germany and have my DNS server return an IP address for the server which matches the region where the request came from then I could give better performance to the 7% of my blog readers who appear to reside in Australia while decreasing International data transfer by about 300MB per month.

• [1] http://www.internode.on.net/residential/internet/home_adsl/nakedextreme/pricing/


• [2] http://www.linode.com/


• [3] http://planet.linux.org.au/


• [4] http://en.wikipedia.org/wiki/Content_Delivery_Network

I love collecting quotes but I file most of them away in some file on my computer or distribute them in class. I thought I might start sharing some of my favorite passages/quotes. This one, which I read 3 years ago, reminded me of the craft-like spirit in Debian and Free Software in general. I like how the author brings together the themes of labor, time, quality, mistakes, intimacy and tools all in one swoop.

I refuse to be in such a hurry that I squeeze the aesthetic value out of everything just to gain a few minutes of time time which will then just be filled with more rushing and more mass-produced, soulless junk. In the drive to achieve instant gratification, we have spent a century trying to shorten the learning curve and eliminate the chance of error in every human activity. There is much good in this, but something has been lost in the process. The Galoots are the guardians of that which was almost lost: the challenge of trying to master a skill that can never be fully mastered, the creative freedom that comes from intimacy with a medium as complex as wood, the sense of self-sufficiency that comes with knowing that you can make a useful object with tools so simple that you can make the tools too, and the peaceful mediation of trying to bring eye, hand, and wood together into harmony through finesse and understanding rather than brute force.

Quoted from Hohn (2005), The Romance with Rust, a Harper’s article on tool collectors. A Galoot is a person with a deep passion for old hand tools, their ways, workings, and their history.

For various reasons I've recently been thinking about forums. Many technical users dislike forums, because they are things that are hard to follow. Even with RSS feeds & etc you need to keep a login and remember to return to see if your post(s) have been answered. However non-technical users love forums, and from a community-building perspective they're very cheap and easy. Particularly if you manage to appoint moderators from within the comunity. I currently find myself in a position where I'd kinda like to have a forum package. Something that I can integrate into existing site easily. Unfortunately most of the "best" forum packages are PHP-based, and have their own complex login, group, and admin facilities. That makes it hard to update them to authenticate against my existing MySQL table(s). (We'll leave my PHP-allergy in the background) So, once more, I've been contemplating the bad route; create my own forum software. I'm well aware that down that path lies badness madnesss. Let us recap. What is a forum?

• A forum is an online site.
• With a coarse list of topics.
• Inside each topic is a list of threads.
• Each thread is comprised of a number of (threaded) messages.

Sound familiar? It should if you use email:

• ~/Maildir contains storage for a collection of mailboxes.
• Each mailbox is a course list of topic-specific discussion.
• Each topic is comprised of a number of (threaded) messages.

So, the unthinkable, could we convert (bi/uni-directinally?) from a Maildir hierarchy to an online forum? Would that make sense? On the face of it. Yes. There are implementation details - the forum index would be essentially a list of Maildir folders (perhaps "~/Maildir/topic1/.title" would be require to give it a pretty name). Each thread topic would be a rendered display of the messages in the folder. So, what are the drawbacks? Well reading Maildir folders gives us threading, and subjects, bodies, etc. But it does mean a fair bit of overhead parsing messages. (Times like this I remember Hughe. Every time we've gotten together for beer & geekery the topic of an extensible perl-based IMAP server comes up. I'm sure it should be written ..) I'll wrap this up now. I'm sure I've made the point. There are some details which have impact - Should the forum accept new posts online? Or only via gated email-delivery? Will it work? Should it be Maildir, or IMAP based? Still at least filtering your SPAM would be easy ;) More questions. Some questions have no answers. Some answers we ignore because we don't like. I need to sleep. ObFilm: 007: Quantum of Solace Bad film. Don't waste your pennies.

Today, the NYT has an interesting piece on the declining numbers of women in the field of computer science. Ultimately the article presents a bleak picture but does not give a firm sense of why this is so (I think because it is so hard to answer). I do agree that if girls are not hopping on the computer at a young age and are not using it as a tool for production (they do use it a social tool), they are always going to have trouble catching up to men. Many CS majors, not to mention most hackers, develop quite intimate relations with the computer from a young age and thus have a level of comfort and expertise they have is nothing short of astonishing. If women are not developing that expertise as children but only much later in life, there will always be two classes of citizens in computing. Men, in other words, are native speakers, while women learn computing as a second language. The comment I agree with less is the following:

Ms. Cassell identifies another explanation for the drop in interest, which is linked to the pejorative figure of the nerd or geek. She said that this school of thought was: Girls and young women don t want to be that person.

It seems to be that in fact in the 80s and prior to that, the only word in town to describe computer folks were nerds. But geek arose to take its place and in part to take away the pejorative sting. Geek is cool. Nerd is not. And geek is now associated with all sorts of computer cultures in a way that it was not before. So it seems to be that more than ever, there is a positive geeky association with computing so in fact this would open the doors to more people than before.

One often requested feature for suspend support on Linux is hybrid suspend, or "suspend to both". This is where the system suspends to disk, but then puts the machine in S3 rather than powering down. If the user resumes without power having been removed they get the benefit of the fast S3 resume. If not, the system resumes from disk and no data is lost.

This is, clearly, the way suspend should work. We're not planning on adding it by default in Fedora, though, for a couple of reasons. The main reason right now is that the in-kernel suspend to disk is still slow. Triggering a suspend to disk on a machine with gigabytes of RAM (which is a basic laptop configuration these days) will leave you sitting there for an extended period of time when all you actually want to do is pick your machine up and leave. Fixing this properly is less than trivial. TuxOnIce improves the speed somewhat, at the expense of being a >500k patch against upstream that touches all sorts of interesting bits of the kernel such as the vm system. We're not supporting that for fairly obvious reasons. But even then, the suspend to disk process involves discarding some pages. Those need to be pulled in from disk again on resume. With the current implementation, suspend to both is fundamentally slower than suspend to RAM for both the suspend and resume paths.

So, what other approaches are there? One is to resume from RAM some period of time after suspending and then if the battery is low suspend to disk. Many recent machines will automatically resume when the battery level becomes critical. If the hardware doesn't support that, we can wake up after a set period and measure the battery consumption, set a new alarm and go to sleep again. The downside of this approach is that your system wakes up and does stuff without you being aware of it, which may be bad if it's inside a neoprane cover at the time. Cooking laptops is generally considered unhelpful.

Using the kexec approach to hibernation provides a more straightforward way of handling the problem. The fundamental problem with the existing approach is that it ties suspend into the vm system and involves making atomic copies of RAM into other bits of RAM. kexec would allow us to pre-allocate enough space on disk to save RAM as-is, and then simply kexec into a new kernel and dump RAM to disk without any of the tedious shrinking required first. Resuming from S3 would kexec back into the old kernel, whereas losing power would just fall back to reading off disk. The extra time taken on the S3 path would be minimal.

In an ideal world we'd adopt the Vista approach where "off" is synonymous with suspend. There's still more work to be done on enhancing reliability before that can be achieved, though.

I played with an Eee for a bit last time I was in Boston, culminating in a patch to make the eeepc-laptop driver use standard interfaces rather than just having random files in /sys that people need to write custom scripts to use. The world became a better place.

However. Asus implemented the rfkill control on the Eee in a slightly odd way. Disabling the wifi actually causes the entire card to drop off the bus, similar to how Bluetooth is normally handled. The difference is that the Bluetooth dongles are almost exclusively USB, while the Eee's wifi is PCI. Linux supports hotplugging of PCI devices, but nothing seemed to work out of the box on the Eee. Another case of this was the SD reader in the Acer Aspire One. Unless a card was present in the slot during boot, it simply wouldn't appear on the PCI bus. It turned out that Acer have implemented things in such a way that removing the card results in the entire chip being unplugged. This was when I started looking more closely into how this functionality is implemented.

The two common cases of PCI hotplug are native PCIe hotplug and ACPI mediated hotplug. In the former case, the chipset generates an interrupt when a hotplug event occurs and the OS then rescans the bus. This is a mildly complicated operation, requiring enabling the slot, checking whether there's a card there, powering the card and all its functions up, waiting for the PCIe link to settle and then announcing the new PCI device to the rest of the OS. ACPI-mediated hotplugging puts more of the load on the firmware rather than the OS - the hotplug event generates a notify message that is caught by the ACPI interpreter in the OS, allowing the OS to check for device presence by calling another ACPI method. If the device is present it's then a simple matter of telling the PCI layer about it.

Native PCIe hotplug has the advantage that there's much less vendor code involved. ACPI is still involved to an extent - an _OSC method on the PCIe bridge is called to allow the OS to tell the firmware that it supports handling hotplug events. This allows the firmware to stop sending any ACPI notifications. ACPI hotplugging requires more support in the firmware, but can work for PCI as well as PCIe.

The general approach taken to getting the Eee's wifi hotplugging to work has been to load the pciehp driver with the pciehp_force=1 argument. This tells the driver to listen for hotplugging events even when there's no _OSC method to tell the firmware that the OS is handling things now. Since the hardware will generate the event anyway, things work. However, this is non-ideal. Some hardware exists where ACPI hotplugging will work, but due to quirks in the hardware design native PCIe hotplugging control will fail. This has been handled in their firmware by having the _OSC method fail, signalling to the pciehp driver that it shouldn't bind to the port. Using pciehp_force overrides that, leading to a situation where hardware could potentially be removed from a port that's powered up. Unfortunate.

My first approach was to add a new argument to pciehp called pciehp_passive. This would indicate to the pciehp driver that it should only listen for notifications from the hardware. User-triggered events would not be supported, avoiding the situation where anyone could remove the card by accident. This worked on my test machine (an Eee 901 somewhere in Ottawa, since I don't actually have one myself...) but was reported to work less well on a 700. Since the 700 didn't claim to have any support for power control, the code was forced to wait a second on every operation to see whether the link powered up or not. This resulted in long pauses during boot and suspend/resume operations.

The final issue that convinced me that this was the wrong approach was reading a document on Microsoft's site on how PCIe hotplugging is implemented in Windows. It turns out that XP doesn't support native PCIe hotplugging at all - that feature was added in Vista. Both the Eee and the Aspire One are available with XP, but things work there. So PCIe native hotplugging was clearly not the right answer. Time to look further.

Armed with a disassembly of the Aspire One's DSDT, I figured out why the ACPI hotplug driver didn't work on it. The first thing the driver does is walk the list of ACPI devices, looking for any that are removable. That was being implemented by looking for an _EJ0 method. _EJ0 indicates that the device can be ejected under the control of the OS. The Aspire One doesn't have an _EJ0 method on its SD readers. However, it did have an _RMV method. This can be used to indicate that a device is removable but not ejectable - that is, the device can be removed (by physically pulling it out or by the hardware taking it away itself), but there's no standard way to ask the OS to logically disconnect it. A quick patch to acpiphp later and the Aspire One now worked without any forcing or spec contravention. This also has the nice side effect of making expresscard hotplug work on a bunch of machines where it otherwise wouldn't.

But back to the Eee. acpiphp still wasn't binding, and a closer examination revealed why. There's nothing to indicate that the Eee's ports are hotpluggable, and there's no topological data in the ACPI tables that ties the wifi function to the PCIe root bridges. However, the Eee firmware was sending an ACPI notification on wifi hotplug. But it was only sending this to the PCIe root bridges, and there's no way to then tell which device had potentially appeared or vanished.

In the end, I gave up on trying to solve this generically. Instead I've got a patch that implements the hotplugging entirely in eeepc-laptop. In an ideal world nobody else will have implemented this in the same way as Asus and we can all be happy.

One month with Emacs and counting - Part 2 A while ago I've blogged about my switch from Vim to Emacs, promising a blog post series, quite a mouthful nevertheless, it's time to continue the series. The first part was about why I think that nowadays Emacs is ready to be switching to. This second part is about flawed Vim design choices which substantially contributed to my choice. (Of course all this post is under a IMO-/rant-disclaimer, it can't be otherwise, so take it cum grano salis) Flawed Vim design choices Vim started as a wonderful editor, following the path of Vi, which in turn has got right a good deal of design choices. One is the often debated modality. In spite of being a HCI PITA in general, modality is not a problem at all for software you are using every single day (and the editor is the 2nd program I use the most, with the terminal being the 1st), because you learn it as a habit. In the case of Vim, modality is good because it let you use powerful yet simple motions in command mode, which can be easily combined with operator-pending commands. This can be considered yet another incarnation of the UNIX philosophy, casted inside the editor itself. ... which brings us to the good old joke which describes Emacs as a great operating system, lacking only a decent editor. In fact, Vim is no longer the nice Unix philosophy player which it used to be, and Emacs plays much more nicely with external tools than Vim. As arguments, let's consider a few (not so) recent Vim evolutions:

• Spell checking. Starting with version 7, Vim has got support for on-the-fly spell-checking of text buffers. It is a super-nice feature, which I've advertised in the past, because spell checking is needed in many tasks we daily do with editors (mail/doc writing, code commenting), and having a single interface to do it comes handy. Unfortunately, how that is implemented in Vim is definitely not along the lines of the UNIX philosophy. We have countless different FOOspell implementations whereas Vim implemented yet another one, without relying on any pre-existing implementation. Even more so, the file format of spell files is basically ad-hoc, and not sharable with other tools. This is already a PITA for packaging (let's add to Debian another 20 binary packages vim-spellfiles-FOO), but is even worst than that: the spell files must be generated in ad-hoc ways which are seriously prone to failures (guess why in Debian we don't have yet the vim-spellfiles-FOO packages which used to exist in experimental a long time ago?). What would have been the UNIX-friendly way of achieving the same result? Well, obviously spawning FOOspell and interact with its process from the editor. Keep that in mind.
• Internal grep. A feature of Vim I've always loved is :grep (yet another instance of quick-fixing, which is also used for jumping to compile-time errors). In its original incarnation it was as simple as invoking grep and parse its output. KISS. Then, Vim started to have a problem: grep -r can take ages and in the meantime the editor was stuck. Hence, starting with Vim 7, vimgrep has born: an internal re-implementation of grep. OK, it is more portable (but how many of us do care? on how many system you use you are missing grep? damn, I used to install it also on Windoze!), and the editor retain control. Control that is exploited just to show a nice progress bar of what is being scanned ..., while the editor is still stuck. Well, to me it looks like the problem would have been solved much more nicely by adding the ability to interact with an external process (deja vu?). That process can then be grep -r. Full stop.
• Lack of debugging support (on purpose). Long standing missing feature of Vim: you can not "easily" drive a debugger from Vim, because a firm choice in Vim is to ... (OK, I confess, I'm starting to beat a dead horse) ... not have support for interaction with external processes. I found such a choice quite dumb: to me it is evident that it induces a trade-off between being feature-complete wrt programmer needs (as available external tools get available to face those needs) and not "re-implementing the wheel" inside the editor. Going back to the lack of debugging support in Vim, that has spawned projects like GdbVim, Clewn, Bram's Agide, and my own tiny teeny incarnation specific to ocamldebug called WOWcamldebug. Every single project of that list acts as an intermediary between Vim and an external process (a debugger of some sort), whereas that could have been implemented by an editor plugin, provided that the editor offer, guess what, support for interaction with external processes.
• Top-level. Similar to the debugging support issue, there is the interpreter issue, namely how to evaluate "phrases" of your interpreted language of choice directly from the editor. Nowadays a lot of languages have the so called top-levels which evaluate language phrases interactively (Python, Ruby, OCaml, many Lisps, ...) and show evaluation results. That ability can speed up testing considerably, but can become cumbersome to use for large code snippets without editor support (good luck with copy and paste). Yes, Vim has support for that, but the implementation choice is close to be ridicolous: only if you have linked Vim together the interpreted for a given language, then you will be able to interactive evaluate phrases of that language. What if you program in Python, Ruby, and Perl? Well, you need to link all of them. What if you also program in OCaml? Then you're screwed, because Vim currently does not support linking with it. (Yes, I know that there are other reasons for doing that linking, they are discussed below.) Do I need to tell you which feature will be enough to address top-level support? interaction with extern.. OK, I'll drop it, you know that already.

Well, I acknowledge that Emacs got this choice right, and that it's an important one: Emacs supports interaction with external processes, and plugin authors have been happy to exploit it to create really cool stuff (sticking to the UNIX philosophy). Please welcome: Flyspell, M-x grep (shameless smartass plug: same number of keystroke of :grep), Grand Unified Debugger, a sampling of language-specific major modes with top-level support. (But I recommend having a look at least once at the coolness of other stuff built-on top of external process support, like Flymake, mentioned by dancer not a long ago.)

• Its own scripting language. I've bored you enough with the external process topic, hence here is the second one: the saga of Vim and its scripting language, i.e., the programming language using which you can customize the editor. Note that the choice of scripting language impacts on 2 different targets: final users in need of fire and forget automations (when they start to get to complex to be implemented on top of, say, macros), and developer of editor extensions such as addons. The impact of scripting language on extension developer is crucial for the evolution of an editor aiming at being powerful. If the scripting language and the API towards the editor is flexible enough, then a lot of cool extensions and features will be developed by third party authors, otherwise the burden stays on editor upstream author.
  1. In its phase 1 (my term, Vim < 7.0) Vim pretended that it needed only a minimal scripting language (Vim script) and that everything else can be developed using external programming languages, linked in the editor. As a consequence Vim script was just a tiny teeny procedural language with editor interfacing capabilities, most notably lacking any "decent" data structures (no lists, no dictionaries, ...). In that phase, if you were a user it was fair enough. You just had to chose your external programming language (at compile time ...), and you were able to write your quick hacks with it. But if you were willing to develop an extension you were screwed, because you had either to impose your external programming language to the final user (that is what gave born to absurdities like vim-full, look at the deps!) or to enjoy a good deal of masochism to explode your 30 lines of Python extension into 200 lines of Vim script to make your Vim extension more "portable".
  2. In its phase 2 (Vim >= 7.0) it has been realized that something were wrong in the initial choices about Vim script, and data structures (lists, dictionaries, function references!) have been added to it, relieving a bit the pain of programming portable extensions. Nevertheless, and probably due to how it started, Vim script is far from being a programming language one can enjoy programming in. Consider for example the standard library of the language. It started as a random collection of unrelated functions being added on a "as-needed" basis, ... and continued along that path! Now the API reference lists together totally unrelated functions, organized inconsistently, and making really painful finding what you need (assuming it exists).

Even in this respect, I acknowledge that Emacs got this right. It has chosen a single, now full-fledged, programming language (Elisp), which is offered both to the final user (fact: the average Emacs user knows much better how to program her own editor than the average Vim user) and to extensions developer. The standard library of the language is organized with a consistent naming (even though not always intuitive) and documented in an organized manner. You might not like the language, but at least is has been taken seriously and managed as such. Finally, being a Lisp dialect, you might need what you learn with Elisp elsewhere. Vim script is too committing: it is useful only inside Vim. I believe that contributed significantly in its scarce diffusion among Vim users. The fact that Elisp was born together with Emacs and that it is also used internally for the editor implementation is not relevant here: I do care about what is offered to me as an user and as an extension developer. What I see on the Emacs side in this respect is much better that what I see on the Vim side. Moreover, from the point of view of the users, is the difference between what is inside the editor and what is outside (i.e., the extensions) that relevant? I think it is not, and that brings me to the final Vim choice which I consider flawed and which has the potential of seriously limit its future evolutions:

• Editor as a distribution. Emacs is managed as a intermediate software distribution layer, similarly to what happens in other softwares where many third party authors cooperates (e.g., TeXLive). The distribution architecture has advantages and contributes to the longevity and potentialities of a software project. What does this mean concretely in the Vim vs Emacs dispute? For example it means that Emacs get more feature-complete each passing release, still preserving uniformity in documentation and keybindings. On the contrary Vim sports many addons, which are very likely to step on each other feet when enabled simultaneously. Actually, that is one of the reason which brought me to the creation of vim-addons: you cannot enable all the content of vim-scripts together due to various kind of conflicts. As we know well in Debian, distributions have a fundamental role in blending together lightly-coupled software components, that's role is missing in Vim evolutionary path and I find that worrisome.

Where to from here in this blog post series? For sure some tips on how to migrate for hard-core Vim users, then we'll see ... If you did enjoy the read please let me know commenting in the discussion page (as you did in the last post, thanks!).

Hey, Xfce 4.6 Beta 2 Hopper has just been released and, guess what, packages are already available. Still not in unstable (or even experimental), that will wait post-lenny. You can install it from my repository, and, as usual, there's no Debian support on them. The known_issue page is currently quite empty, and this beta looks really quite polished. Packages currently available are i386 and amd64, powerpc will be available when I have time to put the mac at build. This beta features mostly bug fixing, and some features too:

• power management stuff in xfce4-session. Based on a patch included long ago in Ubuntu, it means that when you click the logout button it'll ask you if you want to suspend/hibernate the box. That works through hal and it may need some tuning on the machine. Reports appreciated here or there. 
• soname bump in xfconf. That means package renaming from libxconf-0-0 to libxfconf-0-2. No standard upgrade path (Replaces:) is provided because I don't want to clutter the packages before upload to Debian. This will continue for following changes (libxfconf-0-3 for rc for example). For the final release the library name will be changed to libxfconf-1 and the soname will be reset to 0, which means the package name will be libxfconf-1-0. There again, no upgrade path will be provided for people using my repository. The only upgraded path supported will be 4.4 →4.6. (but you won't be totally alone in the dark, I use 4.6 beta on my laptop so I'll pass through hell before you)
• keyboard shortcut can be configured (both window manager ones and applications) and there is now conflict handling
• session management has been greatly improved, you can now save the session immediately (a long-wanted feature) and it manages stuff like SMRestartImmediately etc.

The official announcement can be found there.
Have fnu!

I hadn’t noticed until today when Jordi Guti rrez Hermoso pointed it out to me: We already have AGPL’ed stuff in Debian, and not only in sid but it will also be shipped in Lenny. We have discussed that license in debian-legal during August and September this year, and in November its usage in client code has also being clarified when the FSF updated their FAQ to address that question, but we never reached a definitive conclussion. I also filed a bug against FTP Master asking them to clarify the situation of AGPL licensed stuff in Debian, which still remains unanswered. In any case, debian-legal is just a mailing list for discussion, and does not have the capacity to take any final decisions (that’s FTP Master’s task) but it would have been nice if someone had pointed it out there.

The D-I team finally released Debian Installer RC1 for lenny. That wasn't an easy process and it revealed some miscommunication and rampant conflicts inside the team. That will needed to be solved for squeeze development but, as of now, we (the very few of us still working on D-I development...) focus on preparing an RC2 release. That release is meant to be out ASAP. It is mostly meant to deal with recent kernel updates and definitely not add new features. Even bug fixing will probably be limited to what's considered major blockers. That's another step towards the overall release of lenny, I think. Now we should probably all focus on remaining RC bugs, which count seems to have stopped going down during last weeks, which is IMHO worrying. But, of course, let our good release team deal with all this first (which probably involves dropping some crappy packages, imho).

For tomorrow’s class we are going to be discussing piracy and we will do so with the help of Alan Toner one of the filmmakers behind Steal this Film. We will be reading some of his work (and this ethnographic look at the life of a p2p file sharer provides a refreshing look at what it actually looks like), as well as the work of Matt Mason among others. We will also be reading an oldie but goodie that I could not find easily online and given that it is a class on piracy, I thought I would honor the class (and the piece) engage in a little transgression. If find the piracy exhilarating, daunting, questionable, or reproachable, come to NYU Free Culture’s screening of Steal this Film part 2, this Sunday Nov 16th at 7 PM. Alan will also be there to field questions and kick off the debate. I am looking forward to the post-movie discussion. update: Here is a flyer with lots more information

I’ve been a member of April, the french association for promotion and defense of Free Software, for a bit more than a year, and I often regret not becoming a member earlier. (I was feeling so guilty and shameful about not being a member that I actually postponed becoming a member.) Stop feeling guilty and shameful, become an April member today! Why Is becoming an April member so important?

• Clearly, April doesn’t address the same problems as your local LUG. April is a country-wide organization, and it works on country-wide problems. It’s the only group able to work on such problems at this scale (I’m not sure of the situation in other countries, but I think CCC shares a similar role in Germany for example).
• Each time I talk to people really involved in April (which I’m not), I’m amazed by how powerful they have become. They are able to talk to french or european deputies or ministers’ cabinets, and are considered important. They are doing a fantastic job spreading what matters to us to legislative and executive powers in France and Europe.

Some of the things they worked on recently (from the top of my head):

• Lobbying on :
  • OOXML
  • General announcements about politics (Plan France Num rique 2012, aka Plan Besson).
  • European telecom package and HADOPI law (french graduated response) law, through Quadrature du net. (OK, it doesn’t have anything to do with April, but most of the people involved in Quadrature du Net are also involved in April :-)
  • vente li e : the fact that it’s not possible to buy a computer without a Windows license. It’s illegal in French law, but still the de facto situation almost everywhere.
• Organization of a campaign where candidates to elections in France where asked questions, or asked to sign a declaration about Free Software. In 2007, 8 out of the 12 candidates of the french presidential election answered April’s questions.

So, really, become a member today. It’s only 10 EUR, and you already know they will be well used. April is trying to reach 5000 members by the end of 2008. (Apparently, if you use that address, April will now that you came from me. No benefit for me at all.)

Cute meme du jour:

• Grab the nearest book.
• Open it to page 56.
• Find the fifth sentence.
• Post the text of the sentence in your journal along with these instructions.
• Don t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.

Well, OK. Page 56, fifth sentence:

“The functions of other software interrupt service routines are quite variable; The I/O postprocessing interrupt service routine has a specific function to perform but is data-driven by the I/O request packets (IRPs) in its work queue.”

I know at least one of the slightly more than one people (I count too, right?) who read my blog (Hi, Ian!) might well realize what book this came from: VAX/VMS Internals and Data Structures, by Ruth Goldenberg and Lawrence Kenah. Yes, the book really was the closest to me - I have an overdesk shelf, and it was the furthest out. The book, by the way, is a fascinating read; I don’t know of any other book that lays out the design of an entire OS kernel in the really quite elegant way that this book does. I got mine signed by Ruth, too, which is pretty damn cool. One highlight of this book are the quotes at the beginning of each chapter - sometimes funny, sometimes profound, frequently both. I decided to list those from the first part here, for the enjoyment of both my readers.

For the fashion of Minas Tirith was such that it was built on seven levels, each delved into a hill, and about each was set a wall, and in each wall was a gate.

- J. R. R. Tolkien, The Return of the King

“By indirections find directions out.”

- Shakespeare, Hamlet, 2, i

While I nodded, nearly napping, suddenly there came a tapping,

As of someone gently rapping, rapping at my chamber door.

Edgar Allan Poe, The Raven

And now I see with eye serene

The very pulse of the machine.

William Wordsworth, She Was A Phantom Of Delight

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

Lewis Carroll, Alice’s Adventures in Wonderland

Between the idea

And the reality

Between the motion

And the act

Falls the Shadow

T. S. Eliot, The Hollow Men

What you want, what you’re hanging around in the world

waiting for, is for something to occur to you.

Robert Frost

“Time,” said George, “why I can give you a definition of time. It’s what keeps everything from happening at once.”

Ray Cummings, The Man Who Mastered Time

I claim not to have controlled events, but confess plainly that events have controlled me.

Abraham Lincoln, Letter to A. G. Hodges, April 4, 1864

‘Tis in my memory lock’d

And you yourself shall keep the key of it.

Shakespeare, Hamlet, 1, iii

Love, all alike, no season knows, nor clime,

Nor hours, days, months, which are the rags of time.

John Donne, The Sun Rising

It is equally bad when one speeds on the guest unwilling to go, and when he holds back one who is hastening. Rather one should befriend the guest who is there, but speed him when he wishes.

Homer, The Oddysey

I was alone and unable to comunicate with anyone. I did not know the names of anything. I did not even know things had names. Then one day, after she had tried a number of approaches, my teacher held my hand under the water pump on our farm. As the cool water ran over my hand and arm, she spelled the word water in my other hand. She spelled it over and over, and suddenly I knew there was a name for things and that I would never be completely alone again.

Helen Keller

Dear Stefan ‘Frost’ Mueller, it was a great pleasure to know you. I’m really shocked, that such a nice and young man was pulled out of life out of the blue. Thanks for all the great things you have done for my family and me. Nothing more I can say at the moment other than ‘I hope we will see us again anytime wherever’.

There have been a number of improvements to the Debian installer on Network Attached Storage (NAS) devices in the last few months and they are available to users now that RC1 has been released. We have added support for Marvell's Orion platform. Orion is a system on a chip (SoC) that integrates an ARM CPU, Ethernet, SATA, USB, and other functionality in one chip. The majority of NAS devices that have come out within the last two years are based on Orion chips, so it's exciting to have support for this significant platform in Debian. Specifically, we support the following devices based on Orion: QNAP Turbo Station (TS-109, TS-209, TS-409), HP Media Vault mv2120, and Buffalo Kurobox Pro (with more to come later). Here are some other newsworthy improvements and changes:

• When a static IP address is set in the original system that is the default from the vendor, this address will now be used. In the past, the installer would use DHCP in this case but users found this confusing. This affects the Linksys NSLU2 and Thecus N2100.
• If a static IP configuration is used in the original system but this configuration is incomplete (i.e. IP address or DNS are missing), then the installer will use DHCP (instead of hanging during start). This affects the Linksys NSLU2 and Thecus N2100.
• On the Linksys NSLU2 and Cobalt devices, all required installer modules are automatically installed now and no longer have to be selected manually from a list.
• initramfs will use MODULES=dep rather than MODULES=most. In other words, only modules that are actually needed on your system will be included in the ramdisk.
• /etc/default/rcS will be configured on supported NAS devices to contain FSCKFIX=y, so e2fsck will attempt to repair the filesystem without prompting the user for input. This is useful on NAS devices since they are usually headless.

Finally, the armel port is recommended for new installations now. Debian lenny has two different and incompatible ARM ports: the old ABI port (arm) and the new EABI port (armel). Debian lenny is the last release with support for the arm port and future releases will only support the armel port. It's therefore recommended to use armel for new installations of lenny.

when not being distracted by other uses of the system, i've managed to spend some more time on packaging some more stuff that's useful on a debian ps3. namely:

• ps3-utils: necessary utilities (boot-game-os, ps3-video-mode, etc)
• speutils: threading and message passing library
• spu-medialib: spu-accellerated audio/video library
• xserver-xorg-video-spu: spu-accellerated framebuffer driver for xorg

the last of which i think will be of the most interest to some folks, as it provides an spu-based xvideo extension, which brings back the possibility of playing HD videos etc on the ps3. now if you're interested in checking out these packages, read on, starting with this: !=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!= ZOMG WARNING!!!1!!ONE!! THESE ARE EXPERIMENTAL BLEEDING EDGE PACKAGES. I MAKE NO GUARANTEE WHETHER THESE PACKAGES ARE PROPERLY BUILT, WILL INSTALL, WILL WORK, WILL NOT DESTROY YOUR SYSTEM, WILL NOT CRAWL OUT OF YOUR SYSTEM AND MAKE LONG DISTANCE PHONE CALLS WHILE EATING THAT SNACK YOU WERE SAVING IN THE FRIDGE, ETC. !=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!= okay, so now that we've disposed with that formality, i'm glad if you're interested and still here so... where were we? oh yes. put this in your sources.list:

deb http://people.debian.org/~seanius/ps3-experimental-packages sid main

source packages are also available if you want to poke around or backport the packages to etch or ubuntu or something else wierd like that:

deb-src http://people.debian.org/~seanius/ps3-experimental-packages sid main

now, if you have a properly configured system, you should get a warning:

Reading package lists... Done
W: GPG error: http://people.debian.org sid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY CA78CB3E6E76D81D
W: You may want to run apt-get update to correct these problems

but i promise this key is valid, and mine. but hey, you don't have to take my word for it

sudo apt-get install debian-keyring
gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --export --armor CA78CB3E6E76D81D   sudo apt-key add -

then you can install the packages... assuming you want the xorg video driver:

sudo apt-get install xserver-xorg-video-spu

and update the appropriate Device entry in your xorg.conf, so that the normal fbdev is commented out and instead you use the spufbdev driver. example:

Section "Device"
        Identifier      "Generic Video Card"
        Driver          "spufbdev"
        Option "ShadowFB" "false"
EndSection

and then

sudo /etc/init.d/gdm restart

(or the equivalent if you're using something else). that's it! more packages may trickle in here as well, at least until and they find their way into debian proper. i'm also in contact with the upstream authors of this stuff, and they're generally very responsive, so let me know if you have any problems.

I wrote to a site owner last week and I thought I was writing to a webmaster. The site owner complained about some of the jargon and, while explaining who I thought I was writing for, I explained some of it because I think more website owners might benefit from these three explanations:- “Expat-like terms” - made available in a way that is freely sharable, modifiable and redistributable, similar to the Expat software package, whose terms are published at http://www.jclark.com/xml/copying.txt - this is often used as a clear, simple example for encouraging wide distribution of electronic resources (software). “clandestine Google Analytics” - Google Analytics is a service from Google, Inc for tracking users through a website in various ways. I believe the Data Protection Act means that English websites should obtain informed consent from users by publishing a Privacy Policy on their site which discloses what the GA service will be used for and linking through to GA’s own Privacy Policy. Some websites attempt to run Google Analytics on users’ computers without explaining why and without any Privacy Policy. That is what I mean by “clandestine”. “valid xhtml” - validating against the eXtensible HyperText Markup Language standards published by the World Wide Web Consortium (W3C) - the underlying language of the web. There is a test service provided at http://validator.w3.org/ and passing it is a key stepping stone towards making an accessible website. There’s not really such a thing as “invalid xhtml” - if it doesn’t pass validation, it’s not xhtml. So I guess I’m guilty of using a tautology sometimes - sorry about that. Is it worthwhile knowing those three phrases? Are there other key technical phrases which you think site owners should know?

It’s close! In the township where we live, Barack Obama defeated John McCain by 15 votes! I guess I should mention that the victory margin was 166 to 151. So it’s not like it was 15 votes out of millions. In all, 333 people in our township cast ballots, or about a third of the total population of our township. Just to give you a sense of scale, there are an average of 29 people per square mile out here. And the nutty jail expansion was defeated 3:1. Our county commissioners will just have to figure out some other way to house the county’s prison population (around six inmates) for awhile longer.

OCaml Batteries alpha 2: Debian packages Out of popular request (wow, people on #ocaml@freenode are very excited about the Batteries thingy, good!), I've prepared Debian packages for OCaml Batteries Included, version alpha 2 (which does include the support for transparent gzip-ed channels). Packaging shameless plug: packaging this version has been a nice showcase for TopGit as now I've a couple of inter-dependent branches. TopGit has indeed rocked my world, yay. (Well, I also have to admit to myself that this tiny bit of TopGit mention wont assolve me from the need to advertiseblog about TopGit, ... eventually!) Packages have been uploaded to experimental. As usually I build/upload for amd64, but experimental in Debian is auto-built so eventually the will show up also for other architectures, of course including i386. If you want to take them directly from experimental you have to add this line to your /etc/apt/sources.list:

    deb http://ftp.de.debian.org/debian/ experimental main non-free contrib

and then install requesting explicitly experimental (for some time now, experimental is treated specially, and it won't be used by APT unless explicitly asked for):

    apt-get install -t experimental ocaml-batteries-included

The Debian version (roughly) corresponding to alpha 2 is 0.20081112+gitBB342A7-1. Alternatively, you can grab the packages from my people.d.o space. Since people were interested I've made available both amd64 and i386 builds there.