Entries by Wolfgang Kaufmann

C Traps and Pitfalls, Andrew Koenig, 1988, awprofessional.com, ISBN: 0-201-17928-8.

"This book belongs on your shelf if you are using C at all seriously, even if you are an expert: many of the professional C programmers who saw early drafts said things like that bug bit me just last week!"

Andrew Koenig ist in der C und C++ Welt kein Unbekannter. Er zählt zu den anerkanntesten C++ Experten weltweit und hat bis vor wenigen Jahren, wie auch Bjarne Stroustrup, in einer Forschungsabteilung von AT&T/Bell Labs (Brutstätte von C, C++, UNIX, ...) gearbeitet. Seine Rolle als Verfechter von ISO/ANSI Standards unterstützte er mit seiner Arbeit im ISO/ANSI Standardisierungsgremium für C++.

1985 hat Koenig begonnen Fallen in die C Programmierer sich immer wieder verlieren zu sammeln. Drei Jahre später wurde diese 147 Seiten umfassende Sammlung von Addison-Wesley erstmals im Taschenbuch-Format veröffentlicht. Mir liegt der neunzehnte Druck vor, wobei am Inhalt des Buches seit November 1988 nichts mehr verändert wurde. C hingegen hat sich seit den Achtzigern sehr wohl weiterentwickelt: 1989 wurde ANSI C (ANSI X3.159-1989 "Programming Language C." respektive ein Jahr später ISO/IEC 9899:1990) verabschiedet und seit 1999 (ISO/IEC 9899:1999) gibt es mit C99 wiederum einen neuen Nachfolger-Standard.

Und dennoch: Fast zwanzig Jahre nach Erscheinen dieses Buches lohnt es sich immer noch, Zeit in die Lektüre dieser Sammlung zu stecken. Nicht nur für low-level C-Programmierer. Dem Engagement Koenigs hinsichtlich Standardkonformität ist es zu verdanken, dass seine Sammlung auch wenn sie vor der Verabschiedung von ANSI C entstand, sich dennoch bereits an diesem orientiert.

Der Inhalt

Das Buch ist in 10 Abschnitte geteilt:

0 Introduction
1 Lexical pitfalls
2 Syntactic pitfalls
3 Semantic pitfalls
4 Linkage
5 Library functions
6 The preprocessor
7 Portability pitfalls
8 Advice and answers
Appendix: printf, varargs, and stdarg

"I wrote my first C program in 1977. Of course it didn't work."

In den Kapitel 1 - 3 bespricht Koenig Grundlagen, die man so auch in ähnlichen Büchern findet:

Klassiker wie das ungewollte Vertauschen von = mit == (bzw. &, | mit &&, ||), Greedy / Maximal Munch-Strategie (warum a---b zu a -- - b und nicht zu a - -- b wird), Probleme von verschachtelten Kommentarstrukturen, Zeichenketten vs. Zeichen. Warum man sich vor Ausdrücken wie (*(void(*)())0)(); (declare it the way you use it) nicht fürchten muss; richtige Reihenfolge bei der Operatoren-Auswertung, Dangling-Else, Pointer vs. Arrays und wie man richtig zählt und sich mit asymmetrischen Grenzen viel Ärger (off-by-one errors) ersparen kann. Express a range by the first element of the range and the first element beyond it. [...] Use inclusive lower bounds and exclusive upper bounds.

In Kapitel 4 geht es um die Rolle des Linkers und welche Probleme beim Verlinken von Objekt Modulen auftreten können. Weitere Punkte: Die Unterschiede zwischen einer Deklaration und einer Definition, Bezeichner Konflikte und deren Auflösung (static-Modifier), und was schiefgehen kann, wenn Funktionsargumente, -parameter, Rückgabewerte und external Typinformationen durcheinander gebracht werden.

Es folgt ein kurzes Kapitel über wichtige Funktionen aus der Standard Library mit überraschenden Eigenschaften. Wie etwa: getchar() liefert einen int und keinen char zurück oder der richtige Umgang mit errno. In den nächsten beiden Kapitel dreht sich alles um Macros und auf welche Problemstellen geachtet werden muss, wenn man Software schreiben möchte, die portabel auf mehreren Architekturen unter verschiedenen Umgebungen verwendet werden soll.

