Comparison of One-Hop Distributed Hash Tables (DHT)

I just uploaded an old semester work, which I haven't published here yet, about a comparision of One-Hop DHT:

Distributed Hash Tables (DHT) are an important substrate of several peer-to-peer (P2P) applications. Most existing approaches favor a small memory and network overhead over lookup latency. New approaches question this tradeoff and allow a lookup with using only one hop, but they store the routing information for all nodes on each node in the system and so require higher background traffic to maintain the routing tables up-to-date. In this paper the design of three one-hop DHT approaches is described and compared in detail. This comparison shows that different assumptions are used to analyze the approaches. Therefore, several parameters are inspected and an uni- fied parameter setting is extract. Using the unified parameter setting, a fair and meaningful comparison of the approaches is possible. In particular, the bandwidth consumption, fault tolerance properties, the usage of heterogeneity in the P2P network, and the scalability are compared. The comparison shows that the unified parameter setting lead to different relative results as originally stated by the approach designers.

PDF

First paper accepted

My first paper has been accepted for publication at the SYSTOR'09 conference that takes place in Haifa at May 4-6.

It is based on the first part of my master thesis, but the contents has been extended and revised afterwards:

Data deduplication systems detect redundancies between data blocks to either reduce storage needs or to reduce network traffic. A class of deduplication systems splits the data stream into data blocks (chunks) and then finds exact duplicates of these blocks.

This paper compares the influence of different chunking approaches on multiple levels. On a macroscopic level, we compare the chunking approaches based on real-live user data in a weekly full backup scenario, both at a single point in time as well as over several weeks.

In addition, we analyze how small changes affect the deduplication ratio for different file types on a microscopic level for chunking approaches and delta encoding. An intuitive assumption is that small semantic changes on documents cause only small modifications in the binary representation of files, which would imply a high ratio of deduplication. We will show that this assumption is not valid for many important file types and that application specific chunking can help to further decrease storage capacity demands.

I really look forward to that conference because surprisingly many talks in the program look really interesting and it is my first chance to meet storage researchers outside the Fürstenallee.

Favorite PhD Comics

As newbie PhD student, I should know what to expect. Therefore I read besides xkcd the comic series, PhD Comics:
These are my favorites (in no particular order):

• The Lab/Office Couch:  Hangs beside my office couch, with reason! The legend states that another student rescued the printout out of a professor's trash can.
  
• Deadline: Happened yesterday
  
  
• Author List: That really explains a lot.
  
• Deciphering Academese: One of our prof. mentions in a similar fashion that "widely acknowledged" means "ask two other people on the same floor".
  
• Academic Salaries: Good to see that a PhD student in Germany gets a bit more. :-)
  
• Your Shrinking Sense of Humor: Were on that chart am I, when I like PhD Comics and xkcd?
  
• How long your Prof. thinks it should take to do something: My advisor has said something should take only a week, I'm still searching the technology that does it for me.
  
• Your Impact Factor: I have an impact factor of "Not a number" since "# original articles you've written" is, well, 0

Fertig: Master of Science

Gestern hab ich mit der Verteidigung meiner Masterarbeit mein Informatik-Studium abgeschlossen. Jubel!

Damit bin ich quasi "Master of Science".

Offiziell bin ich es natürlich erst, wenn dies auch durch das Prüf-Sek bestätigt wird. Aber außerhalb der Sprechstunden (Di-Do, 9:30-11:30) ist es mit dem Prüf-Sek so eine Sache (um es mal freundlich auszudrücken). Ob ich daher am Montag, wie geplant, im PC^2 starten kann, steht daher auch noch in den Sternen.

I will start at the Paderborn Center for Parallel Computing

With high probability, I will start as research assistent (aka PhD student) at the Paderborn Center for Parallel Computing.

There I will research in the area of storage systems, especially on the topic "data deduplication". It is really nice to be able to continue and complete the work of my master thesis.

Mac-Cluster an Virginia Tech

