As older versions are still available, I noticed that the beginning of this Privacy Policy has changed over the years. There used to be a first sentence explaining the general approach Google takes towards your data. But read yourself:

August 14, 2000:

Google respects and protects the privacy of the individuals that use Google’s search engine services. _[...]

Well, that sounds fair.

July 1, 2004:

At Google, we strive to develop innovative services to better serve our users. We recognize that privacy is an important issue, so we design and operate our services with the protection of your privacy in mind. _[...]

Hey, they want to bring us innovation. Okay, at least they think about privacy—in the second sentence.

October 14, 2005,
August 7, 2008,
January 27, 2009,
March 11, 2009:

At Google we recognize that privacy is important. _[...]

Yes, they are aware that privacy is important, but they might do whatever they want with your data.

October 3, 2010,
March 1, 2012

_[...]

From here on, no such sentence exists anymore. I leave it to you what that means.

The following is a totally inaccurate benchmark, but I want to share some numbers. The MacPorts repository used here contains lots of directories with only a few files in each, often only a single file. This makes operations walking the .svn directories in the tree very expensive.

Listing status of files:

~/src/macports/trunk-svn $ time svn st

real	3m39.347s
user	0m1.450s
sys	0m5.900s

~/src/macports/trunk-svn17 $ time svn17 st

real	0m23.788s
user	0m1.914s
sys	0m2.297s

Update without changes (locking the whole working copy against concurrent access):

~/src/macports/trunk-svn $ time svn up
At revision 83750.

real	2m32.855s
user	0m1.202s
sys	0m5.060s

~/src/macports/trunk-svn17 $ time svn17 up
Updating '.':
At revision 83750.

real	0m5.362s
user	0m1.793s
sys	0m1.166s

Impressive results!

Unfortunately it grabs the global keyboard shortcuts Ctrl-1, Ctrl-2, …, Ctrl-0 and Ctrl-Option-1, Ctrl-Option-2, …, Ctrl-Option-6 to switch to the corresponding space by default. This prevents using any of these shortcuts in an application. I had defined some of those for use with my favorite editor vim, where the shortcuts ceased to work after the upgrade to Lion.

Even more unfortunate, it’s a tedious task to stop Mission Control from allocating these keyboard shortcuts. The GUI offers the configuration check boxes only for spaces which are currently enabled.

So the solution was to enable all possible spaces, which are capped at a maximum of 16, using the Mission Control interface. Then disable the check box for each of them in System Preferences > Keyboard > Keyboard Shortcuts.

As said a tedious task, but works. I was hoping to provide some defaults write command here, but I was unable to determine where these settings are stored.

But Devin Heitmueller from KernelLabs invested some time to remove the parts from tvtime that still needed the old API. The source is available from this mercurial repo.

hg clone http://www.kernellabs.com/hg/~dheitmueller/tvtime
cd tvtime
autoreconf -i -f
./configure --prefix=/usr/local --disable-nls
make
make install

There is also a report in Gentoo’s Bugzilla with a new ebuild attached, but I haven’t tried that. Installing the new patched tvtime to /usr/local works for now.

I am all ears if anyone can recommend an alternative to tvtime. I know about xawtv, but the interface is poor and offers less features than tvtime.

Fortunately, there is a patch attached to the mentioned bug report which resolves the problem:

cd /usr/src/linux
wget -O cx88-2.6.38-fix-driver-deadlocks.patch 'https://bugzilla.kernel.org/attachment.cgi?id=53722'
patch -p1 < cx88-2.6.38-fix-driver-deadlocks.patch

[Edited on 2011-04-23: replaced patch 52902 with 53722]

After applying the patch, build and install your kernel as usual. But there are still some more problems with 2.6.38 related to tvtime. See also my next post.

I do not follow kernel development close enough to know in which git tree this has to show up to confirm if it has been merged yet. Hopefully this patch will make it into the next kernel release.

$ echo abc def
abc def
$ echo !$
def

A common use case would be mkdir and cd:

$ mkdir foo
$ cd !$

You can also insert the last argument of the previous command and continue typing with <ESC>.:

$ echo abc def
abc def
$ echo <ESC>. ghi
def ghi

Oh, the little things…

for i in *.txt; do
    mv $i $i.old
done

But if the glob pattern does not match anything it will be preserved unchanged in the command. This results in command execution of mv *.txt *.txt.old which fails because no file named *.txt (literally!) exists.

As this is not the desired behavior, here is a way how to do this as expected without forking using the nullglob bash shell option.

oldnullglob=$(shopt -p nullglob)
shopt -s nullglob

for i in *.txt; do
    mv $i $i.old
done

eval "$oldnullglob" 2>/dev/null
unset oldnullglob

This will silently prevent the execution of the mv command. If you use failglob instead of nullglob bash will interrupt the evaluation of any command if the glob pattern did not match anything.

