Tag: "Google"

Angeregt von einem Artikel meines künftigen Arbeitgebers über die Weiterentwicklung von Firefox in den Versionen 10, 11 und 12, möchte ich ein paar Gedanken über die merkwürdige Prioritätenvergabe der Mozilla Foundation loswerden.

Die Features der drei kommenden Versionen konzentrieren sich fast ausschließlich auf Komfort und die weitere Vereinheitlichung der Benutzeroberfläche. Natürlich sind dies bei einem Browser sehr wichtige Faktoren, aber meiner Meinung nach, hat Firefox viel größere Defizite, die Angriff genommen werden sollten.

Projekt Electrolysis

Wie der Name schon sagt, geht es um die Trennung des Ganzen in seine Bestandteile. Auf Firefox bezogen, soll das Projekt Electrolysis auf eine Aufspaltung des großen Firefox-Prozesses in mehrere Prozesse ermöglichen. Google setzt eine solche Architektur von Anfang an in Chrome ein. Es gibt einen Hauptprozess und für jeden geöffneten Tab einen weiteren Prozess. Desweiteren wird jedes Plug-In sowie jede Extension in je einen weiteren Prozess ausgelagert. Damit erreicht Google einen stabilen, effizienten Browser, der den Arbeitsspeicher nicht unnötig belastet und selbst bei einem Absturz eines Tabs, Plug-Ins etc.  immer noch weiterlaufen kann. Apple und Microsoft fanden diese Idee so gut, dass Safari 5 und der Internet Explorer 9 ein ähnliches Prozess-Modell verwenden.

Mozilla wollte ebenfalls auf den Zug aufspringen und hat daher das Projekt Electrolysis ins Leben gerufen. Als ersten Schritt wurde die Ausgliederung von Plug-In-Prozessen in Angriff genommen, die mit Firefox 3.6.4 vor knapp 18 Monaten ihren Weg in die offiziellen Releases fand.

Schritt 2 war die Teilung in den Hauptprozess und Einzelprozesse für die offenen Tabs. Da Mozilla offensichtlich keine Veranlassung sah, dass dieses Feature möglichst schnell in die Desktop-Version Einzug hält, wurde es zuerst in Fennec, die mobile Version von Firefox, implementiert —  durchaus sinnvoll, um mit den begrenzten Ressourcen effizient umzugehen. Seit März vergangenen Jahres ist Fennec im Android Market erhältlich. Viel getan hat sich seit dem nichts mehr. Die Projekt-Seite im Mozilla Wiki wurde zuletzt im April 2011 aktualisiert und auch an anderer Stelle finden sich kaum Hinweise, wie es mit der Entwicklung von Electrolysis weitergeht.

In Anbetracht des hohen Speicherbedarfs von Firefox, insbesondere wenn Extensions im Spiel sind, finde ich es sehr schade, dass sich hier nicht mehr tut oder der Fortschritt nur sehr mangelhaft kommuniziert wird. Firefox würde enorm von der Prozess-Aufteilung profitieren, sei es in Sachen RAM-Verbrauch, als auch Stabilität und Geschwindigkeit.

JavaScript

Sicherlich kann man der Mozilla Foundation zu Gute halten, dass sich die JavaScript-Leistung seit dem Release von Firefox 4 und 9 signifikant verbessert hat, dennoch besteht nach wie vor großer Aufholbedarf gegenüber Chrome. Mit IonMonkey ist ein neuer JIT in Arbeit, der das bestehende Konstrukt aus JägerMonkey bzw. TraceMonkey ablösen soll. Wie die Entwickler zugegeben haben, ist die aktuelle Architektur nur sehr schwer zu optimieren und daher wird IonMonkey zum Großteil komplett neu geschrieben.

Diese Bestrebung ist sehr löblich und wird sicher auch Früchte tragen, aber sie kommt reichlich spät und wird zu dem auch viel Zeit in Anspruch nehmen. Wir können froh sein, wenn IonMonkey am Jahresende seinen Weg in die offiziellen Releases findet. Aber die Konkurrenz schläft nicht und Google hat schon ein paar mal bewiesen, dass sich massiv an der Performance-Schraube ihres eigenen JITs, V8, drehen können. Verbesserungen von 10 – 30% mit einem Release waren keine Seltenheit. Microsoft, Opera und Apple werden ebenfalls daran arbeiten die JavaScript-Leistung ihrer Browser deutlich zu verbessern.

Firefox läuft hier Gefahr ins Hintertreffen zu geraten und daher sollten die Bestrebungen für IonMonkey unbedingt verstärkt werden. JavaScript ist heute unverzichtbarer Bestandteil der meisten Websites und Rich Internet Applications werden zunehmend wichtiger, insbesondere da Microsoft endlich eingesehen hat, dass der Internet Explorer technisch weiterkommen muss.

