Tag: Browser

Posted on

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.

Posted on

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.

Posted on

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 800x600 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. 🙁

Posted on

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.

Posted on

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. 😉

Posted on

Webseiten mit elinks in screen über eine SSH-Verbindung mit rxvt-unicode solarisiert betrachten

Die Überschrift sagt schon alles. Ich vermute ein ähnliches Problem dürfte weniger als ein Milliardstel der Weltbevölkerung betreffen, aber aus Spaß hier die kurze Geschichte.
Ich hatte mich per SSH in den Toshiba Portégé 3110CT alias speedy eingeloggt und wollte nun mit Solarized und meinem neuen 256-Farben-Terminal rxvt-unicode das System updaten und überprüfen, ob mein Blog in elinks irgendwie anders als zuvor aussah. Wenn ich mich remote zu meinem mit Debian Stable betriebenen Laptop verbinde, starte ich danach für gewöhnlich screen, womit es mir leichter fällt mehrere Anwendungen parallel wie mit einem grafischen Fenstermanager zu nutzen.
Als erstes erhielt ich die Fehlermeldung

Error opening terminal: rxvt-unicode

als ich versuchte eine Anwendung wie htop zu starten. Das Problem resultiert daraus, dass das System den Terminal rxvt-unicode-256color nicht kennt und deshalb auch nicht weiß, wie es das aufgerufene Programm darstellen soll. Da das scheinbar ein uraltes Problem ist konnte ich sowohl im englischen Gentoo als auch im deutschen Arch Linux Wiki eine Lösung hierzu finden. Kurz gesagt, muss die Terminfo Datenbank auf den aktuellen Stand gebracht werden und eine Infodatei im versteckten Ordner .terminfo im Home-Verzeichnis des Benutzers auf dem entfernten Rechner angelegt werden.
Im Gentoo-Wiki wird das elegant so gelöst:

infocmp rxvt-unicode | ssh USER@REMOTE_IP 'mkdir -p .terminfo && cat >/tmp/ti && tic /tmp/ti'

Auf dem lokalen Rechner werden die Informationen über den verwendeten rxvt-unicode-Terminal abgefragt und über SSH auf die entfernte Maschine geschickt, wo die Infodatei mit Hilfe von tic von einem Quellformat in ein kompiliertes Format umgewandelt wird. Danach konnte ich dann wie gewohnt Programme öffnen.
Obwohl ich den Terminaltyp in elinks nicht auf 256 Farben eingestellt hatte, sondern weiterhin bei den 16 ANSI Farben belassen hatte, wurde meine Webseite ohne weiteres Zutun schon in den Solarized-Farben dargestellt. Als allgemeiner Tipp solltet ihr bei Farbproblemen % in elinks drücken, womit man zwischen verschiedenen Dokumentfarben umschalten kann. Ich verstehe nur noch nicht, warum bei manchen Farbkombinationen die Schrift fett dargestellt wird und bei manchen normal. Vermutlich hat das etwas mit dem ANSI-Farbcode zu tun. Und so sieht gambaru in elinks solarisiert aus. 😉

Posted on

Iceweasel 6 ist erschienen

Vor kurzem ist Iceweasel 6 erschienen, sehr zeitnah zur Veröffentlichung von Mozillas neuster Firefox Version Nr. 6.
Mittlerweile scheinen sich diverse Abhängigkeitsprobleme in Debian Unstable aufgelöst zu haben, so dass alles seinen gewohnten Gang geht. Das Debian Mozilla Team hat auf seiner Webseite die Installationsbeschreibung auf den neusten Stand gebracht.

Debian Unstable und Testing

Für Unstable lässt sich der neuste Iceweasel-Browser wie gehabt mit

aptitude install iceweasel

installieren. Die deutschen Sprachdateien müssen auch nicht mehr manuell von einem Spiegelserver heruntergeladen werden, sondern können mit

aptitude install iceweasel-l10n-de

eingerichtet werden.
Die selbe Prozedur sollte in wenigen Tagen auch für Testing funktionieren, wenn die Pakete automatisch in diesen Debian-Zweig einfließen.

Debian Stable

Für Debian Stable gibt es einen Backport. Der Eintrag in der /etc/apt/sources.list lautet:

deb http://backports.debian.org/debian-backports squeeze-backports main
deb http://mozilla.debian.net/ squeeze-backports iceweasel-release

Installation

aptitude install -t squeeze-backports iceweasel

Wer an der Beta- oder Aurora-Version von Iceweasel interessiert ist muss nur das Wort release in der sources.list durch beta oder aurora ersetzen.

