Posts Tagged ‘ Software

Gloobus

Ein sehr interessantes Projekt, auf dass ich kürzlich gestoßen bin ist Gloobus, hier insbesondere die Preview-Komponente:

Photo betrachtet in der Gloobus Preview

Erklärtes Ziel dieses Projektes ist es, eine allgemeine Vorschau für Daten aller Art zu implementieren. Besonderes Augenmerk wird hierbei auf die Geschwindigkeit gelegt, denn einer langsamer Start ist ein KO-Argument für eine Vorschau. Dazu gesellt sich noch eine äußerst ansprechende Erscheinung, die laut Beschreibung sogar anpassbar sein soll.

Bei einigen kurzen Tests erwies sich die Vorschau als recht gut benutzbar, auch wenn sie bei hochauflösenden Bildern ähnlich langsam ist wie allgemeine Bildbetrachter wie Ristretto im Vergleich zum hier sehr schnellen Gthumb. Möchte man die jeweilige Datei genauer unter die Lupe nehmen, gibt es einen Vollbildmodus, möchte man sie bearbeiten eine entsprechende Schaltfläche dafür. Schlau ist auch die automatische Anzeige von Album-Cover beim Abspielen von Audio-Dateien.

Ein guter Schritt in die richtige Richtung, nur würde ich mir wünschen, dass die Vorschau automatisch beim Hovern von Dateien aktiv wird. Natürlich verbunden mit einer konfigurierbaren Wartezeit, falls man doch einmal nicht möchte, dass ein 1080p-HD-Video mit einer entsprechenden Dateigröße geladen wird.

Opera ist genial

Ich ging bisher davon aus, dass ich aufgrund meiner doch schon sehr langen Nutzung mittlerweile sämtliche Geheimnisse im Opera-Browser ergründet habe. Und immer wieder gelingt es ihm, mich vom Gegenteil zu überzeugen.

Heutiges Beispiel? Ich versuchte, Thunderbird als als Empfänger für mailto-Links einzurichten. Ein einfaches /usr/bin/thunderbird --compose genügt hier aber natürlich noch nicht, da die Bezugsadresse fehlt. Also versuchte ich, die erforderlichen Platzhalter zu finden, welche Opera durch die entsprechenden Textteile ersetzt. Ich stieß zwar auf eine Dokumentation einiger Platzhalter, doch sind diese nur für die Verwendung in Buttons brauchbar, welche beliebig in die Oberfläche integriert werden können. Bei meinen Experimenten damit fuhr ich mehr oder weniger absichtlich mit der Maus über das Eingabfeld und dies bekam ich zu sehen:

Schön, wenn jemand mitdenkt.

Debian-Repository eingerichtet

Ich habe nun unter http://download.noctus.net/debian/ ein Debian-Repository für meine selbstgebauten Pakete eingerichtet. Momentan sind dort folgende Pakete verfügbar:

Folgende Zeile gehört in die /etc/apt/sources.list, wenn ihr meine Pakete nutzen wollt:

deb http://download.noctus.net/debian unstable/

Kompiliert habe ich sie unter Debian Sid, ihre Lauffähigkeit auf anderen Debian-Zweigen kann ich somit leider nicht garantieren. Um die Warnungen APTs aufgrund des unsignierten Repositories zu unterbinden, kann folgender Befehl ausgeführt werden:

wget http://noctus.net/0x77B0B098.pub.asc -O - | apt-key add -

Damit wird mein öffentlicher Schlüssel dem APT-Schlüsselbund hinzugefügt. Nähere Informationen hierzu finden sich im Debian Wiki.

Ich teste die Pakete auf meinem eigenen System recht ausgiebig und nutze sie auch alltäglich, dennoch kann ich Fehlfunktionen auf anderen Systemen nicht ausschließen, daher geschieht die Nutzung meiner Pakete auf eigene Gefahr.

Thunderbird auf Mailinglisten

