All posts by Lennart Poettering

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

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.

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

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.

I wonder …

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.

CUPS 1.3b1 gained Zeroconf support

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.

Im Zentrum der Macht

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

Project Indiana

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

DMI-based Autoloading of Linux Kernel Modules

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.

On Using Hugin

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

On popular request, here are a few suggestions how to make best use of Hugin for stitching your panoramas. You probably should have read some of the tutorials at Hugin’s web site before reading these suggestions.

  • Use manual exposure settings in your camera. On Canon cameras this means
    you should be using the “M” mode. Make sure choose good exposure times and
    aperture so that the entire range you plan to take photos of is well exposed.
    If you don’t know how to use the “M” mode of your camera you probably should
    be reading an introduction into photography now. The reason for setting
    exposure values manually is that you want the same exposing on all photos from
    your settings.
  • Disable automatic white balance mode. You probably should have done that
    anyway. “Semi-automatic” white balance mode is probably OK (i.e. selecting
    the white balance from one of the pre-defined profiles, such as “Daylight”,
    “Cloudy”, …)
  • Also manually set the ISO level. You probably should be doing that anyway.
  • Using autofocus is probably OK.
  • Try not not move around too much while taking the photo series. Hugin doesn’t like that too much. It’s OK to move a little, but you should do all the shots for your panorama from a single point, and not while moving on a circle, line, or even Bezier-line.
  • When doing 360° panoramas it is almost guaranteed (at least in northern
    countries) that you have the sun as back light. That will overexpose the
    panorama in that direction and lower the contrast in the area. To work against
    this, you might want to choose to do your panorama shots at noon in summer when
    sun is in zenith. Gray-scaling the shot and doing some other kind of
    post-processing might be a way to ease this problem.
  • To work against chromatic aberration it is a good idea to use large overlap areas, and doing your shots in “landscape” rather then “portrait” (so that only the center of each image is used in the final image)
  • Running hugin/enblend on an encrypted $HOME (like I do) won’t make you particularly happy.
  • Pass -m 256 to enblend. At least on my machine (with limited RAM and dm-crypt) things are a lot faster that way.
  • Sometimes moving things (e.g. people) show up twice (or even more times) in the resulting panorama. Sometimes that is funny, sometimes it is not. To remove them, open the seperate tif files before feeding them into enblend into Gimp and cut away the things you want to remove from all but one of these images. Then pass that on to enblend.
  • If regardless how many control points you set in Hugin the images just don’t fit together, you should probably run “Optimize Everything” instead of just “Optimize Positions”.
  • When doing your shots, make sure to hold the camera all the time at the same height, to avoid having to cut too much of the image away in the final post-processing. This is sometimes quite difficult, especially if you have images with no clear horizon.
  • Remember that you can set horizontal and vertical lines as control points in Hugin!
    Good for straitening things out and making sure that vertical things are
    actually vertical in the resulting panorama.