Ich plane ja einen Header in mein Blog einzupflegen; so in etwa wie hier. Allerdings nicht solche alten Bilder, sondern eher etwas ansehnlicheres. Inzwischen bin ich bei bing.com, dem Picture of the Day angelangt.

Lage prüfen

Wir gehen zunächst auf http://bing.de/ und werden auf http://bing.com/?cc=de weitergeleitet, denn wir kommen ja aus Deutschland. Dort sehen wir schon: das ist JavaScript-only. Nicht verzagen, Google fragen: Extract Bing.com Wallpapers. Genau das wollen wir haben. Sieht ziemlich einfach aus:

curl -s 'http://www.bing.com/?cc=de' | grep -oE '\\/fd.+\.jpg'
#  \/fd\/hpk2\/MachuPicchu_DE-DE609064060.jpg

Wenn wir davon die Backslashes entfernen, können wir damit prima auf das aktuelle Tagesbild zugreifen. Spätestens jetzt merkt man aber, dass der Vor und Zurück-Button natürlich auch in JavaScript implementiert ist...

Down Them All

An dieser Stelle war ich dann zunächst etwas ratlos und bin den üblichen Weg über Google gegangen: bing image archive. Gleich der erste Treffer sieht perfekt aus. Auflistung aller Bilder, wahlweise nach Nationen gefiltert, sehr leicht extrahierbar, da die Seitenlogik in PHP realisiert ist, und zwar über einfach zu editierende GET-Befehle.

Via grep lassen sich so einfach die Direktlinks herausfiltern - ausschließlich für DE-Deutschland:

curl -s 'http://www.istartedsomething.com/bingimages/' | grep -oE 'resize\.php\?i=[^.]+_DE[^.]+\.jpg&w=100'
#  resize.php?i=WorldExpo_DE-DE278223030.jpg&w=100
#  resize.php?i=Bratislava_DE-DE736008353.jpg&w=100

Der letzte URL-Parameter gibt an, dass das Bild noch verkleinert werden soll, wird der entfernt, kommen wir an das Originalbild heran. Da sich meine Kentnisse bei den ganzen unix-Tools in Grenzen halten, musste ich zu guter letzt ein kleines Python-Skript zusammenhacken, was alle Bildlinks für August 2009 bis Juli 2010 ausspuckt; natürlich wget-tauglich.

Dann kommt zum Schluss ein nettes wget -i links und schon haben wir über 300 Bilder (ca. 71 MiB) heruntergeladen!

import re
from urllib import urlopen

url = 'http://www.istartedsomething.com/bingimages/?m=%s&y=%s' # month, year

if __name__ == '__main__':

    for t in [(m+1,2010) for m in range(10)] + [(m+1,2009) for m in range(10)]:
        for line in urlopen(url % t):
            m = re.findall("resize\.php\?i=[^.]+_DE[^.]+\.jpg&w=100", line)
            if m:
                print '%s%s' % (url.split('?')[0], m[0].split('&')[0])

Ja, das muss sein. Teilweise ist KDE sowas von absolut sinnfrei konzipiert, das ist die sanft ausgedrückte Variante. Behindert „hat besondere Bedürfnisse“ trifft es aber besser.

Emailverschlüsselung mit KMail ist grundsätzlich schon einmal möglich (hey!), allerdings sollte man es sofort richtig einrichten. Denn sobald es ans Debuggen geht, darf man wieder von vorne anfangen. Denn KMail ist so freundlich, und ermöglicht einem das Debuggen von gpg, indem es einige Zeilen in die .conf bei gpg und dem gpg-agent schreibt. Natürlich wird dabei nicht nach Versionen unterschieden, wer könnte den auf die Idee kommen, dass Software sich ändert? Das wäre ja ein Unding!!1 Tja, Resultat ist, dass man nach dem Haken für Debugging erstmal die configs wieder reparieren und KDE einmal neustarten darf.

