There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla camp, that I, as the Firefox co-maintainer, the xulrunner maintainer, and (soon) Seamonkey iceape co-maintainer, have to rectify. They broke the –enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox at the appropriate places in the build tree so that we could have Firefox with the “unbranded” logo instead of the official logo, as Gervase Markham gave us authorization for. You’re still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken. Firefox logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla has unnecessarily given a non-free license to “clarify” the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period. Debian isn t properly collaborating with Mozilla , sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum’s blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in… that’s exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming. The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas’s blog again).
So, let’s dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
• Changes to fix “make distclean” so that it really cleans the build directory,
• Change not to build the “mangle” utility,
• Change not to call netstat to generate entropy, which is useless on linux,
• Changes to make Firefox build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla guys don’t seem to care much for,
• Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
• Change to allow to build flat chrome without the zip utility,
• Change to allow to use system library for myspell, instead of statically linking the bundled one,
• Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
• Changes to work around bugs with the hidden visibility pragma on gcc,
• Changes to make the pango backend actually build correctly,
• Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in’s,
• Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
• Change not to build useless chromelist.txt files,
• Changes to make helper applications with parameters work,
• Changes to allow builds against GTK 2.8,
• Changes to work around an Xrender bug,
• Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences…),
• Change to allow mice extra buttons to act as something else than a left button,
• Change to allow to build with -Wl,–as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions’ components,
• Changes not to shlibsign the NSS modules at build time, since we’re stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That’s not that many changes, and most of them were taken from either some Mozilla CVS trunk or the Mozilla Bugzilla . And most of those that were not taken from there have been sent, except those that really don’t make much sense outside Debian. So, where are these frozen API changes ? And we’re not properly collaborating, huh ? The Mozilla project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett’s blog) That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I’m not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions. The only main difference now, between the official Firefox and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won’t explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files. Now, a little bit about differences the Mozilla guys don’t seem to care about while they really should: distributions build the Mozilla products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox that is linked against libstdc++6. You are lucky if that setup doesn’t crash. Little extra from comments in Lucas’s blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more. Update:
Debian is going to replace Firefox with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name… that’s quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can’t and won’t do more than a rename for the moment. Update 2:
We (Mozilla ) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it’s Ubuntu, it’s fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes. Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

[2006-10-13 18:00]
There is a popular saying in Spanish, "en viernes 13 ni te cases ni te embarques" - Roughly, On Friday the 13th, don't get married and don't board a ship. That makes perfect sense - I'm already married, so I'm not worried about the first part. About the second, you never now - So I'd better take the plane to a country without sea access. Bolivia, here I go. [2006-10-13 23:30]
I'm writing this blog entry as I fly out of Mexico towards Bolivia, via Panama, on Lloyd Aereo Boliviano's flight number 911. The captain just announced that dinner will be served shortly, and invited those of us who want to enjoy the meal to open the tables, in order to get a better service. I fear that if I don't open it, I might get soup served straight over my pants, or something like that. [2006-10-14 02:40]
At the Panama airport. Captain informs again: "Passengers, we inform you we will replenish fuel. Therefore, if you choose not to go out for 15 minutes, we will request you to sit down with your seat belt unlocked. You will not be allowed to walk along the ailes. The bathrooms will be closed. Please do not ring the bells." Damn, that brings quite a lot of quiet about the refueling process - Of course I went down for 15 minutes, along with everybody else. BTW, shame I didn't take my laptop with me, as the battery is now at 15%... The Panama airport has (contrary to most airports I've been to in recent years) plenty of power outlets. Anyway, maybe on the way back. It's now 03:00 (Mexico time), and I think I'll have a better use for the next four hours until we arrive to Bolivia than coding.

In a comment on a previous blog entry I was described as an active Fedora advocate, I don't think that is an accurate description. I advocate it to appropriate people, which is mostly non-programmers - but as I mentioned that means a larger proportion of the population than to whom I can advocate Debian. It's not that I'm trying to advocate Fedora, just that it fills a need for many people. I believe that the term Fedora advocate means someone has an objective of increasing the use and to use Fedora, I don't have such an objective. I am a Linux advocate, a Free Software advocate, and sometimes a Unix advocate (Unix meaning the entire family of Unix-like operating systems). Merely promoting something does not make you an advocate for it. I don't think of myself as a Debian advocate at this time, but as I am a Debian developer this may change.

