Yesterday was such an insanely long day -- we woke up in a tent, had breakfast over a Treo, then released a lot of software and went to sleep in the middle of the night. It seemed like 4 days, not 1. And this morning I had to take our new mini-SUV into the shop for its first maintenance checkup. For the last 6 years, I've driven a beautiful old wp:Citro n DS station wagon, but around the time Amita June was born I decided I wanted her to learn to drive on it. Maj and I decided that that meant it had to be taken care of a little better, so I put it in storage and we bought at 2005 Hyundai Tucson. (The Hyundai people here in Quebec pronounce it like "Tux-awn", to our endless amusement.) It's weird having a new car -- like, newer than 1972. Parts are not only plentiful but inexpensive. There is a selection of multiple mechanics in my major metropolitan area that can service the vehicle. And people don't point and wave when you're driving, or stop you on the street to tell you stories about how their grandfather used to drive one on their family farm. We'll be driving the car to wt:Boston next week for Wikimania 2006, so I'm glad it went to the shop. It should be in good shape for the drive -- I hope the rest of us are. tags: hyundai tucson citro n ds quebec new car

Slides Speaking of Wikimania -- I'm nowhere near ready for my presentation. Jeez, how'd it get to be almost-August already? Thankfully, no one else I've talked to is really ready to talk, either... so at least I'm not the last one to get my homework done. tags: wikimania presentation slides

Software The OpenID software I did for MediaWiki went out yesterday, and I got a lot of good feedback on it. OpenID requires that some state data is stored between participating servers, and the code I wrote uses the memcached client built into MediaWiki to store it. Not optimal but it works. Well, better today than yesterday, that is. There were some pretty gruesome bugs in the implementation that were only showing up for some exceptional circumstances. So I adapted the JanRain unit tests for the other storage classes to my Memcached class, and that helped a whole hell of a lot for debugging. Yay, unit testing! Some people are still having problems with the software, though. The main thing I've found is that the key-value pair output required by OpenID for its inter-server communications is sensitive to extra whitespace thrown in. Why would there be extra whitespace? I've found that a lot of PHP libraries have bits of whitespace at the end, after the closing ?>, and that will show up in the output. Whether it matters depends on how sensitive the output format is to whitespace. In the case of OpenID, the answer is: pretty sensitive. But I'm looking forward to having some more people try the OpenID MediaWiki extension out. tags: openid mediawiki extension unit test php whitespace

Wikipedia's 25th of July Spot-on satire from The Onion: Wikipedia Celebrates 750 Years Of American Independence. I quote:

• "On July 25, 1256, delegates gathered at Comerica Park to sign the Declaration Of Independence, which rejected the rule of the British over its 15 coastal North American colonies," reads an excerpt from the entry. "Little did such founding fathers as George Washington, George Jefferson, and ***ERIC IS A FAG*** know that their small, querulous republic would later become the most powerful and prosperous nation in history, the Unified States Of America."

Does the fact that I find an Onion article funny say more about my declining humor standards, or about their recent improvements? I don't know. tags: the onion wikipedia satire

Four ideas I was very interested to see Tim O'Reilly's Four Big Ideas About Open Source. I think that there are some fascinating developments over the last few years that have fallen under the rubric of wp:Web 2.0, and I think they affect those of us who put our hearts and minds into Open Source software. I think this was part of his keynote at OSCON 2006, which, y'know, I'm not techically at or anything. It briefly crossed my mind, but I've got too much to do for Thermidor and Fructidor to flit off to yet another conference -- this one only tangentially involved with what I do for a living. Still, it's interesting that Open Source software and Web services are crossing paths. FLOSS has been critical for making Web services possible, but taking that up to the meta-level and seeking the same freedoms from Web apps that you expect from "regular" software... that's a Moebius strip of rights right up in there. tags: floss open source oscon tim oreilly