Schlüssel importieren für mozilla.debian.net

Wie bei Debian üblich werden alle Pakete mit gpg vom Paketverwalter signiert. Der Schlüssel zur Verifikation für mozilla.debian.net lässt sich mit Root-Rechten im Terminal durch zwei Befehle so importieren.
wget -O- -q http://mozilla.debian.net/archive.asc | gpg --import
gpg --export -a 06C4AE2A | apt-key add -

Ansonsten gilt das Geschriebene in meinem alten Post zu Iceweasel 5.0.
Ich hoffe in Zukunft bleibt das Installationsschema nun so erhalten. Damit lässt sich leben. Als offensichtlichste Neuerung ist mir im neuen Iceweasel nur der hervorgehobene Domainname in der Adresszeile aufgefallen, was es schon (wie so vieles) bei Opera mal zuerst gab.
Sollte die Geschwindigkeit bei den Veröffentlichungen beibehalten werden, hat Firefox/Iceweasel die Chance Chromium mit der Versionsnummer Ende nächsten Jahres zu überholen. Ob es sinnvoller ist nur für große Änderungen ganze Versionsnummern zu nehmen oder nicht, sei an dieser Stelle mal dahingestellt.

Posted on

Ein Lob für Midori

An dieser Stelle muss ich einfach mal ein Lob für Midori loswerden. Seit mehr als einem Jahr benutze ich die grüne Pfote nun auf dem Inspiron 4000 und mit der aktuellen Version 0.4 in Debian Unstable hat es Midori geschafft erneut die Balance zwischen Funktionalität und Effizienz wiederzufinden, die mich mal zu diesem schlanken Webkit-Browser gebracht hat.
Ich bin mir nicht sicher, ob es die neue Upstream-Version oder der Wechsel der Bibliothek von libwebkit zu libwebkitgtk in Debian war (die Gründe dafür stehen leider nicht im Changelog), auf jeden Fall ist die Startzeit deutlich verbessert worden und zumindest ein Bug, der mich noch vor Monaten darin hinderte einige Webseiten mit sehr viel JavaScript zu betrachten ist mit der aktuellen Version vollständig beseitigt worden.
Was mir an Midori besonders gut gefällt, sind die schon integrierte AdBlock-Funktion, Mausgesten und ein Feature, was ich bisher nur von elinks und dem Vimperator-Addon des Firefox Browsers kannte.
Drückt man . erscheinen Zahlen neben allen Links einer Webseite. Man muss dann nur noch die Nummer eingeben und Return drücken und schon öffnet sich der Link im Browser. Ich bin zwar auch gerne ein Mausklicker, aber wenn man viel im Internet unterwegs ist, bemerkt man einfach die Geschwindigkeitsvorteile dieser Methode.
Also von mir darf es mit Midori gerne so weitergehen. Gute Arbeit! 🙂

Posted on

Finde den besten WebKit-Browser oder programmiere ihn einfach in 20 Minuten selbst

Ich glaube Linux bietet bei kaum etwas anderem mehr Auswahl und Vielfalt als bei Webbrowsern. Spätestens seit Google das Chromium-Projekt gestartet hat, ist auch dem Letzten die zentrale Bedeutung, das wahre Herzstück, des modernen Desktops ins Bewusstsein gerückt worden. Jeder namhafte Hersteller von Betriebssystemen und Global Superplayer strebt heutzutage die Vorherrschaft im Kampf um den Webbrowser der Zukunft an ...oder lässt nach einem Jahrzehnt zumindest alte Schrecklichkeiten endlich sterben. Vom Browserkrieg war gar schon oft die Rede.
Dabei sollte gerade in Bezug auf Webbrowser weniger das Kriegerische als das Verbindende hervorgehoben werden. Nehmen wir doch als Beispiel mal das WebKit-Projekt. Alles begann einmal als Weiterentwicklung eines anderen Open-Source-Projektes namens KHTML, was noch heute die Grundlage für Konqueror bildet, der wohl bekanntesten Applikation des KDE Desktops. Irgendwann hat dann Apple die Technologie verbessert und als WebKit-Engine zur Grundlage des eigenen Safari-Browsers gemacht. Andere bekannte Größen wie Nokia oder Google sprangen auf den gleichen Zug auf und so entwickelte letzteres Unternehmen schließlich den Chromium-Browser, der sich schnell als dritte Größe zwischen dem Internet Explorer und Firefox etablieren konnte.