Profile

Wenn Firefox sich seltsam verhält, oft abstürzt oder sich anderweitig unangenehm bemerkbar macht, wundern sich viele, dass eine Neuinstallation nichts bringt. Die Universalwaffe gegen Windows-Probleme versagt hier kläglich, weil die Nutzerdaten, Einstellungen und Extensions als separates Profil in den Anwendungsdaten bzw. im Home-Verzeichnis gespeichert werden und dort auch bleiben, wenn man den Browser deinstalliert. Wird Firefox neu installiert, greift er auf dasselbe Profil wie die vorherige Installation zu und hat daher auch die gleichen Probleme.

Probleme mit den Profilen ziehen sich leider immer wieder quer durch die gesamte Geschichte von Firefox und gab es auch schon vorher in der Mozilla Suite — heute besser bekannt als SeaMonkey. Warum das so ist, ist bisher nicht klar geworden. Im Verlauf der Firefox-Entwicklung hat Mozilla in den Profilen einiges verändert.

Vieles, was früher in simplen Text-Dateien gespeichert wurde, befindet sich heute in SQLite-Datenbanken. Damit konnte man z.B. Dinge wie die AwesomeBar, die intelligente Adressleiste, realisieren. Leider ergaben sich hierbei aber neue Probleme. Insbesondere die Browsing History wird sehr ausgedehnt gespeichert, damit aber sehr groß und mit der Zeit auch immer langsamer. Wer keine SSD sein Eigen nennt, kennt die teils langen Startzeiten von Firefox, die unmittelbar damit zusammenhängen. Selbst wenn das Fenster inzwischen geöffnet wurde und man etwas in die Adresszeile eingibt, kann es teilweise mehrere Sekunden dauern, bis überhaupt eine Reaktion erfolgt.

Selbst neue, frische Profile sind manchmal kein Garant dafür, dass Firefox rund läuft. Erst letztens gab es in meinem Freundeskreis den Fall, dass der Browser mit einem ein paar Wochen alten Profil plötzlich regelmäßige Aussetzer hatte und nicht mehr reagierte. Erst ein ganz neues Profil beseitigte dieses Problem.

All dies ist nur ein kleiner Teil mir bekannter Profilprobleme. Mozilla sollte daher schleunigst etwas dagegen unternehmen.

Fazit

Wie man unzweifelhaft sieht, hat Firefox viele technische Macken bishin zu wirklich großen Handicaps. Vielen Nutzern mag dies aktuell noch egal sein, weil sie nicht betroffen sind oder es ihnen egal ist, wie schnell ihr Browser ist. Derzeit ist auch der Erfolg von Chrome kein Anzeichen dafür, dass Firefox auf einem absteigenden Ast wäre. Der steigende Anteil von Chrome geht zum Großteil zu Lasten des Internet Explorers. Trotzdem sehe ich die Mozilla Foundation in der Pflicht endlich angemessen auf og. Problematiken zu reagieren.

Wie bereits erwähnt, schläft die Konkurrenz nicht. Google hat mit Chrome eindrucksvoll gezeigt, wie man einen modernen, schlanken Browser entwickelt. Mozilla tut sich offenbar schwer, Firefox und Gecko entsprechend umzustellen, was für mich als Programmierer bedeutet, dass dort noch viele Altlasten mitgeschleppt werden (müssen). Daher wäre es wohl an der Zeit, einen Strich zu ziehen und vieles komplett neu anzugehen, wie es z.B. schon bei IonMonkey getan wird. Mit einem modernen Aufbau der Interna wäre Firefox zukunftssicher und Mozilla würde sich in der Weiterentwicklung sehr viel leichter tun.

Nach etwas über einem halben Jahr wird es wieder einmal Zeit, den JavaScript Engines der aktuellen Browser-Versionen auf den Zahn zu fühlen. Die Versionssprünge im Vergleich zu den letzten Benchmarks sind beachtlich. Firefox ging von Version 3 (4 war noch Beta) auf 7, Chrome von 10 auf 15. Microsoft machte da einen vergleichsweise kleinen Schritt von 8 auf 9, während Apple und Opera bei ihren Hauptversionen 5 und 11 treu geblieben sind.

Wie üblich dient als Testplattform mein Privatrechner mit folgender Spezifikation: Intel Core i5 750, 8 GB RAM, Intel X25 G2 80 GB und Windows 7 Professional x64 SP 1.

Hier sind die Ergebnisse:

 

Es gibt auch dieses mal keinen klaren Gewinner, der sich alle drei Siege sichern konnte, aber Chrome 15 ist im Schnitt wieder die Nummer 1. Der Internet Explorer 9 mag zwar unter SunSpider der schnellste Kandidat sein, er verliert jedoch die anderen zwei Tests klar. Es liegt daher die Vermutung nahe, dass Microsoft hier einige Optimierungen vorgenommen hat — zumal sich an SunSpider schon länger nichts mehr getan hat.

