Tonight at 6PM the channel 7 news will have a special report about the dangers of inhaling fumes while filling cars with petrol. I m blogging now because based on past experience I expect almost no technical content in the report and that the advert for the news show contains everything that is useful. The advert showed that they had used some film technique to show the fumes leaving the petrol tank while fuel is pumped in. It was obvious that the fumes were rising past the face of the man who was filling the tank. Not that this is really news, if you observe closely when fuel is pumped into a car you can see where the vapor escapes as the slight difference in density causes whatever is behind it to shimmer slightly. For a long time the Prius has had a bladder inside the fuel tank which expands and contracts to match the fuel volume [1]. This greatly reduces the evaporative loss of fuel when the car is parked and the ambient temperature changes and also when fuel is pumped in. So it seems that in regard to the issue of fuel vapor poisoning the driver, the Prius has been better than other cars for about 10 years. Apparently Toyota have developed a new system that they have implemented in the Hybrid Lexus and the new Hybrid Camry which involves vapor recovery , this is supposed to give similar benefits in terms of not releasing petrol fumes into the environment but without limiting the capacity of the fuel tank in cold weather (a common complaint about the Prius). I have not been able to find any technical information on how this works (please let me know if you know a good web page about it). The next issue is that any car which gives good fuel efficiency and has a reasonable size petrol tank will be better in regard to vapor releases. The less frequently you need to refuel your car the less fuel vapor you will inhale. I predict that channel 7 will not suggest that people drive fuel efficient cars, they are probably more likely to go for hand-wringing about the inevitable health problems, or make vague claims that the government should do something about it. The fact that the news show in question is immediately followed by Today Tonight (one of the tabloid TV shows) is an indication of the likely quality. A final issue is the puddles of fuel that you commonly see at petrol stations. People regularly spill reasonable quantities of petrol and Diesel fuel and it just accumulates on the concrete. It s not uncommon that I will have to drive with my car windows open after buying petrol due to the petrol that I stood in evaporating from my shoes. Apart from training people to not be stupid when refueling their vehicles I can t think of any way of solving this problem. A petrol station employee once told me that it s not uncommon for people to refuel cars with their young children standing within splash range of the fuel nozzle. If people can t manage to avoid splashing their children with fuel then it seems that it will be impossible to get them to do anything reasonable or intelligent regarding the refueling process.

• [1] http://www.vfaq.net/FAQ-fuel.html

fun with my machines at home in the last days:

• on the laptop my network interfaces got renamed from eth0 to eth1 & from ath0 to wlan0. messing with /etc/udev/rules.d/70-persistent-net.rules helped. this seems to be #521521.
• strange sound phenomenons on my desktop. turns out that (1) centerim's new sounds are nice but very quiet & (2) the audible bell in xterm is broken; the latter is #520405. fixed by quickly creating a local 243-0.1 package.
• on my laptop the function keys don't work via acpi any more. turns out that CONFIG_ACPI_PROC_EVENT is finally turned off in debian's 2.6.29 kernel, & I found no documentation on how to make the keys work again with hal/evdev/whatnot. this is #521279, & right now I'm building a kernel with CONFIG_ACPI_PROC_EVENT enabled.

sometimes running unstable can be a bit time-consuming ...