Da behaupte noch einer es ginge immer nur gegeneinander. WebKit ist ein Paradebeispiel, warum Open Source und Freie Software so wichtig und auch so erfolgreich sein kann. Irgendwo beginnt eine Idee zu wachsen, ein anderer greift den Gedanken auf und verwirklicht ihn schließlich. Dank des offenen und frei verfügbaren Quellcodes gesellen sich immer weitere Akteure dazu und machen die Idee besser. Man hat ausdrücklich die Möglichkeit voneinander zu lernen und Wissen wird nicht wie in einer mittelalterlichen Gilde im Geheimen verborgen gehalten. Nur so gelingen Innovationen und Fortschritt schneller.

Wähle deinen Browser

Im letzten Post scherzte ich noch, dass rekonq der gefühlt 23. Webkit Browser sei. Ich lag damit gar nicht so falsch! Webkit.org listet auf der eigenen Webseite zumindest 22 auf Webkit basierende Browser auf, wobei rekonq in der Auflistung sogar fehlt. Doch bevor ich damit begann meine übersinnlichen Fähigkeiten zu preisen, fiel mir auf, dass zumindest sowohl xxxterm als auch uzbl in der Liste fehlten und wer weiß wie viele andere noch.
Die Auswahl bei WebKit-Browsern ist also verblüffend groß. Da ich gerne Browser auf älterer Hardware ausprobiere, befinden sich auf meinem Inspiron 4000 neben Iceweasel 5, Chromium 12, Opera 11.5 auch Midori und surf.
Die letzten beiden sind, wie sollte es auch anders sein, ebenfalls WebKit-Browser. Genauer gesagt basieren sie auf WebKit/GTK. Zwar ist der universelle Browser immer noch elinks für mich, aber es mag Zeiten geben, wo ich mir eine Webseite auch mal hübsch gerendert und mit etwas Javascript anschaue. Dabei leistet surf, entwickelt übrigens von suckless, das uns den großartigen Fenstermanager dwm bescherte , auf einer alten Kiste Erstaunliches.


Das ist surf. Nein, hier ist nichts versteckt oder irgendwelche Funktionen deaktiviert worden. Surf stellt nur die Webseite dar und kann auch Links folgen. Keine Werkzeugleisten, Lesezeichen und Addons. Surf konzentriert sich nur auf das Wesentliche - Browsen. Die Darstellung von Webseiten ist dank WebKit hervorragend. Bedienen lässt sich dieser minimalistische Traum mit ein paar Tastenkombinationen. Die in urxvt geöffnete man-Seite zeigt wie es geht. Um zu einer Seite zu gelangen, einfach STRG+g drücken und Adresse eingeben oder surf direkt von der Kommandozeile mit

surf www.meinetolleinternetseite.de

starten. Surf kann keine Tabs, zumindest solange man nicht tabbed installiert hat oder schon die Vorzüge von kachelnden Fenstermanagern wie z.B. dwm oder Awesome kennt. Ich persönlich kann surf einiges abgewinnen.

Oder programmiere ihn selbst

Ich habe mich lange Zeit gefragt, welchen Grund es gibt, dass WebKit-Browser so verbreitet sind. Eine Open-Source-Engine wie WebKit ist eine Sache, aber einen Browser zu programmieren, das stellte ich mir als fortgeschrittene und vor allem zeitintensive Aufgabe vor. Doch dann fand ich dieses geniale 20 minütige Videotutorial zur Programmierung eines WebKit-Browsers mit Python und GTK in Englisch. Danach war mir schlagartig klar, warum es so viele WebKit-Browser gibt. Es macht einfach unheimlich viel Spass einen solchen zu programmieren. Das Tutorial ist aber auch erste Sahne und sehr empfehlenswert. 🙂
Wer sich die Mühe nicht selbst machen will ein paar Zeilen abzutippen, kann auch gleich hinüber zu K.Mandla navigieren und sein 1,5 KB großes Pythonskript kopieren und dann damit anfangen im Netz zu surfen.
Was bleibt als Fazit? WebKit-Browser machen Spass und der IE 6 ist endlich Geschichte. Es darf gefeiert werden.

Posted on

Iceweasel 5.0 freigegeben

Die Mozilla Foundation legt offenbar einen Zahn zu und hat sich von dem längeren Entwicklungszyklus zwischen zwei Firefox Versionen verabschiedet.
In Zukunft erscheinen kleinere Updates nun regelmäßiger, enthalten dafür aber weniger umwälzende Änderungen.

