There is some discussion again about what should be on topic for Planet Debian, whether it should be used for Debian-related announcements and what the archival policy should be. I believe that this discussion is rooted in two circulating views of what Planet Debian should be:

1. A forum for DD's to post Debian-related thoughts and ideas, to be used for those cases where they think a mailing list post may be less appropriate;
2. A way to collect stories about what DD's do and think in any context, the human interest angle: get to know your Debian peers more than just in technical matters.

Although I always regarded Planet Debian to be the latter and I appreciate reading posts telling me about someone's job or other interests, either one isn't an invalid approach per se. They do however prompt different choices about listing policy (Debian-only feeds vs. everything goes), how much effort it is to keep up with them and perhaps archival. The best way to match the expectations of those two groups would be to create two "planets", one for each group. Create an aggregator where any DD can add any of their feeds, and another one with a strict listing policy: only feeds that carry posts actually related to Debian development matters (probably a subset of the first). Then only the question remains which one will get to carry the Planet Debian name...

We escorted Sarge to its last home. 3.1r8 is done, thanks to all the people who made it possible. A big thanks goes to James Troup, our ftpmaster of the day doing all the grunt work of getting a new point release out of the door. To bring in a more personal feeling of who makes this all possible, here is a list of people contributing uploads to 3.1r8 (mostly people from our fabulous Security Team):

• Alberto Gonzalez Iniesta
• dann frazier
• Darren Salt
• Devin Carraway
• Florian Weimer
• Gregory Colpart
• Julien Cristau (who is glad that he finally got rid of xfree86)
• Luk Claes
• Martin Pitt
• Michael Koch
• Moritz Muehlenhoff
• Noah Meyerhans
• Patrick Schoenfeld
• Roland Mas
• Russ Allbery
• Sean Finney
• Steffen Joeris
• Thijs Kinkhorst

I would also like to thank dann frazier, Luk Claes, Martin Zobel-Helas and Neil McGovern for helping with the preparation of the point release.

Having recently been through the process, I've managed to come out the other-side with some some advice for anyone taking this on.

• To start out, the link for making appointments at the Australian Consulate is VisaPoint. I found it was remarkably well hidden.
• Upon entering the country, it's quite likely the immigration officer won't be that familiar with the E3 Visa. I'd recommend you watch them and very politely correct anything you think wrong, in my case my Visa was incorrectly entered as E3-Dependent along with my wife (proving that the system doesn't actually keep referential integrity between an E3 and an E3D holders).
• You can not get paid before receiving a social security number. You can not apply for a social security number within about 10 days of entering the country, as there is a lag between immigration and social security systems. Once you apply it will take a few weeks for the card, but you can probably go back to the office with sufficient ID within two days and receive a print-out of the number. You can call the office you filed with first and they can tell you if it's worth coming in to try it. In the absolute worst case, if things screw-up, you could be in for a long wait. Your company may be able to loan you money if things get desperate.

If anything really stuffs up you'll have to enter the US immigration services, which is no fun. If this happens to you in the Bay Area go straight to the San Francisco office; the San Jose office doesn't have deferred inspections so you'll probably just have to go there anyway.

Your dependent on the E3D Visa will need to fill out an I-765 work authorisation form. This will take up to 3 months to process; you can find out the approximate queue time here. The form doesn't appear to have been updated for E3D; I would strongly recommend getting a lawyer to file it for you so you don't stuff it up. Budget about $400. After this has been processed, the dependent will then need to file for a SSN before they can be paid.

Tax is a black-art. In California expect to pay something like 20-25% federal, 10% state and up to 7% more for Medicare and social security. Expect another $80/month for health insurance.

You can get a bank account without a SSN easily. A good way to transfer money is OzForex, but watch out for fees on the US side (you may have to do wire-transfers which cost about $10 a go, though some banks have bill-pay). The country still runs on cheques for some reason.

You can rent without a SSN, but it will cost you. Budget for 2 months extra rent as deposits and paying ahead.

A car lease is probably a good way to go. Finance will usually look at your visa and only give you a two-year loan, and with no credit that will be at a very high interest rate. In California you can get a 2 year lease on a base model new car (sticker price ~$17,000) drive-away for a down-payment of about $2500 and then $250/month plus taxes. Insurance will be about $120/month on-top of that. The beauty is you just give it back when you go home. For long holiday trips SUV rental may contribute to global warming, but is a very comfortable way to see the country.

