Category Archives: Programming

Der Cliqz-Browser, oder: der Wolf im Schafspelz

Aktuell schwappt ja durch die deutschen Qualitätsmedien eine Welle der Berichterstattung über einen ach so tollen Webbrowser auf deutschen Landen, der es Google mal so richtig zeigen soll. Wer nicht gerade blind durch's Web surft, der wird das sicherlich mitbekommen haben, es handelt sich dabei um den neuen Browser CliqZ.

Cliqz ist kostenlos verfügbar, gut. Mit dem Verkauf von Webbrowser kann man schon seit mindestens 15 Jahren kein Geschäft mehr machen, daher ist das nicht weiter verwunderlich, wer seinen Webbrowser unters Volk bringen will, der muss diesen kostenlos abgeben, sonst kann er es nämlich gleich sein lassen!

Cliqz ist dabei softwaretechnisch nichts anderes als ein Fork von Mozilla Firefox. Man hat also die Basis von Firefox genommen und entsprechend umgearbeitet, was erlaubt ist. Das Meiste an Features, was Cliqz so bietet, kann man übrigens auch problemlos bei jedem anderen, modernen Webbrowsern durch Erweiterungen problemlos nachrüsten. Die Erweiterungen von Firefox kann man jedenfalls mit Cliqz nicht nutzen, da der Entwickler das abgeschaltet hat.

Was die Medien aber stillschweigend verschweigen ist, wer hinter Cliqz steckt, denn die Firma gehört zum Medienunternehmer Hubert Burda. Burda ist einer der großen deutschen Verleger.

Und einer der Unterstützer vom Leistungsschutzrecht. Der Browser ist also eine Waffe, um die Anzeigeneinnahmen von Google zu reduzieren. Und natürlich kommt der Browser mit einer Reihe von Ausnahmen daher, die Werbung vom Verlagshaus Burda&Co. erlauben. Man will sie ja nicht ins eigene Fleisch schneiden, und ebenso wird nur "unsicheres Tracking" verhindert.

Wer also wirklich einen werbefreien Browser haben will, dem bleibt nach wie vor nichts anderes übrig, als sich das mit den zur Verfügung stehenden Mitteln selbst zu machen. Das ist ja keine große Kunst. Der Rest greift eben zu Cliqz.

Die fragwürdigen Nutzungsbedingen von Oculus Rift

Gizmodo schrieb vor zwei Tagen einen sehr länglichen Artikel über die fragwürdigen Nutzungsbedingungen von Oculus Rift. Wenn man sich die einmal durchliest, dann wird einem auch schlagartig klar, wieso Facebook die Firma haben wollte: um diese Bedingungen zu diktieren und die daraus entstandenen Daten abzugreifen. Schöne neue Welt!

Aber mal nun der Reihe nach.

Es beginnt zunächst einmal mit folgendem Passus:

By submitting User Content through the Services, you grant Oculus a worldwide, irrevocable, perpetual (i.e. lasting forever), non-exclusive, transferable, royalty-free and fully sublicensable (i.e. we can grant this right to others) right to use, copy, display, store, adapt, publicly perform and distribute such User Content in connection with the Services. You irrevocably consent to any and all acts or omissions by us or persons authorized by us that may infringe any moral right (or analogous right) in your User Content.

Das bedeutet nichts anderes, dass wenn man eigene Inhalte über die Dienste online stellt, man Oculus kostenlos ein unwiderrufliches und uneingeschränktes Nutzungsrecht für diese einräumt, mehr noch, dass Oculus diese Inhalte sogar weiter lizenzieren darf!

Das ist schon mal ein dickes Ding, als Linden Lab die TOS von Second Life derart änderte, gab's gehörig eine auf den Deckel. Oculus dagegen startet gleich von Anfang an mit dieser "all deine Inhalte gehören mir"-Klausel.

Weiterhin erlaubt man Oculus das Sammeln von Daten aller möglicher Art:

* Information about your interactions with our Services, like information about the games, content, apps or other experiences you interact with, and information collected in or through cookies, local storage, pixels, and similar technologies (additional information about these technologies is available at https://www.oculus.com/en-us/cookies-...);

* Information about how you access our Services, including information about the type of device you’re using (such as a headset, PC, or mobile device), your browser or operating system, your Internet Protocol (“IP”) address, and certain device identifiers that may be unique to your device;

* Information about the games, content, or other apps installed on your device or provided through our Services, including from third parties;

* Location information, which can be derived from information such as your device’s IP address. If you’re using a mobile device, we may collect information about the device’s precise location, which is derived from sources such as the device’s GPS signal and information about nearby WiFi networks and cell towers; and

* Information about your physical movements and dimensions when you use a virtual reality headset.

Also wenn das mal nicht umfangreich ist, sie sammeln sogar Daten über die Bewegungen und Körperdimensionen. Was die das wohl angeht?

Wozu es übrigens genutzt werden soll? Werbung!

To market to you. We use the information we collect to send you promotional messages and content and otherwise market to you on and off our Services. We also use this information to measure how users respond to our marketing efforts.

Also trotzdem man für Oculus bezahlt, ist Oculus nicht das Produkt und man selber der Kunde, sondern man ist mal wieder trotz des hohen Preisetiketts das Produkt. Da Oculus als Gerät normal dauerangeschaltet ist, kann das auch für eine umfangreiche Datensammelei genutzt werden.

Wer weiß, wo das noch alles hinführen wird, aber bei diesen Nutzungsbedingungen kann man nur zu einem raten: Finger weg davon!

 

Microsoft kauft Xamarin, den Hersteller von Mono

Microsoft hat den Softwarehersteller Xamarin erworben, der vor allem als Hersteller der *nix-Implementation von .NET namens Mono bekannt geworden ist. Mono startete seinerzeit als ein von Microsoft nicht genehmigter, unabhängiger und quelloffener Nachbau von deren .NET-Umgebung, der im Laufe der Zeit eine sehr hohe Reife erreichte, aber dessen Weiterexistenz auch immer wegen dem Minenfeld der Softwarepatente als kritisch angesehen worden war.

Diese Besorgnis kann man inzwischen getrost zu den Akten legen, da in 2015 Microsoft selber seine eigene Implementierung von .NET auf Github unter der quelloffenen und weit verbreiteten MIT/Apache-2-Lizenz veröffentlicht hat.

Diese Neuigkeit ist sowohl für Second Life als auch Opensimulator wichtig. Mono ist nämlich in Second Life als Engine die Grundlage für die aktuelle Implementierung der Skriptsprache LSL, während es für Opensimulator die Grundlage für den Betrieb überhaupt darstellt, da Opensimulator in C# geschrieben ist, also der Sprache, die .NET/Mono als Betriebsvoraussetzung benötigt.

Durch den Zukauf von Ximarin ist zu erwarten, dass sich die Qualität von Mono im Laufe der Zeit noch verbessern wird; beide Unternehmen arbeiteten im Laufe der Jahre sowieso schon sehr eng miteinander.

Bitcoin ist so gut wie tot

Ich hatte schon sehr lange nichts mehr über meinen Lieblingshype Bitcoin, also muss da mal wieder etwas her. Ich selber halte Bitcoin für ein interessantes Experiment, dessen Bedeutung aber völlig überschätzt wird, für hochspekulativ und absolut nicht reif für den ernsthaften Einsatz, um mal meine Position abzustecken. Die dezentrale Bezahlfunktion zeigt, dass es dafür Bedarf gibt, aber die Implementierung mit dem Mining ist die totale Katastrophe, ebenso die feste, maximale Geldmenge.

Wie auch immer - Mike Hearn hat nun das Bitcoinprojekt verlassen, das aber nicht, ohne vorher noch einen langen Kommentar darüber zu schreiben, warum er aktuell Bitcoin für gescheitert hält. Ihr kennt Mike Hearn nicht? Nun, er hat die letzten fünf Jahre Vollzeit an Bitcoin gearbeitet und die Implementierung auf Smartphones ist weitestgehend sein Werk. Er weiß also recht genau, wovon er spricht.

Was ist das Problem? Das Grundproblem sieht er darin, dass eine der Grundlagen von Bitcoin, die sog. Block Chain, langsam aber sicher an die Grenzen ihrer bisherigen Implementierung stößt, und so das System langsam wird und unzuverlässig. Die Block Chain ist dabei das Journal aller bisherigen Bitcointransaktionen. Das Problem liegt nach seiner Darstellung daran, dass pro Block maximal ein Megabyte als Speicherbegrenzung vorgesehen ist und diese Grenze langsam erreicht wird.

Nun sollte es doch ein einfaches sein, die Grenze zu erhöhen, meinetwegen auf zwei Megabyte zu verdoppeln oder mehr. Das ist es in der Theorie, praktisch aber gibt es dabei ein Problem: 50% der Miningkapazitäten weltweit werden inzwischen von gerade mal zwei Personen kontrolliert, und 95% der Kapazitäten von weniger als 10. Und diese Leute haben kein Interesse an einer Änderung der Skalierbarkeit, sondern blockieren diese.

Dazu kommt, dass die Mehrheit dieser Leute in China sitzt und der Internetverkehr von und nach China durch die große Firewall verkrüppelt ist.

Bitcoin war früher ein offenes Experiment, nun sei es eine Angelegenheit, die von einigen wenigen Oligopolisten kontrolliert werde, die Änderungen nicht wollen.

Und damit sei es gescheitert. Auch sei das verbliebene Entwicklerteam nicht fähig, eine Änderung durchzusetzen.

Dafür käme nun mit der nächsten Version ein neues Feature namens "Replace by fee", was im Grunde nichts anderes ist, als dass man als Benutzer nachträglich eine Bezahlung innerhalb eines gewissen Zeitraums rückgängig machen kann. Klingt gut, nur bedeutet das für Händler, dass sie nun mitunter Stunden warten müssen, bis die Transaktion dann auch in der Block Chain auftaucht.

Aktuell gibt es zwei Forks, die die Probleme beheben wollen. Ein älterer, Bitcoin XT, war sofort unter Beschuss, als manche damit anfingen, diesen zu benutzen.

Als das größte Problem sieht Hearn aber die massive Anhäufung von Miningpower bei weniger als 10 Personen an; solange es diese gibt und man dieses Oligopol nicht aufbrechen kann, wofür keiner wirkliche Lösungsvorschläge hat, wird die weitere Entwicklung sehr schwer sein und man hat damit im Grunde inzwischen genau das, was man mit Bitcoin nicht haben wollte, dass einige wenige Leute etwas nahezu völlig kontrollieren.

ü, ö, ä usw., oder: bitte ändert alle das mal auf slinfo.de doch per Hand!

Slinfo.de steigt in der Zeit vom 28.12. bis voraussichtlich 30.12.2015 auf eine neue Forensoftware um. Man wirft das alte vBulletin 4.2.2 raus und leistet sich eine Lizenz des neuen Shooting Stars xenForo am Forenhimmel.

So weit, so gut, wenn da nicht dieses winzig, winzig kleine Umlautproblemchen wäre, das man bisher nicht in den Griff bekommen hat: was noch in der alten Installation normal nach "ä", "ö", "ü", "ß" usw. aussieht, das sieht in der neuen Software auf einmal total abenteuerlich nach was ganz anderem aus wie eben beispielsweise "ü", "ö", "ä" und anderes mehr.

Kurz: die Umlaute werden in der neuen Software nicht mehr richtig angezeigt und sehen wie Schrott aus.

Nun arbeitet man mit Hochdruck bereits seit Wochen an der Umstellung und auch dem Problem, also sollte man meinen, dass dieses in Zeiten von Unicode einfach zu lösen sei - aber weit gefehlt!

Denn heute schrieb der Betreiber von Slinfo.de in einer Ankündigung unter anderem, dass das Umlautproblem nach wie vor bestehen bleibt und man doch bitte nach der Umstellung (!) dann in den eigenen Posts (!) diese Umlautartefakte selbständig nachbessern (!) möge. In den Threadtiteln macht das die Moderation, bis es wieder ein gutes Bild abgibt.

Kopf -> Tischkante! Echt, so etwas kann man sich gar nicht ausdenken, es ist traurig aber wahr! Offenkundig hat man bis heute keine Lösung für das Problem gefunden und die Hoffnung aufgegeben, bis zur Umstellung noch eine zu finden und auch die Hoffnung aufgegeben, überhaupt noch eine zu finden!

Geschätzt dürfte bei einem so alten und großen Forum wie Slinfo.de sich die Datenbank im Bereich von gut und gerne 5-10 Gigabyte bewegen, laut Statistik sind in dieser aktuell an die 621.000 Beiträge gespeichert. Soll man nun die alten Beiträge alle per Hand ändern oder was? Das sieht doch nach absolut nichts aus! Und wenn man die neuesten per Hand ändert, dann sind die alten noch immer unbereinigt und nerven einfach, wenn sie mal in der internen Forensuche oder per Google gefunden auftauchen!

Also echt... das kann's doch nicht sein! Beste Grüße!

Der Weg der Software oder: auf den Schultern von Riesen stehen

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.

konqueror-web-browser

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.

HTTP/2.0 in den Startlöchern

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.

CDN und was es bedeutet

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.

High Fidelity, SL TNG und Opensimulator

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.