the rompe blog

Do you have a corrupted flash media and want to rescue as much of your data as possible? Or do you want to be prepared, just in case this happens to you one day? Do you use Linux? Then read on.

Yesterday I was given a defective flash card. It was said to contain several photos, but every attempt to see more than the first DCIM directory resulted in unrecoverable errors on Windows. So I inserted the card into a Linux box, created an image of it using

dd if=/dev/sdb1 of=/tmp/sdb1.img bs=8k

and gave the card back to it's owner. That's important: If you want to experiment with defective or suspect media, then dump it and remove it as soon as possible. Otherwise chances would be high that you only worse the state of the media.

Once I got rid of the original, I created a copy of the dump. It's always a good idea to work on a copy, so:

cp /tmp/hdb1.img /tmp/hdb1.work

Done that, I first tried to mount the copy as a loop device:

mount -t vfat -o loop /tmp/hdb1.work

But the image was so broken that I wasn't able to get mount to accept it as a FAT partition of any type. I also gave the mtools collection a try, but to no avail.

Thinking about other tools to try I remembered the Sleuthkit that I once used to exermine a compromised system. If it is good enough for the big job, it should handle this one with ease, I thought. Sleuthkit is a collection of file system and media management forensic analysis tools. And this great toolkit didn't let me down. Here's what to do:

• Install Sleuthkit (Doh!). Many distributions already contain packages for it, at least Debian Sid does.
• Sneak a peak of the file system with fls. In this case it looks like this:
  

  $ fls -f fat16 -r /tmp/sdb1.work
  d/d 3:  DCIM
  + d/d 517:      100MLT19
  ++ r/r 1029:    PICT0001.JPG
  ++ r/r 1030:    PICT0002.JPG
  ++ r/r 1031:    PICT0003.JPG
  ++ r/r 1032:    PICT0004.JPG
  ++ r/r 1033:    PICT0005.JPG
  ++ r/r 1034:    PICT0006.JPG
  [...]

• Now we want to extract everything that looks like an picture. We can use the icat tool to do that, and because I like oneliners, I did it with a pipe:
  

  fls -f fat16 -r /tmp/sdb1.work | fgrep PICT | while read bla; do
      set `echo $bla | tr -d ':+'`
      icat -f fat16 sdb.tmp $2 >/tmp/$3
  done

And voila, that's all! The first nine pictures contain random data caused by the filesystem damage, but the other seventy or so are fine. Even if you happen to get a media that in worse condition than the one I was given — never despair, Sleuthkit contains other tools that you can use to find your data, no matter if it is deleted. It also lets you search for binary signatures in case the filesystem is completely screwed. For example you could want to search for some Exif information found in every picture, like "MINOLTA DIGITAL CAMERA" in this case. Just read around on the web site and in the man pages, try out as you like, you can't damage anything since you are working an a copy that you can create again in seconds.

Good luck, or better, don't buy cheap flash cards. ;-)

Ich habe einen neuen. Er ist genau, was ich brauche. Er heißt Music Player Daemon oder kurz mpd.

Ich hatte sie ja schon alle: XMMS, den kleinen, stabilen und mittels Plugins schön erweiterbaren Player, dann dessen GTK2-Fork Beep Media Player (XMMS basiert noch immer auf GTK1), dem aber zumindest im Debian-Paket noch einige Plugins fehlen, Rhythmbox, den übersichtlichen und mächtigen Gnome-Player, der aber auch mächtig Platz auf dem Schirm und im Speicher verbraucht, sowie einige andere.

Bisher bin ich immer wieder auf XMMS zurückgekommen, weil der am stabilsten war und meinen Bedürfnissen am nächsten kam:

• Wenig Platzverbrauch auf dem Bildschirm
• Problemloses Handling großer Playlisten
• Crossfading und Random Mode
• Auch per Kommandozeile steuerbar
• Klein und schnell
• Spielt auch Streams und kann diese in Playlisten ablegen
• Status-Icon für die Notification Area

Doch es haben mich auch prinzipbedingte Dinge daran gestört:

• Wenn man sich mal ausloggt, z.B. nach einem dist-upgrade, ist auch die Musik aus
• Will man anderen Leuten im Netz ermöglichen, mal schnell einen Titel zu skippen, muss man ihnen dafür einen ssh-Zugang zum eigenen User aufmachen. Sehr unschön!