It seems that the people who run the Fedora Planet think that my blog has suitable Fedora content, it's been added to that planet. Also the Fedora Planet appears to be running an older version of the Planet software as it has the same problem with my blog that Debian Planet had before the upgrade.

Now on the issue of gratis vs libre: As I am not a Red Hat employee I can't maintain a kernel-xen-nopae package and give it the same status as the kernel-xen package. Even when I was a Red Hat employee I couldn't have done that - it would require some amount of management approval. I believe that this fundamentally makes Fedora less of a libre distribution. There is no room in Fedora for someone who is an upstream developer and who just wants to maintain their own package. There is Fedora-Extras, but that has a second-class status. Only Red Hat employees can maintain packages in Fedora Core. This makes Fedora fundamentally less libre than Debian. I am not trying to suggest that Red Hat change things in this regard, I believe that Fedora is meeting all it's goals and that making Fedora as libre as Debian is not possible given the goals of making a profit on selling support of RHEL.

Chris made a good point. I also believe that MP3 codecs should not be in Debian/main. But I believe that people making mistakes about some issues is not a factor in judging the entire project. I believe that Debian is more libre although some bad decisions were made - largely due to lack of overall management. Fedora has hierarchical management, so when the legal team declares that some software can not be distributed then it gets removed without debate. I guess I could propose a GR to exclude MP3 codecs from main.

Also it should be noted that RHEL Extras has some of this software that is not in Fedora (RealPlayer for example). The Red Hat legal advice was that MP3 codecs need a license, so they ship a licensed version in their commercial distribution. This is the right thing to do for their customers (it's handy to have and I'm sure that they get a good deal by paying license fees for all their customers) and removing such things from Fedora is the right way to offer a gratis product without unreasonable legal liability.

Naturally Fedora is much more libre than any secret-source OS. Every user has the option of downloading the Fedora source and recompiling it as they wish. I could compile Fedora with a Xen kernel that runs on my hardware and with SE Linux policy that is more restrictive than that which Fedora currently has. I could build custom Fedora install CDs to install things the way I want (which I considered doing when I worked for Red Hat). But the liberty to fork a project does not compare to the liberty to join it, and the liberty to create your own packages in extras does not compare to the liberty to add your own packages that do things differently to the default package.

There are of course positive and negative aspects to this. I started work on SE Linux in Debian in 2001. In 2003 I joined Red Hat to work on SE Linux, in Red Hat I was not the only person dedicated to SE Linux work and other people spent part of their time working on it. The SE Linux work in Red Hat soon eclipsed that of Debian because there was management support. There was no possibility for a package maintainer to refuse to fix a bug that affected SE Linux simply because they didn't care for it. The positive side of this is that the SE Linux work proceeded quickly and efficiently. The negative side of this is that things which don't have management support don't appear in Fedora Core. Exim is a fine MTA but is not in Fedora Core. Some people think that AppArmor is a better option than SE Linux, they are wrong - but in Debian any developer has the option to add AppArmor support and neither I nor any other DD can prevent them. The libre nature of Debian means that as long as basic technical criteria are met DDs can add any package that they wish to the distribution.

These issues however are all related to people who are actively involved in Free Software development. For a typical Free Software user it often doesn't make much difference, until of course your favourite program doesn't get management approval to appear in Fedora Core. But the counter argument is that the quality of some of the >10,000 packages in Debian is not so high. You can install a Fedora Core package and have a reasonable expectation about how well it works, but Debian packages are sometimes rather experimental.

I also don't believe that Debian is a very functional Democracy. Some of the problems of Direct Democracy are demonstrated in Debian. In many ways it is more anarchistic, anarchy gives you liberty for good and bad. Maybe we should consider a Representative Democracy model for Debian.

I’ve finally finished packaging keytouch, and gotten approval for it by my sponsor. It’s currently in NEW, and probably won’t make it to etch, because of the freeze. Kind of a shame, since I could have finished a little earlier and it would have gotten in. Well, can’t have everything. I did manage to upload a new version of sawfish, which finally documents how to prepare the source tarball. sawfish has so many old bugs I’m at a loss as how to handle them. I’ll be RFHing it soon, to see if someone can help me triage. But still, with upstream almost dead, it’s hard to think of a good approach.

