Bei all der Abstraktion von der physikalischen Hardwareplattform, mit der heutige Anwendungsentwickler beim Einsatz von auf virtuellen Maschinen basierenden Programmiersprachen wie Java, C# und allen .NET-basierten Sprachen heutzutage wie selbstverständlich umgehen, darf man nie die unumstößliche Tatsache vergessen, dass jedes Stückchen Code letztlich auf einem realen Prozessor ausgeführt und jede Instanz einer Klasse in realem - und das heißt vor allem: in seiner Größe begrenzten - Arbeitsspeicher abgelegt werden muss. Nicht selten ist das Vergessen oder Verdrängen dieses Fakts der Grund für zwar theoretisch ganz toll und elegant aussehende Routinen und Datenmodelle, die sich im realen Betrieb aber dann als überraschend ineffizient und/oder speicherhungrig erweisen.

Grundkenntnisse über die verwendete Prozessorarchitektur lohnen sich daher auch für einen Anwendungsentwickler, der mit maschinennaher Programmierung in C oder gar Assembler nichts am Hut hat. Dasselbe gilt für Kenntnisse über den Aufbau der in der jeweiligen Sprache gängigen Datenstrukturen im Speicher. Derartiges Wissen kann helfen, den "Memory Footprint" einer Software schon im Vorfeld möglichst niedrig zu halten - oder ihn im Bedarfsfall mit möglichst wenig Aufwand zu reduzieren. Ein paar kleine Tricks haben hier mitunter durchschlagende Wirkung.

Seit Sonntag ist es DAS Gesprächsthema im Netz: Die Aufzeichnung von Faustschlägen ins Gesicht, die ein Teilnehmer der "Freiheit statt Angst"-Demo am 12.9. in Berlin von einer Einheit der dortigen Polizei kassierte. Die Bilder sind in der Tat sehr verstörend, und auch ein später aufgetauchtes Video der 30 Sekunden vor der Konfrontation liefert keinen Anhaltspunkt, was den prügelnden Polizisten zur Tat veranlasst haben könnte - jedenfalls keinen, der die Schläge mitten ins Gesicht in irgendeiner Weise auch nur annähernd verhältnismäßig erscheinen lassen könnte.

Über die etwas lachhafte Pressemitteilung der Berliner Polizeibehörde, in der alles Mögliche (teilweise schon durch aufmerksames Betrachten der Videos widerlegbare) irgendwie zur Relativierung des Fehlverhaltens herangezogen wird, will ich mich jetzt nicht weiter auslassen. Von der Gegenseite, d.h. dem Prügelopfer selbst, gibt es ja auch eine Gegenerklärung, der sehr viel mehr mit den Videoaufzeichnungen in Einklang stehende Hintergrundinformationen zu entnehmen sind.

Viel mehr beschäftigt mich ein langer Thread in einem privaten und öffentlich einsehbaren Polizisten-Forum, in dem sowohl andere Polizisten als auch jede Menge Zivilisten den Vorfall diskutieren.

Patch 3.2 ist mit dem heutigen Tag genau eine Woche auf den Live-Servern - Zeit für einen kleinen ersten Rückblick. Wie die meisten großen Content-Patches in World of Warcraft lieferte 3.2 einen neuen Raid-Dungeon, eine neue 5er-Instanz, einige neue (Daily-)Quests, viele neue Rezepte und noch zahllose Detailveränderungen wie diverse Änderungen an der Spielmechanik mancher Klassen. Aber dröseln wir das lieber im Einzelnen auf...

