Nvidia driver 173.14.05 – Positives – Negatives

Posted on by

Ich habe vor kurzem den Nvidia Treiber 173.14.05 über ein rpm aus dem SuSE Repository installiert. Meine Erfahrungen sind durchaus gemischt:

Positiv: Compiz Fusion läuft gefühlsmäßig besser und spritziger, wenn die dortige “Sync to Vblank” Option aktiviert ist. Hier ist das Zusammenspiel zwischen Nvidia-Treiber und Compiz irgendwie harmonischer geworden.

Negativ: Andererseits sieht man dramatische FPS-Einbrüche für glxgears (von über 14000 Fps runter auf unter 2000 Fps). Im Nvidia Forum meinte ein User, das sei mit der Version 173.14.09 wieder besser. Wir werden sehen.

Negativ: Eine ärgerliche Kleinigkeit: Ohne Zusatzmaßnahmen zeigt die Applikation “nvidia-settings” jetzt beim Aufruf des Menüpunktes “X Server Display Configuration” folgende Fehlermeldung:

******
Unable to load X Server Display Configuration page:

Failed to parse the following modeline of display device
0x00010000 ‘Samsung SyncMaster’ connected to GPU-0 ‘GeForce 7800 GTX’:

source=edid :: “nvidia-auto-select” 154.000 1920 1968 2000 2080 1200 1203 1209 1235 +HSync -VSync

******

Man kann das beheben, indem man “nvidia-settings” jetzt mit folgendem Zusatz startet:

LANG=C nvidia-settings

FPDF und PHP – erste Erfahrungen

Posted on by

Ich habe vor kurzem die Aufgabe erhalten, mit PHP PDF-Dokumente zu generieren, die auf den Einträgen in einer Datenbank basieren. Möglichst kostengünstig. Der Griff zur PFDlib war wegen der relativ hohen Kosten für kommerzielle Zwecke also nicht möglich. Zudem behagte mir die PDFlib auch nicht, da sie als Modul im Webserver (Apache) integriert werden muss. Das wäre bei dem Web-Service-Provider, der die Domaine meines Kunden hostet, dann eher ein Problem geworden.

In meiner Not habe ich dann zur Opensource Bibliothek “FPDF” (http://www.fpdf.de/) gegriffen. Die dortigen (objektorientierten) Bibliotheken benötigen nur PHP und werden nicht als Apache-Module geladen. Ich muss nach ein paar Tagen produktiver Arbeit feststellen, dass ich mit der Bibliothek sehr positive Erfahrungen gemacht habe:

1) Die Installation ist sehr einfach.
2) Die Doku ist knapp bemessen, aber verständlich und letztlich ausreichend. Ein Blick in die Online-Tutorials mit den dortigen Beispielen ist sehr hilfreich.
3) Die Einbindung und Erweiterung der zu nutzenden Bibliotheks-Objekte in eigene PHP-Objekte und Methoden ist auf bequeme Art und Weise möglich.
4) Die Methodenaufrufe zur Gestaltung des PDF-Dokumentes sind zwar begrenzt, dafür aber sehr einfach zu verstehen und anzuwenden.
5) Footer und Header-Methoden sind einfach für die eigenen Zwecke zu überschreiben.
6) Tabellarische Inhalte lassen sich sehr bequem erstellen.
7) Die Geschwindigkeit bei der PDF-Erzeugung ist zumindest für einfache Zwecke ausreichend.
8) Es wird nicht zuviel versprochen – die angebotenen Methoden funktionieren.

Etwas umständlich ist die Einbindung von Truetype-Schriften und die zugehörige Erzeugung der metrischen Informationsdateien. Hier dem User etwas kompaktere Tools anzubieten, wäre nicht schlecht.

Aber alles in allem: eine empfehlenswerte Bibliothek für Leute, die PDF-Dokumente mit PHP erzeugen wollen und nicht zur PDFlib greifen können.

Thunderbird und verschlüsselte Mail-Anhänge

Posted on by

Als Linux-Anwender verwende ich neben Kmail manchmal Thunderbird unter Linux. Dort wird zur Verschlüsselung die Linux-OpenPGP Software herangezogen. Unter Windows hingegen kommt das Enigmail Plugin mit der OpenPGP Software im Hintergrund zum Zuge. Hier gibt es ein kleines Problemchen, dass auch für Linux Anwender als Verfasser verschlüsselter Mails interessant ist, wenn der Empfänger Windows Anwender ist.