My life as a toolbar So, sometime in the last year I started installing Firefox toolbars. The main one that's useful to me is Chris Pederick's excellent Web Developer Extension, jam-packed with little tools that make my job as a developer that much easier. But I also install, well, pernicious toolbars. Judgemental toolbars. Toolbars that make me forget what really matters and turn the Web into a horserace or a highschool popularity contest. They're horrible, and they're addicting, and I can't stop using them. The Google Toolbar has some diddly little useless gadgets that I don't give a shit about, like searching my Gmail account for the given search terms (whoopee). What I loooove, though, is the wp:PageRank indicator. PageRank, of course, is the patented algorithm developed by Google founder Larry Page to estimate the importance of a page on the Web. It's incredibly accurate and valuable and though no longer the only criteria Google uses for ranking pages, it's still critical as a measure of the intrinsic value of a page. So, there's this little wp:progress bar on the Google Toolbar that shows the PageRank of any page you're looking at. It's an apparently logarithmic scale from 1-10, with the number showing up in a popup tooltip. Creative Commons? 9/10. Ted's story about the great worldwide race? 2/10. Technorati home page? 8/10. Male Secretary? 6/10. Wikitravel's France discussion? 3/10. And so on and so on. Even worse is the A9 Toolbar, which (again) has a whole bunch of bogus boring features, but also shows the Alexa ranking of any site you're looking at. Alexa ranking isn't some egghead hooty-tooty algorithm about the importance of a page -- it's a ranking on the Big Board of who's the most visited site in the world and who doesn't matter in the slightest. So, I can see that Flickr is ranked #41 today, le Sans Fil is #347,296, and wikiHow is #2248. Alexa is a lot more coarse-grained than Google's toolbar -- it measures the traffic to a given second-level-domain, not a particular URL. So any LiveJournal or Blogger site gets LJ's entire Alexa ranking -- not very useful. Still, I've taken to thinking almost entirely in terms of PageRank and Alexa rank. It's unreasonable. Every site I go to, my eye drifts up to my toolbars to confirm my idea about it. Do I really like Achewood? Sure, but it's only got an Alexa rank around 20,000... Doc Searls's blog has a PageRank of 8, which is really impressive; but... my page for 22 Prairial (Journal/22 Prairial CCXIV) apparently has the same PageRank. Holy moly! Why could that be? (I think it has something to do with the wp:Law of 22 Prairial, but I could be wrong.) Really, putting these numbers on everything is ruining the Web for me. It's turning me into a total jerk, too. I kinda want to go back to the time when I just found stuff on the Web and didn't think, "How do I measure up?" Thankfully the Yahoo Toolbar doesn't include anything remotely like rankings... just as well. Of course, that's the reason I uninstalled it, too. I can find my way to Yahoo! Canada Greetings just fine on my own if I need to. tags: google a9 alexa toolbar pagerank

Adrian von Bidder asked that question on debian-curiosa and stated he would like to see it on planet, but for technical reasons hasn't his blog there: I just read that AMD bought ATI. Is AMD better in terms of Linux support than ATI? Does anybody have contacts inside AMD or ATI who might be able to influence management to change the policy wrt open source graphics drivers now that the company has changed hands? Feel free to join the discussion on the list.

Speaker break-in tme myth or reality tries to debunk the myth of audio speakers needing time in orders of 30-50 hours to get to ther best audio properties after purhase.
I bought a new set of Sennheiser HD 215 a few weeks ago. I unpacked them and conected to my laptop. I was blown away by their performance, but something at how the bass frequencies were “muddy” and not clean confused me. Then I read in the manual that I should play some music on the headphones for at least 30 hours to break them in and only then they would get to their best audio characteristics. So I left the headphones on the laptop and left some music playing in them overnight and only came to them after at least 20 more hours of breaking-in. I put the same music on as I did the first time and I was not dissappointed - the bass was much more clean and instruments in the bass area were finally as distinct as they should be at this level of headphones. I did not listen to the music during the break-in time, so my brain did not adopt to the sound of these headphnes - they acctually sounded better.
I do not really care that a distinguised loudspeeker engineer can not find an explanation of how this break-in happens, but that does not change the fact - it exists.
Update - A few more links:

• Discussion - fun starts around page 10
• Pro-burnin article

