Am 9. Juli erschien Version 2.18 vom alternativen, nur Text Client Radegast. Im November 2014 verkündete sein Entwickler Latif Khalifa noch, keine Zeit mehr für seine Opensourceprojekte zu haben.
Radegast 2.18 wird dabei als kleines Update bezeichnet.
Die moderne Entwicklung von Software hat es so an sich, dass die Programmierer oft das Rad nicht mehr neu erfinden müssen, sondern sich bereits existierender Programmbibliotheken für alle möglichen Bereiche, wie beispielsweise Verschlüsselung, dem Abspielen von MP3s, Videos u.v.m. bedienen können. Der Entwickler nutzt die Schnittstellen der entsprechenden Bibliothek und baut sie in sein Produkt ein, fertig. Natürlich muss er damit auch ab und an sein Projekt der Bibliothek anpassen, wenn sich diese ändern sollte.
Das hier, werte Leser, ist Konqueror. Der Mehrzahl von euch wird Konqueror nichts sagen, es handelt sich dabei um den alten Dateimanager des Desktop Environments KDE unter *nix. Konqueror war schon immer fähig, als Webbrowser zu fungieren und hatte dazu eine eigene, kleine Websiterenderingengine namens KHTML eingebaut plus eine Javascriptengine namens KJS. KHTML war recht flott, leichtgewichtig und einfach in eigene Programme einzubauen.
KHTML kennt heute kaum noch einer, es wird auch nicht mehr weiter entwickelt. Als Apple im Jahre 2003 seinen eigenen Webbrowser namens Safari vorstellte, ging ein Raunen durch die Webszene. Denn in dieser Email meldete sich ein gewisser Don Melton bei den KDE-Entwicklern und verkündete der erstaunten Welt in der Mailingliste, dass Apples neuer Webbrowser auf einem Fork von KHTML mit KJS basieren würde. Dieser Fork, also eine auf Grundlage von KHTML unabhängige Weiterentwicklung trug damals den Namen WebCore, das Gesamtprojekt hörte auf den Namen Webkit.
Die KDE-Leute waren verzückt und gleichzeitig die Macher bei Mozilla verärgert, dass Apple nicht deren ebenfalls quelloffene Engine Gecko benutzt hatte. Gecko war den Entwicklern bei Apple zu groß, zu schwer einzubauen und zu langsam, aber KHTML genau richtig. Dafür konnte Gecko aber auch deutlich mehr Webseiten korrekt anzeigen, als dies bei KHTML der Fall war.
Webkit wuchs und gedieh und findet sich heute auf jedem Smartphone und Rechner als Engine, es ist die Basis für Safari und war die Basis für Google Chrome. An der Entwicklung von Webkit sind unter der Federführung Apples viele, bekannte Firmen beteiligt. Google verabschiedete sich allerdings 2013 von Webkit und gründete seinen eigenen Fork namens Blink. Der Grund dürfte einfach sein, dass man sich so aus der technischen Abhängigkeit von Apple befreien wollte. Ebenso verwendet bis heute der Second Life Viewer Webkit als Viewerkomponente.
Mozilla arbeitet übrigens selber schon seit längerem an einer vollkommen neuen Renderingengine namens Servo, die in einer dafür eigens geschaffenen Programmiersprache namens Rust implementiert wird. Man darf gespannt sein, was dabei am Ende herauskommen wird.
Das moderne World Wide Web hat ein Problem, nämlich sein Übertragungsprotokoll namens Hypertext Transfer Protokoll. Dieses ist recht einfach und designmäßig in die Jahre gekommen, das merkt man eben.
Es gibt bisher zwei Versionen davon, nämlich HTTP/1.0 aus dem Jahre 1996. Bei HTTP/1.0 wird für jede übertragene Datei oder Bild eine neue Netzwerkverbindung aufgebaut, die Daten übertragen und danach die Verbindung wieder geschlossen. Wenn man nur wenig überträgt, dann ist das kein großes Ding, aber eine moderne Webseite besteht heute locker aus über 80 verschiedenen Dateien oder mehr. Jede Verbindung, die per TCP/IP aufgebaut werden muss, benötigt einen gewissen Vorlauf im Betriebssystem als auch im Netzwerk und danach wird sie wieder geschlossen. Das ist so sinnvoll, als würde man für drei Kästen Bier im Supermarkt jeden Kasten Bier einzeln holen.
1999 kam dann eine Verbesserung namens HTTP/1.1 heraus, die bis heute der aktuell gültige Standard ist. Bei HTTP/1.1 kann man eine bereits bestehende Verbindung offen halten und darüber mehrere Dateien anfordern. Man spricht von persistenten Verbindungen und Pipelining, d.h. der Übertragung mehrerer Dateien über die offene Verbindung hintereinander. Das Problem daran ist nur, dass korrektes Pipelining extrem schwer zu implementieren ist und daher nutzt es kaum jemand wirklich. In Google Chrome beispielsweise ist Pipelining implementiert, aber standardmäßig abgeschaltet. Zudem gab es Benchmarks mit mehreren Webbrowsern und dabei keine wirklich meßbaren Unterschiede zwischen an- und abgeschaltetem Pipelining.
Ob nun HTTP/1.0 oder HTTP/1.1, beide Protokolle sind recht einfach gestrickt, sie genügen nicht mehr den heutigen Anforderungen im Webserverbereich wirklich und ein Flaschenhals. Die Übertragung von Webseiten könnte deutlich schneller sein, was aber wegen des zugrundeliegenden Übertragungsprotokolls bisher nicht möglich ist. Es ist ein Hemmschuh.
Google hat das Problem vor knapp zwei Jahren mit der Entwicklung des hauseigenen SPDY-Protokolls angegangen; dieses bildet nun die Grundlage für die aktuelle Entwicklung von HTTP/2.0, dessen Einführung in nächster Zeit absehbar sein wird.
Bei HTTP/2.0 wird zu jedem Webserver grundsätzlich nur noch eine TCP/IP-Verbindung aufgebaut und diese wird on the fly komprimiert. Die Übertragung findet binär statt und der Webserver beherrscht dabei das Multiplexing von verschiedenen Dateien gleichzeitig; auch erkennt er, welche Dateien der Webbrowser als nächstes höchstwahrscheinlich für den Seitenaufbau benötigt und schickt diese dem Browser von sich aus direkt zu.
HTTP/2.0 dürfte dem Web einen dringend benötigten, ordentlichen Geschwindigkeitsschub bringen, der die Breitbandleitungen deutlich besser als bisher auslasten wird.
Second Life bekommt aktuell Unterstützung für CDNs, also Content Delivery Networks, eingebaut. Aktuell gibt es einen Projektviewer dazu und rund 28 Regionen auf dem Mainland, die das unterstützen.
Das Problem daran ist nur: viele können sich unter einem CDN absolut nichts vorstellen, aber sie benutzen es täglich. Was also ist ein CDN und warum ist es gut?
Ein CDN ist, wie der Name schon sagt, ein Netzwerk, das Inhalte verteilt. Nehmen wir mal an, ín meiner Gegend gibt es zwei ALDI-Filialen, die eine ist drei Kilometer von mir entfernt und die andere zehn. Nehmen wir weiter an, ich als ökonomisch handelnder Mensch kaufe immer dasselbe Toilettenpapier bei ALDI, das es in jeder Filiale als Eigenmarke vorrätig gibt. Wohin werde ich natürlich fahren? Richtig: zu der Filiale, die näher an meinem Wohnort ist, denn das Angebot in dem Fall ist ja in allen ALDI-Filialen gleich und es gibt für mich absolut keinen vernünftigen Grund, in die weiter entfernte Filiale zu fahren.
Und genau das ist das Prinzip eines CDNs, nämlich die Inhalte eines Diensteanbieters geographisch (!) gesehen wirklich so nahe als möglich an den Abrufer zu bringen. Das geschieht dabei völlig automatisch, transparent und der Benutzer kriegt davon nichts mit. Der CDN-Anbieter muss dafür eine globale Infrastruktur betreiben.
Wie funktioniert das? Nun, in Second Life wird es für Meshes und Texturen freigeschaltet werden. Bekannte Anbieter von CDNs sind beispielsweise Akamai oder Amazon. Wenn ich also in Zukunft als Deutscher eine Textur runter laden will, dann geht diese Anfrage auf CDN-aktiven Regionen nicht mehr direkt an die Rechenzentren von Linden Lab in den USA, sondern an einen Server des CDN-Anbieters, der irgendwo in Europa steht. Der prüft dann zunächst, ob diese Textur schon lokal vorhanden ist, und wenn ja, dann schickt er mir diese direkt, was in einer deutlich besseren Ladezeit resultiert (das ist einfacher Physik und der Übertragungsgeschwindigkeit geschuldet, sprich man hat eine bessere Pingzeit). Wenn die Textur bisher nicht vorhanden ist, dann fordert er diese beim Stammserver an und hält sie danach für weitere Deutsche für eine gewisse Zeit vor.
Das ist alles. Dadurch haben wir dann in Zukunft eine Entkoppelung des Ladens von Texturen und Meshes von der Infrastruktur Linden Labs in den USA, weil das hauptsächlich über das CDN passieren wird. Als Ergebnis wird man eine spürbare Beschleunigung der Ladezeit von oft bzw. oft wiederholt besuchten Sims feststellen können. Wie hoch, das wird sich zeigen .
Zu beachten dabei ist allerdings, dass nach wie vor die Regionserver in den USA stehen und damit die Avatarpositionsberechnung, Physik usw. ausschließlich über dort geschehen wird.
Philip Rosedale arbeitet unter Hochdruck mit seinen motivierten und fähigen Mitarbeitern an der nächsten Inkarnation einer virtuellen Welt, High Fidelity. Linden Lab überraschenderweise auch schon seit längerem, auch wenn das Kind noch keinen offiziellen Namen hat – manche nennen es einfach Second Life The Next Generation (SL-TNG) – so soll doch bereits 2015 eine Beta verfügbar sein.
Beiden ist gemeinsam, dass sie ordentlich Manpower und ordentlich Geld zur Verfügung haben, um ihre Pläne Wirklichkeit werden zu lassen, dazu kommt noch sehr viel praktische Erfahrung mit dem Betrieb von virtuellen Welten. Während High Fidelity Opensource ist mit einigen, zentralen Diensten, wird SL TNG erst einmal Closed Source sein.
Aber denken wir mal ein wenig weiter und tun so, als ob zumindest einer dieser neuen Dienste verfügbar wäre: neue Möglichkeiten, zeitgemäßere Architektur, bessere Leistung und Geschwindigkeit.
Was wird dann aus Opensimulator? Bis auf einige Hartgesottene bin ich mir sicher, dass es vor allem wegen High Fidelity dann sehr rasch und stark an Bedeutung verlieren wird und irgendwann wohl sanft sterben wird, denn mit dem Erscheinen eines dieser Produkte wird es ziemlich sicher seine besten Zeiten schlagartig hinter sich haben.
Es gibt mal wieder einen neuen Second Life Viewer, mit dem keiner rechnete, namens Replex. Dahinter steckt Latif Khalifa, seinerseits absolut kein Unbekannter, sondern der Autor vom Radegast-Client und einigen anderen Sachen.
Replex kommt einem dabei von Anhieb seltsam bekannt vor, und das ist kein Wunder, handelt es sich doch schließlich bei diesem 1er-Viewer um einen Fork vom Singularity Viewer. Replex basiert dabei auf dem letzten Alphacode von Singularity, enthält aber einen Haufen an Verbesserungen im Vergleich zu Singularity 1.8.5. Allerdings stammt die Mehrheit davon vom Singularity-Team selber, der bisherige Beitrag von Latif Khalifa liest sich dann doch recht bescheiden:
Im Grunde ist also Replex eine leicht veränderte Version des aktuellen Singularity-Alpha-Codes plus einigen, wenigen Änderungen von Latif Khalifa.
Da stellt sich dann die Frage: warum hat der Kerle das gemacht? Einer der Singularity-Entwickler beschreibt das so:
Replex is by no means the successor, it’s just something done because someone has no confidence that we can get our alpha build system up.
Also in seinen Augen ist der Grund, dass Latif einfach kein Vertrauen darin habe, dass das Singularity-Team seine neue Build-Infrastruktur zum Laufen bekommen würde und daher selber was gebaut und nichts anderes.
Latif Khalifa selber schreibt zu seiner Motivation auf seiner Seite nichts dazu. Es bleibt also abzuwarten, ob er wirklich die Energie hat, Replex weiter zu entwickeln oder Replex bald wieder, wie viele andere Viewer vorher auch schon, von der Bildfläche verschwinden wird.
Da ich das bisher komischerweise noch nicht in der deutschen Blogosphäre gelesen habe, eben nun hier: Linden Lab arbeitet nach eigenen Aussagen an einer neuen, virtuellen Welt (oder nennen wir es Plattform).
Diese soll closed source sein, und viele der Fehler von Second Life beheben. Das bedeutet nicht das Ende von Second Life, sondern beide Plattformen werden lange Zeit parallel existieren. Ein Import der Daten von Second Life in diese neue Welt ist nicht vorgesehen und mit einer Beta irgendwann im Jahr 2015 zu rechnen. Die Mehrheit der Programmierer Linden Labs würde inzwischen an dieser neuen Welt arbeiten, außerdem stellen sie gerade zusätzliche Programmierer ein.
In Sluniverse gibt es dazu einen inzwischen sehr langen Thread, in dem sich auch Ebbe Altberg bereits mehrfach dazu geäußert hat, auch hat er diese Meldung offiziell bestätigt. Ein Ziel der neuen Plattform wird definitv auch die Möglichkeit sein, sie mit mobilen Geräten benutzen zu können.
Momentan hat die freie Softwareszene ein gewaltiges Beben erschüttert, und keiner weiß so recht, woran man wirklich ist. Einige kennen vielleicht das freie Verschlüsselungsprogramm TrueCrypt: man kann damit Dateien oder komplette Festplatten verschlüsseln, es läuft unter Windows, Mac OS X und Linux gleichermaßen gut und vor allem auch so, dass man es portabel installieren kann sowie es einfachst zu bedienen ist. Viele Menschen benutzen es weltweit, um sensible Daten zu schützen, wie zum Beispiel der Sicherheitsexperte Bruce Schneier (genauer: er nutzte es) oder Edward Snowden.
TrueCrypt wurde dabei von einem Team an Entwicklern verfasst, deren Identität weitgehend unbekannt ist und sich nur selten in der Öffentlichkeit oder per Email zu irgendetwas äußern. Es ist seit über 10 Jahren bereits verfügbar und sein Quellcode offen verfügbar. TrueCrypt stand bisher im Ruf, weitgehend vertrauenswürdig und sicher zu sein, auch ist gerade momentan eine kommerzielle Sicherheitsprüfung des Quellcodes auf Schwachstellen und mögliche Hintertüren im vollen Gange, die bisher nichts schlimmes zu Tage förderte.
Also ist alles gut im TrueCrypt-Land, so sollte man meinen, aber weit gefehlt: seit ca. zwei Tagen hat sich die Webseite von TrueCrypt dramatisch verändert. Dort, wo bisher eine recht gut gemachte Webpräsenz unter www.truecrypt.org erreichbar war, findet sich nur noch eine im Vergleich dazu recht lieblos und schludrig dahingestellte Warnung, man solle die Software nicht mehr benutzen, da sie nicht mehr sicher sei. Warum TrueCrypt auf einmal unsicher geworden sei, darüber schweigt sich die neue Seite einfach aus.
Als Grund für die Einstellung der Software wird dabei das offizielle Supportende von Windows XP angegeben. Auch die Empfehlungen, welche Software man anstelle von TrueCrypt benutzen sollten, wirken komisch, denn unter Windows wird BitLocker empfohlen, das vermutlich eine serienmäßige Hintertür für die NSA eingebaut haben dürfte, für Mac OS X FileVault und unter Linux solle man einfach installieren, was man installieren wolle. A-ha. Und es gibt eine neue Version der Software zum Download namens 7.2, die aber nur noch das Entschlüsseln ermöglicht und nicht mehr verschlüsselt.
Alles in allem wirkt es auf den ersten Blick sehr sonderbar und so, als wäre da ein Hacker unterwegs gewesen. Der Fakt allerdings, dass die neuen Downloadpakete mit dem digitalen Schlüssel des Entwicklerteams signiert worden sind, machen das dann doch recht unwahrscheinlich. Solch ein Hacker hätte nämlich erst die Identität der Entwickler herausfinden müssen, sich dann noch den Schlüssel besorgen müssen plus das Passwort, mit dem man diesen benutzen kann. Es ist zwar möglich, aber extrem unwahrscheinlich.
Also ist es wahrscheinlicher, dass die Seite selber nicht gehackt ist, sondern echt vom Entwicklerteam so verändert wurde und sie nun keine Lust mehr haben, TrueCrypt weiter zu entwickeln. Die Frage, die man sich dabei stellen muss, ist aber: warum auf einmal das und warum auf einmal so, dass sie alles daran setzen, das bisherige Vertrauen in ihr Produkt nachhaltig zu zerstören?
Auch da gibt es wieder mindestens vier Möglichkeiten, nämlich:
Gegen 4 spricht, dass der Quellcode offen verfügbar ist und bisher im Audit nichts wesentliches gefunden wurde, was aber nicht heißt, dass man noch nichts finden wird. Auch untersucht das Audit ja den Quellcode, aber nicht die Downloadpakete, in denen könnte man ja noch Backdoors eingearbeitet haben. Außerdem würde gerade ein Geheimdienst ja wollen, dass man sein Produkt einsetzt und ein solch weit benutzes Ding wie TrueCrypt wohl kaum mit solch einer Aktion es beenden, denn das wäre ja gegen seine Interessen. Allerdings gelang es neulich jemandem, aus dem Quellcode dasselbe Paket zu bauen wie es zum Download in der Version 7.1a unter Windows zur Verfügung stand, also ist auch das eher unwahrscheinlich.
Gegen 3 sprechen die komischen Empfehlungen, die die Entwickler geben. Wenn jemandem wirklich Sicherheit so wichtig ist, dann wird der nicht auf einmal BitLocker oder FileVault einsetzen noch es empfehlen.
Also bleibt 1 oder 2. Beides ist möglich, und wenn es 2 sein sollte, dann werden wir es so schnell wohl nicht erfahren. Dazu kommt ja, dass keiner weiß, aus welchem Land die Entwickler eigentlich stammen und welchen Gefahren sie sich da möglicherweise ausgesetzt sähen.
Persönlich halte ich Möglichkeit 2 für wahrscheinlicher, denn wenn es 1 wäre, also der interne Streit, dann hätte sich nach über drei Tagen inzwischen sicher mindestens ein weiterer Entwickler vom Team dazu irgendwie geäußert oder gar die alte Seite wieder hergestellt. Was es letzten Endes aber wirklich ist, das muss die Zeit erst noch zeigen, es weiß eben keiner. Übrigens hat sich bei Twitter auch was getan, nämlich bei Steven Barnhart hat sich per Email ein Entwickler des Teams namens „David“ gemeldet, der die Einstellung des Produktes einfach damit begründe, dass man keine Lust mehr habe und nein, es stünde keine staatliche Repression dahinter. Ob man dem nun trauen schenken kann oder nicht, auch das ist wieder ungewiß.
Überhaupt zeigt all diese Heimlichtuerei um die Entwickler ein großes Grundproblem von TrueCrypt: warum bitte haben wir die ganze Zeit lang einem Team von Entwicklern in dieser sensiblen Angelegenheit vertraut, das keiner kennt und die ihre Identität systematisch verheimlichen?
Bruce Schneier jedenfalls ist erst einmal wieder auf PGP Disk umgestiegen, wie es scheint. Die Version 7.2 der Software sollte man besser mit Vorsicht beäugen, d.h. gar nicht benutzen, solange keiner das Programmpaket auf mögliche Hintertüren durchsucht hat. Es gibt bereits Bestrebungen, wie beispielsweise unter www.truecrypt.ch, die Software als Fork weiter zu entwickeln. Eines steht dabei schon fest: TrueCrypt wird sie dann nicht mehr heißen können, weil das ein eingetragenes Warenzeichen ist.
So oder so, es ist alles nur sehr merkwürdig, viel im Dunkeln und was das alles genau soll, kann bis auf die Entwickler vielleicht keiner so recht sagen. Es bleibt also viel Raum für Spekulationen aller Art übrig.
Als Lehre aus dem Desaster sollte man, so finde ich, bei einem so wichtigen Stück Software einem anonymen Entwicklerteam, das keiner wirklich kennt, nicht mehr vertrauen. Gerade bei solchen Programmen ist es wichtig, dass man auch weiß, wer dahinter steht (und Satoshi Nakamoto von Bitcoin kennt bisher auch keiner).
Hier mal ein Debattenbeitrag zu dem Thema, was mit Windows 8 nicht stimmt. Er ist zwar inzwischen drei Jahre alt, aber viel geändert hat sich bis heute nicht daran.
Ui, das ist mal eine Bombe: in diesem Beitrag hier schreibt Swapps Swenson, dass Slinfo.de gehackt worden sei und die ersten Spuren Ende April 2014 zu finden seien. Zwei Benutzer haben sich als Administrator anmelden können und diverse Änderungen an Templates und Plugins vorgenommen, obwohl das Forum immer sicherheitstechnisch auf dem neuesten Stand gewesen sei. Mag sein.
Da er keine Zeit zur vollständigen Fehlersuche habe, möchte er daher das Forum kostenlos inkl. Domäne und Software in vertrauensvolle Hände abgeben, genauer an nur ihm bereits bekannte Personen, oder es alternativ komplett schließen.
Uiuiui.
Wenn ich das lese, dann dreht sich mir gehörig der Magen um: ein Fehler kann ja mal passieren, PHP ist sicherheitstechnisch ein Krampf und das wird man leider niemals dicht bekommen können. Wenn also so was passiert, dann sollte man sich die Zeit nehmen, um sicher zu stellen, dass der normale Betrieb wieder gewährleistet ist und solange man das nicht kann, gehört der Dienst einfach abgeschaltet.
Hier aber wurde mehr oder minder kurz drüber geschaut und die Installation läuft einfach weiter. Go figure, ich halte das für ausgesprochen schlecht, weil so ein sicherer und vertrauenswürdiger Betrieb aktuell nicht möglich ist.
Bartholomew Gallacher