Iceweasel ESR für Debian Squeeze und Wheezy – Kein Support mehr für 3.6

Eine kurze Erinnerung an alle, die Iceweasel alias Firefox mit Debian verwenden. Mike Hommey, Paketverwalter für Iceweasel und Firefox-Entwickler, hat gestern in seinem Blog noch einmal daran erinnert, dass Iceweasel 10 ESR in den Backports für Debian Squeeze zur Verfügung steht. Die ehemals unterstützte Version 3.6 erhält keine Updates mehr und sollte nicht mehr benutzt werden.

Weiterhin wird zwar Iceweasel 3.5.16 wie gewohnt bis 2014 unterstützt, er empfiehlt aber ein Upgrade auf Iceweasel 10 zu machen. Dieser Empfehlung möchte ich mich hier anschließen. Man bemerkt deutlich die verbesserte Leistung des neueren Iceweasel-Browsers. Außerdem stehen deutlich mehr Funktionen und aktuellere Addons zur Verfügung.

Update 07.06.2012: Heute wurde auf der Debian-Mailingliste „debian-security-announce“ offiziell empfohlen von Iceweasel 3.5 auf Iceweasel 10 ESR zu wechseln.

Ich gehe davon aus, dass Iceweasel 10 uns in der nächsten stabilen Veröffentlichung von Debian erhalten bleibt und entweder separat durch Mike Hommey weitergepflegt wird oder durch die nächste ESR-Version, Iceweasel 17, wie bisher durch einen Backport ersetzt wird.

Unter dem Begriff ESR oder Extended Support Release verbreitet Mozilla ein Langzeit-Release, dass vor allem Unternehmen und Öffentlichen Einrichtungen zu Gute kommen soll, die an einer stabilen und langfristig gepflegten Version interessiert sind und nicht die Möglichkeiten haben den normalen „Rapid-Release“-Zyklus zu supporten.

Die aktuellste Version von Iceweasel befindet sich zur Zeit in Experimental. Auf mozilla.debian.net werden nach wie vor die Wege beschrieben, wie man an die gewünschte Version für den jeweiligen Debian-Zweig gelangen kann.

Ansonsten kann ich noch meine Artikel zu Debians Backports oder Iceweasel 6 empfehlen, die das Prinzip ebenfalls erklären.

Wer immer den Überblick über das Versionswirrwarr behalten möchte, kann sich z.B. auch apt-show-versions installieren. Hat man zuvor alle Quellen/Zweige in der /etc/apt/sources.list eingetragen, für die man sich interessiert, genügt

apt-show-versions -a iceweasel

um eine Übersicht über alle verfügbaren Paketversionen zu erhalten.

Dwb und Jumanji: Zwei Webkit-Browser mit vi-ähnlicher Steuerung

Letzte Woche hat mich Georg auf einen interessanten Webkit-Browser namens Jumanji aufmerksam gemacht. Ich ergreife hier die Gelegenheit und stelle sowohl Jumanji als auch Dwb kurz vor. Beide setzen auf die Webkit-Engine und eine vi-ähnliche Steuerung und eignen sich als leichtgewichtige Browser-Alternative nicht nur für ältere Rechner.

Die Bilder stammen alle von meiner ArchLinux-Installation auf dem Inspiron 4000.

Jumanji

Jumanji ist ein minimalistischer WebKit-Browser, dessen Interface schlicht und platzsparend und deswegen auch sehr übersichtlich ist.

Die Bedienung lässt sich tatsächlich mit dem Stichwort vi-ähnlich auf den Punkt bringen. Genauso wie bei seinem berühmten Vorbild betritt man mit dem Doppelpunkt den Kommandomodus und kann von dort diverse Befehle aufrufen. Besonders praktisch ist es mit Hilfe von Tab-Vervollständigung von Befehl zu Befehl zu wechseln. Noch schneller geht es nur noch mit Tastenkürzeln, die man wie bei vi durch das „:map„-Kommando definieren kann.

Neue Tabs öffnet man entweder mit :tabopen oder mit der Taste t. Sie erscheinen in dezentem schwarz hinterlegt am oberen Bildschirmrand. Aktive erkennt man durch die geänderte Schriftfarbe. Interessant ist auch, dass man durch den Browserverlauf mit Tab-Vervollständigung navigieren kann. Mit der rechten Maustaste lässt sich ein kleines Menü aufrufen, um die Seite neu zu laden oder vor- und zurück zu wechseln.

