Das offizielle Blog der h8u.de Gemeinde

Historically I've had a “love-hate” relationship with Apple. They love themselves and I hate them.

-- Jeremy Allison

Heute gibt es mal wieder ein Howto über eine Bastelei, die ein bisschen von hinten durch die Brust ins Auge geht. Aber was will man auch erwarten, wenn es um Hard- und Software von Apple geht? Ich habe einen Mac Mini der ersten Generation, die einen Intel-Prozessor beherbergt. Zugelegt habe ich ihn mir, um die ganzen Programme, die ich so in Qt runterhacke, auch vorkompiliert für den Mac anbieten zu können. Ich bin halt ein echter Freund von Multi-Plattform-Programmierung.

Um mit meinem Rechnerzoo auch "mal so eben schnell" etwas anderes machen zu können, gibt es bei mir einen PXE-Server, der dafür sorgt, dass auch ohne Festplatte über Netzwerk gestartet werden kann. Dies ist besonders praktisch, wenn mal wieder gerade was nicht so klappt, wie es eigentlich gedacht war. Mittlerweile kann das jeder PC mit einer Netzwerkkarte, nur die Apple-Möhren können das nicht. Apple hat sich das was proprietäres eigenes ausgedacht, um ein Mac OS auch per Netzwerk starten zu können. Aber ich will ja gar kein Mac OS X über das Netzwerk laden, sondern meistens ein Linux, und das geht bisweilen nicht. Als ich damals im Internet danach suche habe, habe ich nur Hilferufe von anderen Nutzern gefunden, aber keine Lösungen.

Good evening ladies and gentlemen, this is your Flugzeugführer speakin'. We welcome you aboard of Cash & Flight Airways on our flight through the night. Ich gebe nur das Motto aus: "Wind um die Nase und Sturm in der Hose!"

-- Falco, "Qué Pasa Hombre"

Eines der Teilprojekte meines Hauptbetätigungsfeldes außerhalb der Firma ist ein Programm namens "Notorious" mit der ich die Datenbank der FreeDB durchsuchen kann. Die FreeDB ist eine von Internet-Usern zusammengetragene Liste der Titellisten von CDs. Was da an Daten mittlerweile zusammengekommen ist, ist eine Menge: fast 5GB. Ein Beispiel für die Suche wäre zum Beispiel: ich will wissen, auf welcher CD die Maxi-Version des Titels "Maneater" von Hall & Oates drauf ist. Also suchte ich nach "Maneater" und einer Spielzeit von mindestens fünf Minuten. Die Suche war ein voller Erfolg, mittlerweile stehen zwei verschiedene CDs mit dem Titel in meiner Sammlung.

Normalerweile verwende ich für solche Applikationen gerne die Datenbank SQLite. Sie wird von Qt von Haus aus unterstützt, und kommt ohne eine weitere Einrichtung zurecht. Leider ist SQLite bei den Datenmenge (zumindest so, wie ich die Daten organisiert habe) nicht in der Lage, wirklich performant darin zu suchen. Das Aufbauen der Datenbank ist noch zeitintensiver. Im Moment rettet mich da noch mein Quad Core Rechner, aber auf durchschnittlicher Hardware ist das definitiv kein Spaß mehr. Deshalb muss dort eine tief greifende Änderung her.

Welches ist die Höchstgeschwindigkeit einer unbeladenen Schwalbe?

-- Brückenwächter, "Monty Python - Die Ritter der Kokosnuss"

Eigentlich wollte ich ja mal wieder einen Beitrag machen, der nichts mit Computer zu tun hat, aber dieser wird es noch nicht sein. Es ist quasi ein Nachtrag zu dem Beitrag GCC mit Atom Optimierung. Eher durch einen Zufall ist mir aufgefallen, dass der Testdurchlauf ("Queen Greatest Hits I" von .wav nach .ogg wandeln, mit Standardeinstellungen) auf meinem Haupt-Linux-Rechner auf einmal einen Faktor von circa 30 statt den erwarteten circa 20-fach brachte.

Der Verwunderung konnte erst nach einigen Minuten Einhalt geboten werden: ich hatte einen "Tippfehler" gemacht: statt dem OggVorbis-Encoder meines Testszenarios hatte ich den OggVorbis-Encoder der Linux-Distribution verwendet. Statt der Version 1.0.2 wurde nun 1.2.0 verwendet, aber das kann nicht für einen Geschwindigkeitszuwachs von 50%25 verantwortlich sein. Dafür schon eher die Architektur: mein Linux läuft unter 64 Bit, und nicht wie das Testprogramm mit nur 32 Bit. Da wurde ich neugierig: kann der Schritt von 32 auf 64 Bit für einen Performancezuwachs von 50%25 verantwortlich sein?

