I wonder …

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/send-file.html

… 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.

I wonder …

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/send-file.html

… 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.

CUPS 1.3b1 gained Zeroconf support

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/cups-bonjour.html

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.

CUPS 1.3b1 gained Zeroconf support

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/cups-bonjour.html

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.

Slides for LRL and OLS

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/ols-lrl-slides.html

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.

Slides for LRL and OLS

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/ols-lrl-slides.html

For those interested: here’re my slides for my presentations at LRL and OLS:

LWN linked a short summary of my OLS talk.

Im Zentrum der Macht

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/im-zentrum-der-macht.html

The Government District in Berlin, with the Reichstag and the offices of the members of the Bundestag:

Im Zentrum der Macht

The Diana Temple in the Hofgarten in Munich:

Hofgarten

The Königsplatz in Munich:

Königsplatz

The Residenz in Munich:

Residenz

View from the tower of Old St. Peter in Munich:

St. Peter

Green pastures of Hamburg-Wohldorf:

Wohldorfer Feld

All my panoramic photos. (Warning! Page contains a lot of oversized, badly scaled images.)

Im Zentrum der Macht

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/im-zentrum-der-macht.html

The Government District in Berlin, with the Reichstag and the offices of the members of the Bundestag:

Im Zentrum der Macht

The Diana Temple in the Hofgarten in Munich:

Hofgarten

The Königsplatz in Munich:

Königsplatz

The Residenz in Munich:

Residenz

View from the tower of Old St. Peter in Munich:

St. Peter

Green pastures of Hamburg-Wohldorf:

Wohldorfer Feld

All my panoramic photos. (Warning! Page contains a lot of oversized, badly scaled images.)

Re: Avahi – what happened. on Solaris..?

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/project-indiana-part2.html

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.

Re: Avahi – what happened. on Solaris..?

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/project-indiana-part2.html

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.

Project Indiana

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/project-indiana.html

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

Project Indiana

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/project-indiana.html

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

Virtually Reluctant

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2007/06/12/virtually-reluctant.html

Way back when User
Mode Linux (UML)
was the “only way” the Free Software
world did anything like virtualization, I was already skeptical.
Those of us who lived through the coming of age of Internet security
— with a remote root exploit for every day of the week —
became obsessed with the chroot and its ultimate limitations. Each
possible upgrade to a better, more robust virtual environment was met
with suspicion on the security front. I joined the many who doubted
that you could truly secure a machine that offered disjoint services
provisioned on the same physical machine. I’ve recently revisited
this position. I won’t say that Xen has completely changed my mind,
but I am open-minded enough again to experiment.

For more than a decade, I have used chroots as a mechanism to segment a
service that needed to run on a given box. In the old days
of ancient BINDs and sendmails, this was often the best we could do
when living with a program we didn’t fully trust to be clean of
remotely exploitable bugs.

I suppose those days gave us all rather strange sense of computer
security. I constantly have the sense that two services running on
the same box always endanger each other in some fundamental way. It
therefore took me a while before I was comfortable with the resurgence
of virtualization.

However, what ultimately drew me in was the simple fact that modern
hardware is just too darn fast. It’s tough to get a machine these
days that isn’t ridiculously overpowered for most tasks you put in
front of it. CPUs sit idle; RAM sits empty. We should make more
efficient use of the hardware we have.

Even with that reality, I might have given up if it wasn’t so easy. I
found a good link
about Debian on Xen
, a useful entry in
the Xen Wiki
, and some good
network
and LVM
examples
. I also quickly learned how to use RAID/LVM
together for disk redundancy inside Xen instances
. I even got bonded
ethernet
working with some help to add
additional network redundancy.

So, one Saturday morning, I headed into the office, and left that
afternoon with two virtual servers running. It helped that Xen 3.0 is
packaged properly for recent Ubuntu versions, and a few obvious
apt-get installs get you what you need on edgy and
feisty. In fact, I only struggled (and only just a bit) with the
network, but quickly discovered two important facts:

VIF network routing in my opinion is a bit easier to configure and
more stable than VIF bridging, even if routing is a bit
slower.

sysctl -w net.ipv4.conf.DEVICE.proxy_arp=1 is needed to
make the network routing down into the instances work
properly.

I’m not completely comfortable yet with the security of virtualization.
Of course, locking down the Dom0 is absolutely essential, because
there lies the keys to your virtual kingdom. I lock it down with
iptables so that only SSH from a few trusted hosts comes
in, and even services as fundamental as DNS can only be had from a few
trusted places. But, I still find myself imagining ways people can
bust through the instance kernels and find their way to the
hypervisor.

I’d really love to see a strong line-by-line code audit of the
hypervisor and related utilities to be sure we’ve got something we can
trust. However, in the meantime, I certainly have been sold on the
value of this approach, and am glad it’s so easy to set up.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close