AK's weblog

Nachdem ich in "Was nehmen für statische Seiten?" meine Requirements dargelegt habe, ich allerdings bis jetzt nichts passendes gefunden habe, habe ich mich kurzerhand hingesetzt und selbst ein Tool namens wsg ("website generator") gehackt und in mein Subversion-Repository getan. Das README beschreibt kurz, wie man wsg benutzt, ansonsten ist IMHO alles selbsterklärend (solange man schon mal mit eRuby gearbeitet hat). Und sobald ich meine eigene Internetseite damit neu gemacht habe, wird auch ein etwas umfangreicheres Beispiel vorhanden sein. Wie immer ist Feedback sehr willkommen.

Für Fans der Russendisko und generell den Büchern von Wladimir Kaminer kann ich sehr stark den Podcast Russendisko unplugged empfehlen, der den Charme der Bücher und vor allem der Hörbücher von Wladimir Kaminer in witzige und unterhaltsame Dialoge mit seinem Kollegen Yuriy Gurzhy verpackt.

So, heute geht (mit etwas Verzögerung) dieser Brief an die Beschwerdekommission raus. Und nachdem die ja verpflichtet sind, dem nachzugehen, und mir von dem Ergebnis zu berichten, wird das sicher ein Heidenspaß.

In den letzten paar Tagen wird in Deutschland ja über den wirklich unsinnigen Plan diskutiert, Hartz-IV-Empfänger als Wachpersonal in öffentlichen Verkehrsmitteln einzusetzen. Da ich ja für einige Zeit ein bisschen in dieses "Business" reinschnuppern durfte (beim Bundesheer Wachausbildung inkl. passender Schießübungen, dann ca. 10 Wachbereitschaften in 4 Monaten), meine ich, ein bisschen was dazu sagen zu können.

Ein so ein Wachdienst ist ja mit ein paar Rechten und Pflichten verbunden, die primäre Aufgabe in meinem Fall war es, Angriffe auf das Kasernengelände sowie Personen und militärische Rechtsgüter sowie andere subversive Bedrohungen abzuwehren. Dazu gehört einiges an rechtlichem Background, und es wird einer Wache relativ viel Verantwortung übergeben. Während der Wache muss man natürlich immer korrekt handeln, bei Ernstfällen verhältnismäßige Aktionen setzen, sonst kann es schnell passieren, dass man ein Wachvergehen passiert. Vor allem bei so Dingen wie Waffengebrauch ist das sehr sehr heikel (Achtung: Waffengebrauch != schießen, ein Waffengebrauch kann schon ein festeres Rempeln sein, siehe §§ 17 und 18 Militärbefugnisgesetz). Alles in allem ist der Wachdienst ein eher anstrengender Job, zu dem viel Konzentration und Selbstbeherrschung dazugehört, um sowohl die notwendige Wachsamkeit als auch die erforderliche Verhältnismäßigkeit an den Tag zu legen.

Und natürlich ist es auch so, dass man mit der auferlegten Verantwortung auch einen gewisses Maß an Gewalt oder "Macht" zur Verfügung hat, um den Wachauftrag auch dementsprechend durchzusetzen.

Wenn ich mir jetzt überlege, in welchem geistigen Zustand sich der durchschnittliche Hartz-IV-Empfänger befindet, nämlich frustriert ob der schlechten Bezahlung, des aufgezwungenen Jobs, so sehe ich nicht das nötige Engagement, dass diese Aufgabe dann auch dementsprechend erfüllt wird. In Ausbildung wird bei diesen Hilfs-Sheriffen ja wohl kaum investiert werden, und zu was schlecht ausgebildetes Wachpersonal führen kann, weiß man nur zu gut seit dem Stanford-Prison-Experiment. Macht und die Möglichkeit der Machtausübung führt ohne die notwendige Disziplin und ohne unmittelbare Kontrolle (nicht ohne Grund ist bei der Wache meist der OvT in der Nähe, und in größeren Kasernen ist der Wachkommandant sowieso ein Soldat im Unteroffiziersrang) schnell zu Machtmissbrauch.

Und das ist genau der Punkt, warum der Vorschlag, Hartz-IV-Empfänger als Wachpersonal einzusetzen, äußerst fragwürdig ist. Abgesehen davon, dass ein gewisses Blockwart-Klima aufkommen würde, es würde nichts bringen, sondern nur Probleme herbeiführen. Nein, was man in Hollywood-Szenarien wie einem Attentat auf öffentliche Verkehrsmittel braucht, sind couragierte Bürger, welche die ihnen bereits durch bestehendes Recht zugesicherten Möglichkeiten, einzugreifen, nutzen, nämlich in Form des "Festhalterechts" oder "Jedermannrechts", welches in Österreich in § 86 Abs. 2 Strafprozessordnung geregelt ist.

