Photobearbeitung und -verwaltung für Professionelle

Ich hatte vor einiger Zeit schon mal drüber nachgedacht, ob ich mir nicht eine Lizenz für Bibble Pro zulege, weil die Testversion einen recht guten Eindruck hinterlassen hatte. Speziell die Verarbeitungsgeschwindigkeit war klasse aufgrund des Multithreadings, für mich mit auf der höchsten Prioritätsstufe. Allerdings waren da hinter den Kulissen noch einige Fehler zu finden und letztlich war mir das zu viel Geld für das knausrige Interface.

Etwas Erstaunen hat dann die Nachricht  bei mir hervor gerufen, dass Corel die Firma Bibble gekauft hat und seitdem die Software unter dem neuen Namen AfterShot Pro vertickt. Corel gibt’s tatsächlich noch? … Na jedenfalls soll die mit digikam vergleichbare Software auch weiterhin für Linux angeboten werden und unterstützt zumindest auf dem Papier 32 und 64 Bit.

SSDs, ext4 und BigAlloc

Einige Fundstücke, die sich mit dem Themenkomplex Dateisysteme und SSD beschäftigen. Aufhänger war hier BigAlloc, ein neues Feature für ext4, dass oberflächlich gesagt mehrere kleine Blöcke zusammenfasst und so Verwaltungsaufwand beim Schreiben (deutlich) minimieren kann. Bedauerlicherweise kann es nur mit neu anzulegenden ext4-Partitionen verwendet werden und nicht in bereits existierenden. Erfreulicherweise erhellen die Kommentare bei lwn.net die Funktionsweise von ext4 soweit, dass klar wurde, dass ein ähnlicher Mechanismus bereits eingebaut ist: extents.

Der zweite Artikel vergleicht SSDs und Journaling-Dateisysteme anhand ihrer funktionellen Mechanismen und stellt die Behauptung auf, dass eigentlich SSDs schon genau das tun, was journaling bei Dateisystemen wie xfs, ext3/4 oder btrfs bwirken soll. Interessanter Gedanke in den Kommentaren (sinngemäß): SSDs sind quasi als Ersatz für rotierende Festplatten entworfen worden und werden aktuell auch so gebaut, obwohl die zugrundeliegende Technik völlig anders funktioniert. Mittels des Controllers und der Firmware werden sie aber so gesteuert, dass sie für das Betriebssystem wie eine normaler ATA-sprechender, rotierender Datenträger aussehen. Die Konsequenz daraus ist, dass sie eigentlich eine viel schlechtere Performance liefern als sie eigentlich könnten und dass das zu einem Großteil der Marktdominanz von M$-basierten Desktop-Systemen geschuldet ist.

radeon: cooler and cheaper! (finally)

Woohoo! Since 3 or 4 days ago the radeon (RV770) in my computer runs much cooler, if one switches power_profile from default to low. I don’t know where the change happened, maybe somewhere in the last stable-kernel updates, but i didn’t read anything about it in the release information. From the day AMD announced to release documentation helping kernel/xorg developers producing a working open source driver many people waited for such events. Despite my card is a bit older (in terms of graphic card lifetime) that change will let the card run on lower temperatures and saves me a dollar^wEuro because that means a huge drop in energy consumption too. +20 watt less is a number i’ll see on my annual energy bill. And noise level dropped too. The driver already had *some* power management functions but for a long time voltage/frequency lowering only worked in dpms standby/off (means: monitor in standby or off) and not during normal operation. So, to me it seems like a late Christmas Gift.

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.

Boot-Zeit verkürzen und Wunsch-Desktop bauen

So. Nach etwas längerem Rumfuchteln rennt das System hier jetzt von einer SSD (samsung, 128GB). Gut, mit ca. 20 s (bis login-Prompt)  startete das System nicht gerade langsam, was hauptsächlich an der Verwendung von runit liegt. Der Kernel selbst braucht ungefähr 4 s bis zum init. Aber die gut 15 s kann man ja auch noch einsparen und so in Bereiche von suspend2ram kommen, ohne dessen Probleme.