"[...] For this reason, it is a good idea in a macro definition to enclose each parameter in parentheses. It is also important to parenthesize the entire result expression to defend against using the macro in a larger expression."

Natürlich schlagen oder beißen so manche der beschriebenen Fallen heutzutage nicht mehr (zu). Konnte a =- 1 von frühen C Compilern noch als a = a - 1 statt a = -1 missverstanden werden, so hat sich zum einen C gewandelt, (heute: a -= 1) und zum anderen haben sich die Compiler-Implementierungen gebessert. So sind viele der beschriebenen Compiler-Macken wie etwa a >> = 1 als legales Konstrukt oder 0195 als oktale Zahl durchgehen zu lassen, in modernen Compilern wohl kaum noch anzutreffen.
ähnliches gilt für andere Beispiele, wie etwa: "A function called before it is defined or declared is assumed to return int."
Das stimmt für C90 kompatiblen Code, hat sich allerdings mit C99 geändert. Dennoch finde ich solche Hinweise nützlich, denn abgesehen davon, dass man etwas über die Geschichte von C erfährt, schwirrt da draußen noch sehr viel alter Code rum der gewartet werden muss.

Am Ende eines jeden Kapitels bringt Koenig Übungsbeispiele, die einerseits die besprochenen Inhalte vertiefen und anderseits zur weiteren Beschäftigung einladen sollen. Kapitel 8 enthält ausführliche Lösungen zu diesen Aufgaben, sowie allgemeine Ratschläge zur Fehlervermeidung und Tipps aus dem Alltag.

Exercise 2-1. C permits an extra comma in an initializer list:

    int days[] = { 31, 28, 31, 30, 31, 30,

                   31, 31, 30, 31, 30, 31, };

Why is this useful?


Exercise 5-1. When a program terminates abnormally, the last few lines of its output are often lost. Why? What can be done about it?

Abschließend folgt auf 13 Seiten die wohl beste und ausführlichste Behandlung über die printf-Familie, die mir je in einer nicht C-Referenz untergekommen ist und eine kurze Einführung in variable Argumentenlisten mit varargs / stdargs.

"Perhaps the most important avoidance technique is to know what you're doing."

Fazit

Wer bereits über langjährige C Erfahrungen verfügt, wird in diesem Buch nur wenig Neues erfahren. Anderseits sollte man die erste bessere C Einführung und einige praktische Erfahrungen doch schon hinter sich gelassen haben, um die Inhalte auch wirklich nachvollziehen zu können.

Seit etwa zwei Jahren gebe ich sporadisch einigen HTL Schülern C/C++ Nachhilfe. Das Ganze macht großen Spass, und ist sehr lehrreich. Ich erfahre, welche Konzepte (oft ganz unerwartet) Verständnisschwierigkeiten bereiten (z.B. Funktionsparameter) und kann zusammen mit etwas Computerarchitektur-Hintergrundwissen vermitteln, warum etwas so ist, wie es ist. An diesen Schülern habe ich eine Reihe von Beispielen aus dem Buch erproben und mit Erfolg testen können.

Koenig hat mit diesem Buch aber vor allem eines geschafft: Er hat mich wieder neugierig werden lassen. Wie reagieren und implementieren die C Umgebungen mit denen ich zu tun habe (gcc > 3 mit glibc, dietlibc sowie bedingt die libc von FreeBSD/Apple) tatsächlich? Und das ist weit mehr als ich erwarten durfte.

Müsste ich mich zwischen diesem Buch und "Expert C Programming" von Peter van der Linden entscheiden, dann würde ich letzteres wählen. Dazu jedoch etwas später mehr.

We're sorry but your querys looks similar to automated requests from a computer virus or spyware application.

Dieser Screenshot hier belegt, dass ich ein gefährliches Virus bin und wenn nicht das, dann doch mindestens ein Spion. (Juhuu!)
Wer sich nun wundert, wonach Viren und Spyware Programme wie ich üblicherweise so googlen: nach Auszügen aus Linker-Error Messages!

Vim ist ein großartiger Editor, auch wenn die Einstiegshürden nicht unbeträchtlich sind. So heißt es auf der Vi Lovers Home Page:

You cannot use Vi properly before knowing at least a handful of commands. This makes the threshold rather high. Vi doesn't get fast before you know 25 commands or so, and you won't be the cool dude(tte) before you know even more.

