XOrg vs. Eclipse

Als ich am Montag nach einem System-Update (Debian sid) mein Eclipse starten wollte, erschien statt der erwarteten IDE ein Fensterchen mit der Meldung, es hätte einen Fehler in der JVM gegeben. Eclipse konnte nicht gestartet werden, dementsprechend konnte ich meine Arbeit auch nicht fortsetzen.

Da man den Fehler ja zuerst bei sich selbst sucht, habe ich erst einmal das Update des Java Development Kit rückgängig gemacht und die Version 1.5 installiert. Der Fehler blieb leider.

Ein Blick auf die Console hat folgendes ergeben:
The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 1272 error_code 11 request_code 148 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Eine Suche nach den entsprechenden Schlagworten hat mich schnell in die überall präsenten Ubuntu-Foren geführt, wo sich herausstellte, dass der Schuldige das Paket xserver-xorg-core ist, das mit Einführung eines Sicherheitsupdates das Ausführen von SWT-Applikationen mit eben dieser Meldung quittiert.

Die spontane Lösung dafür ist, das Update rückgängig zu machen und eine ältere Version zu installieren. Die habe ich auf den Paketservern leider nicht mehr gefunden, da dort nur die jeweils aktuellen Versionen vorliegen. Fündig geworden bin ich dann im Paket-Cache auf meinem eigenen Rechner, wo ich zum Glück noch eine ältere Version dieses Paketes hatte; manchmal ist es doch praktisch, nicht immer sofort alle Caches zu leeren. :)

Sollte jemand mit dem gleichen Problem hier vorbeikommen, kann er das mit folgenden Befehlen beheben:

wget http://www.tuxathome.de/deb/xserver-xorg-core_2%253a1.4.1%7Egit20080105-2_i386.deb
dpkg -i xserver-xorg-core_2%3a1.4.1~git20080105-2_i386.deb

Das installiert die Version, die vor dem Update ausgeliefert wurde. Es empfiehlt sich, die Version vom 18.01. als Forbidden zu markieren, damit sie beim nächsten Upgrade nicht gleich wieder installiert wird.

Achtung: Ich übernehme keinerlei gewährt für die Korrektheit und Verfügbarkeit des Paketes auf meinem Server oder den ordnungsgemäßen Ablauf des Downgrades!

Ich werde noch einen Bugrepot anfertigen (den habe ich jedenfalls nicht gefunden) und bin gespannt, wie lange es dauert, bis das Problem behoben ist. Mein Eclipse läuft jedenfalls erstmal wieder.

Treiberdiskette vom Hersteller

Ein Freund hatte in letzter Zeit massive Problem mit seinem (stein)alten Rechner und hat sich heute neue Hardware besorgt und zur Installation hier vorbeigetragen. Dabei sind ein aktuelles Mainboard mit Sockel AM2 und Unterstützung für SATA II mit NCQ und AHCI sowie eine aktuelle Festplatte, die das auch kann. Bekanntlich mangelt es da seitens Windows XP an Unterstützung bei der Installation und man muss F6 drücken und den passenden Treiber nachladen. Der Hersteller war so freundlich eine CD beizulegen und im Handbuch gut zu beschreiben, wie man die passende Diskette erstellt. Ich hab dann auch brav F6 gedrückt und der Windows-Installer fordert mich auf:

Legen Sie die Diskette beschriftet mit

Treiberdiskette vom Hersteller

in Laufwerk A: ein.

* Drücken Sie anschließend die EINGABETASTE.

»Treiberdiskette vom Hersteller«? Also erstens hab ich die gerade selbst erstellt und werde die dafür, dass ich die einmal brauche, sicher nicht beschriften und schon gar nicht so. Zweitens: angenommen, der Hersteller hätte tatsächlich eine Diskette beigelegt, würde er dann »Treiberdiskette vom Hersteller« drauf schreiben? Und was, wenn das jeder Hersteller machen würde und man dann ein paar solcher Disketten zu Haus liegen hätte?

lol2

