Avahi/Zeroconf patch for distcc updated

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

I finally found them time to sit down and update my venerable Avahi/Zeroconf patch for
. A patched distcc
automatically discovers suitable compiler servers on the local network, without
the need to manually configure them. (Announcement).

Here’s a quick HOWTO for using a patched distcc like this:

  • Make sure to start distccd (the server) with the new
    --zeroconf switch, This will make it announce its services on the
  • Edit your $HOME/.distcc/hosts and add +zeroconf. This
    magic string will enable Zeroconf support in the client, i.e. will be expanded
    to the list of available suitable distcc servers on your LAN.
  • Now set $CC to distcc gcc globally for your login
    sessions. This will tell all well-behaving build systems to use distcc
    for compilation (this doesn’t work for the kernel, as one notable exception).
    Even better than setting $CC to distcc gcc is setting it to
    ccache distcc gcc which will enable ccache in addition to distcc. i.e. stick something like this in your ~/.bash_profile: export CC="ccache distcc gcc"
  • And finally use make -j `distcc -j` instead of plain make
    to enable parallel building with the right number of concurrent processes.
    Setting $MAKEFLAGS properly is an alternative option, however is suboptimal if
    the evalutation is only done once at login time.

If this doesn’t work for you than it is a good idea to run distcc
to get a list of discovered distcc servers. If this list
isn’t complete then this is most likely due to mismatching GCC versions or
architectures. To check if that’s the case use avahi-browse -r
and compare the values of the cc_machine and
cc_version fields. Please note that different Linux distributions use
different GCC machine strings. Which is expected since GCC is usually patched quite
a bit on the different distributions. This means that a Fedora distcc
(the client) will not find a Debian distccd (the server) and vice
versa. But again: that’s a feature, not a bug.

The new -j and --show-hosts options for distcc are useful for non-zeroconf setups, too.

The patch will automatically discover the number of CPUs on remote machines
and make use of that information to better distribute jobs.

In short: Zeroconf support in distcc is totally hot, everyone should have it!

For more information have a look on the announcement of my original
patch from 2004
(at that time for the historic HOWL Zeroconf daemon), or read the new
announcement linked above.

Distribution packagers! Please merge this new patch into your packages! It
would be a pity to withhold Zeroconf support in distcc from your users any

Unfortunately, Fedora doesn’t include any distcc packages. Someone should be
changing that (who’s not me ;-)).

You like this patch? Then give me a kudo on ohloh.net. Now that I earned a golden 10 (after kicking Larry Ewing from position 64. Ha, take that Mr. Ewing!), I need to make sure I don’t fall into silver oblivion again. 😉

Avahi 0.6.22

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

A couple of minutes ago I released Avahi
into the wild, the newest iteration of everyone’s favourite zero
configuration networking suite.

Avahi Logo

You ask why this is something to blog about?

Firstly, new in this version is Sjoerd Simons’ avahi-gobject
library, a GObject wrapper around the Avahi API. It allows full GObject-style
object oriented programming of Zeroconf applications, with signals and
everything. To all you GNOME/Gtk+ hackers out there: now it is even more fun to
hack your own Zeroconf applications for GNOME/Gtk+!

Secondly, this is the first release to ship i18n support. For those who
prefer to run their systems with non-english locales[1] this should
be good news. I’ve always been a little afraid of adding i18n support, since
this either meant that I would have contstantly had to commit i18n patches, or that I
would have needed to move my code to GNOME SVN. However, we now have Fedora’s Transifex,
which allows me to open up my SVN for translators without much organizational
work on my side. Translations are handled centrally, and commited back to my
repository when needed. It’s a bit like Canonical’s Rosetta, but with a focus
on commiting i18n changes upstream, and without being closed-source crap.

You like this release? Then give me a kudo on ohloh.net. My
ego still thirsts for gold, and I am still (or again) 25 positions away from
that. 😉


