Lokaler Apache/PHP-Testserver

Posted on by

Ich entwickle oft “PHP 5”-Programme – auch unterwegs. Auf einem Laptop musste ich vor kurzem einen lokalen Apache-Server einrichten, um auch ohne Netzwerkanbindung Programme testen zu können. Der Server sollte natürlich PHP5 unterstützen und für eine bestimmte Testdomaine – “devdomain” – SSL-fähig sein. Hierzu muss man auf die Schnelle virtuelle Domainen einrichten. Das Ganze unter Opensuse 11.3.

Vielleicht ist die nachfolgende Vorgehensweise zur Lösung dieser Aufgabenstellung auch für andere interessant.

/etc/host-Einträge

Der Rechner soll später autonom – d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Für einen lokalen, autonomen Testserver kann für die notwendigen Einträge in der Datei “/etc/hosts” das Loopback-Interface verwenden. Die Einträge können dann etwa so aussehen:

127.0.0.1         localhost.localdomain         localhost

127.0.0.2         mylap.myprivatedomain.de         mylap

127.0.0.2         devdomain

Der erste Eintrag ist ein Standard Opensuse-Entrag, wie er bei einer automatischen Installation erzeugt wird. Den zweiten benötige ich für andere Programme. Interessant für unsere Problemstellung ist die dritte Zeile. Die dortige IP-Adresse ist u.a. wichtig für das spätere Aufsetzen der IP-basierten virtuellen Domaine “devdomain”.

Es gibt im Internet immer wieder Diskussionen um die Verwendung der Loopback-Adresse – ich denke, die oft angeführten Gegen-Argumente kann man im Zusammenhang mit dem beschriebenen Szenario getrost ignorieren. Ein System mit aktiven Netzwerkschnittstellen benötigt natürlich noch mehr Einträge an passender Stelle in der “/etc/hosts” und ggf. eine Adress-Systematisierung über einen DNS-Server. Aber die Funktionalität eines autonomen Entwicklungs- und Test-Systems ist mit den Loopback-Adressen wirklich in hinreichender Weise gegeben.

Für die korrekte lokale Namensauflösung sollte “files” die Reihenfolge der Ressourcen im “hosts”-Eintrag der Datei “/etc/nsswitch.conf” anführen:

hosts:       files mdns4_minimal [NOTFOUND=return] dns

Grundinstallation Apache

Apache2 kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Folgende Pakete aus dem Opensuse 11.3 Standard-Repository habe ich installiert:

  • apache2 (!)
  • apache2-devel (!)
  • apache2-doc
  • apache2-example-pages (!)
  • apache2-mod_dnssd
  • apache2-mod_perl
  • apache2-mod_php5 (!)
  • apache2-mod_python
  • apache2-prefork (!)
  • apache2-utils (!)
  • libapr-util1 (!)
  • libapr-util1-devel (!)
  • libapr1 (!)
  • libapr1-devel (!)

Nach der Installation und einem “rcapache2 start” sollte ein

http://localhost

im Browser bereits eine Seite mit dem schönen Text “It works!” anzeigen. Danach trägt man mit Yast den Apache2-Server in die Run-Level-Konfiguration ein, damit er automatisch z.B. in den Levels 3 und 5 gestartet wird.

Grundinstallation PHP5

Für eine relativ umfassende PHP5-Unterstützung sind für mich in der Regel folgende Pakete/Module von
Bedeutung:

apache2-mod_php5, php-doc, php5, php5-bcmath, php5-bz2, php5-ctype, php5-devel, php5-dom, php5-gd, php5-hash, php5-iconv, php5-imagick, php5-json, php5-mbstring, php5-mcrypt, php5-mysql, php5-pdo, php5-pear, php5-phar, php5-sqlite, php5-tidy, php5-tokenizer, php5-xdebug, php5-xmlreader, php5-xmlwriter, php5-zip, php5-zlib

Die Zusammenstellung kann für umfangreiche Entwicklungsszenarien natürlich komplexer aussehen.

Hinweis zur Aktualisierung der PHP-Installation:
Um eine aktuelle PHP5-Installation unter Opensuse 11.2 zu erhalten (PHP 5.3.3) muss man ggf. die passenden Repositories unter

http://download.opensuse.org/repositories/server:/php/
http://download.opensuse.org/repositories/server:/php:/extensions/

in die Paketverwaltung einbinden. Über das zweite der genannten Repositories erhält man z.B. das Xdebug-RPM.

Modifikation an der php.ini