Disclaimer: Be careful with this option, as this will not be the expected behavior in all cases. Most (in)famously it breaks bash-completion if you set it in your interactive bash session. I suggest to use it temporary only.

This is the script /usr/local/bin/ssl-cert-check which checks the expiry date of the certificate files passed as arguments:

#!/bin/bash

DAYS=30

for file in "$@"; do
    openssl x509 -checkend $(( 86400 * $DAYS )) -in "$file" > /dev/null
    if [ $? != 0 ]; then
        echo "==> Certificate $file is about to expire soon:"
        openssl x509 -enddate -in "$file" -noout
    fi
done

And the corresponding cronjob entry checking SSL certificates once a day:

6       6    * * *   root   /usr/local/bin/ssl-cert-check /etc/apache2/ssl/*.crt /etc/ssl/certs/dovecot.pem

I prefer IRC as communication protocol for multi-user chat and instant messaging. To keep in contact with users of other protocols/clients I use BitlBee which is a gateway connecting other chat networks like Jabber/XMPP and ICQ to your own IRC server.

IRC is a well-established open protocol, but unfortunately it lacks encryption or other measures to secure the transmission of information. I don’t want to run an open BitlBee server, but password protection in plaintext is quite useless if you are in an untrusted network. Authentication should be done with a challenge-response method to avoid leaking passwords, but IRC as a very old protocol does not offer anything like this. And again communication itself would still be unencrypted.

Many people use their terminal-based IRC client irssi over SSH. This way the client runs on the same machine as bitlbee, so a very simple solution would be to bind the server socket to localhost only in this case. For me this is not an option as I am using a GUI-based IRC client xchat locally.

Fortunately it’s possible to secure any TCP connection using SSL!

Unfortunately BitlBee itself does not have builtin SSL support for the server. But a general solution for this problem exists: stunnel. This program acts as a general wrapper around any stream socket based program and is often in use for inetd based services.

Setup instructions

The following instructions are for setting up bitlbee over xinetd with stunnel to secure the connections. Be aware that this inetd approach will spawn a new process for each incoming connection. This setup is not meant to serve many users at once, but works fine for personal use.

First we have to generate and self-sign a new certificate to be used with SSL:

# openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout /etc/stunnel/bitlbee.pem -out /etc/stunnel/bitlbee.pem

Usually you need to be root to write to /etc/stunnel. Of course you can also use a pre-existing certificate signed by a well-known CA or request a new one.

Only stunnel for BitlBee needs to read the certificate file, so we will need a new user bitlbee for this purpose. On my Debian system the package management already added such a user, so your mileage may vary.

# adduser --system --group --disabled-login --disabled-password --home /var/lib/bitlbee/ bitlbee
# chmod 700 /var/lib/bitlbee/
# chown bitlbee:bitlbee /etc/stunnel/bitlbee.pem

Then we need to set up xinetd to secure the connection using stunnel. I modified the basic configuration file provided with the BitlBee source for this; changes are marked in bold text below. The following file should be saved as /etc/xinetd.d/bitlbee:

## xinetd file for BitlBee. Please check this file before using it, the
## user, port and/or binary location might be wrong.

## This file assumes you have ircd somewhere in your /etc/services, if things
## don't work, check that file first.
service ircd
{
        socket_type     = stream
        protocol        = tcp
        wait            = no

        ## You most likely want to change these two
        user            = bitlbee
        server          = /usr/bin/stunnel
        server_args     = -p /etc/stunnel/bitlbee.pem -l /usr/local/sbin/bitlbee

        ## You might want to limit access to localhost only:
        # bind            = 127.0.0.1

        ## Thanks a lot to friedman@splode.com for telling us about the type
        ## argument, so now this file can be used without having to edit
        ## /etc/services too.
        type            = UNLISTED
        port            = 6667
}

After the file is in place, xinetd configuration files need to be read again:

# /etc/init.d/xinetd reload

Now you should be able to connect to bitlbee using your favorite IRC client! Make sure you enable SSL for this connection. If you are using a self-signed certificate you will have to verify it, of course.

For bitlbee usage, you should refer to the official documentation. And maybe I will also write down some basic setup instructions for a closed server in the near future…

$ pastie --help
Usage: pastie [options] [files...]

Options:
    -h, --help          display this help
    -l, --lang    set language of the paste
    -p, --private       make paste private

If --lang is not specified, this script will try to determine the type of each
file automatically based on the extension. If no files are given on the
command line it reads from standard input.

You can download it here:
http://pastie.org/904797

The script is public domain, so do whatever you want with it.

Although this is the initial release, I bumped the version number to 1.6 already. During testing the script I pasted itself several times to pastie.org. I set a arbitrary higher version number to avoid confusion in case the previous pastes ever turn up in Google or wherever.

Update:
Seems like their parser for shell is a bit broken and doubles the heredoc starting and ending sequences in the output. For whatever reason it appears as “<<END<<END”. Please use the raw version for download instead of copy & paste.