Author Archives: mrtux

Cloud Messaging

Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

  1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
  2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
  3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.

Terminprioritäten

Ich habe seit längerem schon das Problem, dass ein Kalender mit festen Terminen und freien Zeiten nicht alle Informationen abbilden kann, die ich dokumentieren möchte: Problematisch sind Informationen, die zwar einen Zeitbezug haben, sich von daher also gut mit einem Kalender visualisieren lassen, jedoch keine Termine sind und damit nach den GTD-Regeln streng genommen nicht in einen (beziehungsweise den) Kalender gehören. Daneben gibt es Termine, die zwar im Prinzip feststehen, sich aber gegebenenfalls verschieben lassen. Dazu gehört zum Beispiel die tägliche Mittagspause.

Ausgehend davon ist mir eben folgende Priorisierung eingefallen, die ich hier einfach mal festhalten möchte:

  • 0 – free:Zu dieser Zeit liegt kein Termin vor.
  • 1 – informal: für Ereignisse, die im Kalender visualisiert werden, aber keine Termine sind (Feiertage, Geburtstage, eingeplante Arbeitszeiten, …)
  • 2 – tentative: Der Termin ist vorgesehen, kann aber gestrichen oder verschoben werden. (z.B. die tägliche Mittagspause) Aus Sicht der Terminplanung ist diese Zeit frei.
  • 3 – normal: Das ist ein ganz normaler Termin nach der GTD-Methode. Die Zeit ist eingeplant und belegt, Verschiebungen sollten vermieden werden.
  • 4 – important: Der Termin ist wichtig, eine Verschiebung ist nur mit viel Aufwand möglich und sollte vermieden werden.
  • 5 – ultimate: Der Termin steht definitiv fest und kann auf keinen Fall verschoben oder umgangen werden. (Sowas wie Prüfungen, der Weltuntergang oder der Besuch des Bundespräsidenten zwecks Übergabe der Weltherrschaft)

Dabei werden niedrige Prioritäten von höheren verdrängt.

Sechs Stufen sind eine ziemlich feine Auflösung, damit sollte sich dann aber wirklich alles abbilden lassen. Am gebräuchlichsten werden wohl die Prioritäten 0 (free) und 3 (normal) sein.

Der ist erstmal nur ein Konzept ohne Implementierung, aber ich werde diese Stufen testen und sehen, ob sie praktikabel sind.

Organisiertes Vertrauen

Eine Idee, die ich heute Nachmittag schon hatte, nachdem Keysigning, GeoCaching und verwandte Dinge gerade mehr oder weniger unsere Gesprächsthemen sind:

Es wäre doch nett, ein Portal zu haben, mit dessen Hilfe man Keysigning-Parties (KSPs) jeglicher Größenordnung organisieren könnte.

Ich stelle mir das so vor:

Man meldet sich dort an und bekommt dann die Möglichkeit, neben seinen aktuellen Schlüsseln auch seinen Aufenthaltsort anzugeben. Damit ist es schonmal leicht, herauszufinden, wer in der Umgebung noch einen PGP-Schlüssel besitzt.

Wer eine KSP organisieren möchte, legt ein entsprechendes Event mit Termin und Austragungsort an. Anschließend können andere Nutzer sich dafür anmelden, wobei sie gegebenenfalls sogar automatisch auf die KSP in ihrer Nähe hingewiesen wurden.

Eine dritte Funktion könnte eine Art Marktplatz sein, auf dem man sich zum Key-Signing verabreden könnte. Wer kein Problem damit hat, mal einen Schlüssel zu verifizieren, gibt das entsprechend bekannt (z.B. durch ein Häkchen im Profil und eine Angabe von Orten, an denen man ihn leicht treffen kann) und wenn man Leute sucht, die einen neuen Key verifizieren, kann man dort einfach auflisten lassen, wer denn in Frage kommt oder eine entsprechende Anfrage stellen und hoffen, dass sich jemand anbietet (auf diese Art lässt sich vermeiden, dass sinnlos Daten ausgespäht werden).

