Firefox 3 – bikubisch schlechte Performance

Vor kurzem noch habe ich mich darüber geärgert, dass die Mozilla-Entwickler der Linux-Variante des Firefox 3.0 keine bikubische Bildinterpolation bei der Skalierung der Seiten verpasst hatten. Dies erschien mir doch als gravierender Nachteil gegenüber der Windows-Variante. Nun nach weiteren Erfahrungen – insbesondere von Kunden – sehe ich das etwas differenzierter.

Warum ?

1) Die Mozilla-Entwickler haben lt. einer Forums-Diskussion unter MS Windows auf Interpolations-Methoden (Routinen) der Microsoft GUI zurückgegriffen. Das ist insofern bedenkenswert, als hier zeitintensiver externer Code mit internen Darstellungsroutinen des Browsers verkoppelt werden muss.

2) Der Preis der unheiligen Allianz mit der Windows-GUI entpuppt sich als extrem hoch:

Man erhält nach dem Zoomen der Webseiten zwar schöne glatte Bilder – aber die Performance beim Scrollen von Bildern und IFRAMES in einer vergrößerten Zoomstufe des Browsers ist im FF 3.0 unter aller Sau und erheblich schlechter als im FF 2.X oder im MS IE 7. Die Scroll-Performance ist bereits auch ohne vergrößernden Zoom schlechter als im FF 2.0 – aber so richtig übel wird es nach dem Vergrößern (Zoomen) der Seiten: horizontales und vertikales Scrollen von Iframes mit größeren Bildern führt zu abenteuerlichen Schlingerbewegungen des Bildes, das offenbar in mehrere Bereiche unterteilt wird, die unterschiedlich schnell transportiert werden.

Hier wird deutlich erkennbar, dass die Bilder zerlegt (gekachelt) werden und dass die (vermutlich laufend) stattfindende Interpolation der Kacheln zu erheblichen Zeitverlusten während des Scrollings führt. Der MS IE 7 hat dieses Problem offenbar viel besser gelöst. Hier muss man sich wirklich fragen, wie die Mozilla-Entwickler die Loops für das Darstellen des Scrolling der IFRAMES und der enthaltenen Bilder (bzw. deren Kacheln) mit der externen Interpolationsroutine von MS verknüpft haben. Die Verlangsamung des Scrollens ist in mir bekannten Fällen gegenüber dem FF 2.0 jedenfalls nachweislich haarsträubend.

Dass es sich um ein reines Problem des FF 3.0 unter MS Windows handelt, zeigt sich denn auch an der Linux-Variante des FF 3.0: Hier funktioniert das Scrollen auch großer Bilder in IFRAMES in hohen Zoomstufen glatt und verzerrungs- bzw. ruckelfrei. Und um Mißverständnissen vorzubeugen: das liegt nicht an Parameter-Einstellungen zum “sanften Bildlauf” !

Fazit:
Wer sich mit den Teufel einlässt, muss wissen, was er tut, oder er bezahlt einen hohen Preis. Ich habe bereits den ersten Kunden, der unter Windows wieder von FF 3.0 auf MS IE umgestiegen ist.

Mir ist im Übrigen völlig unverständlich, warum die Mozilla-Entwickler nicht ein eigenes bikubisches Interpolationsverfahren in den Browser integrieren und sich diesbzgl. von der MS GUI unabhängig machen. Wie man solche Routinen aufsetzen muss, kann man an der GLIB-Komponente von PHP lernen. Es ist eine alte Erfahrung, dass man selbst entwickelten Code letztlich viel besser in performance-relevante Abläufe einbinden oder an solche Abläufe anpassen kann als externen Code.

Aber was reg ich mich auf?

Unter Linux geht das Scrollen ja immer noch performant ! Und das ist mir – ehrlich gesagt – fast lieber als glatte Bilder …

Remote Druckerverwaltung

Einführung

Durch die diversen Distributionen – in meinem Fall durch Opensuse – ist man bzgl. der Drucker-Einrichtung ziemlich verwöhnt und greift gerne zu graphischen Verwaltungstools. Hat man aber einen laufenden CUPS-Druckerserver erst einmal aufgesetzt, so ist die Druckerverwaltung vom Arbeitsplatz-PC (!) aus über ein Terminal oftmals zeitsparender. Allerdings muss man dann einige nützliche Befehle aus dem CUPS-Umfeld parat haben. Wir stellen auf dieser Seite einige Kommandos aus der täglichen Praxis zusammen.

Aktivieren einer stehenden Druckerqueue auf einem CUPS-Server von einem Remote PC aus

Findet der CUPS-Server einen z.B. über USB angeschlossenen Drucker nicht beim Start, so wird dieser Drucker als “disabled” betrachtet, obwohl die Standard-) Queue für den Drucker noch Jobs entgegennimmt. Auch das Anschalten des Druckers hilft dann – je nach Systemkonfiguration – manchmal nicht. Das USB-Subsystem erkennt den Drucker zwar – CUPS bekommt davon aber ggf. nichts mit. Sitzt man nun an einem Remote-PC, so möchte man gerne die Druckerqueue wieder mit einem geeigneten Kommando aktivieren. Hier helfen für Remote-CUPS-Server die Kommandos

