There is a lot of career advice related to writing CVs in books and floating around the net. Unfortunately almost all of it is tailored to permanent positions. Some advice that I have seen includes researching the company you are applying for and emphasising your experience in related fields. This probably makes some sense if you have targetted a major company to be your employer for the rest of your life. But if you are after contract work (which incidentally tends to pay better than permanent positions) then it’s not going to work. About half the time when applying for contract work you won’t know the name of the company that is receiving your CV until after they have decided whether to grant you an interview. Contractors therefore need to write their CVs to have broad appeal (emphasising common technologies such as C programming and skills such as debugging), and to appeal to a recruiting agent. Some people recommend writing your CV in MS-Word to support agencies and potential employers who are not competent enough to open other file formats (such as PDF and HTML). I strongly disagree with this advice, most contract positions are advertised by multiple recruiting agencies and it would be best for you to be represented by the most competent agency. Therefore having an agency staffed by incompetent people not represent you because they can’t figure out how to read a HTML or PDF file is a good thing! The same applies for employers, while applying for the best paying contracts will often result in some strange and unpleasant working conditions having a manager who can’t open a PDF or HTML file is likely to result in something that is unusually bad - run away! Recruiting agents will often give specific requirements for a CV. Sometimes these requirements are a little odd (such as demanding that references to C programming be removed from a CV when applying for a Unix sys-admin job), but being merely a little odd is no reason to boycot the agency. To solve this I wrote my CV in M4 macros to generate HTML code. When I wanted to apply for a position I would just type make to compile the M4 source into five or more different CVs. Sometimes a recruiting agent would request two versions when applying for one position, it’s a strange request but when five versions were compiled in one pass it was easy to satisfy it. If I liked PDF I could have written M4 macros that generate TeX and have the make process convert TeX to PS and then PS to PDF. Unfortunately I can’t share any macros because the code was not of particularly high quality (which is a little ironic) and because it’s tightly tied in to my CV. The best piece of advice that I can give to anyone trying this is to get columns sorted out as the first issue. If you want to have some lists of programming languages, lists of OSs, and lists of hardware, etc in your CV then it usually works best to have two columns in the page. If the largest list is removed then the other lists need to be shuffled around to get the column lengths to match. Doing this in HTML required some ugly M4 macros. There probably is a better way of doing this in TeX (but I’m really not good at TeX and can’t give advice about it). James has some interesting advice about writing CVs. I think that his most useful points are:

1. Use file names based on your name so that agents can find your CV in the directory full of CVs


2. Include complete contact details. One thing he doesn’t mention is that you should buy a mobile phone for the purpose of getting a job even if you don’t want one for any other reason. A 5% difference in pay for a year’s work would cover the cost of many mobile phones and the difference between a good job and a bad one is likely to be more than 5%. If you are afraid of brain cancer then don’t worry, if you only spend a few minutes a month talking to recruiting agents then you are at no risk.


3. Don’t start a sentence in the career history section with the word worked - everything in that section will be related to where you worked in the past. It seems obvious in retrospect but I realised that I have made this mistake on my CV.

Share This

After (again) searching for some good photo album generator, I'm more and more inclined to writing yet another tool to do this. Maybe I just want too much from this, but I haven't found solution that would fit my needs:

• Generate static HTML (or XHTML).
• Design should be done using CSS.
• Ability to process whole tree of photos into single album with directory based sub albums.
• Generate data only for changed/new photos (timestamp checking).
• Support for including EXIF information in results.
• Clean and nicely looking default template.
• Support for image comments from EXIF, JPEG comment field and external file.
• Automatic generating of images suitable for web browsing as well as including links to full sized images from camera.
• Somehow active development. I fear of using code which has not been updated for 3 years.
• It should be fast. This excludes anything written in bash as spawning tons of external programs can not be fast.
• Written in some language I know. I'm pretty sure I will hit some bug and I would like to be able to fix it. In fact only suitable language for me seems to be Python.
• Command line interface is a must.

So far I'm using a bit customised Matew which really does not fulfil everything, but at least works reasonably good (but extremely slow). However the more and more pictures are in my album, the slower this beast seems to be, so it's probably time to switch to something new. So far I haven't found anything that would actually fit, but PyAC seems to be usable as starting point for my new project for generating albums. Or is there a working solution?

Filtering Debian Packages file

pkgprune - Filter a Packages file
Usage: pkgprune Packages > Packages.filtered
Filters a Debian Packages file by removing either a list of packages (and
their reverse dependencies) or the packages that have given tags.
Dependencies in the filtered Packages file will still be satisfied.

Available via:

wget http://people.debian.org/~enrico/2007-08/pkgprune/pkgprune

or:

hg clone static-http://people.debian.org/~enrico/2007-08/pkgprune

The top of the script has a configuration section:

#
# Configuration
#
# Set of packages you don't want to have (the reverse dependencies will be
# removed as far as it's possible)
blacklist_pkgs = set(['gconf2'])
# List of sets of tags; the packages whose tag sets contain one of these tag
# sets will be removed
blacklist_tags = [ set(['implemented-in::php']) ]

Edit that before running the script. The idea is to be able to configure a system to run such a script after apt-get update, both to make dpkg faster on slow arches and to reduce the amount of packages displayed by an interface.

As I type this, debs for a current snapshot of upstream Subversion are on their way to Debian Sid. They are taken from the Subversion trunk and not from the yet-to-be-released 4.6 branch, because a few important changes have taken place on the trunk only, and the 4.6 branch is merged anyway. Hence the version number, 4.6.99+svn6078-1. These packages did spend some time in experimental, and I didn't get any bug reports, but that doesn't mean they're bug-free. Use with caution. One of the big changes is that Gforge now uses Gettext rather than its home-made internationalisation system. Which means probably fewer problems, and a more standard system allowing more people to get involved. Can you guess what I'm hinting at? Yes, it's a call for translations! Anyone interested in getting involved should bzr branch http://alioth.debian.org/~lolando/bzr/gforge/upstream-svn/trunk/, and start poking the existing *.po files (or creating new ones!). Why the private repo and not the upstream Subversion repository? Rationale follows. My job as a freelancer as well as my role as an Alioth admin involve maintaining separate branches of the Gforge code (different clients have different needs and patches). In order to facilitate patch migration, I therefore need a distributed VCS, and I've been using Bazaar for a few years, with a manual gatewaying between upstream CVS first, then Subversion, and a few private Bazaar branches. Now that Bazaar (as in Arch) is dead, I'm using Bazaar (as in Bazaar-NG, Bazaar-2, or bzr), which seems to be approaching a 1.0 release, and which provides a plugin to interoperate easily with Subversion repositories. And since the upstream Subversion repository is not accessible anonymously anyway, I decided to publish my gateway branch. I'll probably publish more branches as time passes (probably the Alioth branch, and quite possibly feature branches too). Note: if you want to share a bzr repository of a project containing PHP scripts with Apache, you may encounter a problem, because the bzr repository contains files named *.php.knit and *.php.kndx. And Apache will happily give these files to the PHP interpreter when serving them, and that's not what you want. My trick to fix that is to add a .htaccess file somewhere where the repository is stored, with the following contents:

AddHandler None .knit .kndx

This will ensure that these files will be sent straight to the HTTP client, and not through the PHP interpreter.

A few days ago, Joe Reagle was telling me about the rise of (sometimes very arcane) policies and bureaucratic imperatives that now characterize Wikipedia. A few days later I stumbled across a few interesting posts on the topic, posts (especially Nick Carr’s) seeping with almost celebratory gloom and doom:

‘But, given human nature, is it really so “incredible” that Wikipedia has evolved as it has? Although writers like Yochai Benkler have presented Wikipedia as an example of how widescale, volunteer-based “social production” on the Internet can exist outside hierarchical management structures, the reality is very different. As Wikipedia has grown, it has developed a bureaucracy that is remarkable not only for the intricacies of its hierarchy but for the breadth and complexity of its rules. The reason Deletionism has triumphed so decisively over Inclusionism is pretty simple: It’s because Deletionism provides a path toward ever more elaborate schemes of rule-making - with no end - and that’s the path that people prefer, at least when they become members of a large group. The development of Wikipedia’s organization provides a benign case study in the political malignancy of crowds.”

It is without question that a problem has arisen in Wikipedia, a problem composed of a thick web and net of rules that can be helpful as guidelines but often are often confusing and clearly work to ensnarl new users. But can we so quickly put blame on so-called human nature? Or is it not a problem of human organization, which as the anthropological and sociological record shows, can take many forms? And is it not just that: a problem begging for a solution instead of an opportunity to declare the fundamental nature of wikipedia (and that of human nature?). Not only may history prove him wrong, other large scale collaborative projects at least prove that solutions can be found to deal with problems of growth and scale. It is as if Carr just wants to see a project like Wikipedia fail, which somehow, this morning hit a raw nerve. What I find exciting about large scale projects of (at times unwieldy) collaboration are not just the explicit outputs of the projects (an encyclopedia or operating system) but the social worlds they create. And there is no inevitable path they *must* follow. These groups have a choice to react to and respond to these sort of problems and enact solutions that will hopefully solve them and allow these projects to change. Debian, a slightly older project than Wikipedia, has gone through many growing pains and there was even a period when the the whole process of integrating new Debian developers was shut down and if my memory serves me correctly, for 2 years! At the time, it could have been possible to say: “This signals the end of Debian” but eventually a solution was found, the New Maintainer process, which while not perfect (what is?) allowed the project to grow and produce a great operating system for years to come. Debian today faces new problems and is working to find solutions. I hope that Wikipedia can and will do the same. And instead of declaring its death, why not wait and see, and offer something a little more constructive and illuminating, than destructive?