Ich bin mit meiner derzeitigen Lösung, wie ich die HTML-Seiten von http://synflood.at/ generiere, nämlich WML (Website Meta Language), nicht wirklich zufrieden. Einfach, weil WML an vielen Stellen eine eher krude Syntax im Einsatz hat (kein Wunder bei den 9 Filtern, durch die jedes WML-Dokument geht, bis am Ende HTML rauskommt), es ist langsam (siehe voriges Argument), es wird zum Scripting Perl eingesetzt (welcome to the 1990s), und last but not least: es wird nicht mehr maintained.

Richard hatte mir empfohlen, m4 einzusetzen, nur davor scheue ich mich etwas, auch wegen der kruden m4-Syntax. Kann mir in der Richtung irgendwer was empfehlen? Was ich brauche ist im wesentlichen ein schnelles Template-System, es muss skriptbar sein in einer angenehmen Sprache, und es sollte Ausgabeformatagnostisch sein (i.e. es spießt nicht, wenn ich WML [Wireless Markup Language] oder Textdateien generieren will). Über Hinweise würde ich mich freuen. Falls es keine Hinweise gibt, dann werde ich mir wohl selber was bauen (müssen), möglicherweise auf eRuby-Basis.

Ich bin einer, der kocht gerne ohne konkrete Rezepte, also allerhöchstens mit einer Auflistung der Zutaten, die Dosierung übernehme ich dann selber, frei nach Gefühl. Sich an Mengenangaben zu halten, finde ich kreativitätstötend. Und so hab ich mich heute hingesetzt, und mir Cheeseburger gemacht. Zuerst habe ich gemischtes Faschiertes genommen, ordentlich gesalzen und gepfeffert, ein Ei reingeschlagen, und das durchgemischt. Daraus habe ich das Fleischlaibchen geformt, und diese dann in einer heißen Pfanne mit ein wenig Öl (ich verwende meistens Rapsöl, weil es faktisch keinen Eigengeschmack aufweist) beidseitig scharf angebraten, bis das Fleisch ca. medium durchgebraten war. Dann habe ich die Fleischlaibchen genommen, mit je einer Scheibe Emmentaler belegt, und dann noch für ein paar Minuten in den vorgeheizten Ofen geschoben, bis der Käse geschmolzen war, dann herausgenommen, jedes Laibchen in ein halbiertes Semmerl gelegt, und etwas Ketchup (Heinz Tomato Ketchup kann ich neben dem McDonald's-Ketchup sehr empfehlen) dazugetan, und dann natürlich gegessen.

Das Anbraten und dann das gar werden lassen (sp.?) im Ofen haben in meinem Fall übrigens dazu geführt, dass das Fleischlaibchen innen äußerst saftig und dadurch sehr schmackhaft geworden ist, wesentlich besser, als es durch normales Braten in der Pfanne normalerweise wird. Viel Spaß beim Nachkochen!

Andreas Bogk hat ja kürzlich den Prüfbericht zu den NEDAP-Wahlmaschinen auseinandergenommen, und etwas ausführlicher darüber im netzpolitik.org-Podcast berichtet. Gerade letzteres ist hochinteressant, und ich hab ein paar der Argumente pro Wahlcomputer durchgedacht, und bin auf eine ganz simple Lösung gekommen:

Das Argument, mit dem Wahlcomputer eingeführt werden, ist eine effizientere und schnellere Ermittlung des Ergebnisses. Das große Manko, das die bisherigen Lösungen allerdings haben, ist die fehlende Nachvollziehbarkeit und Sicherheit. Papier dagegen macht das Zählen relativ langwierig, während dafür die Manipulierbarkeit stark eingeschränkt ist. Warum also nicht das beste aus beiden Welten kombinieren?

Mein simpler, naiver Lösungsansatz ist: verwendet Wahlcomputer, aber implementiert eine Fallbacklösung! Und zwar so, dass man einen Wahlcomputer verwendet, der die Stimme elektronisch zählt, und dazu zusätzlich einen Ausdruck davon, was man gewählt hat, macht. Diesen Ausdruck tut man dann in einen Umschlag, und wirft ihn in eine traditionelle Wahlurne. Für das erste Ergebnis kann man dann das gezählte Ergebnis des Computers verwenden. Sollten an dem Ergebnis des Computers Zweifel aufkommen (z.B. durch Abweichungen der Wahlergebnisse von den Exit Polls, hallo USA, hallo Mexiko!), so hat man immer noch die Wahlurne, die man dann hernehmen kann, und mit dessen Inhalt man eine Nachzählung durchführen kann. Bei Abweichungen gilt dann natürlich das Ergebnis der ausgedruckten Wahlzettel aus der Urne. Diese Lösung geht übrigens auch das Problem an, dass z.B. die Wahlcomputer ausfallen. Und eine langsame, ineffiziente, teure Methode (um mal die Polemik gegen das "alte" System zu verwenden) zum Stimmen abgeben ist immer noch garkeine Möglichkeit, seine Stimme abzugeben, oder? (sollten sich Politiker gegen dieses Argument stellen, so weiß man, die Zeit ist reif, um die an die Wand zu stellen)

Erst vor ein paar Tagen hab ich ein wirklichen cooles, neues Tool von OSX gefunden, und zwar Grapher.app in /Applications/Utilities. Damit kann man alle möglichen Funktionen visualisieren, im 2- und 3-dimensionalen Raum, mit kartesischem Koordinaten, Polarkoordinaten, das ganze auch logarithmisch, usw. Und das tolle ist: man tippt das, was man dargestellt haben will, einfach ein, und es funktioniert. Sogar für Leute wie mich, die von Mathematik keine Ahnung (mehr) haben. Bei Mac OS 9 war sowas zwar auch schon dabei, aber da musste man immer auf y bzw. z (je nach Anzahl der Dimensionen) umformen, und Variablen, wie unten im Beispiel verwendet, konnte man auch nicht verwenden.

Ich hab als kleines Beispiel eine Kummerfläche (evtl. bekannt von den alten SuSE-Schachteln und Manuals) dargestellt:

Tja. Und Windows hat einen Taschenrechner.

I just submitted my paper for 23C3. This year I wrote a paper about trapdoor2, which I wrote together with Clifford. I will focus on its implementation and use it as an example to show what attack vectors against a network server (and especially trapdoor2) exist, and what techniques can be employed to encounter potential attacks. Look forward to a pretty interesting lecture, showing some state of the art techniques in secure network server programming in C on Unix and Unix-like operating systems.

Well, be warned that this comparison is highly unscientific and makes no claims about the overall performance of the mentioned webservers. Anyway, I played with JMeter a little bit this evening, and defined the following test scenario: 5 parallel threads make 500 requests each, each of these requests downloads a small file of 35 bytes. I compared cwapd, the webserver that I based on my HTTP stack, swebd, which nion wrote for an exercise at university, Apache 2.0.55, gatling (the webserver which Fefe used to do his scalability benchmarks) and thttpd. All I was interested in was the through-put, i.e. how many requests per second each server was able to handle. And here are the results:

• cwapd: 93.6 req/s (with a 30.3 % error rate due to some problems with the multithreading, I suppose; the only test candidate with an error rate > 0.0 % at all)
• swebd: 188.2 req/s (not bad for a forking webserver)
• Apache: 412.3 req/s
• thttpd: 448.8 req/s
• gatling: 973.5 req/s (!!! and the best thing: running gatling with whatever load on it never increased the total system load by more than 1!)

I knew that gatling would be a good performer, but I never expected it to be so much better than the others. And in case you don't believe me: download the test plan. The machine on which I did the tests was a 400 MHz AMD K6-2 with 384 MB RAM (not really great, I know, but it works), and JMeter was running on my brand-new MacBook Pro, and never had any significant impact on the Mac's system load.

ndbm is library standardized by SuSv3 to store arbitrary key/value pairs into a file. Out of boredom, I wrote a small and simple implementation of it for dietlibc. The format it implements is incompatible with other ndbm implementations. I compared my implementation with BerkeleyDB and GDBM (which both feature ndbm compatibility modes), and while my implementation is a lot slower, the size of my data files is about 50 to 60 % of the ones produced by BDB and GDBM.

You can download the patch here. I submitted this patch to the dietlibc author, and he found it cool, but hasn't integrated it into dietlibc yet. Oh, and in case anybody asks what software I use to manage my dietlibc patches: I use StGIT on top of git. I have a local copy of the CVS repository, and with StGIT, I can manage the patches in a stack (similar to Andrew Morton's patch scripts and transvn) and keep everything up to date if any changes in the CVS repository or on any patch are done.