Nicht das gesamte System verschlüsseln

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:

modprobe aes
modprobe dm-crypt
modprobe dm-mod
aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3
cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…

mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind

aes
dm-crypt
dm-mod
sha256

Danach nochmal die initrd neu bauen lassen mit

update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:

data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…

Alte Grenzen neu entdeckt

ASUS TUSL2-C – lange habe ich von dem Board geträumt, irgendwann hab ich es mir geleistet und es sehr lange und zu meiner vollsten Zufriedenheit mit einem Celeron 1400 mit Tualatin-Kern betrieben. Jetzt hat es bei mir seine Schuldigkeit getan und es wird Weihnachten die Rechenpower bei meinen Eltern verdreifachen. (Dort werkelt immernoch ein Pentium-III 500 MHz mit Katmai-Kern.) Da sich im Laufe der Zeit einige Riegel SD-RAM angesammelt haben, dachte ich, ich gönne dem Board so 768 MB oder sogar ein Gigabyte, damit die Herrschaften auch vernünftig arbeiten können. Meine Tests mit Memtest86+ waren aber frustrierend. Egal welche Kombination von Riegeln ich ausprobierte, keiner wollte mit dem 512er Kingston (Infineon-Chips) zusammen laufen. Die Aura des TUSL2-C war angekratzt, aber ich hatte mich schon mit den 512 abgefunden.

Gestern dann habe ich noch eine Erweiterungskarte für Firewire 1394a und USB 2.0 bekommen, die die Anbindung schneller externer Speichermedien ermöglichen soll und dazu noch eine schicke Frontblende mit den entsprechenden Schnittstellen, beides von Reichelt, seit Jahren mein Lieblingsversandhaus. Die Beschreibungen der beiden Teile sind ausführlich genug, dass man sie mit ein bisschen Bastelei zur Zusammenarbeit überreden können wird. Außerdem sind in der Frontblende noch Anschlüsse für Kopfhörer und Mikro. Diese müssten mit dem Onboard-Sound verdrahtet werden. Zu diesem Zweck schaute ich nochmal ins Handbuch und konnte nicht widerstehen, auch nochmal das RAM-Problem zu verfolgen. Das Ergebnis:

PC100/PC133 Memory Support: Equipped with three Dual Inline Memory Module (DIMM) sockets to support PC100/PC133-compliant SDRAMs (available in 64, 128, 256, 512MB densities) up to 512MB.

Man beachte den letzten Teil! Verwundertes Augenreiben hilft nicht. Dieses Board mit Chipsatz Intel 815ep limitiert den maximal möglichen RAM auf ein lumpiges halbes Gigabyte. Das erklärt natürlich, warum Memtest regelmäßig Fehler meldete, wenn ich mehr als 512MB installiert hatte – enttäuschend ist das trotzdem, zumal ältere Boards da schon weiter waren. In meinem Heimserver werkelt seit Jahren ein ASUS CUBX-L mit dem sagenumwobenen Intel BX440 und was soll ich sagen? Lassen wir das Handbuch sprechen:

PC100 Memory Support: Equipped with four DIMM sockets to support Intel PC100-compliant SDRAMs (8, 16, 32, 64, 128, or 256MB) up to 1GB. These new SDRAMs are necessary to meet the critical enhanced 100MHz bus speed requirement.

Fazit: Trotz aller Erfahrung: bei alter Hardware doch mal ins Handbuch schauen – wer lesen kann…

Was bringt mir das? Vorteile der Offenlegung von Software

Anfang 2007 habe ich bei Google ein Video eines sogenannten TechTalks gesehen: How Open Source Projects Survive Poisonous People (And You Can Too). Ben Collins-Sussman und Brian Fitzpatrick, beide aktiv an der Entwicklung von Subversion beteiligt, haben einen Vortrag gehalten über die Communitys, die hinter Open Source Projekten stehen und wie man dort am besten mit Leuten umgeht, die die Atmosphäre unter den Entwicklern vergiften. Das Video ist 55 Minuten lang und ich habe es das Jahr über an der einen oder anderen Stelle empfohlen, unter anderem auch beim Eisfair-Entwicklertreffen, von dem ich vor zwei Wochen berichtete.