FLOSS Manuals is proud to announce a three day book sprint for the Pure
Data FLOSS Manual. This sprint will take place simultaneously in New
York City and Berlin from Saturday 4 April to Monday 6 April. The Pure Data FLOSS Manual: http://en.flossmanuals.net/puredata There are possibilities to participate in person by coming to one of the
locations below, or remotely via the IRC interface built into the FLOSS
Manuals editing interface. Video conferencing may take place between the
venues as well. To participate, create a login at the PD FLOSS Manuals page: http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introduction&skin=floss2 Discussion may also take place in the Pure Data mailing list: http://lists.puredata.info/listinfo/pd-list If you are in New York or Berlin, please join us at these locations! NEW YORK CITY * Contact: Hans-Christoph Steiner: hans@eds.org 718 360 4872 * Location (bring ID, you ll need to sign in): ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872 * Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm (if we go later, we ll be in a different room) BERLIN * Contacts Derek Holzer: derek@umatic.nl +49 176 2812 5845
Adam Hyde: adam@flossmanuals.net +49 15 2230 54563 NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52 * Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late
SOME BASIC GUIDELINES: * This manual should address the widest possible user-base. Therefore,
objects which are cross-platform and in Pd Extended should have priority
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn t
always translate well!
* Our readers are assumed to have little to no background in either
computer programming or digital signal processing, which much of the
existing documentation takes for granted. That s why this manual is
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you
use it, and direct the reader to appropriate other chapters/manuals when
necessary.
* Please enter any new technical terms in the Glossary (we need to agree
on global format for glossary terms!).
* Screenshots:
Resolution? (Adam and I will work on this on Monday)
Please upload any complex patches, and make sure to label screenshot
with appropriate filename (see Audio Tutorials for examples)
Please keep explanatory text in the manual rather than only in the
screenshot, so that it can be text-searched by readers.
Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer & Adam Hyde. Your
contributions will only be visible in the editing section until they
meet these guidelines, and after that they can be published to the main
page. Please let us know when your chapter(s) are ready for publishing
and we ll look them over. EXISTING CHAPTERS WHICH NEED HELP: # DataflowTutorials this section needs a lot of help in terms of style and content!!!!!
Tone is very informal, which doesn t help convey the information.
give titles to screenshots so that readers can tell which patches
match which images (some do this, some don t )
Math : examples/discussion of [expr]???
Order of connecting and [trigger] : explain the patches in-line,
rather than only in comments in screenshots (so that text is searchable,
copy/pasteable..)
Luka s screencaps are very aliased, to the point where you can t read
the ~ in the object names. Should they be redone at new resolution or
with antialiasing?
Possible janitors: Derek Holzer, Adam Hyde # PureGlossary format of object names = [italics in square brackets], must be
formatted correctly
format of glossary words in general text: we don t have one yet. Bold
on first use in chapter maybe? Needs formatting all through text. # ListofObjects incomplete, please add more libs
maybe more discussion of externals needed as well
formatting of object names? # PureLinks always welcome MORE CHAPTERS/SECTIONS TO DO (+ suggestions?): * GEM (in order of importance)(Derek can provide example patches for
much of this)
Basic VJ mixer (2 x
[gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with
an alpha-crossfader)(+ platform specific codec info)
Live camera input (same as VJ mixer but with [pix_video], with
platform specific info on USB/firewire inputs what works & what doesn t)
VJ effects (using the various pix objects)
Basic 3D (that actually does something interesting, rather than just
show a sphere or a cube)
Basic movement tracking w/ [pix_blob]
GEM/video optimization/troubleshooting tips (see Troubleshooting
section of existing Pd FLOSS Manual) * MIDI tutorial
hardware:keyboards, sliders, etc,
objects: all MIDI objects
routing: input + output to/from devices or other programs * Patching strategies
Reusable abstractions ($0 etc)
GoP + other GUI creation strategies
Preset saving systems (Frank?) * Audiofile manipulation (Derek can provide examples, possibly also work
with www.pd-tutorial.com with permission?)
sfread, readsf, sfplay, etc
tables + tabplay, tabread, etc
oneshot playback without/with pitch shifting
looping without/with pitchshifting
granulation without/with pitchshifting
Extended objects ([xplay~], [xgroove~] are these stable? In my
experience, no ) * Realtime audio effects tutorial
delays: single tap, multitap, pitch-shifting, tuned comb filter, etc
filters: [hip~], [lop~], [bp~], [moog~], IEM lib filters
[vcf~]/[bp],[hp],[lp], difference between audio signal and message
controlled, building with ggee objects [bandpass],[llowpass],[highpass]
or [biquad~] (resources for coefficients?) * Sensor tutorial (HC?)
[hid]/[hidin]/[pduino]
simple circuit diagrams + photos (voltage divider examples:
potentiometer, photoresistor, etc)(hacked gamepads) * Networked data
netsend/netreceive
OSC
flash server
shell
python externals
others? * PDP/PiDiP
configuration info for OSX (+ poor performance disclaimer!)
basic VJ
networked streaming etc * Procedural Audio tutorial? (Andy?) * RJDJ tutorial? (Frank and the gang?)

I just applied for an individual digital signature certificate at e-Mudhra CA. They have an inaugural offer price of Rs. 248 for a class 3 individual certificate with a validity of two years. The price is good! There is physical presence verification with official documentation at a registration authority (RA) of e-Mudhra, but that should be fairly straightforward. I am hoping that I would be able to file my income tax returns digitally this year.

Experience with the RA, CA and the IT department would be reported.

Recently, my girl friend and I decided to get Arcor DigitalTV. So we got some hardware from Arcor (and unfortunately we needed to "upgrade" our real-ISDN-connection to a SIP-based-one):

• Pirelli Settop Box
• Arcor EasyBox A801 WLAN/ISDN

That second piece of hardware is kinda interesting, because it is an ADSL2+-Modem, (WLAN-)Router, SIP-Gateway and file-/printserver (it has one USB port which can be used to connect an USB hub and up to 4 disks or 1 printer) and 4-Port Switch in one (I think it doesn't include whats called a 'Splitter', because with this kind of connection there is no ISDN signal to be splitted from the internet signal).

Unfortunately not all is well about this (or about my provider). This piece of hardware can be configured with a modem installation code. Which is good for an average user, because he does not need to care about anything. With this process the hardware configures itself by receiving configuration data from a configuration server of the provider. Regardless about other implications this might have: What disturbed me about this is, that I loose control about my router, if I use this. Because when configured this way some sites in the router are grayed out. If you click them you get a message that this setting is controlled by your provider. Uarg. Well, unfortunately IPTV from arcor does not simply use the same internet connection as I usually do (more about this later), so I were suffering from missing informations about how to configure the router manually.
Arcor wasn't particular helpful in this, because they told us "Der Router kann nicht manuell konfiguriert werden." (which means in Englisch: "The router cannot be configured manually."). Although this brought me to laugh, I were also disappointed and worried about this. So I decided to find it out myself. I won't tell what I tried after all, but in the end I found out that the modem installation code-installation does configure:

• 2 PPPOE-Links (1 for the Internet Connection and 1 with private IP-addresses)
  
• 1MAC Encapsulation Routing (which uses DHCP to get settings from tv.arcor.de)

With this knowledge (and some good guessing, e.g. that both PPPoE links eventually use the same user data) I were able to configure the router fully myself, which also enables me to set QoS settings how I want them (which is why I went through the whole torture at all, because SSH was extremely laggish when watching TV). One thing is notable however, how I got the information:

The manufacturer of the router seems to do some things to protect the settings from the user. For example: The page for configuring the WAN is called wan_main.stm, it can be called without trouble if you are configureing the router manually, but the system would block access when you use the modem installation code. BUT and thats how I got the info that the third link is a MAC Encapsulation Link: The status page (where it shows that you are connected etc.) includes javascript vars for nearly everything you ever wanted to know about your router configuration. Not obfuscated after all. You just have to look at the source of the status frame. Thats real professional, Arcor.

To look at the economics of open source software, you have to start with the economics of software as a category, both proprietary and open source. Note: it should be perfectly obvious to everyone that open source software works, and works quite well for some things. This article is more about understanding the how and they why. Just to avoid any confusion... If you look at software as a product, it has a couple of defining characteristics:

• It's difficult to keep people from sharing it. Not impossible, but not easy, either. It was already doable in the days of floppy disks, but with the rise of the internet, it has become nearly effortless. This means, in terms of economics, that it's "non excludable" - it's difficult to keep everyone from enjoying it once you've created it and started to distribute it.
• If you give a copy of a program to a friend, it in no way detracts from your own use of the program. Quite the contrary, it may even make your use of it better, if, say, your friend discovers how to use a cool feature, or writes a handy extension. This is different from traditional goods like bicycles. If you loan me your bicycle, you can't use it to get around. In economics, things like software (or radio or over the air TV) are called 'non rivalrous' goods - many people can take advantage of them without ruining them.

What do you get when you combine something that's "non excludable" and "non rivalrous"? In economics, these are known as "public goods": http://en.wikipedia.org/wiki/Public_good - read the whole thing if you have a few minutes, it's what I'll be talking about. As per the article, "The Problem" as it were, is the free rider problem. Let's stop and look at a contrived example: Bob is an ex-dentist and really knows what it would take to write a great program for managing a dentist's office (or pick your own example... it's contrived, don't quibble about the details). He's also a good programmer, with the skills necessary to implement the program. He talks to a few of his dentist friends, and they're enthusiastic about the whole thing. Let's look at a few scenarios of how things might play out: Bob values his time at 10 dollars an hour, and it will take him 100 hours to complete the project, meaning the whole project would cost about 1000 dollars. One way things could work is that he could find a dentist friend who needs this program, and bill him 1000$ for his time and services, bang out the code, and release it as open source software. Bob gets his money, the dentist gets his code... and all the other dentists in town get it for free, which is bound to make the dentist who shelled out the money a bit irritated, given that he's a human, not a homo-economus, and doesn't like paying and see others get the same thing for free. Let's introduce another variable: the software is only really worth 200$ to the dentist - any more than that and yeah, it's helpful, but not worth that much money (And please stay with me, I know it's contrived, but keep in mind that the situation *is* possible, even if the numbers might be different). That means that if Bob wants 1000$ for his time, but the dentist will only pay 200$, then no transaction will occur! The software won't get written, Bob won't get any money, and the dentist will be worse off because he won't have the nice program, and neither will his dentist colleagues. One way things might still work is if the dentist rounds up some friends and they all contribute a bit, however, that's kind of a pain in the neck for everyone concerned - the dentist doesn't want to get into the software business and spend a bunch of time trying to chase his friends for money, and even if 10 dentists contribute, the ideal position to be in his the 11th guy, who pays nothing, and still gets the software for free. So it's in everyone's interests to not return the dentist's calls in the hope of being the 11th guy. Also, none of them gets the software until they're all on board. So, how to resolve this problem? The wikipedia page talks about introducing an exclusion mechanism, which in this case would be a copyright system so that Bob can sell a copy of his software for 100$ and be sure that it won't be open to everyone to use. This way, the dentists get the software for 100$ less than they value it at (200$), and as soon as Bob signs up an 11th dentist, he's making more than his time/materials costs, and is therefore coming out ahead! The dentists all know that they're paying the same price, so have no reason to grumble about free riders. In short, everyone is pretty happy. Of course, in the real world, things don't play out like that all the time. There are problems with the simplified example above, some of which are very evident: the cost of enforcing copyright laws, in an age when copying is extremely easy, is very high and potentially very intrusive. However, "intellectual property" is, by and large, a compromise solution that has had positive aspects, especially when you ignore the outliers like Microsoft, and look at all kinds of niche software vendors, who make a nice living, create good products, and have happy, satisfied customers. If you look at the other solutions to the free rider problem listed on the wikipedia page, we can see how they might be applied to the world of software.

• Dominant assurance contracts

  Assurance contracts are contracts in which participants make a binding pledge to contribute to a contract for building a public good, contingent on a quorum of a predetermined size being reached. Otherwise their money is refunded. A dominant assurance contract is a variation in which an entrepreneur creates the contract and refunds the initial pledge plus an additional sum of money if the quorum is not reached. In game theory terms this makes pledging to build the public good a dominant strategy: the best move is to pledge to the contract regardless of the actions of others.

  This means that Bob goes out and gets a number of dentists to pledge 100$ to his dentist program, and if he doesn't raise at least 1000$, he'll give them each back 110$. So it's a clever solution that works out for everyone, but is still a lot fiddlier than the copyright system - Bob has to go sell the contracts and explain how things work to a bunch of people before he can get started. This might be doable with 10 dentists, but for a more mass-market sort of program, it would not be feasible.
• Coasian solution

  a mechanism by which potential beneficiaries of a public good band together and pool their resources based on their willingness to pay to create the public good. Coase (1960) argued that if the transaction costs between potential beneficiaries of a public good are sufficiently low, and it is therefore easy for beneficiaries to find each other and pool their money based on the public good's value to them, then an adequate level of public goods production can occur even under competitive free market conditions.

  That sounds an awful lot like open source software, especially the kind espoused by groups like the Apache Software Foundation, where making free software is not a moral imperative, but a good way of producing something that is not necessarily a key business component. This has proven to work very well for infrastructure type code, as well as lots of developer tools. It is less proven as a way to develop end-user software - in the example above, it's not like Bob needs help to develop his system, or that the dentists really want to contribute - they just want a working program and don't want to get involved in its production.
• Government provision This would mean that the government would be responsible for funding the production of open source software. I'm no free-market zealot, but I think the idea of the government being responsible for software products is not one I am entirely comfortable with. Of course, I do think the government has a role with places like universities, where people can do "research" in the sense of hacking on cool systems just to see what can be done, without necessarily having to be thinking of how to make a profit in the short to medium term. Software like BSD, Tcl, and plenty of other great stuff has come out of universities, meaning that in part it is ultimately funded by the government and taxes. The problem, though, is the process of refining those things down into something people are willing to buy. Would Bob go to a local government official to get a grant to produce his software? Why should Bob get the contract and not some other guy? Does the government official know enough about code or dentists to determine who should write the program?
• Subsidies Subsidies might work to encourage software production, but would probably simply be abused. It's probably not as relevant as other potential solutions. What form would it take? 1$ off your taxes per line of code written? It would be difficult to place a value on anything, and might be quite difficult to implement.
• Privileged group This, as the wikipedia page says, is an incomplete solution, and is less generally applicable. In terms of Bob, it might mean that instead of valuing his code at 200$, his wealthy dentist friend with a large practice really needs the code - it's worth 2000$ to him, and can pay Bob the full 1000$ to develop it out of pocket and still come out ahead, and he doesn't really care that much about the free riders because he's getting what he needs and the rest doesn't matter too much.
• Social norms If Bob and the dentists live in a small town, and are all good friends, perhaps Bob could still release the software, and even though the other dentists could copy and use it for free, they don't, because they feel an obligation to Bob to help him out for the work he's done. Even though they could take advantage of it for free, they would feel bad about doing so, and so each chip in 100$, which after enough people contribute, is enough to cover Bob's costs. It's likely that anything distributed on a larger scale, however, will see more free-riding, and "please pay!" might not work out. And it's probably fairly distressful for a developer to make that jump, knowing he's at the mercy of other people's good will.

None of these solutions is perfect, and all, including exclusion in the form of intellectual property laws, or simply doing nothing at all, have problems of their own. Due to the very nature of software, this is somewhat inevitable, and the best we can do is come up with good compromises, and continue to reevaluate them as technology and society change (this is something that needs to happen with IP laws, for instance).

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host

So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host in Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host

So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

UPDATE: added blog title ;)

If you ever have the problem described below, you have to realize that Apache HTTPD is selecting the SSL certificate (and/or key) not based on you VirtualHost definition, but based on the ServerName in the current context. This means that you have two virtual hosts with the same ServerName, but on two different IPs, and are wondering why the wrong key (and/or certificate) is used, it might be because of this. Assume we have the following (simplified) configuration:
<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>

(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA) Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL). This might as well be a bug or a design decision (AKA feature), I don t know. However the workaround that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won t do for the reverse/application proxy part). Update: Fixed formatting on configuration sample to make it clear this is not about namebased virtual hosts.