Da im PC^2 eh jeder Mitarbeiter einen Mac zu haben scheint, wäre es doch nur konsequent den Weg von Virginia Tech zu folgen, oder? 29 TeraFlop sind auch ein bisschen mehr als die 2,6 TeraFlops des Arminius-Clusters.

Do I want to go where the real action is?

The Linux Kernel Module Programming Guide:

You know C, you've written a few normal programs to run as processes, and now you want to get to where the real action is, to where a single wild pointer can wipe out your file system and a core dump means a reboot.

(Hervorhebung von mir)
Wollen? "Wollen" ist nicht der richtige Ausdruck, aber solange sich die iSCSI Target-Implementierung nicht ins Userland bewegt, muß ich mich in den Kernel bewegen. Ansonsten nix "Master of Science".

Google TechTalk: Fujaba-Storydiagramme

Fujaba-Storydriven Modeling (SDM) sind ein an der Uni Paderborn entwickelter Ansatz für General-Purpose-, visuelle, rein-modelbasierte Softwareentwicklung. Mit General-Purpose meine ich, dass es eine Modelsyntax für alle Domainen gibt, also kein unterschiedliches Meta-Modell für unterschiedliche Domains (DSL-Ansatz) mit jeweils problem-spezifischen Code-Generatoren. Das Story in SDM hat auch keinen Zusammenhang mit den Userstories in XP, ganz bestimmt nicht. SDM haben wir in der Vorlesung "Modellbasierte Softwareentwicklung" behandelt.

Gefallen hat mir der Ansatz nie: Zu unkompakt, komplex und unübersichtlich war mir immer die Syntax. Alle Beispiele aus der Vorlesung habe ich in Python und Java nachprogrammiert. Und Python war immer wesentlich lesbarer und kürzer als die Storydiagramme, Java auch in einigen Fällen. Der aus Storydiagrammen generierte Java-Code spottet jeder Beschreibung. Es wurde zwar in der Vorlesung behauptet, dass erfahrende Java-Entwickler Storydiagramme genau so in Code übersetzen würden, aber dann bin ich wohl nicht "erfahren".

Für mich waren Storydiagramme nicht das Silver Bullet, für das einige diese Modellierungssprache offensichtlich halten. Auch insgesamt bin ich von rein-modellbasierter Softwareentwicklung (das berühmte Zitat "Programmierer sind dumm" stammt auch aus der Vorlesung) nicht wirklich überzeugt.

Aber es gibt offensichtlich doch Leute, die sich dafür interessieren.
Der "Erfinder" Alfred Zundorf hat letzte Woche einen Google TechTalk gehalten:

Writing Code not beneath a Gentleman Engineer

Brian Cantrill (Entwicker von DTrace) schrieb in seinem Blog:

We suffer — tremendously — from a bias from traditional engineering that writing code is like digging a ditch: that it is a mundane activity best left to day labor — and certainly beneath the Gentleman Engineer. This belief is profoundly wrong because software is not like a dam or a superhighway or a power plant: in software, the blueprints _are_ the thing; the abstraction _is_ the machine.

Ich werde in der Universität oftmals komisch angesehen, wenn ich sage, dass in 10 Jahren noch Code schreiben will. Es kommt eben darauf an z.B. welchen Code bzw. Code wofür.

Keine Festival-Karten an der FÜ

In den vergangenen Wochen hab ich mit verschiedenen Freunden und Bekannten in der Fürstenallee (FÜ / FA / F-Gebäude) darüber gesprochen, dass der Uni-Mainstream oftmals zu tut als würde die FÜ nicht existieren.

Ein Beispiel war immer die fehlende Möglichkeit Uni-Party-Karten zu kaufen, insbesondere wenn es um die "große, offizielle" Uni-Party ging: dem Asta-Sommerfestival. Karten gab es an dem Uni-Campus, aber niemals an der Fürstenallee. Obwohl es viele Studenten (viele aus der Informatik und E-Technik in den höheren Semestern) gibt, die quasi niemals am Campus sind.