Heute nun bin ich über die verschlungenen Pfade der Blogosphäre auf das Blog von Ben Collins-Sussman gestoßen. Dort finden sich allerlei interessante Beiträge unter anderem auch der Hinweis auf einen weiteren TechTalk aus dem Oktober 2007. Das Video ist fast 50 Minuten lang, aber nicht minder empfehlenswert, wenn auch nicht ganz so amüsant.

Letzte Woche habe ich mich im Büro mit einem Kollegen über genau das Thema unterhalten. Inwiefern können Unternehmen von der Freigabe ihres Quellcodes profitieren? Der Grund dafür, dass es eine längere Unterhaltung war, findet sich auch in dem oben zitierten Video: es gibt keine einfache Antwort. Im Vortrag erläutern Ben und Brian, was sie für den besten Weg halten, den Unternehmen gehen sollten, wenn sie tatsächlich ein Open Source Projekt in die Wege leiten wollen (egal ob auf Basis von vorhandem Code oder von Grund auf). Auf die konkrete Frage, wie sich das mit kommerziellen Interessen verträgt, haben sie auch keine Antwort, die sich in einem Satz zusammenfassen ließe. Viele Vorteile lassen sich nicht direkt in Verkaufszahlen messen, sondern sind nur sehr langfristig sichtbar und betreffen eher den Ruf einer Firma oder die Veränderung eines Software-Marktes. Die Software selbst wird auch besser, aber konkret höhere Profitaussichten durch das offengelegte Projekt, sind wohl kaum der Grund.

Ganz nebenbei wird nochmal der Kernpunkt für eine erfolgreiche Open Source Software erwähnt: eine gesunde Community. In diesem Punkt muss ich den Herren auch aus persönlicher Erfahrung voll und ganz recht geben. Man braucht ein Kernteam von einer Hand voll engagierten und fähigen Entwicklern, die sich gegenseitig respektieren, freundlich und gelassen untereinander sowie zu allen sind, die Fragen zum Projekt haben oder etwas beitragen wollen. Ein Entwickler reicht nicht und Teamwork ist unbedingt notwendig, sonst wird nichts aus dem Projekt.

Das soll als kurze Zusammenfassung zu den beiden Videos erstmal reichen. Ich sehe noch Raum für einen längeren Beitrag über die persönliche Motivation selbst etwas zu Open Source Software beizutragen oder über die Vorteile von Open Source Software im Allgemeinen. Zu den Möglichkeiten für Unternehmen sollte sich jedoch jemand äußern, der besser weiß, womit Firmen wie Trolltech oder MySQL AB ihr Geld verdienen.

WebUni Iconset für Psi

Ich plane, über kurz oder lang ICQ Lebewohl zu sagen und auf Jabber umzusteigen. Gründe dafür gibt’s genug und wer will, kann da sehr viel im Netz finden. Jabber-Clients gibt’s mittlerweile einige und auch die verbreiteten und beliebten Multi-Protokoll-Clients Miranda und Trillian können damit umgehen. Ich persönlich bin ein Fan von Psi. Der unterstützt das Protokoll und viele Erweiterungen, GnuPG-Verschlüsselung ist eingebaut und er sieht sowohl unter Windows als auch unter Linux schick aus – schlicht, aber schick.

Aus Neugier habe ich letztens geschaut, wie die Iconsets dort eingebunden sind. In einem Ordner liegt jedes Icon in Form einer PNG-Datei und dann gibt es eine Datei icondef.xml, die selbsterklärend ist, ein tolles Beispiel für die sinnvolle Anwendung von XML.

