Earlier today I switched Fedora over to install PulseAudio instead of the venerable EsounD by default.
Category: projects
... whether the guys behind this know about this?
It's a pleasure to see as many projects as possible making use of Avahi. OTOH I believe that all solutions should speak the same protocol. Using Apple's somewhat standardized link-local iChat/XMPP protocol (which is what Telekinesis does) seems to be the best option to me: because you get MacOSX interoperability for free and many IM clients (including many on Windows) already contain support for this as well.
Seems CUPS now comes with Zeroconf/Bonjour network printer browsing support included in the upstream tarball. I haven't tried this myself, but presumably CUPS should work on Avahi as well, since we ship a -- these days nearly perfect -- Bonjour compatibility library.
In Fedora Rawhide this functionality seems to be enabled already. Other distibutions, please follow!
Seems at least one good thing came from the recent Apple buyout of CUPS/Easy Software Products: I can now remove one item from my TODO list which has been there for a long time already.
For those interested: here're my slides for my presentations at LRL and OLS:
- Ottawa Linux Symposium 2007: Cleaning up the Linux Desktop Audio Mess (Not too much new stuff here if you already read my LCA slides)
- LugRadio Live 2007: Six Use Cases for Avahi
LWN linked a short summary of my OLS talk.
- 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:
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!