Ich hab bei der letzten Wahl gehofft, dass sich dieser Misstand legt, wenn wir genug Informatiker in das StuPa wählen, aber geändert hat sich nichts. Vermutlich hängen da immer noch genug Geisteswissenschafter im 20. Semester rum, die nichmal wissen, dass die FÜ existiert.

Heute hat die Fachschaft eine Mail herumgeschickt, die ich einfach mal kommentieren möchte:

Der Verkauf der Sommerfest-Karten an der Fürstenallee wurde uns [von der "Uni"]
verboten und wir mussten mit Kasse und Karten wieder abziehen.

Dass der AStA nicht von sich aus früh genug einen Verkauf an der
Fürstenallee einplant, obwohl das offizieller Standort der Uni ist und
viele Studierende sich gar nicht am Campus aufhalten halte ich für
traurig genug, dass uns der Verkauf dann verboten ist sollte aber eine
einmalige Sache sein.

Das die AStA es nicht packt, die FÜ ordentlich in den AStA-Teil des "Stundenleben" einzubinden, ist tatsächlich traurig. Schließlich sind wir (FÜ-Bewohner) genauso Teil der verfassten Studentenschaft. Der Kartenverkauf ist da eher ein Beispiel von vielen.

Schon die jetzige Planung - dass die Fachschaft Informatik selbst den Verkauf übernimmt und organisiert - war eher eine Minimallösung. Das nun nichtmal diese Minimallösung möglich ist, ist bitter.

• Warum erlaubt die Universität den Verkauf und die Veranstaltung am Campus und verbietet den Verkauf im F-Gebäude. Kann man von Informatiker-Diskriminierung sprechen?
• Wer genau hat dies verboten? Universitätsleitung oder der AstA?
• Gibt es eine zitierfähige Begründung für diesen Unsinn?

Zum Glück habe ich mich nicht darauf verlassen und habe schon am Dienstag (als ich einmal zufällig im Campus war) meine Karte gekauft.

Clay-Probleme mit "Jahr der Mathematik"

2008 ist das Jahr der Mathematik und in Paderborn gibt es dazu eine Vortragsreihe mit einigen interessanten Vorträen (während mich die Vorträe zum Jahr der Informatik eigentlich ziemlich kalt gelassen haben).

Zum Beispiel gibt Vorträe über die Clay-Probleme, offene mathematische Probleme für deren Lösung vom Clay Institute jeweils ein Preisgeld von einer Millionen Dollar ausgeschreiben wurde.

Es ging am 24. April los mit der Poincaré-Vermutung und der Hodge-Vermutung. 19. Juni geht es weiter zwei weiteren "Vermutungen" (Birch und Swinnerton-Dyer und Navier-Stokes-Gleichung)

Für Informatiker wohl am interessantesten sind die "Vermutungen", die am 4. Dezember vorgestellt werden. Prof. Hansen stellt die Yang-Mills-Quantentheorie vor. Prof. Bürgisser stellt vor, ob P=NP ist oder eben nicht. Prof. Wedhorn stellt die Riemannsche Vermutung vor.

Wer hat Lust zu diesen Veranstaltungen zu gehen?

IBM kauft Daten-Deduplication-Firma

Wie Golem berichtet hat IBM die Daten-Deduplication-Firma Diligent gekauft. Laut dem Bericht für vermutlich 200 Millionen Dollar.

Das Thema meiner Masterarbeit ist tatsächlich sehr heiß. Auch wenn ich die damalige Bemerkung "akademisch bisher kaum behandelt" nicht mehr so stehen lassen kann. Dafür ist meine To-Read-Liste bei CiteULike langsam zu lang geworden.

Pre-VKrit: Parallel Programming in Java

