I needed to get a list of MediaWiki page names of pages that contained a certain string (“needle”) from a MediaWiki XML dump. This is how I got it, using XMLStarlet:

xml sel -N mw=http://www.mediawiki.org/xml/export-0.3/ \
 -t \
  -m "/mw:mediawiki/mw:page/mw:revision/mw:text[contains(string(.), 'needle')]" \
  -n \
  -v "../../mw:title" wikiexport.xml \
| xml unesc

So, here we go:

Prerequisites:

• GIMP (I’m currently at version 2.6.8, but this will probably work with older versions as well)
• GraphicsMagick (tested with 1.3.8) or ImageMagick (tested with 6.5.8.8)

Procedure:

1. Get the scanned pages opened as layers of one image in GIMP. If they are available as files already, you can use File / Open as Layers….
2. Make sure that the layers are ordered in the following way: Page 1 must be the bottom layer, the last page must be the top layer. You can reorder them via the “Layers” dialogue (activate it via the Windows / Dockable Dialogues menu if you don’t see it)
3. Save As… and choose “MNG animation” or just add “.mng” to the filename. (In case you are wondering, MNG is the animated counterpart to PNG).
   A dialogue window saying “MNG plug-in can only handle layers as animation frames” will come up – choose “Save as Animation” here and press the Export button. In the next dialogue you don’t need to make any changes to the defaults, just press the Save button.
4. Now, open a console window and simply enter
   convert document.mng document.pdf

That’s it – you now have your PDF file ready for sending!

Update (2010-02-08):
As chithanh pointed out in comment 1, there is another convenient way to accomplish the same. It does not involve GIMP, but instead requires pdftk to concatenate PDF files. Please see comment 2 for details.

Update (2010-03-01):
And yet another way (definitely the most straight-forward one, if you have the pages as single image files already) was pointed out by goffrie in comment 5.

Today I found a solution that does not require JACK: Charles Eidsness’ ALSAEQUAL. This is how you get it working with MPD on Gentoo:

1. `emerge alsaequal`
2. Create an .asoundrc file in the home directory of the user that runs MPD on your system (see `grep "^user" /etc/mpd.conf`) with the following content:

   ctl.equal {
     type equal;
   }
   
   pcm.plugequal {
     type equal;
     slave.pcm "plug:dmix";
   }
   
   pcm.equal {
     # Or if you want the equalizer to be your
     # default soundcard uncomment the following
     # line and comment the above line.
   # pcm.!default {
     type plug;
     slave.pcm plugequal;
   }
   

   (copied from the ALSAEQUAL website – modified so that dmix is being used, which allows playing multiple audio sources simultaneously)

3. Find the audio_output section in your /etc/mpd.conf where you currently configure MPD to use ALSA’s default device. Change it so that it looks like

   audio_output {
     type    "alsa"
     name    "equal"
     device  "plug:plugequal"
   }
   

4. `/etc/init.d/alsasound restart && /etc/init.d/mpd restart`
5. Play a track with MPD, then run `alsamixer -D equal`. Modify any of the frequency band sliders and observe the effect.

Other applications will be unaffected by the equaliser, if you don’t change the .asoundrc according to the comment, and if you don’t configure them to use the ‘equal’ ALSA device.

Gut geschrieben und auf den Punkt gebracht. Ich werde hiermit sicher nicht das letzte Mal darauf verlinkt haben.

Here is a map from NASA’s website, I added the local time for Shanghai residents:

Hopefully it won’t be cloudy!

The documentation is not very clear about what “Guest SMP” really does – it could, for example, just show multiple CPUs to the guest, but still only use one host core. To make sure that my assumption of VirtualBox 3 actually making it possible to assign multiple host CPUs/cores to the guest, so that it can actually run faster, I did a quick test. I started by making one of my Linux VMs a dual CPU VM:

In the VM, I then started to build the Linux kernel, once with make -j1 and once with make -j2. This is my CPU usage monitor on the (2-core) host, which shows both cores’ usage combined:

In section 1 of the graph, only one compiler process is running (make -j1). At the end of section 1 I aborted the building process and (in section 2) I typed in make -j2. Thus, section 3 shows the CPU usage when two compiler processes are running simultaneously in the VM. So my assumption was correct, it is now possible to make all of the host’s processing power available in a VM.

Thanks, VirtualBox team! (I won’t address the company behind VirtualBox, since this would probably cause my post to be outdated before I can press the “Publish” button). Lets just hope that this great project will see further development, it is currently the best desktop virtualisation project available, in my opinion. It would be even greater if all of the functionality was available in the Open Source version though. This would ensure that, no matter what the current company behind VirtualBox decides to do with it, development could go on.

Da ich mich seit längerem im Ausland aufhalte, treffe ich viele Deutsch-Schreibende die auf amerikanischem Tastatur-Layout schreiben. Darunter sind (leider) auch viele Windows-Benutzer. Alle diese Personen umschreiben die Umlaute mit “oe”, “Oe”, “ss”, etc.