Nebenbei gibt es natürlich Informationen und Tools für KSPs, zum Beispiel eine Möglichkeit, sich ein nett designtes Formular mit allen Fingerprints der KSP-Teilnehmer herunterzuladen oder eine Liste mit Schlüsselschnipseln zum Ausschneiden und Weiterverteilen.

Wenn viel Serverlast ürbrig ist, kann man sogar Vertrauensnetzwerke berechnen und visualisieren. Der Kreativität sind da keine Grenzen gesetzt.

Falls es eine solche Plattform schon gibt oder jemand Lust hat, das umzusetzen: Lasst es mich wissen! Ich habe im Moment leider keine Zeit dazu.

Kleine Wikipedia-Statistik

Für meine Diplomarbeit habe ich ein Informationsnetzwerk gesucht, das einerseits sehr groß und nicht komplett formalisiert, andererseits aber auch nicht sinnlos ist. Wikipedia bot sich an.

Unter der URL http://dumps.wikimedia.org/ kann man regelmäßig erstellte Datenbankdumps der Wikipedia herunterladen. Ich habe mich für den englischen Teil entschieden und auf die aktuellen Artikelversionen “beschränkt”. Der Dump ist 3,9 GB gross, nach dem Entpacken erhält man eine XML-Datei von ca. 17 GB (Gigabytes!)

Hier fangen die ersten Schwierigkeiten schon an. Solchen Dateien kann man weder mit herkömmlichen Editoren zuleibe rücken, noch mit einem DOM-Parser – beide versuchen zunächst, die Datei komplett in den Hauptspeicher zu laden. So weit sind wir mit der Hardware aber noch nicht.

Die Sprache meiner Wahl ist Java, da ich auch in Java weiterarbeiten werde. Zum Glück gibt es hier noch die SAX-Parser, die eine XML-Datei streamen und die Daten über Callback-Funktionen weitergeben. Damit baut man dann einen klassischen Automaten, der die XML-Daten extrahiert und in Objekte verpackt. Auch hier sollte man nicht auf die Idee kommen, in irgendeiner Form Objekte anzusammeln – der Hauptspeicher reicht dafür nämlich ebenfalls nicht aus.

Was ist zunächst getan habe, ist, die Anzahl der Seiten und Redirects (Artikel, die auf andere Seiten verweisen) zu zählen. Das stellte sich letztendlich doch komplizierter heraus, als ich dachte. Der Dump enthält auch sämtliche Verweise auf Bilder, Templates und andere Namespaces (mit Ausnahme von User und Discussion), die erst einmal herausgefiltert werden müssen.