Dafür habe ich mir folgendes Testszenario aufgebaut: es wurden zwei Testsysteme aufgesetzt, eins mit dem Celeron 220, der die gleiche Architektur wie erste Generation der "Core 2"-CPUs aufweist, und eins mit dem Atom 230. Auf dem wurde die 64-Bit Version von Ubuntu 10.04 alpha installiert. In dieser Umgebung wurde dann oggenc einmal als 64-Bit- und einmal als 32-Bit-Version laufen gelassen. Ich hatte mit einem anderen System schon mal ermittelt, dass es keinen messbaren Performanceunterschied von einem 32-Bit Programm auf einem 32-Bit- und 64-Bit-System gibt. Zum Vergleich gibt es noch die Messergebnisse meines "Haupt-Linux-Rechners", bei dem mir der Leistungszuwachs aufgefallen ist. Der Testparcours ist (wie bei mir üblich) das OggVorbis-Encodieren von "Queen Greatest Hits I".

Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

-- Edsger Wybe Dijkstra, "The Humble Programmer, ACM Turing Lecture 1972"

Einer der Hauptunterschiede der Architektur eines Intel Atom Prozessors im Vergleich zu den meisten anderen ix86-kompatiblen Prozessoren ist die so genannte "out-of-order execution". Das bedeutet, dass der Prozessor die Befehle so umsortiert, dass er sie möglichst schnell ausführen kann, ohne den eigentlichen Ablauf des Programms zu verändern. Beim Atom wurde diese Technik außen vor gelassen, um so den Prozessor einfacher und kleiner gestalten zu können.

Nun bringt der GCC 4.5 eine extra Optimierung für den Atom mit. Diese soll nun die Idee der out-of-order execution quasi vor verlagern, so dass nun der Compiler die Befehle schon in der optimalen Reihenfolge generiert. Das wollte ich mal ausprobieren, und habe meinen alten Atom 230 reaktiviert, ein Ubuntu 10.04 alpha drauf installiert, und den aktuellen Stand des gcc aus dem Subversion-Archiv des Projektes selbst kompiliert.