After much wading through possible names, none of which really excited me, I have finally chosen "DAViCal" as the new name for my CalDAV server that was previously called RSCDS, or the "Really Simple CalDAV Store". In the end, I chose DAViCal because it:

• seems easy to pronounce.
• combines the 'Cal' and 'DAV'.
• returns < 1000 results on google.
• doesn't make me cringe.
• didn't have a domain name registered.

That was about the hardest part of preparing for the 0.8.1 release, and now that I've done that I should manage to make the changes to the packaging, though I have no doubt that the old name will appear in all sorts of places for a while yet. Choosing names is an important business, and I should know that from the length of time we spent agonising over names for our children, discarding all sorts of things because they had silly abbreviation collisions (like the "Royal Scottish Country Dance Society" :-) Even then, I think we got the kids names wrong, and the big one should be called "Thumper" with the little one called "Sly", but perhaps that's just a temporary annoyance and in time the names that we registered for them will fit them better. I also recall Grant once saying that you should never use the word "Simple" in the name of your project, and he should know. DAViCal is no longer particularly simple, although I have attempted to hide the complexity from the user as far as that is possible, and will continue to do so. Once I get out version 0.8.1 of DAViCal I will finally upload it to Debian, proper. This version has some important enhancements to its DAV spec compliance which are going to be needed by some future versions of Mozilla, and probably other things too, so it's important to push it out as soon as possible now.

The Australian has a new Environment writer named Matthew Warren who has a history of doing PR work for the coal industry. This has the potential for insightful articles based on knowledge of what the industry is doing or for PR work for the coal industry masquerading as journalism. Unfortunately it seems like the latter is what we are getting. Matthew’s latest effort is an article claiming a $6.5 billion cost to home-owners because of an “effective ban” on electric hot water systems that Labor might impose. Unfortunately he doesn’t clearly state what an effective ban is, but does note that apartments are exempt. The specific claim that is used as the basis for the article is that solar hot-water systems cost $2,800 more than electric systems, and that after the solar hot-water rebate ($1,000) the additional cost would be $650,000,000 per annum, and that a period of 10 years would be required to replace all hot-water systems thus giving a cost of $6,500,000,000. So I presume that he expects that there would be 650,000,000/1,800 hot water systems installed per year which would be about 361,111. According to the Australian Bureau of Statistics there were 6,744,800 households in Australia in 2003. Matthew’s article states that about 40% of homes can have gas hot-water systems fitted that comply with the proposed new regulations, given that and the exemption for apartment buildings let’s assume for the sake of discussion that 50% of homes would require a solar hot-water system. Assuming that each household has a separate hot-water system that means that for these claims to hole we need an average expected lifetime for a hot water system of 6,744,800/2/361,111 = about 9.3 years. If the currently installed hot-water systems are expected to be replaced in 9.3 years then we can expect that hot water systems tend to survive for an average of about 18.6 years. I wonder if that number is correct (some google searching didn’t turn up an answer). One of the disadvantages of old-fashioned media is that they tend not to include calculations or cite sources adequately so we can’t easily verify or disprove their claims, I wonder if this is deliberate… Matthew admits that using a solar hot water system can be expected to save households $300 per annum in electricity expenses, I presume that this is based on current energy prices and that the savings can therefore be expected to increase as energy prices increase (we have a lack of water which is increasing the cost of producing electricity from coal). Let’s assume for the sake of discussion that the typical home-owner has a mortgage, the Commonwealth Bank is currently advertising mortgages with a rate of just over 8%, the way things work is that there are various criteria for getting a discount rate which most borrowers can meet so the result will be slightly below 8%. If a solar hot water system costs $1,800 extra to install and the money comes from a mortgage then every year it will cost the home owner about 8% of $1,800 which is about $144 (a saving of $156 per annum). If the solar hot water system saves the home owner $300 per annum then at any interest rate below 300/1800 (16.66%) they will make money. If there was no government subsidy and the entire $2,800 extra was paid by the home owner then at 8% interest it will cost $224 per annum (a saving of $76 per annum) and the interest rate would need to increase to 300/2800 = 10.7% to make it break even. So for solar hot water to not save the home-owner money we need to have a significant increase in interest rates (which incidentally would bankrupt many home owners), AND to have electricity prices remain the same (which would require even more of our tax money to be spent on supporting the coal industry). Finally Matthew complains that the solar hot-water rebate could cost the government $4 billion over the course of the scheme (the next 10 years). This sounds like a lot of money until you think about the 9 billion dollars a year that the government spends on subsidies for the coal, oil, and gas industries! On the current course the government would spend 90 billion dollars of our tax money subsidising polluting industries that cause climate change, but Matthew opposes spending 4 billion subsidising technology that prevents pollution and reduces climate change.