[1] Personally, I run my desktop with $LC_MESSAGES=C, but
LANG=de_DE, which are the settings I can recommend to everyone who is from Germany and wants to stay
sane. Unfortunately it is a PITA to configure this on
GNOME, though.

Back from India

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/photos/india.html

FOSS.in was one of the best conferences I have ever
been to, and a lot of fun. The organization was flawless and I can
only heartily recommend everyone to send in a presentation proposal for next year’s
iteration. I certainly hope the commitee is going to accept my proposals next year again. Especially the food was gorgeous.

I will spare you the usual conference photos, you can find a lot of those on flickr. However, what I will not spare you are a couple of photos I shot in Bangalore, Srirangapatna and Mysore.





Lazyweb: POSIX Process Groups and Sessions

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/pgrp-vs-session.html

Dear Lazyweb,

I have trouble understanding what exactly POSIX process groups and sessions
are good for. The POSIX
are very vague on this. What exactly is the effect of being in a process
group with some other process, and what does being in the same session with it
add on top? And what is the benefit of being a group/session leader in contrast of just being a normal random process in the group/session?

The only thing I understood is that kill(2) with a negative first
parameter can be used to “multicast” signals to entire process groups, and that
SIGINT on C-c is delivered that way. But, is that all? The POSIX docs say
… for the purpose of signaling, placement in foreground or background,
and other job control actions
“, which is very vague. What are those
other job control actions?“. What does job control persist of besides
multicasting signals? And what is “placement in foreground or background” other
than delivering signals?

And I totally don’t get POSIX sessions and how they differ from POSIX process groups. Please enlighten me!


stet and AGPLv3

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2007/11/21/stet-and-agplv3.html

Many people don’t realize that the GPLv3 process actually began long
before the November 2005 announcement. For me and a few others, the GPLv3
process started much earlier. Also, in my view, it didn’t actually end
until this week, the FSF released the AGPLv3. Today, I’m particularly
proud that stet was the first software released covered by the terms of
that license.

The GPLv3 process focused on the idea of community, and a community is
built from bringing together many individual experiences. I am grateful
for all my personal experiences throughout this process. Indeed, I
would guess that other GPL fans like myself remember, as I do, the first
time the heard the phrase “GPLv3”. For me, it was a bit
early — on Tuesday 8 January 2002 in a conference room at MIT. On
that day, Richard Stallman, Eben Moglen and I sat down to have an
all-day meeting that included discussions regarding updating GPL. A key
issue that we sought to address was (in those days) called the
“Application Service Provider (ASP) problem” — now
called “Software as a Service (SaaS)”.

A few days later, on the telephone with Moglen2 one morning, as I stood in my
kitchen making oatmeal, we discussed this problem. I pointed out the
oft-forgotten section 2(c) of the GPL [version 2]. I argued that contrary
to popular belief, it does have restrictions on some minor
modifications. Namely, you have to maintain those print statements for
copyright and warranty disclaimer information. It’s reasonable, in other
words, to restrict some minor modifications to defend freedom.

We also talked about that old Computer Science problem of having a
program print its own source code. I proposed that maybe we needed a
section 2(d) that required that if a program prints its own source to
the user, that you can’t remove that feature, and that the feature must
always print the complete and corresponding source.

Within two months, Affero
GPLv1 was published
— an authorized fork of the GPL to test
the idea. From then until AGPLv3, that “Affero clause”
has had many changes, iterations and improvements, and I’m grateful
for all the excellent feedback, input and improvements that have gone
into it. The
result, the
Affero GPLv3 (AGPLv3) released on Monday
, is an excellent step
forward for software freedom licensing. While the community process
indicated that the preference was for the Affero clause to be part of
a separate license, I’m nevertheless elated that the clause continues
to live on and be part of the licensing infrastructure defending
software freedom.