Das Single-Sign-On-System OpenID ist seit einigen Jahren immer mehr in aller Munde - speziell nachdem sich in jüngerer Zeit diverse Branchengrößen wie Google, Yahoo, Facebook und noch einige mehr dazu entschlossen haben, OpenID zu unterstützen. An und für sich ist das Verfahren auch bestechend gut durchdacht: statt für jeden Webdienst eine weitere Username/Passwort-Kombination für den Login zu benötigen, authentifiziert man sich nach Angabe seiner OpenID - die nichts weiter ist als eine URL zu einem OpenID-Provider mit irgendeiner individuellen Komponente, z.B. "http://maxmueller.myid.net" - beim OpenID-Provider mit nur einem einzigen Passwort, der einen anschließend wieder zum gewünschten Webdienst zurückleitet und diesem im Hintergrund Bescheid gibt, dass der User tatsächlich derjenige ist für den er sich ausgibt. Klarer Vorteil aus User-Sicht: OpenID plus Passwort genügen für die Authentifizierung bei allen Diensten, die einen Login per OpenID anbieten. Vorteil aus Security-Sicht: die Credentials (also das Passwort im einfachsten Fall - könnte aber auch eine Zwei-Faktor-Authentifizierung sein) landen nie beim Webdienst selbst, sondern immer nur beim OpenID-Provider, jedenfalls wenn der User aufmerksam ist und etwaige Versuche eines Dienstes, ihn auf "nachgemachte" Provider-Login-Seiten zu leiten, erkennt.

Klingt ja eigentlich ganz gut - hat in der jetzigen Realisierung nur einen kleinen Makel: es gibt zu wenig OpenID-fähige Webdienste, die einen Login per OpenID erlauben - in der OpenID-Lingo "Consumer" genannt. Selbst die ganzen großen Namen, die sich in der Vergangenheit zu OpenID "bekannt" haben, treten in vielen Fällen leider nur als sogenannte Provider auf, stellen also den bei ihnen registrierten Nutzern eine OpenID-URL zur Verfügung, mit der sie sich bei anderen Diensten authentifizieren könnten. Ein Login etwa bei Google-Diensten oder bei Facebook via OpenID ist meines Wissens nicht möglich - genau darum geht es aber doch: die ausufernde Zahl an Login-Credentials einzudämmen, und das schließt auch Logins bei großen Diensten ein. Diese scheinen sich aber bisher besser in der Rolle des Identity-Providers zu gefallen - aus betriebswirtschaftlicher Sicht ist das sogar logisch: als Identity-Provider erhältst du Pageviews bei jedem Login-Versuch eines deiner User bei einem beliebigen anderen OpenID-Consumer und du erhältst interessante Daten wie Informationen über die Dienste, bei denen sich ihre User einloggen. Das lässt schon eine negative Seite an OpenID erahnen - es verschafft den großen Profilern der Internet-Welt noch mehr Informationen - aber um die soll es in diesem Posting nicht gehen (wahrscheinlich schreib ich dazu in einem separaten Posting noch mal ausführlich was). Hier soll es im Folgenden darum gehen, wie man als Webentwickler seine Website für einen Login per OpenID fit machen kann.

Nachdem ich in meinem Laptop schon seit einigen Monaten eine Intel X25-M mit 80 GByte als Festplatte einsetze und von der Geschwindigkeitssteigerung vor allem bei Routinetätigkeiten, die typischerweise mit mehr oder weniger langen Wartezeiten verbunden sind (Laptop hochfahren, Programme starten, Daten hin- und herkopieren, große Dateien in Programme laden, Windows-Updates einspielen, WoW zocken ;-) ) einfach nur hin und weg war, hab ich mich für meinen Desktop-Rechner auch zum Kauf einer SSD als Systemplattenersatz entschlossen. Größere Mengen von Daten darauf zu lagern ist in den meisten Fällen grober Unfug, dafür ist der Preis pro Megabyte einer brauchbaren SSD einfach zu hoch, aber für eine Systemplatte sind die Eigenschaften moderner SSDs perfekt: blitzschnelle Zugriffszeiten auch bei Random-Zugriffen und hohe Datenraten auch beim Lesen oder Schreiben kleiner Dateien. Und für eine Systemplatte braucht es keine Terabytes - 128 Gigabyte würden für meinen Desktop-Rechner mit reichlich installierten Programmen vollkommen reichen, also hab ich bei einem passenden Angebot bei ZackZack zugeschnappt und die damals, d.h. vor 5 Wochen, noch brandneue Falcon von G.Skill für vergleichsweise wenig Geld bekommen können.

