To fix this, create a file named .Xresources in your home directory and add the following line:

*.multiClickTime: 500

Set its value to whatever interval you prefer (the example is using 500 ms).

Edit: JetBrains support just mailed me that the root cause is a bug in the JDK, reported in 2004 and fixed in Java 7 (doh!): http://bugs.sun.com/view_bug.do?bug_id=5076635

Nun ist es ja Dank MNP (Mobile Number Portability) heutzutage kein Problem mehr, entsprechende Konsequenzen zu ziehen und den Netzbetreiber zu wechseln. Sollte man meinen. Der neue Netzbetreiber sollte Vodafone sein und nach schechten Erfahrungen mit Providern sollte es direkt zum Netzbetreiber gehen. Gesagt, getan. Schließlich kam es jedoch ganz anders…

Um bis zum Ablauf der Kündigungsfrist Ende Dezember bei discoPLUS noch halbwegs sinnvoll mobil erreichbar zu sein, sollte die Kombination Rufumleitung von o2 -> Vodafone mit nachträglicher Portierung der alten Rufnummer als Lösung dienen. Laut Vodafone kein Problem. Sollte man meinen. Zitat:

Sie können aber auch sofort bei Vodafone einen Vertrag abschließen und bis zum Portierungstag mit einer temporären VF D2 Rufnummer telefonieren. Wenn Sie wollen, sind Sie auf Ihrer zu portierenden Rufnummer beim bisherigen Dienstanbieter noch bis zum Vertragsende erreichbar.

Also am 28.11.2011 online einen passenden Vertrag bestellt. Der wurde erstmal einen Tag später kommentarlos “auf Ihren Wunsch hin” storniert. Eine Rückmeldung, was schief lief, habe ich bis heute nicht erhalten. Also habe ich den Vertriebskanal gewechselt und telefonisch bestellt. Zwei Tage später war dann die SIM-Karte da (allerdings nicht wie angekündigt via DHL, sondern via UPS). Nun wollte ich die nachträgliche Portierung in die Wege leiten. Dazu muss man wissen, dass das bei Vodafone nicht schriftlich oder online geht, sondern dass man dazu zwingend einen Vodafone-Shop aufsuchen muss. Also habe ich auch dieses Übel auf mich genommen – was tut man nicht für eine einigermaßen anständige Netzqualität. So suchte ich am Abend des 01.12.2011 den (offiziellen) Vodafone-Shop in der Heidelberger Innenstadt auf.

Ich staunte nicht schlecht, als man mir mitteilte, dass man nicht wisse, wie die Portierung für einen Geschäftskunden durchzuführen sei, faxte dann aber ein Portierungsformular an die Vodafone-Niederlassung Süd/West in Stuttgart. Laut einhelliger Auskunft von dritter Seite ist dieses Formular jedoch nicht für nachträgliche Portierungen geeignet – schließlich fehlten auf diesem jegliche Identifikationsmerkmale des Vodafone-Vertrags, auf den portiert werden soll.

Also kontaktierte ich daraufhin die telefonische Kundenbetreuung (die sich vollmundig “Business-Team” nennt). Der Mitarbeiter dort teilte mir freundlich, aber sichtlich ratlos mit, dass nachträgliche eingehende Portierungen für Geschäftskunden nicht möglich seien. Man könne lediglich den bestehenden Vertrag stornieren. Wieso diese Information in öffentlich zugänglichen Vodafone-Medien nirgends Erwähnung findet, konnte er mir aber auch nicht erklären. Ganz in Ruhe ließ ihn der Fall jedoch offenbar nicht, denn fünfzehn Minuten später rief er mich noch einmal an und teilte mir mit, er werde den Fall am kommenden Tag mit der Fachabteilung klären.

Von dort erreichte mich am Morgen des 02.12.2011 tatsächlich auch ein Rückruf: Man habe mit dem Shop in Heidelberg gesprochen, ich möge dort am Abend nochmal persönlich vorstellig werden – man werde dann die gewünschte Portierung umsetzen. Bei Problemen solle der Shop-Mitarbeiter sich mit der Vodafone-Vertriebspartnerhotline in Verbindung setzen. Dort könne man im Fall der Fälle eventuelle Probleme aus dem Weg räumen.