Jumanji lässt sich bei Arch Linux aus dem AUR installieren. Wer yaourt benutzt, erledigt das mit:

yaourt -S jumanji-git

P.S.: Als Randnotiz fiel mir noch der Webseitengenerator der offiziellen Jumanji-Homepage auf. Hakyll ist eine Haskell-Bibliothek, um statische Webseiten zu generieren. Nur falls jemand dachte, es gäbe keine weiteren Alternativen zu den schon im Artikel und Kommentaren genannten Blogkompilierern. 🙂

Dwb

Im Gegensatz zu Jumanji existiert von Dwb seit kurzem eine offizielle Debianversion in Sid und Wheezy.

Dwb basiert ebenfalls auf der Webkit-Engine, besitzt vi-ähnliche Tastaturkürzel und Kommandos und zeichnet sich durch eine ebenso schlanke und effiziente Benutzerschnittstelle aus. Tatsächlich ähneln sich Jumanji und Dwb in vielerlei Hinsicht.

Der große Unterschied ist jedoch, Dwb hat das Konzept schon deutlich weiter entwickelt. Er ist umfangreicher, bietet mehr Kommandos und Funktionen. Genauso wie bei Jumanji lässt sich ein Adblock-Skript einbinden, darüber hinaus besteht aber auch die Möglichkeit Javascript oder Flash zu blockieren. Neue Tabs lassen sich mit O öffnen und d schließen. Lesezeichen werden mit M hinzugefügt und übersichtlich mit gB angezeigt und in einem neuen Tab geöffnet. Links kann per Tastatur gefolgt werden.

Besonders erwähnenswert ist auch, dass sich Einstellungen und Optionen auf einer Extraseite innerhalb des Browsers konfigurieren lassen und die Dokumentation in einem guten Zustand ist. Die Handbuchseite ist vorbildlich.

Die Suche funktioniert genauso wie bei Vi/Vim, indem die Taste / benutzt, der Suchbegriff eingegeben und schließlich n zur Vorwärtssuche ausgeführt wird.

Fazit

Mir gefallen tastaturgesteuerte, leichtgewichtige Webbrowser. Dwb hat bei mir aber gegenüber Jumanji die Nase vorn. Beide ähneln stark dem Vimperator-Plugin des Firefox, setzen aber stattdessen auf die Webkit-Engine und ordnen sich in die Reihe von Webbrowsern wie Vimprobable, Uzbl oder Surf ein.

Webkit-Browser sind nicht wirklich ungewöhnlich, was für die Engine spricht.

Der Speicherverbrauch und auch die Reaktionsgeschwindigkeit lässt sich am besten mit der von Surf vergleichen. Wie im letzten Test, habe ich wieder ps_mem.py als Maßstab benutzt.

Jumanji:

Private: 19MB + Shared: 1,3MB = 20,3MB

Dwb:

Private: 21,1MB + Shared: 2MB = 23,1MB

Die Startzeiten waren sogar noch schneller als bei Surf, obwohl das auch an dem selbstkompilierten ArchLinux-Paket liegen kann. Für die Zukunft werde ich dwb häufiger benutzen und denke, dass es eine gute Wahl war ihn in Debian aufzunehmen, da er sich durch seine umfangreiche vi-ähnliche Steuerung von den anderen Browsern in Debian positiv unterscheidet.

Opera 11.60: Crash nach Laptopmodell

Seit einigen Tagen habe ich ein paar seltsame Probleme mit Opera 11.60. Ich benutze den Inspiron 4000 Laptop auch mal gerne dazu verschiedene Webbrowser zu testen und präsentiere meine Erfahrungen dann mit unfehlbarer wissenschaftlicher Präzision und absoluter Unabhängigkeit in diesem Blog.

Nun gab es in den letzten Monaten ein Update von 11.50 auf 11.60 und ehrlich gesagt, erwartete ich bei so kleinen Zahlen keine großen Wirkungen. Doch Opera 11.60 verhielt sich auf dem Inspiron mit Debian Sid plötzlich nicht mehr ganz so wie erwartet. Während er letzten Sommer mit Version 11.50 noch problemlos funktionierte, gab es nun direkt nach dem Start schon den ersten Absturz. Die Fehlermeldungen sind kryptisch und anscheinend nur für die Entwickler gedacht, was mich aber bei einem closed source Programm nicht besonders überraschte.