Share This

I just completed a very successful and long overdue dist-upgrade of my unstable machine, using mainly DebTorrent for downloading the packages, so I thought I'd post some of my thoughts and experiences. The download consisted of 1294 packages to upgrade, totalling 1350 MB and taking 2h12m to download. Here are some of the good and bad things I observed. Good things There was a single other peer with me in the same torrent, and I managed to download 182 MB from him, which is about 13.5% of the total download. This is the first time I have noticed this downloading from peers occurring, as usually there are too few peers, too many torrents and too many possible packages to download for any sharing to occur. This will hopefully change in the future when more people start using DebTorrent, and when unique piece numbers are introduced to make the torrents last longer. However, it does show how the use of the backup HTTP downloader can seamlessly integrate with downloading from peers to provide a good user experience, even for early adopters. The CPU time used was only 10m46s, which translates to an average CPU usage of 8%, which is very reasonable. The average download speed was 174 KB/s, which is 58% of my maximum download speed. Though this may seem like a bad thing, my goal all along has been to make sure that the download time would not be more than twice as long as using HTTP. Of course, using DebTorrent may never be as fast as a straight HTTP download from a well-provisioned server, but that it not the point. The idea is to reduce the bandwidth needs of hosting a debian archive. But in the future, when there are many peers in a single torrent the download speed may be even faster than using HTTP, especially for peers with very high download rates that could not be matched by a single server. Things that need improvement The completion percentage reported by APT during the download was fairly inaccurate. Here are some sample readings I noted, compared with the actual completion percentage from the DebTorrent status page:

APT Reports	Actual Completion
10%	40%
20%	70%
30%	85%
40%	90%
50%	93%
60%	96%
70%	97.5%
80%	98%
90%	99%

The discrepancy occurs because larger packages are broken up into pieces, so they can be partially downloaded without APT knowing about it (since only fully downloaded packages are passed to APT). Clearly this situation is far from ideal, and can lead to the user feeling that the download is progressing very slowly, or not at all. There are some plans to add status updates to the communication between APT and the DebTorrent client, but they require changes to the APT code to support them, so it may take some time to implement. Another problem is the memory usage I saw during the download, which was approximately 213 MB. This is obviously unnecessarily large, though the metainfo that DebTorrent needs to be aware of is quite large (stored in a text file it is about 3 MB). There does seem to be a memory allocation bug in Python 2.4 which causes increased memory usage, so moving to python 2.5 might help. However, my preliminary tests show this only saves you about 20% for DebTorrent. I think I will have to delve deeper into which parts are using all this memory, and unfortunately python doesn't seem to have a good memory profiler to help with this. I will be looking at both PySizer and Guppy/Heapy to start, but if anyone knows of a better solution, please let me know.

It's been a long time without saying any word, my project completely drained any free time! So it's finished, as long as GSoC goes, but Pancut n still is a work in progress. What happened is that it turned out to be a lot more difficult that what I expected, so during the second part of the program —when I would write all the tests— the schedule ran away. Anyway, the tool is in a fully functional state: you can try it now and it —$DEITY forbids— will not crash on you; but it will not be able to spot many errors yet. So, if you can, please install it and try it out! Bug reports are welcomed, and code will be greatly appreciated. I've set up a debian repository with binaries (i386) and sources where you can grab it from, with all the dependencies, or you can check out the SVN repository. Bear in mind that it depends on a version of libcdio that's still not in the archive, so that can also be found in my private repository. As expected, my work with this tool doesn't end here; I will continue hacking on it as soon as I end my vacations; which brings me to the other subject of this post... Tomorrow I'll be leaving Lisbon, heading north to Porto and then the northern region of Spain: Galiza, Asturias, Euskadi and Catalunya; ending later in Madrid. After Spain I'll visit a friend in Paris and money and time will determine what I'll do after that. I am very excited, I love travelling and I really need some rest. PS: also I moved this blog to blosxom, which I expect to heavy hack on when I get back. Tags: Planet Lugfi, Planet Debian, Programaci n, Debian, Viajes