In the end peple end up playing sine waves and measuring frequency response thus oversimplifying the problem. It is well possible that non-sinusiodal sound is needed for proper break-in (as in sound with multiple different frequencies at once, or sound with harmonics, …). It is well possible that the “sharpness” or “mddiness” that is reported by the audiphiles as the characteristic of a non-broken in sound system is not something that is measurable by frequency response - aharmonic dispositions, temporal dispositions and other distortions of the sound are easy to detect by a trained ear, but very hard measure with precision unless targeted. Also people ignore the real complexities of the materials that are used. We think that wood is simple and plain and understood material, but in reality wood is such a superior microcomposite material that it has properties that are still not nderstood by modern material science. And when we get cooperation of metalic parts, wood, chemicals and, most importantly, natural and complex vibration - predicting all effects of such vibration on the complex system, that is a simple speaker, is … well … complex. Audiophile ear can easily hear distortions that normal audio equipment simply can not measure with any confidence. Discarding phenomena that one simply does not know how to measure or explain is just blindfolding yourself. I was even more fascinated by the description of an simple non-scientific experiment showing break-in effect on audio cables. This was discarded outright as impossible, but it is acctually much easier to understand. Cable is simply a thin piece of metal through which a stream of electrons is flowing. It is not too hard to imagine that these electrons traveling at light speed could impact any impurities or defects in the cable. Any such impacts would distort the analog signal going through the cable. Also after multiple weeks of electron bonbardment it is not impossible to imagine such impurities or defects (or the material around them) being changed in a way to ease the flow of electros (like wind erosion of rocks) thus breaking-in the cables and improving their sound - making it more fluid. That is quite easy to see - why should not there be a set of similar efects working on a whole audiospeaker?

On my way to England, since I was flying RyanAir, I needed to print my boarding pass myself (I could alternatively have chosen to stand in line for two hours). Problem is, I don't have a printer at home, which led to me visiting an Internet cafe.
They were running Windows, and basically had everybody logged in as an admin. When I needed Acrobat Reader, the shopkeep said I should just install it, it would be fine. As the installation looked pretty clean to me, I assume they just reinstall the machine after every customer.
Could that be an idea also for Linux based kiosk setups, a virtualised box where you'd be running out of an LVM snapshot so wiping the box is basically the same as forgetting the changes; then giving users the permission to install stuff?

Flying home from Frankfurt yesterday via Chicago, as usual I randomly selected a shortish looking line in the immigration and customs hall. When it was my turn, the agent behind the counter saw the "business" box checked on my form and asked who I work for, which is pretty standard. He then asked me what I do for HP, but before I could answer, he said "No, wait. You've been through here before. I recognize your passport." I managed to retain my composure just enough to agree that he certainly could have seen my passport before. He smiled, stamped my form, and waved me through. My wife wonders why I was so surprised.

I found a suitable right-angle 50-pin header for the SCSI card while wandering around in the Fry's in Palo Alto earlier this week. This evening, I managed to extract the straight header without damaging the board, and installed the new connector. The board fits in the backplane just fine now... and with a power cable swiped from a dead ATX supply and a suitable SCSI cable and drive from the pile, the card still seems to work. I need to find or make up another cable for the silly MMJ serial connectors, and then I'll be able to try loading ancient Unix...