Doch dieser Aufwand lohnt sich auch heute - 31 Jahre nachdem Bill Joy vi schuf - immer noch. Insbesondere Personen die täglich viele Texte bearbeiten, sei es zum Schreiben von Mails, Notizen, Berichten oder zum Entwickeln von Software, sollten einen Blick wagen. Vim wird von Version zu Version besser und passt sich den neuen Herausforderungen an. So mögen IDEs mit integrierter Projekt- und Versionsverwaltung, Smart-IntelliSense, Live-Code-Evaluation, Debugging, automatisierten Refactoring-Features und integriertem Kaffee kochen locken, Vim bleibt mein tägliches Arbeitspferd.

Und überhaupt: Ein Editor der Emacs überlebt, ist ohnehin nicht umzubringen!

Vor vielen Jahren hatte ich eine Zeit lang GNU Emacs verwendet. Ich halte Emacs für einen großartigen "Editor". Allerdings war das irgendwann zusammen mit X11 auf meiner damaligen Kiste mit 16 MB RAM Kiste kein Vergnügen mehr und ich hatte X11 samt Emacs den Rücken gekehrt.

Mit Vim in der Standard-Konfiguration werde ich jedoch genauso wenig glücklich, wie mit den meisten Konfigurationen anderer Nutzer. Es hakt oft an diversen Details die ich bzw. meine Finger schon auf eine gewisse Weise gewohnt sind. Sei es die ruler-Setting oder dass ich per list/listchars gerne eine visuelle Rückmeldung über vorhandene Tabulatoren- und Zeilenenden-Zeichen erhalte.

Meine vimrc wurde über die Jahre von vielen Snippets und Tipps (die ich weitgehend schamlos, aber dankend, ohne Quellenangabe übernahm) anderer Vim-Nutzer angereichert und drohte ins grenzenlose zu wachsen. Mit meinem Umstieg auf Vim 7 vor einem Jahr, habe ich sie vollständig überarbeitet und drastisch gekürzt.

Das Design-Ziel meiner vimrc ist, sie möglichst kurz (d.h. unter 200 Zeilen) zu halten. Es gab durchaus Zeiten, in denen ihr Umfang der 2000 Zeilen Grenze gefährlich nahe kam.

Der hier veröffentlichte Hauptteil fasst derzeit knapp über Hundert Zeilen und stellt jenes Grundgerüst dar, welches ich auf allen meinen Rechnern einsetze. Wobei einige Teile ausgegliedert wurden:

• gui - hauptsächlich Hintergrund-, Schrift- und Größeneinstellungen


• texte - automatisches Ausmerzen von häufigen Vertippern, Abkürzungen, eine Reihe von besonderen Einstellungen für Mail-/News-Beiträge, automatisches Konvertieren von Texten zu HTML (mit 2html.vim), usw.


• devel - Einstellungen, Mappings, Funktionen und Pakete die das Arbeiten abhängig von der aktuellen Sprach-/Programmierumgebungen enorm erleichtern

Entrümpelt habe ich nach meiner Migration auf Vim 7 beispielsweise Versionsabfragen die Rückwärtskompatibilität bis zur Version 5 garantierten. Vim 7 bietet einfach eine Reihe von Killerfeatures ohne die ich nicht arbeiten möchte. Einstellungen die Vim per Default aktiviert, wurden verworfen; viele Settings aktualisiert und schließlich das Ganze recht ausführlich kommentiert.

People don't know that vi was written for a world that doesn't exist anymore. -- Bill Joy

Eine Empfehlung noch: vim ge-packt von Reinhard Wobst. Eine wunderbare Einführung und Referenz, die ich seit drei Jahren immer griffbereit in Tastaturnähe halte. Auch wenn sich das Buch noch auf Version 6.2 stützt, Angst vor einer aktualisierten Neuauflage braucht man wohl vorerst nicht zu haben. Auf eine Anfrage meinerseits meinte Reinhard, dass solange der Verlag noch einige Bücher vorrätig hat, die Chancen eher schlecht stehen und er außerdem ohnehin zur Zeit mit anderen Projekt ausgelastet ist.

• Meine .vimrc zum Download.

Update: Im Oktober wird voraussichtlich eine neue (3.) Auflage (ISBN: 978-3-8266-1781-2) von vim gepackt erscheinen!