The Google Summer of Code coding period has ended earlier this week, so it seems to be a good time to stop and look what was done (and what wasn't). Let's start with an objective analysis, following the list of planned features:

Advanced query of bugs on the Debian BTS

In a 1-10 scale, I would give myself something like 6 or 7 here. bug-triage can query bugs by number, source package, package, maintainer and submitter. These parameters can be combined to make an query (reports must match all parameters) and more than one query may be added, subtracted and and'ed. A clearly missing feature is querying by usertag, support for it has been added on btsutils already and is just a question of adding a new input box on the query builder dialog (it should work if you enter the query manually in the bug-triage query line AFAICT).

Show all the information related to a bug report

bug-triage has a "goto" button which opens the bug in the user's preferred browser. Missing is the support to open the bug in a MUA, which I have promissed to Lo c.

Send additional information to a bug report

bug-triage has a "followup" button which opens the user's MUA with the right address. Maybe setting the subject would be nice...

Manipulate the tags of a bug report

I haven't had time to implement this at all. I've started it, the bugs have a context-sensitive menu which have each of the available tags as checkboxes on the right current status, but clicking on them does nothing currently.

Search for similar bugs in upstream developer BTS

This one would value something like 3 or 4 in a 1-10 scale. It searches upstream bugzillas by product and component, but doesn't do any cool trick like searching words in the bug subjects. The plus is that it does support KDE bugzilla, even though I haven't been brave enough to promisse it before SoC :P

Forward a bug report to the upstream developer BTS

There isn't really a good interface to report bugs programatically on GNOME bugzilla, which was disappointing. <rant>There is the bug-buddy xmlrpc(?) interface, but the developers say they will actively break anything using it, which I find very free-software-unlike.</rant>. The current bug-triage solution opens a browser with some of the fields filled. It would be nice to fill the full bug description, but its limited by the maximum size of an URL, so it fills only an introductory text (something like This bug was filled on Debian BTS #XXX) currently. Let's hope bugzilla 3 get on the GNOME world soon.

Conclusions

Unfortunately, this project hasn't evolved as much as I would like in the second half of the GSoC. As I said elsewhere, a lot of stuff has happened, some good, some bad, but on the end everything I hadn't been able to dedicate myself to anything I should. Even so, I think the project may be considered sucessful.

Maybe the more interesting product of this project, at least currently, is still on python-btsutils. As I said in the middle-term report, it'll be integrated in the debian_bundle soon, and might be powering important stuff like the devscripts in the future.

The bug-triage application has a lot to evolve yet, but is also an interesting tool IMHO. There are a lot of hurdles in the way to get different BTSes integrated, but the effort will for sure pay in the future. I plan to keep developing it (evon though keeping the GSoC pace is impossible) and am anxious to see the results ;)

Finally, as I said before, one of the main things on GSoC for me was the potential to learn cool stuff. The best choice I've made during all of this was to use Python. Even though it's still a new language for me, and i still have to search embarassingly simple things in the tutorial/reference, it was a lot more productive than if I was developing in C. Learning to use git was also a great. This goal was the more fulfilled one, I've really learnt a lot of things which will surely be useful in the future. BTOH, I still can't get used to glade :/

Thursday morning I arrived Chubu airport near Nagoya and at this time started my first visit to Japan. It will take quite long time (3-6 months), so I should have enough time to do as much sightseeing as I want. But there was not much time for sightseeing so far. Besides work and having rest after 24 hours of travelling, we only went today to see a bit of city. No real sightseeing, it was rather finding out some things. The most important was to find ATM accepting our credit cards. I didn't expect it will be that difficult, but it turned out that most ATMs accept only Japanese Visa and MasterCard cards and not ours. Fortunately post office has ATMs accepting foreign cards, so we finally have enough cache to survive next week ;-). The next step was to buy something we can start to learn Japanese a bit. It would be great to be able to read at least some signs and menu in restaurant. We bought few books, but later in restaurant it turned out to be almost useless. Fortunately the cook can a bit English, so we managed to order something we wanted. But this is the largest problem here - our poor Japanese knowledge as there was not time to prepare for this back at home...

