Originally I wanted to keep out of the WTC-related discussions here because I still consider Advogato a OpenSource-related site... but yesterday they showed something in a german tv magazine that I have to tell the world about.
Remember the CNN pictures of the palestinian people
celebrating? German magazine "panorama" showed the
complete shot. There you can see that the life over there
went on as usual, only a few children celebrating because
a guy in a white t-shirt motivates them to do so. It also
shows that the old woman who celebrates does so because
they offered her cake, and she later denied that she did
it because of the WTC attack.
You can watch the clip in Real format here. It's a 10 minute movie in german, so you have been warned. You can find the CNN/palestinian part at 7:40.
config fs: I'm planning to abandon my proc fs
changes in a future version and instead write new
filesystem based on the proc fs code. Proc FS is a mess.
While most of the files
in /proc are quite convenient to read for human readers
they are almost unusuable for software. The problem is not
that parsing would be so difficult but that it is
impossible to add new fields once you have defined a text
format without breaking all software that reads it. Binary
files suffer from the same compatibility problems. A few
months ago several people convinced me on LKML to go the
"one-value-per-file" way for devreg, and the new
filesystem will enforce this even more than my proc fs
extensions. Every file will be strictly typed (string,
enum), dynamic directories will be possible, the type of a
can be retrieved using ioctls, and unlike my current proc
changes writing will be supported, too.
The more interesting part of the plan is that I want to support both persistent and non-persistent files. So there will be some daemon waiting, similar to devfsd, for files that have been flagged as persistent and will then store their new values when they have been changed. On initialization of a file the daemon will fill it with a previously stored value. Dynamic directories can have keys that can be used to find the correct one. I'm currently calling this concept config fs. Beside the replacement of proc fs for everything but processes it can be used for the configuration of the kernel and drivers. The current way of configuration definitely sucks, module options are a bad idea for most purposes because you cannot change them at runtime and they are not very useful if your driver handles several devices at the same time. They can only be used for the driver's global configuration, but not for the configuration of driver instances. IMHO module options should disappear for anything but boot-time configuration. The only frightening thing about the config fs idea is how close it is to Win2k's registry. It's a little bit less arcane because you can access it as a filesystem, but beside that there are only few differences between them. It could even make sense to use it for the general configuration of system software. bah...
I just wanted to point On2's VP3 codec that has been released in source form yesterday because it did not get as much press as it deserved, IMHO. VP3 is a very good codec with MPEG4-like quality, even if it is not their latest version (VP4). The license is a MPL with a compatibility clause: you are not allowed to take the code or use their patents to build something, that does not (also) encode or decode VP3 streams. While not perfect, it should be good enough to make me happy. It is at least better than the MPEG codecs that are poisened with patents. The source code has not been ported to Linux/Unix yet though, they just released the source for their Quicktime and VfW codecs.
I'm currently extending the device registry with a registry for drivers. It started as a simple idea to solve the problem of displaying several drivers that handle a single physical device. This is quite complicated as I use one-value per /proc file, so a list of values means creating a dynamic directory for enumerating them. I thought of creating a directory per driver and linking from them to the devices instead, which turned out as being a great idea. This does not only allow me to make more information about the drivers available, but moving the devfs node descriptors to the drivers solved some problems with finding the right node of unusual devices that have, for example, several nodes with the same interface. Even more important, I can now add device node ids that can be persistent identifiers of a physical device's devfs node (or major/minor number). This will make libdevreg much easier to use: if you want to find a device node just use its id as an argument to the find function. But even better, I now have an easy solution for having stable minor numbers in the kernel. Just fill a table (with the help of a /sbin/hotplug-style user space program) that maps device node ids on minor numbers. As a timeframe, I hope to have a version of devreg without the stable minor number thing ready in two or three weeks.
I am also writing on a system similar to the minor number thing but for major numbers with the major name instead of the device node id. It will hopefully be ready at the same time. This would solve Linus' decision of not allowing any new major numbers as it moves the major number location from the central register to the user or his distribution. I haven't seen any other patch doing this, which quite surprises me. However, I need this code for the device node id / minor number mapping.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!