Das offizielle Blog der h8u.de Gemeinde

Carlotta war ein Ort für Leute mit ausgeprägt einfachem Geschmack. Abends kam auf den Tisch, was man tagsüber überfahren hatte.

-- Rigby Reardon, "Tote tragen keine Karos"

Ich plane gerade, ein neues Bankswitch-Schema für das Harmony Cartridge zu entwickeln. Das Modul besteht hauptsächlich aus einem ARM Microcontroller, den ich jetzt gerade zu programmieren versuche. Die bisherige Firmware dafür wurde mit der Entwicklungumgebung von Keil programmiert, die allerdings nur für Windows erhältlich ist. Meinen Teil möchte ich gerne mit der GNU Toolchain programmieren, um die Entwicklung unter Linux machen zu können.

Der Code besteht aus reinem ARM7TDMI Assembler, der direkt ohne ein Betriebssystem auf dem Microcontroller läuft. Eine Portierung sieht nicht so schwer aus. Mein größtes Problem ist dabei das Arbeiten mit dem Linker, für den ich ein eigenes Linker-Script entwickeln muss. Das Layout im Flash-Speicher des Microcontrollers soll so aussehen:

Startvektoren
Bootstrapcode
ROM Simulator
2600 ROM Daten

Der Bootstrapcode initialisiert den Microcontroller, kopiert den ROM Simulator ins RAM und startet diesen dann. Der holt dann bei Bedarf die Daten aus dem restlichen Speicher. Die Reihenfolge ist dadurch vorgegeben, das ein ROM-Image durch das Hintereinanderhängen von ARM Code und 2600 Code erzeugt werden soll.

PHP steht für pupertierende Hauptschüler programmieren.

-- Eine beliebte Erklärung, glaub man Google

Vor ein paar Tagen habe ich eine schonungslose Abrechnung mit der Programmiersprache PHP gelesen. Sie ist lang, hervorragend argumentiert, und hinterlässt nicht den Funken einer Hoffnung, dass sich da noch was reparieren lässt. Außerdem ist sie auch noch recht gut geschrieben, so dass das Lesen auch Spaß macht.

Das Ökosystem PHP wird auf allen Ebenen zerlegt: in allen Facetten der Sprachdefinition genauso wie die Standardbibliothek, also die Funktionen, die mitgeliefert werden. Auch so ziemlich jedes "aber"-Argument wird genauso zerlegt. Ein kurze Kostprobe will ich mal übersetzen: das Argument "ein guter Programmierer kann in jeder Programmiersprache guten Code schreiben" wird meiner Meinung nach korrekt auseinandergenommen mit: "Ein guter Handwerker kann einen Nagel entweder mit einem Stein oder einem Hammer einschlagen, aber wie viele Handwerker sieht man, die auf Nägel mit Steinen einschlagen? Ein Teil von dem, was einen guten Entwickler ausmacht, ist die Fähigkeit die richtigen Werkzeuge auszuwählen."

There's no feeling any greater
Than to shoot first and ask questions later

-- "Weird Al" Yankovic, "Trigger Happy"

Ich wurde ge-fefe-t. So kann man wohl am besten beschreiben, was letzte Woche Donnerstag hier im Blog los war. Alles fing mit einem Artikel bei fefe an, wo er sich darüber gefreut hat, dass er bei der Suche nach Blueprint von den Rainbirds über Pop-Splits dazu gestolpert ist. Ich hatte mich schon letztes Jahr mal die Mühe gemacht, alles das, was auf You-Tube von Pop-Splits zu finden war, in einem Blogbeitrag hier zu verlinken. Dann ist das passiert, was ich nicht erwartet hatte: er verlinkt den Beitrag, ohne Rückmeldung. Innerhalb kürzester Zeit war mein Webserver über den ihm zugestandenen Ressourcen und wies Zugriffe ab.

Als ich ihm danach mehr Ressourcen zur Verfügung gestellt hatte, verklemmte nach kurzer Zeit das PHP, was mir aber auch erst Stunden später aufgefallen ist. Und das alles, obwohl ich mir Mühe gegeben hatte den Webserver auf einen eventuellen Ansturm vorzubereiten, zum Beispiel durch das Cachen von PHP-Seiten. Geholfen hat es nichts, wie das Ergebnis zeigt.

Most people, I think, don't even know what a rootkit is, so why should they care about it?

-- Thomas Hesse, President of Sony BMG's global digital business division

Neulich habe ich etwas gebraucht, was ich im Nachhinein "poor man's rootkit" getauft habe. Wir wollten auf einem Linux System feststellen, welches Prozess an Sachen rumfingert, an die er eigentlich gar nicht ran sollte. Als Beispiel nehme ich mal an, dass es sich dabei um eine Konfigurationsdatei handelt.

Ich habe dabei ein paar Sachen kombiniert, die ich schon Monaten, das Meiste davon sogar schon seit Jahren kenne. Interessant ist dabei die Mächtigkeit, die aus den Kombination der Einzelteile entsteht. Der Trick besteht im Wesentlichen daraus, dass man dem Linker beim Starten eines Programms anweisen kann, neben den angeforderten Bibliotheken noch weitere "Shared Objects" hinzu zu laden, die dann eine höhere Priorität aufweisen. Das wollen wir uns zu nutze machen, um den Aufruf der Funktion open() aus der C-Bibliothek "abzufangen".

I am a programmer.

-- Kenneth Thompson

Seit längerem habe ich vor, kniffelige Sachverhalte in meinen Qt Programmen statt in Variablen und komplizierten Abfragen lieber in sogenannten Finite State Machines (in Deutsch auch Endlicher Automat genannt) abzubilden. Diese Woche habe ich mich dazu aufgerafft, diese Vorbaben bei einer von mir programmierte Abfrage der FreeDB Datenbank via des CDDB-Protokolls umzusetzen.