It s good to see that reportbug 4 finally has a graphical user interface it s GTK, but nobody s perfect Anyways, I m really glad to see reportbug aiming to improve it s usability. Reportbug finally shows all the bugreports for a package in a list which is easily filterable. So when you re confronted with a huge list of bugreports but searching for a specific problem, you can just enter a few letters in the filter and the buglist will shrink immediately. This missing feature was basically the most important reason why I developed reportbug-ng: Users are expected to don t report bugs which are already filed against a package, but the main tool which was used back then to report the bugs didn t make this task trivial. Now it does and it s a good thing! Compared to reportbug-ng, reportbug shows the bugreports of a package in a tree-view, while rng shows them in a table-view. The difference is that reportbug could theoretically group serveral bugs together, like merged bugs. It currently only uses this feature to group bugs of the same severity and status. Rng does that by coloring the lines. Unfortunately in reportbug all nodes are collapsed by default, which is not very usable since you have to expand every node in order to see all bugreports. This costs the user several clicks in order to see all bugreports. It s also not possible to sort the bugs via the columns of the table, e.g. sort by date of last action which I think is a huge feature in order to quickly find certain kind of bugs (old bugs, bugs sorted by date of last activity) but that s probably easy to fix. Another good news is that Reportbug now brings it s own editor so the user is not forced anymore to use an console based- and maybe unfamiliar editor to compose his bugreport. This is a huge step forward regarding usability. It also moves the concept of writing a mail to the BTS a bit more away from the user which is a good thing. Maybe the BTS will support an alternative way to receive bugreports in the future so mail clients may become superfluous for reporting bugs. Under the hood reportbug still parses the HTML from http://bugs.debian.org/ go gain the bugreport instead of the BTS SOAP interface. This coupling is of course dangerous since even the smallest change in the BTS webdesign could break reportbug. But SOAP support is already on the todo list of reportbug s devs. I can only encourage this step, when reportbug-ng moved away from HTML-parsing to SOAP the actual amount of work it took was much less then I thought, I think it took me just one or two days and as a result there is python-debianbts which provides a bridge between the SOAP interface and Python. In summary I think this is an important improvement for reportbug. There are still some minor issues like the welcome screen always showing, the nodes collapsed by default and the columns not beeing sortable but those are small issues and easy to fix. I m very happy to see this improvement, since it will motivate the not so tech-savvy folks to report bugs, and more bugreports will ultimately lead to a better distribution. Good work guys!