Weiter geht's zum Akregator: Das Teil ist wieder ein Paradebeispiel für: „ich kann so viel zusätzlich, aber ein Feedreader bin ich nicht.“ Ich bin der Ansicht, dass zumindest Feeds, die den Feed Validation Service bestanden haben, angezeigt werden sollten. Aber leider ist mir nicht möglich, ca. 10% meiner Feeds nicht zu abonnieren, weil das Teil einfach mal abstürzt. Aber hey, ich kann viel zusätzlich einstellen!

Akonadi-Server... schon der Name dieser Software klingt nicht gerade vertrauenswürdig. Problem an diesem Teil ist, dass der Personal Information Manager (PIM), also Kontact, in den nächsten Versionen immer mehr darauf aufsetzen wird um Kontakte und später sogar Emails zu speichern. Leider ist das Teil nicht zu konfigurieren, setzt auf eine MySQL-Datenbank auf, erwartet natürlich, dass die Tables schon existieren. Wenn man ein komplett neues Arch Linux installiert und dann direkt die gesamten KDE-Pakete samt Abhängigkeiten, nein dann funktioniert das natürlich nicht out-of-the-box. Das funktioniert nur in ganz wenigen Distributionen fehlerfrei. Und das soll Standard werden? Dazu gibt es außerdem eine schöne Knowledge-Base, die nicht einmal die zehn Fehler von meiner (vanilla) Installation enthält und trotzdem schon sehr lang ist: Akonadi 4.4: Troubleshooting

Wo könnte man die Ressourcen sinnvoller verschwenden? Zum Beispiel bei Konqueror... weder besteht der den acid3 noch ist der halbwegs schnell (selbst Firefox ist 100 Mal schneller, und das will was heißen). Aber viele unwichtige Features stehen bereit... das ist so eines der größten Probleme bei KDE:

Unzählige Zusatzfeatures, aber die Kernfunktion ist fehlerhaft.

Warum ich trotzdem weiterhin KDE nutze? Es gibt a) keine Alternative und b) einige Programme, die den ganzen Mist wieder gut machen: Kate, Dolphin, Kwin, und und und...

Da ich in den letzten Tagen sehr viele neue externe Module für meine Blogsoftware implementiert habe, bin ich immer häufiger auf das Problem gestoßen, dass Bibliotheken, wenn sie lokal installiert sind, nicht unbedingt fehlerfrei implementiert sind und deshalb die Pfad-Variable weitergesucht wird, bis der Interpreter bei meiner globalen Installation unter /usr angelangt ist und dann dieses Paket nimmt.

Da auf dem FTP-Server aber nicht jene Module global installiert sind, gibt es häufiger Überraschungen, dass mal wieder ein Modul nicht funktioniert. Das ganze zu Debuggen wird immer zeitaufwendiger...

pkgsrc

Meine Idee ist, dass man ja Software an ein bestimmten Pfad gebunden kompilieren kann (per --prefix=/usr) und es vielleicht ganz nützlich ist, sich nochmal innerhalb des eigenen Nutzerverzeichnisses ein root aka / zu bauen, auf dem ich als normaler Nutzer auch "root"-Rechte habe. pkgsrc ist solch ein nützliches Tool.

pkgsrc eine Paketverwaltung, ursprünglich von NetBSD, inzwischen aber für zahlreiche andere Plattformen portiert, die sowohl als grundständige Paketverwaltung z.B. in Verbindung mit apt-get oder eben als lokale Paketverwaltung mit normalen Rechten arbeitet. Dabei werden Abhängigkeiten automatisch gelöst und Software fast so komfortabel wie bei apt-get oder pacman heruntergeladen und installiert.

Derzeit umfasst das Repository 9154 Pakete, die hier gelistet sind. Pakete können dabei vorkompiliert (Binärpakete) oder von Source installiert werden.
Die Pakete werden dabei ähnlich wie in einem Rolling-Release-System ständig aktualisiert, allerdings gibt es die Möglichkeit, einen Software-Freeze zu installieren, ähnlich wie bei Debian oder Ubuntu, wo nur noch Sicherheitsaktualisierungen nachgefliefert werden.

