assign a different color for each nick

Das Skript bildet per Default einen simplen Hashwert über den Nickname, wählt anhand dessen eine Farbe aus und behält diese dann bei. Bei gleichen Nicks ist das dann immer die gleiche Farbe, was ja auch ganz sinnvoll ist.

Das Skript kann darüber hinaus noch mehr, um das rauszufinden, muss man aber einen Blick in den Quelltext werfen, entscheidend ist folgende Subroutine:

sub cmd_color {
  my ($data, $server, $witem) = @_;
  my ($op, $nick, $color) = split " ", $data;
 
  $op = lc $op;
 
  if (!$op) {
    Irssi::print ("No operation given");
  } elsif ($op eq "save") {
    save_colors;
  } elsif ($op eq "set") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } elsif (!$color) {
      Irssi::print ("Color not given");
    } elsif ($color < 2 || $color > 14) {
      Irssi::print ("Color must be between 2 and 14 inclusive");
    } else {
      $saved_colors{$nick} = $color;
    }
  } elsif ($op eq "clear") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } else {
      delete ($saved_colors{$nick});
    }
  } elsif ($op eq "list") {
    Irssi::print ("\nSaved Colors:");
    foreach my $nick (keys %saved_colors) {
      Irssi::print (chr (3) . "$saved_colors{$nick}$nick" .
		    chr (3) . "1 ($saved_colors{$nick})");
    }
  } elsif ($op eq "preview") {
    Irssi::print ("\nAvailable colors:");
    foreach my $i (2..14) {
      Irssi::print (chr (3) . "$i" . "Color #$i");
    }
  }
}

Hier wird für irssi ein Befehl /color definiert, den man mit folgendem ersten Argumenten bzw. weiteren Befehlen aufrufen kann:

• save
• set
• clear
• list
• preview

Was kann man nun mit den einzelnen Befehlen anstellen? Ich gebe mal jeweils ein Beispiel mit der dazugehörigen Ausgabe, allerdings ohne Farben.

/color save gibt nichts weiter aus, speichert aber die mit set festgelegten Farben in der Datei ~/.irssi/saved_colors. Diese gespeicherten Farbzuordnungen werden beim Neustart von irssi bzw. Neuladen des Skripts wieder eingelesen.

/color set foo 7 gibt ebenfalls nichts aus, legt aber eine Zuordnung der Farbe 7 zum Nickname foo fest. 7 ist in dem Fall das, was in PuTTY gelb und auf der Konsole braun, in anderen Terminals eher orange aussieht. (Mehr zu diesem verwirrenden Thema in der englischen Wikipedia.)

/color clear foo löscht die gesetzte Farbe für foo wieder, gibt aber ebenfalls keine Statusausgabe zurück. Interessant werden dann die letzten beiden Funktionen.

/color list zeigt die aktuell gesetzten Zuordnungen in einer Liste an, bei mir sieht das derzeit so aus, die Namen sind in den Farben, wie sie auch im Chat auftauchen, die Zahlen dahinter sind erst bei dem Kopieren aus der Konsole zum Vorschein gekommen, geben aber die Farben wieder:

Mo|23:06:25 -!- Irssi: Saved Colors:
Mo|23:06:25 -!- Irssi: An-Tet (9)
Mo|23:06:25 -!- Irssi: Fabian (7)
Mo|23:06:25 -!- Irssi: Ge0rG (12)
Mo|23:06:25 -!- Irssi: IseeU (13)
Mo|23:06:25 -!- Irssi: Mupfy (3)
Mo|23:06:25 -!- Irssi: priority (3)
Mo|23:06:25 -!- Irssi: schlotze (4)
Mo|23:06:25 -!- Irssi: StarWarsFan (12)
Mo|23:06:25 -!- Irssi: StefanG (3)
Mo|23:06:25 -!- Irssi: SvenG (13)
Mo|23:06:25 -!- Irssi: thndr (12)
Mo|23:06:25 -!- Irssi: thunder (12)
Mo|23:06:25 -!- Irssi: zozi (6)
Mo|23:06:25 -!- Irssi: _MrTux_ (7)
Mo|23:06:25 -!- Irssi: _Tux_ (7)