Ich probierte es daraufhin mit dem parallel installierten Arch Linux, doch auch hier kam ich nicht einmal über das Bestätigen der EULA hinaus. Opera fror ein und versagte den Dienst.

Wenn das nun bei zwei verschiedenen Linuxdistributionen passiert, kann es doch nur an Opera liegen, oder? Ich gab dennoch nicht auf und installierte Opera auch auf dem Thinkpad 600 mit Debian Stable, wo dwm als Fenstermanager läuft. Leider auch hier das gleiche Ergebnis.

Klare Sache. Das musste doch sicherlich auch noch andere Leute betreffen. Eine ausgedehnte Internetsuche brachte aber nichts wirklich erhellendes, Abstürze ja, aber in den gleichen Threads auch wieder viele positive Kommentare, die bestätigten, dass Opera funktionierte.

Kurzum ich fand keinen Fingerzeig oder logische Erklärung für dieses Problem. Ich experimentierte also noch einmal mit speedy, dem Toshiba Portégé 3110CT. Auch hier lief Debian Stable und ich probierte es mit dem Awesome-Fenstermanager.

Erfolg! Opera ließ sich starten und auch mein Blog passte haargenau in die 800×600 Pixel Auflösung.

Was hier schief läuft, ich kann es nicht sagen. Opera scheint zumindest bei meinen Rechnern, sich seine Freunde ganz genau auszusuchen. Ich hoffe nur, dass das nicht der Anfang vom Ende bei der Unterstützung von älteren Rechnern und Linux bei Opera gewesen ist. Möglicherweise habe ich aber auch den großen „Oha“-Artikel einfach überlesen und alles funktioniert wie beabsichtigt. 🙁

Schnell und leicht: Dillo 3 ist zurück

Es war einmal ein Browser, der war schnell und sehr leicht. Er basierte auf GTK1, startete augenblicklich und war in vielen Distributionen zu finden, die sich auf ältere Hardware spezialisiert hatten.

Der Nachfolger mit der Versionsnummer 2 stieg danach auf die FLTK2 Bibliothek um, welche aber einige Lizenzprobleme hatte, so dass der Browser in vielen bekannteren Linuxdistributionen nicht aufgenommen werden konnte.

Wir schreiben das Jahr 2011 und Dillo 3 hat das Licht der Welt erblickt. Mittlerweile sind die Entwickler wieder auf FLTK1.3 umgeschwenkt, obwohl die Lizenzprobleme für die FLTK2-Bibliothek gelöst sind. Wie auch immer, Debian hat sich entschieden Dillo 3 aufzunehmen, weswegen ich mir den Browser kurzerhand mit Apt installiert habe.

Bei den Systemanforderungen ist Dillo 3 nach wie vor äußerst anspruchslos. Er belegt ca. 2 MB auf der Festplatte und laut ps_mem.py Skript ca. 11 MB RAM auf meinem Inspiron 4000. Die Startzeit um diese Seite zu laden liegt bei ca. 2 Sekunden.

Dillo hat sich offensichtlich seit meinen Versuchen Dillo 2 vergangenes Jahr zu kompilieren weiterentwickelt und bietet nun bessere CSS-Unterstützung. Mein WordPress-Blog ist lesbar und alle wichtigen Navigationslinks sind auch dort wo sie sein sollen.

Natürlich hat Dillo 3 auch ein paar Schwächen. HTTPS-Seiten würde ich weiterhin mit ihm nicht besuchen, da er außer rudimentärsten Kommandos SSL/TLS-Verschlüsselung nicht unterstützt.

Die CSS-Fähigkeiten sind sichtbar besser geworden, aber an die Qualität eines modernen Webkit-, Gecko- oder Presto- Browsers kommt er nicht heran.

Für alle, die immer auf der Suche nach dem besten Kompromiss zwischen Leichtigkeit und Funktionalität sind, kommt Dillo als Webbrowser als eine Möglichkeit in Frage. Mittlerweile bieten aber Webkit-Browser wie Surf deutlich bessere Rendereigenschaften bei vergleichsweise geringen Hardwareanforderungen.