On trains from Germany to Switzerland you used to notice the crossing of the border not only due to the appearance of the passport control folks in the train: once the Swiss train team replaced their German colleagues, passengers were finally able to travel in peace. Once you crossed the border, there would be no more almost-continuous blather through the speakers about where to find the restaurant, how lovely and relaxing it would be to enjoy fine cuisine there (I bet they never actually ate there themselves), and that the train crew regrets that some passengers are going to leave at the next stop, how much they hope that they ll soon come back, and how happy they are to welcome new passengers. Each announcement would last somewhere around 30 long seconds, and when it was finally over, they d repeat it in horrific English: wrong words, bad grammar, and pronunciation that made me cringe every time. But apparently, the German railway needs more business and their PR department seems to think that this is the way forward. Not the Swiss, or at least I thought until today. Heck, I even gave myself a GA for my 30th birthday, a year subscription for all Swiss public transport, because I enjoy travelling in Switzerland, and even if it s just to get work done. But just now, on the train from Fribourg back home, the productive and calm silence was interrupted by an announcement where to find the restaurant in four languages, and when the minibar passed the upper deck of our wagon, the voice again made sure we knew. It seems that the days on Swiss trains are gone, when short, smooth, and unobtrusive announcements would let you know about the next station, just in time for you to pack up and get ready to go, or a similarly pleasant message greeted you as you boarded the train, allowing you to make sure that you got on the right line. What a shame.