In California you'll need to book in for a driving test to get a license; you can't do this in a rental car but some local driving schools offer a short introduction course and then let you use their car for the test.

If you're living in temporary accommodation without great facilities Dream Dinners is a good way to easily get some meals together.

In the Bay Area, Yelp is an awesome resource.

Comcast make Telstra look like a well-run, efficient and customer focused organisation!

Feel free to drop me a line if you're thinking of taking an opportunity and have any questions.

If you are writing free software, choose your license appropriately. This can make a big difference with respect to adoption of your software.I'll just show you an excerpt from a Debian changelog:

* DFSG version of Mono 1.9
  + Deleted the mcs/class/System.Web.Extensions/ directory as
    mcs/class/System.Web.Extensions/System.Web.Script.Serialization/JSON/*.cs
    is licensed under Creative Commons Attribution 2.5 which is not
    DFSG-free.

Debian policy doesn't allow us to include Creative Commons Attribution 2.5 in the main Debian archive, since that license doesn't meet the Debian Free Software Guidelines, which are part of our social contract. Therefore we must and will remove such code.debian-legal summary for "main" Creative Commons licensesCreative Commons is aware of these issues:

Creative Commons recommends and uses free and open source licenses for software.

And then they suggest to use GPL. While there is a link in the right side menu to the Creative Commons page on licensing Software, they IMHO don't make this obvious enough. Their license chooser should include a central link "if you intend to license software, read this".Creative Commons even includes "wrappers" for common licenses: CC GPL, CC LGPL, CC BSDSo if you like Creative Commons because of this pretty "commons deed" human-understandable version of the license they offer, just use these wrappers. The "legal code" links will actually take you to the GNU or Opensource.org license pages.I'm not aware of a good reason to use an opensource license other than GPL, LGPL or 3-clause BSD, depending on how you want to allow your opensource code to be used in combination with non-free software. If you are contributing to a bigger project, choosing the same license as the main project is although a very good idea.

Since about half a year now we have a fibre to the home connection. This means that two fiber lines terminate at a box in our living room. It is a blown fibre which means that a tube is buried to your house, after which they use air pressure to put the actual fibre from the house to the POP. There are two fibers: one for bidirectional data (IP), and one that does nothing more than carry the analog cable TV signal. We started out with only the internet facility but now have so-called triple play: phone, analog tv and internet connectivity. The results are in: I find it to be just as good or better than the previous offerings: phone from KPN, tv from Casema or internet from Surfnet. But there's nothing revolutionary. Phone and tv just provide the same service over a different medium. The internet connection is with the standard of 24 Mb/s more than fast enough for any day to day use and an upgrade to 50 Mb/s is pending. A real improvement is that the upstream speed is just as high, very useful when uploading photos, packages or the text of this blog post. One drawback is that they only provide one IP address instead of 32. Also, the service provider (XMSnet) does seem to be a bit stuck in the late nineties with an unfriendly help desk telling you that your situation is impossible , and bad billing, There are plans however to open up the line to other providers in the future. So for now it's just a convenience bundling of services, but nothing really ground breaking. Let's see what the future brings.

Recently I took stock of my Javascript programming efforts, with the intention of simplifying things. To date I've put together three sites which make use of Javascript:

debian-administration.org

There isn't very much javascript in use upon this site, and you might be forgiven for thinking there was none at all if you don't have an account, or don't login. There's a tagging system which is starting to creak under the sheer number of different tags, and several back-end parts of the site make use of AJAX calls. Most of the script lives in a single file common.js which I cobbled via a process of trial and error, augmented with a little copy & paste coding. It works. But I knew I could do better ..

ctrl-alt-date

This was my first attempt to make a site be truely dynamic and "pretty". It has succeeded in that respect, although the lack of members makes the site itself essentially a failure. This time round I decided that I'd utterly refuse to write my own Javascript. So instead I used script.aculo.us (damn I hate those ugly URLS). This library made it almost too easy to add flash. I liked it a lot. Having said that though the sheer scope of the library and the way it didn't fit in the way that I coded made it painful to use at times. It works, and it works well. Like it? Yes. Love it no?

mail-scanning.com

This site has a fair amount of javascript upon it, but that isn't obvious unless you're actually a user. The only piece that I can recall is the real-time count of spam caught upon the front-page. (Realtime stats are cool!) Most of the code here is the simple kind, reverting back to the way I worked on the Debian Administration site; we're talking about basic effects such as:

• show/hide a div
• make an AJAX request every now and again.
• Do a bit of auto-completion.

To get more of a feel for whats out there I wrote this initially with my own code, then later migrated it to jQuery. Quite frankly jQuery rocks. The way it works is a little strange at first, but it is so natural after a while. As an example:

// find the div called "foo" - hide it.
$("#foo").hide()

I'm liking this library a lot recently, but only time will tell if I use it more.

In conclusion I filed #473125: ITP jQuery failing to see the existing ITP already present. Once the package makes it through the NEW queue I will update it to follow the skeletal javascript-policy. I disagree about the naming scheme suggested by that policy primarily because we already have packages of several of the "big" javascript libraries, such as scriptalicious, and see no gain in renaming them. But otherwise the policy is sane enough; following it will cause no harm at the very least. ObQuote: Stand By Me

There are many reasons to hate Java, it's like shooting fish in a barrel. But in the last weeks I found some more, half of them aren't even fault of the standard API (the usual culprit), and I want to share my frustration with the rest of the world. It has no unsigned types Say you want to manage binary protocols, files, etc. You'd like to store and retrieve bytes and words in machine format, of course, but you'll have a hard time finding the right value because you can't have a goddamn unsigned byte! So if you want —for example— to read the length of a string which can be bigger than 127 as a single byte, you'll end doing some aberration like this:

byte strl = foo_retrieve_byte();
int real_strl = strl < 0 ? 256 + strl : strl;

You can't inherit constructors Maybe there's something in the OOP dogma that mandates this, but if I want to define a new exception that does nothing, but allows me to differentiate a custom class of errors, I don't want to explicitly write dummy constructors instead of writing an empty class —which is simpler and cleaner— and have the four standard exception constructors for free. So, you'll have to do this:

public class FooException extends BarException  
	public FooException()   super();  
	public FooException(String s)   super(s);  
	public FooException(Throwable t)   super(t);  
	public FooException(String s, Throwable t)   super(s, t);  
 

Instead of this:

public class FooException extends BarException    

You can't declare destructors Say you've coded a nifty jdbc wrapper that automates most of the boring stuff, like automatically freeing the connection to the connection pool when there was an exception thrown, logs errors and maybe queries, handles auto-commit settings, etc. In the simple case, you'd create an instance, do some work, and then close the connection; if there was an SQL exception, you little class will take care of it and re-throw. BUT, if in the middle of your work in the calling code, you have an unrelated exception, you need to catch it or you'll leak connections, because the wrapper class doesn't have a way of handling this, even if the object gets garbage collected! In the end, I had to write tons of times the same stupid code:

try  
	j = JdbcWrapper.new(foo);
	j.doSelect(bar);
	unrelatedObject.unrelatedMethod();
	j.doUpdate(baz);
  finally  
	j.close();
 

You don't have a sane way of controlling the terminal Most of the time, when dealing with web applications, you won't need this. But when you're doing some serious stuff, you might need to write a CLI application (oh, noes!); and then do some stupid thing like asking the console to stop echoing characters so you can ask for a password. You'd think that the smart guys that designed Java would have devised an portable library to handle this trivial task, but no! Guess what I found when looking at a way of doing this? Some idiot at SUN recommending (and many dummies following) a background thread that spits backspaces faster than the user can write! Of course, SUN will tell you that using Strings is insecure for storing passwords, because they cannot be wiped out like byte arrays. But they fail to mention something as basic as not showing the fucking password in the first place, or something as important as wiping the object after using it: you can't lock memory from Java, so you risk that it could end in some slack in the swap file. No, you can't leave stdin/stdout/stderr fscking alone! When dealing with the previous problem, you say fuck portability and just call stty -echo to do the job. Well, you'll find a little surprise! Even if you don't ask for the process' reader/writer streams, the Runtime class will pipe(2) and dup(2) your child process' standard streams. With this excellent approach you cannot have a child process output stuff to the user, nor even errors; you cannot allow the child process access the tty (stty obviously can't do shit with a piped stdin). And there's no fucking way to tell it to stop crippling your standard streams! The only solution I could find was a very ugly shell hack:

Process p = Runtime.getRuntime().exec(
	new String[] "sh", "-c", "stty echo > /dev/tty < /dev/tty 2>&1" 
);

No, you can't handle signals After doing the previous hack, you find that if you interrupt your process while waiting for user input, your console will remain in noecho state. So the obvious thing is to catch SIGINT and friends and call stty again to restore the console. HA! You will find that there's no standard way of doing that, and if you really need it, you have to resort to undocumented com.sun.* classes which aren't even guaranteed to be present in every JVM. My solution was to set up a shutdown hook, which solved this problem, but would not solve other very common problems that are solved usually with signal handlers. Tags: Planet Lugfi, Planet Debian

Ext JS is some sort of Javascript framework stuff. I know nothing whatsoever about Javascript, but what interested me was the slightly odd license. If you're a non-profit you can have it under the LGPL 3.0, but if you want to use it in a library then you have to buy a commercial license for them. This seems at odds with my understanding of the LGPL, but anyway. I'm a non-profit, so I've downloaded it under the LGPL. Under my LGPL rights, I've put it up for download here. If you want to use it in a library, feel free to do so as long as you abide by version 3.0 of the LGPL.

Thanks to Decklin for pointing this out.

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won’t be ready this week-end. It’s always when you come closer to the goal that it gets farther… And I still haven’t decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue. Considering we will more than probably have both schemes in use within reverse dependencies, I’m not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul… That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though. I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI. The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package. I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast ! For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I’m planning to package a new Webkit snapshot soon after I’m done with xulrunner and Iceweasel, we’ll see then how it performs. While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn’t crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0). Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I’m testing on x86-64).

Between February 29 and March 4, 2008 I attended the Sage Days 8, hosted at the Enthought headquarters in Austin, Texas. This was my 5th time in the USA and it was a marvelous experience, as with all my visits in the states.

As usual, I had some adventures in Atlanta, that interested readers can find at the end of this post. Anyway, on the Austin's airport I met Peter and his wife Crystal, Fernando, Benjamin, Jarrod, Eric and Clement. We went to have a dinner and then me and Clement were staying at Peter's house:



You can see the neighbor's cat and Peter's dog Trinity behind the window. The next day we went to Enthought, that was providing us with a breakfast and a lunch each day - and it was delicious. After the breakfast, we gathered in the room and introduced ourselves. Enthought rents 3/4 of the 21th floor in the Bank of America building, so when I looked left I saw:



When I looked behind I saw:



and in front of me, I saw all the participants (I took photos of all participants together with names). As you can see, there were really good people in there, like Travis (creator of NumPy), William (main author of Sage), Eric (CEO of Enthought), Fernando (author of IPython), Jarrod (the release manager of SciPy), Michael (the release manager of Sage) etc. See also the Fernando's welcome speech and the video of each of us introducting himself.

The views from the windows are terrific. I enjoyed working on each of the 4 sides of the skyscraper with completely different scenery, or when the sun is going down, that's also very cool.

We spent the whole Friday doing presentations, some of which you can find here. Then we went to Eric's house to have a big dinner together.

On Saturday, Sunday and Monday we were all hacking on many different things. I joined Fernando, Benjamin, Brian and Stefan on ipython1, Travis was implementing a new type (gmp integer) in NumPy, William wrote a manipulate command in Sage, Eric did the same in Traits, Gary and Michael implemented parallel testing of Sage, ...

On Tuesday we had final status reports and people left in the afternoon. In the evening we went with Clement to have a dinner and then we visited some bars on the 6th street, having a beer in each.

On Wednesday I visited John and Roy from the Computational Fluid Dynamics Lab at the University of Texas, Austin, who wrote the libMesh library, that I extensively used and also created a Debian package of. It was very influential to see the libMesh "from behind", also John and Roy are cool people (not mentioning the Debian tradition of having good relations with upstream:). Then I visited some professors at the same campus, after which I went into the Capitol and then I took the bus to the Barton Creek Square Mall to buy some ipods and jeans, so that I can say I have jeans from Texas. BTW, the ipod works excellent in Debian - I plugged it in and it just shows on my Gnome desktop. It's true that naively dragging mp3 files on it didn't make it play, but these instructions made it work.

On Thursday I fixed the remaining release blockers in SymPy and made a new release. In the evening, I am going to meet Aswin, he also uses SciPy and also is a friend of Kumar, who is now maintaining python-numpy and python-scipy Debian packages with me (Kumar also knows Prabhu, the author of Mayavi2 hosted at Enthought, so it's all connected).

Anyway, the whole workshop was an excellent experience for me. I learned a lot of new things and being able to speak with people who wrote tools that I use almost everyday is important. We also extensively discussed the future of all the projects (Sage, SciPy, NumPy, IPython, Cython, SymPy). See my summarizing email to the SymPy mailinglist.

Another thing, that I find very interesting is that Microsoft is financing the windows port of Sage, that will make basically anything that uses Python/Cython/C/Fortran very easy to install on windows (just a spkg package in sage). I find it really cool that MS is not only supporting but even financing a truly opensource project.

Finally the promised adventure in Atlanta: we took off the Prague airport on February 28th with a 2 hours delay (due to some paperwork as we were told by the captain). As I had 3 hours in Atlanta for the connection to Austin and I had to go through immigration, it was clear that I'll miss it. But I was not surprised, last time I was flying through Atlanta, they canceled my flight to LA completely. We arrived in Atlanta an hour and a half before my departure, then I was waiting for about an hour at immigration, it was incredibly slow. When I had around 20 min to departure, I had to ask people standing in front of me if they let me in, they were very nice and did. I was leaving immigration 10 min to my departure, then I was running to get my luggage and myself through customs and screening, it was 5 min to my departure when I ran down to the display with departure times. Then I was sprinting like hell to the terminal D to only see the clerk doing some final paperwork with all the people already boarded and the jetway door shut. After a little persuading he let me in too, fortunately there was still one seat left, so I made it. You can imagine my pleasant surprise in Austin when I discovered, that my luggage made it too, considering that I handed it to the Atlanta's airport personnel exactly 10 min prior the departure.

Update (3/3/2008): We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers. Here is my writeup of yesterdays Android Code Day in London. Eclipse 3.3 is needed to get the plugin working. Only eclipse 3.2 is in Debian unstable. Download the Europa release and re-setting up the plugin will do it. I’m no Eclipse fan boy, though the integrated debugger works. The iteration cycles are really short for trying stuff out. Very good. Developers, mainly from a Symbian background grilled Jason Chen over security and wanting C API access. Lot of people didn’t seem to like the idea that users were controlling security. I like Google’s “empowering the users” stance, though I think representatives from operators don’t. I heard that poor argument about users asking their operators for android support. Jason argued well that it’s up to user education to contact the right people. When a computer crashes in the UK, who do people call? VirginMedia? Please! :) How about Breakpad crash reporting on Android?. Jason used the OHA to defend Google from looking like they have all the political power… Hmmmm. :) I can understand the tight rope that Google are walking. They are trying not to fragment their platform before it’s properly released. OEMs, operators will feck it up if they have the chance to play with the source code before a Google co-ordinated release. Once they release Google claim they will release everything under the Apache 2 license. So I asked could we see Android on desktops? Jason said there is nothing stopping you. I hope not. Their opened fonts and multimedia codecs on desktop PCs could really make a big difference for Linux take up, especially in Asian (growth) markets. I have studied and implemented Asian fonts and Android’s font rendering even on that nightmare Website sina looked good to me. Despite the “Symbian developers” giving Jason hell in the beginning I had impression they actually liked Android. It fealt almost staged. Scary. Symbian C++ programmers learning Java and jumping ship! Same old problems with images. People are concerned about how bitmap images will scale on different target screens. There is four ‘skins’ already supported in the emulator (QVGA-L+P, HVGA-L+P). We need scalable images too on the Web. ;) Though there are some workarounds demonstrated which seemed OK to me. During the hackathon, I wanted to write a backup/sync tool. Since only Jason Chen seemed to know Android and there was a filled audience, I didn’t get to ask him how really to go about coding it. Though with the help of Dave from Zyb, we eventually found out about content providers. Took some debugging to find that out, but we got there. Having a working debugger is really really nice. We discovered we needed “android.permission.READ_CONTACTS” in the manifest to make our little application that read out the contact on stdout. Cool, though I’d rather use Javascript and the Web stack. Anyway, Android seemed like a good platform, but I have concerns. My biggest concern is basically where is Google Gears on Android? Jason could neither confirm or deny this, so perhaps they have it. Though gears is an opensource project and you can see code reviews… no Android mentioned. What happens if the Android platform is wildly successful? Then we are going to see two major platforms. The Android platform on mobiles and the Web platform on everything else. I worryingly saw no support for Web application device APIs on Android. Encouraging people to write for their Android/java-esque platform undermines their main Web platform! It’s like Microsoft’s mistake of undermining their own platform all over again. From Android you can use Webkit and the Web stack. But from the Web API stack you can’t seemingly access their Dalvik VM APIs. I disclose I am an employee of Aplix (opinions etc. are my own), also a OHA member. I am actively working on a plugin technology that exposes APIs as familiar JS APIs to Web developers. I have already done a proof of concept implementation of Google Gear’s Location API on mobile devices with Aplix technologies. Google you should really do the same and make Web applications equal citizens on your mobile platform by implementing Gears on Android (if you haven’t already).

I finally got tired of Achievo not remembering what projects I last used, so I whipped up a small greasemonkey script to do that. It just makes the selection sticky, nothing very fancy.

So, MadCoder had doubts about the crazy idea, so I took a little time to do a test with a package I maintain, namely, xulrunner. First, take all the deb files in the history of the package (at least, everything that is available on snapshot.debian.net today).

wget -O - -q http://snapshot.debian.net/archive/pool/x/xulrunner/binary-amd64/Packages.gz gzip -cd > list
awk '/^Filename:/ print $2 ' list xargs -I wget http://snapshot.debian.net/archive/

Next, commit all these in a different repo per package name :

perl -e 'use Dpkg::Version qw(vercmp); sub v my $f = $_[0]; $f =~ s/.*_(.*)_.*/$1/; $f print sort vercmp(v($a), v($b)); map s/^Filename: .*\///; $_ grep /^Filename:/ ;’ list while read f; do
    pkg=$ f%_*_*
    [ ! -d $pkg ] && mkdir $pkg && ( cd $pkg ; git init )
    cd $pkg
    ar -x ../$f
    mkdir data control
    tar -C data -zxf data.tar.gz
    tar -C control -zxf control.tar.gz
    git add data control
    git commit -q -m $f
    rm -rf data control data.tar.gz control.tar.gz debian-binary
    cd ..
