Neben den Soundproblemen, die ich auf meinem Rechner habe, wenn ich den nvidia Treiber benutze, gibt es jetzt noch einen weiteren Grund zum Open Source ‘nv’ Treiber zurückzukehren: im proprietären Nvidia Treiber ist ein Sicherheitsleck entdeckt worden und noch gibt’s von Nvidia keinen Fix.
Ich habe anscheinend endlich den Grund für die Soundprobleme gefunden, die ich immer unter X11 (sowohl XFree86, als auch X.org) hatte: der proprietäre Nvidia-Treiber. Nachdem ich jetzt mal testweise auf den integrierten Treiber von X.org (‘nv’) umgestellt habe, sind die Probleme verschwunden.
Vorher traten sie immer dann auf, wenn man in Opera z.B. zwischen Tabs hin- und herschaltete oder auch beim Scrollen auf einer Webseite. Auch Versuche, das mit dem Ändern der PCI Latenz in den Griff zu kriegen (wie z.B. hier und hier beschrieben) sind leider gescheitert.
Naja, da ich auf 3D Unterstützung im Treiber nun nicht wirklich angewiesen bin, wird’s auch der ‘nv’ tun — wenn ich dafür ungefrustet Musik hören kann, ist’s mir das wert…
Und weil’s so schön ist, noch ein Debian Linux Artikel…
Wenn man das Opera Repository (siehe Post von vorhin) in die sources.list einfügt, beschwert sich APT, dass der entsprechende Key nicht vorhanden und die Quelle daher nicht vertrauenswürdig ist.
Man holt also zunächst den fehlenden Key von einem Keyserver:
# gpg --keyserver gpg-keyserver.de --recv-keys <keyid>
# gpg --armor --export <keyid> > key.asc
Und fügt den dann als root ins APT Schlüsselbund ein:
# apt-key add key.asc
Danach sollte apt-get update dann ohne Warnung durchlaufen.
(ausführlichere Beschreibung: Martins Blog)
Nach langer Zeit mal wieder ein Linux-Posting. 
Mit der folgenden Zeile in /etc/apt/sources.list kann man Opera in Debian per apt aktuell halten:
deb http://deb.opera.com/opera etch non-free
‘etch’ kann in diesem Fall auch durch andere Releases ersetzt werden.
Gefunden im Process of Elimination Wiki.
Google hat Picasa für Linux auf Google Labs veröffentlicht. Basiert auf WINE und es gibt sogar ein Debian Paket. Muss ich im Laufe des Wochenendes mal ausprobieren.
Ich hatte im Oktober schonmal geschrieben, dass nach dem Upgrade eines Debian Woody Rechners auf die damalige Sarge Release täglich zwei Fehlermeldungen von Exim per Mail reinkamen. Damals hatte ich vermutet oder gehofft, dass dieses Verhalten in der Final Release von Sarge, die seit Montag verfügbar ist, nicht mehr auftritt.
Leider ist dem nicht so, wie ich gestern nach dem Upgrade unseres Webservers feststellen musste. Exim beklagte sich heute Nacht auch hier über die falschen/fehlenden Dateien (‘failed to open db file /var/spool/exim/db/retry: file exists’), so dass meine Problemlösung vom Oktober immer noch gültig ist.
Ich habe auf dem Rechner allerdings auch nur Exim 3 aktualisiert und (noch) nicht das empfohlene Upgrade auf Exim 4 vollzogen.
Mit nur einer Woche Verspätung gegenüber dem Anfang Mai angekündigten Veröffentlichungsdatum (31.5.) ist gestern die Version 3.1, Codename Sarge, von Debian GNU/Linux freigegeben worden.
Herzlichen Glückwunsch und vielen, vielen Dank an das Debian Projekt für die neue Version und die immense Arbeit, die darin steckt!
Unglaublich, aber wahr. Die Veröffentlichung von Debian Sarge hat eine wichtige Hürde genommen. Seit gestern befinden sich alle Archivteile von Sarge im “Feature Freeze”, d.h. für die Pakete werden nur noch kritische oder wichtige Bugfixes, sowie Übersetzungs- und Dokumentationupdates akzeptiert.
Der aktuelle Plan sieht ferner vor, Sarge am 30.5. zu veröffentlichen — ob es dazu kommt sei mal dahingestellt, aber selbst wenn’s jetzt noch einen Monat länger dauert, der Meilenstein ist jetzt endlich greifbar!
Eigentlich bin ich hier zu Hause nur noch sporadisch unter Windows XP “tätig”. Meine gesamten Daten lagern auf einer Linux-Partition — auch um anfangs den Druck zu erhöhen, doch gefälligst Linux zu benutzen. Trotzdem kommt ab und zu der Wunsch auf, auch mal auf diese Daten von Windows aus zugreifen zu können, was leider nicht so ohne weiteres möglich ist war. In der aktuellen c’t fand ich aber den Link zum Ext2 Installable File System. Damit kann man unter Windows NT/2000/XP auf die Linux ext2 bzw. ext3 Filesysteme zugreifen und zwar sowohl lesend als auch schreibend. Die Installation ist sehr einfach: Setup aufrufen, durch ein paar kurze Fragen klicken, Laufwerkbuchstaben zuweisen, fertig.
Einschränkung des Treibers ist jedoch, dass die Benutzerrechte der Dateien ignoriert werden, d.h. jeder hat Zugriff auf Dateien an die man unter Linux nicht herankäme, also ggf. auch auf sensible Daten wie /etc/shadow bzw. /etc/passwd. Das sollte man beim Einsatz des Treibers bedenken. Für den Privatgebrauch auf einem Rechner, den sowieso nur wenige Personen benutzen, sollte das aber keine große Hürde sein.
In diesem Beitrag hatte ich das Thema schonmal behandelt: je nachdem, ob der Monitor beim Starten von KDE (bzw. KDM) eingeschaltet war oder nicht, waren die Fontgrössen in KDE mal gross und mal kleiner. Das liegt daran, dass der X-Server vom eingeschalteten Monitor die Auflösung abfragt und in die Darstellung der Schriften mit einbezieht. Ist der Monitor aus, geht das natürlich nicht und es werden Vorgabewerte verwendet.
Eigentlich hatte ich das Problem ja schon im Griff, doch dann kam das neue KDE 3.4.0 bzw. genauer: ein neuer KDM. Letzterer ist unter KDE u.a. für das Starten des X-Servers verantwortlich. Früher konnte man durch einen Eingriff in /etc/kde3/kdm/Xservers dem X-Server eine feste Auflösung vorschreiben. Mit KDM 3.4.0 ist diese Einstellung jetzt in die Datei /etc/kde3/kdm/kdmrc verfrachtet worden und heisst dort ServerArgsLocal. Bei diesem Eintrag muss man zu den ggf. vorhandenen Optionen noch -dpi 85 (oder eben die Zahl, die der Auflösung des Monitors entspricht) einfügen, um den gewünschten Effekt zu erzielen.
