Digested

With things at work at a voluntary standstill, I've been enjoying having time to do some coding. A project that has been kicking around in my mind for at least a decade, with a couple iterations that shrivelled on the vine, is some way to track all the stuff that comes in each day, and which should all eventually be invoiced.

So a while ago I dusted off my very limited c++ skills and dove into the Qt4 api. As expected, the challenge is not so much the syntax. Using a library written by someone else requires getting into their thoughts to be able to make things work. Having done some gui stuff on OS/2 and Windows(very limited) in the past, I knew what I needed, and the learning was how to get Qt4 to give it to me.

I've found that if I feel the need to bend things around, I have missed something. In fact, most everything is quite easy and quick, once you find the class and method that you need to override. Learning which is the slow part of the process.

So I've figured out sql, models, tables, proxy models (finally stable in 4.2.2). The model-view architecture is very powerful. I had a familiar feeling of being totally lost and seemingly unable to grasp the fundamentals. Very satisfying. Already I have seen where KDE will be useful, ie. the date picker widget. I'm about to start delving into the calendar and contacts api's in kdepim. I intend to use the data entry and syncing of data from other sources that is built into the kdepim libraries. That should save me some work.

So here is a picture. Nothing is even close to being useful yet, still working on getting various data entry issues sorted out.

The structure of the application is to take seemingly random and unorganized data from all sources, ie. phone logs, vcalendar files, scanned and ocr'd documents, scheduled work and the odd data entry, and allow users to sort through it all quickly, assigning each event to a job. The job will then be organized further, some explanations and cleanups of the raw data, eventually outputting an invoice. We generate a huge amount of stuff, doing on average 4-5 jobs each a day, each with callbacks, parts ordering, some warranty issues. The only real roadblock so far is the lack of good free ocr software.

In no particular order, here are some highlights from the year. Absolutely selfish and from my perspective.