Been doing some squashing today. No uploads, since I’m not at a BSP. Just posted patches for 389630 and 389375. Let’s go, everyone! If I can fix bugs, so can you!

I'll space them out a bit now, no more daily pictures.

Years ago Jon Wright (a well known bearded OS/2 programmer) told me that after you get past a week of growth it stops being annoying, I think I'm getting to that stage now.

Today I discovered a bug in one of my programs, it called system() and didn't correctly escape shell eta-characters. Fortunately I had written custom SE Linux policy for it which did domain_auto_trans(foo_t, shell_exec_t, very_restricted_t) so there was no possibility of damage.

The log files (which were not writable by the daemon by both SE Linux access control and Unix permissions) indicated that no-one had attempted to exploit the bug.

The kernel team, or should I say, Sven Luther, as the rest of the kernel team hasn't been remotely as visible as him on this topic, is now trying to spam debian-devel-announce, assuming the average Debian developer isn't able to read the proposals. Fortunately, the mail was redirected to debian-devel thanks to clever filtering.

I still think, for the moment, that Choice 2 of the proposal currently being voted (Special exception to DFSG2 for firmware as long as required) is still the best of all proposed choices, and I'll try to explain why.

1. This proposal doesn't only address firmware issues. It clarifies DFSG 2 for other works often found without source, acknowledging current practice for fonts or pictures.
2. Granting an exception only for etch is dishonest. The real reason behind the exception is that we don't yet have any means to ship these firmwares in a way that complies with our principles. We're violating them in the testing and unstable distributions as well, and that has nothing to do with a release.
3. Granting an exception for etch may not be sufficient. I don't want to see these endless discussions again for the next release, and this is what is probably going to happen if an etch-only exception is granted.
4. The proposal frees the hands of people working on stripping the firmwares out. Their patches would have to be accepted straight away, not two months before the release when someone says "Hey! there are non-free firmwares in the kernel!".
5. By principle. I'm fed up with people splitting hair on debian-vote for weeks, to end up reaching a formulation that's close to the one I wrote in a few minutes a month ago.

Everyone should make up his own opinion. You're welcome to read the proposals themselves rather than the propaganda I'm writing, but I hope I've made clearer the rationale of Choice 2.

After restarting my i386 buildd some days ago, H ctor Garc a lvarez asked me where he could find a howto to setup a buildd. Unfortunately, I never found any clear doc about that. Today, I have setup a new sparc buildd which is also rebuilding the whole archive, thus it will take something like... 2 or 3 months I think (UltraSparc II @ 360 MHz with 256 MB RAM). But this time I clearly took notes on what I did, and there's now a mini-howto. I'm sure it's not really complete, but that should help you to have something working. As usual, do not hesitate to send me feedbacks.

At this school, every friday morning one member of staff holds a speech full of wisdom, insight and motiviation. While usually I find these quite transparent and full of good-sounding, not-very-helpful advices, today's speach by a history teacher was different.He talked about how africa keeps blaming the European colonialisation for it's current state, and that it should rather look ahead and "forge forward" (I didn't even know you could use "forge" as a verb implying movement, and dict.leo.org doesn't know either). He listed other countries with a devastating event in their history who were successful afterwards: Japan, after the the atomic bombing, became an industrial giant , German's economic miracly after being bombed to ashes and the Jew's will to go on after the holocaust.He assumed that if the bombs had been dropped on an African country more than half a century ago, people would still be blaming their current problems on the bombs, and demanding compensation, which some Africans do now regarding the slave trade, and which the teacher thinks also displays of lack of own initiative. Again, he compared that to Germany and Japan who did not think of expecting compensation (but then, these two have started the war that caused their bombing, so this comparision is, in my opinion, not entirely valid)Also interesting was the thesis that if these days a large slave ship would land on an African harbour, and announcements would be made that 200.000 slaves would be needed to work on American farms, people would thrash forward to go on that ship. Although it was probably a citique on the mentality of some Africans, it could also be seen as a reference to the state of affairs in Africa, where to some work as a slave might be the better choice.All in all a very interesting point of view that I wanted to share with you. It definately made more impression than my talk about Free Software, but that one went ok as well, I think.

