dapete bloggt

Das Kuratorium der Wikimedia Foundation hat mit Entscheidung vom 26. November die bisherige Beraterin (Management Consultant) Sue Gardner zum 1. Dezember zur Geschäftsführerin (Executive Director, wörtlich Geschäftsführende Direktorin) bestellt. Damit geht eine Suche zu Ende, die vor gut einem Jahr mit der Einrichtung eines Suchkomitees begann.

Neu ist die Aufgabe nicht: sie hat in den letzten Monaten deutlich mehr getan, als man von einem Berater erwartet. Trotzdem ist es sicher etwas anderes, offiziell so eine Aufgabe zu übernehmen. Ich wünsche Sue viel Erfolg.

Mittlerweile habe ich die Datendateien, und dabei leider festgestellt, das die Binärversion doch nicht funktioniert. Sie startet zwar, stürzt aber beim ersten Zugriff ab. Auch die build.sh will nicht so recht. Ich habe selbst rumprobiert, bevor ich diesen Kommentar zum ersten Blogeintrag zu diesem Thema gerade eben freigeschaltet habe. Ich hatte zwar ähnlich auch selbst Erfolg, aber Jan hat es gut aufgeschrieben. Meine eigener Entwurf für eine Anleitung unter Benutzer:Dapete/TntReader unter Gentoo Linux, die entgegen des Seitentitels auch für andere Distributionen sinnvoll sein dürfte, ist nur leicht verändert. Was zählt ist, dass es funktioniert.

Die gerade in neuer Version erschienene Wikipedia-DVD ist endlich auch unter Linux (und MacOS X) direkt nutzbar. Das Prinzip ist das gleiche wie bei der Windows-Version: man startet einen kleinen Webserver, der seine Informationen aus den .zeno-Dateien der DVD bezieht und dem Benutzer per Webbrowser in einer Umgebung präsentiert, die der Wikipedia ähnelt.

Das Programm, das unabhängig vom Windows-Programm ZenoReader entwickelt wurde, nennt sich TntReader. Auf der Mitgliederversammlung von Wikimedia Deutschland Ende Juni hatte Entwickler Tommi Mäkitalo eine noch nicht ganz fertige Version vorgestellt, und die war schon gut. TntReader basiert auf seinem Webserver-Framework Tntnet. Mitgeliefert wird eine vorkompilierte Version für Ubuntu 7.0.4/x86 und natürlich der Quellcode.

Der Versuch, das ganze selbst zu kompilieren, scheiterte bisher. build.sh brach beim Kompilieren von Cxxtools ab. Da ich Gentoo verwende, gibt es zumindest Cxxtools und Tntnet auch als Distributions-eigene Pakete. Die ließen sich installieren, hier klappte dann das Kompilieren des Readers selber nicht. Wenn ich Zeit finde, will ich nochmal gucken, was genau beim Kompilieren schiefgeht.

Schließlich habe ich die mitgelieferten Binaries verwendet. Allerdings muss ich TntReader wie folgt starten, sonst werden die Libraries nicht gefunden:

LD_LIBRARY_PATH="." ./TntReader

Wirklich testen konnte ich das ganze leider noch nicht, denn die Datendateien fehlen mir noch. 75 % sind fertig, der Rest kommt über Nacht (dauert mit DSL 1000 halt etwas länger).

Ich will nicht behaupten, dass ich das Problem bis ins letzte verstehe, aber Fakt ist: auf x86-Systemen ab 896 MB RAM hat man unter Linux ein Problem: HIGHMEM. Worum geht es?

Da es in der x86-Architektur nur 4 GB Adressraum gibt, muss man den irgendwie aufteilen. Linux benutzt dafür normalerweise eine Aufteilung namens 3G/1G: Jeder Prozess im Userspace kann 3 GB Speicher logisch ansprechen, der Kernel 1 GB. Der Kernel muss aber irgendwie auf den gesamten physikalischen Speicher zugreifen können: um das zu erreichen, wird von dem Speicher, der über 1 GB hinausgeht – HIGHMEM genannt –, immer nur ein Teil in den Kernel-Adressraum eingeblendet. Wer noch mit DOS gearbeitet hat, wird sich an EMS erinnern, das funktionierte im Prinzip genauso.

