MeeGo (Nokia/Intel): Openness does not seem to be very important for Nokia and Intel. They develop their stuff behind closed doors and then do a large code drop (once dropped, stuff gets developed in the open). In terms of professionality, it does not look much better: If you look at the meego-dev mailing list, you feel like you are in some kind of a kindergarten for open source developers Things like HTML emails and top-posting appear to be completely normal for them, they don t even follow the basic rules for emails and they also appear to ignore any advice on this topic. Oh, and writing a platform in GTK+ while pushing Qt as the supported toolset is not a good idea. Android (Google): The situation with Android appears to be even worse. Google keeps an internal development tree and the only time the public sees changes is when a new release is coming and Google does a new code drop. Such a behavior is not acceptable. Ubuntu (Canonical): Canonical does an outstanding job on openness. Canonical employees develop their software completely in the open, and there are no big code drops. They basically have no competitive advantage and allow you to use their work for your own project before they use it themselves. Canonical employees basically behave like normal free software developers doing stuff in his free time, the only exception being that they are paid for it. Most Canonical employees also know how to behave on mailing lists and do not post HTML emails or do top-posting. There are of course also other people: The design process of the Ubuntu font on the other hand is a disaster, with the font being created using proprietary software running on Windows; for a free software company, that s not acceptable (such persons should probably not be hired at all). Furthermore, the quality of Ubuntu packages is often bad when compared to the quality of a Debian package (especially in terms of API documentation of Canonical-created software); a result of vastly different development cycles and different priorities. On a scale from 0 to 15 (15 being the best), Nokia/Intel receive 5 points ( D in U.S. grades), Google receives 3 points ( F in U.S. grades), and Canonical receives 12 points ( B in U.S. grades). Please note that those grades only apply for the named projects, the companies may behave better or worse in other projects. Final tips for the companies:

• Nokia/Intel: Teach your employees how to behave in email discussions.
• Nokia/Intel/Google: Don t do big code drops, develop in the open. If someone else can create something awesome using your work before you can, you are on the right way. Competitive Advantage must not exist.
• Canonical: Fire those who used Windows to create the Ubuntu font and restart using free tools.
• All: Document your code.

Filed under: General, Ubuntu

The unofficial rc bug tracker currently knows about the following bugs:

In Total:	501
Affecting Squeeze:	401
Squeeze only:	95
Remaining to be fixed in Squeeze:	306

Of these 306 bugs, the following tags are set:

Pending in Squeeze:	16
Patched in Squeeze:	49
Duplicates in Squeeze:	38
Contrib or non-free in Squeeze:	12
Claimed in Squeeze:	5
Delayed in Squeeze:	6
Can fixed in a security Update:	35
Otherwise fixed in Squeeze:	33

Ignoring all the above (multiple tags possible), 163 bugs need to be fixed by Debian Contributers to get Debian 6.0 Squeeze released. However, the with the view of the Release Managers, 310 need to be dealt with for the release to happen. Please see my older post for an explanation of the different numbers.

Since my last post about available LDAP tools in Debian, I was told about a LDAP GUI that is even better than luma. The java application jXplorer is claimed to be capable of moving LDAP objects and subtrees using drag-and-drop, and can authenticate using Kerberos. I have only tested the Kerberos authentication, but do not have a LDAP setup allowing me to rewrite LDAP with my test user yet. It is available in Debian testing and unstable at the moment. The only problem I have with it is how it handle errors. If something go wrong, its non-intuitive behaviour require me to go through some query work list and remove the failing query. Nothing big, but very annoying.

Request Tracker (also know as RT), the defacto Open Source ticket tracking software, has a special status value to get rid of spam tickets: deleted. It does exactly what it's supposed to do, that is get rid of these tickets quickly.

Unfortunately, it's very easy to accidentally delete a bunch of non-spam tickets via the bulk update interface. Restoring these deleted tickets is not straightforward.

Good news: none of the lost tickets were removed from the database.
Bad news: you can't search for deleted tickets.

Finding the lost ticketsIf you have a copy of the page before you did the bulk update (perhaps in your browser cache?) then you've got all you need. Otherwise, you'll need to access the database directly to get a list of ticket IDs.

First of all, find the user ID of the person who marked of all these tickets as deleted (42 in this example), then issue the following query:

 SELECT id, lastupdated, subject
 FROM tickets
WHERE status = 'deleted' AND
      lastupdatedby = 42
ORDER BY lastupdated;

You may want to filter some more using the lastupdated timestamp if you know roughly when the deletion occurred.

