My Python development environment consists of a GVim window for editing code and a gnome-terminal for running the unit tests. This works out well, but leaves some integration to be desired. In particular, jumping to a test failure point is a little cumbersome. I used to do it this way: copy the filename from the traceback, switch to vim, then type :e, paste the filename with middle-click (now I know I can use * instead) and press Enter, then enter the line number and press G. That is barely acceptable; this particular wart has even contributed to pushing a ex-co-worker towards Emacs (the horror!). I have written a small vimscript function to make the aforementioned use case slightly easier. Now to jump to a failure point, just triple-click the corresponding line in the traceback (that selects the whole line), switch to Vim and invoke the function, which scrapes the clipboard for a filename and line number and opens it in the active buffer. Installation: paste the OpenFileFromClipboard function in your ~/.vimrc and bind it to a key by adding the following lines to your .vimrc:

nmap  :call OpenFileFromClipboard()
imap  :call OpenFileFromClipboard()

These commands bind the key F4 to our function. The first command handles normal mode, and the second handles insert mode (hence the to momentarily escape the insert mode). You can of course change the shortcut to whatever you like. The function should handle following types of references from the clipboard:

• /etc/passwd
• John saved his work to ~john/doc.txt and left.
• File "/home/gintas/devel/project/tests.py", line 123, in tests.py
• /usr/include/stdio.h:333:extern int sprintf (char *__restrict __s,

I hope someone finds this useful.

Satellite TV commented:

"Wow, all that seems pretty complex to me. The U.S is so much more simple, we just chose Dish Network or DirecTV or some kind of cable and call it a day. Then again I don't know if thats a bad or a good thing."

That's a bad thing. Look at the situation: In the US, there seems to be very little free-to-air (FTA) satellite TV for most of the country, except PBS and religious channels. The main US FTA FAQ answers "Should I drop cable/Dish/DirecTV and switch to FTA?" with "Probably not." I'd say "Probably yes" to similar questions in Europe, as long as you aren't dependent on one of the few incompatible pay-TV channels. Channels like MTV, Nick, TVEi and DW are all pay-TV in the US, but FTA in Europe. But if you're in the US, look on the bright side: Canada seems even more behind on this. In Europe, you can still call whatever satellite broadcaster (such as Canal Satellite, Premiere or even Sky) and get a system installed if you choose, but you can also install your own. That's what my FAQ is about: giving people in "the land of the free TV" some starting info on how to do that. Some broadcaster-supplied systems only really work well with one broadcaster's "approved" channels (Sky are particularly bad for that), are more expensive to upgrade than standard systems and don't give viewers the equipment to repair it when it breaks, which encourages them to keep paying the broadcaster's agents. Some of those agents do some pretty dishonest tricks when installing dishes, such as putting them far higher up than necessary, to discourage viewers from fixing it themselves and to advertise satellite TV to the neighbours. It's pretty easy to install a standard satellite system... if you can put up a wall bracket and tune in a video, you can probably do it. Alternatively, there are independent installers who will do it for you, who might seem like they charge more than the broadcaster's agents, but remember that a good one won't keep charging you every month or try to sell stuff to you forevermore!

Scientific papers always have a “related works” section, where the authors describe how the work they are presenting compares with what others did. In the Free Software world, this is nearly non-existent: in a way, it seems that many of us are thinking of their projects as competing products, fighting for market share. On a project web page, I would love to read something like:

This project is particularly well suited if you want XX. But if YY is more important to you, you might want to have a look at ZZ.

Or simply links to similar projects for other environments, etc. All in all, I think that the goal is to improve the global satisfaction. Not to win a few users, who won’t be totally happy, because the project doesn’t really suit their needs. While some projects cooperate and share ideas, like I think desktop environments do inside freedesktop.org, most just ignore each other. I am both a Debian and an Ubuntu developer, and I’m sometimes amazed that Ubuntu discusses technical choices that were discussed (and solved) a few weeks earlier in Debian. And it’s even worse with the other big distros out there. Couldn’t we try to improve this ? We could just create a mailing list, where developers from various distributions could present the way they do things. This would allow to discuss future developments (”We are planning to improve this, what are you doing about that ?“) or simply to improve people’s knowledge of the various distributions. Of course, this could easily turn into flamefests, but they are technical ways to avoid that, like moderating posts from trollers… Does something like that already exist ? Do you think that it would be interesting ? Would you like to contribute to such a forum ? Some examples of things that could be discussed:

• How many packages do you have, and how do you support them ? Do you have several “classes” of packages ?
• How do you manage your releases ? Goal-based ? Time-based ? Bug-count-based ?
• Which kind of quality assurance do you do ?
• How many contributors do you have ? Are they split into different “classes” ? Who has “commit rights” ? Can you give out “commit rights” restricted to subsets of your packages ? A organized sponsorship system for people who don’t have commit rights ?
• etc, etc, etc.

Argh... I know it seems like I've given up on blogging entirely, but that's not the case. I've just been spending a lot of time working on Evan Prodromou instead of on evan.prodromou.name, which has been a whole different kind of world. I'm mostly poking my head up to point to an article in the Montreal Gazette about my new project, Vinismo. Montreal entrepreneur uncorks Wikipedia of wine, says the headline. I guess that "Montreal entrepreneur" is little ol' me. Go figure! The article is nice and balanced -- it covers the obvious fact that one month after launch Vinismo is not the definitive end-all be-all of wine information... yet. Roberto Rocha, the article's author, is doing a great job covering local entrepreneurs and the startup Internet scene, and I'm glad that our site got his vote of approval. And check out the photo they took of me and Niko at the excellent Pullman Wine Bar. How sophisticated. Glad to be getting some press about the site, and good news for Vinismo. tags: wine vinismo montreal gazette me press

BarCampCanada1 I managed to convoke the very busy trio of Sylvain Carle, Simon Law and Fred Ngo yesterday afternoon at La ka to nail down some plans for this fall. (We were lucky enough to get the funny and insightful Madame Woo to help out, too.) The cement's not dry yet, but it looks like we're going to have BarCampCanada1 here in Montreal the 9-10 of Novemeber. That gives us about 8 weeks to plan out what we hope will be the biggest BarCamp ever in Canada. tags: barcamp barcampcanada1 barcampmontreal

Just completed the migration of the next version of apt-cross that is due to be uploaded once dpkg-cross pre2 can be uploaded to experimental. (This in turn is waiting for dpkg to support removal of the dpkg-cross diversions: #439979.)
AptCross:: has gone, replaced by Cache::Apt:: and the Cache.pm from NorthernCross is now called Lookup.pm for clarity.
This update solves a lot of niggles with the old apt-cross behaviour when dealing with non-standard repositories, CDROM archives, proxied mirrors and various other stuff that apt can cope with but which wget found difficult. (#440929, #442012)
Also, the entire package has migrated to GPL v3 or later - all the code was GPL v2 or later.
This means that emdebian-tools will also be migrating to GPL v3 or later when that is updated to use the new apt-cross and dpkg-cross code.
Sometime after Lenny, Cache::Apt:: will migrate into a source package of its own (on CPAN), allowing the apt-cross functionality to be merged into apt and the module to support other tasks in Emdebian.
In other news, gpe-cash is coming along and highlighting a few issues in libqof1, libqof-backend-sqlite and libqofexpensesobjects so there are improvements due there too. gpe-cash and gpe-expenses are also GPL v3 or later, as are deb-gview, quicklist (experimental) and pilot-qof now too.
Most have some machine-operable fields in debian/copyright and most have the new dpkg fields in debian/control.
Got a fix for gpe-bluetooth to upload tonight as well as (hopefully) the last go at getting homebank through NEW.

Bah, MySQL keeps insisting on being a fun way to waste your time.
One of my clients hosts its systems at Dreamhost, a quite nice hosting company, which has... Well, a couple of strange details :-/
Anyway, people who work with databases know that a BLOB (or its equivalent) is the right datatype for storing images or, in general, files, right? After all, BLOB is just an acronym for Binary Large OBject. And if somebody has a BLOB field in the DB and searches on it, most RDBMS-bound programmers will at very least chuckle at a design flaw - BLOBs are just to be stored and retrieved, that's it.
Well, the system I wrote for this client uses a BLOB field - Ok, to be clear: I just declared it as a :binary in the corresponding migration. That should do the trick, and should allow me to keep my system RDBMS-independent, right? So I can still work on my development system using nice-and-trusty PostgreSQL
Anyway... My client said some documents were being corrupted. And that is Not Nice^TM... Documents were being truncated at 63Kb. The bug was consistent across the three instances of my system in Dreamhost, but could not be reproduced at my machines - It didn't take too long to find out it must be the DB (and that's partly because I don't really trust MySQL :) ).
Turns out that, in MySQL speak, there are four types of blobs: TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB. Forgoodnessake, WHY?! The stupidiest one is the tinyblob: A Binary Large OBject limited to 8 bits (255 characters). Regular blobs are 16 bit long (65535 characters - Aha! That's your 63.99Kb limit!). Mediumblobs are 24 bits (16 million), and longblobs are 32 bits (4000 million). And, of course, the blob datatype is not large at all.
Bah.
Anyway... At least this is an open and known issue already to the Rails people, and I do expect them to change the migration equivalencies to something saner.
Bah again.

I am stumbling again on the problem of not being able to install libgnome-dev and libsvn-dev side by side, namely bug #429025.

For some reason, I was under the impression that the bug was fixed... but apr-util is behind :-(.

So, this time it was for real! AMD really meant it when they announce the release of specifications of ATI boards last weeks. During XDS2007 at Cambridge, we received the actual specs, 2 PDFs files, 460 pages for the M56 (Mobility X1600, r5xx board) and 436 pages for rv630. The files are now online, but I am not going to give the link here since the web server already suffered too much today (and the URL is easy to find anyway). People should NOT understand this as if we were going to get an open-source driver for all ATI boards next weeks. First, these are only 2D specifications for r500 and r600. 3D specs are expected in a couple weeks once AMD fixes the remaining issues. r300 specs might arrive later. Also, these specifications are pretty hard to use, as expected. There are something like 9000 registers in r6xx boards, and these PDF files are just description of these registers. It's of course far away from being a "How-to write a driver?". So if you want to help, there will be lots of things to do. We also got a demo from some Suse guys of the driver there are working on. They got these specs about 2 months ago. And they already have some part of modesetting working. It means you might get your X server to start. There are about one hundreds different chipsets with their own quirks, so still lots of work to do. And then lots of performance things, 3D, ... to do. This driver is called "Radeon HD" so far. It will remain separated for now, but it might end up being merged with the upstream ATI driver later since the 3D engine are very similar (I personally hope it will happen). The reverse-engineered Avivo driver is dead now then. Fortunately, Jerome Glisse has been aware of the event for a couple months now, so he didn't waste to much time working on it. xserver-xorg-video-avivo will remain in Debian experimental until the new driver arrives. The good thing about Avivo is that it (and the ongoing Nouveau driver for Nvidia) led to the development of very nice reverse-engineering tools (revenge, renouveau, mmio trace, ...). They will be very useful for other graphic boards, or even some network hardware. Of course, many thanks to AMD for making this happen!

For my diploma thesis (on clustering of high dimensional data, especially correlation clustering, i.e. clustering data by properties such as data correlation) I needed an easy way to filter out data from CSV files as used by gnuplot (actually, they are whitespace-separated).I hacked together a small tool that would allow me to easily 'grep' out certain parts of the datasets. If you know of a similar tool, please send me an email to erich AT debian DOT org.Currently, the tool allows you to do commands such as:

gpgrep "1~5$" "1200"  out/3d-2lin-noise.variances

to select ('grep') all sets where the first column ends with a 5 (regular expression match) and where the first column is less than 199.The tool is still in early development. Syntax may change, and I guess I'll add some more filters. But you get the idea. Focus is on a very compact syntax.A future filter I'm considering would e.g. select 20 random rows (with a fixed seed value, so it's reproduceable!) for sampling and a modulo-match to select e.g. every 7th row.Maybe I'll also add some output processing later, such as averaging values, calculating variances and mean deviations, stripping away columns (but you can do that in Gnuplot already). I don't want to overdo it though - it's just meant as a mini filter you can add to script output visualization. It's not meant to replace a full statistics toolkit.So if you know of a simple tool that can do that already, please tell me.P.S. a few people have pointed out awk. Yes, it can do most of this. One thing I also need, and I'm not sure on how to do that the easiest way in awk is to preserve 'blocking'. That is empty lines. Because the data set

1 1
2 2

1 2 2 1 are two lines with two points each in gnuplot, not one with four points. I guess you could just do a "/^$/ print ", though... hmm... looks like I finally have to learn awk. So far I've always been refusing to learn awk, I was happy with sed, perl and python...

The release plan for Xserver 1.5 and Xorg 7.4 was discussed during the X.org Developers' Summit in Cambridge (September 10-12th). This is what we expect to ship with Lenny, so here are some details about the upcoming. Timeline As usual, there will be a 6 months release cycle. So Xorg 7.4 is expected on March 1st, 2008. There won't probably be any new Xserver release before that since some changes (already merged) require all drivers to be updated anyway. So Xserver 1.5 is expected on the same date. Since there are already some known problems in Xserver, they also plan to release Xserver 1.4.1 on November 1st. PCI Rework The master branch of Xserver already contains the long-expected pci-rework which is supposed to fix all the PCI domains and other non-trivial PCI hierarchy support (important for ia64, but also for some powerpc and sparc users). RandR People having Intel, ATI or recent Nvidia boards learnt to love the RandR 1.2 extension which provides the ability to enable/disable, resize, rotate, move outputs within a single big virtual screen. More transformations should be possible with RandR 1.3. Hopefully, there will also be some standardization regarding output names in various drivers, or at least a way to retrieve the type of each output (LVDS, DVI, VGA, TV, ...). And the server should get an abstraction object to describe GPUs, which might make the support for multiple boards easier. Input On the input side, XKB 2 and XGE should be merged, which shouldn't be really visible to end-users but should make internals much better. Then MPX (Multi-Pointer X server) might be in Xserver 1.5 too (if all semantics issues get fixed first). It would mean support for multiple independent keyboard/mouse pairs or so. See the MPX page for details. Compositing Compositing still gets a lot of attention. Several distributions are actually thinking of enabling Compiz by default. EXA (the new acceleration architecture that has been designed for compositing) got improved a lot in Xserver 1.4. Several drivers including Intel and ATI r300 already work great with EXA (no need to use XAA + XAANoOffscreenPixmaps anymore) which means Compiz works very smoothly, even when resizing windows. XAA won't be removed soon though since lots of things needs to be fixed before that. There are also several videos available online, like this one. But one big piece is still missing for compositing: directed rendering to redirected windows. So far, if you start glxgears in Compiz, you will see that the gears completely ignore wobbli-ness of windows, other windows overriding them, cube rotation, ... they keep rendering of top of everything without any effect. Getting true support for compositing such windows requires lots of work in all parts of the DRI stack. Kristian H gsberg got it to work (and we even get a great demo). See Kristian's blog for details. Upstream devs are now working on integrating all modifications nicely in upstream Xserver, drivers, DRM module, Mesa, ... Once this works, you can get GLX_EXT_texture_from_pixmap for both direct and indirect rendering, and full support for GLX 1.4 in the server (only 1.2 is supported as of now). Also, redirected windows (let's say a wobbly window on a side of Compiz' cube) should get input events correctly thanks to input transformation in Xserver 1.5 (event coordinates will be converted into the redirected window coordinate space before being passed to the client application). Kernel-related reworks Compositing improvements actually require a large rework of the memory management in the server. Basically, we need a global management for both 2D and 3D object allocations, so that you can get both to work fine without having to change config options (things like XAANoOffscreenPixmaps or FbTexPercent). All this is related to the TTM (Translation Table Maps, see these slides for details) which has been under development for a while. It requires to change the interface with the kernel DRM modules, and it won't happen before 2.6.24. The Xserver part of the work is not big, so it might still be done before 1.5 is released. Fortunately, once all this is ready, people should stop complaining about memory allocation failures, Compiz being slow because one option is not enabled by default, ... Another hot topic in the X.org/kernel area is about moving modesetting in the kernel. When you get a kernel panic, you only actually see it if not running X (or if logging kernel messages through the network). So your machine freezes, you don't know why, you have no way to know, and you just reboot. Getting panic messages on X would be much better. To do so, the kernel needs to now which mode is currently in use on the monitor and then it will render the message on the framebuffer. This require lots of work, so it will unlikely be in Xserver 1.5 though. Miscellaneous Xserver 1.5 will also contain XACE (security framework), the cleanup of the ABI (explicit _X_EXPORT required), and possibly glucose (OpenGL acceleration for X, see Zack Rusin's blog). I asked whether there was actually some work on building the GLcore server module as a part of Mesa so that building Xserver does not require the whole Mesa source anymore. People seem to agree the current situation is a real pain for distributions and we should make this change happen. But the actual work has to be done in Mesa anyway, we'll see what happens.

Several months ago, I announced that I'd received a grant from mtvU and Cisco to work on a cool voting technology research project called Selectricity. A project in quotidian democracy, Selectricity attempts to apply some of the best voting technology and election methods research towards every-day decision-making. It takes research I did at the MIT Media Lab and packages it into a real, useful, application. I spent probably half of my time over the last several months managing a team of competent hackers and designers as we've built out the project. Last week, press releases and news stories went out as we launched our first production batch of features and a new design. You can check it out online at:

http://selectricity.org

There is a whole line-up of a groups and organizations, some high profile, that will be using the software in the coming months. There's also half a dozen killer new features that are built and waiting in the wings for a little polish and fanfare. We'll be testing and releasing those in the next couple months. No doubt, I'll be mentioning bits and pieces of my work on the project on my blog here. However, if you want to follow development, you should subscribe to the Selectricity News Blog where more full coverage will take place. You can leave feedback, suggestions, and bugs as comments on the blog or email it to team@selectricity.org. The election method code is already published and we'll be releasing the rest of the code under the AGPLv3 when the license is released by the FSF in the next few weeks.

My mother just asked me to get Google Earth (link to download page [1]) working on her machine so she can see where my sister [2] lives. So I download all 20 megs of the sucker (of course it had a horrible license agreement that precludes packaging for Debian or any other sane distribution) and ran it (under a different account of course because I don’t trust non-free software). It’s unfortunate that Google weren’t prepared to put in the extra effort of making Debian and RPM packages for it. When I examined the contents of the file there were sym-links from FreeBSD, NetBSD, and OpenBSD to Linux and from amd64 and x86_64 to x86. So much for portability, just assume that everything is an i386 running Linux! The first problem I encountered is that it doesn’t support installing in text mode and demands X access, have the Google people never heard of sys-admins who do their work over low-bandwidth links and don’t use X? What happens if your sys-admin is using a braille terminal? When I enabled X by “ssh -X” I encountered the error below (Error 1). It seems that the installation program was not written with the X11 Security Restrictions in mind and only works with “ssh -Y“. The same applies to actually running the program once it’s installed. Finally it gave me a GNOME error dialogue about the Bitstream Vera Sans font not being installed. If they had made a Debian package then it could have depended on the package that provides the font in question. Now I’m left wondering which package provides it, and whether it’s even available (maybe they depend on non-free fonts). Once I got it working I found it to be incredibly slow on my Pentium-M laptop with 1.5G of RAM. I ran it on a Pentium-D desktop system in a Xen DomU (it’s only 32bit and I couldn’t figure out how to get the AMD64 version of Debian to run i386 programs without a chroot or a Xen instance). But it still wasn’t particularly fast. One problem is that the GUI is not well written, so I drag the Earth to rotate it from the initial view and the Earth moves slowly long after I have released my mouse button. Another is that my X server started using significantly more memory while it was running (and has not returned to it’s previous size). Google Earth is a really neat program that does some nice things. But I’m not going to buy a new Thinkpad to run it, and the experience of running it on a Pentium-D server is not that great either. I’ve just rm’d it from my laptop, I’ll leave it installed on the server but probably won’t run it often. I’ll try installing it on my mother’s computer (Celeron 2.4GHz with 512M of RAM) but I am not expecting it to run well. The machine is still new to her, I replaced her Pentium3 800MHz with 384M of RAM about a week ago. She never found the Pentium3 to be slow (and I don’t think that Google Earth is a good reason for an upgrade).

• [1] http://www.earth.google.com/download-earth.html


• [2] http://helen.coker.com.au/

(more…)

Share This

Joey started a stats pron meme, so lets join, with stats from packages.debian.org AKA puccini.debian.org, which I am the local-admin for. This machine has

	2007
Unique visitors	4952207
Total visits	8572139
Total pageviews	43332086
Total bandwidth (apache only)	783.28 GB
Additional traffic due to robots	53328963 pageviews adding 265.73 GB traffic

Looking at the other statistics April and May had a few percent more visitors, but other than that its pretty stable with around 600k unique visitors per month. We do not resolve IPs to hostnames due to the huge amount of useless traffic and load this would generate, so no statistics about the countries. But we do have some other stats. Like a Robot/Spider statistic. It looks like we had about 151 different spiders on our site, a few listed below.

Yahoo	is the most active spider, making some 97.54 GB of traffic
Googlebot	follows on second place, responsible for 43.92 GB
MSNBot	caused about 21.52 GB traffic
Python-urllib	is used by multiple bots and they all made up 43.29 GB traffic

Next interesting point is that of Operating systems.

Linux	is of course the most used one, 48.1% of our visitors told us they use it.
Windows	only on place 2, with 40.5%.
MacOS	all kinds of MacOS add up to 2.5%.

There are various others in the list, but none with more than 1%. Like Sun Solaris which was used for about 63k hits (compare it to Linux with 32 378 942 hits). 5423 users did want us to believe they use CPM, another 76 tried that with VMS. Of course we are interested in more details for the 48.1% Linux users, here they are:

Debian	15397537	22.8 %
Ubuntu	9050014	13.4 %
Suse	542635	0.8 %
Red Hat	107240	0.1 %
Mandriva (or Mandrake)	166545	0.2 %
Fedora	623242	0.9 %
Centos	69998	0.1 %
GNU Linux (Unknown or unspecified distribution)	6421731	9.5 %

Windows is boring, more than 33% are using the XP crap, all BSD version together, including that GNU/kFreeBSD variant have 0.1% all together. Browsers? Of course people do use lots of different browsers. The main browsers, if you ignore all the various versions, are Firefox with 44.7%, (shudder) MSIE with 17.7% and Mozilla with 14.6%. Konqueror is far behind with only about 8.5%, other browsers like Opera (3.4%) and Epiphany (1.5%) are even less used. One browser identification is interesting, namely Debian APT, which seems to be the “Fetch Changelog” function of aptitude. It generated about 200k hits (0.1%). Next point - from where do we get most people to our site? That are people not having any kind of referer information, 65%. The second place here goes to - yes, direct links from various people. Of course our search interface has most hits here, the rest is from some 80k different pages linking to us. Most of those seem to be upstream pages telling their users where to get a Debian package from (most are named something that fits “/software/download” or “is like sf/freshmeat” schema). Interestingly the links the BTS provides in their package overview going to packages.debian.org aren’t used all that much. Only about 30k hits in the whole year 2007 with the BTS as referrer. Only after all those individual links we have search engines giving us hits. That may be partly due to the fact that we did use robots.txt to block them (at least those that are good net citizens) for a long time from indexing our site. Final words: YES, I do know that the stats are likely to be wrong in any size you want them to be wrong. Yes, one cant really trust the User-Agent string, its too easy to change it. Yes, its easy to filter out referer, etc, etc, etc, but IMO its still nice to look at such things, it gives at least a little feeling for what we do burn all those CPU cycles. These stats are based on about 4.5GB of compressed apache logs from the last few months, it took some 14 hours to process the logfiles. Luckily future updates now happen once an hour and take only a minute or two… Ohh, you say Joeys meme was about mail stats? Damn. Ok, short text: 305k mails rejected in the last 7 days while we allowed 1097 mails to pass. For the yearly overview that means some 9.3million rejected and 73k accepted mails (that rate should get better, decreasing the accepted count, with the new etch setup we have now). Of course this isn’t as impressing as lists.debian.org mailstats are. :)

Given that Hecl is very much tied to the Java ME platform, this question is pretty important to me. I was thinking about simply posting it here, on my line journal, but having recently started reading The Wisdom of Crowds, I decided to have a little fun with it, and created a "prediction market" on the Inkling Markets (a YCombinator startup) web site: http://home.inklingmarkets.com/market/show/6481 Of course, if you just want to comment on your answer, that's ok too. My thoughts on the current possibilities:

• Java ME. Widely available right now, but Sun has made a few false steps. For instance, the difficulty of writing something that runs everywhere is a high barrier for hobbyists or small companies.
• JavaFX. Apparently, this exists because Java is seen as being not quite scripty enough to compete with dynamic languages, something that I think is a legitimate concern. However, it currently is not deployed, so it's hard to say what its future will be.
• Web/Javascript. If mobile phones get better/cheaper connections, it would be easy to see them going the way of the rest of the world - rather than native applications, they'd simply be html/javascript apps. Doesn't work for games and some other things, but makes deployment very easy. The big if is the network operators and what they want to do about traffic costs. Apple, for the moment, seems to be taking this route.
• Python. Currently available for Symbian. I don't see it as a big possibility, but who knows.
• Qt. Troll tech is currently shipping a development device, the "green phone". Since it's proprietary, this one seems like a long shot too, but you never know.
• Other. GTK on Linux, Tcl/Tk... maybe even Hecl! In this field, things can be tilted upside down surprisingly quickly, although that's not quite so true for anything involving physical devices.
• None. Java ME becomes less popular, but nothing concrete supplants it, and we end up with a hodge podge of technologies, with no clear leader.

In any case, I think it's a space that's bound to be very interesting, and loaded with interesting possibilities. Update YC.news user jsjenkins points out a silly oversight on my part: Flash Lite. It slipped my mind completely, but is certainly an important player in this market. The Java folks have to be hoping that history will not repeat itself.

It's been a busy week for Koha development, really. Some of my thoughts:-

[Koha-devel] ANNOUNCE: New Installer in master git tree

I announced the new Koha installer. It's not finished (see under KNOWN BUGS), but people are starting to use it, so I thought I'd better announce it. I'll explain more soon.

[Koha] AG KohaLa

The Koha Free Association is about to hold its first General Assembly, so I reposted the announcement. Anyone know what foreign developers should do about it, if anything?

Taking the Open Road: University Libraries Explore Options

Interesting article in E-commerce Times which mentions Koha as one of the more specialist packages libraries are investigating. Good!

Slashdot Libraries Defend Open Access

Not koha, but funny: Legacy journal publishers don't like Open Access? I'm shocked. Or something. Some of the comments are hilarious. Others remind me why I don't read much /.

So, progress has been moving on nicely on a tool for generating gobject-introspection xml. Development’s getting pushed forward now by two veritable geniuses, J rg Billeter and Mathias Hasselmann. We’ve got sparse able to handle extended attributes, so headers can be marked up with details like ownership of returned data. There’s also a git branch of gobject-introspection where we’ve been delveloping some python code that takes the headers, runs sparse over and generates some basic introspection XML, using ctypes to call into gobject for getting interfaces, signals and properties. Very Nice! BUT, we’ve hit a big problem. Sparse is licensed under the Open Software License 1.1. Debian considers this non free, and it certiainly looks to have some overly onerous clauses. Linus did try to relicense it a few years ago, but hit a brick wall with Transmeta, who own some of the copyright from when Linus worked there. We might end up having to drop the use of sparse and maybe have our own bison-based parser. We really don’t want to have to go there though. So, here’s my lazyweb request - Does anyone out there know anyone at Transmeta that we could talk to about relicensing this work? It might be worth pointing out to that it might be in their interests, given the patent termination clauses.

Continuing my mission to put together a kick-ass team to develop the Ubuntu Desktop, the following position is now up on the website: Posting Date & ID: September 2007 UDD
Job Location: Your home with broadband. Some international travel will be required.
Job Summary: To adapt and develop the GNOME desktop to improve the Ubuntu user experience. Key responsibilities and accountabilities:

• Use open source development methods to create, select and adapt software to produce innovative user experiences and address the common problems of desktop computing
• Extend the desktop platform as necessary to support development
• Work with designers, artists and other developers to develop ideas and complete the project
• Involve the community of development projects, teams and Ubuntu supporters to incorporate a range of perspectives and ideas
• Take ownership of many aspects of the desktop user experience (“look and feel”) in Ubuntu
• Follow projects and trends in user interface design in the open source world, integrate the best technologies into Ubuntu and ensure their quality
• Analyse, triage and respond to bug reports

Requirements skills and experience:

• A keen and insightful eye for user interaction
• A passion for intuitive, usable and visually appealing interfaces
• A strong desire to produce distinctive ideas that stand Ubuntu out from the crowd
• Experience with the GNOME development platform and desktop environment and technologies such as GTK+
• Some experience with mainstream graphics technologies such as OpenGL and Cairo in the C programming language
• Ability to be productive in a globally distributed team through self-discipline and self-motivation, delivering according to a schedule
• Familiarity with open source development tools and methodology, especially those in common use for Ubuntu and Debian package maintenance

How to apply Please send a cover letter and CV with references to hr@canonical.com. Please indicate in your submission the role for which you are applying. We prefer to receive applications and CVs/Resumes in either PDF or plain text format.

I have just read an interesting post about Gear Acquisition Syndrome [1] as applied to the guitar industry. Apparently it’s common for people to spend a lot of time and money buying guitar equipment instead of actually playing a guitar. I think that this problem extends way beyond guitars and to most aspects of human endeavour, and that actively trying to avoid the problem is a key to getting things done. I believe that the author however makes a strategic error by then going on to advise people on how to buy gear that won’t become obsolete. Sure it’s good to have gear that will suit your future needs and not require replacement, but if you are repeatedly buying new gear then your problem usually is not that the gear doesn’t do the job but that you want to buy more. I used to suffer from this problem to a degree with my computer work, and still have problems controlling myself when I see tasty kit going cheap on auction. Here is a quick list of things to do to avoid GAS:

• Recognise the problems with getting new gear. It costs money (thus requiring you to do more paid work or skip something else that you enjoy). It needs to have the OS installed and configured which takes time away from other things (unless your job is related to installing software on new machines). Finally it might be flawed. Every time you buy a new computer you risk having a failure, if it’s a failure that happens some time after deploying the machine then it can cause data loss and down-time which is really annoying.


• Keep in mind what you do. I primarily do software work (programming and sys-admin). While some knowledge of hardware design is required for sys-admin work and the ability to make my own hardware work is required for my own software development I don’t need to be an expert on this. I don’t need to have the latest hardware with new features, the old stuff worked well when I bought it and still works well now. My main machine (which I am using to write this post) is a Thinkpad T41p, it’s a few years old and a little slow by today’s standards but for everything that really matters to me it performs flawlessly. If your job really requires you to have experience with all the latest hardware then you probably work in a computer store and get access to it for free!


• When you have a problem think about whether new gear is the correct solution. There are a couple of areas in which performance on my Thinkpad is lower than I desire, but they are due to flaws in software that I am using. As I am primarily a programmer and the software in question is free it’s better for me (and the world) if I spend my time fixing the software rather than buying new hardware.


• Buy decent (not hugely expensive) gear so that you don’t need to continually buy new stuff. EG if a machine is going to store a moderate amount of data then make sure it has space for multiple hard drives so you can easily add new drives.


• Don’t buy the biggest and baddest machine out there. New hardware is developed so quickly that the fastest gear available now will be slow by next-year’s standards. Buy the second-fastest machine and it’ll be a lot cheaper and often more reliable.


• Determine your REAL requirements that match what you do. As I do software it makes sense for me to have the most reliable hardware possible so I can avoid stuffing around with things that don’t interest me so much (and which I’m not so good at). So I need reliable machines, I will continue buying Thinkpads (I plan to keep my current one until it’s 5 years old and then buy another), I believe that the Thinkpad is the Rolls-Royce of laptops (see the Lenovo Blogs site for some interesting technical information [2]) and that continuing to use such hardware will keep me effectively using my time on software development rather than fooling with hardware. For desktop machines I have recently wasted unreasonable amounts of time due to memory errors which inspired me to write a post about what a company like Dell could do to address what I consider the real needs of myself and other small business owners [3] (note that Dell is actually producing more suitable hardware in this regard than most companies - they just don’t market it as such).


• Keep in mind the fact that most things you want to do don’t require special hardware. In fact for most tasks related to computers people were doing similar things 10 years ago with much less hardware. If you believe that it’s just the lack of hardware that prevents you from doing great work then your problem is self-confidence not hardware availability.

It’s interesting that a sports-shoe company has a slogan “Just Do It” while trying to convince people that having special shoes is required for sporting success. Most professional athletes started training with minimal equipment. Get some basic gear and Just Do It!. References:

1. http://www.harmony-central.com/Guitar/Articles/Avoiding_GAS/


2. http://www.lenovoblogs.com/insidethebox - feed: http://feeds.feedburner.com/lenovoblogs/insidethebox


3. http://etbe.coker.com.au/2007/08/25/designing-computers-for-small-business/

Share This

I sadly read that Warsow are having internal problems. It’s a pity, because it’s a great free game (even with its non-free game data), and they deserve the best. In any case, I just wanted to talk about this because of something that’s quite usual in the development of free games: having non-licensed data. According to tigerchas’ note: “The non-licensed state of warsow media is what has allowed this to happen - and the team is now working on rectifying this. This whole episode has been very unsatisfying and has highlighted the problems of not having a global media license for warsow”. I’m not worried about the future of the game at all, it’s not that the reason I’m writing this entry. As they also say in the same post: “Don’t let this announcement affect you too much, warsownians. warsow has hit minor stumbling blocks in the past and this is simply another. Maps can come and go. Rest assured that the current mapping team will be working on other great maps for you to enjoy”. What I wanted to point out with all this, especially to games developers and teams, is that even when licenses are boring stuff and many of you might think that you can safely ignore them and it won’t affect you, especially when you start the development, reality shows that these things happen. I wish all the best for the Warsow team anyway, and to go soon over this. Keep up the good work!

A common question is how to compare Fedora [1] and Debian [2] in terms of recent updates and support. I think that Fedora Rawhide and Debian/Unstable are fairly equivalent in this regard, new upstream releases get packaged quickly, and support is minimal. They are both aimed at developers only, but it seems that a reasonable number of people are running servers on Debian/Unstable. Fedora releases (previously known as “Fedora Core” and now merely as “Fedora”) can be compared to Debian/Testing. The aim is that Fedora releases every 6 months and each release is supported until a release two versions greater is about to be released (which means that it’s about a year of support). The support however often involves replacing the upstream version of the program used to make a package (EG Fedora Core 5 went from kernel 2.6.15 to kernel 2.6.20). I believe that the delays involved in migrating a package from Debian/Unstable to Debian/Testing as well as the dependency requirements mean that you can get a similar experience running Debian/Testing as you might get from Fedora. Stable releases of Debian are rare and the updates are few in number and small in scope (generally back-porting fixes not packaging new upstream versions). This can be compared to Red Hat Enterprise Linux (RHEL) [3] or CentOS [4] (a free re-compile of RHEL with minor changes). Regarding stability and support (in terms of package updates) I think that Debian/Stable, RHEL, and CentOS are at about the same level. RHEL has some significant benefits in terms of phone support (which is of very high quality). But if you don’t want to pay for phone support then CentOS and Debian/Stable are both good choices. Recently I’ve been rolling out a bunch of CentOS 5 machines for clients who don’t want to pay for RHEL and don’t want to pay for extensive customisation of the installation (a quick kickstart install is what they want). The benefit of Fedora and Debian/Testing over RHEL, CentOS, and Debian/Stable is that they get newer packages sooner. This is significant when using programs such as OpenOffice which have a steady development upstream that provides features that users demand. If you want to try new features then Fedora and Debian/Testing are both options that will work. One reason I had been avoiding serious use of Debian/Testing is that it had no strategy for dealing with security fixes, but it seems that there are now security updates for Testing [5] (I had not realised this until today). References:

1. http://fedoraproject.org/


2. http://www.debian.org/


3. http://www.redhat.com/rhel/


4. http://www.centos.org/


5. http://secure-testing-master.debian.net/

Share This