Dell just sent me a letter advertising their new Vostro line “especially for small business“. They say “we listened, then we listened some more” and explain that it’s based on feedback from people in small companies. The problem (which should be familiar to everyone who has ever done any consulting work) is that people don’t ask for what they need! Ask someone what they want in a computer system and the first thing that they will ask for is a fast CPU and a low price, the colour of the box will probably be higher on their priority list than the option of a backup. Dell have proved this by advertising their small business machines by advertising cheap desktop machines for small business use. Here is a list of the features that I consider essential in small business systems (based on my experience working for dozens of small companies):
Reliable operation. Using a relatively inexpensive machine as both a desktop machine and a server for the company network is very common in companies with less than 10 people. The Dell PowerEdge Tower systems are reasonably cheap (as little as $800AU - $100 more than a low-end Vostro in the base configuration, although the Vostro includes a bundled monitor). The PowerEdge machines have ECC RAM as a standard feature (avoids data loss due to memory errors) and can be delivered with hardware RAID support (SATA-2 or SAS) and a variety of backup options. A low-end tower PowerEdge server with 250G of hardware SATA RAID-1, a 160G removable disk for backup, and an extra gigabit-ethernet port costs $2015. Such a machine would do really well as a server for a small company while also being quite good as a desk-side workstation (the cooling fans would probably be louder than on most workstations but the money saved would be worth-while for most small businesses). If Dell was to promote PowerEdge tower machines (maybe under the label “Vostro Servers”) it would be good for customers and should be profitable for them. The next thing that Dell should consider is a laptop with ECC RAM. Many small businesses start out as a sole trader with a laptop. Data loss on such a machine would be catastrophic. At the design stage ECC RAM would not be difficult to add - if there was a company that produced such RAM (I expect that Dell could purchase enough volume to drive the creation of new memory modules). Another laptop issue is the reliability of mass storage. Laptops tend to get dropped and hard drives tend to break when dropped. Lenovo sells a “ThinkPad Serial ATA Hard Drive Bay Adapter” which allows two hard drives in a Thinkpad which could be used for RAID-1 (if you don’t want a built-in DVD drive). I chose to use regular backups instead of buying the extra hardware for RAID-1 but it would be good if other companies offered such options - especially when promoting their products to small businesses (who often don’t do regular backups). Even Lenovo could improve things in regard to their potential RAID-1 support in Thinkpads by promoting this feature (instead of just having the hardware listed as an optional extra with no mention of why you would want it) and offering a default install with RAID-1. Better still would be hot-swap RAID-1 in a laptop (which would be quite easy to do if the expansion bay was changed to use USB as it’s method of connection). Of course RAID-1 only covers you in the case where the drop is only enough to destroy one disk or if it causes partial damage to both disks but doesn’t destroy the same section of data on both disks. The next big thing for laptops will be flash storage. One of the major advantages of flash is that it’s almost impossible to destroy it by dropping it. I would rather have my important data on a flash storage than a hard drive (it also saves electricity and therefore makes the battery last longer). The option of having flash as the primary storage device and a hard drive for files that are larger and less important would be useful to most small businesses. Of course hardly any small business owners will ask for this, they will probably ask for a machine that has a fast CPU. Sometimes when developing a product you have to design something with the features that customers need and get the sales and marketting people to convince the customer of the benefits of the features. Even though the number of people who understand the technology and will jump at the opportunity to buy good things (such as me) is rather small, the number of people who can understand once it’s explained to them is quite significant. I’m sure that if Dell released a new line of computers with the slogan “reliable machines that don’t lose your data” instead of “good-looking new machines” then they would get some interest. After writing this post but before publication time I happened to be speaking to the owner of a small business on the topic of choice of computers for a company such as his. He seemed convinced of the benefits of a better machine to replace his current desktop PC that is running as a server (it’s yet to be seen whether he considers the benefit to be worth the cost). I wonder if Matt Domsch reads my blog…

Share This

This is the first post of a series on componentization, starting with a brief explanation of the problem(s) we are trying to solve. I expect some familiarity with programming in general, but no specific knowledge of any particular system; the terms "DLL" and "shared library" are used interchangeably. When you are writing a DLL, you are essentially committing to support whatever interface you are exporting forever. So it better be good on the first try. DLL hell is what happens if it was not good, and you end up making an incompatible change. The obvious way an interface can be "not good" is when you need to touch the header files that define it in order to implement some new functionality. You can get away with a few things, like the addition of new functions, if you can somehow make sure that users will always have a recent enough version of your DLL around, but in general any change to the interface is going to be incompatible. The traditional Unix way of solving the issue has been renaming the library. When you link a program against a shared library on a system that uses the ELF format, the linker looks inside the library for the SONAME field, which tells it what name the library wants to be known under, and the program will then attempt to load this file at startup (which usually is a symlink to the latest compatible version). This "official" name of the library usually contains a number (sometimes more than one), and when there is an incompatible change, you simply change that number, and the new version of the library can be installed in parallel with the old. There are additional mechanisms, like symbol versioning support, that allow a single library to provide different "versions" of exported functions, and have the program specify the desired version for each symbol. To run a system like this, one generally needs to keep track of programs' dependencies; this generally happens in the package manager with more (Debian) or less (Red Hat) support from package build scripts. If you built your system from scratch, you end up doing this work yourself. That's why you had highly paid system administrators in the old days, and very short shell scripts to replace them (with various degrees of success) in the current age. In the Windows world, things have been a bit different, because except in large installations, you generally do not have a clueful, benevolent system administrator who will take care of these things; rather, you have users that expect your software to work without having an insight into the inner workings. In general, software developers have not been taking chances and simply shipped all the DLLs they needed along with the main program. When they installed these DLLs into the same directory as the program, things were fine, if they installed them into the WINDOWS directory, not so much, because when you had two conflicting versions of the same DLL, you had to decide which one to keep, and a program that would only work with the one that you threw away would simply fail in curious and interesting ways. This is the original definition of DLL hell — you cannot do it right. To make matters worse, this is not the only way an interface could change. When you define a platform, you write up an "Application Binary Interface" (ABI) document that details conventions that should be followed; for example, the ARM processor does not have a dedicated stack pointer register, so the ABI document for Linux on ARM says that R13 is to be used as a stack pointer, functions may thus expect it to point to memory that is readable and writeable, and memory with an address lower than the stack pointer is considered "free". When the function is done, it is supposed to jump to the address in R14, which happens to be the register the ARM's "Branch with Link" instruction sets to the address of the instruction following it. If the function takes arguments, the ABI says where to find them, and if it returns a value, it also tells where to place that. For everything not in the ABI document, the compiler author gets to choose. The ABI document usually attempts to be rather minimal, so it defines how C functions are to be called, and calls it a day. Anything not in the C standard is not guaranteed to work between different compilers (or even different versions of the same compiler). That includes C language extensions such as the "long double" data type, language features in C++ and Java such as namespaces, nested types and exceptions, and the data structures used by the C library's malloc() function. The latter makes life difficult even for pure C programmers, as it disallows releasing memory from a different module than the one it was allocated in, because the different modules may link to different C libraries. In essence, this means you are not supposed to export anything from a DLL that is not a C function, and even then, there are additional requirements. You could in theory export data objects, but that is discouraged, as it exposes an implementation detail. Now, we're in a bit of a dilemma here. There is lots of interesting code out there that is not necessarily written in C, we'd like to reuse it and we don't want stuff to break. The Linux approach so far has been "we simply pretend the problem does not exist", and this has been working to a large extent, simply because everyone uses gcc, and when the ABI extensions the gcc people had made changed, recompiling everything that uses these extensions makes the problem go away. This has several drawbacks. For one, it mandates that the tools used to rebuild everything and keep the installation consistent be written in C or handle the transition gracefully (for the curious who have a Debian system handy: look at libapt-pkg's SONAME), and it also requires that we have the full source code for everything not just available but buildable in an automated way. Within the context of a Linux distribution, both of these are true, so we have survived the last major ABI transitions without too many losses. So we need an extension of the ABI document that specifies how modules written by different people and compiled with different compilers can interact. These are commonly called component models, and, to quote Andrew Tanenbaum, "[t]he good thing about standards is that there are so many to choose from". Next: "componentization tutorial #2: CORBA and COM"

