In response to Darren Kenny:

• On Linux (and FreeBSD) nss-mdns has been providing decent low-level integration of mDNS at the nsswitch level for ages. In fact it even predates Avahi by a few months. Porting it to Solaris would have been almost trivial. And, Sun engineers even asked about nss-mdns, so I am quite sure that Sun knew about this.
• You claim that our C API was internal? I wonder who told you that. I definitely did not. The API has been available on the Avahi web site for ages and is relatively well documented ^[1], I wonder how anyone could ever come to the opinion that it was "internal". Regarding API stability: yes, I said that we make no guarantees about API stability -- but I also said it was a top-priority for us to keep the API compatible. I think that is the best you can get from any project of the Free Software community. If there is something in an API that we later learn is irrecoverably broken or stupid by design, then we take the freedom to replace that or remove it entirely. Oh, and even Sun does things like that in Java, Just think of the Java 1.x java.lang.Thread.stop() API.
• nss-mdns does not make any use of D-Bus. It never did, it never will.
• GNOME never formally made the decision to go Avahi AFAIK. It's just what everyone uses because it is available on all distributions. Also, a lot of GNOME software can also be compiled against HOWL/Bonjour.
• Implementing the Avahi API on top of the Bonjour API is just crack. For a crude comparison: this is like implementing a POSIX compatiblity layer on top of the DOS API. Crack. Just crack. There is lot of functionality you can *never* emulate in any reasonable way on top of the current Bonjour API: properly integrated IPv4+IPv6 support, AVAHI_BROWSER_ALL_FOR_NOW, the fact that the Avahi API is transaction-based, all the different flag definitions, and a lot more. From a technical persepective emulating Avahi on top of Bonjour is not feasible, while the other way round perfectly is.

Let's also not forget that Avahi comes with a Bonjour compatibility layer, which gets almost any Bonjour app working on top of Avahi. And in contrast your Avahi-on-top-of-Bonjour stuff it is not inherently borked. Yes, our Bonjour compatibility layer is not perfect, but should be very easy to fix if there should still be an incompatibility left. And the API of that layer is of course as much set in stone as the upstream Bonjour API. Oh, and you wouldn't have to run two daemons instead of just one. And you would only need to ship and maintain a single mDNS package. Oh, and the compatibility layer would only be needed for the few remaing applications that still use Bonjour exclusively, and not by the majority of applications.

So, in effect you chose Bonjour because of its API and added some Avahi'sh API on top and this all is totally crackish. If you'd have done it the other way round you would have gotten both APIs as well, but the overall solution would not have been totally crackish. And let's not forget that Avahi is much more complete than Bonjour. (Maybe except wide-area support, Federico!).

Anyway, my original rant was not about the way Sun makes its decision but just about the fact that your Avahi-to-Bonjour-bridge is ... crack! And that it remains.

Wow, six times crack in a single article.

Footnotes:

[1] For a Free Software API at least.

Dear Sun Microsystems,

I wonder if the mythical "Project Indiana" consists of patches like these which among other strange things make the Avahi daemon just a frontend to the Apple Bonjour daemon. Given that Avahi is a superset of Bonjour in both functionality and API this is just so ridiculuous -- I haven't seen such a monstrous crack in quite a while.

Sun, you don't get it, do you? That way you will only reach the crappiness, bugginess and brokeness of Windows, not the power and usability of Linux.

Oh, and please rename that "fork" of Avahi to something completely different -- because it actually is exactly that: something completely different than Avahi.

Love,

     Lennart

Anyone looking for free tickets for LinuxTag 2007 (Berlin)? Just ping me, and I'll send you one. (Be quick, they are limited!)

I will be speaking at following conferences in the next three months:

LinuxTag, Berlin

Ottawa Linux Symposium

LugRadio Live, Wolverhampton

GUADEC, Birmingham

Dear Lazyweb!

Does anyone know how I can teach GNU indent to cuddle opening function braces and the closing ')' of the argument list ? i.e.

int main(int argc, char* argv[]) {
}

instead of:

int main(int argc, char* argv[])
{
}

Any help appreciated!

So, you've always been annoyed by the fact that you have to load all those laptop, i2c, hwmon, hdaps Linux kernel modules manually without having spiffy udev doing that work for you automagically? No more! I just sent a patch to LKML which adds DMI/SMBIOS-based module autoloading to the Linux kernel.

Hopefully this patch will be integrated into Linus' kernel shortly. As soon as that happens udev will automatically recognize your laptop/mainboard model and load the relevant modules.

Module maintainers, please add MODULE_ALIAS lines to your kernel modules to make sure that they are autoloaded using this new mechanism, as soon as it gets commited in Linus' kernel.

For a fully automatically configured system only ACPI-DSDT-based module autoloading is missing. I.e. load the "battery" module only when an ACPI battery is actually around.

On popular request, here are a few suggestions how to make best use of Hugin for stitching your panoramas. You probably should have read some of the tutorials at Hugin's web site before reading these suggestions.

• Use manual exposure settings in your camera. On Canon cameras this means you should be using the "M" mode. Make sure choose good exposure times and aperture so that the entire range you plan to take photos of is well exposed. If you don't know how to use the "M" mode of your camera you probably should be reading an introduction into photography now. The reason for setting exposure values manually is that you want the same exposing on all photos from your settings.
• Disable automatic white balance mode. You probably should have done that anyway. "Semi-automatic" white balance mode is probably OK (i.e. selecting the white balance from one of the pre-defined profiles, such as "Daylight", "Cloudy", ...)
• Also manually set the ISO level. You probably should be doing that anyway.
• Using autofocus is probably OK.
• Try not not move around too much while taking the photo series. Hugin doesn't like that too much. It's OK to move a little, but you should do all the shots for your panorama from a single point, and not while moving on a circle, line, or even Bezier-line.
• When doing 360° panoramas it is almost guaranteed (at least in northern countries) that you have the sun as back light. That will overexpose the panorama in that direction and lower the contrast in the area. To work against this, you might want to choose to do your panorama shots at noon in summer when sun is in zenith. Gray-scaling the shot and doing some other kind of post-processing might be a way to ease this problem.
• To work against chromatic aberration it is a good idea to use large overlap areas, and doing your shots in "landscape" rather then "portrait" (so that only the center of each image is used in the final image)
• Running hugin/enblend on an encrypted $HOME (like I do) won't make you particularly happy.
• Pass -m 256 to enblend. At least on my machine (with limited RAM and dm-crypt) things are a lot faster that way.
• Sometimes moving things (e.g. people) show up twice (or even more times) in the resulting panorama. Sometimes that is funny, sometimes it is not. To remove them, open the seperate tif files before feeding them into enblend into Gimp and cut away the things you want to remove from all but one of these images. Then pass that on to enblend.
• If regardless how many control points you set in Hugin the images just don't fit together, you should probably run "Optimize Everything" instead of just "Optimize Positions".
• When doing your shots, make sure to hold the camera all the time at the same height, to avoid having to cut too much of the image away in the final post-processing. This is sometimes quite difficult, especially if you have images with no clear horizon.
• Remember that you can set horizontal and vertical lines as control points in Hugin! Good for straitening things out and making sure that vertical things are actually vertical in the resulting panorama.

Following an invitation of the Nokia 770/N800 multimedia team I've been visiting the Nokia research center in Helsinki last week. A good opportunity to get some more material for Hugin:

Jeff now started to use lennartpoettering for tagging his blog stories... AWESOME!