Irgendwie gab es immer einen Fall, in dem die Abfrage, die außerdem noch eine Schnittstelle zum Auslesen der CD-Daten via CD-Text verwendet, nicht so funktioniert hatte, wie ich es meinte. Habe ich mal schnell eben das eine Problem gelöst, habe ich meistens damit ein bis zwei andere Probleme geschaffen. Unterm Strich blieb immer mindestens ein Problem über. Also habe ich mir Gedanken gemacht, wie die Beschreibung der Funktion in einem Zustandsautomaten aussehen sollte. Nachdem ich dies graphisch beschrieben habe, habe ich es dann "von Hand" runter programmiert. Dabei sind mir noch Unzulänglichkeiten aufgefallen, die ich aber überraschend einfach in den Griff bekommen habe, durch das Hinzufügen eines neuen Zustandes und ein paar übersehener Übergänge. Das vorläufige Endergebnis habe ich hier noch einmal aufgezeichnet.


Wenn ich mir das Bild noch einmal anschaue, verstehe ich auch, warum viele Beispiele von State Machines Ampeln nachbilden: die Dinge neigen dazu, schnell an Komplexität zuzunehmen.

[While searching an appartment in New New York]
Fry: "Well, I give up. What's the catch?"
Realtor: "Oh, no catch. Although we are technically in New Jersey."

-- Futurama by Matt Groening, Season 1 Episode 3: "I, Roommate"

Ein Bereich, der mir im Bereich "Computer basteln" immer besonders viel Spaß gemacht hat, waren Embedded Systeme. Dabei handelt es sich per Definition um Rechner, die in komplexeres System eingebettet sind. Ein klassisches Beispiel dafür wäre ein Verkaufsautomat, wie er hier bei The Daily WTF zu sehen ist. Das ist aber nicht unbedingt die einzige Gelegenheit, in der dieser Begriff verwendet wird, er wird auch gerne als Synonym für Computer verwendet, die einfach nicht so die Leistungsfähigkeit eines üblichen PCs mitbringen, dafür aber andere Vorzüge haben, zum Beispiel eine deutlich geringere Leistungsaufnahme oder kompaktere Ausmaße.

Und um eine solche Kiste soll es im Folgenden gehen. Mir wurde freundlicherweise mal ein solches System von meinem externen Kollegen Michael Sülzer zum Rumspielen zur Verfügung gestellt. Vielen Dank. Es handelte sich dabei um einen Rechner mit den beeindruckenden Ausmaßen von circa 11.5cm x 11.5cm x 3.5cm, der mit einer Vortex86 CPU bestückt ist. Diese CPU ist ein System-On-Chip, ein Chip beinhaltet also alles, was man im Kern zum Betrieb eines Computers braucht: Rechenwerk, Grafik, IO-Funktionalität, etc. Im normalen Betrieb benötigt er circa 7 Watt, ich habe es auch unter Volllast nicht geschafft ihn auf über 10 Watt zu bringen (im Betrieb mit einer CF-Karte). Nicht schlecht für ein System mit 1GHz Takt, 256MB RAM und einer 1GB CF-Karte (eine 2.5"-Festplatte mit PATA Anschluss passt theoretisch auch noch mit ins Gehäuse). Normalerweise schaffen nur ARM-Systeme eine solch geringe Leistungsaufnahme. Um noch ein Vergleich, um klar zu machen, wie kompakt das Gerät ist: man kann es nicht auf eine CD stellen, ohne dass irgendwo etwas hervorlugt, siehe auch die Bilder, da habe ich da nämlich mal probiert.

Wie kommt ein Schneepflugfahrer morgens zur Arbeit?

-- H.G. Butzko

Aus meinem Bekanntenkreis wird immer mal wieder die Frage an mich herangetragen: "Sag mal, wie bekomme ich eigentlich mein Linux bootfähig, wenn ich entweder noch gar keinen Bootloader drauf habe, oder aber der Bootloader kaputt ist?" Bisher war die Lösung immer noch von vielen Rückfragen abhängig, besonders wichtig war dabei das "Abzählen" der Partitionen. Dank GRUB4DOS kann ich jetzt aber mal in einem allgemeingültigen How-To zusammenschreiben. Was im Vorfeld benötigt wird, sind die Parameter, mit denen der Linux-Kernel gestartet wird. Außerdem wird auch die Lage des Kernels im Dateisystem benötigt, diese wird aber von vielen Linux-Distributionen mit deinem Link von /vmlinuz angezeigt, der hier also als Stellvertreter genommen wird.

GRUB4DOS ist eine Abspaltung (auch "Fork" genannt, nach dem englischen Begriff für "Gabelung" oder "Verzweigung") des "originalen" GRUB. Ursprünglich dafür gedacht, um von DOS aus ein GRUB-ähnliches Tool laden zu können, das Programm mittlerweile wohl eher selten von DOS aus genutzt. Die heutzutage viel nützlichere Verwendungsmöglichkeit ist ihn entweder als nativen Bootloader einzusetzen, oder aber um ihn vom Windows Bootloader starten zu lassen.

Sorry I'm late. I was taking a crap.

-- Henry Gondorff, "The Sting"

Vor gut einem Jahr habe ich hier ein Loblied über die Linux Distribution "Tiny Core Linux" anlässlich der Veröffentlichung von Version 2.0 gesungen. Jetzt ist Version 3.1 raus, und man könnte sagen: es wird Zeit für eine weitere Strophe. Eigentlich hatte ich schon vor, diesen Artikel zur Version 3.0 zu schreiben, aber die ersten Vorversionen von 3.1 haben gezeigt, dass es sich lohnen würde noch bis zum endgültigen Release von 3.1 zu warten.