Wie man schön sehen kann, hat Apple im letzten halben Jahr wirklich Fortschritte mit der Nitro Engine gemacht. Safari hat sich von der roten Laterne ins Mittelfeld vorgekämpft und überholt nun Firefox in gleich zwei Disziplinen. Es bleibt abzuwarten, ob Apple den Vorsprung halten kann. Ab Firefox 9 wird Mozillas JIT JägerMonkey durch Type Inference bis zu 30% mehr Leistung bringen. Dazu befindet sich mit IonMonkey ein neuer JIT in Arbeit, der wahrscheinlich JägerMonkey und evtl. auch TraceMonkey ersetzen wird. IonMonkey wird eine andere, moderne Architektur besitzen und damit die Wartbarkeit als auch Optimierungsmöglichkeiten für die Entwickler deutlich verbessern.

Bleibt noch Opera 11, der sich mal wieder sehr gut schlägt und die klare Nummer Zwei im Starterfeld ist.

Fazit

Chrome gewinnt — wie immer. Opera ist Zweiter und im weiteren Feld kämpft sich Safari an Firefox und Microsofts Internet Explorer vorbei.

Ich bin gespannt, ob Microsoft mit dem Internet Explorer 10 wieder aufholen kann. Vielleicht sollte man in Redmond auch die Release-Zyklen überdenken. Alle anderen Hersteller können wesentlich schneller reagieren und optimieren, während Microsoft nur jährlich neue Major Releases bringen will. Wobei ich es für fraglich halte, ob wirklich jedes Jahr eine neue Version kommen wird.

Natürlich haben theoretische Benchmarks in der Praxis weit weniger Relevanz. Meine aktuellen Experimente mit ExtJS zeigen sehr deutlich, dass bei Rich Internet Applications Firefox immer noch kein sonderlich gutes Bild abgibt. Das aufgebaute UI, das für eine RIA eh noch recht spartanisch ausgestattet ist, läuft in allen anderen Browsern wesentlich weniger träge und ruckelig. Gleiches lässt sich auf diverse andere JavaScript-lastige Seiten übertragen, z.B. GMail oder iCloud.

JägerMonkey mit Type Inference, IonMonkey und die lang erwartete Integration des Electrolysis-Projekts sind darum wichtiger denn je.

Nach langer Abstinenz durch Blog-Unlust, wird es Zeit wieder etwas zu schreiben. Ich habe in vergangenen Tagen einige technische Änderungen vorgenommen:

  • Ein Großteil der statischen Inhalte (Bilder, CSS-Dateien, JavaScripts etc.) wird nun über ein Content Delivery Network (CDN) bereitgestellt. Hierzu verwende ich ich die Services Amazon S3 bzw. Amazon CloudFront. S3 übernimmt die eigentliche Speicherung der Dateien innerhalb des Amazon-Netzwerks. CloudFront bezieht die Daten von S3 und stellt sie wahlweise als Download- oder Streaming-Inhalt über das weltweite CloudFront-Netzwerk bereit. Realisiert wird das ganze über das WordPress-Plug-In W3 Total Cache, das die Dateien zu S3 überträgt und sich um die URL-Umschreibung zu CloudFront kümmert.

    Das klingt nun extrem überdimensioniert und ist es eigentlich auch. Mir geht es dabei um den technischen Aspekt, wie man sowas realisiert und die sich daraus ergebenden Vorteile von Cloud Hosting Services. Abgesehen davon, ist es unschlagbar günstig. Man zahlt keinerlei Grundgebühren, es wird nur abgerechnet, was man wirklich verbraucht. Für meine Verhältnisse in Sachen Traffic und Zugriffe, kostet das nur ein paar Cent im Monat.

  • Nach dem ich zwischenzeitlich wieder Google Analytics als Statistikdienst genutzt hatte, bin ich nun auf Piwik umgestiegen. Piwik ist eine Open Source-Lösung, die fast alles kann, was Analytics auch bietet, läuft aber lokal auf meinem Web-Server. IP-Adressen werden ausschließlich anonymisiert verwendet.

    Wer nicht von Piwik erfasst werden möchte, kann sich hier per Cookie ausschließen lassen.

  • Wie oben schon erwähnt, setze ich nun W3 Total Cache ein. Neben der Bereitstellung der statischen Inhalte über ein CDN, bietet es vor allem diverse Caching-Systeme für Dateien, Datenbank-Inhalte, Objekte oder auch HTTP-Kompression. Die Ladezeiten sollten so angenehmer sein und gleichzeitig wird der Server geschont.