Other than coining the Affero clause, my other notable personal
contribution to the GPLv3 was management of a software development
project to create the online public commenting system. To do the
programming, we contracted with Orion Montoya, who has extensive
experience doing semantic markup of source texts from an academic
perspective. Orion gave me my first introduction to the whole
“Web 2.0” thing, and I was amazed how useful the result was;
it helped the leaders of the process easily grok the public response.
For example, the intensity highlighting — which shows the hot
spots in the text that received the most comments — gives a very
quick picture of sections that are really of concern to the public. In
reviewing the drafts today, I was reminded that the big red area in
section 1 about “encryption and authorization codes”
changed and less intensely highlighted by draft 4
. That quick-look
gives a clear picture of how the community process operated to get a
better license for everyone.

Orion, a Classics scholar as an undergrad, named the
software stet for its original Latin definition: “let it
stand as it is”. It was his hope that stet (the software) would
help along the GPLv3 process so that our whole community, after filing
comments on each successive draft, could look at the final draft and
simply say: Stet!

Stet has a special place in software history, I believe, even if it’s
just a purely geeky one. It is the first software system in history to
be meta-licensed. Namely, it was software whose output was its own
license. It’s with that exciting hacker concept that I put up today
a Trac instance
for stet, licensed under the terms of the AGPLv3 [ which is now on
Gitorious ]

Stet is by no means ready for drop-in production. Like most software
projects, we didn’t estimate perfectly how much work would be needed.
We got lazy about organization early on, which means it still requires a
by-hand install, and new texts must be carefully marked up by hand.
We’ve moved on to other projects, but hopefully SFLC will host the Trac
instance indefinitely so that other developers can make it better.
That’s what copylefted FOSS is all about — even when it’s

1Actually, it’s
under AGPLv3 plus an exception to allow for combining with the
GPLv2-only Request Tracker, with which parts of stet combine.

After writing this blog post, I found
evidence in my email archives from early 2002, wherein Henry Poole (who
originally suggested the need for Affero GPL to FSF), began cc’ing me anew
on an existing thread. In that thread, Poole quoted text from Moglen
proposing the original AGPLv1 idea to Poole. Moglen’s quoted text in
Poole’s email proposed the idea as if it were solely Moglen’s own. Based
on the timeline of the emails I have, Moglen seems to have written to Poole
within 36-48 hours of my original formulation of the idea.

While I do not accuse Moglen of plagiarism, I believe he does at least
misremember my idea as his own, which is particularly surprising, as Moglen
(at that time, in 2002) seemed unfamiliar with the Computer Science concept
of a quine; I had to explain that concept as part of my presentation of my
idea. Furthermore, Moglen and I discussed this matter in a personal
conversation in 2007 (around the time I made this blog post originally) and
Moglen said to me: “you certainly should take credit for the Affero
GPL”. Thus, I thought the matter was thus fully settled back in
2007, and thus Moglen’s post-2007 claims of credit that write me out of
Affero GPL’s history are simply baffling. To clear up the confusion his
ongoing claims create, I added this footnote to communicate unequivocally
that my memory of that phone call is solid, because it was the first time I
ever came up with a particularly interesting licensing idea, so the memory
became extremely precious to me immediately. I am therefore completely
sure I was the first to propose the original idea of mandating preservation
of a quine-like feature in AGPLv1§2(d) (as a fork/expansion of
GPLv2§2(c)) on the telephone to Moglen, as described above. Moglen
has never produced evidence to dispute my recollection, and even agreed
with the events as I told them back in 2007.

Nevertheless, unlike Moglen, I do admit that creation of the final text of
AGPLv1 was a collaborative process, which included contributions from
Moglen, Poole, RMS, and a lawyer (whose name I don’t recall) whom Poole
hired. AGPLv3§13’s drafting was similarly collaborative, and included
input from Richard Fontana, David Turner, and Brett Smith, too.

Finally, I note my surprise at this outcome. In my primary community
— the Free Software community — people are generally extremely
good at giving proper credit. Unlike the Free Software community, legal
communities apparently are cutthroat on the credit issue, so I’ve