Ein Mitarbeiter der AG Kastens hat mich heute von meinem angestammten Arbeitsplatz (F1-Freifläche) verjagt. So richtig begeistert war ich nicht davon. Aber es ist das Zeichen, dass die Vorlesung "Parallel Programming in Java" gestartet ist ("Funktionale Programmierung" ist ja leider doch abgesagt worden).

Vor knapp einem halben Jahr hab ich in einer kleinen Artikelserie geschildert, warum ich von der Behandlung von paralleler Programmierung in "Grundlagen der Programmierung 2"(GP2) nicht richtig begeistert gewesen bin. Programme, mit denen Studenten parallele Programmierung beigebracht werden soll, sollten zumindest thread-safe sein und möglichst den empfohlenen Wegen entsprechen. Zum Beispiel wurde java.util.concurrent komplett ignoriert. Diese Artikel sind aber leider bei dem Server-Crash verloren gegangen.

Aber der "Rauswurf" hat mich auf die Idee gebracht Kastens-Material mal anzusehen. Ich nenne es mal "Pre-VKrit", aber im Grunde ist es nur ein Durchsehen der Vorlesungsfolien. Aufgefallen ist mir folgendes:

• Es geht mit bei dem bekannten DigiClock-Beispiel los, dass in GP2 daneben gegangen ist. Hier wurde aber die running-Variable als "volatile" deklariert. Damit ist das Programm dann auch thread-sicher. Es gibt immer noch Varianten, die für den Zweck einen Block in bestimmten Zeitintervallen auszuführen, die vielleicht besser sind (z.B. ScheduledThreadPoolExecutor), aber immerhin ist es thread-sicher es auf diese Weise zu machen.
• Auf Folie 25 wird java.util.concurrent vorgestellt und das locks-Unterpackage näher besprochen. Insbesondere wird fett markiert, dass die dort zu findenden Lock-Implementierungen die gleichen Speichersemantik haben wie die normale Synchronisation. Leider wird die Semantik des Speichermodells im Rest der Vorlesung mit keinem Wort erwähnt. Keine Ahnung, wieso man fett hervorhebt, dass zwei Konstrukte, die gleiche Speichersemantik haben, wenn man diese Speichersemantik nicht vorstellt.
• Die InterruptedException wird immer noch durchgängig sinnlos verwendet (catch (InterruptedException e) {}). Brian Goetz sagt in "Java Concurrency in Pratice", dass man mit einer InterrupedException vieles machen kann, aber man sollte sie niemals fangen und nur ignorieren.

Aber ansonsten fand ich die Folien jetzt recht gut. Ich würde sie hören, wenn nicht mein Softwaretechnikteil schon lange "voll" wäre. Die Vorlesung relativ stark ausgerichtet auf Datenparallelismus, wie sie im High-Performance-Computing wichtig ist, (Loop Transformation, etc) und weniger auf andere Muster wie parallele Programme strukturiert werden könnten (Active Object, Reactor, Fork-Join, etc.). Eine eher "Doug Lea"-orienterte Vorlesung hätte ich es spannender gefunden, aber auf Grund des PC^2 "in der Nähe" ist es wohl auch eine nachvollziehbare Schwerpunktsetzung.

Wer sich für das Thema interessiert und einen vielleicht etwas anderen Blickwinkel wünscht, sollte sich "Doug Lea: Concurrent Programming in Java" und "Java Concurrency in Practice" von Brian Goetz, Doug Lea, Josh Bloch und anderen aus der Bibliothek besorgen. Doug Leas Buch ist ist älter (2000, insbesondere pre-1.5), sehr muster-orientiert (aber kein Muster-Buch wie POSA2) und wirklich gut. Brian Goetz fügt insbesondere eine ausführliche Behandlung des "neuen" Java 1.5-Speichermodells hinzu und bespricht unter starker Berücksichtigung des java.util.concurrent-Paketes wie moderne, parallele Java-Programme strukturiert werden könnten. Das "JCiP"-Buch fand ich einfacher zu lesen.

Sopra: Softwarequalität bewusst niedrig gehalten