• pkgsrc - offizielle Seite
• pkgsrc - Dokumentation
• FAQ

Alternativen

Auf meiner Recherche bin ich erstmal am englischen Wikipedia-Eintrag zur Paketverwaltung hängen geblieben, und habe das als Ausgangspunkt für meine Recherche genommen.

Viele weitere Alternativen zu pkgsrc habe ich aber nicht gefunden:

• ipkg und dessen aktiver Fork opkg
  Leider so spärlich dokumentiert, dass ich nicht einmal eine Features-Liste finden konnte.
• OpenPKG unter http://www.openpkg.org/
  sieht sehr vielversprechend aus, wenn auch die Softwareauswahl mit 1500 Paketen etwas klein erscheint.

Beispiel: Installation von Python im Home-Verzeichnis

Bei der Installation habe ich mich für die Pfade ~/pkgsrc als Wurzelverzeichnis und ~/net als Installationsverzeichnis für die pkgsrc-Komponenten (Repository usw.) entschieden.

Installation von pkgsrc

pkgsrc kann über einen Tar-Ball oder über CVS bezogen werden. Ich habe mich für CVS mit den aktuellsten Software-Releases entschieden:

$ cd ~
$ env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout net

#resultiert in ca. 650 MiB Daten

$ ls net/
archivers/   comms/       doc/          geography/    Makefile     net/        README      textproc/
audio/       converters/  editors/      graphics/     math/        news/       regress/    time/
benchmarks/  cross/       emulators/    ham/          mbone/       packages/   security/   wm/
biology/     CVS/         filesystems/  inputmethod/  meta-pkgs/   parallel/   share/      www/
bootstrap/   databases/   finance/      lang/         misc/        pkglocate*  shells/     x11/
cad/         devel/       fonts/        licenses/     mk/          pkgtools/   sysutils/
chat/        distfiles/   games/        mail/         multimedia/  print/      templates/

Als nächstes muss nun unser lokales root eingerichtet werden:

$ ./bootstrap --workdir ~/pkgsrc --prefix ~/pkgsrc/usr --pkgdbdir ~/pkgsrc/var/db \
  --sysconfdir ~/pkgsrc/etc --varbase ~/pkgsrc/var --unprivileged

Das dauert eine Weile und richtet unter ~/pkgsrc etwas ähnliches wie unter / ein. Mit dazu wird eine Abwandlung von make installiert: bmake. Das liegt in ~/pkgsrc/bin/ und dient zum Bauen und Installation der Software.

Da sich unser lokales root noch nicht in unseren Pfad-Variablen befindet, es aber auch nicht von Vorteil ist, gleich alles unter ~/pkgsrc/bin hinzuzufügen, habe ich mir einen Alias geschaffen: alias bmake=~/pkgsrc/bin/bmake

Das war's soweit. Wir haben nun ein lokales root aka / und einen lauffähigen Paketmanager.

Installation von python

Wenn man sich das Verzeichnis-Listing von ~/net oben anschaut, so kann man gut erkennen, dass es eine ähnliche Struktur wie bsw. das Software-Repository von portage hat. Über find . | grep keyword kann relativ komfortabel nach Software gesucht werden.

Python befindet sich in z.B. lang/python26/. Die Installationsroutine ist sehr simpel:

$ cd ~/net/lang/python26
$ bmake
#Abhängigkeiten werden aufgelöst, Pakete lokal kompiliert
$ bmake install

#Cleanup der Sources
$ bmake clean
$ bmake clean-depends

Schon ist python installiert und kann über ~/pkgsrc/usr/bin/python2.6 aufgerufen werden und hat keine externen Module oder Bibliotheken installiert - absolut keine!