/usr/bin/lpstat
/usr/sbin/cupsenable
/usr/sbin/acccept
/usr/sbin/reject
/usr/sbin/lpadmin

“/usr/sbin/lpstat” liefert Informationen zum Drucker- bzw. Queuestatus (Acceptstatus, Aktivitätsstatus). “/usr/sbin/cupsenable” aktiviert einen Drucker – die Jobs in der Queue werden wieder abgearbeitet. “accept” sorgt dafür, dass die zugehörige Queue wieder Jobs entgegennimmt. Mit “lpadmin” kann man in unserem speziellen Fall beide Kommandos in einem Befehl kombinieren.

Im nachfolgenden Beispiel gehen wir nun auf die Option “-h” ein, die das Arbeiten von der Arbeitsplatzstation auf dem entfernten Server ermöglicht – wenn der Server das gem. Firewall- und cupsd-Konfiguration erlaubt.

Ein Beispiel-Szenario:’

Nehmen wir an, der Server hieße “oxi” und die stehende Queue “oxprinter”. Ferner sei man als Druckeradministrator unter dem Usernamen “pad” auf dem Server mit den entsprechenden Rechten zur Queue-Verwaltung ausgestattet. Der User “pad” sei auch auf dem lokalen PC mit der gleichen UID eingerichtet (oder besser über LDAP zentral verwaltet). Zudem muss der 631 Port auf dem Server für den User “pad” vom Arbeitsplatzrechner aus zugänglich sein. Dies hat man in der Regel schon bei der Einrichtung des CUPS-Servers berücksichtigt. (Die nötigen Einstellungen nimmt man in der Datei /etc/cups/cupsd.conf vor.)

Dann hilft am Remote-Arbeitsplatzrechner folgende Kommandosequenz :

$> su pad
(Passworteingabe)
$> /usr/sbin/lpadmin -h oxi -p oxprinter -E

Man wird dann vom Server mit einer Passwortabfrage konfrontiert, die man entsprechend beantwortet. Danach läuft die Queue (hoffentlich) wieder an.

Die Option “-E” steht dabei übrigens für die Kombination aus “accept” und “enable”;
die Option “-h” steht dabei für “host”;
“-p” erwartet die Angabe der zu aktivierenden Druckerqueue.

Alternativ geht auch folgende Sequenz, wobei wir hier erst eine Abfrage des Acceptstatus der Queues und des Aktivitätstatus eingebaut haben:

$> lpstat -h oxi -a
(Anzeige Acceptstatus aller Printqueues.)
$> lpstat -h oxi -p
(Anzeige Aktivitätsstatus aller Printqueues.)
$> su pad
(Passworteingabe)
$> /usr/
sbin/accept -h oxi oxprinter
(Passworteingabe)
$> /usr/sbin/cupsenable -h oxi oxprinter
(Passworteingabe)

Deaktivieren von Printern bzw. deren Queues:

Das Gegenstück zu “/usr/sbin/cupsenable” ist übrigens “usr/sbin/cupsdisable”. Das Gegenteil von “/usr/sbin/accept” bewirkt das Kommando “/usr/sbin/reject”.

Relevante Dateien:

Lokal: /usr/sbin/lpadmin, /usr/bin/lpstat, /usr/sbin/cupsenable, /usr/sbin/cupsdisable, /usr/sbin/accept, /usr/sbin/reject,
CUPS-Server: /etc/cups/cupsd.conf (zentrale Konfigurationsdatei für den Druckerserver)

Hinweis:
Interessanterweise wird das Kommando “lpadmin” im sonst sehr guten LPI-Buch “LPI LINUX CERTIFICATION IN A NUTSHELL” nicht angesprochen.

Knoppix: Keine Internetverbindung mit DSL?

Hatte heute wieder ein kleines Knoppix/Debian-Erlebnis mit meinem Freund Michael:

Er wollte unter Knoppix /Debian sein DSL-Modem testen. Trotz scheinbar erfolgreicher DSL-Konfiguration konnte er aber (scheinbar) keine Verbindungen ins Internet aufbauen. (Zum schon bekannten eventuelle auftretenden Debian-Problem mit der resolv.conf s. den früheren Eintrag zu diesem Thema.) Die Lösung war am Schluss ganz einfach – man muss nur die Vollständigkeit der Netzwerkkonfiguration im Auge behalten. Aber der Reihe nach:

Das Knoppix-System wie das Debian-System benötigen zur DSL-Konfiguration das Programm “pppoeconf”. Hier bearbeitet man brav die gestellten Fragen zum Useraccount und Passwort ab. Diese Daten werden übrigens in die Datei

/etc/ppp/pap-secrets

und

/etc/ppp/peers/dsl-provider

