Thoughtlessly Thought Thoughts

Es gibt so Vorlesungen, die man sich wegen des Dozenten eigentlich schenken kann. Ich möchte hier jetzt keine Namen nennen, aber folgendes geht mir momentan ziemlich auf den Senkel:

Uno: Der Stoff der Vorlesung ,,Systemarchitektur” ist wohl einer der umfangreichsten im Hauptstudium (4 SWS, 2 SWS Tutorien). Der Dozent verschwendet seine Zeit mit nur mehr oder weniger sinnvollen Beispielen ,,aus dem richtigen Leben”. Bei diesen verbringt er dann einfach noch viel Zeit, indem er jeden möglichen Fall durchexerziert obwohl nach der zweiten Betrachtung klar ist, wie alles folgende funktioniert.

Beispiel: Kommunikation von Threads über eine ,,Mailbox”. Damit kann offensichtlich ein Thread, mit einem anderen kommunizieren. Einer mit mehreren oder mehrere mit einem! Dann gibt es natürlich noch 4 Fälle, welcher Thread der sendenen jetzt der langsamste ist und welcher der 4 empfangenden.

Dos (und eigentlicher Grund meines Unmuts): Der Dozent zitiert diverse Autoren und Mitglieder der Betriebssystem-Community (etwa einen Designer von Sun Solaris). Solaris behandelt Deadlocks nicht. Der Designer begründete das damit, dass sie innerhalb des Betriebssystems fast nie aufträten und außerhalb immer durch fehlerhafte Programmierung von Benutzerprogramen entstünden.

Darauf der Dozent: ,,Der Meinung kann man jetzt sein, ob das so richtig ist, weiß man nicht.” So, als ob gerade er die Lösung zum Problem der Deadlocks in seiner Schreibtischschublade oder sie gar schon umgesetzt hätte. Im Tanenbaum (eines der Standardwerke über Betriebssysteme) liest man dann, dass die theoretische Behandlung von Deadlocks zwar beim Beginn der Betriebssysteme ein großes Thema war heute aber in der Forschung keine Rolle mehr spielt. Man kann sie wohl gut auf Graphen zurückführen, wo sich dann Graphentheoretiker austoben können.

Auf spätere Nachfrage zu einem ähnlichen Kommentar, druckste der Dozent dann herum und behauptete, dass es bestimmt Systeme gäbe, die Deadlocks erkennen könnten. Gerade im Embedded-Bereich. Er könne gerade aber keins nennen.

Warum kann man nicht einfach sagen: ,,Das Ignorieren von Deadlocks ist zwar von einem akademischen Standpunkt aus nicht schön, es gibt aber weder eine theoretisch noch praktisch zufriedenstellende Lösung. Das Thema wurde ausführlich erforscht, aber man hat keine Lösung zur Laufzeit gefunden. Wir müssen wohl warten, bis eine Lösung vom Himmel fällt oder bis die Softwareverifikation weit genug ist, Deadlockfreiheit beweisen zu können. Die Informatik ist von der Lösung des Problems jedoch weit entfernt.”

Weil man dann gegenüber den Studierenden den Eindruck des Allwissens verliert? Besser, als die Glaubwürdigkeit zu verlieren!

Blickt man während des Studiums einmal über seinen Tellerrand hinaus dann zieht man den Kopf doch recht schnell wieder ein: Es gibt einfach viel zu viel zu wissen. Das merke ich zum Beispiel in meinem Studiengang Informatik und ich glaube, dass es kaum möglich ist, in einer ernstzunehmenden Fachrichtung alle angebotenen Veranstaltungen zu besuchen.

Und dann kommt noch der ,,ugh, das ist ja alles anders”-Effekt, der zum ,,das ist ja alles neu”-Effekt hinzu. Dies ist mir dieses Semester in meinem Seminar über die Wahrnehmung des Menschen beim Hören passiert: Das Thema ist zwar schon interessant aber irgendwie doch so sehr anders, neu und vor allem unüberblickbar viel.