Nun machte ich mich also am Abend wieder auf den Weg in den Vodafone-Shop in der Hoffnung, die Portierung endlich zum Abschluss bringen zu können. Zwischenzeitlich hatte ich auch die passende Dokumentation für Vertriebspartner, “Klartext Nr. 102″, aufgetan, in dem die Portierung akribisch genau incl. Screenshots beschrieben ist – auch für Geschäftskunden. Leider sollte dieser Wunsch jedoch nicht erfüllt werden: Nach über einer Stunde des Hin- und Her strich der Vodafone-Mitarbeiter im Shop vor Ort die Segel. Ich möge doch bitte meinen bestehenden Vertrag widerrufen und einen neuen Vertrag mit eingeschlossenem Portierungsauftrag abschließen. Dies habe ich dann schließlich auch getan, jedoch frage ich mich an dieser Stelle, wieso es einem Konzern wie Vodafone nicht möglich ist, eine Trivialität wie eine eingehende Portierung korrekt abzuwickeln bzw. konsistente Informationen darüber bereitzustellen, mit welchen Einschränkungen eine solche Portierung verbunden sein mag. Im Infodok 101 sowie im Klartext 102 ist davon nichts zu lesen.

Für mich bedeutet das Ganze: Außer Spesen nichts gewesen. Keine Portierung, den Vertrag habe ich widerrufen. Ob mein ersatzweise vor Ort beauftragter Portierungsauftrag so umgesetzt und zu den zugesicherten Online-Konditionen abgerechnet wird, wage ich nach dem bisherigen Chaos zu bezweifeln. Vodafone scheint jedenfalls ganz alltägliche Prozesse nicht im Griff zu haben und beschäftigt entweder Mitarbeiter, die das Peter-Prinzip bereits maximiert haben, oder spart so sehr bei den Schulungen, dass die eigenen Mitarbeiter durch die unternehmenseigenen Prozesse völlig überfordert sind.

As I eventually figured out the right URL to use in CUPS:

ipp://<hostname>:443/printers/lp1?encryption=required

Apart from that you need to make sure that IPP over SSL is turned on (which you can’t using the printer’s built-in menu, but only through its web-based management UI [Basic -> Device Security -> Network Security -> IPP over SSL -> Unblock] and [Advanced -> Secure Protocols -> SSL -> On]).

• Intel HD 3000 Power-Saving: Enable the following Kernel command-line options: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1
• Force ASPM: Enable the pcie_aspm=force Kernel command-line option
• In KDE, go to “System Settings” | “Desktop Effects” | “Advanced” and set the “Scale method” to “Crisp”.

Overall, this brings my T420s’s power consumption down below 9 W. For best results, use a recent Linux 3.1-rc pre-release.

To install:

sudo apt-add-repository \
ppa:thilo.ginkel/nvidia-graphics-drivers
sudo apt-get update
sudo apt-get upgrade


Caution: There are some reports on the nvnews.net forums that this driver version breaks Gnome / GTK applications under certain circumstances, which I can neither confirm nor deny as I am using KDE (but GTK apps work correctly for me). You have been warned, use at your own risk.

Da mich soetwas kategorisch stört – schließlich telefoniert das Auge mit – musste eine Lösung her. Mögliche Optionen waren: Das Aufkleben einer Displayschutzfolie, ein Displaytausch oder eine Restaurierung des aktuellen Displays.

Displayfolien waren nun noch nie mein Favorit, sind sie doch sehr schwer sauber aufzubringen. Ein Displaytausch wäre sehr aufwändig und möglicherweise kostspielig geworden und die Verfügbarkeit eines Ersatzdisplays war nicht einfach zu klären. Blieb also vorerst als Option, das bestehende Display zu restaurieren. Im Netz findet man diverse Erfahrungsberichte zu Displaypolituren für Handys, an einem Eurit 4000 scheint sich damit aber noch niemand versucht zu haben. Das klang also erstmal nach einer Option.