After spending a considerable amount of time releasing your Free Software project to the public, you will probably want to make sure that it reaches as many of the people it could be useful to as possible. Here are a few tips to get you started.
Homepage: Is this software for me?The first thing you will probably think about is to create a homepage promoting your project. There are a lot of good tips on how to create an effective homepage, but I will focus here on the contents that you should include.

Screenshots are one of the most important elements you can include on your homepage. First-time visitors will only spend a few seconds on your site before deciding whether or not the information is relevant to them. You need to be able to summarize in a few pictures what your project is all about.

Would you be willing to read long white papers or to go through long build instructions just to find out that this software isn't going to be useful to you after all? Probably not. Make sure you can help users figure this out in a few seconds, even if your software lacks a graphical user interface.

Of course you will also want to describe the project in a few words and provide links to the source code and other services you may have available.
Hosting ChoicesWhere to put your contents is somewhat of a personal choice but there are a few things to keep in mind.

First of all, depending on the size of your project and its related data, the hosting site should may need a significant amount of storage and bandwidth. Furthermore, you should check whether download statistics are collected by your hosting provider. While not strictly necessary, it can be very motivating to watch these numbers go up!

Free Software hosting sites like Google Code, Source Forge and LaunchPad also provide different services like bug trackers and source control repositories.

