Various, unrelated news:

Thanks to Marvin Stark my project syrep is now available in Debian. As you might know all the cool kids have written their own distributed revision control systems. This is my contribution on this topic. Although I started to work on it four years ago syrep is still unrivaled and unbeaten in its specific feature set. (Which is admittedly very different from the feature set of most other software in this area.)

Thanks to CJ van den Berg and Sjoerd Simons (and a few others from #pulseaudio) PulseAudio is now available in Debian, the auxiliary GUI tools like pavucontrol seem to be still missing. Nonetheless: it's now easier then ever to try PulseAudio:

sudo aptitude install pulseaudio \
    pulseaudio-module-hal \
    pulseaudio-esound-compat \
    pulseaudio-utils \
    libgstreamer-plugins-pulse0.10-0 \
    pulseaudio-module-gconf \
    pulseaudio-module-x11 \
    pulseaudio-module-zeroconf

For the next months I will focus on my Diplomarbeit (German equivalent of a master thesis). Due to this I passed maintainership of Avahi to Trent Lloyd and of PulseAudio to Pierre Ossman. I hope to resume maintainership of both projects in January.

My first non-trivial kernel patch has been merged into Linus' kernel, although the 2.6.19 merge window was already closed. I take this as birthday present from Linus.

If you have a laptop (such as the MSI S270) with Ricoh SD/MMC interface (not one of the new controllers which are SDHCI compatible, but the old ones where the SD/MMC is a virtual PCMCIA slot identifying itself as Bay1Controller), then please support me in writing a Linux driver for it and request the necessary documentation and datasheets from Ricoh. For more information on this issue see this posting on the s270-linux mailing list, and this followup.

That's all for now.

A few minutes ago I released Avahi 0.6.14 which besides other, minor fixes and cleanups includes a new component avahi-autoipd. This new daemon is an implementation of IPv4LL (aka RFC3927, aka APIPA), a method for acquiring link-local IP addresses (those from the range 169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol available. However, this one tries to do it right and integrates well with the rest of Avahi. For a longer rationale for adding this tool to our distribution instead of relying on externals tools, please read this mailing list thread.

It is my hope that this tool is quickly adopted by the popular distributions, which will allow Linux to finally catch up with technology that has been available in Windows systems since Win98 times. If you're a distributor please follow these notes which describe how to integrate this new tool into your distribution best.

Because avahi-autoipd acts as dhclient plug-in by default, and only activates itself as last resort for acquiring an IP address I hope that it will get much less in the way of the user than previous implementations of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the name I chose for my mDNS implementation when I first started to work on it) source code repository, 18 months after Trent and I decided to join our two projects under the name "Avahi" and 12 months after the release of Avahi 0.1, it's time for a little "State of the Lemur" post.

To make it short: Avahi is ubiquitous in the Free Software world. ;-)

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many minor distributions have it. A quick Google-based poll I did a few weeks ago shows that it is part of at least 19 different distributions, including a range of embedded ones. The list of applications making native use of the Avahi client API is growing, currently bearing 31 items. That list does not include the legacy HOWL applications and the applications that use our Bonjour compatibility API which can run on top of Avahi, hence the real number of applications that can make use of Avahi is slightly higher. The first commercial hardware appliances which include Avahi are slowly appearing on the market. I know of at least three such products, one being Bubba.

If you package Avahi for a distribution, add Avahi support to an application, or build a hardware appliance with Avahi, please make sure to add an item to the respective lists linked above, it's a Wiki. Thank you! (Anonymous registration without Mail address required, though)

Play around with Cairo: Check!

One thing that has been sitting on my TODO list for a very long time was playing around with Cairo. No longer! Yesterday I spent a little time on hacking a Cairo based equivalent of KDE's Filelight (Which BTW is one of the two programs that KDE has but GNOME really lacks, the other being KCacheGrind). The result after two hours is this:

This screenshot shows the development tree of my Syrep tool.

This tool has definitely nicer anti-aliased graphics than Filelight, doesn't it? The source code is here: fring.py. Anyone interested in turning this into a proper GNOME application?

Thanks to Marc-Andre Lureau there's now a jhbuild file for PulseAudio. And there is this (little bit chaotic) Wiki page in GNOME Live! about the relation of PulseAudio and GNOME.

A few weeks ago I wrote a new page for our Wiki where I tried to describe the steps necessary to get the most out of PulseAudio. It's called the Perfect Setup.

A few minutes ago I released PulseAudio 0.9.5 and new versions of the auxiliary tools. The changelog:

• Add module-hal-detect, a module that detects all local sound hardware using HAL and loads the necessary modules. Handles hot-plug and hot-removal of audio devices. (Contributed by Shahms E. King)
• Add shared memory transfer method for local clients
• Update module-volume-restore to automatically restore the output device last used by an application in addition to the volume it last used
• Add a new module module-rescue-streams for automatically moving streams to another sink/source if the sink/source they are connected to dies
• Add support for moving streams "hot" between sinks/sources
• Reduce memory consumption and CPU load as result of Valgrind/Massif profiling
• Add new module module-gconf for reading additional configuration statements from GConf
• Fix module-tunnel to work with the latest protocol
• Miscellaneous fixes

One of the nicest new features of PulseAudio 0.9.5 is HAL integration (which has been contributed by Shahms King). PulseAudio will now automatically detect all available sound devices and will make use of them. It supports both hot-plug and hot-remove.

Another nice feature is the GConf integration which allowed us to add another nice application to the PulseAudio toolset: the PulseAudio Preferences utility:

The idea is to have a simple, nice configuration dialog that allows configuration of the more exotic features of PulseAudio which we do not enable by default due to security considerations or to not confuse the user. Right now a lot of features are hidden behind non-trivial configuration file statements. This preferences tool shall make them available for the users which are not so keen on editing configuration files.

Playing around with Valgrind's Massif tool and KCachegrind I did a little bit of memory and perfomance profiling of the PulseAudio daemon. The 0.9.5 release contains a lot of optimizations which are result of this work.

Before:

After:

These plots show the memory consumption against the time, from starting the server, to playing stream, to stopping the stream and shutting down the server again. The major improvement was actually an update to libsamplerate done by its maintainer to improve the memory handling of that library. (He didn't release an updated version of his library containing the changes shown in the plots yet).

PulseAudio had the nice feature of remembering the playback volume of every application for quite a while. Starting with 0.9.5 PulseAudio it also remembers the output device for every application. Together with an updated Volume Control tool which now allows moving streams between sinks while they are played this can be used to configure a ruleset like "Ekiga always on the USB headset, Rhytmbox always on the external speakers" very intuitively and easily:

And here's a final screenshot showing all the tools we currently have for PulseAudio 0.9.5.

I always think twice before entering my name in any web form or posting to a mailing list. Is the web site/list respectable? Do the owners of the web site have any commercial interest in my name (spam, marketing, ...)? Would I ever regret that my name can be found with Google in context with this web site/mailing list? If I enter my name is it used for collecting data about me? Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers to these questions are unsatisfactory. I like to be in control of my name. If I am not confident that I remain in control I don't enter my name to any service.

Recently it came to my attention that Canonical decided to create an account (!) for me in their commercial, proprietary bug tracker called "Launchpad". I never asked for one! I never even considered having one, because their service clearly is nothing that would pass the tests mentioned above. They are a commercial service, my account data is apparently "content" for them, they don't seem to have any privacy policy. (At least I couldn't find any, the navigation is pretty crappy.)

Canonical's nimbus of being "the good guys" doesn't hinder them to incorporate data from free sources (apparently they got my data from the Debian BTS) and make a commercial service of it, without even asking the original contributors if that would be OK with them, or if it is OK to incorporate their name or personal profile in the service. Apparently Canonical is not much better than a common spam harvester: generating personal profiles for business, without consent of the "victim".