Took some time at lunch today to look at more places. auzure_skies and I came home, and I got an email saying that I've been accepted into the M.Sci IS program. Then we called the real estate agent and asked her to come over so we could make an offer.

And yesterday the first book in the CIM course showed up.

The nice part is that much of the CIM should be finished by the time the baby's born. The move will be done and out of the way, and the Master's program doesn't come until several months after. So it only *feels* like I'm insane. Really!

We have started using qemu for automated testing at work. Right now we only have one kernel and disk image that I threw together by hand (for ARM), so I spent a big chunk of this afternoon trying to figure out how to do it and document the process. When I did it last time, I needed major kernel hacks and qemu patches and debian-installer tweaks, because the ARM emulation didn't have anything capable of working as a hard drive; so I took some code that Paul had written to use the Angel RDI semihosting operations as a "virtual block device" that talked to the host system. I added support for this hack to qemu and forced d-i to install even though there was only a single non-partitionable device. Since then, Paul added real PCI support to the ARM qemu. So I expected everything to be much easier. I took Aur lien Jarno's excellent writeup and prepared to try again. But since we already had a functional ARM disk image, that was lower priority... I decided to try MIPS. I helped get the MIPS softmmu port working about a year ago, but it hasn't been receiving a whole lot in the way of care (though there's a bunch of unreviewed patches for it). First I discovered that I'd never gotten initrds implemented last time I worked on qemu-system-mips. So I hacked that together. Then I needed a drive; I used root NFS in my last setup, but the whole point of this experiment was to avoid that. So I added the emulated ISA IDE controller. Good news: both of those worked easily! And the d-i session starts up OK, and even writes to the disk OK; partition tables were discovered at next boot. I've posted some patches for these. Bad news: it hangs during formatting the swap partition, consuming endless CPU. It's definitely doing _something_ in userspace, but I'm not sure what, and it's hard to find out. I've heard other reports of faulty MIPS emulation recently, too. I know how to debug this sort of thing, but it's really more time-consuming than I can manage now :-( While waiting for builds in that, I resolved to try reproducing a nasty kernel bug in qemu for x86-64: since I booted into 2.6.19-rc1 all my coredumps have been truncated very short. My normal hardware kernel boots OK, but if I rebuild the kernel with the default config and debug info, it doesn't:

checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
Freeing initrd memory: 5498k freed
*hang*

And the other thing that's apparently not been getting a lot of love lately is the debugging stub; if I attach GDB, it dies much earlier, so I can't set a breakpoint at initramfs detection to see what's going on. Overall result for the day: Argh!

It is always nice to get feedback from people using your work. It happens that a long time ago (February 2002) I wrote a tiny little program called "udp-broadcast-relay" that does nothing but hauling udp broadcast packages from one local network to another one. I wrote it because I needed it then, and did not care for it after somewhen in summer 2002, when I did not need it any more.Yesterday, I got this message:

Von:	<xxxxxxxx@mail.ru>
An:	Joachim Breitner <mail@joachim-breitner.de>
Betreff:	udp_forward_relay
Datum:	Wed, 11 Oct 2006 19:59:23 +0400 (15:59 GMT)

Hello Joachim,
Thank you on your programm udp_forward_relay.
Best regards
  Alezander

And today:

Von:	<xxxxxxxx@mail.ru>
An:	Joachim Breitner <mail@joachim-breitner.de>
Betreff:	Respect
Datum:	Thu, 12 Oct 2006 22:39:07 +0400 (18:39 GMT)

Hello,
> Thanks for the mail. It's always good to hear that people are using
> it. What do you use it for, if I may ask?  
Im us if on a router with 6 network segments for relaying broadcast packet from quake3,
war3 and VyPress Chat. Im from Russian and live in "NNSU" universety hostel,
in Nigniy Novgorod state. All peoples from my hostel send respect for you...
P.S. Sorry for my english...
Best regards
   Alezander        

That feels good. I once got a similar thing from pakistan, too. Strange selection of countries...