Emulated atomic operations and real-time scheduling

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

Unfortunately not all CPU architectures have native support for atomic
, or only support a very limited subset. Most
prominently ARMv5 (and
older) hasn’t any support besides the most basic atomic swap
operation[1]. Now, more and more free code is starting to
use atomic operations and lock-free
, one being my own project, PulseAudio. If you have ever done real-time
you probably know that you cannot really do it without
support for atomic operations. One question remains however: what to
do on CPUs which support only the most basic atomic operations

On the kernel side atomic ops are very easy to emulate: just disable
interrupts temporarily, then do your operation non-atomically, and afterwards
enable them again. That’s relatively cheap and works fine (unless you are on SMP — which
fortunately you usually are not for those CPUs). The Linux
kernel does it this way and it is good. But what to do in user-space, where you cannot just go and disable interrupts?

Let’s see how the different userspace libraries/frameworks do it
for ARMv5, a very relevant architecture that only knows an atomic swap (exchange)
but no CAS
or even atomic arithmetics. Let’s start with an excerpt from glibc’s
atomic operations implementation for ARM

/* Atomic compare and exchange.  These sequences are not actually atomic;
   there is a race if *MEM != OLDVAL and we are preempted between the two
   swaps.  However, they are very close to atomic, and are the best that a
   pre-ARMv6 implementation can do without operating system support.
   LinuxThreads has been using these sequences for many years.  */

This comment says it all. Not good. The more you make use of atomic
operations the more likely you’re going to to hit this race. Let’s
hope glibc is not a heavy user of atomic operations. PulseAudio however is, and
PulseAudio happens to be my focus.

Let’s have a look on how Qt4
does it:

extern Q_CORE_EXPORT char q_atomic_lock;

inline char q_atomic_swp(volatile char *ptr, char newval)
    register int ret;
    asm volatile("swpb %0,%1,[%2]"
                 : "=&r"(ret)
                 : "r"(newval), "r"(ptr)
                 : "cc", "memory");
    return ret;