Gestern hab ich endlich Zeit gefunden, mir Call of Duty 2 für den Mac zuzulegen (leider nicht auf Englisch - nicht mal der McShark kann's auf Englisch bestellen). Auf jeden Fall hab ich gestern von ca. 16:00 an bis vor ein paar Minuten alle Missionen durchgespielt, unterbrochen nur durch einmal einkaufen gehen und schlafen. Ich muss sagen: das Spiel entspricht voll und ganz meinen Erwartungen, wenn auch die deutsche Lokalisierung ein paar kleine Probleme bereitet, wie etwa dass man die Anweisungen der eigenen Truppe nicht vom Geschrei der Deutschen unterscheiden kann - beides ist ja deutsch. In der englischen Demo, über die ich auf CoD2 gestoßen bin, war das noch wesentlich angenehmer. Andererseits wurden bei der Lokalisierungsarbeit kleine Fehler gemacht, und dann hört man mitten in Stalingrad die Warnung von einer amerikanischen Granate. Allerdings war das Länder-Granaten-Problem das einzige, das ich gefunden habe.

Nun zum eigentlichen Spiel: die Stimmung ist allgemein sehr beklemmend, das gesamte Spielerlebnis ist äußerst intensiv, intensiver als in jedem anderen Spiel, das ich bisher gespielt habe. Auch die Inszenierung als solches trägt dazu bei: die Kämpfe bestehen nicht nur aus simplem Vorstoßen, Vorstoßen, Vorstoßen, sondern es gibt auch immer wieder Situation, wo man sich zurückziehen muss. Außerdem werden so Situationen wie ein naher Artillerieangriff oder das Einschlagen eines Geschoßes aus einer Panzerkanone mit dem "Saving-Private-Ryan-Effekt" theatralisiert, das heisst dumpferes Hören, langsamere Wahrnehmung, eben so wie in der Eröffnungsszene von eben diesem Film.

Was ich übrigens auch noch positiv anmerken muss: bei diesem Spiel wurde offenbar bewusst nicht auf die Darstellung von Blut verzichtet, dadurch erhielt das Spiel auch keine Jugendfreigabe. Alles in allem ein wirklich gelungenes Spiel, das meine Erwartungen aus dem Demo bei weitem übertrifft.

I put even more work into Liam this weekend, and added and improved several things. For example, it is now possible to save attachments or even complete mails to your local file system. I improved handling of MIME types with attachments, including choosing the best encoding for the mail body and each attachment. And even such small things as defining a signoff string, a signature file or your preferred editor have been implemented. The performance issues that I previously experienced with the file browser are no more, I was able to identify the problem and fix it.

And so far, I only have a few more big TODOs on my list, like moving mails to other folders, a search function, a notification when new mails arrive while the mailbox is open and a scripting interface to make Liam scriptable and more customizable. Support for other protocols and storage formats is also missing, but e.g. support for Maildir(++) and MBOX should be pretty easy to implement. What I also have in my mind is a (hear! hear!) disconnected mode that should make it possible to read mails that have been downloaded previously, but that lies a bit farther in the future.

That's my status report so far, feedback is as usual welcome.

This week, I put quite a lot of effort into pushing Liam further in terms of features. It is now a quite nice mail client, already. What you can currently do is send mails, reply to mails, forward mails (even as attachments, just like Thunderbird does it) and attach files to mails with a nice file browser. You can view mails, viewed mails will be marked as seen. You can mark already seen mails as unread. You can mark mails as deleted, and then expunge them from the mailbox. Mails marked as deleted can also be undeleted as long as haven't been expunged. When you reply to a message, it will be marked as "answered" on the server. This is also shown in the mailbox view. You can flag messages. You can define a "header filter" which describes which headers shall be shown in the mail view. If you don't define such a filter, all headers will be shown. And even documentation for everything is available, in DocBook format. This feature list might not look really long, but remember, this is all the achievement of less than a week!

If you want to try out Liam, just check it out from the SVN repo. Liam depends on several external packages, such as Ruby 1.8, STFL and RubyMail. STFL is noteworthy because currently you need this patch to fix a bug in STFL and to add a new widget and probably this and this patch if you have troubles building it. And don't forget to install swig before building STFL as it is required to build the Ruby bindings.

If you managed to get Liam running after all that, look at liamrc.example and create your own ~/.liamrc after it. As usual, feedback is welcome. If you're eager to help with Liam development, don't hesitate to look at the TODO list, hack away and send patches. So far, I would like to thank Michael Prokop for his huge amount of valuable input and for trying out Liam in this early stage.

After the generally positive feedback that I got for the first few steps with my prototypical IMAP client, I put further effort into it, and implemented cool features like replying, group-replying (aka "Reply All") and sending mails. Currently, the only transport protocol implemented is SMTP, but I made everything as generalized as feasible, so replacing SMTP with e.g. the local "sendmail" command wouldn't be much of an effort. In addition, I added (hear! hear!) support for showing threads. This means that threads of email discussions, be it a long conversation between you and a friend or a discussion on a mailing list, is shown in its structure. Again, I compiled a feature show of new features since the last posting as screencast.