There is one particular aspect of Microsoft’s document format going through ISO process that I had a hard time to find a counter-argument against: “Well it is better to have multiple open formats, isn’t it?”. Last night when I was presenting in a Document Freedom Day event, I finally got one. When multiple standards exist in the same area, two options can exist:

1. Cooperative standards - providing similar functionality in different ways that can coexist in the same medium without a significant overhead. An example of this are the credit cards - they have multiple ways that the card information can be transferred to the bank: visual writing down of the data, imprint, magnetic strip and the chip. Any of these ways can be used and all of the are equally valid;
2. Conflicting standards - providing the same functionality in incompatible ways. The example here is the power adaptors - the form of the power plug is an open and public standard (AFAIK), but so many of them exist in different places that it creates all sorts of problems both for companies producing electronic equipment and for frequent travellers.

What Microsoft proposes is much worse than the power plug mess, because the power plug standards are at least restricted by region. But imagine going to another country and having to be ready that you hotel could have any one of 8 power plug types at random. And while electricity is rather easy to convert looselesly, complex documents are far more .. complex. It is like having to buy 8 different power bricks for each of your electrical devices to be prepared for all possible voltages, frequencies, waveforms, polarities and whatnot. Having more than one ISO document standard in a horrifying idea for any programmer that will have to ever work on software that will need to support both of them - twice the work for no etra benefit whatsoever. If Microsoft can prove (in technical terms) that their file formats present capabilities that Open Document can not, then the only sane way to implement those in the ISO format is to add those capabilities as an extension of the existing Open Document format and not to reinvent the wheel. Microsoft also has a habit of pointing to JPEG and PNG being “competing”. Well, they are not - those are complimentary standards, because JPEG is designed for compression of photographic details while PNG is designed for the compression of bitmapped vector images. Something like DejaVu could be seen as a superset of the two formats. So, if you ever need an argument against more standards - remember about the power plugs.

Ah, Erich, that IS so true. I never found a well written PHP application anyway, or it was only 10 lines long. I guess that's primarily the language fault. It permits to do a lot of stuff and does not simplify, help nor force the simplest implementation methods like MVC which should be the base in Web developement. Well, take as example what we would do with Python and GTK+ if they were like PHP and HTML (I do not have the API reference so it will be somewhat improvised):

#finally we do not need this module I wrote everything myself
#import somemodule
def main():
    # Well we want to do some printing
    window = GtkWindow()
    # Connect to the database without any abstraction, that sucks
    db = mysql.connect()
    data = db.query("select RANDOMLYTYPEDDATA from MYONLYTABLE");
    while data:
        # Ah, we do not have include() so we cannot reuse code
        # I'm a PHP developer, I do not know functions
        import somestuff
    window.print(somestuff.result)
    # Obviously, forgot to close db connection, etc.
    if form.data.field == "hello":
        # The user asked for hello, print hello
        window.print("hello")
    # debug
    print data[0]
    if form.data.anotherfield[0] == "morning":
        data = db.query("select anotherdata from MYONLYDATA")
    else:
        sys.exit(42)
    label = GtkLabel()
    # Yes know we construct the view!
    window.add(label)
    label.print(data)