Auf einem Entwicklungssystem will man man Fehlermeldunge zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags “” statt lauffähig sein sollen. Um beim Einsatz der Funktion “date()” Warnungen zu vermeiden, stellt man auch die Standardzeitzone für das PHP-Modul ein. Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Entsprechende Einträge (plus ein paar mehr) :

  • short_open_tag = On
  • error_reporting = E_ALL & ~E_DEPRECATED
  • display_errors = On
  • log_errors = On
  • ignore_repeated_errors = Off
  • ignore_repeated_source = Off
  • register_globals = Off (immer gut)
  • include_path = “.:/usr/share/php5:/usr/share/php5/PEAR” (PEAR soll funktionieren)
  • date.timezone = Europe/Berlin

“Spiel-Zertifikat und SSL-Aktivierung unter Opensuse 11.3

Viele meiner PHP-Frameworks für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist dann zudem eine zweite separate virtuelle Domaine einzurichten.

SSL geht nicht ohne ein Minimal-Zertifikat. Für lokale Testzwecke reicht ein “Spiel-Zertifikat”. (Im Browser fügt man dann bei Warnungen eine Ausnahmeregel für das Zertifikat ein.)

Unter Opensuse 11.3 erreicht man die notwendige Grundausstattung des Apache-Servers unter Benutzung von Apache-Tools durch folgende Kommandos:

  • a2enmod ssl
  • a2enflag SSL
  • /usr/bin/gensslcert (als root absetzen)
  • cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf
  • Anpassung der vhost-Dateien (s.u.)

Ein paralleler Blick in die “sysconfig”-Dateien des SUSE-Systems ist hier nicht verkehrt. Dafür kann man z.B. den sysconfig-Editor von Yast heranziehen. Im dortigen kategoriebaum bewegt man sich in den Zweig

“Netzwerke   >>>   WWW   >>>   Apache2”.

Unter dem Eintrag “APACHE_MODULES” sollte man folgendes finden:

authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap ssl php5 authz_default

Unter dem Eintrag APACHE_SERVER_FLAGS sollte SSL
auftauchen:

SSL

Hinweise:

  • Ein Extra-RPM für das SSL-Modul muss unter Opensuse 11.3 nicht installiert werden.
  • gensslcert erzeugt nur eine Spiel-Cert. Dabei werden folgende Dateien überschrieben:
  • /etc/apache2/ssl.crt/ca.crt
  • /etc/apache2/ssl.key/server.key
  • /etc/apache2/ssl.crt/server.crt
  • /etc/apache2/ssl.csr/server.csr
  • Der Virtual-Host für die SSL-Domaine muss IP-basiert (!) angelegt werden – also nicht namensbasiert. “*”-Angaben für die IP-Adressen werden mit Fehlermeldungen quittiert. In unserem Beispiel werden für das autonome Testsystem die Loopback-Adressen herangezogen.
  • Man darf nicht vergessen, dass man für einen Standardzugang “http://localhost” eine eigene virtuelle Domaine einrichten muss, da es bei virtuellen Domainen ohne Vorkehrungen keinen Standard-Host (Default-Web-Server) mehr gibt.

Konfigurationsdateien

Nachfolgend gebe ich (etwas verkürzt) an, welche Grundeinträge in zwei Konfigurationsdateien unter dem Verzeichnis

/etc/apache2/vhosts.d

notwendig sind, um das Ziel zu erreichen,

  • einen Standardhost ohne SSL-Verschlüsselung unter “http://localhost”
  • eine Testdomaine “devdomain” für Entwicklungszwecke über “https://devdomain”

ansprechen zu können:

Inhalt der Datei “ip-based_vhosts.conf” für den Standardserver

<VirtualHost *>

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>

Hinweise:

  • Der Name der Datei kann beliebig gewählt werden !
  • Es wird hier kein “server-name angegeben” !!!! – Default-Server
  • Das Root-Verzeichnis für den Standardhost ist hier “/srv/www/htdocs”. Dort sind die Web-Dateien und PHP-Programme anzulegen.

Inhalt der Datei “vhost-ssl.conf” für den IP-basierten, SSL-Server für die Domaine “devdomain”

<IfDefine SSL>

<IfDefine !NOSSL>

<VirtualHost 127.0.0.2:443>

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk/”

ServerName
devdomain:443

ErrorLog /var/log/apache2/error_log

TransferLog /var/log/apache2/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>

SSLOptions +StdEnvVars

</Files>

<Directory “/srv/www/cgi-bin”>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent “.*MSIE.*” \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

</IfDefine>

Hinweise:

  • Der Host muss eine IP-Adresse erhalten – hier die lokale Loopback-Adresse.
  • Der Servername (vergl. mit /etc/hosts) wird in einer speziellen, separaten Zeile eingetragen.
  • Die IP-Adresse muss mit dem angegebenen Namen des Servers auch in der Datei “/etc/hosts” eigetragen sein !
  • Das DocumentRoot-Verzeichnis habe ich deshalb mit dem “trunk”-Zweig ausgestattet, um die Verzeichnisstruktur eines an Eclipse angebundenes SVN-Repositories zu berücksichtigen. Das kann man natürlich auch anders machen.