A frequent criticism of solar power is that the sun only shines brightly for part of the day, and that many of the times when there is significant electrical load (EG when people get home from work in winter) the sun light will be weak. One interesting solution to this problem is to store the solar power by splitting ammonia into nitrogen and hydrogen gases, storing them separately, and then reacting them to produce super-heated steam for power generation at any time that power is needed. The technology is based on three decades of research at ANU and the Federal government has allocated $7,400,000 for building a power station near Whyalla in South Australia. The down-side to this is that it needs water for the steam part of the electricity generation process which is a minor problem as we are having water shortages in most parts of Australia. But the up-side is that the process of combining nitrogen and hydrogen to produce heat should be something that can be turned on rapidly. So it seems that there is potential for having a wind power plant designed to satisfy all the power requirements on windy days and store hydrogen and nitrogen for times when there the combination of sunlight and wind is not adequate to satisfy the power requirements. Previous plans for the maximum possible use of renewable energy in producing electricity have included gas fired power plants for times when wind and solar power can’t meet the demand. It seems that with technology such as this one it will be practical to have all electricity produced from renewable sources of energy.

Share This

It is nice to see books on free software finally get their day under the sun and today, Samir Chopra and Scott Dexter have announced the release of Decoding Liberation. Because it is a bit on the pricey side, try to get your library or work to order it and then when you get it, enjoy. I know I did and had the pleasure of reading early versions during an informal reading ground held in NYC 2 years ago and final versions more recently. Among other great chapters, the one on the aesthetics of code, is, well beautiful. I can’t wait to re-read it. If you are in the city, make sure to catch one of the book events that will be happening; your very own will help lead a discussion on October 3rd and I might write something up more formal about the book (and of course post here) then.

It is the year 2007. The entire world has build tools that look at the modification dates of files to decide whether a certain build step needs to be run. Well, except for a small town somewhere near Seattle. A bug report for that has been opened almost a year ago, only to be closed a month later with a resolution of "cannot be resolved" in light of the new guidelines on bug reporting that state that no bug reports for intrusive changes will be honoured for Visual Studio SP1. I'm slightly tempted to write an open-source reimplementation of msbuild and place it under the GPL. What I won't do is answer to Their job advert.