Danny Allen started producing the Commit Digest, with the first issue on April 9th. Scroll through, and you will see a week to week report of the development effort. This is an enormous effort, and Danny deserves kudos and intoxicating liquids (except on the weekends. Send something healthy like, umm, celery. Otherwise he won't be able to produce the report). The uninformed who talk of what they know not have obviously not been keeping up. Thanks Danny.

DBus and HAL have become ubiquitous parts of the desktop infrastructure. Even though KDE 3x doesn't use DBUS as inter process communication, it is used for device detection handling. KDE4 has replaced DCOP with DBUS. The UDEV -> HAL -> DBUS stack measurably improves the user experience, and has become the standard.

Successful integration of usability people into the KDE development process. There isn't one event that would make this obvious. Maybe it is the lack of resistance to the idea. The beginnings of the HIG is a valuable addition.

Focus on KDE 4. The magnitude of this endeavor is not to be understated. It is not a simple port to Qt4, but entails redesign of many of the fundamental libraries that make up KDE. I built and ran KDE4 a week ago and was pleasantly surprised, first that kdelibs and kdebase built without error. It is definitely not a working desktop yet, but I suspect that will change over the while. For the uninitiated, this is an opportunity to see a complex system come together, where the core libraries (Qt), the base KDE libaries, the specialty libaries such as Phonon and other new technologies are in flux, and on top of that the apps are being ported, all the while new functionality is being added. To an outsider it looks like a huge mess, a quagmire. But whenever something gets finished, that allows another level to start progress, and so on.

Coming as a surprise to me, the advancements and improvements to KDE3 are outstanding. KDE3 will be around for a long time. I am in awe seeing the two parallel development efforts.

The Novell-Microsoft pact. There are many opinions on this, some quite strong. Lug Radio Season 4 Episode 8 has an interview with Nat Friedman giving one point of view. On the other hand Jeremy Allison quit Novell because of it. There are many parts to this story. First is patents, and the danger they present to free software. Novell did something they thought would help. They maybe forgot that other than their contributions, they don't own the software that they distribute. The multitudes of very opinionated developers, some who work for Novell competitors, most with a deep distrust of the software behemoths that have arguably ruined more than built, own the software. We are going to see many more of these controversies. This community reminds me in some ways to the Bullet Ant. They have relatively primitive social organisations, but are characterized by their nasty sting, compared to being shot. They sting only when provoked, effectively protecting themselves and their nests with a nasty sting that forces large mammals to stay clear. Their nests are small and could easily be destroyed inadvertently by a large mammal, so they sting to remind everyone of their existence. So effective are they that other insects imitate them. This community tends to sting from time to time to remind the behemoths to stay clear. I suspect that next time Novell wants to do something like this they will tread a little more carefully.

More legal stuff, but in SCO vs IBM, IBM was able to limit SCO's claims. SCO has said lots of things over the last few years, but proof has been hard to come by. The judge seemed to agree, and many of the allegations have been struck from the case. This is a major victory for IBM, and probably the first of many serious reverses that SCO suffers while being smeared on the highway by a fast moving IBM. It is worthwhile to remember that as a community we would be hard pressed to come up with the defenses to fight this sort of battle, and we have IBM to thank.

Strigi. If you haven't, try it out. We will see more in KDE4, but it has the feel of a very solid solution. A fast, well maintained storage and indexing libary, CLucene. A stream design that is showing up in other contexts. Developers that are intent on making it easy to use and implement. I predict that this will be one of the jewels of KDE in a year or two.

10th anniversary of KDE. We are seeing a maturity of process all the while maintaining the openness that has characterized KDE. There are some developers that have been here all along, but we are seeing maintenance of applications being passed on the third or fourth time. KDE is doing something right.

And finally, having run out of ideas, I would like to thank everyone for their work. Every year I look back and am amazed, and wonder what more could be done. Not this year though. It seems the closer we get to the destination, the clearer the focus becomes on what remains to be done.

Some of the trollish comments on the Dot and the link to the Adobe thread where KDE is described as something written by college students brought to mind a phone-in show on CBC Vancouver. The guest was a technology guru, and offered to help people sort out computer questions. The majority of the calls were from people trying to get things done in spite of the limitations that came from software publishing firms trying to lock down their data and formats, or lock out a competitor. Yes, some problems were about Adobe products.

I called in, and said that most of the issues that were brought up could be solved by using free software.

Now I don't have my head in the clouds, thinking that the KDE desktop is vastly superior to everything else out there. No. There are many areas where it is incomplete, and for some not functional enough for their needs. But inexorably it progresses, and eventually will become complete enough for most people.

But the fundamental strength is freedom. Every time I use some proprietary application, even on my linux box, there is always an insistence on preventing me from using the application freely. Sometimes I am forced to use these things. But I am finding that there are more and more free alternatives, and I find the freedom is of far greater value than some neat feature. In fact, freedom is the neatest feature of all.

This is constantly being confirmed when dealing with the plethora of embedded devices at work. Why would a bleeping thermostat have bleeping software bugs? And what the bleep are we to do when more and more of our lives are controlled by trashy software? And we only find out about the bugs long after the systems are installed, and usually during extreme circumstances, like Canadian winters. I dream of a time where the code would be available for all these things, with the ability to fix and update the software. I'm reminded of a story told by a technician who works for the local school district. He is a highly qualified programmer, but decided to leave the industry after one too many death march projects. The school district had an intrusion alarm system installed that would fail reliably under a peculiar circumstance. He removed the rom chip, disassembled the opcodes and found a bug in the software. The manufacturers refused to fix the problem. So he burnt a new rom, installed it and the thing worked as expected. A hacker in the true sense of the word. Unfortunately I think we are doomed to the sloppy and closed, but damned if I'm going to submit to that tyranny if I have the choice.

Running a linux desktop means you are always a little behind the curve. Actually, this is an advantage. By the time the technologies are fully supported, the technology is mature.

I have always listened to CBC radio during the work day, but it seems to have left me somehow, or my interest have left it. So I started listening to podcasts from various sources. My first attempts were to copy onto an sd card and listen on the palm that i carry all the time. Highly unsatisfactory. So I bought a cheap mp3 player that could use sd cards. Much better, although after a month's use it started acting strange, and AAA batteries are expensive. So I picked up a Zen from Creative, 8 gigs. Luckily the mpt protocol has just matured, and Amarok fully supports it. Very nice. Probably by the time I wear it out, Rockbox will have a port ready for it.

Is there any way to share or publish podcast lists? The top of mine would be Lugradio. At first it sounds like some wierd revival of sorts with incantations of 'Jesus Christ' and other strange things, but after a while your ear tunes to the inflections and between the body function jokes there is good information and opinion. Great fun. I have a young lad working with me and the show had him laughing while proselytizing linux. I don't know if the button down business types would enjoy it.

In the continuing saga of keeping hardware working, Samsung has released a new set of drivers for their printers and scanners. They seem to work, but it is disconcerting to see an installation program install all sorts of versions of libc and the like. Of course the real solution would be to open up their software and allow it to be included in the various printer driver aggregations and sane driver collections. In the meantime they have to come up with some magic that keeps things working over versions of glibc, gcc compiler versions, cups iterations, and whatever else they use, just to keep one small binary working. All of course outside of the system package management, sprinkling who knows what all over the place. From where does this perverse logic come from? What could possibly happen to Samsung if they dared release some printer language specs? Ooh, someone may write a printer driver that actually works, ie. prints and respects the system that it is installed on.

Watching this horrible spector got the juices running. Has anyone written a tool that would build packages for all the distros? And all the versions thereof? I don't know if it would even be possible. The speed of the desktop development may eventually force these people into either giving up or opening their code and allowing the community to handle the distribution. Hopefully the later.