I was invited to talk about Free Software at yesterday's FLISOL. Yesterday? Aren't FLISOLs organized on Saturday? Well, not this one, for various reasons which I won't quote here. And no, I am not a supporter of the installfests idea, but I went gladly to talk about what is Free Software all about - The philosophy behind Free Software. Besides, the talk was at FES Iztacala, where I worked for four happy years, 1999-2003. I have not been often to Iztacala since 2003 (probably I have visited only three or four times), partly because of the distance (~25Km from home in a straight line, but the city's Northern part is quite poorly communicated). The last time I was there, last October, I went by bike, just to test my endurance and... because I could. Yesterday, I also did, not to be outdone by my fellow Debianers Christian and Dirk. Think they are so cool because they can run for 43Km? Well, I had my 55Km yesterday, and I was not even in a competition! (yes, yes, running and biking is not the same. So sue me. I just didn't want to stand still and let them walk away with all of the fun!) I took slightly different routes (my route to get there on Nokia Sportstracker and OpenStreetMap trace, my route back on Nokia Sportstracker and OpenStreetMap trace), crossing diagonally Azcapotzalco, a region of the city (delegaci n) I hardly know... The Sourthern of it seems like a continuation of Tacuba to the North, small and not-very-well-communicated prior villages engulfed by our hungry, huge city. The Northern half is a mostly industrial area, with very sparse population, lots of trucks, and streets that are not in the best shape. You can end up feeling lonely in those regions, and I am glad not to have crossed back by night. And the trip back was interesting as well... Mexico City is home to many more bikers you would expect given its size, and it is very common to find other people doing nice long stretches. In this case, I started cycling quite close to another guy in a white bike more or less when I got to Calzada Camarones. Possibly we had passed each other over and over until after Tlatelolco, arriving to Guerrero, where I approached him at a stoplight:
Hi! Where to?
Near Vocacional 7, Iztapalapa!
Nice! I'm just going to Copilco Every now and then we crossed each other... Turns out he does this ~30Km commute daily between Iztapalapa and Azcapotzalco. Quite admirable, to be honest. I also crossed my road with Sergio Mendoza, fellow Debianer (and co-administrator of our Mexican mirror) around Centro M dico (about 7Km north from my destination), whom I had only seen before around the University. Nice surprise. And yes, getting to know the city by bike is the best way to go! Back to the conference... my first thought when I was invited was to present Qu es el Software Libre?, a talk I have given over and over since... 2002 (although, yes, with updates). I must say it's one of the best structured talks I have prepared and has almost always been very successful - But give the same talk based on the same script over and over (AFAICT, around 20 times), and you will be fed up with it. And yes, yesterday I didn't take my laptop along, and didn't put my presentation on a USB stick - I took a pen and some paper, and during the presentation prior to mine, wrote some points to go over. And yes, it was a refreshing change. The talk was as successful as expected, and it's much more refreshing to talk about the same topics bot on a different way, and without being constrained to a predefined script. I know that organizing formally your ideas makes sure you don't miss out important points and that the audience is sometimes encouraged to pay attention by having some bullet points to look at - But on the other hand, it is much easier to follow your audience's interest if you are not bound by the script. And the few times I've spoken that way, it has felt refreshing and nice.

I was contacted today via private e-mail by Rafal Czlonka, as the hackergotchi I use (at least) in Planet Debian is wrongly rendreed by his WebKit-based web browser, Arora. So, in order to get more people to notice the bug if it exists: This is my hackergotchi (copied from Planet Debian, so I can update it and this post still shows a valid one): And this is the sample he sent me on how it is rendered by Arora - Pay no attention to the horizontal lines (those are taken from the background where it is rendered): So, is the first image correctly rendered? (I usually have my skin in a pinkish tone, and I was wearing a blue shirt). But, yes, that makes understanding the PNG encoding a bit more interesting. I guess PNG defines hues (as neither of those colors is completely uniform, they both vary slightly depending on the section of the picture)... And for some reason, my hackergotchi (generated by the Gimp) confuses the renderer and makes it switch the hue areas? (Note that I am tempted to use the corrected version as my hackergotchi.. It looks more interesting!) [update] I could not resist it... and have uploaded my blue hackergotchi to planet.debian.org - Yes, I'm a smurf now, it's no longer a rendering error.

dput + mini-dinstall to ease people.d.o uploads As DDs we often want to offer unofficial packages, but still preserving a bit of "authoritativeness". A widespread solution is to upload somewhere under http://people.debian.org/~LOGIN as an APT repository. I've been using that solution too since ... ever, but I've never been happy about how to advertise the packages, probably just because I've never liked dpkg-scan packages,sources and hackish scripts built on top of them. My goal, as simple as it can be, is to work as I do to prepare "real" packages to be uploaded to the Debian archive, and just upload to people.d.o as the final step. Thanks to DSA which satisfied a request of mine by installing a while ago mini-dinstall on ravel, today I've finally set up a work-flow that enabled me to reach my goal. This post is a quick howto to implement that setup. If you have suggestions about where (wiki.d.o? devref?) to paste these info so that other DDs can more easily find them in the future, please let me know, via comments or mailing me. Step 1: configure mini-dinstall on people.debian.org On people.debian.org, create a ~/.mini-dinstall.conf file containing something like the following:

    [DEFAULT]
    mail_to = zack
    incoming_permissions = 0750
    architectures = all, i386, amd64
    archive_style = flat
    dynamic_reindex = 1
    archivedir = /home/zack/public_html/debian/
    generate_release = 1
    release_origin = Zack
    release_label = Zack
    release_description = Unofficial Debian packages maintained by Stefano Zacchiroli
    [zack-unstable]
    release_suite = zack-unstable

Highlights of that conf:

• "flat" archive style means "all in one dir", a more structured alternative is "simple-subdir"
• you request to generate a Release file, which is needed for the secure APT machinery; various fields of that file are specified by the release_* options
• you call your suite "zack-unstable" (well, I do ). That suite must match the distribution in your debian/changelog entries. In theory you can use legacy names such as "unstable", but as we are humans and we make mistakes, better to use invalid suite names that will be refused by dak if you upload to the wrong queue

The resulting repository will be accessible using the following /etc/apt/sources.list lines:

    deb http://people.debian.org/~zack/debian zack-unstable/
    deb-src http://people.debian.org/~zack/debian zack-unstable/

Step 2: configure dput The default incoming dir of mini-dinstall, relative to the configured archivedir, is mini-dinstall/incoming. The following entry for your ~/.dput.cf (on the machine you upload from) will therefore setup your dput for uploads:

    [people.debian.org]
    fqdn = people.debian.org
    method = scp
    login = *
    incoming = /home/zack/public_html/debian/mini-dinstall/incoming
    post_upload_command = ssh people.debian.org mini-dinstall -b

The only interesting detail here is the post upload command, which will run a "pulse" of mini-dinstall on people.d.o just after the upload, to process the uploaded file. Alternatively, you can leave mini-dinstall running on people.d.o, but I consider it unnecessary (because usually you are the only one able to upload to your home dir), unelegant, and complicated (because you then need to verify mini-dinstall is running). Step 3: enjoy (i.e., upload) Now you can prepare your packages as you always do (which means using cowbuilder!) and, when you are done with your foo_1.0-1_amd64.changes, upload it doing:

    $ dput people.debian.org foo_1.0-1_amd64.changes

Signing the Release file The above setup does not sign Release files, which means your APT users will receive complaints from the secure APT machinery. To fix that you must sign the Release file with some key and distribute the key to your users to be processed by apt-key add. You have a couple of ways to sign the release file automatically:

1. (/me doesn't like this) use a GPG key created for the occasion, store that key (including the private part) on people.d.o, and use the mini-dinstall contrib script sign-release.sh by adding something like the following to your mini-dinstall.conf:

     release_signscript = ~/bin/sign-release.sh
   
   

2. (/me likes this) use some script to sign the Release file remotely and send the resulting deatched signature back to people.d.o just after the mini-dinstall pulse; that way you can sign with your own private key, which will be reasonably felt as more trustworthy, being part of the Debian keyring. To achieve that, the most elegant way would be to fix debsign wishlist #465240 (volunteers? ). As I'm lazy, I'm using my own sign-remote script, which is a bit more generic. Remote signing should be attached to dput upload hook as well. All in all, here is my actual ~/.dput.cf stanza:

     [people.debian.org]
     fqdn = people.debian.org
     method = scp
     login = *
     incoming = /home/zack/public_html/debian/mini-dinstall/incoming
     post_upload_command = ssh people.debian.org "mini-dinstall --batch" && sign-remote people.debian.org:~/public_html/debian/zack-unstable/Release
   
   

Enjoy! Update: do both mini-dinstall run and signing in post_upload_command, following gregoa's suggestion via comment

I've been talking serial consoles with a couple of the other guys at work: how nice they are to have for machines in the datacenter, how annoying it is that vPro serial-over-LAN doesn't seem to be robust (yet?), and how serial access concentrators are lung-and-kidney expensive (especially when you've got 50-some racks to outfit). This discussion, combined with my ongoing embedded-hardware-fascination lust for a SheevaPlug appears to have spurred my brain into coming up with a Brilliant Idea: tie a SheevaPlug to a pile of USB to serial adapters and use that as your per-rack serial concentrator. Imagine: faffenheimer, a dedicated server you manage for a customer, and located in rack 27 of your DC, has just crashed, and you'd like to know WTF has happened rather than just blindly reboot, but you're in the office 15 minutes away from the DC floor, and the customer's going to want that machine back up and running pretty quickly.

workstation:~/porn$ ssh rack27.serial
rack27:~$ sconsole faffenheimer
[screen session attached]
[minicom running, shows the horror of a kernel crash dump]
[oh look at that, kernel bug]
^A ESC
[pgup pgup]
[enter]
[pgdn pgdn]
[enter]
^A >/tmp/faffenheimer-crash-dump
^A d
rack27:~$ exit
workstation:~/porn$ scp rack27.serial:/tmp/faffenheimer-crash-dump ~
workstation:~/porn$ powercycle rack27 faffenheimer

Shiny! We got a crash dump in a minute or so (rather than having to take phonecam photos of KVM screens in the DC), never had to leave our comfy seat, and the machine's on it's way back up. We're now free to pursue diagnostic activities on that crash dump at our leisure. 10 minutes later, the downtime for faffenheimer that was automatically set when we ran powercycle runs out and Nagios sends us threatening messages. Hmm, something's gone wrong here. Back into the console...

workstation:~/porn$ ssh rack27.serial
rack27:~$ sconsole faffenheimer
[screen session attached]
[Boot is hung waiting for root password after initrd has bombed]
[Type root password]
[Oh look, the root MD appears to have come asunder]
[clickety-click... fixee fixee]
[reboot]

The more I think about this, the more I reckon I'm onto a bona fide winner. The sheevaplug is a powerful ARM-based system with USB/ethernet/SD ports that is packaged literally in it's own power supply wall wart -- it's a plastic box with power plug prongs poking out the side. That's all there is to it. The USB to serial adapter things are likely to be a bit more of a pain, but I've played with enough of them by now to not be too scared. So, you plug the Sheeva into a power socket, plug an Ethernet cable and USB hub into the Sheeva, configure things a bit so that the system knows which serial adapter maps to which machine, and you're away. Oh, and the best bit: the Sheeva apparently draws as little as 2W when idle. A whole datacentre's worth of serial goodness for about a server's worth of power. The cost per rack should be somewhere below AU$250, especially in bulk. Let's see if I can convince work to spring for a Sheeva, a USB hub, and a half dozen or so USB to serial adapters to test this whole thing out. Given that the whole thing looks like it'd cost less than AU$250 (plus my R&D time), I can't imagine it'll be too hard a sell to at least give it a go. Watch this space...

I am sure many have seen this video pirates. drugs. gay marriage and I think it speaks for itself. But I have to say, this video caught be off guard early this morning when I am first exposed to the day s viral videos, memes, and other savory and unsavory delights. Though I have been consuming and digesting this stuff for awhile now, I am still amazed by the craziness, creativity, outrageousness (often offense) that circulates every day, without fail, on the internets. Most of the stuff, even if pretty low brow can be said to be artistic in one classical sense of art: l art pour l art , with the aesthetics being focused on some combination of shock, irony, and humor. But how about the political activists? They are not dipping into this genre enough and it s high time they use start using these tactics/viral videos to shock/shame their opponents, using the sugar coating of humor and raw audacity to spread their message.

As you might know, as part of the Haskell Hackathon 5 in Utrecht, the second darcs hacking sprint took place. Thanks to generous donations to the Darcs project, I have been able to attend. I took the overnight train from Prague on Thursday evening interestingly, we managed to accumulate about 90 minute delay in Germany, but by skipping some detours (throwing passangers out at more convenient ones) we managed to get to Utrecht on time. (Wow.) After a while of confusion, we managed to get our strippencards and find the right bus and get to the UU campus (at that time, we have already met with Thorkil, whose train was combined with mine in the middle of the night somewhere in Germany). The first thing there was to get our name tags and a round of introductions followed I was fairly surprising by (large) number of darcs hackers among the general Haskell population present at the Hackathon. Overall during the sprint, various topics have been discussed ranging from theory issues to actual implementation bits in current darcs. Some roadmapping has taken place. It was great to see all those darcs people together. More interestingly, it sort of convinced me that actually something is going on with darcs. Although most people seem to be pretty short on time, at least I got the impression that people have actual intent to keep advancing darcs, in one form or other. Also, there s been some preliminary plotting on what is the life expectancy of darcs 2, roughly. My current plan is to use darcs 2 as an implementation vehicle, because people use it in real life, for carrying out the actual work on hashed-storage. That way, we should be able to de-couple low-level repository and file access code from darcs itself, also meaning it should be reasonably easy to plug it into camp later (or maybe it turns out we instead want to remodel darcs so that we can plug camp-core in time should tell). We have done some bits of work on darcsit (gitit) migration of wiki.darcs.net, although it hasn t been so much of a smooth sailing. I have even tried to set up gitit on one of my machines, but cabal-installed happstack went eventually crashing and burning instead of doing anything useful. I m stuck on that front, hoping that Eric and Gwern can get test.darcs.net running within reasonable resource usage. I have thrown a chat with various people about hashed storage and I have explained various problems of the current darcs hashed repositories and how hashed storage addresses those. Also, I have talked with Benedikt about his filecache and we entertained some initial thoughts on how those two play together. We have also spent a while at a whiteboard with Eric discussing what needs to be fixed in sources handling: the file that lives under _darcs/prefs/sources and that keeps track of related branches of a given repository. The catch is, that when inappropriate entries get into that file, bad things can happen: darcs repeatedly waiting for a nonexistent remote machine to answer, or triggering automount a few thousand times by probing just the wrong directory. These need to be remedied and we came up with a reasonable action plan. Hope to have this in 2.3, as it should be moderately hard to fix and it has potential to sweep a fair amount of silly and obscure performance bugs. All in all, it seems to me that the important part of the sprint this time was talking to people and thinking about things. Still, I did manage to get some hashed-storage coding done (but mostly cleaning up and documenting work) during the sprint. I expect the fruit of the sprint discussions to take shape in form of code improvements in following months.

For a very long time, I use mutt with emacsclient as configured editor and a single GNU Emacs instance started from either .screenrc or .Xsession, depending on the system. And I m very used to switching the virtual desktop or the screen window after starting a mail in mutt. Since Debian 5.0 Lenny and Emacs 22, Emacs automatically grabs the focus and switches to the right virtual desktop. So after telling mutt recipient and subject of a new e-mail, it invokes emacsclient and immediately the focus has moved to the running Emacs instance. Because I was used to switch one virtual desktop to the right at that point, I often found my self two desktops to the right until I got used to it. :-) I usually hate applications which grab the focus without being asked. But in this case I basically asked for it. And there s no delay like with starting up an application which has to read in some database first think of Liferea or Rhythmbox which take many seconds to minutes to start up, even on my 2.2 GHz dual core ThinkPad. In the meanwhile I got so used to that automatic desktop switch that I forget to switch the screen window in the second scenario where I use this combination: My screen doesn t automatically switch to the Emacs window (window 1) after I told mutt recepient and subject in window 2. Knowing that screen is quite scriptable, I found out that only a very small change is needed to my mutt configuration to get that desktop feature to my everyday screen session. I simply replaced the editor setting in my .muttrc with the following line:

set editor="screen -X select 1;emacsclient"

Now mutt tells screen to switch to window 1 (where Emacs is running) and then tells Emacs to open the appropriate file to edit my new mail. Update Friday, 2009-04-24, 18:22 Even though Zack surely is right with his comment about the multi-terminal feature of the upcoming GNU Emacs 23, I still have Etch (and therefore GNU Emacs 21) on the server where I have my screen session. So the next step was to switch back to the mutt window (window 2) after I m finished with editing the mail. Since mutt gives the the file to edit as argument to the contents of $editor, simply adding ;screen -X select 2 at the end of $editor doesn t suffice. So I wrote a small shell script (named ~/.mutt/editor.sh) as wrapper which calls all the commands and passes the parameters to the right command:

#!/bin/sh
screen -X select 1
emacsclient -a ~/.mutt/alteditor.sh "$@"
screen -X select 2

Of course, $editor is now set to that script:

set editor="/home/abe/.mutt/editor.sh"

Emacsclient of GNU Emacs 21 already supports the -a option to call another editor in case of not being able to connect to a running Emacs instance. Since I don t want to switch to another screen window in that case, I wrote a second shell script (named ~/.mutt/alteditor.sh) which switches back to the mutt window and then calls GNU Zile, my preferred low-end emacs clone:

#!/bin/sh
screen -X select 2
zile "$@"
screen -X select 1

I love it!

---

This year it looks like Google Summer of Code will bring me much more work than it has brought in past years. Currently I have four students on the track:

• Mobile phones synchronisation for OpenSUSE. This will hopefully bring improvements to both Gammu and Conduit and the outcome should be working solution for at least some phones.
• Import improvements for phpMyAdmin. I would say this has been the best GSoC proposal I have seen so far, so let's see how it will progress.
• Changes tracking in phpMyAdmin. At the end we do have two projects on similar topic, but I want to push one of students more to synchronisation direction.

Let's see what will this bring to participating projects, but I hope all projects will end up at least with partial success and will bring great additions to free software.

At work I've been promoting the use of pkg-config and modules to solve the problems of avoiding hard-coded paths and an environment where we've multiple compilers. In summary, "module load intel-cc" to load the intel compiler, "module load netcdf-intel" to, which among other things appends /ichec/packages/netcdf/4.0-intel/pkgconfig to $PKG_CONFIG_PATH, and then:

NCDF_INCS :=  pkg-config netcdf --cflags 
NCDF_LIBS :=  pkg-config netcdf --libs 

in the application code. Replace "intel-cc" and "netcdf-intel" with "gcc" and "netcdf-gcc", and it builds with gcc. This would work better if upstream supplied .pc files, which means the next stage in world domination is to send patches to do just that. But it's not that easy, apparently. netcdf (for example) supplies two libraries, libnetcdf.so and libnetcff.so, with the second including code only needed for Fortran. So, for gcc I have the following netcdf file:

prefix=/ichec/packages/netcdf/4.0-gcc
exec_prefix=$ prefix 
libdir=$ prefix /lib
includedir=$ prefix /include
Name: netcdf
Description: netCDF libraries, include files and development tools (gcc version)
Version: 4.0
Libs: -L$ libdir  -Wl,--as-needed -lnetcdf   -lnetcdff 
Cflags: -I$ includedir 

While for Intel I have:

prefix=/ichec/packages/netcdf/4.0-intel
# Add fortran libs 
forlibs=/ichec/packages/intel/fce/11.0.081/lib/intel64
exec_prefix=$ prefix 
libdir=$ prefix /lib
includedir=$ prefix /include
Name: netcdf
Description: netCDF libraries, include files and development tools
Version: 4.0
Libs: -L$ libdir  -lnetcdf -L$ forlibs   -lnetcdff -lifcore
Cflags: -I$ includedir 

The main problem is that --as-needed is not understood by non GNU-ld linkers, and must be conditionally removed somehow. Any ideas ? (There is a second wrinkle of needing to add additional libraries for Intel Fortran here, but I'm sure I can remove that with the addition of more .pc files.). A second issue is that --as-needed can break otherwise working pkg-config usages. Thanks to galtgendo at PhP Bugs for this example:

alastair@ailm:~$ cc -o testx  -Wl,--as-needed  pkg-config glib-2.0 --cflags  test.c  pkg-config glib-2.0 --libs 

works, but:

alastair@ailm:~$ cc -o testx  -Wl,--as-needed  pkg-config glib-2.0 --cflags    pkg-config glib-2.0 --libs  test.c
/tmp/ccsUEwtk.o: In function  main':
test.c:(.text+0x20): undefined reference to  g_print'
collect2: ld returned 1 exit status

The problem being that --as-needed removes libraries as unnecessary before the linker sees the test.o code. Tags programming, debian, work, pkg-config, shared-libs, lazyweb

Almost two years ago I blogged about a strange performance problem with SATA disks [1]. The problem was that certain regions of a disk gave poor linear read performance on some machines, but performed well on machines which appeared to be identical. I discovered what the problem was shortly after that but was prevented from disclosing the solution due to an SGI NDA. The fact that SGI now no longer exists as a separate company decreases my obligations under the NDA. The fact that the sysadmins of the University of Toronto published all the most important data entirely removes my obligations in this regard [2]. In their Wiki they write after SGI installed rubber grommits around the 5 or 6 tiny fans in the xe210 nodes, the read and write plots now look like and then some graphs showing good disk performance appear. The problem was that a certain brand and model of disk was particularly sensitive to vibrations. When that model of disk was installed in some machines then the vibrations would interfere with disk reads. It seems that there was some sort of harmonic frequency between the vibration of the disk and that of the cooling fans which explains why some sections of the disk were read slowly and some gave normal performance (my previous post has the graphs which show a pattern). Some other servers of the same make and model didn t have that problem, so it seemed that some slight manufacturing differences in the machines determined whether the vibration would affect the disk performance. One thing that I ve been meaning to do is to test the performance of disks while being vibrated. I was thinking of getting a large bass speaker, a powerful amplifier, and using the sound hardware in a PC to produce a range of frequencies. Then having the hard disk securely attached to a piece of plywood which would be in front of the speaker. But as I haven t had time to do this over the last couple of years it seems unlikely that I will do it any time soon. Hopefully this blog post will inspire someone to do such tests. One thing to note if you want to do this is that it s quite likely to damage the speaker, powerful bass sounds that are sustained can melt parts of the coil in a speaker. So buy a speaker second-hand. If someone in my region (Melbourne) wants to try this then I can donate some old IDE disks. I can offer advice on how to run the tests for anyone who is interested. Also it s worth considering that systems which make less noise might deliver better performance.

• [1] http://etbe.coker.com.au/2007/06/27/strange-sata-disk-performance/


• [2] http://wiki.cita.utoronto.ca/mediawiki/index.php/Xe

From the exoplanets mailing list:

A 1.9 Earth mass exoplanet (period 3 days)
has been detected around Gliese 581 (Mayor et al).
See
http://exoplanet.eu/planet.php?p1=Gl+581&p2=d
It is the lightest planet detected up to date around a main sequence star.
In addition, the planet Gliese 581 d has a revised period of 67 days,
bringing it in the habitable zone of the parent star.
Jean Schneider

Gliese 581d is now more solidly inside the habitable zone; it was considered before to be on the outer edge of the habitable zone (this work moves its believed semi-major axis from 0.25 AU to 0.22 AU). Gliese 581d was a maybe for habitability (see this Centauri dreams article for example), depending on cloud cover, etc. Now its definitely in. The new Gl 581e is beyond the classical habitable zone. These planets are quite close in: Rory Barnes and colleagues at Lunar and Planetary Laboratory in Arizona did some good work on the habitability of Gliese 581 c (paper online) and concluded that it would be tidally heated to such a degree it was probably never habitable. Such tidal heating might make Gl 581e habitable; time to run the model again. Correction: On reading the ESO Press release and paper (via) it appears that Gl 581e is inside the orbit of Gl 581b, and too close to the star to be habitable. To date, planets have been labelled b, c, d .. as they are discovered, and they've been discovered shortest-period first, so 'b' also meant closest to the star. Now Gl 581e is closest to the star, with a period of 3 days. Tags exoplanets, tides, astronomy, habitability

Doesn t this class look great??

Department of History Workshop MEDIA AND COMMUNICATION IN THE MIDDLE AGES Professor Brigitte M. Bedos-Rezak Medieval circumstances presented multiple challenges to media, mobility, and communication. Cultivators were bound to the land and monks to their monasteries; pilgrims traveled to holy places, crusaders and warriors invaded and then settled foreign lands, rulers and nobles were frequently itinerant. Literacy was largely limited to Latin, and possessed principally by churchmen and nuns so the transmission of ideas occurred mainly through the spoken vernacular word, and by means of gestures, images, and the manipulation of symbolic objects (thus, for instance, the relics of saints were carried to distant lands to collect alms, to recover possessions appropriated by nobles, or to aid in battle). While seas, rivers, ports, networks of roads provided with rest houses, ferries and bridges, were generally available, routes and means of transportation selected differed markedly according to the traveler s status and the journey s purpose. Christianity stimulated pilgrimages, missions to convert the heathen, and crusades. Marriage took brides to foreign courts where they served as cultural ambassadors. Medieval kings and great nobles were continually on the road, changing their abode every two or three days. Lesser officials and messengers traveled on government business. Knights sought out tourneys and distant wars to advance their fortunes and reputations. Merchants and carriers transported goods to regional fairs, and engaged in international trade. Minstrels, jongleurs, and troubadours traveled to gain patronage and to extend their repertoire, spreading news and influencing the reputations of warriors, heroes, and kings. Students too journeyed extensively from place to place in order to sit at the feet of famous masters; some wandering scholars came to be known as Goliards. Artists were invited to decorate manuscripts and architects to erect buildings.
The pursuit of favorable opinion became an essential feature in the process of state-building during the Middle Ages. Those who challenged traditional norms also came to rely on the efficiency of communicative systems to expand their ranks with adherents. Through the use of propaganda, medieval society experimented with such forms and methods of communication as symbols, stereotypes, and slogans, thus elaborating features of communication which, however modified, are still in use today.

Raphael Bauduin emailed me to say that he s organising an event for Profoss: (28 april in Brussels) will take a look at legal aspects of the use of FOSS in professional environments. http://www.profoss.eu/events It will bring interesting information for most ICT professionals, even for those specialised in FOSS, but if this is not for you, it might be of interest to people around you (your boss or colleagues), so don t hesitate to spread the information around you. There is problem with the current website: it requires javascript. An updated site without that problem will appear very soon . If you go to the event, I d love to hear how it goes - please leave a comment on this article!

TED published an interesting interview with Shai Agassi about electric cars [1]. One idea that I hadn t heard before is that of moving car batteries between regions as they lose capacity. An old battery for an electric car that can only handle short journeys may be useful in a region where journeys are typically short. On a similar note I expect that in a few decades the less prosperous countries will import old electric vehicles and fit them with 4 or more batteries. Last time I checked the Prius battery pack weighed about 120Kg, so the car would be usable with 4 battery packs if driven at low speeds. Shai Agassi also gave a TED talk on this topic [2]. The real solution for the problem of providing convenient and affordable electric vehicles is to start by recharging the batteries whenever the vehicle is parked (at the office, shopping center, home, etc). Then on the rare occasions when the car is being driven for longer distances and the battery gets flat it can be swapped for a charged battery. They have apparently designed a robot for changing car batteries, so changing the battery would be like driving through a car-wash. He describes this as an economic model that decouples the expensive battery from the car, so you pay for the use of the battery not the ownership - just as with a petrol car you pay for the petrol you use not for a portion of the ownership of an oil well. He also pointed out that cars produce 25% of the world s CO2 emissions, so his plan for all electric cars everywhere seems to be an essential part of solving the environmental problems. He then compared this to the UK parliamentary discussion on ending slavery, at the time slaves provided 25% of the energy used by the UK. After a month of discussion the decision was made to make the moral choice and end slavery regardless of the cost.

• http://blog.ted.com/2009/04/from_software_e.php


• http://www.ted.com/index.php/talks/shai_agassi_on_electric_cars.html

Today was the season opener for Tripoli Colorado at their launch site on the buffalo ranch near Hartsel, Colorado. After huge snowfalls along the front range of the mountains in the last few days, we were a little tentative about going, but it turned out to be nearly perfect flying conditions! There was apparently much less snow this week on the high plains west of the front range, and by this morning the snow had almost entirely disappeared, the skies were clear and blue, and the winds were calm except for a few gusty bursts in the afternoon. This launch site is really something special, at 8800 feet above mean sea level, in the middle of a huge area of wide-open short grass prairie. We love flying there, and today the drive to and from the launch site through the snow-covered Colorado Rockies was just beautiful! Son Robert and I flew three rockets today, including his LOC/Precision Lil Nuke with added payload section on an Aerotech G54W-M reload, and our Polecat Aerospace 5.5 inch Goblin kit on one of the relatively new Aerotech I245G-M "Mojave Green" green-flame reloads. But by far the highlight of the day was flying my Giant Leap Vertical Assault on a Cesaroni J335 red-flame reload... with serial number 1 of TeleMetrum on board collecting our first-ever flight data! From the ground, it looked like a textbook perfect dual-deploy flight, with a small drogue chute out at apogee around 4000 feet above ground, and the main chute deploying at 700 feet above ground for a beautiful, soft landing only a couple minutes walk from the launch rail. The ejection events were controlled by a PerfectFlite MiniAlt/WD. The data recovered from it shows a big negative spike in the altitude right at apogee, coincident with firing of the apogee deployment charge. I have to assume this means the aft bulkhead on the avionics bay in the reconstructed coupler section isn't sealing well, and some pressure from the apogee deployment charge leaked in to the avionics bay "fooling" the altimeter into thinking the altitude was lower for a sample or two. Clearly, that needs to get fixed before that airframe flies again. Further evidence that we had a mighty kick from the apogee ejection charge was discovered when we went to clean the motor casing. The Cesaroni reloads are packaged in a plastic liner tube that slides into the reusable aluminum case. When we pulled the spent reload out of the case, it was significantly shorter than when it was loaded, suggesting that the ejection charge forced the forward closure on the reload backwards compressing the heat-softened plastic. This could be evidence that the reconstructed coupler was slow to separate from the booster airframe due to excessive friction? The flight data recovered from the TeleMetrum board looks great until apogee, when the data collection stopped. Since I flew firmware that was compiled and flashed on the flight line from Keith's latest git commit as of this morning, it's entirely possible that there was a software bug that caused data collection to terminate at apogee. We'll investigate that. But I personally think what actually happened is that we experienced a temporary short in the power supply at the time the apogee ejection charge fired. On extraction of the electronics sled from the avionics bay this evening, I noticed that one of the mounting screws has gone missing. If it wasn't snug enough, and vibrated loose during flight, it could have been torn loose at the time of the ejection event and shorted something as it rattled around in the avionics bay. The screw is now just missing, but may have fallen out when we were extracting data on the flight line just after the flight without being noticed at the time. So I'm not inclined to worry much about this, at least until we can get some more flight data! Keith post-processed the raw flight data and presented me with a plot showing two traces, acceleration and barometric altitude. The data from the accelerometer closely matches the published data for the motor we flew, which is a really cool result, and my 10-year-old son enjoyed figuring out why the rocket showed negative acceleration after the motor burn out but was still climbing. (See, there really is some science education hidden in the fun!) All in all, we had a great time, and it's totally cool to have data from a first flight of TeleMetrum! Can't wait to fly it again!

When Kubuntu switched to KDE4 as it s main desktop, I was disheartened. KDE 4, at the time was just, well, pretty unusable for me. It kept crashing, I couldn t do the things that I wanted to, and I spent more time fighting with KDE than I did actually doing work. After about a week, I d had enough, and I switched to Gnome. Now, a lot of people are probably going to respond to this with Gnome vs KDE flames, but let me explain my viewpoint on the whole Desktop Environment war I prefer KDE, but if a desktop will let me do the work I need to do without getting in my way and causing issues, then I can learn to use it. The above is possibly the reason that I can get along ok with Windows XP, but if I have to use Vista, I ll end up wanting to throw the machine out of the window. So, for possibly the last year or so (I m not too sure on the timescale!) I ve been using Gnome in Ubuntu, and I must say, I ve liked it. the fact that I can login, and instantly get access to my servers without having to type in my SSH key password (yes, insecure I know!), and that everything seems to integrate in a nice way, well.. it s been fun. But still, my heart lies with KDE, and I ve been flipping back to it to see how KDE4 is coming along on a regular basis. So far, I ve seen it gradually improving, and well, it looks damned sexy to be honest, but there were a few things that I felt it was missing. The ability to have multiple rows of apps on the task switcher was a big one for me. I generally have a lot of windows open, and I don t like the Grouping functionality. So when I get more than a few apps open, I could only see the icons. That s been fixed in KDE4.2, and it does it in a nicer way than Gnome does it (only switching to two rows once there are a certain amount of windows open. Next on the list is the whole password management thing. Gnome does a GREAT job at this. I login, and it unlocks the default keyring, sets up the SSH agent, adds my key, unlocking it from the keyring, and I don t have to do anything but login with my normal user and password (though I intend to switch that to biometric login once I can be bothered to setup the fingerprint reader). I ve fixed that little issue (well, for SSH) by setting up an autostart script using ksshaskpass to add my SSH key when I login. So far, KDE seems pretty usable for me now, but then, I m quite happy to plod along on my Laptop and try things out. I m feeling a bit lost with all the new functionality, and wishing that the Ubuntu Gnome Notifications (from pidgin, which I use as my IM client) didn t look so ugly in the new sexy KDE Desktop (in fact, if anyone knows a way to get pidgin to use the Jaunty style notifications in KDE, let me know, as they d fit in quite well under the new KDE look :D) - I d like to see some sort of common ground for notifications across the desktops, but who knows when that s going to happen! I ll also try using it at work, if I can use it there without it getting in the way, then I will happily switch back permanently, but that s the ultimate test. I m pretty sure that KDE 4 will be usable for me soon, and I ll let you know if that s now

/tmp/lab announces the second Hacker Space Festival
(Paris, 26-30 June 2009) Hacker Space Festival 2009 Call For Proposals HSF2009 In 2008, we organized HSF[1] on the spot, as an ad-hoc meeting for
hackerspaces-related networks, technical and artistic research emerging
from them and social questionning arising from them. This sudden
experiment proved to be a huge success, as much as on the
self-organizing level as on the participants and meetings quality, as
well as the emotionally-charged ambient, the kind of which you make
fond memories. The 2008 edition generated a strong emulation in France, from its
historical role as the first official hack meeting there, and in Europe
with the subsequent creation of the Hacker Space Brussels[2], the
rapprochement with The Fiber in Amsterdam and the hackerspaces.org[3]
network. Initiatives of hackerspace openings in Grenoble or Lille, or
the upcoming FrHack[4] conference show an actual enthusiasm in the
French hackers community that was doomed to the underground not so
long ago. We salute these initiatives and their diversity! Soon enough, we wanted to reiterate the HSF experience : however, it
was out of the question to institutionalize this temporary autonomous
zone, nor make it an ersatz of the previous edition, nor even to wrap
it into an elite or underground aura. On the opposite, we ardently
desire; and especially to explore further, in all directions some
lesser known domains (see below) et foster meeting and sharing around
experiences at the confluence of art, technology and politics. The world financial crisis, the decay of democracy in Europe, the
obscurantism, paranoia and lack of culture presiding over legislation
(Internet and Reaction Err Creation Law[5][6]) seem a fertile
environment for the sensible development of new (social ) life forms.
Quick! Let s rest for a few days in jubilation and ecstasy to take a
deep breathe of freedom under the indelicate smells of the medicine
factory nearby! For if the public space is shrinking to oblivion, where any side-step
becomes suspect, and that, from an early age (deviant behavior
detection in nursery school), where moving without a mobile phone
becomes suspect (hello you Julien Coupat[7], a French political
prisoner in France!), there s a domain that the Leviathan would have a
lot of trouble to contain, and for a reason: that of sensitivity. Even
the desperate attempts of the State to block the free and premonitory
expression of sense (hello you Demeure du Chaos![8]) cannot do anything
against a loud laughter or a knowing glance, a sensual kiss or an
explosion of colors. Sensitivity, we could say, is what is left to a human being when she
has nothing anymore, and differenciates her from the body corporate or
the institution, that are, in essence, devoid of it. Therefore, Art
definitely remains the public space to share between humans, and only
between us. And if it the last one to share, we propose to explore it
and take it over during the upcoming edition of the Hacker Space
Festival, from the 26th to 30th of June, 2009 at Vitry sur Seine[9]. ========================================================================
Keynote Speakers: Sergey Grim and Larry Fake with Eric Schmoudt
Groogle Summer of Crode, Survivor style
VLC, I vote against you because you really fucked up when ========================================================================
== W A N T E D ========================================================= Focus on solutions rather than problems. * The Final (Hardware) Frontier: Open FPGA Cores, Reverse Engineering
* Designer Religions and Creative Beliefs Systems
* WiFiDoors & WiFi System-on-Chip controllers firmware hacking,
infection & backdooring
* Telecom Core Network Equipment Reverse Engineering: MSC, STP,
Switches,
* Algebraic Attacks and Modern Cryptography Attacks
* Autonomous, Parasitic and Viral Drones
* Enhanced or Infected Reality Swarms
* Auto-Builders / Self-Fabrication
* Embedded OS breakins stories & recipes
* Actualization rather than mere concepts
* FPGA & ASIC hacking / backdooring
* Cloud+Privacy+Open Source: O Brave New World?
* Explosion-Proof clothing
* Radio Appz & Hackz: Mesh @ RF Layer 1-3
* Database & Privacy
* Problematic & Ethical Open Source/Content Licenses
* Institutional Relationships: Lobbying or Licking?
* Non Lethal Protection (anti-taser vests?)
* Survival in the Age of the Ministry of Immigration and National
Identity
* Mental asylum improvised visit
* Open Source Legacy Media(TM) Production Solutions (TV, Radio, Press,
DRM)
* Gas Sensors & Environmental Benchmarking
* Building Hackerspaces Without Money
* Milsatcomm hacking: Military satellites shots, broken birds in the
sky
* Other research topics on security and insecurity
* Academics and Hackers
* Organics and Fermentation
* Clean Food in Tainted Environment
* Low Impact Energy & Recycling
* Media Sandwich: layers of crap makes good food?
* Deconstructing Carla Sarkozy
* Knitting DIY Factory (jazzy, eh?)
* Signs of life among industrial wasteland
* Hallucinogenic & Computing: Can you Code on Acid?
* Mesh Networking (Wireless BattleMesh Royal!)
* Legal Sabotage: When Democracy Needs You And anything that does not fit. ========================================================================
== P R O P O S E ======================================================= Send you contributions to HSF2009-CFP@lists.tmplab.org + Type of the proposal: 1. conference (45min. presentation + 10min. for questions)
2. workshop / demo (30min. 2 heures)
3. installation / performance (music, plastic, sound, video) Lightning talks can be proposed and organized until the last moment,
according to available space and schedule, in the form of BarCamps or
Blitz Conferences. + Required Information: * Title of the presentation
* Type (see above)
* Language : French or English
* Name of speaker(s)
* Affiliation (organization / company)
* Short biography
* Abstract (5 to 10 lines)
* Topics / Keywords
* Includes a demo? YES NO
* Release during the festival? YES NO
* Internet connection required? YES NO + Acceptable Formats * Open Document
* PDF
* Plain Text
* RTF + Agenda * beginning of proposals : now
* end of proposals : 01 May 2009
* selection notification : 07 May 2009
* publication of program : 15 May 2009 + Evaluation criteria for proposals: 1. Innovating Topic
2. Open Technology
3. Demonstration / Live Act
4. DIY Reproducibility
5. Fun Potential The Programming Committee resembles that of last year
See : http://hackerspace.net/committee ========================================================================
== V E N U E =========================================================== /tmp/lab
6 Bis rue Leon Geffroy
94400 Vitry sur Seine
France http://hackerspace.net/directions ========================================================================
== P A R T I C I P A T E =============================================== Email : http://lists.tmplab.org/listinfo.cgi/hsf2009-talk-tmplab.org
CFPmail: HSF2009-CFP@lists.tmplab.org
IRC : irc://irc.freenode.net/frlab
Jabber : xmpp:hsf2009@space.cepheide.org?join
Wiki : http://hackerspace.net/hsf2009 ========================================================================
== L I N K S =========================================================== The CFP is available online at http://hackerspace.net/cfp [1] http://hackerspace.net/hsf2008
[2] http://hsb.wikidot.com/
[3] http://hackerspaces.org/
[4] http://www.frhack.org/
[5] http://jaimelesautistes.fr/
[6] http://laquadrature.net/
[7] http://fr.wikipedia.org/wiki/Julien_Coupat
[8] http://www.demeureduchaos.org/
[9] http://hackerspace.net/
Philippe Langlois
Email: philippelanglois@free.fr
PGP Key: 8DAEE244

Update: It turns out that the original PSB code is still on the moblin site - I just failed to notice that there's two pages of git repositories. I fail. Last update is from March 2008, though.

Edited again: An up-to-date version of the drm code is available as part of the Moblin kernel SRPM - repo.moblin.com isn't obviously linked off the Moblin website, but I should have thought to find and check their source repository.

By and large, working with Intel is a pleasure. In fact, a while ago I said so in a fairly obvious way. So it's a shame that the support for Poulsbo is still an absolute fucking mess with absolutely no obvious end in sight. Intel's Moblin group (the people who seem to be closest to having responsibility for providing any public Linux support for that hardware, though it's really not clear if they've got any more say in this than I do) have a kernel team that don't want or need a git tree despite having someone who's working on forward porting the driver to modern kernels - probably a job that requires more than one person given what a godawful fucking mess the last public release was, but it'd at least be nice to see what the current state is. Especially since you don't even seem to be able to get the last public release - moblin's git repositories have been rearranged and I can't find the psb-kmod one on their gitweb any more.

The most terribly depressing thing about this is that development is clearly still happening internally. Ubuntu is still being sent tarball releases by Intel, not that the code's getting any better judging by the type of diff involved. This is made even more entertaining by the bug in question being private, leaving no indication whatsoever about what bugs this code is meant to fix or why.

Closed development, random private tarball drops to partners without any public releases or changelogs, no indication of any upstream release, kernel developers entirely unrelated to the development of the driver trying to get code merged so people can actually use the hardware they bought? I'd expect this of some random far-east vendor with no experience in working with Linux, but not a company that's consistently one of the top ten contributors to the kernel and has frequently touted their level of support. There's no meaningful support for Poulsbo. There's just a thin cardboard cutout that's been carefully placed in front of a hole filled with users' hopes and money.

Seriously Intel. Sort it the fuck out.