Erschwert wurde die Entscheidung pro oder contra Politur allerdings dadurch, dass der Swissvoice-Support keine Aussage zum Material der Displayoberfläche machen konnte, weshalb die Auswahl der korrekten Politur eher zur Glückssache ausartete (die gängigste Politur am Markt verträgt sich beispielsweise nicht mit Polycarbonaten).

Disclaimer: Die im Folgenden beschriebene Prozedur hat bei meinem Telefon zufällig funktioniert. Ich übernehme bei Nachahmungen keine Gewähr für eine Unschädlichkeit der Prozedur.

Lange Rede, kurzer Sinn: Ich habe in den sauren Apfel gebissen und einen Versuch mit “Displex Display Polish” unternommen, mit dem ich unter leichtem Druck unter Zuhilfenahme eines Wattepads das Display in geraden Bewegungen poliert habe. Vorher nicht vergessen, das Display rundum abzukleben, damit man nicht versehentlich den Rahmen mit poliert. Das Ergebnis kann sich durchaus sehen lassen – ich würde sogar sagen, das Display sieht fast wieder neuwertig aus.

Die Lösung war aber schlussendlich so simpel, dass ich sie hier dokumentieren möchte: Offenbar hat der Höreranschluss des Eurit 40 gegenüber dem Eurit 4000 eine andere Pin-Belegung. Ein passendes Kabel aus dem Zubehör, im Falle des Eurit 4000 ist das die Plantronics-P/N 27190-01, hat das Problem in Nullzeit gelöst.

Let’s see whether there will be any IPv6-based requests (except for my own ones thanks to the excellent SixXS service).

Welcome to the next evolutionary stage of the Internet!

Now, what if your laptop could automatically detect your working environment and disarm or re-arm the screen lock depending on its physical location? Well, it can: Turns out there are some nice hooks available to run scripts during various network state change events. The ones that will be of interest for us are if-up and if-down. Apart from that we make the assumption that it will be possible to detect the laptop’s “safe” home location by means of it being signed in to a given WiFi network (identified by its SSID).

Before proceeding, let’s make some further assumptions for the sake of simplicity:

• You are running a recent KDE version (the author uses 4.6.x – older versions may also work, though).
• The paths mentioned in this guide may be specific to Ubuntu/Debian. Your mileage for other distributions may vary.
• You have configured a screensaver through the KDE System Settings to automatically kick in after some time of inactivity.

The portion we will be automating is enabling and disabling the automatic screen lock after disengaging the screensaver using KDE’s kwriteconfig command. To do so, create a new script /etc/network/if-up.d/screenlock and populate it with the following content:

#!/bin/bash

SSID=
USERNAME=

/sbin/iwconfig wlan0 | /bin/grep -q ${SSID}

if [ $? = 0 ]; then
    logger "Disarming screen lock"
    su -c "/usr/bin/kwriteconfig --file kscreensaverrc \
       --group ScreenSaver --key Lock false" ${USERNAME}
else
    logger "Re-arming screen lock"
    su -c "/usr/bin/kwriteconfig --file kscreensaverrc \
       --group ScreenSaver --key Lock true" ${USERNAME}
fi

exit 0

Make sure not to forget to configure your user and SSID placeholder at the top of the script.

Also, make the script executable:

sudo chmod +x /etc/network/if-up.d/screenlock

So far, the script is only invoked when establishing a network connection. To also invoke it upon disconnecting, we need to create an appropriate symbolic link:

cd /etc/network/if-down.d/
sudo ln -s ../if-up.d/screenlock .

You can test whether the screen lock is working by manually enabling the locking facility in the KDE System Settings -> “Display and Monitor” -> “Screen Saver” -> “Require password after …”. Test whether the lock is effective by letting the screensaver kick in. When dismissing the screensaver you should be prompted for a password. Now, connect to your WLAN. Retry the screensaver test cycle, which should no longer require the entry of a password. Last, disconnect from your WLAN again to observe the lock coming back.

That’s it. Have fun with your new location-aware screen lock configuration. Of course, further uses of the mechanism can be thought of, such as automatic file synchronization. More to follow in a future blog post.

Bildquelle: http://commons.wikimedia.org/wiki/File:Mrs._Herbert_Stevens_May_2008.jpg