Also habe ich heute mal recherchiert, ob es nicht doch eine Möglichkeit gibt, diesen Personen zu Umlauten zu verhelfen. Die offensichtlichste Möglichkeit ist natürlich, auf Linux umzusteigen und meine .Xmodmap zu verwenden. Aber das ist eher etwas längerfristiges, und viele sind dafür einfach zu unflexibel…
Es gibt jedoch noch eine andere Lösung, dank der unter der GPL stehenden Software AutoHotKey. Ungewohnt schön (für Windows-Programm-Verhältnisse) an dieser Software ist, dass sie sogar einen “Compiler” mitbringt, der aus der Tasten-Mapping-Definition eine ausführbare Datei erstellt.

Die AutoHotKey Mapping-Definition (.AHK Datei), die zu meiner gewünschten Funktionalität führt, sieht so aus:

+#a::Ä
#a::ä
+#o::Ö
#o::ö
+#u::Ü
#u::ü
#s::ß

Sehr wichtig dabei ist, dass die Datei ANSI-codiert gespeichert wird, weil AutoHotKey wohl nichts mit Unicode anzufangen weiß. Wenn man sich allerdings (wie ich während meiner Recherche) auf einer Windows-Installation befindet, deren Non-Unicode program locale keine deutschen Umlaute im erweiterten ASCII-Bereich hat, ist das nicht sonderlich einfach zu bewerkstelligen. Man kann die Datei nicht ohne Weiteres mit Windows-Bordmitteln ANSI-codiert abspeichern, sofern man nicht die Locale auf Deutsch (oder irgend eine andere Sprache bei der die o.g. Umlaute im erweiterten ASCII-Bereich vorkommen) umstellt. Und danach ist natürlich Neustarten angesagt – wie könnte es auch anders sein…

Mit etwas Vertrauen in mich kannst du aber auch einfach meine umlauts.exe herunterladen, die ich mit AutoHotKey erstellt habe. Nach dem Ausführen befindet sich das AutoHotKey-Logo im System-Tray und man kann Umlaute wie oben beschrieben tippen. Ich habe keine Trojaner oder sonstige Schädlinge eingebaut (zumindest nicht wissentlich).

Update (2009-05-17): Es hat sich herausgestellt, dass diese ganze Sache in GTK-für-Windows-Anwendungen wie Pidgin nicht funktioniert. Ich habe nun einen Workaround gebastelt, der in Pidgin funktioniert – aber schön ist was anderes. Die AHK-Datei ist dadurch etwas länger geworden: umlauts.ahk

Die umlauts.exe habe ich aktualisiert.

Update (2010-03-12): Als (verspätete) Reaktion auf jan und Daniels Kommentare habe ich nun das Script umlauts.ahk verbessert, und auch eine neue umlauts.exe gebaut. Ich verwende weiterhin die [Windows]-Taste. AltGr ist keine Option, da es diese Taste auf vielen Tastaturen (z.B. US-Layout) nicht gibt.

That statement may be technically correct, since fragmentation is really rare with ext3 – but what about spatial locality of reference – files that are often accessed at nearly the same time being spread over the whole disk, thus causing long access times due to head positioning?
There is (AFAIK) no way to (programmatically) optimise / sort a Linux filesystem in a way that for example all init scripts, binaries, libraries, etc. reside in nearby sectors on a harddisk. Those tools do exist in the Windows world (built into those 3rd party defragmenters).

The only way to do this optimisation is “by hand”: make a backup, mkfs and restore the backup – but that’s something you only do when you have a lot of time, or when I/O finally got painfully slow.

One factor that probably plays an important role, is, that I usually only have one partition (+swap) that contains everything – etc, usr, usr/portage, var, home, …
With such a setup, after only a few months of updating the system, downloading stuff from the net, copying pictures from the DSLR to the harddisk, updating the system again, etc. will lead to all kinds of files being well spread throughout the whole disk. Imagine some init scripts and binaries they call still being at the “beginning” of the disk, some others, due to updates, at the “end”. And that’s what makes I/O slow… see for yourself:

From loading the kernel to KDM being ready for login on a

• fresh ext3 – 32 seconds
• rotten ext3 – 57 seconds

(sorry for the poor video quality)

That is an ~80% performance decrease.

How I got the videos:

1. Capture startup of my system stored on a months old ext3 partition
2. Backup (with dar)
3. mkfs.ext3
4. Restore
5. Capture startup of my system on a freshly made ext3 partition
6. Trim the videos so that frame 1 is the first frame on which kernel output is visible and the last frame is the first frame on which KDM shows the input widgets

Hoping that this situation will improve with ext4 – I heard online defragmentation will be possible at some point, and that probably also makes “sorting” the filesystem possible.

A while ago I stumbled on Pidgin bug report 5662 and thought that might be the bug we were encountering – but there were no efforts going on to fix the issue. It turned out to actually be GTK-on-Windows’ fault (thanks to David Grohmann for the analysis and bringing it to the attention of the GTK developers).

Now, “only” eight months after the bug had been reported, the issue has been fixed in GTK. The crashes on those workstations disappeared after bringing the new Pango libraries into place.