In a recent work-related conversation, Matthew Wilcox pointed out that EFI partitions are mountable on Linux and many distributions keep ia64 system partitions mounted at /boot/efi by default, but Debian does not. Since that behavior is mostly my fault, I recounted the history by way of explaining why it worked that way... and on suggestion from Martin Pool am repeating it here to document all this for posterity. When we were making ia64 bootstrap decisions, the default bootloader on i386 was lilo, and the closest example to what we needed for ia64 in Debian was powerpc. This is because systems using EFI only understand FAT partitions by default, and thus need a FAT partition somewhere that the firmware can read from... often the first partition on the first disk. The Debian model for handling such things at the time seemed to be to craft a command to hook from kernel package postinst scripts that did the heavy lifting in association with a config file. What went on behind the curtain wasn't something to bother the user with on an average day if you could avoid it cleanly. Some bootloaders know how to read a config file from /boot directly, and we started out thinking we'd use elilo that way, but it was hard to match up paths/naming in EFI to what they would look like under Linux. It was also clear to me that most ia64 systems were going to have large system partitions so there'd be plenty of space. So we punted and copy the elilo executable, config file, and any kernels or initrd files referenced in the config to the system partition. I also thought the default location other distributions had chosen for mounting the EFI partition once the kernel was up, /boot/efi, was pretty ugly, but I couldn't think of anything better. The problem is that the standard says you need an \efi\"whatever" directory as the root of your content in the system partition, so mounting the partition at /boot/efi yields paths like /boot/efi/efi/debian. Some distributions didn't adhere to the standard at first, and so didn't see the ugliness until they started to comply... but I was on a team at HP making disk partitioning and content decisions that caused me to be very aware of these details. Putting that all together, I decided there wasn't any point in having the EFI partition mounted by default... anyone who cared and wanted it mounted could just add a line to /etc/fstab to put it wherever they wanted. If I were doing it again today, I'd have an entry in /fstab marked noauto delivered during system installation. I haven't cared enough to tackle that change, though. Sadly, there's one detail of the current implementation that can get in the way of complete happiness. The Debian-specific 'elilo' script that runs in user space to manage the EFI boot partition contents based on the content of /etc/elilo.conf expects to have to mount the EFI partition, and exits with a complaint if the partition is already mounted. For typical users, this script only gets called during installation and from kernel package postinsts, and the actual elilo bootloader remains oblivious to all this. If other distros have picked up the Debian script, I'm not aware of it. So, you're no worse off mounting the EFI partition in Debian than with some other distro, you just get treated poorly if you try to use our elilo script while the partition is mounted. Clearly, we could handle this better. If someone wants to offer up a patch to the elilo script that asks the user if it's OK to scribble in the already-mounted partition instead of doing a mount / scribble / unmount cycle in the presence of an existing mount, I'll be happy to include it in the Debian elilo package. Meanwhile, a lot of us have switched from lilo to grub on our i386 systems, and I'd love for my ia64 systems to work more like my grub-equipped systems. But making a substantive change like teaching elilo to know where /boot is so that it can read a config file from there and do things more like grub, without symlinks, etc, has several issues. We'd need to get the right set of file systems supported from EFI/elilo, we'd need to address the naming issues, and we would require either user intervention on upgrade, or some clever automatic parsing and rewriting of the relevant config files. I can think of other things that would be more rewarding to work on, so don't anyone hold their breath...

What a couple of weeks.

So I went off to Europe. I had planned to meet up with Daniel Stone and many others in Paris, but fate decided to piss in my cornflakes and delay my flight out of Boston so that we missed the connecting flight to Paris. I spent the whole next day in Montreal's airport, and while I got a lot of reading about Norse mythology done, I didn't have nearly as much time in Paris and didn't get to meet up with anyone. Daniel and I will have to postpone drinking and bashing X in person until a latter date. The time that I did spend there, was great though, and I got to do some of the tourist things that I didn't get to do last time I was there. Nicole, my girlfriend, had never been to Europe, so she was thrilled to see things for the first time.

Then it was off to Munich, where I did get to spend some time with Michael Banck, who is even more awesome in person than on the internets. Michael was my sponsor in Debian for well over a year, as well as my advocate, and now we're both ops in #debian together, so it was a real thrill to finally meet up with him. He was too polite to let me buy him dinner or a drink as thanks, so I'm hoping he comes to visit so I can repay him. I also got to meet several others, including release manager extraordinare Andreas Barth, which was a lot of fun. We were in town when Germany was playing Sweden in the world cup, and Germany actually won, so the whole city was singing until dawn. Ever since I've been back I've been drinking lots of Hefeveisens and wishing that they were served in 1 liter form.

Surprisingly, since I've been back, I've had the opportunity to do some programming at work and push Free Software at the same time. A co-worker of mine recently did an experiment that got her a list of 900 genes, and she wanted to narrow that list by comparing them to another list or two, but had no idea how to get this done in a reasonable amount of time. So one afternoon I wrote a small ruby script to do this, and all of a sudden my boss is looking at me wondering what other sort of neat computer things I could whip up. I also had to start doing some statistics, and I found a test that I needed to do which Excel couldn't do, so I started learning and coding a bit of R, which is pretty nice so far. The co-worker of mine just invested $800 in a two day class on learning to use an add-on for R, which is cool because I've totally failed until now to get anyone to use Free Software in the lab. The whole thing is making my labmates look at me a little funny though, since this stuff is way out of their league for the most part.