Naja genau genommen habe ich nicht nur aus reiner Neugier geschaut. In meinem Freundeskreis gibt es einige Leute, die bei der Online-Community WebUni aktiv sind. Mit der Zeit verinnerlicht man die Abkürzungen für die dort gebräuchlichen Smilies und dann benutzt man die irgendwann auch außerhalb von WebUni – beispielsweise im Instant Messenger. Was liegt näher, als dort auch die gleichen Icons anzeigen zu lassen. Da es, wie oben beschrieben, recht einfach ist, für Psi ein Iconset zu bauen, habe ich mich mal kurz hingesetzt und das gemacht.

Das größte Problem bestand darin, dass Psi keine animierten GIF-Icons anzeigt und ich aus den animierten noch je ein charakteristisches Einzelbild extrahieren musste. Der Rest ging sehr flott von der Hand und daher gibt es jetzt als Weltpremiere und exklusiv bei antiblau: das Psi Iconset »WebUni«. Einfach an geeigneter Stelle entpacken, in Psi auswählen und freuen. Als kleiner Vorgeschmack dann hier noch ein Screenshot:

Screenshot Psi Iconset »WebUni«

SMTP-DSN: Warum einfach …

… wenn es auch kompliziert geht.

Hintergrund ist folgender: Ich habe für eine Plattform ein Mailinglisten-System implementiert. Das war notwendig, weil es dort sehr spezielle Regeln zur Generierung der Empfänger gibt, die jedes Mal dynamisch angewendet werden müssen. Bestandteil dieses System ist natürlich auch die Erzeugung von Bounces, um Fehler und Ausnahmezustände mitzuteilen.

Dabei ist mir etwas aufgefallen: Es gibt drei nette RFCs, die sich mit dem Format dieser Delivery Status Notifications (DSN oder kurz Bounce) beschäftigen:

Diese Konventionen regeln, wie eine Bounce-Message aufgebaut ist, wie die Informationen abgelegt werden, welche Fehlercodes es gibt und so fort.

Und nun kommt unser kompliziertes Leben: Kein Mail User Agent, den ich kenne, wertet die Bounces anhand dieser RFCs aus! Statt dessen bekommt der – mittlerweile oft laienhafte – E-Mail-Nutzer eine kryptische Fehlermeldung zu sehen, die häufig so interpretiert wird, dass die Adresse nicht existiert. Das ist ein beliebter Grund für Bounces, aber oft auch falsch.

Liebe MUA-Programmierer: Warum gibt es keine Ansicht fuer Bounces, in der die Informationen aufgeschlüsselt sind und auch den Nutzern, die E-Mails nicht per telnet lesen können, verständlich gemacht werden? Das würde einen weißen (nein, eigentlich schwarzen) Fleck auf der Landkarte der E-Mail-Kommunikation beseitigen.

Binary H(e)art

binary heart Heute schrieb die ettercat einen Link auf nebenstehenden Comic von xkcd.com ins IRC. Die Seite hat mich schon des öfteren mit wirklich lustigen Comics begeistert, zumal einige nur mit entsprechendem Geek-Hintergrundwissen wirklich lustig sind. Nummer 99 – »binary heart« – trifft vom Untertitel der Seite (»A webcomic of romance,
sarcasm, math, and language.«) klar den romantischen Teil. Aber ganz ehrlich, seid Ihr nicht auch total neugierig, ob sich hinter den Nullen und Einsen im Bild nicht noch eine zusätzliche Botschaft verbirgt? Ich war es jedenfalls und da nur selbst dekodieren schlau macht, hab ich frei nach dem Perl-Motto »Es gibt mehr als einen Weg, etwas zu tun« die Zeichen einzeln abgetippt und ein kleines Skript geschrieben.

Hart (siehe Titel ;-)) war da dran einerseits das Abtippen vom Comic – man verrutscht schon sehr leicht in Zeile und Spalte – und andererseits um Mitternacht die eingerosteten Perl-Kenntnisse zu reaktivieren. Wer sich gern selbst an einem Progrämmchen in beliebiger Sprache probieren will, kann sich die binär codierte Nachricht runterladen, die Textdatei, wo ich mal die Einsen und Nullen abgetippt habe.

