Linux finally has a free mDNS/DNS-SD implementation (Apple Rendezvous/Bonjour, Zeroconf). Avahi 0.1 has been released yesterday and provides a LGPL’d embeddable mDNS core. See the homepage for more details.
Linux finally has a free mDNS/DNS-SD implementation (Apple Rendezvous/Bonjour, Zeroconf). Avahi 0.1 has been released yesterday and provides a LGPL’d embeddable mDNS core. See the homepage for more details.
I’ve been using mDNS on Linux for quite a while, with this setup:
http://www.iscblog.info/blog/display/80
It works quite well. How is this “finally” a free mDNS implementation, when there have been others before (with much fewer dependencies, I might add?)
HOWL contains code licensed under AFPL, which is considered “non-free” by some. Hence many distributions (e.g. Debian) don’t ship with it.
That’s the APSL, not the AFPL.
– lathiat
(e.g. Debian) don’t ship with it.
According to Package search engine from debian.org it does: http://tinyurl.com/9h3ve
Yes, Debian non-free. But not the real thing. non-free is not considered to be part of Debian.
Yes, Debian non-free
I explicitly searched for “main”
The page I linked to says:
“You have searched for howl in packages names and descriptions in distribution unstable, section main..”
Read this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302462
It only entered main because maintainer lied about license.
Read this regarding HOWLs status in Debian/Ubuntu:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302462
It really depends on your definition of free, Avahi is fully LGPL, where as others in the past have not been (various BSD + APSL related things that scare people away) – there was one GPL core, but it was very limited and only a core, it was also not very secure.
As for dependencies, avahi requires very small to actually run, the various dependencies provide extra features which you would use in say, a desktop environment, where you would already have these kinds of dependencies anyway.
– Lathiat
apt-cache search howl
howl-utils – Tools for use with Howl (mDNSPublish and mDNSBrowse)
libhowl-dev – Development files for the Howl library
libhowl-doc – Documentation files for Howl library
libhowl0 – Library for Zeroconf service discovery
mdnsresponder – Howl Rendezvous/mDNS service responder daemon
apt-cache policy libhowl0
libhowl0:
Installed: (none)
Candidate: 0.9.8-2
Version table:
0.9.8-2 0
500 http://ftp.us.debian.org unstable/main Packages
apt-cache policy mdnsresponder
mdnsresponder:
Installed: (none)
Candidate: 0.9.8-2
Version table:
0.9.8-2 0
500 http://ftp.us.debian.org unstable/main Packages
apt-cache policy howl-utils
howl-utils:
Installed: (none)
Candidate: 0.9.8-2
Version table:
0.9.8-2 0
500 http://ftp.us.debian.org unstable/main Packages
Is mDNS/DNS-SD??????
This is explained on Avahi’s home page.
http://www.freedesktop.org/Software/Avahi
Oh many thanks, that clarifies it
http://en.wikipedia.org/wiki/Zeroconf#Apple.27s_protocol
Yeah, this is another one of those Gnome-centric software that requires million other libs, the kitchen sink, your dog and priest, and lawer to be present.
Why the hell the need for python when it’s written in Gtk with Gnome-lib dependency already there?
It realy seems like they purpously add an extra few dependencies just to make it harder for users.
It is not in any way gnome-centric, there is simply an avahi-discover tool which uses GTK for its interface, if we used QT then you could make the argument we were ‘KDE Centric’
Additionally, we provide a GLIB adapter because thats what we use, it’s easy to integrate it into any kind of main loop and we will gladly accept patches for ready to go adapters to anything else. You can still build it without glib.
As for python, it’s convenient, and it has nothing to do with gtk and we do not use any gnome libs at all.
Get over it, these things are *not* required to use them, they simply make it nicer, and face it, the majority of people already have most of these things anyway, if they don’t, they can build without them.
– Lathiat
Way too many dependencies? I count two *mandatory* packages – expat, and libdaemon. Hardly excessive, really.
Of course if you have the various gtk and python libraries installed, you get some extra support apps and extra language bindings, but they’re strictly optional.
avahi depends on libdaemon and libexpat only. Everything else is optional.
It isn’t “written in Gtk”. (Which is stupid anyway) And it doesn’t have any (optional or not) Gnome dependency.
Whats wrong with Apple’s mDNS? I understand they “fixed” their licensing for it. They even note in the dev spec that hardware/embedded space people are encouraged to embed mDNS daemons onto their hardware.
I’d really really like to see a C# / Mono wrapper or implementation of mDNS/ DNS-SD. I’ve gotten nothing but angst from SWIG so far whenever I try to use it.
Myren
No, they didn’t fix the licensing. mDNSResponder itself is still published under APSL. Only one header file that needs to be included by client applications has been relicensed to BSD.
Myren again,
Avanti actually looks like it has a somewhat indirect but very viable C# implementation: it uses DBUS (“to communicate form the application to the session-daemon”).
Of course, two paragraphs down: “The mDNS responder is implemented as a C library (“avahi-core”) which is embeddable into other applications”… which makes me really wonder.
I’m hoping the app just needs to file some info against a daemon via dbus and it’ll work from there.
Myren
It’s not Avanti. It’s Avahi.
Yes, you can take avahi’s mDNS stack and embedd it into other (presumably embedded) applications. For that you can use avahi-core.
Yes, the DBUS-API is public and may be used directly by any application, including those written in C#. In fact the client side tools that ship with Avahi are written in Python using the DBUS API natively.
Indeed I am actually talking with someone at the moment and we plan to implement native (well, using dbus) bindings for Mono.
Avahi-core would not be used by most people and having C# bindings to that *probably* wouldn’t make sense, if someone really wanted it they could just bind to it themselves I suspect.
– Lathiat
Well, claim what you want but the whole package with the standalone app and the client utils do need
DBUS 0.3x or newer (optional, for IPC with client applications)
gtk2 + glade2 (optional, for the GUI avahi-discover-standalone tool)
doxygen (optional, for the API documentation)
Python2.4, pygtk2 (optional, for the client tools)
python-twisted (optional, for the tool avahi-bookmarks)
Otherwise you only get the core and still need something if you want to do your own discover.
So yes, it has a helluvalot dependencies if you want functionality.
Why coudn’t all that been done in plain Gtk?
I for one will never use Python for anything. Although it comes with my distro, Slackware, I simply standardized the apps that I use to be Gtk and Qt only.
If it’s written in other toolkit I will simply not use it. I haven’t found anything yet that would’ve been such a huge “must-have” to make me bother with other toolkits.
Sure, you’re free to use whatever toolkit you want to write your app, but don’t expect me to use the app.
I’ve gone through installing Python crap before and will never do it again.
Well, on the bright side, when switching to Icewm and looking for a config tool for it, I came across IceWMCP which needs Python.
Rather than bothering with Python I learned how to hand edit Icewm config files. Once less dependency!
Choce is good. And I choose less dependencies!
You should learn bash, you would have even less dependencies!
Try to boot your kernel with init=/bin/bash , i’m sure you can fit all the dependencies on a floppy disk.
Lathiat and I breifly discussed bindings for mono languages such as C#. Im sure you will hear more about them shortly.
-i386