Last not least kann man sich mit /color preview auch noch eine Liste der verfügbaren Farben ausgeben lassen:

Mo|23:19:39 -!- Irssi: Available colors:
Mo|23:19:39 -!- Irssi: Color #2
Mo|23:19:39 -!- Irssi: Color #3
Mo|23:19:39 -!- Irssi: Color #4
Mo|23:19:39 -!- Irssi: Color #5
Mo|23:19:39 -!- Irssi: Color #6
Mo|23:19:39 -!- Irssi: Color #7
Mo|23:19:39 -!- Irssi: Color #8
Mo|23:19:39 -!- Irssi: Color #9
Mo|23:19:39 -!- Irssi: Color #10
Mo|23:19:39 -!- Irssi: Color #11
Mo|23:19:39 -!- Irssi: Color #12
Mo|23:19:39 -!- Irssi: Color #13
Mo|23:19:39 -!- Irssi: Color #14

Alles in allem eine sehr praktische Erweiterung für irssi, wenn man weiß, wie man sie bedienen muss. ;-)

Ein Punkt, den ich persönlich bedauere ist die Offenheit des Projekts. Es hat sich historisch so entwickelt, dass es ein Kernteam von offiziellen Entwicklern gibt, diejenigen, die das Basis-System betreuen, das Kernel-Paket und diverse große Pakete wie Mail, Samba, MySQL, Apache usw. Das ist grundsätzlich erstmal nichts verkehrtes, man kann z.B. einfach nicht der ganzen Welt Schreibzugriff auf das zentrale Entwicklungs-Repository geben – Lesezugriff hingegen schon. Leider ist nicht nur dieses Repo der Öffentlichkeit verborgen, sondern es läuft auch viel Kommunikation an den öffentlichen Newsgroups vorbei. Dafür gibt es Gründe und die meisten Entwickler und Anwender sind mit der Situation so auch zufrieden.

Ich persönlich denke, dass ein öffentliches Repository (read-only ;-) ) und ein öffentlicher Bugtracker die Entwicklung und Popularität eines Projektes fördern, auch wenn die Entwickler dann möglicherweise mehr Zeit für Support aufbringen müssen und sie diese Zeit nicht für die Entwicklung zur Verfügung haben. Weil ich das so sehe und weil ich mit meinen eigenen Paketen natürlich machen kann, was ich will, gib es eben diese ab sofort frei – so frei wie in Freiheit und so frei wie in Freibier: http://www.lespocky.de/eisfair/

Jeder eisfair-Entwickler und -Nutzer kann also ab sofort meine Pakete nicht nur installieren, sondern den Quellcode auch abseits der Paketdateien direkt im Repository anschauen, auschecken, ändern, mir Patches schicken, Tickets anlegen usw. – wie man das von vielen anderen OpenSource-Projekten kennt. Ich weiß, dass ich keinen Ansturm erwarten darf und genau genommen erwarte ich eher, dass alles genauso ruhig abläuft wie vorher – aber es besteht die Möglichkeit und ich habe die leise Hoffnung, dass sich andere eisfair-Paketentwickler ein Beispiel nehmen und dem Projekt durch mehr Offenheit zu mehr Popularität und dadurch mehr Verbreitung, neuen Entwicklern und letztendlich mehr Qualität verhelfen werden.

:-)

Der Open-Source-Tag selbst findet zum ersten Mal statt und wird von Stefan Schumacher organisiert. Unterschrieben ist das mit »Entwicklung trifft Anwendung«, die Themenschwerpunkte gehen in Richtung Erziehung, Bildung, Publishing. Natürlich sind auch ein paar thematisch anders gelagerte Vorträge im Programm. Jenes liest sich übrigens sehr interessant, man kann sich kaum zwischen den vier Tracks entscheiden.

Ich persönlich werde mir wohl die Vorträge anhören, die in Richtung LaTeX gehen und ich werde natürlich selbst auch auf der Keysigningparty zugegen sein. Dort sind übrigens auch ein paar Leute anwesend, die Punkte für CAcert vergeben können und wollen. ;-)

