11.12.2008 von rmo.

Dieser Treiber ist aus meiner Sicht (trotz Beta-Status) für KDE4-Neugierige (und nicht-produktive Linux-Umgebungen) empfehlenswert.
Es verschwinden nämlich wie von Zauberhand eine Reihe von KDE 4 - Problemen, u.a.:

• Artefakte auf den Taskbars beim Einsatz von GTK-Applikationen
• Fehler bei der Darstellung von transparenten Objekten auf Webseiten in Konqueror

Geschwindigkeitseinbußen oder Instabilitäten habe ich unter KDE 4.2 Beta mit Compiz auf einem Opensuse 11.0-System (x86_64) bislang nicht feststellen können.

Geschrieben in Hardware, Treiber, KDE, Erfahrungsberichte | Keine Kommentare »

1.12.2008 von rmo.

Beim Web-Entwickeln stößt man ab und zu auf das Problem, dass man zum Testen auf seinem Apache2-Webserver schnell mal zwei separate Domainen benötigt, um typische Situation bei Web-Providern nachzustellen:

Auf den gehosteten Servern findet man regelmäßig Verhältnisse vor, bei denen einem in einer abgekapselten “chroot”-Umgebung zwei oder mehr Verzeichnisse bereitgestellt werden, denen dann unterschiedliche Domainen zugeordnet sid oder zugeordnet werden können. Und als Entwickler möchte man gerne domainenübergreifende PHP-Klassenbibliotheken in Verzeichnissen außerhalb der eigentlichen Domainen installieren und testen, ob die Klassen auch ordentlich in allen Domainen gezogen werden …. oder man hat mit ähnlichen domainübergreifenden Problemstellungen zu tun …..(Dass man Bibliotheken in domainunabhängigen, übergeordneten Verzeichnissen des Webservers installiert, hat seinen Grund übrigens nicht nur in der Vermeidung von Doppelpflege, sondern es dient u.U. auch der Sicherheit.)

Möchte man ähnliche Situationen auf einem eigenen Apache-Server nachstellen, greift man am besten - wie der Webprovider auch - zu namensbasierten virtuellen Domainen.
Das folgende einfache Beispiel zeigt, wie man zwei solcher zusätzlicher Domainen auf einem Opensuse-System einrichten kann und wie man dafür sorgt, dass der ursprüngliche Zugriff auf den Server erhalten bleibt. Wir gehen von folgendem Szenario aus: Es laufe ein Webserver unter der beispielhaften Adresse “server.mydomain.de”. Ihm sei die IP-Adresse “192.168.0.10″ zugeordnet. Die DNS-Einstellungen im Netzwerk seien so, dass man den Webserver unter “http://server.mydomain.de” oder “http.//server” erreicht. Der Web-Server selbst sei im Moment so eingerichtet, dass in der Haupt-Konfigurations-Datei

/etc/apache2/http.conf

über eine inkludierte Datei die erforderlichen Port- und SSL-Einstellungen des Webservers vorgegeben werden. Das entsprechende Include-Statement in der httpd.conf findet sich meist an deren Anfang

Include /etc/apache2/listen.conf

Später werde auch die Default-Konfiguration des Servers über eine weitere Konfigurationsdatei (globale Einstellungen für den Defaultserver) in die “httpd.conf” geladen. Dies geschieht z.B. über den Eintrag

Include /etc/apache2/default-server.conf

Ein nachfolgender Eintrag in der httpd.conf sorge dafür, dass Definitionen für virtuelle Domainen aus dem Verzeichnis “/etc/apache2/vhosts.d” geladen werden, sobald wir (s.u.) solche Definitionen angelegt haben:

Include /etc/apache2/vhosts.d/*.conf

Auf andere Einträge in der Datei “httpd.conf” gehen wir im Moment nicht ein, da sie hier nicht von direkter Bedeutung sind.
Folgende Einträge in der “default-server.conf” sorgen vor der Umstellung auf virtuelle Domainen für den reibungslosen Betrieb.

DocumentRoot “/srv/www/htdocs”
<Directory “/srv/www/htdocs”>
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>

Alias /icons/ “/usr/share/apache2/icons/”

<Directory “/usr/share/apache2/icons”>
     Options Indexes MultiViews
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>
ScriptAlias /cgi-bin/ “/srv/www/cgi-bin/”
<Directory “/srv/www/cgi-bin”>
     AllowOverride None
     Options +ExecCGI -Includes
     Order allow,deny
     Allow from all
</Directory>
<IfModule mod_userdir.c>
     UserDir public_html
     Include /etc/apache2/mod_userdir.conf
</IfModule>
Include /etc/apache2/conf.d/*.conf
Include /etc/apache2/conf.d/apache2-manual?conf

Diese Einstellungen können später pro virtueller Domaine überschrieben werden. Das Apache2-Konzept ist hier sehr modular.

Einrichtung der virtuellen Domainen
Nun richten wir uns 3 virtuelle Domainen ein. Zwei davon werden zwei speziellen Verzeichnissen zugeordnet; die dritte ersetzt den bisherigen “Default-Server”. Die dritte virtuelle Default-Domaine ist deshalb wichtig und notwendig,

• weil bei einem “namebased virtual server” zunächst keine Default-Domaine existiert und der Standard-Default-Server keine Wirkung mehr hat und
• weil man die bisherigen User des Servers nicht dazu zwingen will, ihre Lesezeichen in Ihren Browsern grundlegend zu ändern.

Diese dritte Domaine darf in einer professionell genutzten Umgebung bei der Umstellung nicht vergessen werden.

Für die Umstellung ist zunächst ein Eintrag in der Datei “/etc/apache2/listen.conf” essentiell:

NameVirtualHost 192.168.0.10:80

Nachdem wir das erledigt haben, erstellen wir im Verzeichnis “/etc/apache2/vhosts.d” eine Datei “virtu.conf” für eine virtuelle Domaine “virtu.mydomain.de” mit folgendem Inhalt :

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtu.mydomain.de
     ServerAlias virtu
     DocumentRoot /srv/www/vitualdomains/virtu
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtu”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Beachten Sie den Eintrag zum “DirectoryIndex” und “ServerAlias”. Letzterer macht die neue Domaine auch über eine Abkürzung (http://virtu) anstelle des voll qualifizierten Domainnamens ansprechbar. Der “DirectoryIndex” spezifiziert, welche Dateien aufgerufen werden sollen, wenn als Http-Adresse nur die Domaine (also das Verzeichnis) angesprochen wird. Diese Vorgabe gilt aber auch für Subverzeichnisse. Einträge aus der Datei “default-server.conf” bleiben weiterhin gültig, soweit sie nicht überschrieben wurden. Eine weitere Domaine kann etwas so aussehen:

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtual.mydomain.de
     ServerAlias virtual
     DocumentRoot /srv/www/vitualdomains/virtual
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtual”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Abschließend möchten wir noch den Server mit einer Default-Domaine ausstatten, die für alle sonstigen Zwecke aufgerufen wird, und die der ursprünglichen Serverkonfiguration entspricht:

<VirtualHost 192.168.0.10:80>
     DocumentRoot /srv/www/htdocs
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/htdocs”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Man erkennt, dass hier der “ServerName”-Eintrag fehlt !
Bleibt nur noch, auf unserem DNS-Server (oder auf dem Client-Rechner in der “/etc/hosts”-Datei) dafür zu sorgen, dass “virtu.mydomain.de” und “virtual.mydomain.de” im Netzwerk auch unter der Adresse “192.168.0.10″ gefunden werden. Danach können wir den Webserver neu starten und erreichen in einem Browser über “http://virtu.mydomain.de” bzw. “http://virtual.mydomain.de” die neuen Domainen. Rufen wir nur “server.mydomain.de” oder “http://192.168.0.10″ auf, so erhalten wir diejenigen Seiten, die auch auf dem urssprünglichen Server schon angezeigt wurden.
Viel Spaß mit den neuen Domainen!
Wenn es funktioniert, dann ist es an der Zeit, sich mit weiteren Varianten und Möglichkeiten von virtuellen Domainen auf einem Apache-Server auseinanderzusetzen. Das obige Beispiel war nur eine sehr einfache Lösung zu fester IP-Adresse und einheitlichem Port.

Geschrieben in Netzwerk, LAMP / Webentwicklung, Erfahrungsberichte | Keine Kommentare »

26.11.2008 von rmo.

Nach einem früheren Beitrag zu KDE 4 möchte ich nun nach ca. 1 Monat produktiver Arbeit unter dieser Oberfläche eine Reihe von Einschränkungen bzgl. des Einsatzes in einem produktiven Umfeld machen. Ich schicke voraus, dass ich KDE 4.1.3 unter Opensuse 11.0 verwende. Das System wird bzgl. KDE 4 auf sehr aktuellem Stand gehalten. Als Graphikkarte kommt einen Nvidia-Karte zum Einsatz. Ich möchte auch betonen, dass ich vorher mit KDE 3.5.10 sehr zufrieden war.

Problembereich Konqueror
Konqueror unter KDE 4 erscheint mir in vielerlei Hinsicht unausgereift. Die nervigsten Punkte, die ein produktives Arbeiten verhindern, sind:

• Regelmäßige Abstürze bei Multimedia-lastigen Seiten (u.a. mit Flash-Elementen, man gehe nur mal auf die Nvidia-Seiten oder die Seiten der Telekom oder von Vodafone und probiere dort alle Optionen aus),
• Falsche Behandlung und Darstellung von Seiten mit halb-opaquen Designelementen (wie halbtransparenten Menüpunkten); die Darstellung ist z.T. katastrophal bei dynamischen halbtransparenten Objekten. Man sollte solche Elemente lieber noch eine Weile völlig intransparent darstellen als den experimentellen Murks anzubieten, der im Moment vorhanden ist.
• Fehler oder Unsauberkeiten in der Javascript-Engine - im Besonderen bei Querbeziehungen zwischen mehreren geöffneten Fenstern einer Applikation (so kann man PhpMyAdmin z.B. wegen dieser Probleme nicht in vollem Umfang benutzen - wahnsinnig nervig)
• Eine falsche und z.T. chaotische Behandlung von “textarea”-Elementen auf Formularseiten im Zusammenhang mit Mausinteraktionen (falsche Cursordarstellung bei scrollbaren Feldern über dem Scrollbar, falsches Einsprungverhalten bei Maus-Klick auf den Text - vermutlich wg. Fehlberechnung der Scrollposition, etc.) Das macht den Einsatz im Zusammenhang mit formularlastigen Datenbankapplikationen zur Nervensache ….)
• Falsche Breitenberechnung von Input-Elementen bei der Inhaltsdarstellung - zuminest bei verwendung des Oxygen-Designs für die KDE-Oberfläche - auch dies wieder nervig bei formularlastigen Web-Applikationen

All diese Schwierigkeiten tauchen in anderen Browsern (Firefox, Opera) nicht oder nicht in dem Ausmaß auf wie in KDE4’s Konqueror.

Problembereich CPU-Belastung
Generell erscheint mir die CPU-Belastung im Schnitt deutlich höher zu sein als unter KDE 3.5.10.
Ich muss aber dazu sagen, dass ich Compiz im Einsatz habe und hier spielen evtl. auch die Nvidia-Treiber eine Rolle. Auffällig ist z.B., dass aktive, geöffnete Amarok-Fenster zu einem Anstieg der CPU-Belastung von über 10% führen im Gegensatz zu einer Situation, in der das Amarok-Fenster minimiert ist. Die laufenden Bildschirmupdates kosten unter KDE4 scheinbar erhebliche CPU-Zeit.
Dieses Problem gab es früher auch schon mal unter KDE 3.5, war dann aber eine ganze Weile beseitigt.
Aber auch Applikationen wie das neue Ksysguard sind wahre Ressourcenfresser - reale Messungen der CPU-Belastung sind damit fast nicht mehr möglich, weil Ksysguard oft selbst mehr Ressourcen als andere Applikationen schluckt.

Problembereich GTK-basierte Applikationen (Openoffice, VMware Wokstation, etc. )
Es ist wirklich nervig, dass das Arbeiten in und mit GTK-Applikationen zu störenden Nebeneffekten auf der KDE4-Oberfläche führt - u.a. Überdeckung der KDE4 Kontroll-Leiste durch Artefakte. Diese verschwinden wieder, wenn man die Maus in den gestörten Bildschirmbereich bewegt - ärgerlich ist das aber trotzdem. Zumal durch die Artefakte auch Bereiche überdeckt werden, die Informationen beinhalten.
Ob auch dies mit Nvidia-Treibern zusammenhängt konnte ich nicht prüfen; es hängt aber sicher nicht mit Compiz zusammen, sondern ist ein reines Problem zwischen der KDE-Oberfläche und GTK-Applikationen. Das haben auch andere bestätigt.

Probleme mit Notizbüchern unter Kontact
Leider muss ich sagen, dass das Arbeiten mit Notizbüchern unter Kontact ein Glücksspiel ist. Mir sind bereits mehrfach Einträge verlorengegangen. Es fehlt eindeutig eine Option zum Zwischenspeichern eines erarbeiteten Eintrags. Notizbücher sind ein schönes Feature, aber leider noch viel zu unsicher für den produktiven Einsatz.

Als Anwender kann man nur hoffen, dass die Konqueror-Probleme und das generelle Problem mit GTK-Applikationen unter KDE 4 umgehend gelöst werden.

Geschrieben in KDE, Erfahrungsberichte | 1 Kommentar »