done

Finally, evaluate sizes for each package, respectively, of all .deb files, their content imported in git (only the .git directory, including the index ; some space could be gained removing it), and the “optimized” git repository (after git gc, without modifying delta depth or window size, which may even improve the result)

awk '/^Package:/ print $2 ' list sort -u while read p; do
    du -c --si $ p _*.deb tail -1
    du -s --si $p
    cd $p; git gc ; cd ..
    echo
done 17M total
16M libmozjs0d
4.7M libmozjs0d 34M total
31M libmozjs0d-dbg
14M libmozjs0d-dbg 4.7M total
7.1M libnspr4-0d
1.3M libnspr4-0d 9.2M total
12M libnspr4-0d-dbg
2.8M libnspr4-0d-dbg 25M total
28M libnss3-0d
4.6M libnss3-0d 81M total
61M libnss3-0d-dbg
21M libnss3-0d-dbg 15M total
16M libnss3-tools
3.1M libnss3-tools 288M total
265M libxul0d
146M libxul0d 2.0G total
1.8G libxul0d-dbg
1.1G libxul0d-dbg 5.1M total
6.8M python-xpcom
1.1M python-xpcom 2.5M total
5.6M spidermonkey-bin
861k spidermonkey-bin 13M total
14M xulrunner
2.0M xulrunner 3.3M total
5.9M xulrunner-gnome-support
979k xulrunner-gnome-support


