Deus Ex: HR ist würdig
Deus Ex bleibt das beste Spiel aller Zeiten. Aber der direkte Nachfolger Invisible War war nicht ansatzweise so gut - zu viele Brüche mit dem Original, ohne einen eigenen Stil oder eine weniger wirre Story zu entwickeln. Zu kleine Level und zu viele technischen Probleme.
Human Revolution macht auch vieles anderes als Deus Ex. Aber es schafft es, trotzdem einzufangen, was Deus Ex ausmachte. Und es hat definitiv Stil:
Das Fähigkeitensystem ist weg. Schleichen geht immer noch am besten im Kriechen, aber statt des Schattens auf der Waffe sind Sichtkegel und das Deckungssystem relevant. Implantate schließen sich nicht mehr gegenseitig aus. Die wenigsten Gegner sind durch einen einzelnen Kopfschuss zu besiegen. Die Levels sind enger. Verschiedene Lösungswege werden offensichtlicher in Redundanz angeboten.
Und doch erweist sich HR als echtes Deus Ex. Zum einen, weil die Geschichte auf gleiche Weise faszinierend und klischeehaft ist. Zum anderen, weil mit den anderen Methoden doch ähnliche Ergebnisse erzielt werden: Der Spieler kann trotz meist enger Level recht frei seinen Spielstil wählen und seine Fähigkeiten entsprechend anpassen. Und obwohl es keine Fähigkeiten gibt, werden doch noch Erfahrungspunkte vergeben, die nun eben Implantate freischalten. Sich durchzuschießen mag einfacher sein und gibt mehr Beute, aber Schleichen wird mit Erfahrung belohnt.
Insgesamt spielt es sich ähnlich, trotz all der Unterschiede. Es schafft es, als natürlichen Spielstil eine leise Vorgehensweise vorzugeben, aber Schießen möglich zu machen. Und natürlich ist es wieder möglich, das Spiel ohne einen einzigen ausgeschalteten Gegner zu beenden. Ausgenommen der Bosskämpfe. Baut aber trotzdem die eine Situation ein, in der dem Spieler es fast unmöglich gemacht wird, das Spiel ohne Waffengewalt zu beenden und keine massiven Gewissensbisse zu erleiden.
Die Orientierung am Vorgänger reicht bis hin zum Gegnerverhalten, die immer noch erst kurz stutzen, wenn sie den Spieler sehen, um erst nach dieser kurzen Verzögerung Alarm zu schlagen. Die zwar intelligenter in Deckung gehen, aber immer noch keine Leiter nutzen (vielleicht könnten sie es inzwischen, aber die Gelegenheit ergibt sich normalerweise nicht). Um überhaupt zu realisieren, dass solche Eigenheiten den Vorgänger ausmachen, muss das Team, das HR gemacht hat, Deus Ex exzessiv analysiert haben - und das ist großartig.
Das Ergebnis dieser Analyse dann noch mit großartiger Inszenierung zu verbinden war auch nicht schlecht.
Dazu kommen die vielen kleinen Verbeugungen vor dem Vorgänger, all die Anspielungen - nie ist es ein einfacher Auftritt einer Person aus dem Vorgänger, auch wenn man in Mails von ihnen liest. Es ist mehr die Inspiration beim Leveldesign und bei der Story. So läuft diese nach dem Intro für mehrere Stunden ähnlich wie die des Vorgängers ab: Denton muss alleine eine Geiselnahme durch Terroristen beenden, hat aber ein anderes Primärziel - genau wie Jensen. Denton wird in die Stadt geschickt, um etwas zu holen - so wie Jensen. Dort passiert etwas, was eine Reise nach China notwendig werden lässt - so wie bei Jensen. In China infiltriert Dention eine Biotech-Firma - so wie Jensen.
Und sowieso, die Namen klingen gleich.
Sicher, die Details sind anders. Aber es ähnelt sich der grobe Rahmen. Schließlich lösen sich die Geschichten, um später wieder ähnlich zu werden, bis hin zum Einsatz einer Rakete und einer zerstörten Feindesbasis.
Es sind dann diese Leveldesigns, die Elemente des Vorgängers aufgreifen - manchmal verfremdet, wenn z.B. das Sarif-Labor am Anfang dem VersaLife-Labor im ersten Teil ähnelt - die dem Spieler das Gefühl geben, hier schon gewesen zu sein. Und dass er doch etwas neues erlebt, keinen müden Abklatsch, dafür sorgen die Variationen, der einzigartige visuelle Stil und die neuen Spielelemente.
HR borgt sich Spielelemente wie das Niederschlagen und die Minispiele beim Hacken bei Alpha Protocol (oder es hat ähnliche Einflüsse), und das ist gut so, denn Alpha Protocol war toll. Leider übernimmt es auch die oben schon erwähnten Bossfights, und die waren schon bei AP dumm, überflüssig und scheiße und sind genau das auch hier.
Doch auch Deus Ex hatte Macken. Deshalb ist Deus Ex: Human Revolution trotz seines einen groben Patzers nicht nur ein tolles Spiel, sondern auch eine absolute Seltenheit: ein würdiger Nachfolger eines Kultspiels.
Lesbarer Google Reader
Updates für den music-streamer
Schau ich mir die commit-Liste an meldet sich doch recht eindeutig das Gefühl, dass ein bisschen viel Arbeit in dieses völlig unwichtige Nebenprojekt geflossen ist. Schließlich soll er nur vom Pogo aus Musik per Browser streamen.
So sieht er jetzt aus:
Die erwähnenswerten Verbesserungen seit der ersten Vorstellung:
Design
Vorher war er fast komplett ungestylt, jetzt ist er dunkel und hat halbtransparente dunkle Buttons mit Hovereffekten. Ich bin mir zwar nicht sicher, ob dieser dunkle Hintergrund wirklich gut aussieht und zu einem Musikspieler passt, aber im Vergleich zu vorher ist es bestimmt ein Fortschritt.
Automatisches Umkodieren
Ich hatte bei einem ähnlichen Projekt mitbekommen, dass das automatische Umkodieren der Musikdateien auch auf schwacher Hardware funktionieren sollte. Stimmt auch tatsächlich und ist zumindest noch so lange praktisch, bis der Firefox .mp3s unterstützt.
Ich wollte vor allem sehen, wie so etwas funktioniert. Leider wurde das nicht ganz perfekt: Durch den falsche Content-Length-Header (die Dateigröße steht ja beim ersten Abruf noch gar nicht fest) wird manchmal das on-the-fly kodierte Lied nicht ganz abgespielt, und wegen der fehlenden Range-Request-Unterstützung kann nicht frei vorgespult werden.
Damit das erzeugte Lied ohne Ladezeit gestreamt werden kann, muss der Webserver das unterstützen - webrick fällt damit weg, aber sowohl thin als auch puma sind Alternativen. Puma kommt ohne EventMachine aus und wurde daher von mir als Standard gesetzt.
Prefetching
Gapless Playback habe ich nicht hinbekommen, beim Wechsel zwischen Audioelementen stocken die Browser immer ein bisschen. Aber um das so weit wie möglich zu reduzieren, wird beim Abspielen des einen Liedes das nächste schon in den Dom geladen und vorgepuffert.
Suche
Die Mediendatenbank ist etwas durchsuchbar:
Das ist simpel gehalten und durchsucht bisher nur die Künstlernamen, funktioniert dafür aber angenehm schnell.
Fazit
Sicher ist das Software geworden, die ich eine ganze Weile benutzen werde - ist ja auch komplett an meinen Musikhörstil angepasst (albenweise hören, Album für Album). Aber durch die aufgetretenen Bugs mit dem HTML5-Audio-Element ist mir nun klar geworden, warum professionelle Software wie Google Musik immer noch auf Flash setzt.
Außerdem war es wieder ein Experiment, wie die Javascriptebene am besten gehandhabt wird, auf Serverebene bin ich mit Ruby und Sinatra erstmal ziemlich zufrieden. Nicht objektorierentiertes und fast pures Javascript ist es diesmal, nur mit snack.js (eigentlich nur für schönere Ajax-Aufrufe und Eventbinder), von dem ich angesichts mir vorher unbekannten kritischen Bugs etwas weniger überzeugt bin als zuvor. Zusätzlich scheitert es am aktuellen Opera, es ist einfach zu wenig gepflegt.
Das nächste mal werde ich es vielleicht mit dem anderen Extrem versuchen, objektorientiertes Javascript und eventuell ein Framework wie AngularJS.
Der Code liegt auf Github.
Mega gestartet
Danisch hat natürlich recht, wenn er das Gerede von "militärischer Sicherheit" als PR-Geschwafel bezeichnet. Die jetzt eröffnete Dateihosterseite Mega selbst ist in ihrem Auftreten wenn auch nicht bescheiden, so doch etwas dezenter und sachlicher, sodass man sie sich ruhig mal anschauen kann. Das Konzept von verschlüsseltem Speicherplatz in der Cloud ist ja nun nicht uninteressant.
Funktionsweise
Wie kann man etwas so mithilfe des Browsers verschlüsseln, dass der Nutzer immer wieder dran kommt, der Betreiber es aber nicht entschlüsseln kann?
Bei Mega (laut der Seite selbst und den Kommentaren auf HN, ich habe nicht in den JS-Code geschaut) arbeitet man mit einem Nutzerpasswort, einem bei der Registrierung erstellten RSA-Schlüsselpaar (2048 bit) und symmetrischer Verschlüsselung auf dem Server selbst. Meiner Spekulation nach läuft alles nach diesem Schema ab:
- Die Datei "Batman.mkv" soll hochgeladen werden.
- Der Client erstellt den Hash H(Batman) der Datei und verschlüsselt mit diesem Hash und einem symmetrischen Verschlüsselungsverfahren wie AES (128 bei Mega) die Datei selbst.
- Nun bildet er den Hash der verschlüsselten Datei, also Hash(encrypt(Batman.mkv)), und nennt ihn Lokalisierer.
- Diesen Lokalisierer sendet er an den Server. Kennt der Server den Lokalisierer schon, kann er die Datei verfügbar machen, sonst muss die Datei hochgeladen werden.
- Wird die Datei hochgeladen, wird dieser Transfer mittels RSA verschlüsselt. Der Client holt sich vom Mega-Server seinen privaten Key, der mit dem Nutzerpasswort verschlüsselt ist, entschlüsselt ihn und verschlüsselt damit die Datei. Der Server kann sie dann mit dem öffentlichem Schlüssel (trotz des Namens nur dem Server bekannt) entschlüsseln.
- Da der Browser nicht zuverlässig Daten speichern kann, muss der Key H(Batman) ebenfalls auf dem Server gespeichert werden, natürlich ebenfalls verschlüsselt (ob mit RSA oder symmetrisch mit AES und dem eigenen Passwort ist eigentlich egal).
Das ist deutlich komplizierter, als die Datei einfach per RSA auf dem Client zu verschlüsseln und so verschlüsselt auf dem Server zu speichern. Es hat aber zwei Vorteile:
Obwohl der Serverbetreiber nie den Inhalt der Datei sieht, kann er doppelte Datei duplizieren, anstatt sie mehrfach speichern zu müssen. Erst durch diese Duplikation werden solche Speicherdienste überhaupt bezahlbar.
Außerdem wird es theoretisch möglich, im kleinen Kreis Dateien zu teilen, ohne den öffentlichen RSA-Schlüssel weitergeben zu müssen, indem der Datei-Key (H(Batman)) weitergegeben wird.
Sicherheit
Dass Kim Dotcom überhaupt einen so verschlüsselten Dienst aufbaut hat natürlich primär ein Ziel: Er will von nichts wissen. Da sein Server nie den Inhalt der Dateien sieht, kann er nur schwer belangt werden, wenn auf seinem Server Schwarzkopien gehostet und getauscht werden. Nach dem illegalen Angriff der USA auf ihn ist das ein verständliches und für ihn wichtiges Ziel. Das heißt aber nicht, dass Dateien auf Mega absolut sicher sind. Es gibt durchaus ein paar Bedenken.
Zum einen wird die RSA-Keygenerierung im Browser per Javascript erledigt. Javascript jedoch hat keinen Zugriff auf einen echten Zufallszahlgenerator (RNG). Schon deshalb halten manche die so erstellten RSA-Keys für unsicher.
Ich teile die Meinung nicht: Im wahrscheinlichsten Angreifermodell hat der Angreifer nur Zugriff auf den Dateistrom zwischen Mega und Client. Selbst wenn der RNG nicht perfekt arbeiten würde, ist da immer noch der Input aus den Mausbewegungen und sonstigen Eingabedaten des Nutzers. Daran dürfte ein Angreifer erstmal knabbern.
Es gibt keinen Grund anzunehmen, dass trotz dieses Inputs mit hoher Wahrscheinlichkeit nur ein kleiner Zahl des Zahlenraums gewählt wird.
Viel gewichtiger ist das Bedenken gegen Crypto per JS, das auf dem Misstrauen gegen den Serverbetreiber beruht. Denn die Skripte kommen ja vom Server selbst. Wenn Mega wirklich wollte, könnten sie natürlich eine bestimmte Datei unverschlüsselt übertragen lassen, es prüft ja niemand jedes mal allen Javascript-Code. Daran hat Mega aber eigentlich kein Interesse. Trotzdem, im Kampf gegen einen Staat mit einem Geheimdienst, der Mega entsprechend beeinflussen könnte, würde ich mich nicht darauf verlassen.
Bleibt die Urheberrechts-Industrie. Die hätte im oben beschriebenen Verfahren tatsächlich die Möglichkeit, Dateien vom Server wegfiltern zu lassen, indem sie den Lokalisierer bekannter illegaler Kopien erstellt und an Mega schickt. Da bisher aber noch keine Möglichkeit besteht, Videos von Mega aus öffentlich zu streamen (wie es früher mit MegaUpload ging), dürfte sie das relativ wenig reizen und sie auch wenig rechtliche Handhabe haben, diese Filterung privater Dateien duchzusetzen.
Ob das relevant wird dürfte davon abhängen, welche weiteren Funktionen die Seite noch bekommt.
Fazit
Ich würde Mega nutzen. Weniger wegen der Verschlüsselung, obwohl ich das Verfahren nett finde, sondern weil 50 GB kostenloser Online-Speicher auch ohne Verschlüsselung nicht schlecht zu haben ist.
Wichtiger als die Sicherheitsfrage ist derzeit die Nutzbarkeit, der Server ist gerade komplett überlastet. Und es muss sich sowieso noch zeigen, ob so ein Online-Dateimanager irgendwie relevant für meine tägliche Nutzung werden kann. Ich bezweifel das bisher und denke mehr an ein zusätzliches Backup. Mit der vorhandenen API könnten aber noch ein paar interessante Programme gebaut werden, die das ändern - ein Dropbox-ähnlicher Client mit 50 GB kostenlosem Speicher wäre schon sehr reizvoll, auch weil dann die Verschlüsselung nicht in vom Server gesendeten Skripten passieren müsste.
Oder vielleicht bewährt sich Mega doch als als Server zum Filesharing, eventuell RetroShare-mäßig begrenzt auf den Freundeskreis oder im großen Stil, wenn die Dateischlüssel einfach geteilt werden können. Da muss man abwarten, wie genau die Share-Funktion umgesetzt werden wird - genau wie beim Rest der Seite.
Chrome Bug? Viele Audio-Elemente und der Browser-Cache
Für music-streamer versuche ich, einfach das HTML 5 Audio-Element zu nutzen und den Rest dem Browser und ihrer Weiterentwicklung zu überlassen. Funktionsweise: Mein Javascript erstellt immer ein Audio-Element für das derzeitige Lied, am Ende davon wird das Element mit einem neuen für das nächste Lied ersetzt usw. Natürlich kann man auch vor- und zurückwechseln.
Beim schnellen Wechseln passiert es manchmal, dass der generierte HTML-Code einwandfrei aussieht, das Audio-Element aber inaktiv bleibt (insbesondere signalisiert das ein durchgestrichener Lautsprecher bei der Laustärkeeinstellung). Was passiert da?
Mir fielen mehrere Möglichkeiten ein: Eventuell sind alle Verbindungen zum Server belegt, weil der Browser das Ersetzen des Audio-Elementes nicht mitbekommt und daher alle kurz geöffneten Musikstücke auf einmal versucht zu ziehen. Oder Chrome scheitert daran, den Rest der nur bruchstückhaft im Cache gespeicherte MP3 herunterzuladen.
Es kann auch eine Kombination sein, dass durch den Cache verhindert wird, dass nach dem Freiwerden einer Verbindung der Download fortgesetzt wird. Das ist meine derzeitige Vermutung, mein Workaround legt das nahe.
Aber erstmal die Problemdiagnostik. Gut zu sehen ist es auf diesem Netzwerkprotokoll:
Ich habe eine Reihe von Songs duchgewechselt. Track 24, 25, 26 und zurück zu 25. Und genau, Track 25 lädt nicht. Man sieht im Protokoll, dass der Ladebalken grau bleibt, also kein echter Request abgeschickt wird (oder was bedeutet es sonst, dass der Balken grau ist?). Hier ist das zugehörige Serverprotokoll:
requesting track 23 127.0.0.1 - - [07/Jan/2013 16:40:18] "GET /track/23 HTTP/1.1" 206 11062262 0.9775 requesting track 24 127.0.0.1 - - [07/Jan/2013 16:40:20] "GET /track/24 HTTP/1.1" 206 4937698 0.4218 requesting track 25 127.0.0.1 - - [07/Jan/2013 16:40:23] "GET /track/25 HTTP/1.1" 206 5535170 0.5492 requesting track 26 127.0.0.1 - - [07/Jan/2013 16:40:25] "GET /track/26 HTTP/1.1" 206 2987291 0.2839 localhost - - [07/Jan/2013:16:40:25 CET] "GET /track/26 HTTP/1.1" 206 2987291 http://localhost:4567/ -> /track/26
Am Server kommt nie ein zweiter Request für Track 25 an. Riecht also nach einem Cache/Browserproblem.
Der Code zum Senden der Tracks sieht so aus (music-streamer nutzt Ruby mit Sinatra):
get %r{/track/([0-9]+)} do |id|
puts "requesting track #{id}"
path = Database.new.getPath(id)
type = FileMagic.new(FileMagic::MAGIC_MIME).file(path)
content_type type
send_file path, :type => type
end
Die Datei wird also mit dem richtigen Content-Type rausgesendet, viel mehr passiert hier nicht.
send_file kümmert sich darum, dass die nötigen Header richtig gesetzt werden. Insbesondere setzt es den Last-Modified Header auf das echte Datum, an dem die Datei das letzte Mal editiert wurde. Zusammen mit dem grauen Balken und der nichtvorhandenen Serveranfrage vermutete ich, dass der Browser damit nicht zurechtkommt.
Daher kam ich auf diesen Workaround: Browser-Caching verhindern, indem der Last-Modified-Header auf "jetzt" gesetzt wird:
send_file path, :type => type, :last_modified => DateTime.now.httpdate
So bleibt zwar immer noch etwas Wartezeit, wenn zu viele Tracks auf einmal gesendet werden, aber nach dieser Wartezeit wird der Track geladen.
Die richtige und bessere Lösung wäre wohl, den Browser dazu zu bringen, abgebrochene Lieder nicht weiter zu laden. Dann käme es gar nicht dazu, dass die Maximalanzahl an Verbindungen zum Server überschritten wird.
Es ist natürlich trotzdem möglich, dass der Fehler nur ausgelöst wird, weil im Javascript das alte Audio-Element noch herumfliegt und deswegen die Verbindung bestehen bleibt. Doch selbst wenn dem so wäre, sollte Chrome den Request neu abschicken, wenn das Audio-Element neu erstellt wird. Daher sieht das für mich sehr nach einem echten Bug in Chromium aus.
Android auf dem HP Touchpad ist großartig
Das Touchpad ist ein ziemlich gutes Tablet mit einem etwas zu spiegelnden Display, das seinen Preis im Firesale allemal wert war. Und webOS ist ein Betriebssystem mit einer gut benutzbaren Oberfläche. Aber selbst mit den Homebrew-Patches fiel es nun in sich zusammen: Immer wieder streikte das WLAN, die Suche im Browser über die URL-Eingabe funktionierte nur noch sporadisch, und es gab trotz Uberkernel noch Momente, in denen scheinbar ohne Grund das gesamte System ins Stocken geriet. Ich dachte schon, das Tablet sei kaputt, daher war Android per Cyanogenmod 9 zu installieren ein letzter Versuch. Ergebnis: Alle Probleme sind weg.
Android läuft hervorragend auf dem Touchpad. Die Oberfläche ist flott, die Bugs sind verschwunden. Selbst wenn doch mal das WLAN abbrechen sollte: Android ist intelligent genug, sich dann einfach wieder zu verbinden, was webOS nie alleine hinbekommen hat. Die Auswahl im Play Store ist hervorragend, aber auch die Standardprogramme sind besser, schon alleine der Browser. Ausgenommen der Apollo Player, der keine Auswahl für einen Musikordner hat und den Download-Ordner ignoriert, also komplett unbrauchbar ist, aber mit diesem Scheitern ragt er auch wirklich heraus aus einem sonst sehr gut funktionierendem System.
Es gibt einen einzigen bleibenden Nachteil: Das Flashplugin lief unter webOS etwas stabiler, aber es läuft unter Android nicht so schlecht, dass man sich damit nicht arrangieren könnte. Und gefühlt ist die Akkuleistung geringer geworden, kann aber auch an der vermehrten Nutzung liegen.
Die Installation war ziemlich einfach: Die richtigen Dateien herunterladen, auf den Touchpad packen, einen Befehl per novacom absenden (was allerdings unter Windows nicht funktionierte) - dieser Anleitung folgen. Die Google-Apps musste ich allerdings nachträglich installieren, die wurden vorher ignoriert.
Ein funktionierendes System ist eben doch besser als ein überlegenes Konzept voller Bugs. Und obwohl ich Android auf dem Handy immer etwas verwirrend fand - das Kartensystem von webOS ist prägend - empfand ich den cyanogenmod auf dem Tablet von der ersten Minute als einfach bedienbar.
Ich wünschte, Android gäbe es auch für das HP Veer.
Streamer: Eigene Musik im Browser hören
Ein Experiment: music-streamer ermöglicht das Hören der Musik auf dem Server im Browser.
HTML 5 ohne Fallback, mp3s funktionieren also noch nicht im Firefox. Soll auf meinem Pogoplug laufen, als Alternative zum Musikplayer von ownCloud, was mir als Dienst zu groß ist.