Ich schreibe gerade an einen Artikel über das "Softwaretechnikpraktikum" an der Universität Paderborn und wollte eigentlich begründen warum ich die alte Aufgabenstellung ("Shuttle-Simulation") trotz all der Probleme besser finde als die neue Aufgabenstellung ("dSpace Systemdesk").

Dazu lese ich gerade auch den Artikel "Ein verbessertes Softwaretechnikpraktikum: Zwischen grüner Wiese und Legacy-Systemen" in dem Björn Axenath und Stefan Henkler ihre Neukonzeption beschreiben. Vielleicht muß ich mir das nochmal überlegen.
Geschockt war ich als ich laß (Hervorhebung von mir):

In den letzten Jahren wurde den Studenten der undokumentierte Code eines komplexen, verteilten Systems [die Shuttle-Simulation] gegeben. [...]
Für einen Großteil der Studenten war dies die erste Begegnung mit einem großen Softwaresystem. Da es sich um ein Legacy-System handelte, war die Qualität bewußt niedrig gehalten.

Was? Bewusst?
Das ein System mit den Jahren verkümmert, kann ich ja noch irgendwie verstehen. Die bekannte Liste "realer" Architekturtypen von Brian Foote und Joseph Yoder (Big Ball of Mud) sind gleichzeitig Zeugniss und Warnung davor. Ich bin immer davon ausgegangen, dass dies eben unabsichtlich passiert ist, weil sich niemand um die Qualität gekümmert hat. Mein Eindruck war damals, dass es am Anfang durchaus als gutes System entwickelt wurde (z.B. konnte man die Überreste eines State-Pattern finden, wenn man genau hingeguckt hat) und die Qualität aber den späteren Entwicklern stumpf egal war.

Aber ein bewußt meises System zu entwickeln und frischen Studenten vorzusetzen, ist doch so ziemlich das Schlimmste was man machen kann: Das ist Anti-Code-Reading. Und wir wundern uns über die meise Softwarekonstruktionsfähigkeiten von Absolventen. Wo sollen sie es den gelernt haben, wenn selbst im berühmten Elfenbeinturm kein "Vorbild" vorgesetzt wird?

Sopra: Softwarequalität bewusst niedrig gehalten

Ich schreibe gerade an einen Artikel über das "Softwaretechnikpraktikum" an der Universität Paderborn und wollte eigentlich begründen warum ich die alte Aufgabenstellung ("Shuttle-Simulation") trotz all der Probleme besser finde als die neue Aufgabenstellung ("dSpace Systemdesk").

Dazu lese ich gerade auch den Artikel "Ein verbessertes Softwaretechnikpraktikum: Zwischen grüner Wiese und Legacy-Systemen" in dem Björn Axenath und Stefan Henkler ihre Neukonzeption beschreiben. Vielleicht muß ich mir das nochmal überlegen.
Geschockt war ich als ich laß (Hervorhebung von mir):

In den letzten Jahren wurde den Studenten der undokumentierte Code eines komplexen, verteilten Systems [die Shuttle-Simulation] gegeben. [...]
Für einen Großteil der Studenten war dies die erste Begegnung mit einem großen Softwaresystem. Da es sich um ein Legacy-System handelte, war die Qualität bewußt niedrig gehalten.

Was? Bewusst?
Das ein System mit den Jahren verkümmert, kann ich ja noch irgendwie verstehen. Die bekannte Liste "realer" Architekturtypen von Brian Foote und Joseph Yoder (Big Ball of Mud) sind gleichzeitig Zeugniss und Warnung davor. Ich bin immer davon ausgegangen, dass dies eben unabsichtlich passiert ist, weil sich niemand um die Qualität gekümmert hat. Mein Eindruck war damals, dass es am Anfang durchaus als gutes System entwickelt wurde (z.B. konnte man die Überreste eines State-Pattern finden, wenn man genau hingeguckt hat) und die Qualität aber den späteren Entwicklern stumpf egal war.