inline int q_atomic_test_and_set_int(volatile int *ptr, int expected, int newval)
    int ret = 0;
    while (q_atomic_swp(&q_atomic_lock, ~0) != 0);
    if (*ptr == expected) {
	*ptr = newval;
	ret = 1;
    q_atomic_swp(&q_atomic_lock, 0);
    return ret;

So, what do we have here? A slightly better version. In standard
situations it actually works. But it sucks big time, too. Why? It
contains a spin lock: the variable q_atomic_lock is used for
locking the atomic operation. The code tries to set it to non-zero,
and if that fails it tries again, until it succeeds, in the hope that
the other thread — which currently holds the lock — gives it up. The
big problem here is: it might take a while until that happens, up to
1/HZ time on Linux. Usually you want to use atomic operations to
minimize the need for mutexes and thus speed things up. Now, here you
got a lock, and it’s the worst kind: the spinning lock. Not
good. Also, if used from a real-time thread the machine simply locks
up when we enter the loop in contended state, because preemption is
disabled for RT threads and thus the loop will spin forever. Evil. And
then, there’s another problem: it’s a big bottleneck, because all
atomic operations are synchronized via a single variable which is
q_atomic_lock. Not good either. And let’s not forget that
only code that has access to q_atomic_lock actually can
execute this code safely. If you want to use it for
lock-free IPC via shared memory this is going to break. And let’s not
forget that it is unusable from signal handlers (which probably
doesn’t matter much, though). So, in summary: this code sucks,

Next try, let’s have a look on how glib
does it:

static volatile int atomic_spin = 0;

static int atomic_spin_trylock (void)
  int result;

  asm volatile (
    "swp %0, %1, [%2]\n"
    : "=&r,&r" (result)
    : "r,0" (1), "r,r" (&atomic_spin)
    : "memory");
  if (result == 0)
    return 0;
    return -1;

static void atomic_spin_lock (void)
  while (atomic_spin_trylock())

static void atomic_spin_unlock (void)
  atomic_spin = 0;

g_atomic_int_exchange_and_add (volatile gint *atomic,
			       gint           val)
  gint result;

  result = *atomic;
  *atomic += val;

  return result;

Once again, a spin loop. However, this implementation makes use of
sched_yield() for asking the OS to reschedule. It’s a bit
better than the Qt version, since it doesn’t spin just burning CPU,
but instead tells the kernel to execute something else, increasing the
chance that the thread currently holding the lock is scheduled. It’s a
bit friendlier, but it’s not great either because this might still delay
execution quite a bit. It’s better then the Qt version. And probably
one of the very few ligitimate occasions where using
sched_yield() is OK. It still doesn’t work for RT — because
sched_yield() in most cases is a NOP on for RT threads, so
you still get a machine lockup. And it still has the
one-lock-to-rule-them-all bottleneck. And it still is not compatible
with shared memory.

Then, there’s libatomic_ops. It’s
the most complex code, so I’ll spare you to paste it here. Basically
it uses the same spin loop. With three differences however:

  1. 16 lock variables instead of a single one are used. The variable
    that is used is picked via simple hashing of the pointer to the atomic variable
    that shall be modified. This removes the one-lock-to-rule-them-all
  2. Instead of pthread_yield() it uses select() with
    a small timeval parameter to give the current holder of the lock some
    time to give it up. To make sure that the select() is not
    optimized away by the kernel and the thread thus never is preempted
    the sleep time is increased on every loop iteration.
  3. It explicitly disables signals before doing the atomic operation.

It’s certainly the best implementation of the ones discussed here:
It doesn’t suffer by the one-lock-to-rule-them-all bottleneck. It’s
(supposedly) signal handler safe (which however comes at the cost of
doing two syscalls on every atomic operation — probably a very high
price). It actually works on RT, due to sleeping for an explicit
time. However it still doesn’t deal with priority
problems — which is a big issue for real-time
programming. Also, the time slept in the select() call might
be relatively long, since at least on Linux the time passed to
select() is rounded up to 1/HZ — not good for RT either. And
then, it still doesn’t work for shared memory IPC.

So, what do we learn from this? At least one thing: better don’t do
real-time programming with ARMv5[2]. But more practically, how
could a good emulation for atomic ops, solely based on atomic swap
look like? Here are a few ideas:

  • Use an implementation inspired by libatomic_ops. Right
    now it’s the best available. It’s probably a good idea, though, to
    replace select() by a nanosleep(), since on recent
    kernels the latter doesn’t round up to 1/HZ anymore, at least when you
    have high-resolution timers[3] Then, if you can live
    without signal handler safety, drop the signal mask changing.
  • If you use something based on libatomic_ops and want to
    use it for shared memory IPC, then you have the option to move the
    lock variables into shared memory too. Note however, that this allows
    evil applications to lock up your process by taking the locks and
    never giving them up. (Which however is always a problem if not all
    atomic operations you need are available in hardware) So if you do
    this, make sure that only trusted processes can attach to your memory
  • Alternatively, spend some time and investigate if it is possible
    to use futexes to sleep on the lock variables. This is not trivial
    though, since futexes right now expect the availability of an atomic
    increment operation. But it might be possible to emulate this good
    enough with the swap operation. There’s now even a FUTEX_LOCK_PI
    operation which would allow priority inheritance.
  • Alternatively, find a a way to allow user space disabling
    interrupts cheaply (requires kernel patching). Since enabling
    RT scheduling is a priviliged operation already (since you may easily
    lock up your machine with it), it might not be too problematic to
    extend the ability to disable interrupts to user space: it’s just yet
    another way to lock up your machine.
  • For the libatomic_ops based algorithm: if you’re lucky
    and defined a struct type for your atomic integer types, like the
    kernel does, or like I do in PulseAudio with pa_atomic_t,
    then you can stick the lock variable directly into your
    structure. This makes shared memory support transparent, and removes
    the one-lock-to-rule-them-all bottleneck completely. Of course, OTOH it
    increases the memory consumption a bit and increases cache pressure
    (though I’d assume that this is neglible).
  • For the libatomic_ops based algorithm: start sleeping for
    the time returned by clock_getres()
    (cache the result!). You cannot sleep shorter than that anyway.

Yepp, that’s as good as it gets. Unfortunately I cannot serve you
the optimal solution on a silver platter. I never actually did
development for ARMv5, this blog story just sums up my thoughts on all
the code I saw which emulates atomic ops on ARMv5. But maybe someone
who actually cares about atomic operations on ARM finds this
interesting and maybe invests some time to prepare patches for Qt,
glib, glibc — and PulseAudio.

Update: I added two more ideas to the list above.

Update 2: Andrew Haley just posted something like the optimal solution for the problem. It would be great if people would start using this.


[1] The Nokia 770 has an ARMv5 chip, N800 has ARMv6. The OpenMoko phone apparently uses ARMv5.

[2] And let’s not even think about CPUs which don’t even have an atomic swap!

[3] Which however you probably won’t, given that they’re only available on x86 on stable Linux kernels for now — but still, it’s cleaner.

The next step

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

A few minutes ago, I finally released PulseAudio 0.9.7. Changes are numerous,
especially internally where the core is now threaded and mostly lock-free.
Check the rough list on the milestone page, announcement email. As many of you
know we are shipping a pre-release of 0.9.7 in Fedora 8, enabled by default. The final release
offers quite a few additions over that prerelease. To show off a couple of nice features, here’s a screencast, showing hotplug, simultaneous playback (what Apple calls aggregation) and zeroconfish network support:


Please excuse the typos. Yes, I still use XMMS, don’t ask [1]. Yes, you
need a bit of imagination to fully appreciate a screencast that lacks an audio track — but demos audio software.

So, what’s coming next? Earcandy, timer-based scheduling/”glitch-free” audio, scriptability through Lua, the todo list is huge. My unnoffical, scratchy, partly german TODO list for PulseAudio is available online.

As it appears all relevant distros will now move to PA by default. So,
hopefully, PA is coming to a desktop near you pretty soon. — Oh, you are one
of those who still don’t see the benefit of a desktop sound server? Then,
please reread this too
long email of mine
, or maybe this
ars.technica article

OTOH, if you happen to like this release, then consider giving me a kudo on ohloh.net, my ego wants a golden 10. 😉



[1] Those music players which categorize audio by ID3 tags just don’t
work for me, because most of my music files are very badly named. However, my
directory structure is very well organized, but all those newer players don’t
care about directory structures as it seems. XMMS doesn’t really either, but
xmms . does the job from the terminal.

Flameeyes, thank’s for hosting this clip.

Yummy Mango Yummy Lassi Yummy

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

Mango Lassi tastes a lot different than a milk shake, believe me! Also,
even if Mango Lassi was actually a western thing, do you know that just
recently I was witness of Sjoerd[1] ordering a Vindaloo Pizza
(or was it Korma?) at a Boston restaurant — italian pizza with indian-style curry on top. Now, that’s what some people
might be calling “ignorant of indian cuisine”. But actually I think that, like
in music, mixing different styles, combining things from different origins is a
good thing, and is what makes culture live.

[1] Who doesn’t have a blog. Can you believe it?

Mango Lassi

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

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:

Mango Lassi Screenshot

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
  • 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/


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
. I’d be very thankful for every icon submission!

Enforcing a Whitespace Regime

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

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



# 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))

                	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")))

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

			ignore = True


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


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

iLock-in: Apple locks Free Software out, but where’s the news?

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

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

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.

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.