Hinweis an Debian–Nutzer: seit Version 1.5.0.5-1 wurde dem Thunderbird–Paket seitens der Maintainer der Reply–To–List–Patch hinzugefügt. Meine Pakete sind damit obsolet und werden nicht mehr aktualisiert.

Seit einiger Zeit verfolge ich die Aktivitäten auf manchen Mailinglisten wie z. B. der „Debian User German“-Mailingliste. Da ich auch hin und wieder antworten möchte, war ich, wie wohl die meisten Thunderbird-Nutzer, gezwungen, entweder die „Antworten“-Funktion zu verwenden und die E-Mail-Adresse zu korrigieren oder aber die Privatadresse des Empfängers bei der „Allen Antworten“-Funktion zu entfernen.

Der Grund dafür ist, dass Thunderbird keine Möglichkeit bereitstellt, direkt auf die E-Mail-Adresse zu antworten, welche im List-Post-Mailheader enthalten ist. Dieser Mailheader legt im Allgemeinen fest, auf welche E-Mail-Adresse zu antworten ist, um direkt in die Mailingliste zu posten.

Angenervt von der Tatsache, dass der Umgang mit Mailinglisten im Thunderbird deshalb ziemlich umständlich ist und ich auch schon versehentlich eine E-Mail direkt an einen Poster geschickt habe, begab ich mich auf die Suche nach einer Lösung für dieses Problem. Und ich wurde fündig: Reply To List Thunderbird Extension.

Der Haken an dieser Erweiterung für Thunderbird ist jedoch, dass sie ein wenig tiefere Eingriffe in den Quellcode des Mailclients erfordert, da sie auf einige Funktionen zugreift, welche sich noch nicht in den offiziellen Quellen des derzeitigen Thunderbird-Entwicklungszweiges befinden. Der dafür erforderliche Patch ist nicht sonderlich umfangreich und deshalb erstaunt es umso mehr, dass der zugehörige Bugreport erst sechs Jahre nach Eröffnung geschlossen wurde.

Die Zeit bis zur Veröffentlichung von Thunderbird 3.0 wollte ich nicht abwarten, also lud ich mir mit Hilfe meiner Paketverwaltung die erforderlichen Quelldateien herunter, wandte den Patch an und baute mir frische und installierfertige Pakete. Diese wurden natürlich sogleich installiert, um die erforderliche Erweiterung ergänzt und für funktionstüchtig befunden. Mir steht nun also die gewünschte „An die Liste antworten“-Funktion zur Verfügung, welche das Arbeiten mit Thunderbird wieder etwas komfortabler macht.

Um anderen diesen Aufwand zu ersparen, stelle ich die von mir erstellten Pakete in meinem Repository zur Verfügung.

Ade, ATI-Treiber!

Ich wechselte bereits vor einiger Zeit vom offiziellen ATI-Treiber („fglrx“) zu seinem freien Pendant („radeon“) und bin damit bis auf einige Dinge auch recht zufrieden. Der Treiber ist im Gegensatz zum offiziellen Treiber sehr stabil und erlaubte mir nun auch erstmalig, die Composite-Erweiterung des X-Servers zu nutzen.

Bedauerlicherweise stand mir hier bis jetzt kein Direct Rendering zur Verfügung, was zur Folge hatte, dass sämtliche die Grafik betreffenden Berechnungen nicht direkt von meiner Grafikkarte durchgeführt werden konnten. Doch dies hat sich heute geändert. Das tägliche Systemupdate meiner Debian-Sid-Installation brachte heute die Mesa-Bibliotheken in Version 6.4.2-1 mit sich und nachdem ich im Bugtracker keine Release-kritischen Fehler finden konnte, welche mich betroffen hätten, aktualisierte ich die Bibliotheken.

Nun, nachdem ich mein System einmal neu gestartet hatte, um einige Dinge unter Windows zu erledigen, wollte ich einmal nachschauen, was mir die Aktualisierung gebracht hat und führte glxinfo aus:

ashura@core2:~$ glxinfo
name of display: :0.0
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 456 TODO - double side stencil !
***************************************************************************
No ctx->FragmentProgram._Current!!
display: :0
screen: 0
direct rendering: Yes

Erst traute ich meinen Augen nicht und vergewisserte mich deshalb mit Hilfe von glxgears:

ashura@core2:~$ glxgears
5304 frames in 5.0 seconds = 1060.651 FPS
5326 frames in 5.0 seconds = 1065.156 FPS
5335 frames in 5.0 seconds = 1066.958 FPS
5343 frames in 5.0 seconds = 1068.417 FPS
5332 frames in 5.0 seconds = 1066.281 FPS

Zugegeben: der freie Treiber ist halb so schnell wie der offizielle, aber dies kann sich in Zukunft ja noch ändern.

Der aktuelle Entwicklungszweig von Mesa ist nun also in die offiziellen Pakete eingeflossen, womit mir nun endlich Direct Rendering zur Verfügung steht, was mir bisher nur die offiziellen Treiber ermöglichten.

Jetzt kann ich also auch endlich gänzlich auf ATIs Treiber verzichten, womit mein System gleich ein ganzes Stück sauberer wird. Und in Kombination mit meinem Wechsel des X-Servers zum modularen Zweig vor einiger Zeit ist mein System nun bestens gewappnet für nützliche Verschönerungen wie Xgl und AIGLX.

QEMU die Zweite

Angesichts der doch recht trägen Bedienbarkeit des per QEMU emulierten Windows-Systems spielte ich hin und wieder mit dem Gedanken, die Leistungsfähigkeit mit Hilfe des KQEMU-Kernelmodules zu verbessern. Doch die scheinbar komplizierte Kompilierung und Einbindung in mein System schreckte mich immer wieder ab. Zumindest bis vor ein paar Tagen, als ich beschloss, es erneut zu versuchen; die extrem niedrige Geschwindigkeit des Windows-Systems machte es einfach nahezu unbenutzbar.

Meine Suche nach vorgefertigten Paketen für meine Paketverwaltung verlief erfolglos, also machte ich mich daran, alle erforderlichen Schritte mit Hilfe des Quellcodes durchzuführen. Meine Suche führte mich zuallererst zu einem Blogeintrag bei Geek Pit. Das dort beschrieben Vorgehen führte aber leider nicht zum Erfolg, QEMU ließ sich nicht kompilieren und quittierte mit einer nicht sonderlich hilfreichen Fehlermeldung (welche mittlerweile in meinem Kommentar zu diesem Blogeintrag nachlesbar ist). Bei meiner Suche danach stieß ich neben einigen erfolglosen Diskussionen in Mailinglisten auf Nando Florestans „Installing KQEMU in Ubuntu“. Das dortige Script erschien mir, nachdem ich es mir zu Gemüte geführt hatte, recht brauchbar. Wie die Kommentare unter dem Beitrag aber zeigen, ist es noch fehlerbehaftet, weshalb ich es ein wenig überarbeiten und an mein System anpassen musste. Die fertige Fassung stelle ich hier zur Verfügung. Besonders nützlich an dem Script ist, dass es für den Kompiliervorgang kurzzeitig den aktuell installierten GCC (GNU Compiler Collection) umbenennt und eine gleichnamige symbolische Verknüpfung auf den alten GCC 3.x anlegt. Damit greift make auf diesen zu, womit sich QEMU kompilieren lässt. Ein weiterer Fehler ließ sich beseitigen, indem ich die aktuelle Version von checkinstall installierte, welche sich noch nicht im Repository meiner Paketverwaltung befand. Dieses Programm hat die nette Eigenschaft, dass es ein mit meiner Paketverwaltung installierbares und verwaltbares Archiv erzeugt.