Aber ein bewußt meises System zu entwickeln und frischen Studenten vorzusetzen, ist doch so ziemlich das Schlimmste was man machen kann: Das ist Anti-Code-Reading. Und wir wundern uns über die meise Softwarekonstruktionsfähigkeiten von Absolventen. Wo sollen sie es den gelernt haben, wenn selbst im berühmten Elfenbeinturm kein "Vorbild" vorgesetzt wird?

Die Prüfungsordnung: Vertiefungsprüfung

Wie ich schon am 1. April geschrieben habe, ist am 9. April meine Vertiefungsprüfung im Masterstudiengang.

Die Vertiefungsprüfung im Masterstudiengang, oder "Abschlussprüfung" wie sie offiziell heißt, ist ausführlich festgelegt in §14 (4) Satz 1 und 2 festgelegt Master-Prüfungsordnung:

1. drei studienbegleitenden Modulprüfungen im Vertiefungsgebiet; eins dieser Module ist in
der Regel das Modul Projektgruppe mit einer dem Vertiefungsgebiet zugeordneten
Veranstaltung (26 Leistungspunkte), die beiden anderen bzw. gegebenenfalls alle drei
Module sind Wahlpflichtmodule mit einem Umfang von 8 Leistungspunkten,
2. einer mündlichen Abschlussprüfung über die Zusammenhänge der Inhalte aus den drei
Modulen unter Nr. 1

und §19 (2)

Die Gesamtnote errechnet sich aus dem gewichteten Durchschnitt der Noten aus [cut, siehe auch]. Dabei wird abweichend von den in § 16 Abs. 4 festgelegten Leistungspunkten die Projektgruppe mit 8 Punkten, die Abschlussprüfung mit 16 Punkten und die Masterarbeit mit 50 Punkten gewichtet.

Ende! Das wars. Mehr Festlegungen gibt es nicht bzw. mehr offizielles und öffentlich festgelegtes konnte ich nicht finden. Ich bin ja durchaus gegen diese "Hochschule als Verwaltungsorgan des Landes"-artige Überreglementierung, aber dies ist schon etwas arg wenig. Für 16 ECTS-Punkte also soviel wie 4 Master-Vorlesungen ist dies sehr viel Unklarheit!

Nur wenig mehr Klarheit besteht bei dem Begriff "Vertiefung" also den Veranstaltungen deren Zusammenhang Thema der Vertiefungsprüfung ist. Wie oben zitiert wurde, besteht die Vertiefung "in der Regel" aus
- der Projektgruppe
- zwei Modulen mit insgesamt vier Veranstaltungen davon mindestens einem Seminar (§16(7)).
All diese Veranstaltungen und die Projektgruppe müssen aus dem gleichen Informatikgebiet (SWT, ESS, MUA, MMWW) kommen (§16(2)).
Diese Variante ist wohl der Standardfall. Bei mir ist dies die Projektgruppe "ORCOS", das Seminar "Rechnernetze" bei Prof. Karl, "Betriebssysteme" bei Prof. Rammig, "Architektur paralleler Rechnersysteme" bei Jens Simon und "Speichersysteme" bei Andre Brinkmann.

Wenig bekannt ist die Alternative mit drei "normalen" Modulen aus dem Vertiefungsgebiet. Das "in der Regel" kann man dann getrost vergessen. Die Projektgruppe gilt dann als normales Modul in einem der anderen Bereiche und ersetzt das normale Module dort. Wichtig, die Projektgruppe muss dann dort eingebracht werden. Der Gesamt-"Workload" bleibt der Gleiche. Zum Beispiel könnte man eine Projektgruppe im Bereich "Modele und Algorithmen" machen, nichts anderen in dem Bereich und dann "Mensch-Maschine-Wechselwirkung" als Vertiefungsgebiet wählen und dort 6 Veranstaltungen absolvieren. Das Beispiel ist arg theoretisch, denn es gibt bekanntlich (in diesem Semester) keine Projektgruppe bei den "Theoretikern".