Für reine HTML-Seiten ist Dillo ideal, obwohl links2 mit der -g Option ähnliche Ergebnisse bietet. Für Textseiten ohne Javascript und alles andere gibt es ja auch noch elinks. Interessant für Webentwickler ist auch Dillos Buganzeige am unteren rechten Bildschirmrand.

Am Ende muss man einfach abwägen, was man tatsächlich zum Browsen braucht. Standardmäßig ist Dillo sehr sicherheitsbewusst eingestellt. Cookies werden immer abgelehnt. Normalerweise lässt sich dieses Verhalten in ~./dillo/cookiesrc wieder ändern.

DEFAULT DENY
fltk.org ACCEPT
.host.com ACCEPT_SESSION

Hiermit werden alle Cookies abgelehnt, bis auf fltk.org, welches immer akzeptiert wird und host.com, wofür Dillo aber nur für die Dauer der Sitzung Cookies entgegennimmt. Leider gelang es mir trotzdem bis jetzt nicht, mich in das WordPress-Backend oder Google-Mail einzuloggen. Bei letzterem könnte auch die Beschränkung auf „Standardbrowser“ eine Rolle spielen.

Häufig gestellte Fragen beantwortet die Dillo FAQ.

Wie immer gilt, Dillo am besten selbst einmal ausprobieren.

Ein Vergleich von grafischen Browsern für Linux

Mal ehrlich der einzige Grund, warum alle Welt noch nicht ausschließlich auf der Konsole lebt, ist die Notwendigkeit Internet Banking, Shopping und Social Networking über einen grafischen Browser abzuwickeln. Bemitleidenswert erscheinen da frühere Generationen, die ihre Überweisungen noch persönlich bei ihrer Hausbank vorbeibringen mussten, dabei im Plausch mit den Bankangestellten ihr Soziales Netzwerk erweiterten und danach erstmal bei Wertkauf einkaufen gingen. Damals.

Natürlich möchte heute niemand mehr in eine solche Schublade gesteckt werden. Ich natürlich auch nicht, weswegen ich als moderner Mensch nicht nur einen grafischen Browser sondern deren gleich sechs, übrigens eine vollkommene Zahl, auf meinem Laptop installiert habe. 😉

Ich hatte schon in meinem Beitrag zu den Webkit-Browsern und noch etwas länger her zu Leichtgewichtigen Linuxanwendungen erwähnt, dass ich mir gerne die Unterschiede der zahlreichen Webbrowser auf älteren Laptops anschaue.

Nicht ganz erstaunlich sind diese mitunter ziemlich groß. Was liegt also näher als die Erfahrungen mit dem Internet zu teilen.

Als Testrechner benutzte ich den Inspiron 4000, einen PIII mit 800MHz, 256MB RAM und einer 4200rpm Festplatte.

Ergebnis:

Chromium 13: Start1       26s
             Start2       15s
             Private:     62,2MiB
             Shared:      18,2MiB

Iceweasel 6: Start1:     27s
             Start2:     17s
             Private:    51,2MiB
             Shared:      2,7MiB

Midori 0.4:  Start1:      8s
             Start2:      4s
             Private:    34,7MiB
             Shared:      7,3MiB

netsurf 2.7: Start1:     14s
             Start2:      8s
             Private:    17,2MiB
             Shared:      3MiB

Opera 11.5:  Start1:    17s
             Start2:     9s
             Private:   58,9MiB
             Shared:     2MiB

surf:        Start1:     7s
             Start2:     4s
             Private:   23MiB
             Shared:     2,5MiB

Was bedeuten die Zahlen? Zum einen habe ich die Zeit gemessen, wie lange es vom Start dauert bis der Browser www.gambaru.de aufgerufen und dargestellt hat. Danach habe ich den Browser geschlossen und erneut die gleiche Seite aufgerufen. Über diese Startzeit gibt Start2 Auskunft. Schließlich habe ich mit dem Python Skript ps_mem.py aus dem letzten Beitrag den Speicherverbrauch gemessen. Dabei wurden außer dem Terminalemulator urxvt keine weiteren Programme aufgerufen und es waren keine weiteren Tabs offen.