If anyone from Canonical reads this: It is not OK for me to use my name as "content" for your commercial, proprietary service. Please remove any reference to my name from your "account" database. I don't want to have a Launchpad account. I don't plan to use Launchpad. Let me decide if I ever want to join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in a service where Hitler apparently already has six (!) accounts. I am very sure that I don't want to be part of that community.

Are you a Win32 hacker and looking for something worthwhile to do in Free Software? We're eagerly looking for someone to port Avahi to that platform. Now that D-Bus is available on Win32, the last major stumbling block for this feat is no more.

I am happy to bring you yet another release of Avahi, everyone's favourite Zeroconf stack.

• Add a new D-Bus method for changing the mDNS host name during runtime. This functionality is only available to members of the UNIX group "netdev", which is the same access group that is enforced by GNOME's NetworkManager daemon. Since NM will probably be the most prominent user of this new method, we decided to limit access to the same group. The access group can be set by passing --with-avahi-priv-access-group= to "configure". If you need more sophisticated access control you can freely edit /etc/dbus/system.d/avahi-dbus.conf.
• Add a new utility "avahi-set-host-name" which is a command line wrapper around the aforementioned SetHostName() method.
• Bonjour API compatibility library:
  • Implement DNSServiceUpdateRecord()
  • Allow passing NULL as callback function for DNSServiceRegister()
  • Implement subtype registration in DNSServiceRegister() in a way that is compatible with Bonjour.
  • Update to newer copy of dns_sd.h
• If the host name changes update names of static services wich contain wildcards.
• Don't build documentation about embedding the Avahi mDNS stack into other programs by default. This is a feature used only by embedded developers. Pass --enable-core-docs to "configure" to enable building these docs, like in Avahi <= 0.6.12.
• Build Qt documentation only when Qt support is enabled in the configuration. Same for GLib.
• Change algorithm used to find a new host name on conflict. In Avahi <= 0.6.12 a conflicting host name of "foobar" would be changed to the new name "foobar2". With 0.6.13 "foobar-2" will be picked instead. This follows Bonjour's behaviour and has the advantage not confusing people with regular host names ending in digits.
• Don't disable all static services when SIGHUP is recieved.
• Fix build when Avahi is configured without Gtk+ but with Python support
• Fix build on MacOS X
• Support using Solaris DBM instead of gdbm for the service type database. The latter is still recommended
• Minor other fixes and documentation updates

The relevant NetworkManager bug about SetHostName() is #352828.

And our bug tracker is back to only two open bugs for Avahi. That's a good feeling, I can tell you!

Earlier this year I worked on reverse engineering the brightness control of my MSI S270 laptop. Turning this work into a proper kernel driver was still left to be done. Until yesterday... The result of yesterday's work are two kernel patches I already posted for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

1. acpi-ec-transaction.patch
2. acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate "MSI S270 Laptop Extras" under "Device Drivers"/"Misc devices" and recompile and install. After loading the s270 module, you now have a backlight class driver exposing its innards in /sys/class/backlight/s270bl/. For changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which allows reading the current state of the WLAN/Bluetooth subsystem. The platform drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan                 # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth            # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have an MSI S270 the machine is probably not recognized correctly by its DMI data. In that case you can pass force=1 to the driver which will force the driver load even when the DMI data doesn't match. YMMV. If everything works correctly please make sure to send me the output of dmidecode, so that I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop models, too (such as S260). YMMV. But don't come running when the driver causes your machine to explode! MSI laptops such as the S270 or S260 are often sold as OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100 or "SAM2000"), so if your laptop looks remotely like this one and dmidecode | grep MICRO-STAR yields at least a single line, and you are adventurous than you might want to test this driver on it. And don't forget to send me your dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn't support the generic backlight device class yet, which means no gnome-power-manager support for now.