Laut Auskunft des Prüfungssekretariats muss man selbstständig einen Termin mit zwei Prüfern aus der Gruppe der Veranstalter der Vorlesungen im Vertiefungsgebietes vereinbaren und eine gewisse Frist vorher beim PrüfSek schriftlich anmelden. Dabei soll mindestens ein Prüfer auch Professor sein.
Die Rechtsgrundlage für diese Festlegungen sind mir nicht klar. Wie ist es geregelt, wenn kein Termin organisiert werden kann? Was passiert, wenn ich in meinen Vertiefungsveranstaltungen keinen Professor gehabt habe (schwierig, aber theoretisch denkbar?). Diese Fragen sind unklar.

Die wichtigste Unklarheit bleibt der Inhalt der Prüfungen:
Zur Erinnerung: "Abschlussprüfung über die Zusammenhänge der Inhalte" ist alles wir haben. Dies ist aber auch der entscheidende Unterschied zur DPO4-Vertiefungsprüfung. Es geht (mehr) um die Zusammenhänge zwischen den Inhalten der Veranstaltungen.

Meine Empfehlung ist mit den Prüfern vorher zu sprechen. Dies ist üblich und wirklich ratsam. Mit viel Glück schränken sie den Stoffumgang auch noch etwas ein.

Eine wichtige Frage ist der Umgang mit Seminaren. Muss man "fit" in allen Seminarthemen sein, oder reicht es wenn man sein eigenes Thema kennt. Dies handhaben die Prüfer wohl jeweils anders. Auch ist nicht in dem Fall sichergestellt, dass auch jeder Teilnehmer Zugang zu allen Ausarbeitungen hat.

Wichtig ist, auch die Prüfer daran zu erinnern, dass es sich um Prüfungen im Master handelt. Prof. Karl hat mir zwar mal gesagt, dass es mittlerweile jedem Prüfer glasklar sein sollte worin der Unterschied besteht. Aber ich bin zu lange an der Uni Paderborn, um daran nicht hin und wieder meine Zweifel zu haben.

Am 9.4 um 15:30 bis 15:45 kann ich mehr berichten.

Disclaimer: Bitte in Zweifelsfällen immer nochmals bei den verantwortlichen Stellen nachfragen. Ehrlich!

Ein glorreicher Tag: Die Projektgruppe ist beendet

Kein Aprilscherz: Gestern abend haben wir - die Ehre für das Softwareteam wurde mir überlassen - die Abgabeversion der Projektgruppe getaggt. Die Projektgruppe ist damit beendet. Hab ich schon mal gesagt, dass ich lieber bei SmartTeams hätte mitmachen sollen?

Nein, im Ernst: Ich bin froh, dass die Projektgruppe vorbei ist. Vielleicht schreibe ich dazu mal etwas mehr. Aber nicht heute.....

Nächste Schritt: Vertiefungsprüfung am 9. April.

VKrit: Philosphie der Technik

Nachdem ich vor zwei Jahren die gute, interessante Vorlesung zur Sozialphilosphie gehört habe und ich noch Punkte für das Studium Generale brauchte, hab ich im letzten Semester die Vorlesung "Philosphie der Technik" von Prof. Peckhaus gehört. Da Prof. Peckhaus auch im Vorstand des "Heinz Nixdorf Institutes" sitzt, klang auch erstmal nicht schlecht.

Ich nehme die Verantwortung des Ingenieurs durchaus ernst und auch deshalb habe ich gedacht, es könnte interessant werden. Und wurde bitter enttäuscht.