So these packages, stored in git, take between 15 and roughly 50 percent of the .deb size, which may be a nice improvement. Il would be interesting to know how these numbers evolve with time. Some files, such as the changelog.Debian.gz files, would also benefit from being stored in plain text instead of gzipped form. Note git gc took a while and a lot of memory for libxul0d-dbg. Also note these don’t include delta files that would be necessary to recreate the original .deb file, but this shouldn’t make a huge difference.

This is no doubt one of the best FOSDEMs, ever. At least to me it was, and I've been to every FOSDEM, and to the second day of the original OSDEM as well. Great weather, great people, great talks, and great fun. What more can one want? Where I had to nag about a few things yesterday, today I can only feel exhausted, but happy. Some loose ends:

1. Apparently someone forgot a camera in the Debian Developer's room; this is a Kodak EasyShare ZD710. If you're quick, you may be able to still get it at the info desk; otherwise, contact either me or "Chipzz" on the Freenode network (perhaps in the #fosdem channel). If you're still in Belgium, we may arrange for you to pick it up, otherwise we'll have to send it to you.
2. Thijs said it after the last talk in the Debian devroom, but let me repeat it here: if you have comments about the Debian presence at FOSDEM (and I mean about any subject, really), just let me know. This was a great FOSDEM already, but there's always room for improvement. Oh, and yes, we need a bigger devroom, and the FOSDEM people know this, and they can't really help us but they'll do what they can. Unfortunately "too many people" is a general problem at FOSDEM.

See you next year!

This weekend, like past years, I'm off to the Free and Open Source Developers European Meeting in Brussel(s), joining Jeroen and Joost in our friend Geert's car. I recently leared that Belgium is the only seaside country that doesn't have an island. If that information is not worthy of a blog entry then I don't know what is. As you can see I'm certified to attend:

This January I've put some research (together with Dick) into the security of electronic waste registration techniques. About 25% of Dutch municipalities employ some kind of tariff differentiation ("diftar"): a household pays per quantity of waste. A traditional way of implementing this is to use coloured, taxed garbage bags, but more modern municipalities employ bins with RFID tags or underground containers which can be opened with (again) RFID cards. These underground containers then communicate their records of disposals to the central office. We visited a number of municipalities around the country, scanned ID cards and containers and even tooka ride on a garbage truck. Some highlights of our findings:

• Most access cards for underground containers can be trivially cloned; they are EM4x05 type cards with factory UNIQUE.
• In one municipality, we could open the underground containers with any card of the EM4x05 type, regardless of origin. With one notable exception: 0x0 doesn't work.
• One type of tag has preventive measures against readout (and hence cloning), but these features are not used.
• Virtually no encryption is used in any of the communications, e.g. plain HTTP was used for worldwide access to the adminsitrative backend interface. Again one exception: a new version of a system used WEP to "secure" wireless transfer of data...
• There's no security awareness among municipalities. Defined requirements concern the physical robustness of systems or collection costs, but no demands are placed on information integrity or confidentiality.

We saw many different systems with each having their own flaws. It would be better if municipalities joined forces and designed one or two good systems instead of a dozen half-baked ones. These public systems funded with public money should then have a similarly public security evaluation.

Today while reading Planet Webtuesday, I stumbled upon a nice cartoon about the one and only measurement of code quality: WTF per minute. Somehow I noticed that the blog in which this cartoon was posted in is powered by Blojsom, a Blosxom derivative written in Java (and nowadays database powered). I already have heard of a lot of blogging software which works similar to Blosxom and often is also named similar, e.g. Pyblosxom or Blosxonomy, but Blosjom hasn’t been noticed by yet although it is mentioned in Children of Blosxom where I first noticed Blosxonomy. So far, so good, but what really surprised me is that a blog engine developed after Blosxom’s ideas officially made into MacOS X 10.4 Server. (BTW at a time, I neither had a blog nor knew about Blosxom. :-)

Colin, you might want to check out PyPy, especially it’s translation framework, which (as I read it) allows the separation of language definition, optimisation techniques and machine backends (virtual or not). It looks like right now you can translate Python to C, CLR, JVM, LLVM or even JavaScript and there seem to be people working on different language definitions also, with JavaScript, Prolog, Scheme and Smalltalk in the tree.

According to a notification of trade on the Oslo B rs market, Nokia has made an offer for Trolltech of about 843 million Norwegian kroner , around 104 million. What this could mean for GTK+ is anyone’s guess. I’d expect at least that Nokia’s competitors that use Qtopia (like Motorola, Panasonic and Sony) are probably a little worried at the moment. Maybe there’ll be impetus for OSSO to move over to Qt, or maybe there’ll be internal competion at Nokia between a Qtopia stack and a GTK+/X11/Freedesktop stack. Maybe Qt will become more closed as Nokias pushes its advantage, or maybe it’ll be more open as development becomes less dependant on non-GPL license revenues, or maybe it’ll just stay the same. An interesting left-field move in this space is OpenMoko moving over to EFL, but on a primarily GNOME/Freedesktop stack. EFL is certainly much more capable than GTK+ in producing flashy UI’s on limited hardware. I”ve also heard of some companies writing UI’s in Flash using Gnash. I also wouldn’t be suprised if we start seeing embedded hardware running Mono and Moonlight at some point. Maybe one day we’ll have a GTK3 with DOM-like two pass event system and a cairo backend that renders totally on the GPU. One thing’s for certain, there’s a hell of a lot of competition on the toolkit front and it will only grow.