Dass ich mich dabei auf ein kleines Abenteuer einlassen würde war mir zum Kaufzeitpunkt natürlich nicht bewusst; alles was ich wusste ist, dass die Falcon eine der wenigen SSDs ist, die für mich überhaupt in Frage kommen.

Nun ist's also so weit: Wir haben offiziell keinen unzensierten Internetzugang mehr. Gut, das Gesetz muss noch durch den Bundesrat, Köhler muss es unterzeichnen, es muss veröffentlicht und dann durch die Provider umgesetzt werden - aber das ist alles nur eine Frage der Zeit. Aus dem Bundesrat ist kein überraschender Widerstand zu erwarten, Köhler hat uns in dieser Beziehung schon bei der Vorratsdatenspeicherung maßlos enttäuscht, und die Provider sind zur Umsetzung ohnehin gezwungen.

Bleibt nur der Gang zum Verfassungsgericht, der wenig überraschend schon vorbereitet wird. Da hab ich wiederum schon eine gewisse Hoffnung auf Erfolg, aber die verfassungsgerichtlichen Mühlen mahlen langsam (wie man an der immer noch ausstehenden finalen Entscheidung zur Vorratsdatenspeicherung erkennen kann - zugegeben, das ist hochkomplexe und heikle Materie, da dort die europäische Gesetzgebung mit reinspielt, aber die Verfassungsklage ist ja nun schon seit mehreren Jahren anhängig...). Während dieser Zeit des Wartens besteht die dringende Gefahr, dass die ganzen üblichen Lobbyisten und Trittbrettfahrer aus der RaubkopiermordterroristenGlücksspielKillerspieleUndDerhatmichaufwikipediadummesaugenannt-Fraktion, die mit Brief und Siegel garantiert in den nächsten Wochen und Monaten aus ihren Löchern kriechen, erste Ausweitungen des neuen Gesetzes erreichen oder zumindest den Boden dafür bereiten können.

Wie real diese Gefahr ist, zeigt uns freundlicherweise Thomas Strobl (CDU). Man beachte das Datum der Mitteilung: das wurde kurz nach der Abstimmung kundgetan und ist nicht die olle Kamelle von vor einer Woche, auch wenns derselbe Politiker mit derselben Forderung ist - der angeblich nicht die Meinung der Partei ausdrückt, wie es gestern bei der Plenarsitzung zur Verabschiedung des Gesetzes zum Ausdruck kam, aber wer weiß, wie lange das noch der Fall ist oder ob das nicht sowieso nur eine wahltaktische Äußerung war?. Als Computerspieler bekomme ich interessanterweise nur bei solchem inkompetenten Gebrabbel immer die Art von "Aggressionen", die angeblich von den ach so gefährlichen "Killerspielen" geschürt werden sollen. Wird es daher Zeit, Politikeraussagen zu zensieren?

Interessant war es in jedem Fall, dem ganzen Schauspiel gestern zuzusehen. Jörg Tauss wurde rüde von einem SPD-"Kollegen" abgebügelt, als er eine Frage während seiner Ansprache loswerden wollte, und durfte diese erst später noch stellen. Praktisch alle Argumente gegen Websperren sind zur Sprache gekommen - wenngleich man das zumindest bei den Parteien der großen Koalition wohl als wahltaktisches "wir-verstehen-eure-Bedenken-ja"-Getue auslegen kann. Zensursula selbst war während der Debatten und der Abstimmung gar nicht mehr anwesend (hatte sie Angst, dass sie doch noch zu ihren mittlerweile nachgewiesenermaßen überzogenen, falschen und erfundenen Zahlen und Argumenten Stellung nehmen muss?). Und während der Abstimmung hat der Tauss dann noch eine sehr nette persönliche Rede gehalten.

Interessant, aber letztlich einfach nur deprimierend...