Ach und für die ganz Neugierigen oder zur Kontrolle des eigenen Programms hier noch die Auflösung:

iloveyOuilOveyouiloveyOuilOveyOuiloveyouilOveyouilOveyOuilOv

ext3-Dateisystem verkleinern mit Knoppix

Hatte ich schon erwähnt, dass ich im September umgezogen bin? Bin ich, nur in anderes Viertel, aber mit jemandem zusammen in eine neue WG, der wie ich ebenfalls einen kleinen Server zu Haus stehen hatte. Da die Hardware heutzutage leistungsfähig genug ist und Xen zuverlässig läuft, sind wir dabei Schritt für Schritt die Dienste von den beiden ehemaligen Servern auf eine Maschine mit ein paar virtuellen Xen-Hosts zu packen. Da ich ungern an Produktivsystemen neue Dinge ausprobiere, teste ich solche Sachen auf einem anderen Rechner. Gestern hatte ich dank dieser Anleitung auf besagtem Testrechner unter Debian Etch in kurzer Zeit einen laufenden Xen-Wirt eingerichtet. Die 40GB-Platte war dort ungefähr zu gleichen Teilen in /home und / geteilt – klassische Partitionen. Da ich Xen gern mit LVM testen wollte und die Partitionen kaum belegt waren, entschied ich mich für eine Neuaufteilung: 8 GB für das root-Filesystem und der Rest für LVM. Auf dem Testsystem sind außer Testinstallationen keine wichtigen Daten, also die erste Gelegenheit für mich, mal resize2fs auszuprobieren…

Beim Verkleinern einer Partition soll man erst mit resize2fs das Dateisystem (ich benutze eigentlich immer ext3) verkleinern und dann mit fdisk die Partition selbst noch verkleinern. Das Manual sagt, dass die Partition natürlich nicht kleiner gemacht werden soll als das Dateisystem – logisch. Zunächst jedoch will resize2fs nochmal e2fsck aufgerufen haben:

e2fsck -f /dev/hdb3
resize2fs -p /dev/hdb3 8G

Dann habe ich fdisk /dev/hdb aufgerufen, hdb3 gelöscht und neu angelegt. Der vorgeschlagene Beginn der Partition war der gleiche wie zuvor, habe ich extra kontrolliert und dann die Partition mit +8300M neu angelegt. Reboot und siehe da: reicht wohl nicht, es kommt die Beschwerde, dass das Dateisystem 2 097 152 Blöcke hat, die Partition aber nur 2 026 458. Also nochmal Knoppix booten und Partition neu anlegen. Interessant ist dann zunächst die Ausgabe von fdisk -l

Platte /dev/hdb: 40.0 GByte, 40020664320 Byte
16 Köpfe, 63 Sektoren/Spuren, 77545 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes

    Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/hdb1   *           1         203      102280+  83  Linux
/dev/hdb2             204        2284     1048824   82  Linux Swap / Solaris
/dev/hdb3            2285       18367     8105832   83  Linux
/dev/hdb4           43895       77545    16960104    5  Erweiterte
/dev/hdb5           43895       77545    16960072+  83  Linux

fdisk zeigt hier auch Blöcke an, aber die Anzahl ist verschieden zu der, die zuvor e2fsck beim Boot des Systems zeigte – genau genommen exakt viermal so groß. Aber irgendwie stimmt das auch ungefähr mit den 8300 Megabyte von vorhin überein, in Kilobyte versteht sich. Ich habe dann also diesmal beim Neuanlegen der Partition +8388608K angegeben, das vierfache von dem Wert, den das System vorher beim Booten für die Größe des Dateisystem genannt hatte. Der kam wie gesagt ursprünglich von den 8G beim resize2fs. fdisk machte dann ein paar Blöcke mehr draus, als ich Kilobyte eingegeben hatte, umso besser. Da der Kernel noch nichts von der Änderung der Partitionstabelle durch fdisk wusste, lohnte ein e2fsck unter Knoppix nicht und ich hab gleich neu gestartet.