The bad news is that a few days after I came back, I found that my laptop's hard drive started making some very bad noises. I moved my data to backup computer that I'd inherited but not really used, only to find that the backup machine was prone to weird random errors. That left me without a functional computer at home. I took the opportunity to order a new machine for myself, but for now I'm kind of stuck with a web browser at work. In the meanwhile, I've taken to teaching myself statistics, and in order to do that, I've been re-learning calculus. I find it a little weird that I'm going home at night and picking up a calculus text book in my free time.

As far as X work goes, not having a working computer has caused a bit of a problem. Luckily, just before my machine died, Andres Salomon had nearly finished work on backporting Xorg 7.1 to sarge. Afterwards, he decided that he wanted to join the XSF, so since then he's been spearheading getting 7.1 in to experimental. He's been continuing the work that I haven't been able to do lately, and I'm excited to work with him in the future. In addition, Jurij Smakov joined the team as sparc driver maintainer, and Drew Parsons is officially joining the team, bringing Xprint officially in to the XSF. So even though I haven't been able to do much, things are moving forward, which is wonderful to see. As soon as I can get set up, I'm going to keep working with Andres to get 7.1 ready to ship in December.

Surprisingly, I drink far more lately than when I had a working computer. I think something is wrong with me if working on Debian helps to keep me from seeking chemical modification.

About a month ago or so, I joined in a discussion on the debian-boot and pkg-exim4-devel mailinglists about the current Exim (v4) configuration schemes. To keep you from having to google for that discussion, I'll quickly summarize my opinion on the subject of the exim4 configuration scheme in Debian: I think it sucks. I've been a rather fanatic (ish) exim user since about two months after I became a Debian Developer. Initially, I removed it to replace it with sendmail. But that was a bad idea, and I quickly found out why. However, I never liked the exim 3 configuration script, since I never could get it to do what I wanted; and, according to the exim 4 maintainer (and to anyone who compares both schemes), the current exim 4 configuration system is just a rehash of the exim 3 configuration system; not much more. But it's so backwards. The initial question which exim4-config asks you may have been relevant in the time the initial exim 3 config script was written, but it is so totally outdated in a modern Internet. As a result, my current modus operandi when I install a new box is to get out of the exim4 config system as soon as I can, to gunzip /usr/share/doc/exim4-config/examples/example.conf.gz to /etc/exim4/exim4.conf, and to open the file in a text editor. At least I know that works, the way I want it. No hard feelings, Marc (but you knew that already). Personally, I had different ideas about what an efficient question would be, and I posted those to the mailinglist (you will have to google for those if you want them, though :-). I also promised to come up with some code to implement my ideas. This has proven to be... interesting. Currently, I have a config script that does a few questions and then switches to "Not Yet Implemented" mode. As in: it displays a debconf template of "Type: error" that basically says "This part still has to be implemented". For the postinst script, I wanted to base myself on the existing postinst script. That does not seem to be a very good idea, however; the existing postinst script contains a lot of upgrade cruft. And then I still have to write my update-exim4.conf. Looks like I took on a job which turns out to be larger than expected... Oh well, I guess I'll cope. It'll just take a bit longer than I wanted it to.