Just did an awesome install of Debian etch onto Maggie's laptop, which had stopped having working wifi in windows for unknown reasons. Everything worked great in the installer and the resulting desktop felt very nice for a regular user, the only things I had to add were madwifi (non-free..) and network-manager. It was probably my most painless and happy Debian installation ever. (Details on the page for ?phoenix, and in the installation report linked to from there.)

Many moons ago I thought it might be nifty for my work on Debian QA to have an easy way to see what has changes in each version of a Debian package. I wrote a little script that built a bzr branch for each package, and imported each new version in my mirror. Unfortunately, there were some problems, and I didn't have the patience then to fix them. Last weekend I finished the script (despite not doing any Debian QA work anymore), and set it running. Today it finished. There were still some problems: 88 packages failed, due to problems in bzr. I've reported them to the bzr mailing list. The run took about three full days, on an machine with a 2 GHz AMD64 cpu (in 64-bit mode), 1 GB of RAM, and two 80 gigabyte hard disks in striping mode. It would've gone faster, but I ran out of disk space a couple of times, and it took me hours to wake up and notice. Disk space usage is now about 90 gigabytes, but that's with most branches' working files removed, to save disk space (i.e., only the .bzr directory and contents in most branches). Note that the size shouldn't grow very quickly. Most new versions only change some files, and only parts of each file. Version control systems are good at keeping only the changes. I'm pretty sure 200 gigabytes would last for a long time. Bandwidth and disk I/O might be more limiting, if we wanted to have this as a service open to everyone. I don't know if bzr is the best vehicle for this; perhaps a huge Subversion repository would work better. My instinct says that a distributed version control system would work better, but I'm sure a centralized one would work, too. Whatever the system, it might be helpful for QA work, and for making changes in many packages at once, to have something like this. For QA work, it would make it easy to see what has changed in each version, or to find the version in which a certain change in a package was made. For sweeping changes, this kind of a system should, I think, make it easier to automate the build and upload of packages that are changed. I'm not, by the way, suggesting that this kind of a system would be used to do normal maintainer development. It would work by importing new uploads, not by having people commit to it directly. Or perhaps such a system wouldn't have any use for Debian, I don't know. But at least the script was useful for stress testing bzr a bit, and finding a couple of bugs in it. So it wasn't a waste of time to finish it.

Dear Lazyweb, I’m looking for a small, (easily fits on my lap on the cramped seat of a bus,) inexpensive, (around $100 CAD,) mobile text-editing device with a 90%-sized keyboard and decent battery life that runs an open source OS and Vim, and that I can sync to my desktop system. My first mobile device was a NEC PC-8201A, circa 1984. It ran on 4 AA NiCad batteries which I hardly needed to change more than once a week. At the time, it was my ideal mobile notetaking device. Its near-full-sized keyboard, Wordstar-compatible text editor, terminal program and serial interface allowed me to take notes which I would sync to my father’s Mac at home or to the VAX at the university. Today, my mobile computing needs have hardly changed: text editing is almost all I do. I don’t ask for much of a display, but as an 80 to 90 wpm touch-typist, I won’t settle for anything less than a near-full-sized keyboard. I’d prefer a system that runs Debian, and Vim is a must. Some means of easily synchronizing the device with my home system is necessary: PCMCIA wireless-B would be ideal, but is not a must-have. At the moment, I’m using an old Zaurus (not Linux-compatible) ZR-5000 which has good battery life but a very cramped keyboard, poor software, and no functional means of synchronizing the device to my PC. OK for jotting down quick notes, but frankly, I’d rather have my PC-8201A back again. I could at least type on it and sync it across the serial cable. I took a brief look at various Psion models, but they appear to be near-impossible to find. The HP Jornada 720 looks intriguing. And the NEC Mobilepro 780 appears to be another possibility. Have I overlooked anything? So, suggestions please.