über mein erstes Gigabyte an Festplattenspeicher hatte ich mich noch riesig gefreut, mein erstes Terabyte hingegen lässt mich auch ein wenig den Kopf schütteln. Über Bill Gates sagt man, dass er 1981 den Speicherbedarf von PCs mit "640K of memory should be enough for anybody" etwas unglücklich eingeschätzt haben soll. Unvorstellbar heute, und doch hätte ich vor zehn Jahren über 100 Gigabyte Festplatten sicherlich auch noch ähnliches gesagt.

Das Terabyte volllaufen lassen habe ich mit einer ICY BOX IB-351StUS2 in der eine Samsung T166 HD501LJ 500 GB betrieben wird.

Er ist zurück. Der Erasmus-Blogger.

Nun, was darf man sich erwarten? Eine Menge! Gerfried pflegt im Allgemeinen einen äußerst würzigen, intelligenten und witzigen Stil und obendrein hat der Mensch auch noch eine Menge zu sagen. Steve Yegge muss sich anschnallen, er ist nun nicht mehr der einzige in der Online-Welt, der weiß, wie man mit gepfefferten Rants und Technologie-Insights seine Leser unterhält.

• CREOtive Thoughts

Ö1 ist ein werbefreier österreichischer (öffentlich-rechtlicher) Radiosender und für mich seit Jahren meine primäre Radiostation. Er ist das einzige ORF Organ, welches den durch das Rundfunk-Bundesgesetz an den ORF gerichteten Kultur- und Bildungsauftrag annimmt und auch erfüllt. Wechselte ich ursprünglich als Hörer zu Ö1, da ich das gesprochene Wort und die Informationssendungen des Senders der Brittney-Spears-Daddelmusik-Bestrahlung anderer Sender vorziehe, konnte ich mich mit der Zeit auch mit dem Klassikprogramm sehr anfreunden.

Ein Manko hat die Sache: Man verpasst viel zu leicht eine Sendung. Auch bisher gab es durch den Ö1-Downloadservice "Ö1 zum Nachhören", die Möglichkeit gegen einen kleinen jährlichen Beitrag ausgewählte Aufzeichnungen von Sendungen runterzulanden. Nach dem Motto: "Lieber spät als nie" hat Ö1 es jetzt allerdings auch in den Podcast-Club geschafft. Auf der Ö1 Podcastseite bietet der Sender nun 14 seiner Sendungen als Podcast abbonnierbar an.

Über das Netz kann man Ö1 seit längerer Zeit über zwei Webstreams hören:

• Liveradio
• Inforadio

Leider jedoch in einer überraschend schlechten Audio Qualität.

Neben Ö1 höre ich noch BBC (vorwiegend Radio 4), WDR5 (Wissenschaftsmagazin Leonardo) und seit Holger Kleins Rundfunkgebührenapell vorallem Deutschlandradio und Deutschlandfunk.

Wissenschaftliche Experimente müssen u.a. nachvollziehbar und wiederholbar sein, von letzterem würde ich in diesem Fall allerdings Abstand nehmen...

Zutaten