Some people prefer a distributed approach to source control and issue tracking to avoid trusting their master copy of the data to a third party. Setting up a separate code repository on sites like Github or Gitorious is an option to consider.

All of these hosting providers promote the software they host to varying degrees. Have a look around before deciding where you should park your project.
Announcing your ReleaseFinally, what would a website be without other sites linking to it? The obvious place to start would be the main search engines, but that in itself is unlikely to bring much traffic in the early days of your project.

Sites dedicated to Free Software are more likely to bring visitors to your shiny new project. The most famous place for Free Software release news is Freshmeat. Whether or not you visit this site regularly, you should know that its contents is widely read and syndicated and you should not pass on this great opportunity to let people know about your software.

Other directories that may be of interest include the Free Software Foundation Directory and Ohloh (especially if you offer a publicly available source code repository).

Now that the word is getting out, it's time to start thinking about supporting these new users!

Latest Tasmanian Devil Linux 2.6.29 adds quite a lot of new features: Kernelnewbies 2.6.29 Overview. Thanks a lot to the FTP Master Team for making possible the same day upload. Big thanks also for the regular testers of the rcX trunk snapshots.

I generally try not to get caught up in writing auxiliary tools for my free software projects. My experience in the past has been that given how little spare time I have each week, a tool that takes more than an hour or two to write quickly ends up becoming a time sink that prevents me from making progress on the main project. But occasionally it's worth the effort. I spent the last couple weeks putting together a tool to extract information about a dependency search from a log trace of aptitude's resolver. The search is displayed in a log interface that shows both the steps of the search in order, and the tree structure of the search. It took a long time to write, but after working with it for just a few hours, I was able to track down the bugs in the resolver modifications I was trying to write; without a tool like this, it would have taken a lot of painful grepping through log files to get all the information I needed. In other news, the resolver now stores the choices it has made as a single set of choices, instead of using two different sets for the two types of choices it can make. There's no user-visible change (although I did fix another performance problem that affected safe-upgrade), but this will pave the way for adding more types of choices in a cleaner way: in particular, the resolver should get explicit support for package replacements in the near future. The code for this is available in the tools directory of aptitude's experimental Mercurial repository, http://hg.debian.org/hg/aptitude/post-lenny. When I get around to merging it this with the main repository, it will also be available at http://hg.debian.org/hg/aptitude/head.