Nachdem QEMU und KQEMU nun erfolgreich kompiliert, installiert und im Falle von KQEMU an die richtige Stelle verschoben wurden, wollte ich das Kernelmodul per modprobe laden. Murphys Gesetz folgend verlief aber auch dies nicht erfolgreich; ich erhielt ein „FATAL: Error inserting kqemu Invalid module format“, was sich darauf begründet, dass das mit dem GCC 3.x kompilierte Kernelmodul nicht in meinen per GCC 4.x kompilierten Kernel geladen werden kann. Meine Suche danach führte mich zu diesem hilfreichen Beitrag im QEMU-Board. Ich folgte dem dort beschriebene Vorgehen, kompilierte KQEMU mit meinem aktuellen GCC erneut und verschob das Modul in das erforderliche Verzeichnis. Damit konnte ich das Kernelmodul schließlich erfolgreich laden. Ich legte die KQEMU-Gerätedatei /dev/kqemu mit den erforderlichen Zugriffsrechten an und startete mein Windows-System per QEMU.

Und es hat sich gelohnt: die Geschwindigkeit ist massiv gestiegen und macht das System nun erstmalig wirklich benutzbar. Natürlich ist das emulierte System langsamer als ein physikalisch installiertes, doch für Testläufe und dergleichen reicht es allemal. Ein weiterer Nebeneffekt machte sich kurz darauf auch bemerkbar: Töne des Windows-Systems wurden nun auch endlich ausgegeben. Mir war zuvor noch nicht bewusst, dass hierfür SDL (Simple DirectMedia Layer) erforderlich ist. Das Windows-System läuft nun also genau so wie vorher, nur weitaus schneller und mit Tonausgabe.

Angesichts der Tatsache, dass QEMU zwangsläufig mit dem GCC 3.x kompiliert werden muss, verzögerte sich das ganze Vorhaben beträchtlich aber unlösbar war es letztendlich dennoch nicht.

Neues Spielzeug: QEMU und IE 7

Da es mich immer mehr nervte, für Arbeiten unter Windows mein Debian-System herunter- und Windows hochfahren zu müssen, habe ich mich nun endlich einmal durchgerungen, mich mit QEMU zu befassen.

QEMU ist ein vollwertiger System-Emulator, mit dessen Hilfe man beliebige Systeme in virtuellen Maschinen unter GNU/Linux, Windows und Mac OS X laufen lassen kann. Doch im Gegensatz zum bekannteren VMWare ist QEMU freie Software, das heißt, dass man sich die Quellen herunter laden, sie studieren und auch – die entsprechenden Programmierkenntnisse voraus gesetzt – modifizieren um sich angepasste Versionen zu erstellen.

Die Installation verlief unter meinem Debian-System gewohnt einfach. Ein einfaches apt-get install qemu genügte, um den Emulator sofort betriebsbereit installieren und einrichten zu lassen. Als nächstes musste ein Festplatten-Image für mein künftiges Windows-Gastsystem her, was wiederum mit qemu-img create winxpsp2.img 2G schnell erledigt war; damit hatte ich nun binnen weniger Augenblicke ein unformatiertes, 2 Gigabyte großes Festplatten-Image erstellt. Die Einbindung meiner physisch vorhandenen Laufwerke stellte sich zuerst als schwierig heraus, doch nach dem ich das QEMU-Tutorial im Ubuntuusers Wiki gelesen hatte, war auch dies kein Problem mehr. Ein noch viel ausführlicheres Tutorial findet sich in Form dieses Threads zu QEMU bei linuxforen.de; dort werden so gut wie alle aufkommenden Fragen beantwortet.

Als Nächstes folgte nun die Installation des Windows-Gastsystemes. Hierfür habe ich – wie bei meinem tatsächlichen Windows-System auch – ein angepasstes Setup verwendet, welches ich vor längerer Zeit per nLite erstellt hatte. Damit lässt sich das zu installierende System bereits vor der Installation an die eigenen Bedürfnisse anpassen; die Einstellmöglichkeiten sind umfangreich. Ohne Probleme konnte die Installation abgeschlossen werden und es folgte der große Moment: Windows startete.

