Digested

Previous experience has taught me to set aside a bit of time to get new hardware working with linux. With google and a bit of re-acquaintance with the configuration files, usually things get working.

So when I purchased a Logitech cordless mouse, I wondered if I remembered the arcane details of the xf86config file format. So I plugged the base into the usb port, put batteries into the mouse, moved it and it worked. Just like that. There is even a KDE configuration section to set some rates for it.

I'm very pleased.

I'm in the process of getting the Digest ready for the move to subversion. I've got the base class that gets stuff from the repository done, now to tie the whole thing together. I'm still not quite clear how access to the older issues will happen, ie. do I keep a cvs repository available? In any case things are progressing.

Some questions and comments come to mind. How will the mirroring work? If the kde svn repository is in bdb format, does rsync work? I searched for subversion mirroring in vain. It looks like I'll need to have a local mirror to allow reasonable performance (more on that below).

Subversion has some neat features for viewing the repository without creating a local copy.

svn list https://svn.kde.org/home/kde/trunk/ 
give a directory listing. 

svn cat https://svn.kde.org/home/kde/trunk/kdeedu/khangman/ChangeLog 
gives you a copy of the file, and if you 

svn cat -r ### https://svn.kde.org/home/kde/trunk/kdeedu/khangman/ChangeLog 
with a revision number, you can get that version. So you could browse the repository 
without checking out. I use these commands to generate the digest. Oh, another neat 
feature is the log output in xml format.

One thing that I've found a bit annoying is to get a diff for the changes that make up a revision. If you use svn diff -r 300000 https://svn/repository/and/file.c, it gives you the difference between that revision and head (assuming you don't have a local copy). If you want the difference to the previous version, you (or I, as in had to code) need to figure out the previous revision, ie. previous:current. Since revision numbers are incremented with each change to the whole repository, I get the log for the file, get a list of revision numbers then get the desired number to get the diff. Maybe I'm doing this wrong, but I couldn't see any other way from the documentation. In other words, to get the diff for a revision, I need to get the log for that revision and grab the list of edited files, get the log for each file, figure out the previous revision for that file, get the diff, rinse repeat. Since the revisions may touch any number of files, creating a diff display requires at least three svn commands. Hence the need for a local mirror.

As I said, things are progressing.

There seems to be quite an audience for KDE related information. A dot link brought down a server. I checked the logs, and for the march 11 issue, there have been 9310 hits. That is using a rather unscientific 'grep -c newissue=mar112005 access_log'. The previous issue had 11232 hits. Who would have thought there would be that many people willing to read commit logs?

Robert Alsina's blog brought to mind my first serious contact with KDE. I installed a beta version of the desktop, and ran into a bug in one of the core components that prevented me from using it. As a good citizen, I got a bugzilla account, and filed the bug with the backtrace.

Soon after I got a response from a developer saying he didn't know what was happening (it worked fine on his machine obviously) and could I test this patch. So over the next week or so I set up a build and test environment on my machine, but before I got to the point where I could test things, another email came asking testily if I had tried the patch yet. Eventually I got to the point where I could, and no it didn't fix the problem. So I looked through the code, found a couple of places where a pointer was dereferenced without checking, put a bit of code in to check, recompiled, and tested. Problem solved. So the patch was posted to bugzilla, applied with some modifications, and all was well.

You see, from my standpoint everything worked as it should. I have access to an amazing desktop, development framework, community of users and developers. Comparing what we had then to now, the progress has been amazing. And it costs nothing.

I could find things to complain about with this arrangement, I suppose. Any complaints would stem from thinking that I deserve all of this for nothing. Which I don't. So what is left except appreciation for a valuable gift, and finding some way to pay it back?

Developer centric, user-centric are meaningless. It's whoever does the work-centric. Which means in the end developers.

I got 8/10, even though I only recognized two. http://www.malevole.com/mv/misc/killerquiz/.

Flash required. Hmm.. I like it when things just work

Some stories from the last little while bring to mind how easy it is to lose sight of the basic strengths that make free software work. Surprisingly so. The conventional wisdom always will tend towards the old way. To illustrate:

Recently there was a blog entry about the lack of developers for the Mozilla project. Not to overstate the problems, but contrast that with the buzz around a New York Times advertisement, and the almost 10% browser share. The metric, and the only real target for a marketing drive for any project is developers. Users are important, and the growth of Firefox has forced web developers to write for more than IE. But if there isn't any developers, how can the growth be maintained? There is a natural attrition that occurs in project; people get jobs, leave school, get married, get burned out, get bored, etc. New blood is always needed. The natural advantages of free software will attract users, as long as there is enough help available to finish and package the software appropriately. KDE does quite well with this.

And may I whisper a blasphemy: maybe all these Windows users that we all need and are striving for don't give anything back.

Another idea that stirred the hornets nest commented on the fractured nature of free software, a replay of the Unix mess of the past. Again, what is the strength of free software? You can change the code. So what do we all do to distribute free software? We put together nice binary packages. In a shrink wrap. With incomprehensible version numbers. Tell me how is this different than what we had before? How easy is it for someone to change a few things in one of the software packages they need? Quite complicated, which creates a high cost of entry into the real advantages of free software. How about a distribution designed around the idea of people modifying the source code (within reason) and still being easy to install and administer? The closest I've come to that is the now unmaintained gentoo kde-cvs ebuilds, where I could change or patch things in the local working copy from cvs. And wouldn't the easy building from source eliminate the incompatibilities that are inherent in binaries? The source is our strength, why not take advantage of it?

There are real people making real cash from implementing free software solutions, including the desktop. It will grow naturally due to its inherent advantages. I remember reading back in the '80s about how the cost of entry into the then nascent software market was around a million dollars. Most of that was marketing costs. Now someone with some skill, time and a non-abrasive personality can put out code, attract a community of developers, and a while later produce some very decent software. Some smart ones get a customer to pay them in the meantime. If we get into the million dollar game, we lose before we start. That is not our strength.