---

A brief digression regarding the implementation language The tool is implemented in Haskell, a decision that I'm not sure was the right one. Haskell's data model was perfect for this task: having algebraic datatypes allows me to precisely represent cases where parts of the structure can't be inferred from the log file, or can only be inferred incompletely. And of course there are the other well-known benefits of Haskell (pure, a strong type system, good support for higher-order programming, etc). But all those benefits were wiped out by the time I spent fighting the runtime. The thing is, Haskell is a lazy language. In theory, this means that it never evaluates anything you don't need and that you can work with arbitrarily large (even infinite) values and only allocate the parts you actually use. In practice, this means that you have to pay excruciatingly close attention to every single expression you write, or as soon as you run your program on non-trivial input, it will either run very slowly, eat all your memory, die with a stack overflow, or all of the above. Oh, and did I mention that laziness means that you can't have a runtime debugger, that trace statements are mostly-useless, because your program doesn't run in any predictable order, and that it's impossible to get backtraces when there's a fatal error? I think if I were doing this over again, I'd use O'Caml. I'm less familiar with it and its syntax is clunkier, but I have used it productively in the past and it provides the core stuff I wanted from Haskell (functional programming with algebraic datatypes). If someone could make a language that was pure, had Haskell's nice syntax and type features, but was also strict, and that had decent tool support and development resources, I think I'd be in nerd heaven.