Nach dem Anlegen der Dateien kann man nun die neue Konfiguration nach einem “rcapache2 restart” testen. Dazu legt man im Verzeichnis

/srv/www/htdocs/Entwicklung/devdomain/trunk/

eine kleine Testdatei an oder kopiert die “index.html” aus dem Pfad “/srv/www/htdocs” dorthin. Firefox sollte beim Aufruf der Adresse “https://devdomain” keine SSL-bezogene Fehlermeldung anzeigen, sondern nur wegen des nicht vertrauenswürdigen Zertifikats warnen. Der Warnung begegnet man mit einer dauerhaften Ausnahme-Regel. Danach sollte die Test-Datei angezeigt werden. Taucht wieder Erwarten eine Meldung “ssl_error_rx_record_too_long” auf, so ist etwas an der Apache-Konfiguration faul und man muss nacharbeiten.

Das ist natürlich nur eine Ruck-Zuck-Installation eines lokalen Testservers für den Hausgebrauch auf einem PC oder Laptop. (Ein ordentlich aufgesetzter Apache2 sieht anders aus). Aber mit der obigen Konfiguration lassen sich schon bestens PHP-Programme testen.

Viel Spaß also beim PHP-Entwickeln unterwegs – und natürlich unter Linux !

Ergänzung 02.10.2012:

Eine knappe Grundinstallationsanleitung zu Apache2, MySQL, PHP (LAMP) unter Opensuse 12.1 findet man übrigens unter:
http://www.
liveconfig.com/de/kb/9.html

Links

http://de.opensuse.org/Apache/SSL-Anleitung
http://de.opensuse.org/Apache
http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren
http://wiki.ubuntuusers.de/Apache/SSL
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf12.htm
http://de.opensuse.org/Apache/Schnellstartanleitung

Vererbung von ext3-/ext4-Gruppenrechten

Posted on by

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht – und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige – wenn auch rekursive – Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems – “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” – siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung
n
Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse

Kontact, Kmail, Adressbuch – Nachtrag

Posted on by

Am 19.03. habe ich mich ein wenig genervt über die Adressbuch-Philosophie der KDE-Kontact-Entwickler ausgelassen (Link zum Blog-Artikel).

Damals konnte ich die Adressen des “Default Adressbook” (Akonadi-Ressource), aber auch die Einträge eines unter Akonadi angelegten konventionellen Open-Xchange-Adressbuches (OX-Ressource) nicht unter Kmail nutzen. So funktionierte z.B. die automatische Adress-Vervollständigung während der Erstellung einer Mail nicht mehr. Die Lösung bestand darin, unabhängig von der Ressource “Default-Adressbuch” unter Kontact/Kontakte eine weitere Ressource in Form eines “herkömmlichen” Adressbuches anzulegen. Diese wurde – wenn ich mich recht erinnere – damals als Akonadi-Ressource, aber auch als KDE-Ressource bekannt gemacht.

Gestern setzte sich der Ärger bei der Neuanlage eines Users mit KDE 4.4 erneut fort: Das Anlegen einer “herkömmlichen” Adressbuches unter Kontact/Kontakte reicht definitiv nicht, um die Adressen eines externen Open-Xchange bei der Neuanlage von Mails unter Kontact/Kmail verwenden zu können. Vielmehr ist es notwenig, die externe Adressbuch-Ressource zusätzlich und manuell als KDE-Ressource über die KDE “Systemeinstellungen” anzulegen.

Wie ein normaler Anwender das bei der Einrichtung von Kontact/Kmail erkennen soll, ist mir ein Rätsel ….. aber ich wundere mich langsam über gar nichts mehr ….. und habe den alten Artikel entsprechend abgeändert.

OO 3.2.1.2 und KDE

Posted on by

Ich hatte ja versprochen, auch mal wieder was Positives zu schreiben ….

Kaum lässt man Frust ab (siehe den Beitrag von gestern zu Openoffice – “Ärgerliche Probleme der Openoffice Integration in KDE 4), passiert auch schon was. Spät am gestrigen Abend habe ich mir testweise die neueste verfügbare Openoffice-Version von Opensuses OO-“Unstable”-Repository installiert.

OpenOffice.org 3.2.1
OOO320m18 (Build:9502)
ooo-build 3.2.1.2

Nach ersten Tests so aus, als ob die gestern oben beschriebenen Probleme 1 und 2 behoben sind. Die KDE-Dialoge für Öffnen/Speichern kommen schnell und sind sofort bedienbar. Und die Statuszeile ist nun wieder permanent sichtbar und verschwindet nicht mehr bei Fensteränderungen oder Manipulationen am Text.

