Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/apple-sucks.html

So,
Apple now blocks third-party software from accessing iPods. But is behaviour like that
news? No, unfortunately not at all.

Let’s have a look on two technologies that are closely related to the iPod
and Apple-style media playback: DAAP (Digital
Audio Access Protocol) and RAOP
(Remote Audio Output Protocol). RAOP is the protocol that is spoken when
you want to output audio from iTunes over the network on your AirPort base
station. DAAP is the popular protocol which you can use to swap music
between multiple iTunes instances on a LAN. Both technologies use cryptographic hashes to block interoperable alternative implementations.

Now, the RAOP client crypto key has been extracted from iTunes, hence its
now possible to implement alternative software that takes the role of iTunes
and streams audio to an AirPort. However, noone managed to extract the RAOP
server key yet, hence noone is able to implement software that exposes itself
as AirPort-compatible audio sink on the network, so that iTunes could stream
data to it.

With DAAP it’s a similar situation: iTunes uses cryptographic hashes to make
sure that only real iTunes instances can swap audio with each other. This key
has been broken multiple times, hence there are now a couple of alternative
DAAP implementations, which can swap audio with iTunes (Rhythmbox being one
example). However, with iTunes 7 Apple changed the cryptographic key once
again, and until now nobody managed to break it.

So basically, Apple now dongles AirPorts to iTunes, iTunes to iTunes and
iTunes to iPods. The whole Apple eco-system of media devices and software is dongled
together. And none of the current iterations of the underlying technologies
have been fully broken yet.

While the audio files you can buy at the iTunes shop may now be DRM-free,
you’re still locked into the Apple eco-system if you do that. They replaced DRM with
vendor lock-in.

This lock-in behaviour is childish at best. DAAP once was the de-facto
standard for swapping media files in LANs. Swapping files in LANs is
perfectly legitimate and legal. Then, Microsoft/Intel started to include a
similar technology in UPnP, the UPnP
MediaServer. An open technology that has now been included in endless media
server devices. Several Free Software implementations exist (most notably gUPnP). These days, uPNP MediaServer is
ubiquitous, DAAP is no more. Apple had the much better starting position, but
they blew it, because of their childish locking-out of alternative
implementations.

I believe that DAAP is the superior protocol in comparison to UPnP
MediaServer. (Not really surprising, since I wrote most of Avahi, which is a free implementation of
mDNS/DNS-SD (“Zeroconf”), the (open) Apple technology that is the basis for
DAAP.) However, due to the closedness of DAAP I would recommend everyone to
favour UPnP MediaServer over DAAP. It’s a pity.

Both DAAP and UPnP MediaServer are transfer protocols, nothing that is ever
directly exposed to the user. Right now, Free Software media players support DAAP much better than UPnP MediaServer. Hopefully, they will start to
abstract the differences away, and allow swapping music the same way over DAAP
and over uPnP. And hopefully, DAAP will eventually die or Apple will open
it. They have shown that they are able to change for the good, they became much
more open with WebKit, and they changed the license of Bonjour to a real Free
Software license. Let’s hope they will eventually notice that locking users in
makes their own technology irrelevant in the long term.

Oh, and let’s hope that Jon finds the time to break all remaining Apple crypto keys! Jon, DAAP 7.0, and the RAOP server key is waiting for you! I’d love to make PulseAudio RAOP-compatible, both as client and as server.

Update: Ars Technica has an update on this.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/lugradio.html

Woah, I am interviewed on LugRadio. (@ 71:09)

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/ccache.html

$ ccache -s | egrep "(cache hit|cache miss)"
cache hit                        3518652
cache miss                        168484
$ echo $((168484*1000/3518652))
47
$

Less than 5% of the compiler invocations on my development machine since 2004 actually processed new and unseen code.

I’m still unsure, though, what this is telling me?

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/foms-2008.html

Only three days left for sending in your paper for FOMS 2008, the best Free Software
multimedia conference/workshop around. The best chance to meet all the
important people from the major multimedia projects!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/pulseaudio-fedora.html

Earlier today I switched Fedora over to install PulseAudio instead of the venerable EsounD by default.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/guadec-2007-slides.html

My GUADEC 2007 slides.

Post Syndicated from Lennart Poettering original https://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.

Post Syndicated from Lennart Poettering original https://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.

Post Syndicated from Lennart Poettering original https://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.

Post Syndicated from Lennart Poettering original https://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.

Post Syndicated from Lennart Poettering original https://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

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/linuxtag-freikarten.html

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

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/conferences-2007.html

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

LinuxTag, Berlin

Ottawa Linux Symposium

LugRadio Live, Wolverhampton

GUADEC, Birmingham

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/cuddle-function.html

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!

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/dmi-based-module-autoloading.html

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.

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/tag.html

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