Restoring deleted ticketsSince all of the tickets are still in the database, all you need to do is to go to each of them directly (e.g. http://www.example.com/Ticket/Display.html?id=12345 for Ticket #12345) and change the status back to "open".

Request Tracker is a really neat support tool, but one of the common complaints I heard from people using it during a previous project was that it was pretty slow.

There wasn't much we could do about the (overloaded) server it was running on, but I found that enabling mod_deflate really helped.

After watching this great video though, I was inspired to look into it a bit more, focussing this time on latency.

Description of tests

• RT 3.6.7-5+lenny4
• Running on a Debian Lenny vserser.
• Server is on the LAN.
• Firefox 3.6.6 client (with Firebug 1.5.0)

Also note that I was looking for the "best case" for each of the different configurations and so each screenshot was taken after reloading the homepage 10-20 times to maximize cache hits (thanks in large part to mod_expires).

(Is there a nice automated way of measuring average latency?)

Stock RT 3.6Using the default apache2-modperl2 config file (as supplied by RT), here's what the homepage (logged in as root) looked like before I changed anything:



The purple section here indicates the time spent waiting for the server. This shows that the server (running Mason inside mod_perl) is doing quite a bit of processing, including a lot more work than you'd expect while serving static files. It's quite impressive to see how fast the images are being served (directly by Apache) in comparison with the Javascript and the CSS files (which go through Mason).

The reason while Javascript and CSS files have to be served by mod_perl is that they are in fact templates. They contain a few Mason variables which must be substituted before being served.

Looking into it further though, all of these replacements have to do with variables defined in RT_SiteConfig.pm (mostly the install path). Here's an example:

var path = "" ? "" : "/";

which gets turned into:

var path = "/rt" ? "/rt" : "/";

So as long as these paths don't change, then there is no need to re-generate these files.

Static Javascript and CSSThis next diagram was produced after configuring Apache to serve all Javascript and CSS files directly from Apache:



The way I did that (without modifying any of the original files) was by saving the Javascript/CSS sent to the browser and using mod_rewrite rules to serve these files instead of the original templated ones:

# Serve static files directly
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/ahah.js$ /var/www/rt/ahah.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/cascaded.js$ /var/www/rt/cascaded.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/class.js$ /var/www/rt/class.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/combobox.js$ /var/www/rt/combobox.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/list.js$ /var/www/rt/list.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/titlebox-state.js$ /var/www/rt/titlebox-state.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/js/util.js$ /var/www/rt/util.js
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/css/3.5-default/main-squished.css$ /var/www/rt/main-squished.css
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/css/print.css$ /var/www/rt/print.css
RewriteRule ^/usr/share/request-tracker3.6/html/NoAuth/webrtfm.css$ /var/www/rt/webrtfm.css

Removing unnecessary images

Finally, one thing I noticed from this last graph is that the rounded corners in the theme require a number of small images. While these don't take a whole lot of bandwidth, they do require quite a bit of back and forth between the browser and the server.

So I replaced all of the "rounded corner" images in the main-squished.css file with the following CSS attributes:

-moz-border-radius-topleft: 8px;
-moz-border-radius-topright: 8px;
-moz-border-radius-bottomleft: 8px;
-moz-border-radius-bottomright: 8px;
-webkit-border-top-left-radius: 8px;
-webkit-border-top-right-radius: 8px;
-webkit-border-bottom-left-radius: 8px;
-webkit-border-bottom-right-radius: 8px;

(yes, Internet Explorer users probably don't get the rounded corners... oh well)

This eliminated a number of roundtrips and shaved off a few more milliseconds:



Merging CSS and Javascript filesBy this stage, the pages are pretty snappy so there is not much to be gained anymore, but I figured I'd try to reduce the latency a bit more by combining all Javascript files into one (and doing the same for CSS files with the exception of print.css). This is what I got:



(Note that I also took the opportunity to minify both squished files to reduce the filesize.)

Not a huge improvement and I unfortunately had to copy quite a few Mason templates from /usr/share/request-tracker3.6/html/ to /usr/local/share/request-tracker3.6/html/ and then replace all of the script tags with a single one in html/Elements/Header.

Others things to look intoI've stopped here, but there might be ways to further reduce the processing time on the server (hence the latency) by tuning mod_perl/Mason or Postgres. The RT wiki also has a few pointers.

Replacing Apache with Nginx (which means moving to FastCGI) was something I considered, but after trying it out, it turned out that it would add about 100ms of extra latency.

Feel free to leave a comment if you've found something else that makes a big difference on your site.

The cloth is woven, so the tailors are busy collecting measurements. If you've ordered a kilt or whatever, and have not yet sent in your dimensions & money you need to do that within about 24 hours if you're hoping to get something in time for DebConf.We seem to have got about 20 yards more than we ordered (weaving's more of an art than a science) so if you've only just realised that you want a kilt, skirt, whatever, in glorious Debian Tartan, I suggest you get in touch promptly, as even if you don't want it in time for DebConf, I imagine the rest will get snapped up as soon as people see what they've been missing in New York.I'm getting some Ties made -- they'll cost about 25.00 GBP each. If you fancy one, tell me, and add yourself to this table on the wiki. There's more background on that page.

1.5.x branch

This is the branch of Cupt I intend to put into Squeeze, I fix rare bugs from time to time there. Today I uploaded the version with the support of the architecture wildcards in source packages, defined in recently released Debian Policy 3.9.0.

2.0 branch
In the same time, I started a rewrite of the whole thing to C++ to make Cupt not only (as possible) feature-rich and bug-free, but also fast, following the example of Git DVCS. I have a significant chance to finish this task before Squeeze+1 release.

Bug-Squashing-Party in Munich We are organizing another BSP in Munich on the weekend of 17th/18th July. Like the last BSP, it will take place in the LiMux office in the city center. See the coordination page for further information and directions and in order to sign up for it. Food and drinks for the event are partly sponsored by the City of Munich and this amount (100 ) has been again matched by credativ GmbH. Contributions by non-DDs are welcome as always; the BSP will be attended by several Debian Developers who will be able to upload fixes. Attending BSPs is a great way to get involved in the Debian community! We cannot guarantee crash space to people from outside Munich at this point, so if you want to attend please contact the Munich list (area-muc@teams.debian.net) beforehand or arrange your own accomodation. We probably start the BSP at some point after 6PM on Friday evening already, but the main action will be on Saturday and Sunday. As usual, people should bring their notebooks and possibly an ethernet cable. Wireless will be present as well, but a certain bandwidth cannot be guaranteed. Bug-Squashing Introduction I also plan to give an introduction to bug-squashing at this month's Garching Debian Stammtisch, which will take place next Wednesday, July 14th in the campus-cneipe (or its beergarden) as usual (the monthly Stammtisch is always on the second Wednesday of the month). If you study/work in Garching and would like to attend the BSP, come to the Stammtisch for a tutorial (and beer)! Debian Packaging Tutorial Some time ago, I gave a tutorial on Debian packaging in the TechTalk series of the Open-Source- School. The audience seemed to be pleased with the talk, and as more people requested to attend than there were seats in the room, we decided to reprise the event on September 7th. Attendence is free, but you have to register (see the event page). There are still some places left at this point.

So there are times that I think of course anyone remotely interested in Free Software, virtual projects, and similar endeavors knows about Debian and its strange rituals. I am pretty mistaken, actually. Recently I have attended various events where it has been made clear to me that there are hordes of folks interested in the politics of openness, access, and free software who have heard about Debian but don t really know what it takes, socially and politically, to manage such a project. Luckily I had the chance to spread some of the esoteric knowledge during a talk at MIT for the Knight News Challenge winners and I have received many emails, excited and some surprised about the governance structures of Debian. If interested, here is a video of my talk, which is quite short, so I don t go into as much detail as I would like. There is a great audio quote from a Debian developer, taken from this class visit for which there is a podcast and which I recommend as well. If you can t play flash, you can download the a video of the talk here (look at the right hand side of the page for download link). update: Interesting blog post on Why the open source way trumps the crowdsourcing way that explores some of the issues I raise in the panel talk. I don t think it always trumps open source but it is certainly a niche form of production that is useful in some cases but all too often confused with expert peer production in quite unproductive and empirically wrong ways.

So there are times that I think of course anyone remotely interested in Free Software, virtual projects, and similar endeavors knows about Debian and its strange rituals. I am pretty mistaken, actually. Recently I have attended various events where it has been made clear to me that there are hordes of folks interested in the politics of openness, access, and free software who have heard about Debian but don t really know what it takes, socially and politically, to manage such a project. Luckily I had the chance to spread some of the esoteric knowledge during a talk at MIT for the Knight News Challenge winners and I have received many emails, excited and some surprised about the governance structures of Debian. If interested, here is a video of my talk, which is quite short, so I don t go into as much detail as I would like. There is a great audio quote from a Debian developer, taken from this class visit for which there is a podcast and which I recommend as well. If you can t play flash, you can download the a video of the talk here (look at the right hand side of the page for download link). update: Interesting blog post on Why the open source way trumps the crowdsourcing way that explores some of the issues I raise in the panel talk. I don t think it always trumps open source but it is certainly a niche form of production that is useful in some cases but all too often confused with expert peer production in quite unproductive and empirically wrong ways.

Songs: * Affirmation (Jose Feliciano)
* Breezin (Bob Woomack)
* Phase dance (Pat Metheny)
* gua de beber (Tom Jobim / Vinicius de Morais)
* Marina (Dorival Caymi)
* Samba de Orly (V. de Morais / Chico Buarque / Toquinho)
* de manh (Caetano Veloso)
* Cora o leviano (Paulinho da Viola)
* Pecado capital (Paulinho da Viola)
* Folhetim (Chico Buarque)
* com esse que eu vou (Pedro Caetano)
* libi (Djavan)
* Capim (Djavan) Thanks to friends who came out to hear us // #fun

Currently I own and use an iPhone 3G. I bought it almost two years ago, when the local phone provider LMT started offering the iPhone legally. I had a pretty good experience with it most of the time, but now it is showing its age:

• The two year warranty will run out in September
• The iOS 4 update left out most of the new features my model cann t have multitasking or backgrounds or any of that new cool stuff that is exclusive to the new iPhone 4
• The hardware itself is starting to wear the speaker stopped working a few weeks ago (so I have to use the loudspeaker function or headphones) and also approximately around that time the phone stated to randomly lock up approximately one a week or two it freezes and after a few minutes reboots and demads to be connected to iTunes and restored from backup
• Also the battery does not last as long as it used to

I will try to send my iPhone in for repair hoping to extend its usefulness, but frankly it looks that I might have to get a new phone at or before Debconf. So I am considering my options for a new phone and so far I have 3 main options each with some sub-options. The main options are: iPhone 4, MeeGo and Android. Each choice has its benefits and drawbacks and each also has several sub-options related either to specific phone models or to purchase methods. What I need is a phone with: calling function, contact information synchronised to Google, support for Google Mail/Contacts/Calendar simultaneously with one Exchange account also providing mail/contacts/calendars, music, audiobooks saving my place in the audio book and in the list of books, fully featured Twitter client with Twitpic and location support, encrypted password storage application (preferably open source), GPS with maps, ability to download maps for offline use, Geocaching support with offline cache info and logging, Skype client, ability to write in Latvian, English and Russian in all applications, reliable backup and restore of phones data including settings and data of installed apps. Optional features: last.fm streaming and reporting support, ebook applications with purchasable ebooks, high quality video and photo recording (for a phone), ability for me to write applications on the phone, ssh client, wireless data upload to the phone, ability to change the phones battery without loosing data in the phone (on the go), compass, physical keyboard, confidence in getting software upgrades and developer interest for the next 2 years. I ll try to describe all of the options here to organise my thoughts and maybe also help someone else make the choice. Option 1: iPhone 4 To get the iPhone 4 I have two options: LMT and unlocked. The official arrival of iPhone 4 to Latvia is expected in September and it will likely be sold by LMT for the same prices as iPhone 3GS is now. If I choose this scenario, I will need to survive with my semi-broken iPhone for 2-3 more months. Total price over 2 years (LVL): 131 (purchase price) + 24 * 8 (surcharge) = 323 LVL. Note: the surcharge is the extra cost of the iPhone call plan compared to a comparable regular plan (Vien dais 7 + Internets telefon 5). If I go and purchase an unlocked iPhone 4 in a country where such units are sold (UK is the most easily accessible choice, because a few of my workmates travel weekly to and from UK) then the total price over 2 years would be the purchase price: 499 GBP + 65 GBP (2 year warranty extension) = 505 LVL Now lets go over the general benefits and downsides of the iPhone 4, first the positives:

• It is a simple to use device that I am used to over the two years
• The screen resolution is higher than any other option
• It is smaller and lighter than Nokia N900 and the bigger Android devices
• There is a huge number of free and paid apps as well as accessories for the iPhone docks, headphones, chargers,
• I know that it can do every thing that I need it to do (with apps) and most of the optional features too, except (see drawbacks)

Drawbacks:

• The first thing that I hate about the iPhone is its umbilical cord like link to iTunes. iTunes is the sole purpose I still have a real Windows installation on my main computer (in a Sun VirtualBox, thankfully). iTunes is slow, clumsy and generally unusable piece of dog excrements. It can only do one thing at a time, mostly: if you are adding a folder to your library, you can t switch to another tab and see how the backup of your iPhone is going. The actions do happen in the background, but more often than not you cann t switch away from some actions. If you try to do multiple things in parallel, instead of resolving any process conflicts and queueing the actions iTunes will simply silently fails to do something, often leaving remains of the half-finished actions. It also does not bother to check if the backup or restore of the phone is complete before using it in this way I have many time gotten into a situation where I connect the iPhone to the iTunes, it starts backing it up, then crashes and next time happily offers this half-done backup copy as a valid restore point. Or it crashes during restore and only writes some files and settings to the phone other settings stay at their default values. It is also very cryptic, for example if you have a lot of music it can take hours to import it into iTunes (it spent 2 hours Analysing gapless playback information of 5000 songs) and then you will be puzzled about how to put some of that on the iPhone. If you just tick the checkbox to sync your music you ll get an error stating that there is not enough free space, which is not very helpful. The magic combination was to check Manually manage music and then go to music tab and choose Autofill option. At that point iTunes will spend half an hour choosing which songs to put on the phone, before it even starts copying. And god forbid that you would use that AppStore application on the iPhone to actually install apps sooner or later you will run into a backup bug where creating or restoring a backup of your iPhone might take 2-3 hours instead of more normal 5-15 minutes. Only a factory reset of the phone followed by selective reinstallation of applications (loosing all their settings in the process) can work around this bug currently.
• The closed nature of the iPhone means that I cann t install unapproved software unless I jailbreak the phone and even then it is rather problematic to develop for the phone unless you have a Mac and shell out 99$ a year for participation in the developers program
• The iPhone is a consumption device and not a productivity device. I would like to have a device on which I could be creative as a software developer as well

Option 2: Maemo/MeeGo Some of my colleagues at work (in the Riga office of Accenture) have N900 phones and I have been exposed to people with raw enthusiasm towards the Maemo platform ever since the Debconf in Helsinki, where we saw the first N700 devices in the hands of some lucky Debian/Nokia people using it as an Internet tablet. N900 has been a strong leap forward for the platform, before its head was teleported sideways by the whole MeeGo merger/debackle. Again I have two options here: Get a N900 either here in Latvia for 325 LVL (that would be the total cost over 2 years) or get it from USA during Debconf for 399 USD (+129 USD for 2 year warranty) = 317 LVL. And additional option would be to wait until October/November and then buy the new Nokia MeeGo device, rumoured to be N9-00 and likely to be around the same price as N900 was when it was introduced (around 500 LVL). Benefits:

• A fully open and rooted Debian Linux based device with apt-get, X, pusleaudio, d-bus and Qt as core technologies
• I can install software from anyone and can also write my own software either in Qt/C++ or even in Python
• There is (or was) a significant hacker community that develops applications for N900
• As far as I know most of the features that I need do work on N900, but I am unsure about:
  1. audiobook support how easy it is to put a MP3 on the device and tell it is an audiobbok so that the device would remember position when playing the file and save it even if the player is stopped and the device is rebooted or backed up and restored from backup?
  2. can I have Google Mail, Contacts and Calendar and at the same time also have an Exchange account with mail and contacts and calendar active?
  3. how is the Geocaching.com support is there an app already that makes it easy to geocache while offline?
  4. Multilingual keyboards I ve seen people having to reimplement the on-screen keyboard in their programs, and naturally they do not bother to add support for all language. So support for multilingual keyboard input is an open one.

Drawbacks:

• All the uncertainties above while I could write all the above software, it would be better if I would not have to, so that I could focus on something more productive
• Also the whole position of Nokia on the MeeGo support on the N900 is kinda backwards. I am now used to the Apple way that if I get a device, then it will get software updates for at least next two years and will get the new software features developed in the next two years at least. If Nokia would have said All phone-oriented MeeGo releases will have a version for N900 until at least the end of 2012. Then this drawback would not have been there, but currently it is a mayor sticking stone for me. I don t want to buy a device that will be on a dead-end software platform that will die before the end of this year.
• N900 is the largest and heaviest of all the options

Option 3 Android After looking trough the options for Android phones, I ve narrowed the selection to the ones that are either available from local carriers or can be easily gotten unlocked also the phones need to have announced plans to have at least Android 2.2 version. Currently the choice is limited to HTC Desire (from carrier or unlocked) and Samsung Galaxy S (unlocked). The prices over 2 years break down as follows: HTC Desire (locked to LMT): 69 + 9*24 = 285 LVL
HTC Desire (locked to Bite): 199 + 2*24 = 247 LVL (Note: only 500Mb of data per month available)
HTC Desire (locked to Tele2): 179 + 6*24 = 323 LVL
Note: all the above options would also require me to pay a 45 LVL early termination fee on my current iPhone contract if I choose to do this before September.
HTC Desire (unlocked): 311 LVL
Samsung Galaxy S (unlocked): 350 LVL (import from Germany) Benefits:

• As far as I could find, the features I need are out there in one way or another there usually is an app for that!
• Google looks poised to continue development at a rapid pace
• There is an active hacker community and also an active commercial software community that offers cool applications for a few bucks
• As far as I understand the phone backups onto itself a backup of the phone is created onto a SD card in the phone and you can then copy that off the phone for permanent backup, it is a nice concept
• There are literally thousands of sources for Android applications: from the official Market to Google Code to individual web pages and forums
• The hardware looks solid, powerful and generic enough to last for a couple of years
• It is likely that knowing how to program Android app will be useful for me at work
• It is cheap and simple to start writing Android apps on Linux

Drawbacks:

• Typical usability of Android apps is pretty low compared to iPhone
• The Android environment is very unique and is not like anything else it s not really much of a Linux system from an apps perspective
• I would be relying on HTC to provide OS updates in a timely manner it is quite likely that after a year or so the updates to new version will come slowly or even stop altogether and I will have to use hacked ROMs
• I have a dislike for Java. I wish one could write fully featured Android apps in Python

Please correct me if I am wrong with something!!! And also it would be cool if you expressed your own opinions in the comments. Currently I am very undecided about what I am going to do, but after completing this entry I am leaning towards an unlocked HTC Desire. Update:
Olivier Cr te shares a N900 vs. Nexus One experience Edit 01-07-2010: Handed my iPhone in for a warranty repair, got a dumbphone Nokia as a loaner during repairs. Very surprised about how long a battery can last on a low powered and cheap phone. In the mean time from all the comments here and elsewhere I am starting to see that I am too annoyed with the iPhone platform (mostly iTunes) to stay there and that I am also not convinced in the direction MeeGo is going (a lot of community developers are annoyed and are jumping ship), so N900 is also out. I will need to see 2-3 MeeGo smartphones and also see how Nokia will treat their smartphone users and developers on this platform, in the long term, before I ll be ready to trust them with my money. Therefore, my choice is becoming pretty clear look for the best Android phone (after my iPhone dies). We have this thing at Accenture, where we can get company phones at a discount and HTC Desire is on that list. If I can get that, it would slash 100 LVL (almost a third of the price!) off it, but to get there I either need to get a promotion (rather rare after just one year with the company) or prove the necessity of the phone for the needs of my project (kinda hard currently). Well, the situation will be a bit clearer next week when I get my iPhone back. (Apparently the Latvia s largest holiday Midsummer Festivities or J i/L go with tons of traditional outdoor activities, caused a lot of phones to become broken and there is a backlog of warranty service ) So at this point my plan is: get my iPhone repaired and get a promotion or a project where I can justify a company-paid HTC Desire and then hope that Nokia/Intel really get their stuff together and make MeeGo a great smartphone platform over the next year or two. Update: Got my iPhone 3G back from the warranty . It is in quotes because they just gave me a new iPhone 3G. The battery lasts for 3 days of minimal use and it has not crashed yet. The recovery process was a pain again caused by iTunes: iTunes refused to restore my backup onto the new phone, because my backup was made on a iOS 4.0, while the new phone I got from the warranty has 3.1.3 on it. So I had to set this phone as a new phone, initialise it, make a backup, upgrade to 4.0, restore from the (empty) backup, then reset the phone to factory settings again and only then I could start restoring data from my original (pre-warranty) backup and start copying my data on to the device. All in all it took nearly 3 hours if iTunes doing something and almost a dozen reboots of the phone. Almost half of that time was spent doing completely unnecessary steps to work around the fact that iTunes is braindead. I ll continue using my iPhone for now, keeping my eyes on the newest Android phones and also waiting for the long-promised first MeeGo phone from Nokia.

check-deps.sh
Phil Hands and I devised a little script which is currently packaged as part of multistrap to check the dependencies of a .deb package before installing it - called check-deps.sh and can be found at /usr/share/multistrap/check-deps.sh. I just thought I'd publicise it a bit because it can help with one of my common test cases - when a binary package changes dependencies but you haven't uploaded it yet.

check-deps.sh takes a .deb to the command line -f --file option and outputs the dependencies of that .deb and whether those dependencies (at the requested versions) exist in your apt-cache policy. Optionally, you can use check-deps.sh to also then install those dependencies (not the dependencies that would come from the current version in the repository) and the package itself.

I've found this to be a much more friendly way of satisfying runtime dependencies of a package. Where things like pbuilder would just force install the .deb and then get apt-get -f install to try and fix things, check-deps.sh will fail if the required dependencies are not available in the first place.

The benefits are two-fold. First you get to see the full list and you can easily see if your work to drop a dependency has just resulted in another package bringing that dependency back in etc. Secondly, you can test whether your .deb is installable without breaking your system and then having to remove it - e.g. against backports or a Debian derivative test chroot. It should be possible to extend the script to read Build-Depends but that means reading the input from the source package, not the built binary. Might be just as easy to have a second script for Build-Depends.

(Comments are still disabled due to spammers and time-wasters, but if you would like to see check-deps.sh more widely used or extended it isn't that hard to find my email address at debian.org.)

xapt
Another new perl script, this time using the multistrap and apt-grip core to replace the apt-cross breakage to install cross-dependencies of a Debian source package. xapt has very few dependencies (dpkg-dev, dpkg-cross, apt, perl) and very simple logic. It doesn't try to second-guess which packages to use as dependencies of cross packages, it just gets them all. As such, it still isn't the tool we need for optimal cross-dependency resolution, but then neither is apt-cross - come to that, Multiarch or sysroot aren't going to provide the right tool any time soon either. So xapt at least gets over the worst of the design problems in apt-cross (by not using the apt perl bindings mainly) and seems to just work within clean chroots which is where apt-cross has the most problems.

xapt will be a new binary package, so it will need to go through NEW but I'm looking at using it as part of pdebuild-cross because it is faster than apt-cross and seems to work much more efficiently than apt-cross inside a clean chroot. xapt does not care about multiarch or sysroot, it just gets the packages and passes them to dpkg-cross. Normally, xapt cleans up after itself but you can choose to leave the built packages in /var/lib/xapt/output if that is useful.

Last weekend (2010-07-02 2010-07-04) nine people met at the FAI developer workshop at Linuxhotel in Essen/Germany. If you can t remember: FAI is a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large-scale infrastructures and clusters. The participants of the FAI meeting: second row from left to right: Michael Goetze, Michael Prokop, Andreas Schuldei
first row from left to right: Sebastian Hetze, Manuel Hachtkemper, Thomas Lange, Mattias Jansson
missing on the picture: Thomas Neumann (left on sunday midday) and Stephan Hermann (only part-time) Friday afternoon started with getting to know each other, continuing with discussions all around FAI. On saturday we started to hack on FAI. Between the hack sessions and discussions the attending people presented their FAI usage and approaches. Some notes from the presentations:

---

FAI Manager webfrontend / Stephan Hermann Stephan \sh Hermann presented his FAI web frontend which should be released under the GPL license in those days. The frontend uses qooxdoo whereas the backend is based on django, rpc4django and python-tftpy. A demo video is available at blip.tv. Currently Stephan is searching for a nice name for his FAI management tool please send suggestions either to him or to the linux-fai-devel mailinglist. Grml / Michael Prokop Grml is a Debian based Linux live system specially made for system administrators. Grml uses grml-live for building the ISOs, whereas grml-live itself uses FAI s dirinstall feature to build the live system. This provides the Grml team with a nice way to autobuild 18 ISOs per day, known as daily.grml.org. Mika also presented Grml s netscript bootoption and the ethdevice bootoption of live-initramfs which is useful for booting Grml/FAI via PXE. Host Europe / Michael Goetze Host Europe uses FAI for installing Debian and Ubuntu (32+64 bit) in the support center. They have ~20 FAI classes and use a Debian lenny NFSROOT as base for all deployed systems. Their main problems with FAI aren t related to FAI itself, but instead e.g. broadcom NICs with lack of support for it in Lenny s kernel. They are not using softupdate (yet) and currently use Kickstart for deploying CentOS but are working on deploying CentOS with FAI as well. LIS AG / Sebastian Hetze Linux Information Systems AG (LIS AG) are using FAI 3.2.17 and provide a luma and PyQt based GUI to their customers. They use DHCP, LDAP and DDNS for inventory, configuration and deployment. Mathematical Institute of the University of Bonn / Manuel Hachtkemper The Mathematical Institute of the University of Bonn uses FAI 3.1.8 and 3.3.5 for managing ~150 systems. They are automatically running softupdates every day, reporting how many hosts actually did run the softupdate and how many didn t run. The involved failogwatch tool supports two regex files, one for excluding specific hosts and the other one for grepping for known problems in the logs. Spotify / Andreas Schuldei + Mattias Jansson Spotify is a peer-to-peer music streaming service and the operating people at Spotify use FAI for deploying the systems. Currently they are using FAI 3.3.3 to deploy ~400 bare metal machines and ~150 virtualised machines. They have their class names in DNS using the txt/Text record entry. They are using a self written prepend_class script to manage dependencies between classes. University K ln / Thomas Lange Thomas uses FAI s trunk version (of course ), managing ~25 machines with less than 20 FAI classes. He s not using softupdates as Lenny s aptitude ignores the hold status of packages (this bug should be fixed for Squeeze). $COMPANY One of the big telecommunication providers in Germany uses FAI 3.3.3 for installing their bare-metal and virtual servers, providing Debian, Ubuntu and SLES. They are using Debian NFSROOT as a base for all systems as well and their main problems with FAI wasn t FAI itself but how to manage installation of virtual machines.

---

On Saturday evening we had a nice barbecue which included beer and K lsch *d&r*. On Sunday we continued with discussions and development. Our work-log of the weekend:

• identified important packages for the Debian/squeeze release
• discussed features that should be available (important packages and bugreports, missing features, )
• fixed several bugs (wrong exit codes, error handling, variable handling, )
• discussed FAI packaging for Ubuntu (packages for lucid are available at ppa at launchpad)
• implemented support for grub2 in fai-cd (will be merged soon)
• implemented initial support for retrieving sources with FAI (available in svn s trunk)

Important decisions made:

• next major release will have version number 4.x
• we want to continue to provide a stable version 3.x (no new features, just bugfixes and maintenance) side-by-side with version 4.x
• deprecated setup-harddisk will be dropped, setup-storage is well established, works fine and is properly maintained by FAI developer Michael Tautschnig (who sadly couldn t attend the FAI developer meeting)
• a FAQ section will be created on the FAI homepage

We noticed that many FAI users implement their own way how to handle dependency management between classes, we will re-consider how we could provide such a mechanism through FAI s core. We also noted that it s important that any self-written scripts used within FAI are fully idempotent and users should be aware of this. Last but not least many thanks to the sponsors of the FAI developer workshop 07/2010! The workshop wouldn t have been possible without our generous sponsors, namely being:

• Debian
• Linuxhotel
• Linux Information Systems AG
• Netways
• Spotify
• Thomas-Krenn.AG

My project. This post assumes that the reader has read my last post. I m posting this weekly report earlier this week because there are too many things to tell already. I ve found the reason behind the segfault I m looking for so much time. The last problem, which is the only I know exactly when was fixed, because the programs started working, was related to allocating two times in the same region of memory. This happened because in each major GC the list of free line groups is generated again, but my old code was still allocating in the same line group of the last generation. So the last part of the line group, which was not yet used, would be a part of a line group in generated in the new collection, and it will be used for allocation two times: one in the allocation of the current line group, and another when this new line group starts being allocated. The implementation of the allocation of memory in lines is not very complicated, but it has some details that should be paid attention, and that were the cause of most trouble last weeks, and still need improvement. Initially I was allocating one object per line, just to see if it would work. As it didn t, I kept on improving the approach until I could find the problem. The next attempt was by setting ws->todo_free and ws->todo_lim in alloc_for_copy() in rts/sm/Evac.c. I think this is not ideal, because I didn t want the code to become too inconsistent with the way memory was allocated using these pointers before my changes. So I created new variables, line_free and line_lim, at first in the gen_workspace ws, the same place that todo_free and todo_lim are, but because of the last problem I described in the previous paragraph I changed it to generation. I m still not sure about where to place these pointers, this is something that can be improved. Another problem that I took a long time to understand is that the object need to be scavenged after being allocated. When it was allocated in todo_free, it was being scavenged by scavenge_block() in rts/sm/Scav.c, because the block in which it s in, todo_bd, is scavenged by this function. As I didn t wanted to the whole block where the free line group is to get scavenged again, I didn t want to send it to this function. So I thought about creating a way to scavenge only part of a block, that is, the space in the free line group that was allocated. This is still a valid idea, but I noticed that it was easier to use the mark stack. So I mark the object that is allocated in the line and push it in the mark stack. The main problem with this approach it s only possible to allocate in lines during major GCs, since only in this kind of GCs the mark stack is active. This is certainly the place where I can make more improvement. The patch of these changes and another one for the sanity checking explained in the last post. I m now benchmarking these changes with nofib, to see how much it affects the performance.

This Monday I was again at concert of Grossstadtgefl ster, and it was again one of the best concerts I've visited. Their new album again has again great songs on it like the former two, and their live performance is truly worth it. Besides they are charming like hell offstage, too. Jen, Raphi and Chriz, I simply love you! It's hard to choose which songs to put here because there are way too many great ones, so feel free to dig around yourself if you like them:

• Weil das morgen noch so ist: Their current single, great video, giving a good impression of their style and the fun they have doing this.
• Lebenslauf: Great song from their former album.
• Fehler: So much truth in the lyrics, so much touching the heart.

Enjoy!

Some time ago, someone posted to a development mailing list about a piece of code, Cc:ing some people who had modified the code in recent past. Within hours, the original author replied to complain about not being Cc'd. Several thoughts went through my mind:

• Is this man a walking colostomy bag?
• Why is this clown proud of his code? It is sloppy and riddled with bugs, and half of the changes made to it by other people have been obvious fixes.
• Why did his parents not raise him better? Doesn't he realize that demanding recognition in this way makes him a bad person?

This is Free Software, and people are motivated by all kinds of factors. Some bad reasons include

• Recognition, praise, or other Community ego-stroking
• Gaining a competitive advantage for one's for-profit business
• Line items on one's CV
• Finding a husband
• Accumulating increased influence in other communities

Looking at it through an Open Source lens, all these bad reasons are good reasons. For whatever motives, people are getting work done and accomplishing things. Of course, there are always an irritating number of hangers-on, and people who do not actually achieve much but are filled with such self-importance that they believe they deserve to be highly influential through sheer force of will, and the majority of the Community will concede this influence to them due to a variety of flaws in the Human Condition, but I digress. It would be nice if everyone had motives that were pure and good, especially since at least 90% of problems in Free Software projects are due to ego issues, but when the world works, the world works. So I am happy to get code contributions for whatever reason (assuming there are no strings attached). The problem I have is when people insist that their bad reasons are legitimate and should be catered to and accommodated by others.

I am staring at three different plug computers and wondering how many more will appear. They are in varying states of Debianness: all are running squeeze, but the GuruPlug is the only one that's pure . The SheevaPlug is running a wacky version of U-Boot, because the u-boot package in Debian can't cope with the SD card device. Hopefully this can be fixed some year. Worse yet is the FreeAgent DockStar, which is running a foreign kernel and two (TWO) foreign U-Boots (the first one chains to the second one which then boots off a USB stick). Unfortunately I'm afraid to correct these things because, unlike the other two, it is not a developer board, and messing it up would mean trying to deal with 3.3V RS-232 or something equally unpleasant. As it is, bricking one of the plugs where I actually have serial/JTAG causes enough emotional turmoil.

A few years ago, when I was still a member of the Jozef Pauly ensemble from Ekeren, at some point I took over maintaining their website. One of the things I did was converting it to drupal, mainly because that would allow other members of the ensemble to help maintaining it. Of course, such things do not happen automatically; and had I spent some more time on the project, it might've actually worked. But I didn't, so it didn't. Oh well. One of the main issues with the site as I set it up, was that I hadn't really done a very good job integrating everything. The standard drupal 5 theme looked pretty good, I thought. Slap on a few modules, and done. Unfortunately, I skipped a bit of testing, and as a result, the site didn't really function the way it should've. When this became apparent, I didn't have the time to properly fix it. During the last few years that I was a member of the ensemble, someone else stepped up to help maintain it. I told him that one of the things that I wanted to do was to upgrade the site to Drupal 6, so as to make i18n a bit easier. But some of the modules which weren't in drupal core made this somewhat harder than needed, and I didn't have the time to investigate in-depth what the issues were. In the end, I set up a secondary site on a different vhost on the same server that ran drupal6, and gave that guy admin rights there to help convert things to the new site. I planned to lead the effort to make things work; but when I came back not so much later, it turned out that he'd done a very good job already, and that it was probably a good idea to let him finish. This took much, much longer than expected; but eventually, he's finalized the setup, and it's now live (since a few weeks) on their official site. This site has content in both Dutch and English, though there is slightly more in the Dutch version: since they're doing a concert trip again this year, there's a blog for their families. Also, some people individually have decided to blog about the whole thing, too, which is... interesting. At any rate, I think the site looks very, very cool. Go check it out! I guess we may have to start thinking about doing an upgrade to Drupal 7 some time soon. But, hey.

I m a Debian developer since 1998 and have been fostering cooperation between Debian and Ubuntu since its inception with various levels of success. I recently decided to go one step further and join Ubuntu as an official member. I wanted to be able to vote and to promote best cooperation practices from the Ubuntu side as well (and not only in Debian). Joining as a Debian developer should be relatively easy, it is well known in the Debian community that Mark Shuttleworth once said:

Every Debian developer is also an Ubuntu developer, because one way to contribute to Ubuntu is to contribute to Debian.

So I sought to verify that too! Here s the result. I prepared my application page collecting 2 testimonials from Lucas Nussbaum and Colin Watson, I registered for the next EMEA membership meeting (which happened yesterday, irc logs here), and I attended. (I just followed the instructions on the wiki) During the meeting, when it was my turn, I pasted my short introduction and got immediately +1 votes from several board members, they didn t even want to hear from me, they were already convinced. I still responded to a few questions and elaborated on my goals and was promptly accepted even if I made it clear that my technical contributions will continue to be done within Debian. A few minutes later I was added to the ubuntumembers launchpad group and this morning I followed the instructions to add my feed to Planet Ubuntu and here I am The whole process has been very smooth and the meeting shows a very welcoming attitude. Even someone who was denied the Ubuntu member status was cheered for his work and encouraged to try again when he can present some testimonials from other members. Hello Planet Ubuntu! 11 comments Support my work