Last weekend, I went to Zurich for the second leg of my own personal BSP marathon. Martin Krafft organised the BSP at the AI Lab in Zurich, arranging sponsorship and encouraging local DDs and users to turn up. Martin and I started early on Saturday morning, opening up the lab shortly before 9am and making a start on the RC bug list. Over the course of the next few hours, more people turned up and started work too - local DDs and a couple of Debian users from ETH. We worked our way through a fair number of bugs that day; personally I closed #389318 (a grotty FTBFS bug caused by IMHO a design mistake upstream - parsing header files using a simple awk script to create an m4 script to then generate C source) and spent quite some time digging into some other bugs. For our late dinner on Saturday, we headed to a local American-style bar/restaurant in Oerlikon called Cheyenne. Their speciality, it seems, is the "Big Mama", the largest burger I've ever seen! It comes on a huge serving plate, and is enough to feed up to 4 people...

I took the chance over dinner to chat with the small group of locals, especially Axel Beckert who had some interesting stories about Fedora, Opera and other groups. On Sunday, we started slightly later but probably had a more productive day in terms of the number of bugs closed. I fixed some silly FTBFS issues in ser: #384772 and #390008 were both caused by the build system assuming i386/amd64 compiler options. I adapted patches suggested by Julien Blache from his own work on openser (thanks!) and tested on my sparc and hppa systems at home. Job done... For the rest of the day, I used the time to work on remaining bugs in my own packages. Both CVS and debian-cd needed new uploads to be ready for the Etch freeze. CVS had a bucket-load of new translations following Christian Perrier's call, and debian-cd had a large number of bugs that had already been fixed in svn for a long time. Between those 2 uploads (and some other old bugs in debian-cd that needed reviewing) that made another 17 bugs fixed, although none of them were RC. Once those uploads were done, I continued on with my debian-cd multi-arch development work. On Sunday evening, we went into the middle of the old city centre in Zurich to a more traditional Swiss restaurant. Several of Martin's colleagues from the lab joined us, and we had some widely varying conversation, ranging from Debian (of course! *grin*) to gossip in the lab via lots of other topics. Due to my ridiculously early flight home on Monday morning we couldn't stay out too late nattering, but nonetheless all the people seemed to enjoy themselves. The Swiss group were a fair bit quieter then the Dutch the previous weekend, but seemed just as committed to getting work done and getting Etch out on time. It was lovely to meet and spend time with them, and I've promised to go back and visit again soon. Until then, I've put my small selection of photos online.

Right now I'm just starting to break new personal records for hairyness.

I've been surprised that the GIMP isn't as difficult to use as I had previously thought. I particularly like the preview feature for saving JPEGs. I can use a slider to set the quality of the image and see a preview of viewing the file before saving. In the past with less capable software I used to go through a laborious process of saving a JPEG, viewing it in a separate program, and then repeating until I achieved an acceptable balance of file size and quality. Now I can adjust the slider and see what the result would be in terms of both quality and file size.

Recently I was doing sys-admin work for a company where Windows was the desktop standard. Often we had to send around screen-shots of various problems and the way of doing this was to use CTRL-PrtSc to copy an image of the window in question and then paste it into a MS-Word document because the Windows image had no other program that was capable of dealing with image data. One significant problem with MS-Word is that it doesn't allow expanding the image or modifying it, so you see it at about half the original resolution. It seems that what I should have been doing is pasting the image data into the GIMP and then saving it as a PNG file (PNG is loss-less compression which avoids the ripples you get from JPEG compression of text and it's also very efficient at compressing the regular data that is typical in a screen-capture). PNG files would take much less space than MS-Word documents and allow efficient viewing by many programs (including web browsers which are on all machines).

Ajax has shown how viable it is to run client-side computations, while just downloading the raw data from a server. But Ajax is not restricted to doing fancy user interfaces. It should easily be possible to use an iframe based ad to use the CPU power of page visitors to do some large-scale computations. Can you imagine how much processing power Google could churn up by having its GMail users do some distributed computing? Or on YouTube. While the user is watching the video, a javascript does some calculations in the background. By keeping data in a cookie, your calculations might even be able to survive page reloads. And if you're running a large ad network such as Googles', you might even be able to dect user inactivity. Update a cookie whenever the user comes onto an adsense page; if he didn't go on such a page for 30 minutes assume the user is idling and start computation. If he leaves open his web browser over night you'll get a lot of CPU cycles. (Yes, I know that Google is supposedly not in desparate need for free CPU cycles...)