Ein Bekannter, der Thunderbird unter MS Windows einsetzt, hatte nun das Problem, dass er Anhänge von Mails, die ich ihm verschlüsselt geschickt hatte, nicht öffnen konnte. Vielmehr erhielt er die Fehlermeldung “IMAP-Nachricht ist zu groß zum Entschlüsseln”. Man möge es mir glauben: Die Mail und der Anhang waren winzig. Unter Linux hatte ich dieses Problem nicht. Der Kollege greift tatsächlich, wie die Fehlermeldung es andeutet, auf einen IMAP-Server zu.

Als Ursache entpuppte sich eine Einstellung des Enigmail Plugins unter Windows. Klickt man in Thunderbird unter MS-Windows den Menüpunkt “OpenPGP” an, und geht man dann weiter zu “Einstellungen” und zum Reiter “Erweitert”, so findet man eine Checkbox für den Punkt

“Anhänge nur herunterladen, wenn diese geöffnet werden sollen (nur bei IMAP)”.

Dieser Punkt muss deaktiviert werden, wenn die Anhänge verschlüsselter Mails in Thunderbird geöffnet werden sollen. Ich meine, die Fehlermeldung ist wirklich irreführend. Als Versender verschlüsselter Mails sollte man daher seine Windows-Adressaten auf diesen Punkt hinweisen.

Firefox 3.0 ohne verbesserte Bildskalierung unter Linux

Posted on by

Gerade habe ich Firefox 3.0 unter Windows und unter Linux installiert. Neben vielen positiven Dingen muss ein für Linux Anwender sehr enttäuschender Punkt angesprochen werden:

Im jetzigen Release 3.0 funktioniert das “smooth image scaling”, das im Vorfeld so viel Furore machte, unter Linux überhaupt nicht, während es unter Windows wirklich beeindruckende Ergebnisse zeitigt.

Inzwischen wurde bereits ein Mozilla-Bug zu dieser Thematik eröffnet. In einem Kommentar zur Bugmeldung wird allen Ernstes empfohlen, sich bei den Linux-Distributoren zu beschweren, da im X-Server benötigte Features fehlen würden. Dazu ist aus Anwender-Sicht Folgendes zu fragen bzw. anzumerken:

1) Fehlt nun etwas in Xorgs X-Server oder implementieren die Packages der Distributoren X nur eingeschränkt?
2) Man versteht als unbedarfter Mensch nicht, was X überhaupt mit der Thematik zu tun haben soll. Müsste dieses Thema nicht eine Ebene höher angegangen werden? Firefox ist doch unter Linux wohl GTK basiert und liefert GTK nicht etliche Funktionen, um eine ordentliche bikubische Interpolation von Images durchzuführen?

Egal wie: Als Linux User bin ich erstmal enttäuscht. Das wird jeder verstehen, wenn er folgende zwei Bilder vergleicht – das erste wurde im FF 3.0 unter Linux gemacht, das zweite im FF 3.0 unter Windows (das natürlich im VMware-Fenster läuft) – bei gleicher Vergrößerungsstufe :

anracon_logo_FF_linux anracon_Logo_windows

Die Enttäuschung ist umso größer, als hier eine Opensource-Firma die Anwender des Opensource-Betriebssystems Linux offenbar als Anwender zweiter Klasse behandelt. Denn dass eine gute Bildskalierung unter Linux ein prinzipielles und ernsthaftes Problem darstellen soll, glaube ich nicht. Das Gegenteil ist durch GIMP, Scribus und diverse PDF-Programme bereits bewiesen. Vielleicht lassen sich aber die Windows-spezifischen Algorithmen nicht 1 zu 1 auf X, KDE und Gnome übertragen. Man müsste wohl eigene Lösungen entwickeln. Die Veröffentlichung des jetzigen Releases zeigt aber wohl, dass die Mozilla-Entwickler dies bislang versäumt haben. Ein schnelles Windows-Release ist inzwischen wohl wichtiger als gute Qualität auf verschiedenen Betriebssystemen ……

KGpg – Schlüsselimport mit Fehlern

Posted on by

Man müht sich ab, seinen Kunden beizubringen, wichtige Informationen im Internet verschlüsselt zu übertragen. Eine Voraussetzung dafür, dass der Kunde sich mit den entsprechenden Verfahren anfreundet, ist, dass das Erzeugen eines Schlüsselpaares und das Verteilen des öffentlichen Schlüssels ohne größere Schwierigkeiten durchgeführt werden kann – unter Linux wie unter Windows. Leider können hier auch unter Linux Schwierigkeiten auftreten, die den Anfänger überfordern.