Nicht behoben ist allerdings der Punkt 3 : Die Checkboxen für die Toolbars werden beim Öffnen des Submenü-Dialogs immer noch mit falschen Flags angezeigt.

Aber: es tut sich was – was Positives ! Ich freue mich …..

Amarok 2 – Abstürze beim Abspielen von CDs

Posted on by

Nun hatte ich nach dem letzten Blog-Eintrag eigentlich wieder was Positives aus dem Linux-Alltag berichten wollen. Aber der Amarok-Absturz, den ich im letzten Blog-Artikel erwähnt hatte, ist zu “schön”, um das hier nicht anzubringen.

Bekanntermaßen halte ich von Amarok 2 im Gegensatz zur alten 1.4 Version nicht viel. Dennoch habe ich mich schon ein wenig gefreut, als der Equalizer vor einiger Zeit wieder auftauchte und manche Leute der MP3-Generation gemerkt haben, dass man doch hin und wieder mal gerne auch eine CD unter Amarok abspielen möchte. Ja, ich fand das eigentlich richtig gut, als ab einer der letzten Versionen Amarok 2 doch tatsächlich CDs erkannte und abspielen wollte. Ich habe sogar extra einen Freund angerufen, als ich das entdeckte …

Die Freude hielt halt mal wieder nicht lange. Denn leider stürzt Amarok 2.3.0 beim Abspielen von CDs oft und unmotiviert ab, während Amarok 1.4.10 bei denselben CDs keinerlei Zicken macht.

Ein solcher Absturz geschah gerade während des Schreibens des letzten Bog-Beitrags. Lustig waren dann aber auch die Absturz-Meldungen. Zunächst erschien das übliche KDE-Absturzfenster. Das allein ist sehenswert.

amarok_bug_1

Der schöne Hinweis auf Deutsch zur Nutzlosigkeit der Felermeldungen wird hier gepaart mit einer norwegischen Erläuterung dafür, was man tun muss, um bessere Fehlermeldungen zu erzeugen.

Nun frage ich mich natürlich, warum Teile des Textes in Norwegisch erscheinen. Es wird doch wohl hoffentlich nichts damit zu tun haben, dass ich mehrere Sprachen in den “System-Settings” eingerichtet habe, um automatische Fehlersuchen auch in norwegischen Texten durchführen zu können (s. den vorletzten Blog-Eintrag)? Ich mag gar nicht darüber nachdenken. Außerdem verstehe ich ja Norwegisch. Also versuche ich, durch Druck auf den Button “Debug-Symbole installieren” den Amarok-Entwicklern zu mehr Informationen zu verhelfen. Dann kam folgende Meldung:

amamrok Bug 3

Jetzt natürlich auf Englisch. Und irgendwie habe ich aufgrund der Meldung den berechtigten Eindruck, ich müsse nun selber herausfinden, was ich an Debug-Software für Amarok 2 aus welchem Repository dieser Welt installieren muss. Das demotiviert – und meine Zeit ist begrenzt. Und CD-Abspielen ist ja unter Amarok 1.4 auch unter KDE 4 einwandfrei möglich. Also gebe ich auf und blogge lieber ….

Dennoch: Wenn es noch etwas benötigt hätte, um das zu unterstreichen, was ich im letzten Blog-Eintrag zum generellen Status des KDE4-Anwenders als Beta-Tester gesagt habe, dann war es dieser Amarok-Absturz.

Ich habe Amarok 2 dann übrigens doch nochmal gestartet – denn ein Absturz beim CD-Abspielen läßt sich ja über kurz oder lang reproduzieren. Das Lustige war, dass der Absturz schon am Ende vom ersten ausgewählten Song auf der CD kam. Normalerweise dauert das länger. Aber diesmal kam dann auch die KDE-Absturzmeldung nur kurz – ca. 1,5 Sekunden – und verschwand dann wie von Zauberhand von selbst. Offenbar will die KDE-Welt wirklich keine Fehlermeldungen mehr von mir haben … Auch recht …

Ach, ich liebe Amarok 1.4! Zur Beruhigung meiner Nerven höre ich nun dieselbe CD, bei der Amarok 2 zusammenbricht, seit ca. 70 Minuten ohne jeden Fehler oder Absturz mit der 1.4er-Version an. Was nutzt einem die schöne neue Welt unter KDE4, wenn die zugehörigen Applikationen zwar bunt sind, aber die Funktionalität, die schon mal zur vollen Zufriedenheit da war, entweder nicht mehr vorhanden ist oder schlicht und einfach nicht funktioniert?

Und was nutzen Absturzbotschaften, mit denen ein normaler User nicht mehr umgehen kann, ohne viel Zeit zu investieren? KDE – quo vadis ?