Although this driver is based on reverse engineered data it should be legally safe even in the US. After I did my initial work on the S270 controls MSI supplied me with a register table of their ACPI Embedded Controller (which is what this driver interfaces with) and one of their engineers even tested my work.

Last but not least I created a mailing list for discussion of Linux on the MSI S270. Please join if you run Linux on one of these machines! I will announce future driver work for the S270 there.

Yesterday Apple Bonjour has been released under the Apache License 2.0, replacing the old much criticized (because non-free) APSL licensing.

What does this mean for Avahi? First of all although the Apache License is much better than the APSL it still isn't GPL compatible (at least in the eyes of the FSF), which effectively means that Bonjour still cannot be used by more than 66% of the Free Software projects available. Secondly Avahi is more powerful in most areas than Bonjour ever was. (In fact, there is only a single feature where Bonjour surpasses us: writable "Wide Area DNS-SD"). Avahi uses all the "hot" Free technologies like D-Bus and a has much better integration in the Linux networking subsystem. Avahi is more secure (chroot()...) Avahi is compatible API- and ABI-wise with Bonjour, but not the other way round. Avahi is now part of every major Linux distribution.

Avahi is actively developed. The aforementioned Wide Area DNS-SD is currently being worked on by Federico Lucifredi. Since I will write my master thesis about mDNS scalability a lot of additional development will be done for Avahi in the next month.

In short: Avahi is here to stay. Apple's move to the Apache license is too little, too late.

Update: the Bonjour client libraries are BSD licensed, so the 66% argument doesn't hold.

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is discussing whether to enable Zeroconf/Avahi in default installations. I would like to point out a few things:

The "No Open Ports" policy: This policy (or at least the way many people interprete it) seems to be thought out by someone who doesn't have much experience with TCP/IP networking. While it might make sense to enforce this for application-level protocols like HTTP or FTP it doesn't make sense to apply it to transport-level protocols such as DHCP, DNS or in this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

• Even the simplest DNS lookup requires the opening of an UDP port for a short period of time to be able to recieve the response. This is usually not visible to the administrator, because the time is too short to show up in netstat -uln, but nonetheless it is an open port. (UDP is not session-based (like TCP is) so incoming packets are accepted regardless where they come from)
• DHCP clients listen on UDP port 68 during their entire lifetime (which in most cases is the same as the uptime of the machine). DHCP may be misused for much worse things than mDNS. Evildoers can forge DHCP packets to change IP addresses and routing of machines. This is definitely something that cannot be done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in the local LAN. They (usually) don't come with any sort of authentication and they all are very easy to forge. The impact of forged mDNS packets is clearly less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn't allow you to change the IP address or routing setup (which forged DHCP allows) and because it cannot be used to spoof host names outside the .local domain (which forged DNS allows).

Enforcing the "No Open ports" policy everywhere in Ubuntu would require that both DNS and DHCP are disabled by default. However, as everybody probably agrees, this would be ridiculous because a standard Ubuntu installation couldn't even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in effect every single process that uses this function has an open port for a short time. And the DNS client code runs with user priviliges, so an exploit really hurts. dhclient (the DHCP client) runs as root during the entire runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and chroot()s.

It is not my intention to force anyone to use my software. However, enforcing the "No Open Ports" policy unconditionally is not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a default install is indeed problematic. However, if the "No Open Ports" policy is enforced on all other application-level software, there shouldn't be any application that would want to register a service with Avahi.

Starting Avahi "on-demand" is not an option either, because it offers useful services even when no local application is accessing is. Most notably this is host name resolution for the local host name. (Hey, yeah, Zeroconf is more than just stealing music.)

Remember: Zeroconf is about Zero Configuration. Requiring the user to toggle some obscure configuration option before he can use Zeroconf would make it a paradox. Zeroconf was designed to make things "just work". If it isn't enabled by default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this...