So, das war’s dann erstmal. In Zukunft werden wieder mehr Einträge folgen, wie üblich hauptsächlich über Technik, Web-Entwicklung oder Spiele.

Es ist vollbracht: madcats[welt] läuft mit WordPress.

Angekündigt war dieser Schritt bereits für September, aber wie das halt so ist, kam immer etwas dazwischen. Dabei war eigentlich alles in ein paar Stunden fertig. Der technische Teil war schnell erledigt, aber ein passendes Design zu finden, war ob dieser Riesenauswahl gar nicht so einfach.

Am Ende fiel meine Entscheidung auf zBench, das ich aber zu einer aufpolierten Version von mcw[ruby] umgebaut habe — vom Original-Design ist eigentlich nicht mehr viel übrig. Die Anpassungen sind noch nicht ganz fertig. Bei den Kommentaren und der Tag Cloud wird sich in den nächsten Tagen noch etwas tun.

Um endlich von den Einschränkungen der immer selben Schriftarten für Websites wegzukommen, nutze ich jetzt den Dienst typekit. Typekit bietet professionelle (und daher meist kostenpflichtige) Schriften als Web-Fonts an. Man stellt sich einfach ein Schriftpaket für seine Seite zusammen, fügt zwei Zeilen JavaScript in den head-Bereich ein und kann die Schriften wie gewohnt im Stylesheet angeben. Den Rest erledigt typekit.

Wer das ausprobieren möchte, kann einen kostenlosen Trial-Account mit maximal zwei Schriften und 5 GB/Monat Traffic (für die Schriften) nutzen. Für die meisten Blogs sollte das sogar ausreichen, ansonsten dürfte der “Personal Plan” für 24,99 $ im Jahr die richtige Wahl sein. In Anbetracht der Auswahl und sich ergebenden neuen Möglichkeiten, finde ich das nicht sonderlich teuer. Aktuell verwende ich für Überschriften “Adelle” und im Fließtext “Droid Sans”.

Zum Schluss noch etwas Werbung bzw. die Erklärung für die Überschrift:

Ich kümmere mich ja bereits seit Jahren um die technische Seite von Pias Weblog. Bisher lief alles über die FTP-Veröffentlichung von Blogger. Anfang des Jahres kündigte Google an, diese Funktion zum 1. Mai 2010 einzustellen. Betroffenen wird ein Umzug auf Blogspot mit eigener Domain empfohlen. An sich eine brauchbare Lösung, wenn man dafür nicht die DNS-Einträge der Domain in einem Umfang ändern müsste, den kaum ein großer Hosting-Anbieter erlaubt. Daher haben wir uns für einen Umzug auf WordPress entschieden.

Da Pia gerne und viel fotografiert, haben wir gleich noch ein zweites WordPress als Foto-Blog eingerichtet. Momentan sind noch nicht so viele Bilder online, aber ein Blick lohnt sich definitiv jetzt schon!

Dank einer neuen Rechtslage verzichte ich vorerst auf den Einsatz Google Analytics und ich rate jedem, der es einsetzt das gleiche zu tun – das gilt auch für ähnliche Tracking-Systeme. Hier droht sonst eine neue Abmahnwelle gegen Blogger.

Unsere obersten Datenschutzbehörden hatten den tollen Einfall, dass Tracking-Systeme, die sich auf IP-Adressen beziehen, personenbezogene Daten sammeln und daher erst eine Einwilligung des Nutzers vorliegen muss, bevor seine Nutzungsdaten erfasst werden dürfen. Für mich als Privatnutzer von Analytics hat das keine großen Konsequenzen, auch wenn es recht interessant ist, welche Beiträge am meisten gelesen werden, wie die meist genutzen Keywords aussehen oder woher die Besucher kommen.

Ich arbeite in der E-Commerce-Branche und hier hat es große Auswirkungen, wenn solche Tools nicht mehr verwendet werden dürfen. Tracker wie Econda erleichtern es Shop-Betreibern erheblich Schwachstellen in ihrer Seite zu finden oder gezielt Aktionen wie Newsletter, Werbung, Einträge in Preissuchmaschinen etc. auszuwerten. Mal wieder wird es hier hauptsächlich die kleineren Shop-Betreiber treffen und u.U. viel Geld kosten.

Es ist wirklich eine Sauerei. Sicher wird die IP-Adresse für die Auswertung benutzt, aber es gibt keinen legalen Weg die Daten einer bestimmen Person nur anhand der IP-Adresse zuzuordnen. Das geht nur in Notfällen oder bei Straftaten über die Polizei bzw. Staatsanwaltschaft. Ich sehe daher kein Problem für den Datenschutz, aber das müssen wohl erst die Gerichte klären.

mehr zum Thema bei it-recht-kanzlei.de