Anschließend gibt es in den Erklärungen dazu, was eine Wikipedia-Seite ist, noch folgenden Text: any page that is in the article namespace, is not a redirect page and contains at least one wiki link. Der letzte Teil ist wichtig: Zusätzlich zu den Namespaces muss auch noch nach Links gefiltert werden, sonst landen jede Menge Stub-Seiten mit Verweisen zu anderen Wikis in der Statistik. Auf diesen Fakt wurde ich im Mediawiki-Channel (freenode:#mediawiki) hingewiesen.

Nach insgesamt 5 Experimenten gibt es nun also plausible Ergebnisse:

[main] INFO WikipediaImporter - Wikipedia Importer started.
[main] INFO WikipediaImporter - Time taken: 0h 11m 34s.
[main] INFO WikipediaImporter - Articles: 2863041
[main] INFO WikipediaImporter - Redirects: 2548806
[main] INFO WikipediaImporter - Wikipedia Importer finished.

Insgesamt befinden sich im Dump also 2.863.041 Artikel – nach meiner Zählung.

Als nächstes werden die Verlinkungen bereinigt (Redirects aufgelöst) und daraus ein Graph hergestellt, der dann ausschnittsweise visualisiert wird. Außerdem werde ich wohl eine Klassifikation anhand der Kategorien herstellen. Das Feld ist offen für Experimente und ich nehme gern Ideen entgegen. Aber: Bei 2.8 Millionen Knoten werden die klassischen Graphen-Algorithmen wohl gnadenlos versagen.

Notebookreparatur, 2

Über den ersten Teil meiner Notebookreparatur habe ich vor einiger Zeit schon geschrieben. Gestern und heute ging es dann weiter mit Teil zwei.

Nachdem ich mir geeignetes Werkzeug besorgt hatte, um die Seriell- und Parallelport-Anschlüsse auf der Rückseite des Notebooks abzuschrauben, habe ich es gestern Abend noch einmal auseinandergenommen. Diesmal ist es mir auch gelungen, das Mainboard mit der schadhaften Netzteilbuchse zu auszubauen.

Die korrekte Fehlerdiagnose: Da die Buchse nur an ihren Lötfahnen befestigt ist, wurde durch die dauerhafte Belastung eine dieser Fahnen abgerissen. Das erklärt, wieso das Verkanten des Steckers für eine Weile geholfen hat, bevor dann gar nichts mehr zu holen war.

Ich habe die Buchse ausgelötet, was überraschend reicht ging, und bin damit heute zum Elektronikladen gelaufen. Der Verkäufer kannte zwar mich nicht (wie auch …), aber sowohl Buchse als auch Problem. Und er wusste, dass es diese Buchse so nicht gibt und ich mir aus Drähten, einer anderen Buchse (die es gibt …) und Schrumpfschlauch etwas selbst basteln muss.

Jetzt habe ich also zwei Optionen:

  1. Entweder etwas basteln, das mit Draht, Buchse und Schrumpfschlauch wieder einen Anschluss ermöglicht – wobei ich noch das Problem der Zugentlastung lösen muss.
  2. Ein (kaputtes) Mainboard mit gleicher, intakter Buchse finden, das ist als Ersatzteillager missbrauchen kann.

Ich tendiere mittlerweile aber schon sehr zu Variante eins. Das ist nicht so schick, aber weitere Reparaturen dürften sich wesentlich einfacher gestalten.

Spontane Idee: Festplattenstecker und -buchse verwenden. (Also, die Teile, die im PC zur Stromversorgung genutzt werden.) Die Festplattenbuchse wird dann mit Kabeln aufs Mainboard gelötet, an den Festplattenstecker kommt die Buchse für die Notebook-Stromversorgung. Der Festplattenstecker passt dann noch ins Notebook und dient gleichzeitig als Zugentlastung. Falls dort mal etwas reisst, lässt sich das leichter reparieren, als wenn ich wieder am Notebook löten müsste.

Songbird: Music Player für Windows

Meine Suche nach einem Amarok-Äquivalent für Windows hat ein Ende gefunden!

Ich bin heute zufällig über einen Mozilla-basierten Music-Player für Windows gestolpert: Songbird.

Die Playlist sieht ähnlich aus wie beim Amarok (oder iTunes, das sich auf meinem Rechner aber nicht gut benimmt), ich bekomme die für mich interessanten Meta-Informationen angezeigt und es gibt – wie man es von Mozilla gewohnt ist – eine Menge addons. Zum Beispiel, um bei last.fm zu scrobbeln.

Einziges Manko: Das Programm lässt sich nicht in die Traybar minimieren – aber da finde ich sicherlich auch noch etwas.

Kommentare in der .htpasswd

Ich bin gerade ein wenig unsicher, ob ich mal wieder Google-blind bin oder ob es wirklich nicht vorhanden ist – jedenfalls war ich nicht in der Lage, eine vernünftige Dokumentation des Dateiformats für die Passwortdateien des Apache zu finden.

Die meisten Einträge befassen sich damit, wie man das htpasswd-Tool benutzt, mit dem sich solche Dateien über die Kommandozeile bearbeiten lassen. Ich möchte aber wissen, ob und wie ich dort Kommentare einfügen kann.

Letztendlich habe ich einfach mal probiert und war damit erfolgreich, vor die betroffene Zeile eine Raute zu setzen (#), also so zu kommentieren, wie in shell-Scripten.

Aber eine fundierte Lösung wäre mir natürlich lieber. Falls jemand etwas hat: Ab in die Kommentare damit!

Spaß-Admins?

heise.de schreibt im Artikel “Per Browser auf den Mainframe”:

Es werde aber immer schwieriger, Nachwuchs für die Betreuung der Rechner und der Software zu finden, der mit den herkömmlichen Terminals arbeiten will.

Das bestätigt einen Eindruck, den ich selbst auch schon desöfteren hatte: Die neue Generation der Computernutzer scheint davon verwöhnt, dass Systeme entweder auf Anhieb funktionieren oder sich durch bunte Howtos und Rumklicken zu einer Form von Funktion bewegen lassen. Auf jeden Fall müssen sie schön bunt sein und Spaß machen.

Nach einem Hype von Ich-kenn-mich-mit-Computern-aus-Menschen scheinen sich wieder die herauszukristallisieren, die sich wirklich mit der Materie beschäftigen wollen – und sie dementsprechend auch beherrschen.

Gehen uns die Admins aus?

(Der Artikel ist einseitig, übertrieben und verallgemeinernd. Das muss so. Es darf diskutiert werden.)

CLI siegt

Spontane Erkenntnis: Ich nutze lieber den Kommandozeilenclient als die Shell-Extension im Kontextmenü – jedenfalls wenn es um Subversion geht. Gerade Routineaufgaben wir update und commit gehen damit einfach schneller.

Mögliche Erklärung: In der KDE kommt man aus dem Dateimanager per F4 in ein Konsolenfenster mit dem aktuellen Verzeichnis. Dort muss ich dann nur noch svn up eingeben, mit das Ergebnis anschauen und die Konsole mit Strg+D wieder schließen. Das geht wesentlich schneller, als mit der Maus im Kontextmenü die entsprechende Option zu suchen.

Die HCI-Community spricht hierbei von habit, also der Gewohnheit beziehungsweise Routine. Während man bei der Mausbedienung zuerst den Mauszeiger suchen muss, um ihn dann auf die richtige Position im Dateimanager und im Kontextmenü zu navigieren, ist die Position der Tasten fest, die Tastaturbedienung bedarf also wesentlich weniger Planung und fördert daher eher ein routiniertes Vorgehen. Letztendlich entlastet das das Gehirn und wird deshalb als energiesparende Maßnahme bevorzugt. Aber wer gern Shortcuts benutzt, kennt das ja … 8)

Nachtrag: Da war ich wohl etwas eilig und hab die Abkürzungen nicht erklärt…

CLI = Command Line Interface; eine Form von Kommandozeile, entweder auf der Konsole oder in ein Programm eingebettet.

HCI = Human-Computer-Interaction oder Human-Computer-Interface, also die Schnittstelle beziehungsweise Interaktion zwischen Mensch und Computer.

irssi-Hilight mit Jabber

Seit einigen Jahren läuft in meiner Screen-Session neben ICQ und anderen Tools auch ein irssi, um mich mit der Welt des IRC zu verbinden. In den meisten Channels bin ich einfach nur anwesend, gelegentlich spricht mich dann aber doch jemand an. Dank hilight im irssi wird man darüber ja eigentlich informiert. Nur leider schaue ich viel zu selten in das irssi-Fenster, um das dann letztendlich auch zu sehen. (Ja, screen informiert ueber Pings in anderen Fenstern, aber da guck ich doch erst Recht nicht hin …)

Da irssi eine schicke Perl-API hat, liegt es doch nahe, ein Perl-Script zu schreiben, mit dessen Hilfe ich mich anderweitig informieren lassen kann. Sehr nahe liegt da der Instant Messenger, der sowieso immer läuft, wenn ich am Rechner sitze – konkret Jabber.

Mit dem Perl-Modul Net::Jabber ist das alles kein Problem (abgesehen von den lückenhaften Dokumentationen, insbesondere in der irssi API) und so gibt es nun das Script irssi2jabber.pl, das als irssi-Script geladen werden kann und mir nun bei jedem Hilight oder jeder privaten Nachricht, die auftreten, während ich /away bin, eine Nachricht an meinen Jabber-Account schicken.

Das Script ist etwas kommentiert, die notwendigen Einstellungen stehen ganz am Anfang und müssen in die irssi-Config. Unter der GPLv3 darf es jeder weiterverwenden, natürlich nehme ich auch Patches an, die, wenn sie nützlich sind, eingepflegt werden.