Quote from Joey Hess: In 1999, Debian began moving /usr/doc to /usr/share/doc to comply with the FHS. Due to unfortunate dpkg issues at the time, we couldn t simply move the directory and be done with it, but decided to move things peicemeil by updating all packages. Due to some silly concerns about users having to look in two places during the transition, we decided to start by making /usr/doc/ -> /usr/share/doc/ symlinks. In 2001, putting any documentation in /usr/doc became a serious policy violation. The symlinks were still allowed. In 2002, we completed the first stage of the transition, released woody with complete /usr/share/doc and /usr/doc directories, and policy was changed to not require the /usr/doc symlinks. debhelper was changed to stop adding postinst and postrm fragments to manage the links, and so most packages only needed a recompile to finish the transition. As a result, More than 250 bugs were filed, blockers of #322762. Most of these bugs, rot in peace in the BTS for years, some maintainers fixed them themselves, some other maintainers NMUed and others did QA uploads to deal with this issue. But it was not enough. It looks like at a certain point I decided we would not ship Etch with a transition from 2002 still in progress, so I did approximately 114 NMUs between the 11th and the 18th of July, fixing 152 bugs, 46 of which were not related to the /usr/doc transition. I also closed the ones affecting packages not in testing or unstable, unblocked the ones for packages that would not ship with etch (as exim3, that will be replaced by exim4), and updated the MIA info for several of the maintainers. At the same time, I revamped packaging a bit if I felt inspired to do so. Sure, things went wrong at bits and places, which I later fixed the best I could, but inmense love was poured in these NMUs. Several maintainers thanked me and the most NMU-unfriendly people didn't even complain. Lars Wirzenius pointed me to other related bugs, found by upgrading from testing to unstable with piuparts, and added blocking relationships with #322762 where needed. At this stage, less than 5 open bugs remain. I suspect that more packages once created this link and don t remove it on upgrade. I would need some help to find them. All this NMU fever happened while Joey was away on holidays, and when he returned, he confirmed my fears, I had DoSed his email and bandwidth: <joeyh> amaya: did you have to fix all the /usr/doc bugs while I was on vacation?
* joeyh watches his inbox and BW groan at the seams :-)
There is still several important and minor issues that we should deal with before Etch is released, Release Goals or not, just because we are Debian, and just because we care about this sort of things:

• The "You still Build-Depend on Xlibs-dev" Transition.
• The "You left a link link in /usr/doc" Transition.
• The "Please use Invoke-rc.d in all maintainer scripts" Transition.
• The "Let's switch to Cdebconf" Transition.

Some of you will argue that these might not be transitions per se, just mass-bugfilings. I don t really care how you d rather call it. If you are looking for easy ways to help Debian, or to fill your lazy summer afternoons with, provide a patch today and CC: me. I intend to group these bugs either using user-tags or blocking bugs in the BTS. Help locating them and grouping them will also be appreciated. [Updated entry to reflect more accurate NMU and bug totals]

Collection Management I like to collect things, books, audio cds (which I buy exclusively second-hand/used then rip), and films. I’ve had a lot of fun putting my film collection online (Warning image-heavy). Although I admit the reason I did it in the first place was because I found myself buying DVDs I already owned more than once. I do the same thing with books. I can recognised covers easily, so if I see a book which is by an author I like I will look at the cover and think “Hmmm got this”, or “Hmmm thats new”. This leads me to buy duplicates too often. This leads me to wanting to organise the hundreds of books I have, so I can lookup what I have/dont have easily. My recent query the other day about scanning ISBN numbers with a barcode reader seemed to suggest that using the hardware is trivial. However the next step is hard. I can’t find a decent tool for using storing the data in. So far I’ve looked at:

alexandria

I loved this when I started it up and imported a few books by ISBN. It found the title, the publisher, a cover image, and more. However the backend seems to be a bit hit and miss. Picking books at random I soon found major gaps. e.g. Adding Terry Pratchett’s Mort gave me all the details. Adding Witches Abroad gave a blank image and just the title, all the other details were wrong/missing.

tellico

Tellico I’ve just ruled out. It allows you to create collections of things, but you must enter all the details yourself. I’ve neither the time nor the patience to do that.

So I’ll postpone this project for a while. Probably just as well since I’ve discovered that a suprisingly large number of my books do not actually contain ISBN numbers! Mostly the older paperback fiction books I have such as “H.G.Wells the valley of the spiders & other stories”, but even modern books like some of Steven Brust’s Vlad Taltos series are free of ISBN numbers.

ScatterChat is a new cross-platform IM client announced by the Cult of the Dead Cow / Hacktivismo (during the HOPE conference, it seems). From the website:

ScatterChat is a HACKTIVIST WEAPON designed to allow non-technical human rights activists and political dissidents to communicate securely and anonymously while operating in hostile territory. It is also useful in corporate settings, or in other situations where privacy is desired. It is a secure instant messaging client (based upon the Gaim software) that provides end-to-end encryption, integrated onion-routing with Tor, secure file transfers, and easy-to-read documentation. Its security features include resiliency against partial compromise through perfect forward secrecy, immunity from replay attacks, and limited resistance to traffic analysis... all reinforced through a pro-actively secure design.

So the client is a "friendly-fork" of Gaim, it uses Tor to achieve anonymity, and for the crypto parts (secure messaging, secure file transfer) ScatterChat uses libgcrypt. It's a cross-platform application available for Linux, Windows; support for other OSes is planned (Mac OS X, others). You can always download the source code, of course, as it's free software. Actually, not quite. While ScatterChat itself is based on the GPL'd Gaim, it has to be GPL'd, too. However, the scatterchat-module package, which seems to contain the crypto-parts, is licensed under a custom "Hacktivismo Enhanced-Source Software License Agreement" (HESSLA) right now, which is so horribly long I didn't even bother reading it. However, the README says:

I am open to the possibility of re-licensing parts of this library to GPL, BSD, public domain, or some other license. I cannot make any promises, but I will try to accomodate reasonable requests.

I'm going to do just that, email the author and ask him nicely to change the license to some sane, well-known free software license. If you feel similar, please let the author know (hint, hint). Depending on what the HESSLA really says, it might prevent ScatterChat from entering Debian, for example. I haven't yet tried to use the application, but it sure looks like it has a lot of potential. It also seems do most security-related things right:

• it doesn't try to reinvent/reimplement its own crypto primitives (which would be doomed to fail), but rather uses libgcrypt
• it has a documented crypto protocol
• it's free software, which is a major requirement (see Kerckhoffs' principle)
• it doesn't reinvent the wheel, but rather uses Tor for anonymity (for example)
• etc. etc.

Of course that's no guarantee that it's secure; I hope some crypto-gurus look over it soon. But at least they didn't make obvious stupid mistakes we've all seen in many other pieces of software. Anyways, I feel this is a real important project which will help lots of people (activists, political dissidents, normal people like me and you who value their privacy). Go check it out! (via Boing Boing)

With the help of Antoine I’ve customized my Debian Unstable Firefox. Via right-clicking, customize and dragging away the various widgets, I’ve managed to remove most junk and leave the stuff I want:

1. Google’s spell check
2. Google’s pagerank indicator
3. del.icio.us bookmarking
4. sURInk.com to shorten&share long URLs

The extensions I have installed are:

1. Google toolbar
2. Mozex 1.07.1 for editing textareas with vim
3. Web Developer 1.0.2
4. Searchbar Autosizer 1.1 to expand the Google search box for longer queries

I’m also back to using wmii window manager, although I miss Ion’s speed. I should try dwm when it is packaged. Overall, I am happy with this desktop.

Following about a month of irregular activity, I just uploaded three source packages (along with related binary packages, of course) to Debian unstable: gforge (4.5.14-9), gforge-plugin-scmcvs (4.5.14-3), and gforge-plugin-scmsvn (4.5.14-2). I hope unstable will give them more exposure than experimental did. Plans for the future: I’ll focus on getting these packages into testing, without too many changes if possible. I haven’t managed to get dbconfig-common to work reliably (or at all) with PostgreSQL so far, so I’ll consider the migration to its infrastructure as a nice option, but not a blocker. The problem is that it would make the install scripts simpler and (hopefully) more reliable if it worked. Again, help would be very much appreciated. (And yes, I will be submitting bug reports when I get some time to do some more thorough testing of dbconfig-common.)

So the flight to Sydney was relatively uneventful. I managed to get a reasonable amount of sleep, and with the assistance of some Coke, I've managed to stay awake and will probably last until a reasonable bed time for this time zone. The general suckiness is because they managed to lose my bag. I feel totally naked without a functional mobile phone. My work one isn't roaming for some reason (it seems to be the phone itself, and so I'm assuming it's a GSM900 thing), and my personal Australian one is in the lost bag. Then I discovered that United didn't take the I-94 out of my passport when I checked in, so that's probably going to cause me all sorts of immigration grief when I return to the United States.