Es muss irgendwann im Jahr 2003 gewesen sein, dass ich eisfair zum ersten Mal installiert und ausprobiert habe. Das Projekt selbst lief da schon einige Zeit, das Archiv der Newsgroup wurde jedenfalls im November 2001 eingerichtet. Ich hatte zu Beginn des Studiums ja noch den alten Pentium 233 MMX von meinen Eltern als Rechner benutzt, 2003 erstand ich bei eBay dann das ASUS TUSL2-C mit Celeron 1400, über das ich hier bereits schrieb. Das wurde dann Arbeitsrechner und aus den Teilen vom Basteln mit dem Fli4l-Router waren so einige Teile übrig, woraus dann ein Zweitsystem zusammengesteckt wurde. Irgendwann fand dann eisfair den Weg auf dieses Testsystem, zunächst wohl für Webentwicklung oder Spielerei oder ähnliches. Damals war noch Kernel 2.2.x Stand der Dinge (für eisfair) und es gab auch keine Install-CD. Meinen Promise Ultra 66 bekam ich erst mit dem ersten Testkernel 2.4.23 und manuellem Anlegen von /dev/hde? zum Laufen, das base-Paket war glaube ich noch bei 1.0.3 oder so.

Anfang 2004 waren ein paar Freunde für eine kleine private LAN-Party zu Besuch. Ich spielte immernoch unter Windows 98 und der eine oder andere wird sich erinnern, dass es da mit vernünftigem Multitasking, noch dazu aus nem Spiel raus, nicht soweit her war. Mal eben zum ICQ-Client wechseln und zurück gefährdete massiv die Stabilität des Spiels, warum also nicht den ICQ-Client auf dem zweiten Rechner laufen lassen? Da eisfair nun ein Serversystem ohne grafische Oberfläche ist, kamen da nicht viele Clients in Frage, genau genommen nur einer: micq.

Die damals verfügbare Version hatte Probleme mit der damals aktuellen Version vom ICQ-Protokoll und so fragte ich den damaligen Maintainer vom micq-Paket, Roman Schließmeyer, nach einem Update:

ich habe im Moment leider keine Zeit um die Pakete zu pflegen, deswegen werde ich auch kein Update des micq Paketes durchführen. Wenn du magst kannst du das gerne übernehmen,

So kam dann eins zum anderen und am 12.04.2004 veröffentlichte ich mein micq-Paket in Version 1.0.1. Warum? Eigenbedarf! Genau darum ging es nämlich im eingangs erwähnten Chat. Eine der größten Antriebskräfte im Open-Source-Bereich ist Eigenbedarf. Das gilt für meine eisfair-Pakete ebenso wie für IMPULS und es gilt nicht nur für mich selbst. Viele Open-Source-Entwickler arbeiten an »ihrer« Software, weil sie sie selbst einsetzen und benutzen wollen. Natürlich ist das nicht der einzige Grund, aber ein sehr wichtiger, das sehe ich bei eisfair im Prinzip täglich. Das Zitat zeigt aber auch noch etwas anderes: eisfair ist ein reines Freizeitprojekt und Zeitmangel ist bei den Entwicklern praktisch obligatorisch – damals wie heute.

Ende 2005 bekam ich dann die Einladung dem frisch gegründeten Test-Team beizutreten, im letzten Jahr war ich zum ersten Mal auf dem Entwicklertreffen. Seit 2003 ist viel passiert in der Entwicklung, ich hatte ja schon an der einen oder anderen Stelle mal was angedeutet. Da ließe sich auch noch viel mehr schreiben, aber das hebe ich mir mal für einen späteren Beitrag auf. ;-)

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.

Die Vorteile:

• browser-basiert (funktioniert prima mit Firefox) und damit plattformunabhaengig
• Nur eine einzelne (zugegeben grosse) HTML-Datei, brauch lediglich einen Javascript-faehigen Browser
• Datei kann lokal gehalten werden oder auch auf tiddlyspot.com oder eigenem Webserver online verfuegbar gemacht werden
• fuer mich sehr angenehme Verwaltung der einzelnen Arbeitseinheiten von GTD (Actions, Projects, Areas)
• einfache Bedienung durch Tiddlers (Miniseiten innerhalb des TiddlyWikis)
• MonkeyGTD erstell beim Speichern selbst ein Backup von sich, dass nur noch manuelle archiviert werden muss
• Backups und Upgrades koennen scheinbar ueber einen vorhandenes Plugin jeweils ohne viel Aufwand mit der aktuellen Version zusammengefuehrt werden (habe ich noch nicht probiert)

