Older blog entries for firefly (starting at number 8)

David Zeuthen stole my idea yesterday...

...and I only got it ten minutes ago. Damn, that man is fast!

Intelligent Directories

Basically, what I've just described is "just" a variant of "intelligent directories". Why should directories just be passive containers? Why not allow extra work to take place behind the scenes when certain magic directories get updated?

I hate configuration files and I hate programs that I manually have to run to catch updates.

I want intelligent directories that automatically email/rsync/backup when I copy/move files to them. I want intelligent directories I can drop fonts or video codecs into.

And I want intelligent directories I can drop applications in.

Poor Man's Union Mount

(commentary on OLPC applications management)

1) there shall be a daemon

2) the daemon sets up inotify watches on /applications

3) when a new directory shows up, it creates symlinks from /usr/bin/app-cmd to /applications/appdir/app-cmd

4) same thing happens for libraries, manpages.

5) UI data files (sounds, icons, glade files) -- some will have to be symlinked or copied, some can stay "private".

6) notifications have to be posted to the desktop environment: .desktop files, MIME magic files, MIME icons, application icoms -- touching a directory may be enough (because some other daemon-like entity will pick up that signal and take it from there).

7) if there's already an application with the same name, we can create /usr/bin/app-cmd-v1.2 and /usr/bin/app-cmd-v2.0 symlinks in addition to moving /usr/bin/app-cmd to point to the newest version of the app.

Think of this sorta like udev for applications...

why does cpio -i (that is, the copy-in mode) copy files out of the archive and cpio -o (that is, the copy-out mode) copy files into an archive?

There are two main versions of the C++ ABI in the free world. That's one of the fun things we have to deal with. We solve it by supplying a wrapper around g++ that compiles everything twice; once with a compiler that supports one ABI and once with a compiler that supports the other one.

Some fun filename mangling and parameter massaging takes place behind the scenes in order to make that work.

It now works well enough that I've managed to build a proper autopackage for Scribus 1.3.2 and install it locally (non-root) on charybdis, my desktop machine.

This is good<tm>.

That's nothing, Mike. Try Habermas some day. Half-page sentences are not unusual in his works (which are quite banal, if you manage to penetrate the thick German academic style). One reason why he has become so unreasonably influential and supposedly widely read must be exactly that he is extremely hard to understand.

The Lonely Crowd is another one of those badly written (and boring) books that got extremely influential. The research behind it seems rather poor, too.

I'm afraid that's sociology for you :(

Autopackage is Yet Another Packaging System.

As if there weren't already enough of those. The unique feature it has is that it is distribution neutral. You can make one autopackage and install it on Red Hat, SuSE, and Ubuntu.

The LSB tries to accomplish the same thing both by standardizing a directory structure and by standardizing a package format + a set of standard packages.

Unfortunately, it is not enough. Applications need to integrate well with Gnome and KDE these days. They also need more binary portability than LSB can easily provide.

I'm testing Gnome Blog...

Okay, so Gnome Blog can't upload images to advogato -- and it can't handle links to them either.

But editing the entry afterwards to manually link to an image works fine :)

First post!

I just registered the Autopackage project here a few minutes ago and was asked about the license. "The license? Uhh, GPL, I think... lemme check".

Yes, most of it is GPL and some parts are by necessity LGPL and there's a bit that looks like the non-advertising BSD.

But some of it doesn't carry a clear license. Another item for the TODO list, I guess :/