...wo sind wir? Richtig: im Straßenverkehr! Jedes Kind kriegt das korrekt zugeordnet. Nur für unsere werten Internetausdrucker Politiker und das ganze daran angekoppelte Gesocks scheinen diese Dinge heutzutage in erster Linie "Fachbegriffe" bei der Diskussion um Internet-Angelegenheiten zu sein, wie der Ruf nach einer "Notrufsäule" im Netz des BDK gemeinsam mit Ursula von der Leyen (weiß der Geier was auch immer diese Schnattertante plötzlich dazu "qualifiziert", für allgemeine Sicherheitsbelange im Netz zuständig zu sein...) wieder einmal vor Augen führt.

Ein Posting im zugehörigen Kommentarforum bringt das Thema wunderschön auf den Punkt:

Eigentlich ist das ja nicht mehr ganz brandaktuell, ich hatte hierzu schon mal was ins MobMap-Devblog gepostet. Aber mir gefällt das Theme immer noch so sehr, dass ich hier nochmal kurz drüber schreib.

Theme? Ja, es geht tatsächlich nur um ein Theme, nicht um die hunderttausendste in der Praxis völlig unpraktikable, aber zum Angeben im Netz durchaus brauchbare "Lösung", WoW mittels Remote-Desktop-Technologien "auf" dem iPhone zu spielen. Aber hey, es ist immerhin ein cool aussehendes Theme :D

Wie hier in diesem etwas längeren Artikel erklärt wird setze ich mit diesem Blog auf die noch recht wenig in der Praxis eingesetzte, aber enorm interessante und zukunftsträchtige Technik der Auslieferung von XML-Dokumenten statt HTML-Seiten, die dann clientseitig per XSLT zu den anzuzeigenden XHTML-Seiten transformiert werden. Die ganzen Vorteile dieses Ansatzes will ich jetzt nicht nochmal runterrattern, sondern auf den Hauptnachteil eingehen.

Auch wenn die großen 4 verbreiteten HTML-Rendering-Engines - die IE-Engine, Gecko (Firefox), Webkit (Safari, Chrome) und Presto (Opera) - in ihren aktuellen Versionen allesamt XSLT unterstützen, muss man immer noch damit rechnen, dass ein Client kein XSLT verstehen könnte. Das könnte daran liegen, dass alte Versionen der genannten Browser installiert sind, oder dass es sich gar nicht um einen Browser handelt, sondern um einen Suchmaschinen-Crawler, einen Screenreader oder ähnliches. Es wäre also wünschenswert, wenn man - so wie das bei serverseitiger Komprimierung der Seiten vor der Übertragung auch geschieht - vollkommen transparent eine Transformation auf Serverseite zwischenschalten könnte, aber nur für diejenigen Clients, die XHTML benötigen. Glücklicherweise geht das - und es ist gar nicht mal schwer zu konfigurieren :)

MOGIS, ich liebe euch! Die Idee, die Unsinnigkeit von "Umfragen" wie die der Kinderhilfe durch den Kauf einer zweiten Umfrage mit leicht abgeänderter Fragestellung beim selben Institut zu widerlegen ist einfach genial! Als Argumentationsmittel ist diese zweite Umfrage trotz für Sperrgegner traumhaften Ergebnissen wohl wenig geeignet, doch sie demontiert äußerst effektiv die Marketing-Wirkung der ersten Umfrage und lässt deutlich werden, wie unsinnig Umfragen zu komplexen Themen mit stark vereinfachten (und meist in eine bestimmte Richtung "optimierten") Fragestellungen sind.

Was mich überrascht hat: so eine Umfrage zu kaufen ist nicht mal teuer, laut MOGIS in diesem Fall 1100 Euro und es waren immerhin schon 3 Fragen statt nur zweien und ebenfalls 1000 Befragte. Den Trick muss ich mir merken :o)

P.S.: im Heise-Forum zum Newsbeitrag über die zweite Umfrage gefunden: klick mich und bereite dich darauf vor, Tränen zu lachen :)