Nach einigen kleineren nachträglichen Anpassungen hatte ich nun also ein vollständiges Windows-System, welches – natürlich nicht so schnell wie mein tatsächliches Windows-System – als Gastsystem unter Debian lief. Wirklich bemerkenswert einfach verlief die Einrichtung der Netzwerkverbindung, welche es dem Gastsystem ermöglichen sollte, auf das Internet zuzugreifen; mit einem einfachen -net nic -net user war dies im Handumdrehen erledigt.

Fortan startete ich dieses Gastsystem nur noch mit der Option -snapshot, welche QEMU veranlasst, jegliche Änderungen am (Datei-)System des Festplatten-Images lediglich temporär durchzuführen. Sofern man nicht im QEMU-Monitor (welche per Strg + Alt + 2 erreichbar ist) den Befehl commit ausführt, werden alle Veränderungen beim Beenden des Gastsystemes verworfen.

Der eigentliche Anlass dieses Vorhabens war jedoch hauptsächlich eines: die Installation der derzeitigen Beta 2 Preview des Internet Explorer 7. Nach dem der Eindruck der ersten Beta-Version für viele eher nüchtern war, versprach diese Version nun erstmalig auch wirkliche Ver(schlimm)besserungen unter der Haube. Viele Rendering-Bugs sollten behoben und einige neue Features hinzugefügt worden sein.

Um den IE 6 weiterhin parallel nutzen zu können, verließ ich mich nicht auf die Installation, sondern kopierte den Inhalt aus dem im Stammverzeichnis temporär entpackten Setup-Archiv in ein anderes Verzeichnis und brach das Setup ab. Ein wenig später erfuhr ich, dass man aber ebenso einfach das Setup mit einem Archivprogramm öffnen kann, um an dessen Inhalte zu gelangen.

Abschließend benannte ich nur noch die shlwapi.dll um und erstellte die aus den Standalone-Paketen des IE bekannte leere iexplore.exe.local-Datei; damit konnte ich den IE 7 nun starten. Eine alternative Methode besteht unter Nutzung des IE7 Standalone Launch Script. Ich ließ mich nicht von der veränderten, Windows Vista-inspirierten Oberfläche beirren sondern rief einige erste Seiten auf, um die tatsächlichen Verbesserungen heraus zu finden.

Mein bisheriger Eindruck bestätigt meine Erwartungen: der IE hat offenbar einiges dazu gelernt (alphatransparente PNGs werden nun offenbar korrekt unterstützt, die Pseudoklasse :hover wird nun auch bei nicht-Links interpretiert), aber vieles fehlt noch. So fehlt merkwürdigerweise die Unterstützung für einige andere der Pseudoklassen, die min-* und max-*-Eigenschaften sind noch immer nicht implementiert, obwohl sie wirklich nötig wären. Die Interpretation von fehlerhaftem Code wurde dagegen offenbar minimiert, was darin resultiert, dass nun diverse Hacks nicht mehr funktionieren.

Fazit: Allzu viel hatte ich nicht erwartet und dementsprechend bin ich von den neuen Rendering-Fähigkeiten auch nicht allzu enttäuscht. Ein wirkliches Urteil werde ich mir wohl frühestens bei Erscheinen der Beta 2 bilden. Bis dahin hat das Entwicklerteam des IE noch einiges zu tun und ich hoffe, dass so viel wie möglich ausgebessert wird. Zudem sollte der IE nun beständig weiter entwickelt werden, sofern Microsoft noch etwas am Marktanteil des IE liegt. Die Alternativen sind vielfältig und schon seit längerer Zeit dem IE in vielen Bereichen voraus.

Immerhin hat mir das ganze ein „Sandbox“-System beschert, mit dem ich nun nach Belieben experimentieren kann, ohne mein tatsächliches Windows-System zu gefährden.

Der Kampf mit den ATI-Treibern