That is typical PHP code: we just take randomly typed data from our DB eng... no wait, from MySQL (remember that's LAMP!!! Not LAPP or anything else, bitches!), then we print some HTML code with data, and we do tests on environment, forms, etc, and we get back data, reprint them, do not use functions but include() multiple times thousand of files and then do not close/free anything. It's so easy to do bad code that lot of people coming from nowhere and who did not learn anything from other languages are doing it. Another hypothesis coming from my experiment: PHP is a language which can be developed under any OS since it's server-side executed. A link between mostly brain dead "developers" from the Microsoft world and whose from the Free Software world. A clash. I apologize to some of my coworkers doing better PHP all the day.

A year ago I posted an anti-platform with some things I wanted to work on over the next year or three. This is a followup to see what, if anything, has been accomplished. constantly usable testing CUT generated some discussion in the project, but I've done nothing toward it myself. The only real progress in this area over the last year has been increasing improvements in the testing security team, and the release team, both of which I'm not currently active in. deprecating www.debian.org This continues to happen organically, for example, Debian Weekly News stopped and http://wiki.debian.org/DeveloperNews took its place. Aside from pointing out that this is happening, I haven't done much to push it. double the archive sync frequency again Sadly, this has not happened yet. automated whole system testing HP donated a test machine, which I set up to run emulated tests of installations of i386, amd64, s390, mips, and mipsel. (Arm and armel should be added soon.) I don't always manage to keep all the tests working at all times by myself, but they have been valuable. developer (virtual) machines My test machine spits out disk images for 5 architectures that have debian pre-installed on them, but due to hosting issues I have not been able to share those images with others yet. find the next nslu2 I was pretty sure this would be OpenMoko's Neo phone, but I have only briefly had access to one, and it's not clear it will be easy enough to get the hardware to make it worthwhile to target it. Meanwhile, tbm has found a more nslu2-like next nslu2, the QNAP Turbostation NAS device, and there's work underway to fully support it from d-i onwards. Others have also worked on running Debian on various related AP hardware, including the ASUS WL-500g and Linksys WRTSL54GS, using OpenWRT to boot Debian. There's instructions and downloads on a wiki page. It would be good to get this fully supported without the hacks.

My mobile music player is often missing the files I want to hear right now if I'm under way because my music collection is too big to fit on it.
Long time ago I used gnump3d which seems to be unmaintained in Debian for quite some time and then I often listened to some live streams, network connections are available nearly everywhere.
But I always wanted my own live stream with music I want to hear. There are several solutions out there for this task but they all require the creation of a playlist before the streaming starts.

Fortunately mpd provides the possibility to define different output targets and also one for streaming to a shoutcast or compatible server like icecast.

So after apt-get install mpd icecast2 (on a Debian box) you have to edit /etc/mpd.conf
There is not much to do, be sure to set music_directory to the place your music is located and the configure the output part.
Add the following to your mpd.conf and adapt some values:

The type defines that this output will be streamed to a shoutcast target. The name will be displayed by the client you use to play your stream. 8000 is the port icecast2 will listen on host "localhost" (in this example the icecast2 server is on the same host). format specifies the audio format of the stream, the first number is the sample rate in Hz, the second number is the number of bits per sample and the last number defines the number of channels (2 is stereo here). Those values should work for most of you. mount specifies the path under which the stream is available later from the server root, in this example http://localhost:8000/stream.ogg.
quality defines the ogg encoding "quality". You can also specify the bitrate instead of it. The user and password values are used to authenticate mpd at the source input for icecast2.

There seems to be a bug in the 0.13 release (which is also in Debian) of mpd that prevents this from working. I don't know the details about this bug but adding
fixes it.

Make sure to set START_MPD=true in /etc/default/mpd to enable mpd.
That's all that needs to be done for mpd.

The next step is to edit /etc/icecast2/icecast.xml.
The default configuration nearly ready to use. Configure the authentication part:

The source password is the one we specified in the mpd configuration. This is needed to authenticate mpd with icecast. source is the default user name icecast uses here. Additionally we define an admin-user that can be used to add users to icecast later because we want to protect the stream by a username and a password.
Then set .
This hostname is used to generate URLs in icecast that a user receives.

Because we want a very simple authentication for the stream we need to add some options for the mount (/stream.ogg):

I think the xml tags are pretty much self-explanatory. Keep in mind to set the filename to a location the icecast daemon has access to, that's why I used /etc/icecast2. Then you can add users with htpasswd or using the web interface on port 8000 and add a user there.

The last thing to do is to adjust the <alias source="/" dest="/status.xsl"/> setting. Change status.xsl to auth.xsl people need to authenticate if they connect to the web interface before seeing the stream information.

Now you can login via ssh on your home server and use your favorite mpd client to configure playlists on the fly, I use ncmpc for this. Of course the authentication is not secure, people who sniff your traffic can see your login data.
One thing to keep in mind is to restart mpd after restarting icecast otherwise mpd will hang and not continue to stream, this seems to be a bug.

After routing through your NAT, you should be able to play your stream via http://you.somehost.org:8000/stream.ogg.

SymPy is a pure Python library for symbolic mathematics. Last year SymPy had 5 excellent students and this year we are accepting students again.
Why should you apply? And why to SymPy?

Well, let me give you some reasons:

• First of all, it's fun. To get some idea, read the GSoC2007 SymPy page, where you can find out what the last year students did and especially read their reports, where they describe their impressions from the summer, how they tackled problems and their overall conclusions.
• It's not just about coding, we enjoy the social part too. There is a great community around numpy, scipy, ipython, matplotlib, Sage and similar tools and if you do scientific computing with Python, you gain a lot just being part of it, because you learn new things from the others.
• I currently live in Prague (most people say it's a beautiful city, but I actually like Los Angeles, or the Bay Area:), if there are enough interested people, we can make a coding sprint here (plus of course some sightseeing+pubs). Anyone with a good commit history is welcome to stay at my apartment. :)
  
• You earn $4500, some of which I suggest to spend on travelling to conferences/workshops, here are some tips: SciPy2008 (see also SciPy2007), EuroSciPy2008, Sage Days (you can read my impressions from SD6 and SD8), watch the numpy/scipy mailinglists for announcement of other meetings.
  

Read also the current status and motivation of SymPy and it's relation to Sage. If you want to apply, all the necessary information is on our wiki page.

Nevertheless, if you decide SymPy is not for you, but still you'd like to do GSoC project in a similar area, there are other good options too - one is SciPy/NumPy, the other is Sage. Unfortunately Sage was not accepted as a mentorship organization, but it has several good projects too, some of which you can do for example under the umbrella of the Python Software Foundation.

One of them is improving the Sage notebook. If you've never seen that - download Sage, start it (./sage), type "notebook()" and a nice Mathematica like notebook will popup in the browser. It allows collaborative editing ala Google Docs and many other things. If you'd like to work on it, reply to the email on sage-devel.

This post is both an attempt at replying to a bug against telepathy-glib, but also an attempt at explaining what Requires.private do (and don't). I am using Evolution as my example here, not to pick on Evolution or its authors in any way, but because it's a convenient example. Currently, on Ubuntu Hardy, evolution links against 75 different libraries. Amongst those, we find libz.so.1, libXinerama.so.1 and many more. I'll go out on a limb here and claim that Evolution does not call any of the functions in libXinerama directly. Let that be the assumption from here on. An obvious question then is, why does evolution link against libXinerama.so.1 if it doesn't use it? To answer that question, we need to go back in time to before we had dynamic linking. If you wanted to build a binary like evolution you had to have 75 -l statements when you linked and you ended up with the whole code for Xinerama embedded in your email and calendar client. For various reasons, we stopped doing that and switched to dynamic linking where the evolution binary just contains a reference to libXinerama. At some point we also grew the ability for libraries to contain those references to other libraries, so you don't have to hunt down all the dependencies of libfoo when you are linking with it. We also got tools such as libtool which try to abstract away a lot of the problems of building on older platforms which don't support inter-library dependencies. Now, since evolution still doesn't use anything directly in libXinerama.so.1 but just uses a library which in turn links against libXinerama.so.1, it shouldn't be linking against it. Then why is it linked with it? Again, we need to look back at history, and for this part I am at least partially responsible. pkg-config was originally written as a replacement for gnome-config and various other -config utilities. Lots of libraries and applications now ship .pc files and we have a standardised interface for querying those files. One of the problems the original authors of pkg-config faced was the problem of dependencies. They added dependencies so the authors of gst-python-0.10 could say "We need pygtk-2.0 too" and so the compilation flags needed for gst-python-0.10 would also include those for pygtk-2.0. Note that I'm using "compilation flags" loosely here, I am not just talking about CFLAGS. This did not fix the problem of inflated dependencies. Not at all. I talked with some of the Debian Release Managers back in 2004/2005 and we worked out a solution which should help us have correct, uninflated dependencies since the then-current way of handling dependencies caused big problems for migrations of packages between unstable and testing. The plan was to introduce a new field, Requires.private which would not show up unless you passed --static to the pkg-config invocation (since you need all libraries if you are linking statically). This definition of Requires.private was mostly useless since GNOME and GTK+ have a habit of including each other's headers. To make a long story short, I changed the semantics so the Cflags field from private dependencies were included even when not linking statically. A problem which pkg-config does nothing to guard against in this case is if you have libfoo.so.2 linking against libbar.so.1 and libfoo.so.2 exports some of libbar's types in its ABI (and not just as pointers, but actual structs and such). If libbar's soname is then bumped to libbar.so.2 and libfoo is rebuilt, libfoo's ABI has changed without a soname bump. This is bad and will cause problems. If your application is linked against both libfoo.so.2 and libbar.so.1, you'll still get problems since libfoo.so.2 then suddenly pulls in symbols from libbar.so.2. If you used symbol versioning, you would at least not get symbol conflicts and your application would continue to work, but you would have a spurious dependency and the package containing libbar.so.1 would be kept around until your application was recompiled. With this background, you might ask the question why we still have Requires since it is seemingly useless. For C, it is useless in all but the most special cases, just use Requires.private instead (and its sibling Libs.private). Other languages have different semantics. Some people use .pc files for other purposes such as gnome-screensaver having variables defining where themes and screensavers go. Hopefully this blog post has explained a bit about why we have Requires.private and what the difference between this and their regular counterpart is. If there's anything unclear, please do not hesitate to contact me.

I've spent a lot of hours over the weekend stripping out markup on my personal website, so that I can regenerate it from a templating system. My template-compiler is horribly hacky, but it produces reasonably good results from simple input files. The only motivation for this was to finally transition my site to a consistant layout, and allow me to easily change the layout again in the future. I looked over WML, htmlpp, and a few other static web-compilers before writing my own tiny processor. I guess most of them are more powerful than mine, but similarly more complex to get started with. I'll share the code if there is any interest. (Primarily it is template expansion of a body, optional per-page menus, and per-page HTML header inclusion.) The only significant thing that has changed in my website is a tiny RSS feed of updates (also compiled!) and the removal of many sections from the top-level menu. (For example my body piercing section has been obsolete for years. It is still present, but I see no point in advertising it. Better resources exist.. The plus side is that I've managed to do all this whilst watching "Dead Like Me" over the Easter weekend. Both series from start to finish. Good show.. Obquote: 10 Things I Hate About You

(Note: this is a long post)
Package: deb-gview
Use of GnomeVFS: "Individual package files or packages referenced in a changes file can be viewed from local or remote filesystems using GNOME VFS."
Main changes: src/dvarchive.c but also src/main.c.
Port Status: Complete and tested.
Prerequisites
Do not run any code before completing this step
You must ensure that gvfs, gvfs-bin and gvfs-backends are all installed and operational before running any of your modified code. Thereby hangs another tale. The application itself probably needs to depend on both gvfs and gvfs-backends. gvfs-bin provides test binaries like gvfs-info.
You need to ensure that the following command operates correctly:

$ gvfs-info http://www.google.com

display name: /

edit name: /

type: unknown

size: 0

attributes:

  standard::display-name: /

  standard::edit-name: /

  standard::content-type: text/html

  id::filesystem: type='http',uri='http://www.google.com',mount_prefix='/'

Note that this is run as the normal user, not under sudo and not as root. - that just complicates things. If you find that this works with sudo but not without, read the bug report against gvfsd.
If you get this output:

$ gvfs-info http://www.google.com

Error getting info: The specified location is not supported

read the bug report, find and kill the borked gvfsd process and ensure that gvfs-backends is installed before attempting any other gvfs* commands (including via your modified source code).
Starting

1. Online copy of the GIO docs. online copies of the GVfs docs. I mainly use Anjuta where both sets of the docs are available via libglib2.0-doc >= 2.16.1 and devhelp or via your localhost using dwww.


2. #include <gio/gio.h> to replace #include <libgnomevfs/gnome-vfs.h>.
   (May sound obvious now but examples are not that frequent in the GIO docs as part of libglib2.0-0.)


3. The GIO docs do give some info on porting variables:
   
   
   • GnomeVFSHandle * vfshandle; became GFile * ghandle; GInputStream * stream; in deb-gview
   
   
   • Extra variables needed for deb-gview: GVfs * vfs; GError * result; GFile * gfile; GFileInfo * ginfo;. GError itself is not new but it can catch you out in the port because so many GIO/GVfs functions can use it and you find yourself using g_clear_error(&error) a lot or GLib will complain about trying to replace data in a GError.
   
   


4. Separate path and URI handling - GIO and GVfs have separate filename/path handling for paths on a local filesystem and paths on remote filesystems and the two cannot be mixed. This was a big source of bugs during the port (it may be a UTF-8 issue) and in the end I went for a gboolean flag in the context that this particular viewer was handling a file from a remote filesystem (e.g. http://localhost/incoming/deb-gview_0.2.0_amd64.changes, http://ftp.debian.org/debian/pool/main/e/emdebian-tools/emdebian-rootfs_0.9.1_all.deb or http://incoming.debian.org/foo_version.changes) and not from a local path (e.g. /opt/debian/deb-gview/deb-gview_0.2.0_amd64.changes or ../../debian/deb-gview/deb-gview_0.2.0_amd64.deb). Personally, I found g_file_is_native to be unsuitable for this purpose and as I had a "user-entered" path available, I simply use if ((g_str_has_prefix (path, "..")) (g_str_has_prefix (path, "/"))) but YMMV, depending on how you obtain the path itself.
   Keep track of the type of input file when handling GFile - g_file_get_path will fail if passed a GFile that needs g_file_get_uri and vice-versa. These failures output messages to the console so they are relatively easy to track but not only will the call fail but the GFile itself is likely to get corrupted, leading to other bugs and messages to the console. g_vfs_get_file_for_path(vfs, path) and g_vfs_get_file_for_uri(vfs, path) (which obtain the GFile from GVfs in the first place) also fail if passed the wrong type of path.
   In some situations, g_file_get_parse_name can be used to get a "normal" char* representation of the path to the GFile but I was only able to use this in specific circumstances and only when the path and URI handling flag was implemented.
   This all complicates the port because gnome_vfs_make_uri_from_input did not have this separation issue.


5. Checking if a file exists - if (!g_file_query_exists (gfile, NULL)) may seem easy but unless issues with the URI and path are handled cleanly, this simple check will fail even though the file exists. The problem arises because GFile appears to mangle a URI with a path function and vice-versa. The GFile ends up with an invalid path and hence there is no valid file to check so the query fails - but without indicating that it's actually an internal error in GFile rather than a valid path that simply does not exist.


6. Reading files in one go - vfsresult = gnome_vfs_read_entire_file (vfstext, &changes_size, &contents); gets replaced with g_file_load_contents (cfile, NULL, &contents, &changes_size, NULL, &result); (note the order swap between the size and the buffer to use). Once read, the buffer can be handled as before. This is one of the easier changes in the port, once the above issues are all cleared up. On the other hand, GIO and GVfs do appear to handle relative paths more easily than GnomeVFS.


7. Checking VFS is active -
   

   vfs = g_vfs_get_default ();
   
      if (g_vfs_is_active(vfs))  



8. Reading files as a stream - result = gnome_vfs_read (vfshandle, readbuffer, skip, &bytesread); becomes bytesread = g_input_stream_read (stream, readbuffer, skip, NULL, &result);. Fairly straightforward as long as you use:
   

   if (result)  
   
   g_warning("Error: %s", result->message);
   
   g_clear_error (&result);
   
    

   (or something equivalent to get the error message to the user), every time you use &result.
   vfs_uri = gnome_vfs_uri_new (gnome_vfs_make_uri_from_shell_arg (filename)); becomes filestream = g_file_read (deb->ghandle, NULL, &result); (there's that &result again).


9. Checking the stream remains open.
   

   stream = (GInputStream*)filestream;
   
          if (g_input_stream_is_closed (stream))
   
          return FALSE;



10. Seeking inside the stream - YMMV but seek never appeared to work well for me in VFS so I had to read into a dump instead.
    

    gpointer dump; 	        
    
            dump = g_new0(gchar, seek); 	        
    
            result = gnome_vfs_read (deb->vfshandle, dump, seek, &bytesread); 	 
    
            g_free (dump);

    
    In GIO, seek is much easier: g_input_stream_skip (stream, seek, NULL, &result); - just handle that &result again.


11. Closing the stream - gnome_vfs_close (vfshandle); becomes g_input_stream_close (stream, NULL, &result);.


12. Getting information on files - if ((vfsinfo->type != GNOME_VFS_FILE_TYPE_REGULAR) (vfsinfo->size == 0)) becomes
    

    ginfo = g_file_query_info (ghandle, G_FILE_ATTRIBUTE_STANDARD_SIZE, G_FILE_QUERY_INFO_NONE, NULL, &result);
    
     if (0 == g_file_info_get_attribute_uint64 (ginfo, G_FILE_ATTRIBUTE_STANDARD_SIZE))
    
     
    
           dv_show_error (DV_ERR_NO_FILE, parent);
    
           return;
    
     

    
    (dv_show_error is a user-facing error report func) and, yes, there is a g_clear_error(&result); later.

Summary
This took me quite a bit of time and the bug in gvfsd was a significant hindrance so ensure that you test with gvfs-info before thinking there is a bug in your code. (Also remember that if you are reading files from http://incoming.debian.org/ then those files will disappear once each day when the cron job moves them into the pool. ) I recommend developing and testing against http://localhost/ during the port.
The GIO docs are relatively thin (especially for GVfs) and that is not just because GIO is still new. Starting a new application using GIO and having a working GIO/GVfs setup in place already would be much easier so new applications will work. As ever, the problems really show up when trying to port an application that has already worked around the various GnomeVFS bugs and now has to both remove those workarounds and implement one or two other changes for GIO.
Ensure your application has Depends: gvfs-backends - until the bug in gvfsd is fixed, it would be unwise to put gvfs-backends in Recommends: because that will almost inevitably result in any user without Recommends: enabled passing a call to GVfs at least once without an available backend, resulting in a broken gvfsd process and a completely broken application until the user either kills the process or logs out and logs back in. Even identifying that issue in a bug report is not straightforward - hopefully the bug report and this post will help. (Yes, depending on how you configure the ported application, it is entirely possible for this broken gvfsd process to break all file operations in your application, even local ones.) Unfortunately, there is no call (currently) to take down GVfs - you can only test to see if it is already active and that check is not sufficiently intelligent to detect the broken gvfsd process.
Subjectively, GIO does appear smoother than GnomeVFS and maybe faster. Now I need to get on and try to port other applications to GIO.....

GNU Smalltalk 3.1 rc1 includes Seaside, a web application framework based on continuations. To use, you'll need to install package gnu-smalltalk 3.1~rc1-2 from experimental. Then, from a terminal, launch gst and type[1]:

st> PackageLoader fileInPackage: 'Seaside'
st> PackageLoader fileInPackage: 'Seaside-Development'
st> PackageLoader fileInPackage: 'Seaside-Examples'
st> ObjectMemory snapshot: 'seaside.im'

Now start you can start Seaside with gst-remote -I seaside.im --daemon --start=Seaside, and launch your browser on http://localhost:8080/seaside:

---

[1] taken from GNU Smalltalk info page

pianofiles.com, a sheet music exchange site which I had mentioned two years ago, has gotten a nice facelift. It used to be very slow and neither very pretty nor convenient. Most of these shortcomings have now been corrected. It's a great place to look particularly for modern tunes which, unlike classical works (which are usually public domain anyway), do not have a canonical version, but heaps of arrangements and transcriptions of live performances. Quality of course varies, but point is that you can get your hands on many versions and compare them. Typical latency of requests is about a day. For example, just yesterday I fired off a few emails, and today I have got three versions of "Nardis" by Bill Evans. Feel free to ask for any sheets I've got.

Since the last post, I have significantly improved debian-mr-copyright-mode, that now provides an interactive function, debian-mr-copyright-scan-files that shows which files are covered by which clause of the debian/copyright file. I've also significantly improved my understanding of font lock and emacs lisp in general... As a demonstration, the attached picture represents the results of debian-mr-copyright-scan-files on the monsterz source package (Sam's original example). The output clearly shows that some files are not covered yet... You can get the emacs mode there. Its is starting to be good, but of course, many more improvements are still planned - in particular, quotes for files probably don't work yet. By the way, imenu now works. A debian package should probably come soon.

One of the challenges maintaining the Debian archive kit (dak) is dealing with Debian-specific requirements: fundamentally because there are a lot of them, and they can get quite hairy – yet at the same time, you want to keep them as separate as possible both so dak can be used elsewhere, and just so you can keep your head around what’s going on. You can always add in hooks, but that tends to make the code even harder to understand, and it doesn’t really achieve much if you hadn’t already added the hook. However, dak’s coded in python, and being an interpreted language with lots of support for introspection, that more or less means there’s already hooks in place just about everywhere. For example, if you don’t like the way some function in some other module/class works, you can always change it (other_module.function = my_better_function). Thus, with some care and a bit of behind the scenes kludging, you can have python load a module from a file specified in dak.conf that can both override functions/variables in existing modules, and be called directly from other modules where you’ve already decided a configurable hook would be a good idea. So, at the moment, as a pretty simple example there’s an init() hook invoked from the main dak.py script, which simply says if userext.init is not None: userext.init(cmdname). But more nifty is the ability to replace functions, simply by writing something like:

# Replace process_unchecked.py's check_signed_by_key
@replace_dak_function("process-unchecked", "check_signed_by_key")
def check_signed_by_key(old_chk_key):
    changes = dak_module.changes
    reject = dak_module.reject
    ...
    old_chk_key()

That’s made possible mostly by the magic of python decorators – the little @-sign basically passes the new check_signed_by_key function to replace_dak_function (or, more accurately, the function replace_dak_function(...) returns), which does the dirty work replacing the function in the real module. To be just a little bit cleverer, it doesn’t replace it with the function we define, but its own function with simply invokes our function with an additional argument to whatever the caller supplied, so we can invoke the original function if we choose (the old_chk_key parameter – the original function takes no arguments, so our function only takes one). Right now, we don’t do much interesting with it; but that should change once Ganneff’s little patch is finished, which should be RSN… Hopefully, this might start making it easier to keep dak maintained in a way that’s useful for non-Debian installs – particularly if we can get to the point where hacking it for Debian generally just implies changing configuration and extension stuff – then we can treat updating all the real scripts as a regular software upgrade, just like it is outside Debian.

I tend to favour text-mode applications (I’m sure vim, irssi, zsh and mutt account for most of my keystrokes, in that order), but there are times when a graphical application is called for, for example the browser. Or when I just find it more convenient, for example the music player. Lately, though, I’ve been pleasantly surprised by a couple graphical applications, for which I had text-mode versions which worked more or less acceptably: a random-note taker (I was using vim), and a dictionary (/usr/bin/dict). I’ve replaced these two with Lars’ Notetak, and StarDict. I’ve found that having them constantly running in desktop #2 (which is one keystroke away) beats having to start up vim or dict each time. Curiously enough, in both cases the main interface of the application is a text input line which offers some kind of “incremental search” functionality. StarDict is packaged in Debian (package name stardict-gtk or stardict-gnome), and Notetak, being Python, is easy enough to run from source (the page claims there is a Debian repository there, though I can’t access it).

trickle (available in a package repository near you) is a neat little tool to limit network bandwidth of a particular app. It's very useful for those situations where you don't want your connection gobbled up, but the application in question does not implement traffic limiting. For example, to run a dist-upgrade capped at 30 KB/s, run this: trickle -s -d 30 apt-get dist-upgrade (Care to guess what I'm doing now?) Note that trickle does not seem to work across the sudo boundary: don't do trickle -s -d 30 sudo foo, do sudo trickle -s -d 30 foo .

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

• [1] http://www.airs.com/blog/archives/115

Share This

Unsurprisingly, there is a deal of common ground between a SQLite backend and a GDA backend. Both need simple routines that convert library data into SQL statements but each has very different ways of reading that data back from storage.
I've spent today doing upstream work (whilst also getting my central heating system replaced). Gutted the house, gutted the library - what's wrong with that?
However, I've decided to make these new functions private to the library rather than exporting them. Simple reason really - they are one-way routines.
One day, QOF will support UPDATE statements and one day a bit later it will also support DELETE and even DROP but those require changes within the library like "unregistering" objects that the current code simply doesn't expect.
Eventually, this kind of SQL support can make a usable query interface for quicklist and a few other stalled projects (like DWI). The principle gain is to allow QOF objects to evolve and adapt but retaining compatibility will be a challenge. (QuickList is likely to only support a read-only mode for some objects and require that others are renamed before being amended.)
The other advantage of this refactoring is that the SQLite backend in libqof2 will be a lot smaller than before. Migrating the code hasn't increased the size of libqof2 either because so much deprecated code has been removed when bumping the SONAME.
I'm sticking with the roadmap of not looking to release libqof2 until after Lenny but that gives me plenty of time for internal reworking to get the GDA backend functional.
So far, I have been able to create a test GDA data source, add a table and data, delete the data and drop the data source. Not bad! (I test with SQLite but XML, MySQL, PostgreSQL and other ODBC connections are supported by GDA without changes to the QOF code.)
As ever, implementing new functionality needs a new test case so that has also been started - only 20 tests so far but worth doing.
Other changes before libqof2 - at the request of the original developer - will include updating QOF-Generator to work with libqof2, updating the old HTML example pages to provide a "QuickStart Guide" and other introductory documentation. Whilst I'm doing that, I'll probably also work on the Emdebian website documentation that also needs improved coordination.
Also note that pilot-qof and gpe-expenses are already libqof2 compatible. All that will be needed is some way for those to provide the username and password variables that some GDA connections would need. (The QOF GDA code already has support for such settings, it just needs to be implemented in the respective frontends.)
First set of changes are now in QOF CVS.
(Yes, CVS - I just don't see the appeal of all those new-fangled RCS versions - subversion is about as "modern" as I need. I just don't need the hassle that comes from git fanboys (or any of the other RCS versions) - nor do I need the hassle of migrating CVS to SVN.)
What I would say is that of the various SVN WWW interfaces, websvn stinks, view svn is a bit better but the only one I really like is Trac. For a single large project, Trac is much more friendly IMHO.

Some time ago I started developing a system to classify free games for Debian, based in Enrico’s DebTags. Up to now I’ve been able to develop a basic set of tags to classify the games, so it’s time to start tagging the games. I’d really like to get as much feedback as possible, especially from teachers, educators, parents and in general people that work with and study about children. The idea is not to develop a fully exhaustive system with a thousand tags. I believe that parents and tutors must check themselves the games before letting their kids play with them, and supervise them while they do if they’re little. This does not try to be a replacement for parents, but a helper to let them have a rough idea about where to look at the games in the repositories according to their own criteria. Being exhaustive is thus not as a priority as keeping the system simple and easy enough. I’ve designed the tags along 3 main lines:
1) Contents that might not be wanted by some parents, teachers or tutors.
2) Games too complex for some children’s cognitive and/or coordination skills
3) Educative contents and skills that the game might help to develop. Right now some of the tags are already being used by GoPlay!, a system to find games in Debian, but it a very alpha state. The purpose is to make it configurable so that parents can decide which tags are important for them. I hope to achieve that in the next version of the program. I hope that the overall scheme can be understood, but I plan to write a rationale about it as soon as I can, as well as develop some examples so that they can be easily understood. I know that the tags might be a bit subjective and probably a bit culturally biased. The former is not avoidable, there will always be some kind of subjectivity in these kind of classification, so I won’t fight the impossible to achieve absolute objectiveness. I’m trying to compensate that by allowing parents and tutors decide the subjectivity they want to have by selecting and priorizing the tags. About being multicultural, I cannot do that on my own, as I’m not that multicultural myself, so I won’t try to invent what other cultures might be worried about or not based on some fuzzy stereotypes I might have about them. If someone from a different culture steps forward and wants to help, they will be welcome. I prefer to rely on other people from different cultures help me to broaden the classification. Feedback is of course welcome and encouraged.