Konsequenz der Bequemlichkeit

Oh oh, dachte ich heut Nachmittag, als ich versuchte, meinen Passwort-Safe zu öffnen. Den hatte ich seit einiger Zeit nicht mehr angefasst, genauer gesagt, seit der Umstellung des Systems von 32 auf 64 Bit. Eigentlich ist das – im theoretischen Idealfall – kein Problem, weil das System trotz breiterer Architektur bei Vorhandensein der 32Bit-Bibliotheken auch 32Bit-Programme ausführen kann. Die hatte ich vermutlich bis vor kurzem auch noch auf der Platte und es wäre mir wahrscheinlich gar nicht aufgefallen, vielleicht etwas Gejammer wegen fehlender Bibliotheken, aber es wäre noch möglich gewesen. Durch einen unsachgemäßen Eingriff hab ich aber den Paketmanager vor ein paar Wochen dazu gezwungen, aus dem eigentlich inkonsistenten Zustand (Unmengen an alten 32Bit-Paketen waren noch auf der Platte, aber das Paketsystem sah sie nicht mehr) wieder einen konsistenten Zustand zu machen. Das hatte das Entfernen von reichlich 1200 Paketen zur Folge, u.a. auch das für diesen Artikel ursächliche. Leider geht Nachinstallieren für x86_64 auch nicht mehr, da das Paket gar nicht mehr im Debian-Paketsystem geführt wird. Da ist guter Rat teuer.

Glücklicherweise finden sich im Netz noch die originalen Quellen (2010 das letzte Lebenszeichen) auf github. Und in meiner nicht-mehr-ganz-so-jugendlichen Naivität dachte ich natürlich, dass ein Übersetzen der Quellen mit dem aktuellen System kein Problem sein sollte und mich zum Öffnen des Safes befähigen müsste. (Der geneigte Leser mag sich die Fortsetzung dieses Gedankengangs kurz selbst ausmalen.) Es ging natürlich nicht. Obwohl das Binärformat des Safes in einer Definition festgeschrieben ist und eigentlich unabhängig von der verwendeten Architektur sein müsste, ließ sich die Datei nicht öffnen, schlimmer noch, das Programm verstarb geräuschvoll mit SEGFAULT bei jedem Versuch.

Jetzt bleiben noch ein paar Möglichkeiten, bevor ich mir den Kopf zerbrechen muss, was an wichtigen Daten da drin stand, die ich unter Umständen nicht wieder zurück bekomme. Ein Übersetzen mit debug-Informationen, um überhaupt erstmal die Ursache des Fehlers beim Öffnen zu finden. Das wird nicht leicht, da make mit gesetztem DEBUG eine metrische Tonne an Fehlermeldungen ausspuckt. Eine andere Möglichkeit wäre ein cross compile für 32 Bit, was vermutlich am Alter der beteiligten Bibliotheken scheitern wird. Und der letzte Akt ist das Aufsetzen einer 32Bit-VM und das Übersetzen des Programms da drin. Auch nicht unbedingt ein Garant für guten Schlaf. Die nächsten Tage werden es zeigen.

Schon wieder fetter werdende Software

Aufgrund eines (vermutlich) eher banalen Fehlers beim Aufbereiten der neuen Pakete durch den Maintainer, ist das update von syslog-ng bei mir erstmal fehlgeschlagen. Bisher gab es nur ein Paket, syslog-ng. Neu ist, dass syslog-ng ein Meta-Paket ist, dessen Installation selbst eigentlich keinen weiteren Inhalt mitbringt, aber stattdessen mehrere neue Pakete als Abhängigkeiten mitinstalliert. Warum? Weil die Software seit Neustem (im debian-Zeitraum) Plugins für diverse Speichertechniken wie zum Beispiel Datenbanken mitbringt. Das gleiche hab ich auch schon an anderer Stelle gesagt: sowas ist für mich ein Grund, mich nach einer anderen, schmaleren Software umzusehen und bei Erfolg diese zu installieren. Ich möchte das nicht. Syslog-ng war einst eine kleine, aber feine Alternative zum Standard syslog/klog und machte eigentlich nur den Kern dessen, was eine logging-Software machen soll: Nachrichten des Kerns und verschiedener Daemons entgegen nehmen und abhängig von der Konfiguration in Dateien schreiben oder an einen anderen Rechner schicken. Das ist in meinen Augen noch als KISS-gerecht zu bezeichnen. Aber nicht mehr das Schreiben von log-Meldungen in Datenbanken. Die Möglichkeit Plugins zu nutzen sollte entweder schon beim ersten Entwurf der Software Bestandteil sein oder gar nicht. Das nachträgliche Einführen ist in meinen Augen der sichere Weg um die Software fett und anfällig zu machen, sprich: bloat. Die Plugins bedeuteten ja nicht, dass der Kern der Software unangetastet bleibt. Auch wenn der Großteil der neuen Funktionalität in externen Modulen liegt, so muss doch das mögliche Einbinden weiterer Module zusätzliche Arbeit beim Verarbeiten von log-Meldungen und beim Laden des Programms bedeuteten. Also die Komplexität steigt erheblich an und damit die Anfälligkeit für Fehler. Bei so einer grundlegenden Anwendung wie dem syslog-Daemon keine gute Idee. Vor allem, da die angebotenen Plugins sicher nur einen Bruchteil der Anwender wichtig sind. Und wenn ich mir so die wishlist-Punkte im bugtracker anschau, wird mir nicht besser.