Der absolute Fokus der Vorlesung lag auf extrem technik-kritischen Kräften wie Martin Heidegger und Hans Jonas. Zum Beispiel geht es bei Jonas laut der Vorlesung nicht mehr um eine Risikoabschätzung und Bewertung alleine. Wenn eine Technologie, Erfindung oder Tat größere negative Folgen haben könnte - egal mit welcher Wahrscheinlichkeit oder welchen Umständen, nur die Möglichkeit zählt - dann sollte man die Erfindung nicht tätigen, nicht in die Richtung forschen oder etwas nicht tun. Ich glaube nicht, dass ich das so falsch sehen wenn ich sage, dass man mit dieser Leitlinie kann man Forschung und Technikanwendung einfach komplett einstellen kann.

Irgendwie konnte ich mich nie dem Gedanken verwehren es geht doch mehr darum, dass "kapitalistsche (-technische)" System an sich zu kritisieren als mir als Ingenieur sinnvolles Handwerkszeug in die Hände zu geben.

Die Unterlagen waren ziemlich schlecht und können von der Qualität nicht ansatzweise mit den Unterlagen wie sie in der Informatik üblich sind mithalten. Dass die Klausur trotz (mit etwas Abstand gesehen) sehr einfachen Fragen gar nicht so gut ausgefallen ist, lag weder an der Komplexität des Stoffes oder den Studenten sondern an den Unterlagen. Ein roter Faden fehlte meiner Meinung nach zum Beispiel komplett.

Zumindest im letzten Monat wurde sehr oft mit Videobeiträen gearbeitet, wo zum Beispiel gezeigt wurde das für ein tolles, vorbildliches, weil untechnisiertes Leben Heidegger in den Alpen führte. Ist dass richtig in einer Universtätsvorlesung? Man braucht sich dann auch nicht mehr zu wundern, wenn die Lehramtsstudenten (die meisten waren aus der Schiene) diese "Technik" in den späteren Unterricht übernehmen.

Mein Fazit ist nie wieder, aber mein Studium Generalle ist seit Mittwoch auch "voll". Es gab nur einen Grund weiter zu der Vorlesung zu gehen und der hatte mit Kaffee zu tun.

Plagiate

In guter Regelmäßigkeit wird durch Hochschulen bemängelt, dass Studenten Teile von Seminararbeiten oder sogar Diplomarbeiten aus dem Internet abschreiben: Ein Plagiat.

Und ich sehe keinen Grund so etwas zu verteidigen. Es missachtet die Arbeit des originalen Autors, stellt dem Prüfer in Abrede dies zu entdecken zu können und unfair gegenüber Mitstudenten, die ehrlich ihre Leistung erbracht haben.

Aber ohne Zweifel gibt es dies auch in der anderen Richtung. Spiegel online berichtet von einem Fall bei der ein Professor die Arbeit einer Studenten unter eigenem Namen veröffentlicht hat.

Vielleicht kann mir da mal jemand erklären. Wie kommen Wissenschafter darauf geistige Schöpfung von anderen zu nehmen und unter eigenen Namen in die Welt zu tragen? Wo ist die wissenschaftlich Ethik geblieben?

Seminararbeit Rechnernetze

In diesem Semester habe ich bei Professor Karl am Seminar "Rechnernetze" teilgenommen.

Meine Arbeit hat sich mit verteilten Hashtablen mit direkten Routing (One-Hop Distributed Hashtables) beschäftigt.

Abstract:

Distributed Hash Tables (DHT) are an important substrate of several peer-to- peer (P2P) applications. Most existing approaches favor a small memory and net- work overhead over lookup latency. New approaches question this tradeoff and allow a lookup with using only one hop, but they store the routing information for all nodes on each node in the system and so require higher background traffic to maintain the routing tables up-to-date. In this paper the design of three one-hop DHT approaches is described and compared in detail. This comparison shows that different assumptions are used to analyze the approaches. Therefore, several parameters are inspected and an uni- fied parameter setting is extract. Using the unified parameter setting, a fair and meaningful comparison of the approaches is possible. In particular, the bandwidth consumption, fault tolerance properties, the usage of heterogeneity in the P2P net- work, and the scalability are compared. The comparison shows that the unified parameter setting lead to different relative results as originally stated by the approach designers.

Download: PDF 1,2 MB