Aber jetzt habe ich micht endlich einmal aufgerafft, mir den mpd anzusehen. Es handelt sich dabei um einen Daemon, der wahlweise beim Boot oder als User gestartet werden kann. Dieser Dämon tut nichts anderes, als auf einem eigenen TCP-Port auf Requests zu warten und entsprechend seine Playlisten zu verwalten und Musik abzuspielen. Um mit dem Daemon zu sprechen, stehen einem verschiedene Clients zur Verfügung. In Debian sind bisher der Kommandozeilen-Client mpc und der Gnome-Client gmpc enthalten. Es gibt aber auch noch andere, auch für KDE.

Den mpc benutze ich überwiegend zum Scripten, beispielsweise zum nächtlichen Update der Datenbank mittels "mpc update", sowie zur Einbindung in Webbrowser, Streamtuner und andere Programme mit Hilfe der in der Man Page angegebenen Scripts.

Die Gnome-Variante gmpc verwende ich genau so, wie ich bisher XMMS interaktiv verwendet habe. Der Player ist in etwa so groß wie XMMS, aber viel übersichtlicher und passt sich natürlich besser in einen Gnome-Desktop ein. Das Status-Icon für die Notification Area bietet mehr Information bei gleichem Platzbedarf, und da das POP-Up-Fensterchen dieses Icons eigentlich alle Informationen zusammenfasst, die man auch auf dem Player selbst zu sehen erwartet (auch den Albumnamen!), bleibt das Hauptfenster der Players ohnehin meist geschlossen.

Und das schöne ist: Wenn jemand anderes im Netzwerk (oder auch ich selbst von einem anderen Comuter aus) den Player steuern möchte und ich ihn dafür freigeschaltet habe, dann kann er das ohne Umwege tun. Beispielsweise kann jeder in dem Büro, in dem ich gerade sitze, einfach auch den gmpc starten und auf meinen Rechner konfigurieren, und schon sieht sein gmpc genau so aus wie meiner und er kann auch die gleichen Funktionen damit steuern. Man kann den mpd also auch als Netzwerk-Jukebox benutzen.

This PDF (mirror) contains loads of general information about performance tuning for Linux systems. It is neither new nor does it offer secret knowledge, but I have learned some little details by reading through it.

While searching for bottlenecks I found the sysstat package very useful. It logs system performance data from /proc that you can browse later using the accompanying command line tools or a GUI frontend named isag which draws nice graphs with GNUPlot.
Debian Packages:

• sysstat - sar, iostat and mpstat - system performance tools for Linux
• isag - Interactive System Activity Grapher for sysstat

If you want to tune the performance of an OpenLDAP server, these are some links you may like to check:

• Quick guide to LDAP - Performance Tuning
• A paper from the competent guys at metaconsultancy
• Big (500 pages) PDF about configuring and using LDAP, including a section about performance tuning
• OpenLDAP Faq-O-Matic: Performance Tuning
• Short, Redhat centric guide with generic tuning tips

Ich habe ja nun eine Weile in das selbstlose Experiment gewagt, zuhause nur noch KDE statt, wie bisher, Gnome einzusetzen. Zunächst war ich von so vielen Dingen begeistert, dass ich glaubte, dieser Ausflug könnte mich derart überzeugen, dass ich Gnome fortan den Rücken kehre.

Dazu ist es nun aber doch nicht gekommen, da ich im Laufe der Zeit anfing, Eigenschaften von Gnome zu vermissen, die eine unvergleichliche Usability bieten, aber im Laufe der Jahr einfach so selbstverständlich für mich geworden sind, dass ich gar nicht daran gedacht habe, explizit Wert darauf zu legen. Man denke nur an Dinge wie "im Webbrowser ein Lesezeichen direkt aus dem Lesezeichenmenü heraus editieren" oder "gesamten Lesezeichen-Subfolder als neue Reiter öffnen". Genauso auf die gleiche Weise möchte man doch eigentlich auch alle Starter und Applets im Panel über das Kontextmenü bearbeiten können. Geht natürlich auch bei KDE, aber eben an jeder Stelle komplett anders und oft unnötig kompliziert.