Ein etwa zwei Jahre altes Powerbook (G4, 12" Zoll, 1024 MB RAM, 80 GB HD, 1.5 GHz), einen Digitus WLAN Antennenfuss und ganz wichtig: Man muss überzeugt davon sein, dass der Magnet viel zu schwach ist und eine Festplatte in einem Powerbook sowieso alleine schon durch das Apple-Strahlenschutzfeld vor allen bösen Geistern und Einflüssen sicher sei.

Was macht man, wenn nicht alle Anwesenden (wie etwa meine Person) im Raum der selben überzeugung sind?

Die Demonstration

Klar, man demonstriert allen Ungläubigen durch eine Vorführung, dass man Recht hat - oder auch nicht. Also, kurzerhand für wenige Sekunden den Antennenfuss auf der linken Seite neben das Mousepad parken (darunter ist die Festplatte verbaut) und schon weiß man mehr.

Der Effekt

Der Bildschirm ist eingefroren, der Sanduhr-Ersatz-Mauszeiger von OS X drehte sich, aber das System war eingefroren und zeigte keine weitere Reaktion mehr. Die Festplatte machte zunächst noch unscheinbare, leise klackende Geräusche, diese wurden jedoch schnell lauter. Beim nächsten Bootvorgang jaulte zunächst der CPU Lüfter laut auf und gleichzeitig ertönte auch das klackende Geräusch wieder. Der Bildschirm blieb schwarz bzw. grau... Die Festplatte ist eindeutig hinüber.

Das Versuchs-Setup

Hier eine Hörspielprobe (269K): Zu hören sind die ersten 15 Sekunden nach Einschalten des Geräts.

Update: Ich hatte bewusst den Namen der Person, welche im Namen der Wissenschaft die Festplatte ihres Powerbooks geröstet hatte, nicht genannt. Inzwischen haben mich jedoch mehrere Leser angesprochen, die den Beitrag so verstanden hatten, als wäre ich selbst das gewesen. Diese Ehre kann ich allerdings nicht für mich beanspruchen, daher mit Nachhalt: Weder habe ich mit dem Magneten rumgespielt, noch wurden diese Experimente mit meiner Hardware durchgeführt. Ich war reiner Augenzeuge. Ich habe auch eine neue (konvertierte) Version der Hörspielprobe hochgeladen - hört hier mal rein - sollte das jemand für den nächsten Sommerhit verwenden wollen, gerne.

Durch Zufall habe ich gerade noch rechtzeitig von einem Vortrag von Prof. Andreas Zeller von der Universität des Saarlandes (Saarbrücken) erfahren.

Ich hatte vor vielen Jahren mal einen kurzen, aber sehr netten E-Mail-Kontakt mit Andreas Zeller. Ich habe damals einige LaTeX-Klassen für Online-Präsentationen (wie beamer, foiltex, prosper, ...) getestet und bin dabei auch auf stslide von Andreas gestoßen. Das Paket hat mir gefallen und Andreas reagierte auf eine Rückfrage prompt und sehr freundlich.

Erst später ist mir aufgefallen, dass er einer der Hauptautoren von DDD ist (dem Data Display Debugger - eines der Frontends für gdb und Co.) und ich auch ein Buch von ihm im Regel stehen habe.

In Programmierwerkzeuge gibt er eine Einführung und Tipps anhand von praktischen Beispielen zu diversen Unix-Entwicklungstools wie diff, patch, make, lex, yacc, autoconf, lint, gdb, ddd, gprof, ...

Das Buch ist zwar nett und vermittelt einen brauchbaren überblick über die wichtigsten Entwicklungstools und -methoden, dennoch möchte ich es an dieser Stelle nicht empfehlen. Denn das meiste kennt man schon und den Rest erfährt man mit etwas Aufwand auch günstiger aus dem Netz und den allgemein verfügbaren Dokumentationen. (Es gibt übrigens auch eine 2. Auflage: "Open-Source-Programmierwerkzeuge", 2003)

Ich wusste, dass sich sein Forschungsschwerpunkt hauptsächlich um Debugging- und Programm-Analyse -Techniken dreht, weshalb ich den Ankündigungstext auch gar nicht richtig gelesen hatte - der Name langte mir um einen Interessanten Vortrag zu erwarten.

Andreas Zeller hat diesen Vortrag in den letzten Monaten schon oft an verschiedenen Unis, Tagungen und Konferenzen gehalten - diese Erfahrung merkte man dem Vortrag auch deutlich an. Zudem verwendet er ein schwarzes MacBook und dazu Apples Präsentationssoftware Keynote - wodurch die visuelle Aufbereitung des Inhaltes alleine schon den Besuch wert war. Das geht ganz stark in die Richtung von Steve Jobs und Lawrence Lessig.

Es waren sehr viele Professoren von verschiedenen Informatik-Instituten anwesend, was mir sehr gefallen hat. Ich hoffe mal, dass der eine oder andere auch einige Impulse - trotz unterschiedlicher Vorraussetzungen (Stichwort: "Folien als Skriptenersatz") - für den eigenen Vortagsstil und vorallem hinsichtlich Präsentationstechniken und Folienaufbau (Stichwort "Powerpoint-Bulletpoint-Orgien") für sich mitgenommen hat.

Jedenfalls, dass war eindeutig der beste Vortrag hinsichtlich visueller Präsentation den ich bislang auf Deutsch (von einem Informatiker) gehört habe. Leider konnte ich weder ein Video des Vortrages noch die verwendeten Folien im Netz finden, sehr schade.

Nunja, kurz ein paar Worte zum Inhalt:

Zeller hat ein Konzept erarbeitet wie er Aussagen über die zukünftige Fehlerträchtigkeit von Modulen unter Einsatz verschiedenster Metriken machen kann. Dies kann man beispielsweise dazu nutzen um die Quality Assurance Maßnahmen bei besonders fehlerträchtigen Modulen anzupassen oder um herauszufinden, welches verfügbare Softwarepaket (Beispiel: DirectX vs. OpenGL) tendentiell eher weniger Probleme machen wird. Er wurde von Microsoft eingeladen seine Analysemethoden auf fünf große Softwarepakete von Microsoft anzuwenden und anhand der Daten versuchen zukünftige Fehler vorauszusagen. So hatte Zeller die Gelegenheit Code und Fehlerdatenbanken von folgenden Komponenten genauer zu untersuchen:

• Internet Explorer 6
• NetMeeting
• DirectX
• Internet Information Server
• Interprozess-Komponente

Die Fehlerdatenbank von Microsoft wird u.a. durch Nutzerdaten gespeist. Man kennt den Fehlerdiagnose-/Problembericht-Senden-Dialog von Windows XP, laut Zeller bekommt Microsoft pro Nacht etwa 1000 Stück solcher Berichte übermittelt. Der Großteil dieser Daten betrifft natürlich Programme von Drittherstellern, Microsoft leitet daher die entsprechenden Daten auch an diverse andere Hersteller weiter.

Ich habe noch nie bewusst auf "Problembericht absenden" geklickt. Ich fühle ich mich von diesem Dialog in einer Absturzsituation noch mehr genervt als ohnehin schon, und wenn ich lese "irgendwelche Informationen an Microsoft senden", dann suche ich reflexartig nach dem "Nee, Danke"-Button - auch deshalb, weil ich immer angenommen hatte, dass das sowieso nichts bringen würde. Mittlerweile habe ich dieses System-Verhalten gänzlich abgeschaltet. (Arbeitsplatz - Eigenschaften - Systemeigenschaften) Gut zu wissen, dass die Daten durchaus nützlich verwertet werden.

Die Analysierungsmethoden von Zeller eignen sich besonders für objektorientierte Strukturen. Einige Kernaussagen seines Vortrages:

• Je nach Projekt greifen unterschiedliche Metriken (wie etwa Anzahl der Klassen, Anzahl von Methoden, Komplexität, Lines of Code, ...). Diese lassen sich allerdings nicht verallgemeinern und auf andere Projekte umlegen.


• Erfahrene Entwickler machen die meisten Fehler, denn sie arbeiten üblicherweise an den schwierigsten und komplexesten Modulen. (Wie z.B. bei Eclipse die CLASSPATH-Komponenten an denen auch Gurus wie Erich Gamma wiederholt scheitern)


• Auch intensives Testen eines Moduls heißt nicht, dass die Fehlerhäufigkeit dadurch geringer wäre - im Gegenteil, denn meistens testen Entwickler gerade jene Module besonders, die auch bisher schon die meisten Probleme machten. überhaupt können gute Entwickler instinktiv (wohl aus schmerzlicher Erfahrung) recht genau kritische Module bestimmen.


• Die (Fehler-)Vergangenheit eines Projektes ist entscheidend für die zukünftige Entwicklung. War eine Komponente in der Vergangenheit für viele Fehler verantwortlich, so wird sie das auch in Zukunft sein. Kann man auf keine ausreichenden Erfahrungsdaten zurückgreifen (etwa bei neuen Projekten) dann besteht die Möglichkeit Rückschlüsse über die Daten eines "sehr ähnlichen" Projekt ziehen zu können.


• Die Fehlerrate von Microsoft wäre nicht schlechter als der industrielle Schnitt, also etwa 1-2 Fehler pro Tausend Codezeilen.


• Die Open-Source Gemeinde mit ihren Aufzeichnungen liefert wertvolle frei verfügbare Daten für die Forschung in diesem Bereich (Mozilla und Eclipse wurden bereits analysiert)

Mehr dazu: The Software Evolution Project

Gerfried und Ich haben die letzten drei Tage in Wien verbracht. Simon hat uns schon länger eingeladen, ihn doch mal besuchen zu kommen, doch leider hat es bisher nicht so recht geklappt. Wir hatten recht angenehmes Wetter, wobei der Wiener Wind im Allgemeinen doch ein wenig gewöhnungsbedürftig ist.

Simon wohnt in einer tollen Wohnung im siebten Bezirk, die Innenstadt ist zu Fuß in wenigen Minuten erreicht - sprich: unsere 72 Stunden Karte für die öffentlichen Wiener Verkehrsmittel war ziemlich unnötig.

Zusammen mit Simon hatten wir nicht nur eine Menge Spaß und sehr gut gegessen, sondern auch etwas gearbeitet und viele Ideen besprochen. Siehe www.CREO.at.

Wir hatten auch die Gelegenheit uns mit der Wii anzufreunden. Als alter Freund von Nintendos NES-Spielkonsole (Nintendo Entertainment System) freut es mich zu sehen, dass die Firma scheinbar einen Weg gefunden hat, mit Spielspaß und Innovation im aktuellen Konsolenkampf zu bestehen.

Drei Tage waren natürlich viel zu kurz, so haben wir auch relativ wenig von Wien gesehen und haben auch die Entwicklung von Lit unter diesen zeitlichen Rahmenbedingungen nicht weiter vorrantreiben können.

Fazit: Nette Lokale, gutes Essen, interessante Leute und viel Spaß!

Dieser Weblog wird über das Wochenende nach blog.datentyp.org übersiedeln. Wer bestehendes Interesse daran hat, möge bitte Montag den neuen Feed abbonnieren. Mit dieser Umsiedlung verbunden ist auch der Umzug der elektronischen Postadresse, Mails an eine meiner bisherigen Postfächer könnten deshalb in nächster Zeit eventuell verloren gehen.

Update: Vollzogen! Das Blog ist umgezogen, die Redirects sind gesetzt. Einige Korrekturen sind allerdings noch vorzunehmen, so dass Feed-Bezieher in dieser Woche damit rechnen müssen, vermehrt ältere (bearbeitete) Beiträge als neu gekennzeichnet zu sehen.

Von dem Moment an, als Garr Reynolds erwähnte, dass Al Gore zu jener Sorte Rednern gehört - die mich sehr beeindrucken (wie Steve Jobs oder Lawrence Lessig) - wollte ich mich selbst davon überzeugen und seinen Film über Erderwärmung sehen.

Eigentlich hätte ich den Mann von dem gerne behauptet wird, er würde behaupten, er hätte das Internet erfunden im September 2001 in Wien auf der Ifabo (die soweit ich weiß, in diesem Jahr zum letzten Mal stattfand) treffen sollen. Doch zeitgleich planten einige Terroristen etwas ungleich weitreichenderes. Nun denn, hier also meine Nine-Eleven-Story: Am besagten 11.09.2001 waren Simon, Britta und Ich in Wien auf dieser IT-Messe um Material für unsere (Internet-)Radiosendung zu sammeln. Wie sich herausstellte war die Messe selbst ein einziger Reinfall, auf der Radio Seite konnten wir lediglich ein brauchbares Interview mit Dr. Hans G. Zeger, den Obmann von ARGE DATEN (österreichische Datenschutz/Privacy Organisation), verbuchen. Von Al Gore keine Spur. Enttäuscht verließen wir am späteren Vormittag das Messegelände um im Wiener Prater einzukehren. Dort liefen im Hintergrund zwei Fernseher, die irgendeinen mir bis dato völlig unbekannten Action-Film zeigten, mit täuschend echt wirkenden CNN Reportagen bestickt. Ich erinnere mich noch an meine Betroffheit auf der Heimfahrt, und an das Unbehagen darüber, dass ausgerechnet jetzt dieser nicht sehr überzeugende Herr George Walker Bush an der Spitze der USA stehen musste.

Etwa ein Jahr vorher bemühte sich Al Gore noch Präsident der Vereinigten Staaten von Amerika zu werden, wurde sogar von einer Mehrheit gewählt, allerdings dann doch nicht Präsident. Dazu muss man wissen, dass in den USA - im Gegensatz zu demokratisch orientierten Ländern - die Wahlen nur zur Beruhigung der Bevölkerung stattfinden, denn die eigentliche Entscheidungsmacht wird von den sogenannten Wahlmännern (siehe Electoral College) zugeteilt. In Deutschland erfolgt die Wahl des Bundespräsidenten übrigens nach einem ähnlichen Schema.

Nun, nach der gewonnen Wahl, war er wohl von seiner Arbeitslosigkeit überrascht. Diese gab ihm allerdings die Zeit seine alten Dia-Vorträge über Erwärmung multimedial aufzubereiten und damit durch das Land zu reisen und seine Mitmenschen über Umwelt und Klimawandel aufzuklären. Um mehr Menschen mit seiner Botschaft zu erreichen, wurde aus diesem Vortrag nun ein Film. Weiters erspart sich Al so wohl auch den einen oder anderen Trip in seinem ökologisch nicht sehr sinnvollem Privatjet...

Und gestern war es endlich soweit. Ich hatte hohe Erwartungen und wurde dennoch positiv überrascht. Ich fand den Film wirklich gut, und es tat mir ausnahmsweise mal nicht leid um das Eintrittsgeld.

Zum Inhalt folgendes:

Unser Umgang mit Treibhausgasemissionen, fossilen Brennstoffen, CO2 und der Umwelt allgemein, trägt unangenehme Früchte. Wie etwa die globale Erderwärmung, die uns allerdings gerade recht kommt, denn die nächste Eiszeit ist ohnehin längst überfällig und so hebt sich das ganze gegenseitig prima auf und wir können weitermachen wie gehabt! Nein, blöder Scherz. Guckt euch den Film einfach mal an. Besser heute als morgen.

Dieser Weblog ist ab heute auch unter www.datentyp.org erreichbar. Eventuelle Änderungen der bisherigen Newsfeed-Adresse werde ich hier, hoffentlich zeitnah genug, mitteilen.

Zur Registrierung kam es eigentlich recht spontan: In einem Usenet-Posting über Provider die Python 2.5 anbieten bin ich auf domainfactory aufmerksam geworden. Und dann führte ein Klick zum Nächsten. Hintergrund ist allerdings auch, dass Simon und ich beschlossen haben, theparallax.org, mittlerweile im siebten Bestehungsjahr, endgültig einzustellen. Umstellung, Auflösung und Rettung diverser Inhalte werden natürlich nicht von heute auf morgen geschehen; jedoch planen wir in den nächsten Wochen / Monaten das Seitensystem Schritt-für-Schritt in seiner bisherigen Form abzubauen und schließlich gänzlich aufzulösen.

Was war.

Einiges, dennoch: zu wenig. Gründe dafür wie immer vielfältig; Gerfrieds einjähriger Erasmus-Aufenthalt in Lille ist einer davon. Unsere Vorstellungen reifen immer mehr. Wir haben das Konzept mit vielen Leuten besprochen, wodurch die Zuversicht wächst, dass der Bedarf für die Umsetzung unserer Vorstellungen definitiv vorhanden ist.

Die Domain litproject.org wurde registriert; wir nutzen nun eine eigenfinanzierte Infrastrukur. Simon hat einen ersten UserInterfaceDesign-Prototypen (Client) entwickelt, der mir schon ziemlich gut gefällt. Wir hatten wiedermal viele Ideen für richtig interessante Features. Wir haben verschiedene Entwicklungs- und Finanzierungsvarianten diskutiert und wir haben uns Gedanken um die Software-Architektur und die technische Realisierung einzelner Module gemacht.

Was wird.

Wir werden mit den bisherigen Inhalten von lit.berlios.de umziehen. Simon wird seine Arbeiten am UID-Prototypen fortsetzen und sich um die Webseite kümmern. Wir werden endlich Zeit finden, um mit dem Code hacken anzufangen.

Es ist wieder mal soweit: November. Stressig wie immer. Wettertechnisch vermisse ich natürlich den warmen Sommer, und das Radeln. Der erste Schnee ist bereits gefallen und ein kalter Winter kündigt sich an.

Abseits von Uni sind Gerfried und ich derzeit heftig am Planen unserer eigenen Firma. Wir sind noch dabei diverse Optionen und Pflichten auszuloten, voraussichtlich wollen wir jedenfalls mit Anfang nächsten Jahres als Software-Entwicklungsfirma für andere Unternehmen das tun, was uns am meisten Spass macht.

Auch sonst bestätigt sich ein altbekanntes Phänomen wiedermal: Man entwickelt die besten Ideen und kann die größten Energien freisetzen, wenn man sich eigentlich mit etwas vollkommen anderen beschäftigen sollte. So tut sich bei Lit derzeit wieder einiges; aber dazu später mehr.