DebTags is a really nice system for clasifying programs, it allows you to select which packages you want by being able to select between many different kind of labels, that are used to categorize them. Anyway, there is sitll a long way to go if we want to make it easier for users to locate the programs they want, and that goes for games too. In DebConf7, in Edinburgh (Scotland), Enrico suggested me that we could do a GUI for searching the games available in Debian, using his DebTags as the backend. Starting there, using his libept library for accessing the data, FLTK (Fast Light Toolkit) as the toolkit engine, and C++ as the programming language, we’ve been slowly developing it. The version 0.1 of the program is ready, and hopefully will be in Debian soon. We’ve decided to create a standalone package with the thumbnails, that could also be shared with other programs, and the package for goplay itself. Both are now waiting in the NEW queue, and hopefully soon they will be in Debian. Of course, more snapshots of the games shall be taken, and there’s a lot of room for improvements, but at least it’s a starting point. For using it, you’ll need to install debtags and ept-cache in your system, and set them up properly, and possibly also the results from popcon, if you want to have that data in the GUI too: apt-get install debtags ept-cache
debtags update
mkdir /var/lib/popcon/
cd /var/lib/popcon
wget http://popcon.debian.org/all-popcon-results.txt.gz
ept-cache reindex

And no, I don't mean Mao.
How was Thursday 23 for me?
6:30 Wake up, knowing it will be a long day. No, don't get those delicious extra 15 minutes of sleep.
8:00 Arrive to work, ~90min earlier than usual, to finish the Rails app you have to demo at 10:00
10:00 Meeting with the Institute's Director, Academic Secretary and Technic Secretary to show them the system for following the internal inter-tematic colloquium information workflow. Thankfully, they were happy with it.
11:20 (20 minutes after scheduled): As several academics have said they are interested in getting to know Linux, I'm giving a series of introductory sessions on Debian to them. So, I went with some of them through the Etch installation. Of course, mostly everything was fine. What was not? Resizing a Windows partition is still a step that requires several jumps through hoops (i.e. booting Debian LiveCDs, some console-based interactivity which I wanted to avoid...), and... Well, d-i does not time out if the selected mirror is not responding. Will file a bug, yes. Anyway...
14:30 Managed to leave the lab working, with no damages. Went to the bank to check some data and to have a quick lunch.
16:00 Get back to the institute. Jos Luis, from Difusi n y extensi n was already waiting for me to show a set of components for the Comas-based system we use for tracking attendance to the Institute's activities
16:45 The people from AMECIDER arrived so I could show them my proposal for their new website. Can you believe most of the websites I host are still completely static HTML, and, what's even worse, generated by the $ despiseful_adjective Dreamweaver? Yes, I am proposing them to move over to Drupal
17:30 I finally received another person, one of the people that's attending my Thursday lessons, wanting me to help with some Linux questions. What's Linux's killer app for my Institute's researchers? Believe it or not, a not-brain-dead PDF reader. They are amazed that, using Gnome's Evince, they can just copy-paste bits of PDFs into their documents (and the fact that pasting tabular data into OpenOffice's Calc allows for an easy import feature - Yesterday I spent ~1hr with this researcher importing data generated by the International Monetary Fund into his work), and they are even more amazed with the gnome-screenshot they can directly include graphics from such documents without redrawing them.
19:45 (45 minutes behind schedule): Went to the Astronomy Research Institute, to meet with Sergio, H ctor and Eric, to decide on bits of the implementation of the new gear we will be putting in nisamox, our dear and faithful ftp.mx.debian.org mirror. Thanks to everybody! We will soon tell you what we got and what we did with it, it's mostly settled by now.
20:30 Had the first of some... Four calls regarding yet another system I have been working with for the ICME conference, to be held in Mexico in 2008. Several pushing details that need my attention and work, bah :-/ Have to work on them...
21:00 Got home. Did a couple housekeeping activities (i.e. take out the trash, buy some food...). I was too burnt out to start making my bags for going to Vienna (I'm leaving tonight!), work on the pending systems I have to work on, or even stay awake.
Leaving work for a week to go a conference is always fun and great... But man, it's stressing!

I got a few replies to my post about UMTS and finally ordered the flatrate from Moobicent as they use the Vodafone net. Vodafone got the best recommendations in the replys and is also the only one that has UMTS available in the area I want it… Basic summary of the comments is - Vodafone is the way to go as they (currently) have the best UMTS network. Even in Portugal, it seems, so if I plan a vacation that seems to be a good place to stay online during it. :) I also got the tip to always have a data transfer running in the background as it seems to make working with ssh way more comfortable. That should be simple to arrange. :) I already got the registration e-mail from Moobicent, my username and, in a seperate mail, my password to login to their service. I just need to wait for the hardware before I can start with that stuff. There was a big rant here first, about how “nice” it is to send you your username and your password in two unencrypted mails (sent at the exact same second, no difference in the header part beside subject and the SMTP id postfix puts in…………..). I decided to delete it, doesn’t help anyway. Instead I decided to play with Amazon wishlist a bit. Thats better for my blood pressure. :) Anyway, Im happy to have ordered the stuff and would love if the hardware would already be here (it will probably arrive on Friday/Saturday, I hope, having ordered on Wednesday). Oh my, lets play in NEW a bit, that usually kills lots of time… :)