Ein großes Problem ist vor allem der andere Ansatz der Psychologen (der von mir bearbeitete Text stammte von einem), die leider nicht so strukturiert arbeiten und beschreiben, wie ich das von den Mathematikern und Informatikern gewöhnt bin.

Nun, ich habe mich irgendwie durchgebissen, wen meine Ausarbeitung ,,Eigenschaften akustischer Objekte” interessiert, der findet sie hier (PDF)

Wer sich eine neue Digitalamera kauft, der muss damit rechnen, dass die Bildbearbeitungsprogramme wie iPhoto oder Photoshop erst einmal nicht mit dem RAW Format zurecht kommen. Klar: In jeder Kamera gibt es neue Features und das RAW Format ist ja nichts anderes als ein Moment-Abbild des Kamerazustandes beim Auslösen.

Eben dieses Erlebnis hatte ich vor rund zwei Monaten mit meiner Canon 400D: iPhoto konnte nur die die JPEGs lesen, kein RAW. Kurz nach dem Erscheinen der 400D auf der Photokina gab es dann eine Mac Os X Aktualisierung, die “Digitale Bilder.app” auf den neuesten Stand brachte, so dass ich die RAW-Dateien zumindest auf meinen Rechner bekam.

Man könnte sich jetzt denken, dass diese Aktualisierung die Bibliothek austauschte, die iPhoto zum RAW-Imprort benutzt aber weit gefehlt. Man könntet sich jetzt noch vorstellen, dass es zeitnah zum Betriebssystem-Upgrade eine Aktualisierung von iLife per “Software Update” gab. Wieder weit gefehlt.

Stattdessen fand ich heute auf Apples Seiten eine Datei zum Download die dort wohl schon einige Zeit liegt aber in noch keine neue Version von iLife integriert ist. Warum, liebe Apple-Leute, bringt ihr nicht einfach eine Aktualisierung für iLife über eure tolle Software-Upgrade heraus sondern lasst mich zufällig über den Link stolpern.

Etwas verärgert und verwirrt,

Manuel

Wer von euch noch nie etwas von SOA gehört hat, dem gehört sofort die Lizenz zum Denken an informatiktechnische Themen entzogen (”Die Gedanken sind frei, niemand kann sie erraten?” - nach Softwarepatenten und DRM gehört das blöde Lied ja wohl hoffentlich der Vergangenheit an). Also, zurück zum Thema.

Im Prinzip arbeiten doch alle in der Informatik und Informationstechnik doch ausschließlich der Softwaretechnik (kurz SWT, wir Informatiker lieben ja Abkürzungen - wie viele 3-Buchstabige es davon gibt kann man etwa in der Wikipedia finden zu. (Softwaretechnik = Wie baue ich meine Programme gut, toll, schnell etc.).

Und es will ja wohl hoffentlich keiner abstreiten, dass Service Oriented Architecture, kurz SOA (sprich sauer) das Architekturparadigma ist, dass alle anderen Architekturparadigma überflüssig macht! Grund genug, sich in der SWT ausschließlich mit SOA zur PS (Performancesteigerung) zb (zu befassen).

Naja, kommen wir zum Pudels Kern (PK): SOA Facts just made my day!

I have been searching for an easy way of writing XMLRPC servers in Ruby and letting them run on top of Mongrel for the last days.

I found some people who shared the problem but either they did not solve it or they never told anyone.

So I gave up my search for something that was already there and started hacking away my own code. The excellent Mongrel RDOC documentation made it clear that creating a Mongrel request handler would be a snap and after realizing this, I just had to port some of the code of Ruby’s standard library’s XMLRPC module CGIServer over to a Mongrel Request Handler.

The result is Proof Of Concept (.rb) script that allows to run a XMLRPC Server in Ruby on top of Mongrel. I’ll cut out the interesting code, add some tests and make it available for download over the next days (hopefully).

Maybe this will find its way into Mongrel’s or Ruby standard library’s code base one day…