Nach dem Auspacken und Einbau der SSD wurde das bestehende System gestartet und die Platte erstmal mit smartctl inspiziert. Nächster Schritt war das Partitionieren und Ausrichten, dann das Einrichten eines ext4-Dateisystems und dann das eigentliche Kopieren der Daten vom alten System auf die neue Platte. Schon beim Kopieren kann man einen Eindruck bekommen, welcher Schritt der Umstieg auf so einen schnellen Datenträger bedeutet. Trotz werkseitig eingebautem Fehler des SB600-Chipsatzes und eher lahmer Gesamtperformance konnte rsync die Prozesslast auf hohem Niveau halten und rund 70 MB/s rüber schaufeln. Das liegt nur geringfügig unter der theoretischen Maximalleistung laut hdparm und macht eher deutlich, wie schlecht die rotierenden Platten an dem Chipsatz arbeiten.

Das Einrichten von grub, um von der neuen Platte zu booten, ging auch recht schnell. Dachte ich. Leider ließ sich update-grub nicht dazu überreden, in der grub.cfg die richtige Platte und Partition für den root-Parameter zu schreiben. Bedauerlicherweise kennt das Programm aber auch keine Möglichkeit das zu erzwingen. Mit dünner werdenden Nervenkostüm und nach einiger Zeit des Probierens schwenkte ich auf syslinux um, weil ich dachte, dass es eben an grub (in seiner moderneren 2er Version) liegt. Aber mit syslinux das gleiche Spiel: wieder wurde das root-device nicht erkannt und es landete wieder die alte Partition in der Konfiguration. Durch Zufall fiel dann beim Stöbern auf, dass /dev/root einfach falsch gesetzt wurde. In meiner modifizierten runit-stage 1. Vermutlich aufgrund der immer wieder sporadisch auftauchenden Bequemlichkeit standen dort die device-Parameter fix drin und nicht wie im originalen udev-Skript als zur Laufzeit zu ermittelnde. Nachdem das gefixt war und auch im BIOS die Reinfolge geändert wurde, rannte das System jetzt von der richtigen Platte (ohne manuellen Eingriff). Und zwar so schnell, dass man vom eigentlichen Booten (dank zu langsam umschaltenden Bildschirm) nichts mehr sieht. Syslinux-Bildschirm -> schwarz -> xdm-Login in geschätzten 8 Sekunden. Schön.

Der nächste Schritt wird jetzt das Einsparen des xdm und des Logins werden. Boot to Desktop, möglichst mit allen gewünschten Fenstern und laufender Musik. :)

Farbtreue Bildbearbeitung

Mäh. Ich wollte jetzt nicht color management im Titel schreiben, aber um genau das geht’s. Bisher an mir vorbei gegangen ist die Nachricht, dass Linux (und vermutlich auch andere Open-Source-Plattformen mit Bedarf) bald ein ordentliches, systemweites Farbprofil-management (hmm, wie nennt man das nur richtig) bekommen könnte. Es gibt sogar *zwei* Projekte, die sich dieser Aufgabe stellen. Das erste System ist colord (mehr GNOME-ig, aber doch universell) und das andere, oyranos, gibt es seit letztem Jahr seit 2005 (wuä? lwn-Infos ungenau). Natürlich gibt es so einige Anwendungen unter linux, die mit icc-Profilen etwas anfangen können, aber der systemweite Ansatz fehlte bisher. Windows oder MacOS haben das schon recht lange. Das ist einer der Gründe, warum Bildbearbeitung unter Linux eher ein Krampfthema war. Mit digikam und gimp gibt es zwei in meinen Augen wichtige Werkzeuge, die aber vom workflow ein eher isoliertes Dasein führen. Der colord-Ansatz verspricht eine durchgehende Farbtreue von der Kamera über den Monitor bis zum endgültigen Ausdruck, ohne dass das in jeder beteiligten Anwendung einzeln eingerichtet werden muss.