Am I the only one who thinks that the usefulness of Fedora Planet as severely limited because of the low signal-to-noise ratio that is due to far too many non-english (i.e. german, french) language posts?

If you want to know more about PulseAudio's relation to GNOME (especially if you think PA is evil) then please read through this thread on desktop-devel, and especially this long email I posted as a reply a few minutes ago, where I try to debunk all the FUD that has been spread.

Yesterday, at the GNOME Summit in Boston I did a quick presentation of my new desktop input sharing hotness thingy, called "Mango Lassi" (Alternatively known as "GNOME Input Sharing"). Something like a Synergy done right, or an x2x that doesn't suck.

So, for those who couldn't attend, here's a screenshot, which doesn't really tell how great it is, and which might also be a bit confusing:

And here's a list of random features already available:

• Discover desktops to share mouse and keyboards with automatically via Avahi.
• Fully peer-to-peer. All Mango Lassi instances are both client and server at the same time. Other hosts may enter or leave a running session at any time.
• No need to open X11 up for the network
• You have a 50% chance that for your setup you don't need any configuration at all. In the case of the other 50% you might need to swap the order of your screens manually in a simple dialog, because Mango Lassi didn't guess correctly which screen is left and which screen is right.
• libnotify integration so that it tells you whenever a desktop joins or leaves your session.
• Shows a nice OSD on your screen when your screen's input is currently being redirected to another screen.
• Uses all those nifty GNOME APIs, like D-Bus-over-TCP, Avahi, libnotify, Gtk, ...
• Supports both the X11 clipboard and the selection, supporting all content types, and not just simple text -- i.e. you can copy and paste image data between Gimp on your screens
• Lot's of bugs and useless debug output, since this is basically the work of just three weekends.
• Tray icon

And here's a list of missing features:

• Drag'n'drop between screens. (I figured out how this could work, it's just a matter of actually implementing this, which is probably considerable work, because this would require some UI work, to show a download dialog and suchlike.)
• Integration with Matthias' GTK+ window migration patches, which would allow dragging GTK+ windows between screens. The migration code for GTK+ basically works. It's just a matter of getting them merged in GTK+ proper, and hooking them up properly with Mango Lassi, which probably needs some kind of special support in Metacity so that we get notified when a window drag is happening and the pointer comes near the edges of the screens.
• Encryption, authentication: Best solution would probably be that D-Bus would get native TLS support which we could then make use of.
• Support for legacy operating systems like Windows/MacOS. I personally don't care much about this. However, Zeroconf implementations and D-Bus is available on Windows/MacOS too, and the exposed D-Bus interfaces are not too X11-centric, so this should be doable without too much work.
• UI Love, actually hooking up the desktop order changing buttons, save and restore the order automatically.
• MPX support (this would *rock*)

And finally, here's where you can get it:

git clone http://git.0pointer.de/repos/mango-lassi.git/

gitweb

Oh, and I don't take feature wishlist requests for this project. If you need a feature, implement it yourself. It's Free Software after all! I'd be happy if someone would be willing to work on Mango Lassi in a way that it can become a really good GNOME citizen and maybe even a proper part of it. But personally I'll probably only work on it to a level where it does all I need to work with my Laptop and my Desktop PC on my desk in a sane way. I am almost 100% busy with PulseAudio these days, and thus unable to give Mango Lassi the love it could use. So, stand up now, if you want to take over maintainership!

Hmm, Mango Lassi could use some good artwork, starting with an icon. I am quite sure that someone with better graphic skills then me could easily create a delicious icon perhaps featuring a glass of fresh, juicy Mango Lassi. I'd be very thankful for every icon submission!

Hahaha.

Yours truely, Lennart (C list blogger).

I hope other distributions will follow.

So, you want to be as tough as the kernel guys and enforce a strict whitespace regime on your project? But you lack the whitespace fascists with too many free time lurking on your mailing list who might do all the bitching about badly formatted patches for you? Salvation is here:

Stick this pre-commit file in your SVN repository as hooks/pre-commit and give it a chmod +x and your SVN server will do all the bitching for you -- for free:

#!/bin/bash -e

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

# Require some text in the log
$SVNLOOK log -t "$TXN" "$REPOS" | grep -q '[a-zA-Z0-9]' || exit 1

# Block commits with tabs or trailing whitespace
$SVNLOOK diff -t "$TXN" "$REPOS" | python /dev/fd/3 3<<'EOF'
import sys
ignore = True
SUFFIXES = [ ".c", ".h", ".cc", ".C", ".cpp", ".hh", ".H", ".hpp", ".java" ]
filename = None

for ln in sys.stdin:

        if ignore and ln.startswith("+++ "):
                filename = ln[4:ln.find("\t")].strip()
                ignore = not reduce(lambda x, y: x or y, map(lambda x: filename.endswith(x), SUFFIXES))

        elif not ignore:
		if ln.startswith("+"):

			if ln.count("\t") > 0:
                        	sys.stderr.write("\n*** Transaction blocked, %s contains tab character:\n\n%s" % (filename, ln))
                        	sys.exit(1)

                	if ln.endswith(" \n"):
                        	sys.stderr.write("\n*** Transaction blocked, %s contains lines with trailing whitespace:\n\n%s<EOL>\n" % (filename, ln.rstrip("\n")))
                        	sys.exit(1)

		if not (ln.startswith("@") or \
			ln.startswith("-") or \
			ln.startswith("+") or \
			ln.startswith(" ")):

			ignore = True

sys.exit(0)
EOF

exit "$?"

This will cause all commits to be blocked that don't follow my personal tase of whitespace rules.

Of course, it is up to you to adjust this script to your personal taste of fascism. If you hate tabs like I do, and fear trailing whitespace like I do, than you can use this script without any changes. Otherwise, learn Python and do some trivial patching.

Hmm, so you wonder why anyone would enforce a whitespace regime like this? First of all, it's a chance to be part of a regime -- where you are the dictator! Secondly, if people use tabs source files look like Kraut und Rüben, different in every editor^[1]. Thirdly, trailing whitespace make clean diffs difficult^[2]. And think of the hard disk space savings!

I wonder how this might translate into GIT. I have a couple of GIT repositories where I'd like to enforce a similar regime as in my SVN repositories. Suggestions welcome!

Oh, and to make it bearable to live under such a regime, configure your $EDITOR properly, for example by hooking nuke-trailing-whitespace.el to 'write-file-hooks in Emacs.

Footnotes

[1] Yes, some people think this is a feature. I don't. But talk to /dev/null if you want to discuss this with me.

[2] Yes, there is diff -b, but it is still a PITA.

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.

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

$ 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?

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!