Bei 2.4er-Kerneln wurde bei 1 GB Speicher noch geraten, aus Geschwindigkeitsgründen lieber HIGHMEM komplett abzuschalten und nur 896 MB zu nutzen, als mit 128 MB HIGHMEM zu leben. Bei 2.6er-Kerneln soll das nicht mehr so schlimm sein, aber genaue Zahlen konnte ich nirgendwo finden. Hier muss jeder abwägen, ob er mit den Problemen (dazu später) leben kann.

Lösung

Seit Kernelversion 2.6.16 gibt es die Möglichkeit, diese Aufteilung zu ändern. Als Gentoo-Nutzer ist der Kernel eh selbstkompiliert, also kein Problem, auch wenn die Option gut versteckt ist. Man muss zunächst folgendes aktiviert haben:

General setup --->
[*] Prompt for development and/or incomplete code/drivers
…
[*] Configure standard kernel features (for small systems) --->
…

Dann kann man auch das hier einstellen:

Processor type and features --->
…
Memory split (…) --->
…

In diesem Unterpunkt hat man dann die Wahl zwischen den verschiedenen Aufteilungen (diese gibt es in 2.6.23):

• 3G/1G (896 MB ohne HIGHMEM),
• echtem 3G/1G (damit ist wirklich 1 GB ohne HIGHMEM möglich),
• 2G/2G (2 GB − 128 MB),
• „echte“ 2G/2G (2 GB) sowie
• 1G/3G-Aufteilung (3 GB − 128 MB ohne HIGHMEM).

Probleme

Ganz problemlos ist das ganze leider nicht. Hier eine Auflistung einiger Probleme, die ich gefunden habe:

• Die Größe von Prozessen ist, unabhängig von vorhandenem RAM oder Swap, auf den ersten Wert begrenzt. Bis zu den echten 2G/2G würde ich das mitmachen, aber 1G/3G könnte problematisch sein. Wer über 2 GB RAM hat, will wahrscheinlich auch Programme laufen lassen, die mehr als 1 GB belegen.
• Binärmodule, die für 3G/1G kompiliert wurden, funktionieren möglicherweise nicht. Der aktuelle proprietäre NVIDIA-Treiber ist allerdings davon nicht betroffen; wie das bei anderen Dingen aussieht, weiß ich nicht.
• Wine funktioniert nicht richtig. Ich hab es nicht genau recherchiert, da ich Wine eigentlich nicht brauche, aber soweit ich es verstehe, benutzt Windows normalerweise 3G/1G, und das simuliert Wine auch; ab Windows 2000 als Kompatibilitätseinstellung geht aber auch 2G/2G. Wenn man also nichts mit Wine laufen lässt, das nur unter simuliertem Windows 9x läuft, sollte es trotzdem gehen.

Links

• HighMemory (LinuxMM-Wiki) mit einigen allgemeinen und technischen Informationen (englisch)
• Feature: High Memory In The Linux Kernel (KernelTrap, Februar 2004) geht etwas tiefer (englisch)
• Linux: Using 1GB of RAM Without HighMem (KernelTrap, Januar 2006) beschreibt die Entstehung der Kerneloption (englisch)

Tim Bartel hat (blogtechnisch) ein Lebenszeichen von sich gegeben. Anders als ich hat er aber eine gute Ausrede: im OTRS ist immer was zu tun. Ich dagegen hätte eigentlich genug Zeit, und es gibt eigentlich auch immer mal wieder was zu berichten. Aber uneigentlich fehlt mir dann wieder die Lust. Dabei sind für mich sind dieses und die anderen Blogs, die im Planet Wikimedia gesammelt werden, ein gutes Medium, um auf wichtige Entwicklungen hinzuweisen. Wenn keiner was schreibt, bringt das natürlich nichts; also werde ich mich bemühen, da häufiger was beizutragen. Gerade zum Thema Wikimedia Foundation und der englischen Wikipedia wäre das recht einfach, denn ich lese die einschlägigen Mailinglisten und Diskussionsseiten eh.