Klar, es ist alles für die Wissenschaft. Wenn man es aber ernsthaft angehen will, muss man mehrere Tests durchführen, über Tage und Wochen Buch führen, Werte messen und einen Durchschnittswert bilden. Denn je nach dem, wie viele weitere Tabs man parallel öffnet oder welche Anwendungen zusätzlich laufen, das Ergebnis verändert sich.

Ich denke, ich kann trotzdem guten Gewissens zu einem Urteil kommen.

Iceweasel alias Firefox ist mein bevorzugter Browser auf praktisch jedem System. Wie der Test aber zeigte ist der gute Fuchs nicht der schnellste bei den Startzeiten. Genauer gesagt fühlt er sich sogar ziemlich zäh an, wenn man versucht einzelne Webseiten oder sogar mehrere davon aufzurufen.

Chromium wird manchmal sogar als leichtgewichtige Alternative bezeichnet. Das ist er mit Sicherheit nicht. Er bietet aber eine akzeptable Startzeit, die sich nicht großartig von Iceweasel unterscheidet. Ich persönlich sehe nur marginale Unterschiede auf einem älteren Laptop.

Das Einzige, was man Opera vorwerfen kann ist, Opera ist nicht Freie Software. Mittlerweile kämpft Opera im Browser-Markt förmlich ums Überleben. Schade eigentlich, denn Opera war und ist eine Quelle für Innovationen. Die Startzeit ist besser als bei anderen großen Browsern. Dazu bietet Opera einige Alleinstellungsmerkmale, wie Opera Unite, Opera Mail oder Opera Turbo.

Netsurf ist quasi der Außenseiter. Im Grunde genommen dreht sich alles um Webkit, Gecko oder Presto. Er ist genügsamer als die großen Spieler, bietet aber leider auch wesentlich weniger Feature. Obwohl ich wahrscheinlich mit netsurf leben könnte, gäbe es keine anderen Browser,ist es doch etwas enttäuschend, dass er weniger schnell als bekannte Webkit Browser ist und gleichzeitig auch noch die Webseite schlechter als das Original darstellt.

Midori verwende ich schon sehr, sehr lange. Zwischenzeitlich war die Startzeit ziemlich schlecht und es gab einige Bugs, die Midori gegenüber den großen Browsern klar zurückfallen ließen. Seit die 0.4 Version erschienen ist, spielt Midori wieder vorne mit. Die Startzeit auf dem älteren Laptop ist hervorragend und die Webseiten werden ausgezeichnet gut gerendert. Manchmal kommt es zu einem unerwarteten Absturz, den ich leider nicht reproduzieren kann und nach wie vor ist das sogenannte Speed-Dial Feature buggy. Zumindest kann ich keine Links per Linksklick mit der Maus hinzufügen.

Surf ist ein minimalistischer Traum. Dieser Browser benutzt wie Midori die Webkit-Engine, ist aber ansonsten radikal auf Minimalismus getrimmt. Er nimmt relativ wenig Speicher in meinem System ein und wenn man so wie ich nur eine handvoll Webseiten hat, die man wirklich braucht, sehe ich auch keine Probleme mit surf.

Mein Fazit ist: Geschwindigkeit und Startzeit ist nicht alles. Ich bin auf meinem Laptop mit Midori seit Version 0.4 wieder sehr zufrieden. Dieser Browser verbindet sowohl Standards als auch schnelle Startzeiten.

Wenn man lediglich ein paar Webseiten regelmäßig aufruft und weiß, dass diese mit surf funktionieren, spricht nichts dagegen auch diesen kleinen Webkit Browser zu verwenden.

Wie schon erwähnt benutze ich Iceweasel in der Regel am häufigsten. Er ist zwar nicht der schnellste, er bietet mir aber mit Abstand die meisten Erweiterungsmöglichkeiten von allen vorgestellten Browsern.

Auf neueren Rechnern merkt man alle diese Unterschiede kaum. Erst wenn man Browser auf älteren Computern ausprobiert, fällt dies wirklich ins Gewicht.

Die Zahlen werden mit Sicherheit auf jedem System anders ausfallen. Trotzdem glaube ich, dass sie zumindest auf meinem Laptop die Wirklichkeit richtig widerspiegeln. Übrigens, für einen Vergleich von text-basierten Browsern hat K.Mandla schon interessante Daten veröffentlicht. 😉