Ich befasse mich nun schon eine beachtliche Zeit lang mit meinem Debian-System und arbeite aktiv damit. Nach und nach gelingt es mir, einen weiteren Schritt zur vollen Nutzbarkeit der Geräte an und in meinem Rechner zu tätigen. Heute wollte ich mich (erneut) mit der 3D-Beschleunigung befassen.

Zu meinem „Glück“ steckt in meinem Rechner eine Sapphire Radeon 9600 Atlantis und Grafikkarten mit Chips von ATI (bzw. die Treiber dafür) haben den Ruf, sich – im Gegensatz zu mit NVIDIA-Chips bestückten Grafikkarten – etwas „schwierig“ in GNU/Linux-Systeme zu integrieren. Aber nichtsdestotrotz wollte ich es nun (erneut) versuchen; warum sollte ich auf die 3D-Beschleunigung verzichten, nur weil ich ein Nicht-Windows-System nutze? Also frisch ans Werk.

Ich begann meine Suche nach einer kurzen Suche auf der ATI-Supportseite in der Treibersektion, wurde schnell fündig und konnte die Linux-Treiber für meine Grafikkarte herunterladen. Zuallererst habe ich es mit dem Installer versucht, welcher augenscheinlich ordnungsgemäß alle erforderlichen Dateien einrichten konnte. Im Anschluss daran musste ich nur noch fglrxconfig ausführen, um die Konfigurationsdatei für meinen X-Server, xorg.conf auf den neuesten Stand zu bringen. Damit sollte die Einrichtung abgeschlossen sein und ich mich eines Debian-Systemes mit 3D-Beschleunigung erfreuen können. Sollte. Nach dem obligatorischen Neustart war vom neuen Treiber nichts zu spüren. Die Testtools glxgears und glxinfo spuckten nach wie vor ärmliche Ergebnisse aus:

ashura@core2:~$ glxgears Xlib: extension "XFree86-DRI" missing on display ":0.0".
1638 frames in 5.0 seconds = 327.600 FPS
1488 frames in 5.0 seconds = 297.600 FPS
1612 frames in 5.0 seconds = 322.400 FPS
1388 frames in 5.0 seconds = 277.600 FPS
1488 frames in 5.0 seconds = 322.400 FPS

Soviel also zum offiziellen und einfachen Weg.

Angesichts dieses Misserfolges stellte ich meine alte xorg.conf wieder her und begab mich wieder in Richtung Suchmaschine. Nach längerer Suche stieß ich schließlich auf dieses sehr gute Tutorial für die ATI-Treiberinstallation. (Die Site ist offenbar seit einiger Zeit offline. Ich habe daher aus dem Google-Cache ein Backup des Tutorials erstellt.) Da ich einen 2.6er-Kernel verwende, kam für mich der entsprechende Installationsweg auf dieser Seite in Frage, welcher – zu meinem Erstaunen – angenehm kurz zu sein schien.

Nach dem ich also die erforderlichen Kommandos in der Konsole ausgeführt hatte, wurde mir ständig die gleiche Fehlermeldung präsentiert:

ATI module generator V 2.0 ==========================
kernel includes at /usr/src/linux/include not found or incomplete
file: /usr/src/linux/include/linux/version.h

Nach dem ich nun also wieder unseren liebsten Freund – die Suchmaschine – gequält hatte, fand ich heraus, dass ich die Kernel-Header meines aktuellen Kernels benötigte. Ich zweifelte jedoch schon fast an meinem Verstand und meinen Suchmethoden, als ich diese nirgends auftreiben konnte. Wieder nach einigem Suchen stieß ich dann aber auf den erlösenden Befehl: apt-get install linux-headers-`uname -r`. (Der Unterbefehl uname -r spuckt hierbei die Version des aktuell laufenden Kernels aus.) Damit konnte ich nun (endlich!) die Kernel-Header installieren. Dass ich bei meiner Suche nach „kernel-headers-2.6.12“ nicht erfolgreich war, verwunderte mich nun nicht mehr sonderlich.