Einziger Nachteil, den ich bisher gefunden habe, ist, dass die Backupdateien mit der Zeit sehr viel Platz beanspruchen (bei knapp 500 KB pro einzelnem Backup).

Mein MonkeyGTD befindet auf einem USB-Stick, ich setze es seit knapp drei Wochen taeglich sowohl im Buero als auch daheim ein  (jeweils mit Firefox) und ich bin sehr gluecklich damit. Mein Arbeitstag mit seinen vielen Aufgaben und auch Ablenkungen wird zunehmend ueberschaubarer und handhabbarer, weil ich nichts mehr im Kopf behalten muss, ich deswegen mehr schaffe und ich trotzdem nichts vergesse.

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.

Folgende Eigenschaften soll es haben:

• Frontend im Stil vom Google-Kalender. Erreichbar über jeden Browser.
• Verfügbare Software, die ich auf meinem eigenen Server installieren kann und die mir alleinige Kontrolle über meine Daten gibt.
• Das Backend kann Kalenderdaten in IMAP-Foldern verwalten. Das ist meine derzeitige Speicherform, die den Vorteil hat, dass ich kein zusätzliches LDAP- oder DAV-System installieren muss, sondern einfach mein E-Mail-Postfach verwenden kann.
• Kostenlos und OpenSource.
• Optional: Eine schicke API, mit der ich ggf. auch andere Tools wie z.B. einen Reminder anbinden kann. Das muss aber nicht sein, weil die Daten ja auch schon im IMAP-Folder gut lesbar vorliegen.

Sachdienliche Hinweise bitte in die Kommentare oder per Nachricht an mich.

Seit gestern Abend ist unter http://tools.penguineering.com eine Sammlung von Tools zu finden, die in einzelner oder gemeinsamer Arbeit der Blog-Autoren entstanden sind und allgemein verfügbar sein sollen.

Die Seite sieht noch etwas mager aus, aber das wird sich im Lauf der Zeit ändern.

Nun wurde kürzlich ein neues Kernel-Paket für eisfair-1 veröffentlicht: ein gepatchter 2.4.35. Wir haben im Testteam lange getestet bis er im März der Öffentlichkeit zum Fraß vorgeworfen wurde. Ein neuer Kernel bedeutet aber auch, dass LIRC neu übersetzt werden muss, da es seine Treiber selbst mitbringt und Kernelmodule nunmal zur Kernelversion passen müssen. Es gab auch schon die eine oder andere Anfrage in der Newsgroup und ich beschäftige mich seit ein paar Tagen mit einer neuen Version des Pakets.

Zunächst steht das Kompilieren an. Ich konnte LIRC 0.8.2 für die eisfair-Kernel 2.4.26-1 und 2.4.35-wt1 jeweils in den Versionen mit und ohne Unterstützung für SMP übersetzen – für 2.4.26 mit der alten Build-Umgebung mit gcc 2.95.3 und für den 2.4.35 mit der zukünftigen Build-Umgebung mit gcc 3.4.6, die zur Zeit vom Testteam getestet wird. Das Übersetzen von LIRC artet schnell in Arbeit aus, weil es mit einem Lauf aus ./configure, make und make install nicht getan ist. Das muss für jede Kernel-Version und jeden gewünschten Treiber einzeln gemacht werden, es sei denn, man kompiliert gleich alle Treiber. Tut man dies nicht, ist noch mindestens ein Lauf mit der Option --with-driver=userspace nötig, damit LIRC auch in der Lage ist mit verschiedenen Treibern gestartet zu werden und nicht nur mit dem, für den es kompiliert wurden, wie z.B. serial.