Das Debian etch beschwerte sich dann nicht mehr über ein Filesystem, das größer war als die Partition, ließ aber dennoch einen Check drüber laufen. Der weitere Systemstart verlief problemlos. Das LVM richte ich dann später ein…

happy

Interessant finde ich jedoch noch die Frage, was ich hätte eingeben müssen, um von vornherein die passenden Größen für resize2fs und fdisk parat zu haben, einfach auch 8G bei fdisk wäre nämlich deutlich zu wenig gewesen. Ziel: möglichst wenig Platz auf der Partition verschenken. Wer da Ideen hat, den bitte ich um Kommentare!

Die Auferstehung des Zaurus: Anforderungen

Nach dem ersten Beitrag zu diesem Thema geht es nun um die Anforderungen, die ich an ein mobiles PIM-Gerät stelle. Natürlich beziehe ich mich an dieser Stelle wieder speziell auf meinen Zaurus, jedoch denke ich, dass auch für andere Geräte interessante Anregungen dabei sind.

Ich gehe dabei von drei Aspekten aus:

  • Benutzerfreundlichkeit (im Neusprech auch als Usability bekannt)
  • Sicherheit
  • Aktualität der Daten

Benutzerfreundlichkeit bedeutet dabei, dass sich die Software unterwegs gut bedienen lassen muss, also auf eine vorhersehbare Interaktion und gegebenenfalls auch eine stiftlose Bedienung zugeschnitten ist.

Wer gerade in der Stadt unterwegs ist, möchte nicht ständig den Blick auf dem Display haben, weil die Bedienschritte selbst bei Routineaufgaben ständig unerwartete Wendungen nehmen (einige Mobiltelefone sind mit dieser Interface-Krankheit geradezu verseucht) und auch nicht jedes Mal den Stift herausholen, um nachzuschauen, was am Tag noch ansteht oder einen Punkt auf der TODO-Liste abzuhaken. Das besonders kleine Display und eine mögliche Bedienung des Touch-Screens mit dem Finger müssen bedacht werden.

Genauso wichtig ist aber, dass die Anwendungen selbst auf ihren speziellen Verwendungszweck zugeschnitten sind. Eine Kalenderanwendung wird verwendet, um nachzuschauen, welcher Termin als nächstes ansteht oder um einen Termin zu vereinbaren. Dabei sehe ich immer wieder Anwendungen, die den Prozess der Terminvereinbarung eher behindern als unterstützen: Nicht nur, dass es keine Unterstützung zum Finden freier Termine gibt, häufig wird z.B. auch verlangt, dass erst einmal Betreff und Ort eingegeben werden, bevor es möglich ist, eine Zeit festzulegen. Hier wird missachtet, dass bei der Terminvereinbarung die Zeit im Mittelpunkt steht – die übrigen Metadaten lassen sich selbständig und im Nachhinein ergänzen. Gleiches passierte mir schon regelmäßig beim Anlegen von Kontakteinträgen: Es gibt nicht wenige Mobiltelefone, die zuerst die Eingabe des Namens verlangen, bevor eine Telefonnummer eingegeben werden kann. Wenn ich jedoch das Telefon heraushole, um eine Nummer zu speichern, ist es eben die Nummer, die mir zuerst und vor allen Dingen von meinem Gegenüber diktiert wird. Und diese Nummer möchte ich zuerst speichern können. Das sind Kleinigkeiten, die sich jeoch ganz massiv auf die Zweckmäßigkeit des Gerätes auswirken.

Wichtig für mich ist vor allem eine schnelle Übersicht der Dinge, an die ich zu dem Zeitpunkt denken sollte, zu dem ich auf meinen PDA schaue.

Sicherheit wird dann wichtig, wenn unbefugte Personen Zugriff auf meinen PDA erhalten. Sei es in einem unbeaufsichtigten Moment oder bei Verlust des Gerätes. Schlimmer als die Notwendigkeit, Hardwareersatz und die verlorenen Daten zu beschaffen ist nämlich der Umstand, dass diese Daten in fremden und sehr wahrscheinlich den falschen Händen sind.