[Rob Pike's] Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
[...]
Ken Thompson, the man who designed and implemented the first Unix, reinforced Pike's rule 4 with a gnomic maxim worthy of a Zen patriarch: When in doubt, use brute force.

-- Basics of the Unix Philosophy

Zu meinen Aufgabenbereichen gehört bei meinem Job auch das Portieren von altem Code auf unsere neue Plattform. Einer der größten Unterschiede dabei ist, dass sich der Compiler von GCC 3.x auf GCC 4.x geändert hat. Das bringt einige Probleme mit sich. Interessant finde ich dabei, wie die Probleme von den Leuten aufgenommen wurden, die für den ursprünglichen Code verantwortlich waren.

Ein fast schon klassisches Beispiel: in C++-Code wurde eine Klasse angelegt, die verschiedene Variablen enthält, die aber nicht initialisiert wurden. Der GCC 3.x hat die Speicherbereiche anscheinend mit Nullen gefüllt, der GCC 4.x erwartet vom Programmierer, dass er dort etwas genauer spezifiziert, was er eigentlich gemeint hat. Tut er dies nicht, wird (vermutlich aus Performancegründen) der Speicher dort auch nicht initialisiert. Dies hat zur Folge, dass die Software mal geht und mal nicht, je nachdem, was gerade zufällig an dieser Stelle im Speicher steht. So ziemlich jeder weiß, dass solche Fehler sind schwer zu finden sind. Erste Reaktion die ich auf den Hinweis bekommen habe, dass man das so besser nicht machen sollte: "Wieso hat denn den Fehler im GCC 4 noch keiner behoben?" Ich weiß bis heute nicht, ob diese Frage wirklich ernst gemeint war, oder doch nur Spaß... Meine sonstigen Erfahrungen lassen mich allerdings ersteres annehmen.

(Nicht nur) bei uns ein weiterer Klassiker: während des Kompilieren werden Warnungen noch und nöcher geworfen. Bei den größeren Einzelteilen sind sie im vierstelligen Bereich. Die Herangehensweise ist auch schon klassisch: "Wieso die Warnungen rausnehmen? Das Programm läuft doch." Natürlich wird es für einen schwer, selbst Code von besserer Qualität in ein solches Moloch einzufügen. Die Warnung vom eigenen Code gehen in dem Sumpf einfach unter. Ein Kollege hat das die Tage so beschrieben: wenn ein Haus irgendwo steht und die Scheiben heile sind, bleiben sie auch heile. Ist aber erst mal eine kaputt, geht es schnell, bis auch die anderen eingeschmissen werden.

Lucy: "Ha! You got your shoes on the wrong feet again!"
Linus: "I don't have time to worry about the non-essentials! These are my shoes and these are my feet.. Shoes are on feet... That's all I care about!"

-- Peanuts by Charles M. Schulz, 6. März 1957

Normalerweise pflege ich im Bereich "Computer" eher einen konservativen Ansatz: nichts einsetzen, was sich nicht schon wenigstens woanders bewährt hat. Wenn ich programmiere achte ich im Allgemeinen auf eine breite Einsetzbarkeit meiner digitalen Ergüsse. Die meisten meiner Programme laufen auf vielen Betriebssystemen. Um dieses Ziel zu erreichen setze ich das Qt-Framework ein, welches das Schreiben von Multiplattform-Applikationen sehr stark erleichtert.

Mich überzeugt ein Programm erst dann, wenn man nicht erst noch einen Tag oder länger einen Rechner installieren muss, nur um überhaupt mit dem Programmieren anfangen zu können. Genauso will ich aber auch, dass man für meine Programme auch nicht viel machen muss, um sie laufen zu lassen. Deshalb habe ich mir mal einen gebrauchen Mac Mini gekauft, damit ich meine Programme bereits installationsfertig auch für diese Plattform anbieten kann. Für Windows gibt es sowieso mehr als genug Möglichkeiten, seine Software benutzerfreundlich auszuliefern. Das Standard-Installationsformat für Unix-Derivate die nichts mit Linux zu tun haben, ist sowieso der Quellcode.

Bleibt noch Linux. Da wird es kompliziert. Da gibt es zum Beispiel verschiedene Paketverwaltungen, was aber nicht wirklich ein Problem darstellt, da es dafür Konvertierungsprogramme gibt. Problematischer wird es zum Beispiel bei der verwendeten Codebasis, da möchte ich mal wieder auf das eingangs erwähnte Qt zurück kommen. Das wird kontinuierlich weiterentwickelt, bleibt aber dabei innerhalb der Version 4.x abwärtskompatibel, so läuft ein Programm, welches nur Funktionen von 4.3 verwendet auch unter 4.4 und 4.5. Andersherum geht das natürlich nicht.

Qt hat für mich immer etwas von Ratiopharm oder Obi. Für 90%25 der Probleme, die sich mir beim Programmieren stellen, haben die schon mindestens eine Lösung im Sortiment. Frei nach dem Motto: "Da gibt's doch was von Qt" oder auch: "Entweder man programmiert es selbst oder man nimmt was von Qt".

-- SvOlli

Was ich oben gesagt habe stimmt zwar, aber hier ist ein Problem der übrig gebliebenen 10%25: ich will mir in Qt einen möglichst einfachen Kommunikationsbus programmieren, über den sich mehrere Applikationen unterhalten können. In den letzten zwei Wochen habe ich mir eine Lösung zusammengehackt, die auf jeder Plattform funktioniert, die ich einsetze. (Windows, Linux, Mac OS X 10.4)

Leider gibt es noch einige Plattformen mehr, die von Qt unterstützt werden. Bei einigen fehlt mir der Zugang, wie zum Beispiel Unixware. Im Allgemeinen fehlt mir auch die Zeit die Systeme aufzusetzen, nur um ein Testprogramm darin laufen zu lassen. Darum hoffe ich mal auf die Internetgemeinde: ich habe eine kleine Seite (auf englisch) aufgesetzt, die mein Vorhaben beschreibt, und wie man einen einfachen Test durchführen kann.

Jetzt sind die Nerds aufgerufen, die ein Qt auf ihrem System haben und wissen, wie man "make" bedient: saugt Euch den Code, kompiliert ihn und lasst den Test laufen. Und denjenigen, die ein Blog schreiben, dass solche Nerds anspricht, wäre ich dankbar, wenn sie diesen Artikel oder die eigentliche Seite meines Vorhabens (http://svolli.org/software/slart/slartsock/) dort verlinken könnten.

Ich bin die Zahnfee, ich polier dir die Fresse!

-- Kreep, iBash.de #16432

"Irgendwie unspektakulär" titulierte der Kollege hier. Dem kann ich frei nach Radio Eriwan hinzufügen: "im Prinzip schon". Im Rahmen meiner Entscheidung, das Xandros Linux meines Eee PCs gegen etwas zeitgemäßeres auszutauschen, war die letzte zu klärende Frage "wie online gehen?" Mit Xandros und meinem Nokia 6233 war das besonders einfach: per Bluetooth aufs Handy, und von dort aus dann weiter per UMTS ins Internet. Seit dem Upgrade auf ein HTC Magic aka Google G1 ging das nicht mehr.

Aber ich verwende nun schon seit über zwei Monaten ein Huawei E160 USB-UMTS-Modem von Tchibo, welches auch gerne "Surf-Stick" genannt wird an meinem Notebook. Da ich selten beides gleichzeitig im Einsatz habe, habe ich nun versucht, diesen an meinem 901er zum Laufen zu bekommen: Windows XP kein Problem, aber das interessiert mich ja nur zum Aufladen des Guthabens. Unter Linux ging es nicht so einfach: Xandros hat das Modem nicht richtig erkannt, und unter Ubuntu bekomme ich zwar eine Verbindung, kann laut Statusmonitor Daten senden, aber keine Empfangen.