Nachtrag: die Homepage von syslog-ng bestärkt mich nur noch mehr. Das es eine kommerzielle Variante gibt, ist schon länger bekannt und eigentlich kein Problem. Nur wenn die Feature-Liste zu nackt aussieht, kauft das ja keiner, also wird da reinimplementiert was das Zeug hält. Bullshit-Bingo dürfte damit auch in erreichbarer Entfernung sein.

twitter unter Linux PITA?

Im Vergleich mit anderen Leuten, dachte ich immer, sind meine Ansprüche an Software meistens gering und ich kann mich besser eher mit irgendwelchen Mätzchen arrangieren. Seit ich twitter benutze, hat sich das offensichtlich geändert. Ich hab vermutlich alle gegenwärtig über apt zu bekommende linux-Versionen probiert und keinen client gefunden, der nicht irgendein Haar in  der Suppe hat. Manche waren länger im Einsatz, zum Beispiel qwit und zur Zeit hotot, andere sind sofort nach dem ersten Ausprobieren wieder von der Platte geflogen. Ich verwende kein KDE/gnome, daher mach ich um explizit für diese Desktop-Umgebungen entwickelte Clients gleich einen Bogen. qwit, zum Beispiel, hat tweets oft verkürzt in der timeline, obwohl weit weg von der 140-Zeichen-Grenze. Da gerade hashtags und URLs am Ende eines Tweets stehen, ist das unendlich nervig. hotot hab ich dabei noch nicht erwischt, aber der client ist im Gegensatz zur Meinung des Autors nicht wirklich lightweight (baut auf webkit auf) und dem fehlt ein mir langsam lieb gewordenes feature von qwit: Klick auf den @autor öffnet im Browser dessen timeline. Mal davon abgesehen, dass die twitter-Seite auch seltsame Eigenheiten aufweist (die letzten X tweets werden irgendwie erst nach einer halben Minute oder mehr geladen), seh ich dort eigentlich alle tweets eines Autors. Die Webseite fand ich bisher deswegen interessant, weil da seit einer ganzen Weile zu einem tweet auch die komplette Unterhaltung mehrerer Autoren zu finden ist. Dankenswerterweise kann hotot das auch. Und so bleibt dieser client für die nächste Zeit auf meinem Desktop. Solange bis eine bessere Software auftaucht.

xorg – roll it back!

Weil der aktuelle Xorg hier nahe an der Unbenutzbarkeit (sehr langsam, flackernd) ist, hab ich die alte Version aus dem November letzten Jahres wieder installiert. Downgrade ist allerdings immer so eine Sache, man kann sich damit auch gepflegt in den Fuss schießen. Offiziell wird so etwas nicht von debian unterstützt, die Software (apt und Konsorten) gestattet es aber.

Zuerst sichert man die sources.list, dann erzeugt man eine neue mit dem Inhalt:

deb http://snapshot.debian.org/archive/debian/20101201/ unstable main contrib

snapshot ist das Archiv der debian-Repositories und spiegelt den Inhalt von 2005 an bis zum heutigen Tag. Also wenn der Paketzustand vom 1. Dezember letzten Jahres wieder hergestellt werden soll, ist die obige Zeile in die neue sources.list einzutragen. Ein anschließendes Update holt das Verzeichnis der zu diesem Zeitpunkt vorhandenen Versionen aller Pakete:

apt-get -o ‚Acquire::Check-Valid-Until=false‘ update

Die Angabe der Option ist dabei notwendig, da sonst apt das Update verweigert.

Da ich meine xorg-relevanten Pakete vorher schon alle entfernt hatte, reicht ein einfaches

apt-get install xserver-xorg xserver-xorg-core …

und ich hab wieder die Versionen aus dem November auf der Platte.

wollte ich eigentlich noch schreiben

RawTherapee ist ein Bildbearbeitungsprogramm, hauptsächlich für das Verarbeiten von raw-Bildern gedacht. Mit Freude hatte ich schon vor einigen Wochen gelesen, dass die Software unter GPL gestellt wird und somit eine weitere Alternative auf dem Weg zu meinem Rechner ist. Gegenwärtig ist die „geöffnete“ Variante der Software eine alpha-Version, es fehlen einige Merkmale und mit Abstürzen sollte man rechnen. Das hält mich natürlich nicht davon ab, sie mal zu testen und die Ergebnisse mit digikam oder ufraw zu vergleichen. Erster Eindruck: die Entwicklung von raw-Dateien bringt in etwa vergleichbare Ergebnisse. Kein Wunder, liegt doch auch hier dcraw wie bei den anderen Kandidaten zu Grunde. Der Umfang an Manipulationsmöglichkeiten erscheint mir reichhaltiger bzw. viel feiner abstufbar. Das kann zum Spielen einladen, aber wenn man mal einen eigenen workflow gefunden hat, kann man das gleich als Profil speichern und in Zukunft wieder verwenden. Was mir mit den oben genannten Kandidaten und auch rawtherapee etwas aufstösst ist die Bearbeitungsgeschwindigkeit. Wenn man mal bibble 5(kommerzielle Software) ausprobiert hat, kommt einen der Rest wahrscheinlich immer langsamer vor (das ist eine Entschuldigung! *g). Mehr dazu, wenn die Software mal gefestigt ist und auch per apt zu bekommen ist.

stoff

Ja worüber will ich eigentlich hier schreiben. Ein spezielles Thema hab ich nicht, eher der übliche Kleinkram der einem so durch den Kopf geht. Tagespolitik wird ein Thema sein, Technik natürlich, Bilder sollen auch regelmäßig erscheinen und noch Themen aus der Open-Source-Welt, speziell Linux und Debian.