Nachdem ich nun noch eine auf das eigentliche Kernel-Header-Verzeichnis deutende symbolische Verknüpfung namens „linux“ unter /usr/src angelegt hatte, um den ATI module generator zufrieden zu stellen, führte ich erneut oben erwähnte Kommandos zur Kompilierung des Treibermodules aus. Es folgte also das altbekannte fglrxconfig und meine xorg.conf war wieder auf dem neuesten Stand. Danach folgte der Neustart und die ersten nervösen Momente beim Starten des Systemes. Der X-Server gab keine Fehlermeldung aus, Auflösung und Farbtiefe waren unverändert und mein Window-Manager wurde wie gewohnt gestartet. Nun also der spannende Moment; ich führte glxgears aus:

ashura@core2:~$ glxgears
11883 frames in 5.0 seconds = 2376.600 FPS
12929 frames in 5.0 seconds = 2585.800 FPS
12946 frames in 5.0 seconds = 2589.200 FPS
12947 frames in 5.0 seconds = 2589.400 FPS
12947 frames in 5.0 seconds = 2589.400 FPS

Ungeachtet dieser mehr als erfreulichen Ausgabe führte ich nun dennoch zusätzlich glxinfo aus:

ashura@core2:~$ glxinfo | grep "direct rendering"
direct rendering: Yes

Und was soll ich nun noch groß sagen, außer: „Es funzt™!“

Zugegeben: die Installation war lang und steinig, aber dafür bin ich nun recht froh, alles selbst gemacht zu haben und ich dieses Wissen sammeln konnte. Meiner Meinung sollte ATI hier aber noch einiges in Bezug auf die einfache Installation der Treiber und damit einher gehend die Bedienerfreundlichkeit verbessern, wenn ihnen die GNU/Linux-Nutzer nicht gänzlich egal sind.

IEs4Linux

Zwar habe ich bis jetzt meinen Umstieg auf Debian GNU/Linux in keiner Weise bereut, aber hin und wieder fehlen ein paar Kleinigkeiten, die mich zum Booten meines Windows-Systemes bewegen könnten.

Dass gute PC-Spiele hauptsächlich für Windows entwickelt werden, ist landläufig bekannt. Damit komme ich recht gut klar, da ich sowieso sehr selten am PC spiele. Lästiger dagegen ist die Tatsache, dass in einem browserübergreifenden Test eines Website-Layouts oder eines anderen Webprojektes zwangsläufig auch der IE mit einbezogen werden muss.

„Dafür gibt es doch WINE!“ werden jetzt einige sagen und sicher können damit sehr viele native Windows-Applikationen unter einem GNU/Linux-System ausgeführt werden.

Meine lokalen IEs habe ich damit jedoch nicht ausführen können, also habe ich mich auf die Suche nach einer Alternative gemacht. Und ich bin fündig geworden: Sérgio Lopes’ „IEs 4 Linux“-Projekt ermöglicht mir nun nicht nur den aktuellen IE 6.0, sondern zudem auch noch den IE 5.5 und den IE 5.0 unter Debian zu nutzen.

Für die Ausführung wird aber dennoch WINE benötigt. Die Installation der IEs ist kinderleicht und ist ausreichend auf der Projektseite dokumentiert. Ich habe lediglich nach der Installation den Inhalt des neu erstellten ~/bin-Verzeichnisses nach /usr/bin verschoben, so dass ich die IEs nun überall schnell aufrufen kann.

„IEs 4 Linux“ ist meiner Meinung nach ein bemerkenswertes Projekt, was sich jeder unter einem GNU/Linux-System arbeitende Webentwickler und -gestalter einmal zu Gemüte führen sollte.

Nachtrag: Selbst die Conditional Comments werden von jeder dieser IE-Versionen korrekt interpretiert und umgesetzt, was selbst unter Windows-Systemen nicht ohne größeren Aufwand möglich ist.