Also wie gesagt, ich konnte LIRC für die Treiber serial und atiusb kompilieren – das sind die beiden, wo ich selbst Hardware zum Testen habe. Dank VMware waren auch die verschiedenen Kernel kein Problem, ich hab einfach für jeden eine neue virtuelle Maschine angelegt. Die anfängliche Euphorie, dass auch ein LIRC 0.7.1 mit den aus 0.8.2 gebauten Kernelmodulen für 2.4.35 läuft, wich dann der ersten Enttäuschung. Ich hatte zunächst die Version, die mit allen Treibern laufen soll, mit --with-driver=none kompiliert. Das funktionierte logischerweise nicht. Der erste herbe Rückschlag: LIRC 0.8.1, 0.8.2 und 0.8.3pre1 lassen sich mit der neuen eisfair-Buildumgebung und der korrekten Option --with-driver=userspace nicht übersetzen, wie man auf der Mailingliste von LIRC nachlesen kann.

Man kann dort ebenfalls nachlesen, dass ich versucht habe, die neueste Version aus dem CVS zu übersetzen, wo dieser Fehler bereits behoben ist. Leider macht mir da die Buildumgebung einen Strich durch die Rechnung. Das Skript ./configure liegt nicht im CVS, sondern wird mit den autotools (autoconf, automake usw.) erst noch selbst erzeugt. In der Theorie funktioniert das gut, in der Praxis tritt bei mir leider der gleiche Fehler auf, den ich vor einiger Zeit schon hatte, als ich climm aus dem SVN bauen wollte. Es wird ein unbrauchbares Skript erzeugt, dass nur eine wenig hilfreiche Meldung ausgibt. Wenn sich jemand gut mit autoconf auskennt und eine Idee hat, wo da das Problem liegt, möge sie sich dringend bei mir melden! Fazit jedenfalls: LIRC aus CVS ist für mich nicht möglich.

Heute erreichte mich dann über die Mailingsliste von LIRC die überraschende Nachricht, dass gerade die 0.8.3pre2 rausgegeben wurde. Der o.g. Fehler tritt nicht mehr auf, dafür ein neuer. LIRC lässt sich nicht mehr mit dem Treiber serial übersetzen, weil in der entsprechenden Quellcode-Datei eine Header-Datei aus den Kernelquellen nicht gefunden wird. Zumindest wird sie bei den 2.4er Kerneln nicht gefunden. Ein flüchtiger Blick in den Quellbaum eines 2.6er Kernels offenbarte, dass es dort zwei Dateien io.h gibt, eine in /usr/src/linux/include/linux und eine in /usr/src/linux/include/asm – beim 2.4er Kernel gibt es bloß letztere.

Auch dies habe ich auf der Mailingliste von LIRC gemeldet und warte erstmal ab. Es gibt nämlich mehrere Möglichkeiten jetzt:

• ich warte ab, bis die nächste LIRC-Version veröffentlicht wird, mit der ich alles korrekt übersetzen kann
• ich baue das allgemeine LIRC und die Treiber für atiusb aus der 0.8.3pre2 und die Treiber für serial aus der 0.8.2
• ich kann durch wundersame Eingebung oder Hilfe von außen den Fehler in der Buildumgebung finden, so es denn tatsächlich einer in dieser ist, und die aktuelle Version aus dem CVS übersetzen
• ich gehe in den Versionen soweit zurück, bis ich auf eine stoße, die ich komplett übersetzen kann, das wäre dann wahrscheinlich die 0.8.0
• ich behebe den Fehler in 0.8.3pre2 selbst und übersetze dann meine modifizierte Version

Ehrlich gesagt, gefällt mir die erste Version bisher am besten, allerdings könnte das unter Umständen noch eine Weile dauern, je nachdem wie schnell die Entwickler von LIRC die nächste Version rausbringen. Module aus verschiedenen Versionen wollte ich eigentlich vermeiden, um mir nicht eine zusätzliche Fehlerquelle aufzureißen. Auch eine alte Version finde ich nicht so cool. Ob wir den potentiellen Fehler in der Buildumgebung schnell finden, ist auch ungewiss, bleibt also im Grunde noch die letzte Möglichkeit: ich stöber durch den C-Code und beheb den Fehler selbst – dazu hab ich keine Lust…

Falls sich also jemand fragt, warum die neue Version des LIRC-Pakets für eisfair so lange braucht, ich weise sämtliche Schuld von mir und schiebe es auf höhere Gewalt!