Was mir vermutlich wieder keiner glauben wird: Gnome2 ist bei mir schneller als KDE3. Klar, KDE hat durchaus Komponenten, die an Geschwindigkeit kaum zu überbieten sind und die offenbar mit links auch noch ordentlich Eye Candy bieten, beispielsweise die ruckelfrei animierten und wahlweise auch noch transparenten Menüs. Ob man diese Schnörkeleien braucht, ist eine andere Frage, aber zumindest ist es schön, die Möglichkeit zu haben, sie einzuschalten. Vermutlich tut man's aber nur für Demo-Zwecke. Aber in einer kompletten Sitzung habe ich den Eindruck, dass ich mit Gnome weniger Wartezeiten habe. Zum einen liegt das vermutlich daran, dass Gnome nicht so viele komplette Repaints eines aktiven Fensters macht wie KDE (und wenn, dann nicht so offensichtlich), zum anderen aber auch daran, soviel muss ich fairerweise sagen, dass ich in KDE beim Keramik-Theme geblieben bin, während ich in Gnome mit den recht schlichten Theme Lighthouse-Blue arbeite.

Muss es mir eigentlich peinlich sein, dass ich schon das ganze Wochenende mit KDE geliebäugelt habe? Ausgerechnet ich, wo ich doch immer auf der Seite der Guten (also Gnome) gestanden habe. Nein, es ist bestimmt nur so eine Phase. Das gibt sich wieder. Vielleicht.

Seit Gnome 2 entwickeln sich einige Dinge in eine sehr professionelle Richtung, keine Frage. Vor allem an der Usability wurde mächtig gearbeitet, was zur Folge hat, dass die meisten Gnome2-Anwendungen nur noch ganz wenige sichtbare Konfigurationsoptionen haben. Klar, so gewinnt man neue User, nämlich die breite Masse, die gar keine Lust hat, die Funktionsweise eines Programmes verstehen zu müssen, nur um es zu benutzen. Aber eventuell verliert man auch alte User damit, die gerne etwas tiefer in ihr System einsteigen. Und die alle auf den GConf-Editor zu verweisen, nein, das kann nicht die wirkliche LKösung sein.

Wozu muss man sich denn überhaupt auf eines der großen Desktop-Environments festlegen? Eigentlich nur aus wenigen Gründen:

1. Alle Programme passen optisch gut zueinander
2. Die Bedienung aller Programme folgt den gleichen Usability-Regeln
3. Da alle Programme die gleichen Libraries teilen, sind auch fette Klötze schnell gestartet und verwenden wenig neuen Speicher, wenn die Libs schon von anderen laufenden Binaries geöffnet wurden

Ich gebe zu, dass mir auch der erste Punkt, und sei er technisch gesehen noch so dämlich, nicht ganz egal ist.

Wenn man diese Gründe für irgendwie zutreffend hält, entscheidet man wohl die Wahl des Desktop-Systems am ehesten anhand der bevorzugten Anwendungsprogramme. Was also hält mich bei Gnome?

• Galeon, mein Webbrowser. Ist immer noch gut, aber nicht mehr so elegant wie die frühere GTK1.2-Version. Hat meines Erachtens auch zu wenig sichtbare Konfigurationsoptionen. Wenn ich mir dagegen Konqueror anschaue, werde ich glatt ein wenig neidisch.
• grip, eine Oberfläche zum CD-Rippen und MP3-Kodieren. Benutzt ohnehin einige eigene Widgets und sieht daher auch unter Gnome wie ein Fremdkörper aus. Wird selten gestartet und läuft dann meist recht lange am Stück.
• The GIMP, das GNU Image Manipulation Program. Ein echtes Paradestück für GTK-Programmierung. Wen wundert's, wo doch GTK ursprünglich nur ein Toolkit für GIMP war. Wird viel zu selten von mir benutzt, aber wenn, dann nehmen die diversen offenen Fenster ohnehin mindestens einen kompletten Desktop ein, so dass die Fenster nicht unbedingt mir anderen harmonieren müssen.
• Multi Gnome Terminal, ein Terminalemulator mit Tabs. Liegt noch nicht als GTK2-Version vor und kann nur wenig mehr als konsole aus dem KDE-Projekt. Textschatten sind allerdings bei halbtransparenten Terminals nicht zu verachten, so etwas habe ich in konsole noch nicht gefunden.

Hier schrieb ich ja, dass mein DSL-Zugang nur noch mit dem kommerziellen EnterNet 300 funktioniete. Das hat mir natürlich keine Ruhe gelassen, und so habe ich gestern festgestellt, dass das nun auch wieder mit dem Roaring Penguin klappt. Ich kann mir wohl sparen, NGI darauf anzusprechen - man wird dort wieder behaupten, nichts verändert zu haben. Da freue ich mich doch lieber, dass ich meine Software nun wieder selbst wählen kann.