Ebenfalls nicht zu verachten ist die Möglichkeit, dass man abends, nachts oder zu einer beliebigen anderen Zeit auf der Straße angehalten und zur Herausgabe seines Gerätes gezwungen wird. Mir ist das zum Glück noch nie passiert, aber bei der Entscheidung Hardware oder Gesundheit gewinnt eindeutig letztere. Wenn es dann möglich ist, die Daten zu entfernen oder wenigstens unzugänglich zu machen, verliert diese Situation an Schrecken.

Wie erreicht man das? Die Lösung setzt sich für mobile Datenträger und auch auf einigen Desktops mittlerweile schon durch: Sämtliche persönlichen oder sensiblen Daten sollten ausschließlich verschlüsselt abgelegt werden. Beim Einschalten des Gerätes muss eine PIN eingegeben werden (unter Berücksichtigung der Benutzerfreundlichkeit), die den Crypto-Container freischaltet. Wer versucht, unbefugt an die Daten zu gelangen, wird nichts vorfinden, was von Nutzen ist. Da der Zaurus über einen SD-Port verfügt, bietet sich an, diesen Container auf einer SD-Karte abzulegen. So sind auch Datensicherungen sehr schnell gemacht, weil nur ein Image der SD-Karte gezogen werden muss. Einen halbwegs intelligenten Räuber kann man vielleicht sogar noch dazu überreden, auf die SD-Karte zu verzichten. So bleiben aktuelle Daten erhalten.

Grundsatz sollte auf jeden Fall sein, keine sensiblen Daten offen und unverschlüsselt zu lassen. Mit einer vernünftigen Verschlüsselung hat der PDA einen gewaltigen Vorteil gegenüber jedem low-tech-Papierplaner.

Aktualität der Daten muss durch entsprechende Synchronisationsverfahren gewährleistet werden. Nur wenn die Daten überall auf dem neusten Stand sind, kann man sich auch auf sie verlassen und auf deren Basis Entscheidungen treffen.

Der Zaurus, wie ich ihn beschrieben habe, hat zwei Schnittstellen: Den USB-Port und eine CF-WLAN-Karte.

Der USB-Port ist in ein Cradle integriert, das auch zum Aufladen des Gerätes verwendet werden kann. Beim Einstellen des Gerätes sollte also ein Abgleich sämtlicher Daten erfolgen. Wenn möglich, vollautomatisch. Auftretende Konflikte sollten an einem beliebigen Gerät gelöst oder später bearbeitet werden können. (Warum schließlich soll ich mich mit dem Mini-Display des PDA abmühen, wenn direkt daneben ein ausgewachsener Desktop-PC steht?)

Die Synchronisation mittels WLAN sollte ähnlich laufen, kann jedoch auch von unterwegs erfolgen. Zu beachten ist hier, dass es auch zu einem Abbruch der Verbindung kommen kann, also eine entsprechende Transaktionsverwaltung nötig ist.

Ziel der synchronen Datenhaltung ist, jede Information auch nur einmal eingeben zu müssen und sie trotzdem an jedem meiner PIM-Geräte zur Verfügung zu haben.

Fazit: Wer sich sein eigenes Handy oder einen handelsüblichen PDA betrachtet, wird schnell feststellen, dass keines der Geräte alle diese Aspekte erfüllt. Spätestens bei der Verschlüsselung wird auf aktive Sicherheit gesetzt und nicht beachtet, dass insbesondere Speichererweiterungen auch am System vorbei ausgelesen werden können. Benutzerinterfaces sind häufig nur verkleinerte Varianten eines Desktops und für kleine Touch-Screens oder die Bedienung mit nur wenigen Tasten ungeeignet. Auch die Synchronisation klappt in den wenigsten Umgebungen reibungslos. Es gibt viel Nachholbedarf, bis ein PDA wirklich effektiver ist, als ein Papierplaner und man mit solch einem Gerät Zeit spart.