Debians umbenannte und von problematischen Markenrechten befreite Firefox Version namens Iceweasel, befindet sich ebenfalls auf dem aktuellen Stand und wird von den Paketverwaltern auf http://mozilla.debian.net gepflegt.
Update 17.08.2011: Für Iceweasel 6 und hoffentlich auch alle kommenden Versionen, habe ich die Installation hier noch einmal übersichtlicher zusammengefasst. Ansonsten gilt das hier Geschriebene.
Die Installation gestaltet sich ähnlich einfach wie bei einem Ubuntu PPA.
Update 07.07.11: Vielen Dank an Simon, der in den Kommentaren auf das neue Versionsschema von Iceweasel in der sources.list hingewiesen hat. Im Blog des Debian Paketverwalters für Iceweasel wurde heute angekündigt, dass Iceweasel als Release Version (5.0), Beta (6.0) und Aurora (7.0) in Zukunft zum Download bereitsteht.
Für den 15. Juli kündigte er auch an, dass Iceweasel 5 direkt für Debian Unstable ohne den Umweg über den mozilla.debian.net Spiegel oder Experimental verfügbar sein wird. Wann allerdings der Browser in dieser Version für Testing zur Verfügung stehen wird bleibt vorerst ungewiss, da zuvor erst alle Paketkonflikte aufgelöst sein müssen. Für alle, die wie ich gerne mit der aktuellen Iceweasel Version browsen, geht es wie folgt am einfachsten.

mozilla.debian.net in sources.list freischalten

Für Debian Unstable und Testing lautet der Eintrag in der /etc/apt/sources.list

Für Iceweasel Release:
Ist nun in Unstable bzw. Testing
Für Iceweasel Beta
deb http://ftp.de.debian.org/debian experimental main
Für Iceweasel Aurora
deb http://mozilla.debian.net/ experimental iceweasel-aurora
Schlüssel importieren für mozilla.debian.net (gilt für alle Debian Versionen)
Wie bei Debian üblich werden alle Pakete mit gpg vom Paketverwalter signiert. Der Schlüssel zur Verifikation lässt sich mit root Rechten so importieren.

wget -O- -q http://mozilla.debian.net/archive.asc | gpg --import
gpg --export -a 06C4AE2A | apt-key add -

Die APT Quellen updaten
aptitude update
Iceweasel für Debian Unstable und Testing installieren
aptitude install -t experimental iceweasel

Debian Stable alias Squeeze

Es ändert sich nur der Eintrag in der sources.list und der Installationsbefehl.
Release (5.0):
deb http://backports.debian.org/debian-backports squeeze-backports main
deb http://mozilla.debian.net/ squeeze-backports iceweasel-release
Beta (6.0):
deb http://backports.debian.org/debian-backports squeeze-backports main
deb http://mozilla.debian.net/ squeeze-backports iceweasel-beta
Aurora (7.0):
deb http://backports.debian.org/debian-backports squeeze-backports main
deb http://mozilla.debian.net/ squeeze-backports iceweasel-aurora
Installation
aptitude install -t squeeze-backports iceweasel
Wer auch zukünftig schnell in den Genuss der neusten Firefox/Iceweasel Version kommen möchte, sollte mozilla.debian.net in der sources.list eingetragen haben.
Iceweasel 5.0 reagiert besser und rendert Seiten fühlbar schneller als das derzeitige Iceweasel 3.5.19 in unstable.
Der Nachteil: Außer Englisch stehen momentan keine weiteren Sprachpakete zur Auswahl und das Addon "Torbutton" funktioniert mit Firefox/Iceweasel 5 leider auch nicht mehr.
Update 24.06.2011
Im Blog des Debian Paketverwalters für Iceweasel und Icedove konnte ich heute den Tipp lesen, wie man ganz leicht deutsche Sprachunterstützung erhält. Wie ein Kommentator schon treffend bemerkte wird dadurch aus Iceweasel in Teilen wieder Firefox. Nehmt es mit einem Lächeln. Deutsch ist für den Paketverwalter nicht die einzige Sprache, die er als Paket zur Verfügung stellen muss. 😉
1. Es muss lediglich die Sprachdatei von Firefox installiert werden. Für Deutsch ist das de.xpi.
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/
In Iceweasel genügt ein Klick auf die Datei de.xpi und die Sprachdatei wird installiert. Auf einem System mit voreingestellter deutscher Spracheinstellung sind keine weiteren Schritte nötig.
Ansonsten noch folgendes erledigen:
2. about:config in die Adresszeile von Iceweasel eingeben
3. Suche nach general.useragent.locale und ändere es von en-US zu de-DE
Update 04.07.2011
Torbutton ist seit dem 30.06. aktualisiert worden und kann beim Torprojekt heruntergeladen werden.