Vor kurzem konnte ich die Probe aufs Exempel machen – ein Kunde, der Thunderbird unter Windows einsetzt, lud sich das Enigmail-Plugin und GnuPG für Windows herunter. Die Installation verlief problemlos. Ebenso nach einer kurzen Einweisung die Suche nach meinem “public key” und der Import des Schlüssels von einem PGP-Server in den Schlüsselring. Der Kunde konnte mir dann auch ohne Schwierigkeiten verschlüsselte Mails schicken. So weit so gut.

Die Überraschung kam nach dem Generieren des eigenen Schlüssels. Die Erzeugung des Schlüsselpaares verlief wie erwartet. Der Kunde sah den Schlüssel, dessen Kennung (die letzten 8 Ziffern des Fingerprints) und bei einer Detailansicht auch den gesamten Fingerprint. Der Kunde versuchte dann seinen öffentlichen Schlüssel auf einen PGP-Server hochzuladen. Auch dies war ohne Problem möglich. Dann suchte der Kunde zur Probe nach seinem Schlüssel – zunächst mittels eines Statements der folgenden Art:

http://pgpkeys.pca.dfn.de/pks/lookup?op=vindex&hash=on&fingerprint=on&search=0x{16 Hex-Ziffern}

wobei “{16 Hex Ziffern }” durch die letzten 16 Hexadezimal – Ziffern des Schlüssel-Fingerprints zu ersetzen ist. Der Schlüssel wurde einwandfrei identifiziert und angezeigt. Dann probierte der findige Kunde jedoch folgendes Statement, bei der er dem “search”-Parameter nur die letzten 8 Stellen der Schlüssel-Kennung übergab (nur diese werden nämlich typischerweise in den Key-Verwaltungsprogrammen angezeigt):

http://pgpkeys.pca.dfn.de/pks/lookup?search=0x{8 Hex Ziffern = Schlüsselkennung}&fingerprint=on&hash=on&op=vindex

Wie es der (unwahrscheinliche) Zufall so will, kamen als Antwort 2 Schlüssel mit derselben 8-stelligen Kennung hoch – der des Kunden und einer, der im Jahre 1998 angelegt wurde. Diese “Konkurrenz” bzgl. der 8 stelligen Schlüsselkennung fand der Kunde sehr beunruhigend. Ich demonstrierte ihm dann, dass sein Schlüssel dennoch von dem des “Konkurrenten” verschieden war und dass die Schlüsselkennung und der Fingerprint ja eigentlich mehr als 8 Hex-Stellen umfassen. So zeigt z.B. KGpg unter KDE in der Detailansicht eines Schlüssels nicht 8 sondern die hinteren 16 Hex-Stellen des Fingerabdrucks an.

Der wirkliche Ärger begann aber, als ich versuchte, den öffentlichen Schlüssel des Kunden unter Linux/KDE in meinen eigenen Schlüsselring zu importieren. Das misslang unter KDE KGpg bei Einsatz des Standardimports von einem PGP-Server auf wirklich schlimme Weise:

Obwohl ich die eindeutige 16 stellige Kennung im Such/Import-Dialog angab, importierte KGpg beide Schlüssel – den des Kunden und des Konkurrenten. Noch schlimmer: In der Detailansicht wurde bei beiden Namen ein und derselbe Fingerprint (der des Kunden), aber die falsche Kennung (die des Konkurrenten) angezeigt. KGpg hatte also die beiden Schlüssel beim Import intern nicht sauber getrennt.

So etwas ist katastrophal! KGpg ist offenbar nicht in der Lage den Standard-Import von Schlüsseln zu regeln, wenn die letzten 8 Hex-Stellen der Kennung mit denen eines anderen Schlüssels identisch sind. Das Gleich geschah übrigens auch, wenn man nach der dem Schlüssel zugeordneten Namen bzw. der Web-Adresse suchte.

Testweise versuchte ich dann den Import unter Windows mit Thunderbird und den dahinter liegenden OpenPG-Programmen. Auch hier werden zwar zwei Schlüssel importiert – offensichtlich reagieren die Programme nur auf die letzten 8 Hex-Stellen. Aber der Import verlief mit der richtigen Zuordnung der Schlüssel zu den Namen und Webadressen.

Eine Lösung des Problems unter KGpg besteht darin, den Import des Kundenschlüssels manuell über die Zwischenablage durchzuführen. Für Einsteiger wäre das aber nicht zumutbar.