Stewart Smith has written about the removal of a blog from Planet Linux Australia [1] due to publishing a list of URLs that the Australian government wants to censor. The first point I want to make is that even if you had a list with thousands of entries that are not likely to offend anyone or incur any legal liability then it s still not suitable for syndication on most Planet feeds. The correct thing to do is to have a paragraph describing the list and why people would want to read it and then use the MORE feature of your blog so that the rest isn t in the RSS feed. If you use Wordpress which seems to have the MORE function broken then that would mean hosting the list somewhere else. In regard to the specific post, in a comment on Stewart s post Matt suggests that the Planet software somehow filter out certain blog posts. I am not aware of any way of doing that apart from through code changes, Matt could submit some patches to allow that sort of thing. One thing that would be really good would be to have an exclusion tag or category in a blog feed. So you for example you could have feed URLs such as /feed/lca which would be configured to list all posts without the tag not-lca. Another way for a blogger to do this would be to use Yahoo pipes [2]. The people who run a Planet should be prepared to take any feed URL. It would not be difficult for a blogger to create a pipe that excludes all items that have NSFW in the title (or any other possible way of listing them). A final option is to have multiple blogs. I have a blog for documents that I regularly update [3]. Many of those documents had been plain HTML files edited with vi for years before I started blogging. But Wordpress is a reasonable CMS and as I use it for blogging it made sense to use it for other documents too. Wordpress has no good option for managing two types of documents, ones that are date-based (regular blog posts with the date in the URL) and non-date based (which change periodically and have different date stamps). There are Wordpress pages, but the support for having moderate numbers of pages is not great. Also on my document blog I will often have articles appear new regularly as I change the date when updating them. Anyone is welcome to subscribe to the feed for my document blog if they are interested in seeing new versions of the documents, but I expect that most people don t want to. The Debian Wordpress package (as of last time I used it) and my fork of the Debian Wordpress package have great support for multiple blogs. There is Wordpress-MU for bulk blog hosting, but that is only designed for people who want to run something like LiveJournal or Blogger. If you just want a few blogs for friends and relatives then the regular Debian Wordpress package will do the job well. Some bloggers maintain two blogs, one for public things and another for close friends and relatives (people who ARE interested in what they ate for breakfast). Having one blog for the NSFW material would be a reasonable thing to do for certain bloggers. Finally while I doubt that someone who runs a Planet installation faces any legal liability, there is also the issue of a PR liability. From a PR perspective I think it s best for the reputation of Linux users in Australia for certain things to not appear on Planet Linux Australia. That said it would be good if there was a process for removing and reinstating blogs that was publicly documented. There will obviously be many differences of opinion as to what is too risky to allow on the Planet so we should expect that from time to time feeds will be temporarily removed. When that happens what does a blogger have to do to be done to be syndicated again? Update: A comment has revealed a way of filtering out RSS feeds via the feed URLs used by wordpress. A URL such as /feed/cat=-X will give a feed of all articles that don t contain category number X. Multiple categories can be specified when separated by commas. So this allows Wordpress users to exclude their NSFW category from Planet Linux Australia.

• [1] http://www.flamingspork.com/blog/2009/03/21/things-not-to-post-on-planet-la/


• [2] http://pipes.yahoo.com/pipes/


• [3] http://doc.coker.com.au/

You may have noticed, or not, but WebKit 1.1.3, which has been released a few days ago, is available in experimental. The great news is that we now have a real maintenance team, because I now have a co-maintainer, who actually did most of the work getting the 1.1.x releases in shape for experimental. Now, some JavaScript performance figures, as I have been doing for most WebKit releases I uploaded to the archive, with a recap of previous episodes:

• svn 27674: 3932.0ms
• svn 31842: 2612.2ms
• release 1.0.1: 1658.4ms
• release 1.1.3: 1333.2ms

All there tests have obviously been run on the same machine, under the same conditions. The machine in question is my x86-64 laptop, which means all these test are with a x86-64 binary. This also means the last release, 1.1.3, doesn t take advantage of the Just In Time JavaScript compiler, which is only available on x86 binaries. With the x86 binaries under a x86 personality chroot, I get under one second:

• release 1.1.3, with JIT, x86: 985.4ms

But, in the last few days, I ve been working on getting JIT first to build and then to work on x86-64 linux, and with the help of folks on the webkit-dev list, that just happened. And the result is just wow.

• release 1.1.3, with JIT, x86-64: 623.0ms

(Note that a few tests are actually slower than on x86) That s so many times faster than what we had a year ago that it s almost unbelievable. Expect the next upstream release, planned for some time in the near future, to have my patches applied. In the meanwhile, you can get them here and here.

Cheers.