eingetragen. Für den Fall des manuellen Editierens der Dateien: Die Userkennung beim Provider muss in beiden Dateien identisch sein. Weitere Informationen zur grundlegenden Konfiguration liefert die Datei “/usr/share/doc/pppoe/README.Debian.gz” (Zur direkten Ansicht kann man das Kommando “zless” verwenden).

Die nächste Frage, die sich stellt, ist die des Verbindungs-Auf- und Abbaus. Zum Aufbau der Verbindung verwendet man (im einfachsten Fall) den Befehl “pon”:

pon dsl-provider

Der Abbau wird durch das Kommando “poff” erledigt. (Natürlich kann man hier nach entsprechender Konfiguration auch mit anderen Programmen wie “kinternet” arbeiten.)

Ist die Konfiguration erfolgreich verlaufen, so erhält man als Ergebnis von “/sbin/ifconfig” einen Eintrag zu der Schnittstelle “ppp0”. Dieser sollte nach dem Verbindungsaufbau dann auch bereits automatisch eine IP-Adresse zugeordnet worden sein.

Soweit war Michael auch schon gelangt. Dennoch konnte er im Internet keine einzige Webseite aufrufen. Das Problem konnte nach der erfolgreichen Zuordnung einer externen IP-Adresse durch den Provider nur noch an zwei Stellen vorhanden sein – auf der Ebene der IP-Konfiguration oder der Ebene der DNS-Server. Als erstes probierten wir deshalb mehrere “ping”-Abfragen auf bekannte Server (194.25.2.129 – Telekom DNS-Server). Es schlugen bereits die Pings auf vorgegebene IP-Adressen fehl. Also musste das Problem ein Elementares ein. Nach einem Nachdenken bleibt da nur noch eine fehlende oder falsche Konfiguration der Routen übrig. Also haben wir den Befehl

“route” oder “route -v”

abgesetzt. Hier tauchte dann prompt auch kein Eintrag für die Default-Route auf. (Mögl. Grund: ein vorkonfigurierte eth0-Schnittstelle. Jedenfalls mochte Knoppix hier nix selbständig konfigurieren.) Das Routing musste Michael also von Hand erledigen:

route del default
route add default ppp0

Der erste Befehl dient zur Sicherheit zum Löschen der bisherigen Route – falls doch ein (falscher) Default-Routen-Eintrag vorhanden gewesen sein sollte. Der letzte Befehl legt die Route auf ein Device – und nicht auf eine IP-Adresse! Das ist für ein (DSL-) Modem natürlich sinnvoll:

Die IP-Adresse wird ja beim Verbindungsaufbau zugeteilt und kann sich bei jedem Neuaufbau der Verbindung nach außen ändern! ( Arbeitet man dagegen nicht mit einem direkt angeschlossen DSL-Modem sondern mit einem zwischengeschalteten (Firewall-) Router, so ist natürlich dessen statische IP-Adresse für die Default-Route von Interesse.)

Nach dem Setzen der Routen funktionierten bereits die pings auf vorgegebene IP-Adressen im Internet ! Natürlich gilt hier: die obige Routenkonfiguration ist der einfachste Fall für einen Standalone-Rechner mit Internet-Anbindung über ein DSL-Modem. Ansonsten muss man das Routing natürlich auf seine speziellen Netzwerkbedürfnisse hin konfigurieren.

(Die Beschreibung von Routing-Konfigurationen führen an dieser Stelle zu weit. Wie man seine Netzwerk-
und Routing-Daten in den Debian Startup-Skripten permanent hinterlegt, lese man bitte unter den letzten zwei der unten angegebenen Links und dortigen weiterführenden Adressen nach. Bzgl. des Zwischenspeicherns der Konfigurationsdaten zu einem Knoppix-Live-System auf einem USB-Stick hilft der Artikel “http://www.easylinux.de/Artikel/ausgabe/2004/08/024-knoppix/” weiter.)

Abschließend lohnt sich nun noch ein Blick in die Datei “/etc/resolv.conf”. Hier muss man prüfen, ob die DNS-Server des Service-Providers korrekt eingetragen sind.

Achtung:
Einige Service-Provider sind inzwischen dazu übergegangen, nur noch ihre eigenen DNS-Server für Abfragen auf dem Port 53 zuzulassen. Also testweise auch mal den vom Provider vorgegebenen Nameserver eintragen, wenn die Namensauflösung trotz gelungener Internet-Anbindung nicht funktionieren sollte.

Michael kann nun endlich sein DSL-Modem ausgiebig unter Knoppix testen. Er sollte aber auch nicht vergessen, seine Firewall zu starten!

http://www.easylinux.de/Artikel/ausgabe/2004/08/024-knoppix
http://channel.debian.de/faq/ch-confignet.html
http://www.linux-user.de/ausgabe/2001/08/018-rp-pppoe/rp-pppoe.html
http://wiki.debian.org/NetworkConfiguration
http://www.tldp.org/HOWTO/NET3-4-HOWTO.html
http://www.debian.org/doc/manuals/reference/ch-gateway.de.html