Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Swap – ein paar Bytes zuviel?

Posted on by

Änderung des Beitrags am 07.06.2009:

Der nachfolgende Beitrag hat sich inzwischen in wesentlichen Punkten als haltlos entpuppt:

Ursache der Abstürze ist eindeutig ein fehlerhafter Speicherbaustein – also ein Hardware-Fehler in der betroffenen Maschine. Die unten beschriebene Verringerung des Swap-Bereiches hatte evtl. trotzdem positive Wirkung, als die Wahrscheinlichkeit, den defekten Speicherbereich zu treffen möglicherweise verringert wurde.

Es bleibt als Befund lediglich der fühlbare Geschwindigkeitsunterschied bei der Verringerung des SWAP-Bereiches und die Erkenntnis, das man bei statistisch auftretenden Fehlern der Klasse “General Protection Fault” zunächst mal den RAM auf Funktionstüchtigkeit prüfen sollte, bevor man sich in Spekulationen verliert.

********************************************

Alter Beitrag

Am letzten Wochenende musste ich mit einem Problem auseinandersetzen, dessen Ursache letztlich wohl im SWAP-Bereich lag. Das Ganze ist aber irgendwie komisch und deshalb aus meiner Sicht einen Blog-Beitrag wert. Zumal ich im Internet gefunden habe, das auch andere Leute mit verschiedenen Kernelversionen unter Opensuse 11.1 unregelmäßige Abstürze erlebt haben.

Ich hatte ein neues System mit 8GB DDR3-RAM und einem Intel Quadcore Q9550 Prozessor aufgesetzt (Opensuse 11.1 – x86_64). Das ist gleichzeitig die RAM-Grenze des Mainboards. Das System hat vier 1TB Platten in 2 Raid-1-Arrays. Da auf diesem System i.d.R. 2 VMware-Maschinen mit je 2GB Hauptspeicher und ein Samba-Server sowie Datenbank-Server laufen sollen, ist die Kalkulation des SWAP-Speichers nicht ganz einfach – zumal man hierzu im Internet durchaus unterschiedliche Philosophien finden kann.

Ich hatte auf der einen Partition eine SWAP-Partition von 4GB eingerichtet, auf der anderen einen Bereich von 8GB – letzteres nur testweise. Mein Motiv war, einfach mal auszuprobieren, ob im Alltag überhaupt Unterschiede feststellbar wären. (Generell glaube ich, dass bei 8GB Hauptspeicher selbst 4GB Swap völlig überdimensioniert sind, da ausgelagerte Bereiche komprimiert werden. In der Praxis zeigte sich, dass der Swap-Bereich lediglich beim parallelen Handtieren mit mehreren großen Dateioperationen eine Rolle spielte).

Egal:Zuletzt hatte ich den 8GB Swap Bereich mit “swapon” aktiv auf swap eingehängt. Im Zuge diverser anderer Ereignisse hatte ich dies aber vergessen und danach die Maschine mit dieser Einstellung produktiv benutzt.

Dann kam es zu unregelmäßigen, nicht nachvollziehbaren Abstürzen oder einem Einfrieren des ganzen Systems. Dies war für mich insofern erschütternd, als mir alle wesentlichen Einstellungen identisch mit einer fast gleich konfigurierten Maschine erschienen, die sich seit Wochen fehlerfrei im Dauerbetrieb befindet. Die Abstürze geschahen vor allem dann, wenn ich viele Dateien kopierte – ob unter VMware oder unter Linux.

Nach einer Beobachtung und Auswertung von /var/log/messages kam ich dann dahinter, dass die meisten der Abstürze an einen “General Protection Fault” gebunden waren. Dies versetzte mich bereits in gehörige Unruhe.

Als nächstes tauchten bei der Installation eines Programmpaktes plötzlich Meldungen auf, dass das System auf illegale Speicherbereiche jenseits der Parttionsgrenzen zugreifen wolle. Nun dachte ich an Speicherfehler – und ließ memcheck mal über mehrere Stunden laufen – ohne Fehlermeldungen.
Noch schlimmer wurde es, als ich danach einen systematischen Test der mehr als 10 Partitionen des Systems mit fsck durchführte – Fehler über Fehler trotz Recovery Journal des Ext3-Systems. Hier rächte sich übrigens die Aktivierung des Write-Cachings auf dem Raid Controller bitter. Der hat mehrere hundert MByte Caching Speicher. Bei den festgestellten Abstürzen findet hier kein sync des Writecaches mehr auf die Platten statt – das Filesystem kann deshalb nach dem Hochfahren auch über das Journaling Fehler ggf. nicht mehr ausbügeln – und man
merkt es nicht einmal !

Merke: Nach Abstürzen und aktiviertem Write-Caching trotzdem fsck-Prüfungen fahren !

Nun erklärt das aber nicht die Ursache der Abstürze – es macht höchstens ein systematisches Anwachsen der Filesystem-Probleme plausibel, wenn fsck nicht angewendet wird. Ich bereinigte also die Filesysteme über “fsck -f” . Danach prüfte ich alles Mögliche und verglich die Konfiguration meiner Maschinen – ergebnislos.Ich installierte einen älteren Kernel, deinstallierte überflüssige Pakete – alles vergebliche Mühe.

Durch Kopieren großer Dateimengen konnte ich den Fehler inzwischen systematisch provozieren. Und irgendwannmal gelang es mir nach einem Protection fault die Maschine noch weitgehend geordnet herunterzufahren. Dabei fiel mir auf, dass die Swap-Partiton nicht mehr freigegeben werden konnte. Nun erinnerte ich mich wieder an meine eigentlich “testweisen” SWAP-Einstellungen und aktivierte die kleinere SWAP-Partition statt der großen. 4GB SWAP waren übrigens auch auf dem Vergleichsystem eingestellt !

Und siehe da, das System lief danach

1. fehlerfrei

2. deutlich schneller als zuvor.

Kann Opensuse 11.1 mit dem aktuellen Kerne 2.6.27 nun einfach nicht mit 8GB SWAP arbeiten ? Ich weiss es nicht – komisch ist die Sache schon.

Interessant ist auch, dass der “testweise” Swap-Bereich minimal gößer als 8GB war. Zusammen mit den 8GB Ram wurde also evtl. ein irgendwo existierendes 16GB-Limit überschritten.

Der Kernel ist übrigens der aktuell für Opensuse 11.1 im Update Repository angebotene 2.6.27.21-0.1-default #1 SMP x86_64 .

Wenn einer eine Idee dazu hat, was hier los war, möge er mich informieren !

Installation Windows und CS4….ein Albtraum

Posted on by

Weil Krise ist und der Bürger mehr kaufen soll, um den Binnenmarkt anzukurbeln, wollte ich in Web-Entwickung investieren und habe mir das Upgrade auf Adobe CS4 Web Premium (Windows-SW!) geleistet.

Das ist eine sehr kostspielige Investition – der Preis für das Upgrade liegt etwa beim Doppelten dessen, was ein Harz4-Empfänger im Monat bekommt. Also erwartet man wenigstens eine halbwegs funktionierende Installation. Leider wird man hier bitter entäuscht. Schlimmer noch:

Ich habe noch nie eine so albtraumartige Installation irgendeines Systems vornehmen müssen !
18 sinnlos vergeudete Stunden!

Warum schreibe ich nun in einem Linux-Blog über ein Update in der Windows-Welt ?

1. Weil bei mir Windows (XP, SP3) unter VMware auf einem Linux-Host läuft und ich bislang mit den Adobe-Tools auch Web-Applikationen entwickelt habe.

2. Weil man sich ab und zu eine Windows-SW-Installation antun muss, um wieder genau zu wissen, was die IT-Entwicklung mit Linux und Opensource erreicht und gewonnen hat. Man durchforste mal das Internet bzgl. Installationsfehlern und -Problemen mit CS4 ! Ich finde das Beispiel symptomatisch für den Verfall jeglicher Qualitätssicherung im kommerziellen SW-Bereich. Man fragt sich angesichts der riesigen Anzahl an Treffern wirklich: Warum muss man eigentlich so viel Geld für Produkte bezahlen, für die der Kunde schon bei der Installation Beta-Tester spielen muss?

Ich habe die CS4 – Installation unter folgenden Voraussetzungen begonnen:

Voraussetzungen :

Vorhandene Adobe SW: Adobe Web-Premium CS3 habe ich vor 1,5 Jahren unter Windows XP als Update zu Macromedia Studio 8 installiert. Bis vorgestern habe ich die CS3 Suite produktiv eingesetzt. Alle CS3-Komponenten und Programme sind gepflegt und auf dem neuesten Stand.

Windows XP: Mein Windows XP ist unter einer virtuellen Maschine (VMware Workstation) auf einem Linux-Host (z.Z. Opensuse 11.1) installiert. Die virtuelle Maschine wurde vor ca. 3 Wochen problemfrei auf eine neue HW-Plattform (mit Intel-Quad-Core Prozessor) umgezogen. (Vorher lief diese Maschine über 3 Jahre stabil auf einem Athlon X2-System.) Der HW-Wechsel führte zur Installation neuer Treiber unter Windows. Windows selbst musste danach neu aktiviert werden. (Die vorhanden Adobe-Produkte [CS3] interessanterweise nicht, obwohl ich auch das schon bei Kunden erlebt habe.) Die virtuelle Maschine lief seitdem auf der neuen Hardware ohne Störungen. Die VMware-Version selbst ist die aktuellste (WS 6.5.2).

Host und HardwareMein virtuelle Maschine läuft auf zwei 2,83 GHz Prozessoren (von insgesamt 4 der Quad-Core-CPU des Linux-Hosts). Windows habe ich 2 GB RAM (von insgesamt 8 GB des Hosts) zur Verfügung gestellt. Im Laufe der Installation habe ich VMware ferner 2 DVD-Laufwerke zugänglich gemacht. Beides SATA-Laufwerke, die im Linux-Host als /dev/sr0 und /dev/sr1 erschienen. Im Windows Host bilden sich die als SCSI-Laufwerke ab. Dies ist deshalb erwähnenswert, weil der BusLogic SCSI-Controller der virtuellen Maschine in dieser Situation mit dem Treiber von VMware und nicht von Microsoft betrieben werden muss, auch wenn die virtuellen Festplatten als IDE-Platten eingerichtet wurden.

Also: Windows XP ist bei mir zwar virtuell vorhanden, dafür aber sehr großzügig ausgestattet – auch für Adobe CS3-Verhältnisse, das ja mindestens ein GB RAM sehen will. Ich ging daher davon aus, dass auch CS4 nichts zu meckern haben würde.

Ziel der Installation

Ich wollte CS4 zusätzlich zum vorhandenen CS3 installieren, um bei evtl. Problemen noch auf CS3 zurückgreifen zu können. Das ist eigentlich das vorgesehene Standardverfahren – zumindest habe ich nichts
Gegenteiliges gelesen.

Problem: Die Installation von Web Premium CS4 bei vorhandenem aktuellem Web Premium CS3 funktioniert nicht oder zumindest nicht immer !

Die Installation (des Updates) funktioniert unter den oben genannten Voraussetzungen nicht! Ich möchte den Leidensweg meiner vielen Anläufe über mehr als 18 Stunden hinweg nicht im Detail beschreiben – das würde Seiten füllen. An dieser Stelle mögen Stichworte genügen:

Mehrere Installationsanläufe mit sich ändernden Fehlern / Update-Versuche der Komponenten, die installiert wurden, über das Internet mit völig unterschiedlichem Ergebnis / Crashes und Blue Screens der virtuellen Maschine (sowas habe ich zuvor über mehrere Jahre hinweg überhaupt noch nie erlebt) / Probleme mit der Adobe Acrobat Seriennummer nach Deinstallation von Acrobat.com (es lief schon fast alles ausser Acrobat) / Installation nur einzelner Komponenten von CS4 / Installation unter verschiedenen Usern / Installation von der Festplatte statt von DVD / Installation nach Deinstallation von CS3, ……… immer gab es irgendwo und irgendwann Probleme – z.T. massiver Art bis zum Absturz von Windows. Und alles auf einem bisher absolut stabilen System.

Ich behaupte mal, dass das nichts mit der VMware-Umgebung zu tun hat, sondern mit früheren regulären Updates der vorhandenen CS3-Programme und entsprechenden Registry-Einträgen, die dem CS4 nicht gefallen.

Und mit diesem Befund stehe ich weiss Gott nicht alleine da – im Internet gibt es -zig Seiten zu der völlig misratenen Installationsroutine von Adobe und zu den vielfältigsten Varianten der resultierenden Katastrophen. Typischerweise bricht die Installation bei einer oder mehreren wichtigen Programmen (Photoshop, Flash) ab. Man kann danach noch einige Reste an SW installieren. Insgesamt kommt es aber zu einem Fehler “1603”, der sich hartnäckig als irreperabel erweist. Zudem folgen u.U. eine Reihe weiterer Fehler 1714, 1907 etc., oft im Font-Bereich oder im Zusammenhang mit Acrobat, Photoshop oder Flash. Man suche mal im Internet unter CS4 und Fehler 1603 !

Die Versuche, es durch erneute Anläufe und Zugriff auf Updates aus dem Internet doch irgendwie hinzukriegen, münden nur in einen gigantischen und sinnlosen Aufwand (bei mir ca. 20 Arbeitsstunden). Das Verhalten des Installers ist dabei völlig unberechenbar und inkonsistent. Ich habe in stundenlangen Versuchen so ziemlich alles ausprobiert, was ich im Internet an Hinweisen von Leidensgenossen gefunden habe. Übrigens auch viele Ratschläge der Fa. Adobe, die bis auf einen nichts geholfen haben.

Dabei konnte ich nur deshalb halbwegs ruhig bleiben, weil ich vor dem ganzen Theater einen Clone meiner virtuellen Maschine angelegt hatte, auf den ich im Ernstfall zurückgreifen hätte können (es lebe VMware !). Ich möchte mir eine entsprechende Situation und die Gefühle von Leuten mit realen, produktiven Windows-Systemen gar nicht ausmalen! Im Internet gibt es dazu einiges zu finden.

Letztlich funktionierte bei mir nur eines – nähmlich ein Vorgehen nach dem Prinzip “tabula rasa”: Man bereinige das System von allen Adobe-Einträgen und früheren Installationen und installiere erst danach CS 4 (erneut).

Meine Lösung:

Läuft die Installation nicht von Anfang an fehlerfrei durch, so erhält man durch neue Versuche (auch durch erfolgreiche Updates) offfenbar ein immer problematischer werdendes System. Man entferne deshalb schon nach dem ersten Fehlschlag systematisch alles, was sich aus früheren Installationen auf dem System befindet. In meinem Fall bedeutete das Folgendes:

  1. Systematische Entfernung von Adobe CS3
    Es reicht nicht, das über eine Windows-SW-Deinstallation zu tun. Man beschaffe sich vielmehr gleich die Tools von Adobe (http://www.adobe.com/support/contact/cs3clean.html) und benutze die mindestens auf Level 2 (ggf. 3 oder 4 – man kann dies
    einfach eingeben, wenn nach dem Level gefragt wird)
    .
  2. Reboot des Windows-Systems
  3. Beseitigung aller vorhergehenden (missglückten) Ruinen der CS4-Installation.
    Dazu setze man nach einer Deinstallation über das Windows SW-Management auch die Reinigungstools von Adobe ein (http://www.adobe.com/support/contact/cs4clean.html). Gut, dass es wenigstens diese Tools gibt.
  4. Reboot des Windows-Systems
  5. Reinigen der Oberfläche der CS4-DVDs (es gibt sehr viele Mini-Dateien zu übertragen – das DVD-Laufwerk wird in puncto häufige Positionierung sehr belastet)
  6. Installation als “administrator” – es wird wirklich der Windows “system”-Account benötigt.
  7. Abschalten des Virenscanners (rein aus Zeitgründen) – eine sinnvoll konfigurierte Personal-Firewall bereitete keine Probleme (F-Secure in meinem Fall).
  8. Zur Sicherheit: Zuordnung von nur einem Prozessor-Kern zur virtuellen Maschine. Bei SATA-DVD-Laufwerken am Host : Check, dass dem BusLogic-SCSI-Controller der virtuellen Maschine der VMware-Treiber und kein Microsofttreiber zugeordnet ist. Mit dem Microsoft-Treiber laufen die Sata-Devices, die als SCSI-Laufwerke abgebildet werden, nicht stabil genug. Den VMware-Buslogic-Treiber findet man im Downloadbereich der VMware-Website.
  9. Zuordnung zweier DVD-Laufwerke zur virtuellen Maschine und Einlegen der ersten CS3 DVD in ein Laufwerk. Dies gilt vermutlich nur,wenn CS4 als Upgrade eingespielt wird. Bei mir wurde die Seriennummer des CS4-Paketes nach der Deinstallation von CS3 und CS4 nicht mehr akzeptiert, solange der Installer nicht irgendwas von CS3 auf dem System finden konnte. Ich habe daher im zweiten Laufwerk während der ganzen Installation die CS3-DVD mitlaufen lassen.
  10. Neuinstallation von der CS4-DVD. Das lief bei mir dann anstandslos durch.
  11. Bei manchen Leuten hat es geholfen, die DVDs auf C:/ zu kopieren und dann von der Festplatte aus zu installieren. Man muss dabei aber den Namen des Verzeichnisses “Adobe CS4” jeder DVD rechtzeitig während der Installation umbenennen – der Adobe Installer sucht beim verlangten DVD-Wechsel immer nach dem gleichen Verzeichnis “Adobe CS4”. (s. auch “http://www.keptlight.com/?p=383” und die dortigen Hinweise).

Diskussionswürdige Ratschläge von Adobe im Internet

Noch etwas – einige Hinweise von Adobe selbst im Internet (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb404083_ger_DE&sliceId=1)
sind für mein Gefühl letztlich eine Zumutung (obwohl sie bei dem einen oder anderen Betroffenen geholfen haben mögen):

So stimmt mich der lapidare Hinweis, es unter Abschalten aller Firewalls und Virenscanner zu versuchen, von Haus aus nicht nur missmutig sondern auch mißtrauisch. Warum sollte das erforderlich sein ? Was betreibt Adobe da auf der Maschine ? Ich habe das trotzdem probiert – genutzt hat es gar nichts. Das gleich gilt für die empfohlene Deinstallation des Google-Desktop – sowas gab und gibt es bei mir sowieso nicht.

Hinzu kommen die Aufforderungen, die Installation doch bitte mal für einen neu angelegten User zu versuchen oder gar auf einem anderen Computer. Wenn es so auch nicht ginge, solle man sich an Adobe wenden ! Ansonsten an den Hersteller des Computers.

Was denken die sich eigentlich ? Dass jeder Kunde gerade mal einen zweiten Computer für stundenlange Tests parat hat und dass kleinere Firmen es sich leisten können, im produktiven Umfeld nebenbei neue User einzurichten und dann alle erforderlichen Konfigurationseinstellungen nachzuziehen. Sinngemäß heisst das: Lieber Kunde wende dich erst an mich, wenn du meine fehlerhafte SW, deren Installation ca. 2,5 Stunden kostet, mehrfach auf verschiedenen Systemen und unter anderen Accounts ausprobiert hast. Und wenn du dabei zufällig eine Konstellation finden solltest, mit der auch wir bei der Entwicklung des
Installers gerechnet haben, dann darfst du dich wegen der vorhergehenden anderen Probleme nicht mehr an uns sondern deinen Computerhersteller wenden. Was für eine Zumutung und Arroganz – und was für ein Armutszeugnis für eine so renommierte Firma !

Dann lese man sich auch mal folgende interessanten Blog-Artikel zum persönlichen Service von Adobe im Zusammenhang mit der CS4-Installation durch:

http://www.keptlight.com/?p=382 und http://www.keptlight.com/?p=383

Dem gibt es nichts hinzuzufügen !

(Zugegebenermaßen gibt es auch bessere und sachlichere Beispiele an Adobe Ratschlägen :
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb408716 – Lösung 7.

Schlechte Erfahrungen auch schon mit CS3

Auch bei der Installation von CS3 (Upgrade von Studio8) vor eineinhalb Jahren gab es bereits erhebliche Probleme, die ich damals aber umschiffen konnte. Ich hätte also gewarnt sein können. So schlimm wie bei CS4 war es aber bei weitem nicht gewesen!

Fazit und Appell:

Liebe Leute von Adobe:

Wenn ihr einfach zugeben würdet, dass die Installation bei einem vorhandenen CS3 nicht läuft und im Internet schreiben würdet, dass man von vornherein alles, was mit Adobe zu tun hat, vom System entfernen muss und zugleich die Registry mit euren Cleaner-Tools bearbeiten muss, so würdet ihr vielen Menschen weniger unproduktive und sinnlos vergeudete Zeit von ihrem Leben stehlen. Würden allein alle diejenigen Betroffenen, die zu den Installationsprobleen im Zshg. mit CS4 inzwischen etwas ins Internet gesetzt haben, für die vergeudete Zeit eine Rechnung zum Stundensatz eurer Entwickler stellen, würde das für euch sehr teuer werden. Diese Summe solltet ihr künftig in die Qualitätssicherung eurer Installationsroutinen stecken!

Bei mir hat die CS4-Installation nur dazu geführt, mich wieder intensiver im Opensource-Bereich nach Alternativen umzusehen. Was bei Flash zugegebenermaßen ein schwieriges Unterfangen ist ….

GA EP45 Extreme mit 8 GB

Posted on by

Unter Linux lohnt sich ein großer Hauptspeicher, wenn man viel mit einer oder mehreren virtuellen Maschinen arbeitet. Eine unserer neuen Arbeitsstationen basiert auf einem Gigabyte Board, dem “GA EP45 Extreme”. Wir wollten dieses Board mit 8GB Hauptspeicher bestücken und zwar Modulen von Corsair (Dominator PC2-8500 C5 1066 Mhz, 2GB pro Speicherriegel).

Als CPU kam ein Intel Q9550 Quadcore zum Einsatz (2,83 GHz). Die Speicherbänke waren durch 4x 2GB-Speicherriegel voll besetzt. Installiert werden sollte Opensuse 11.1, 64Bit.

Die Dominator-Speicherbausteine von Corsair sollen theoretisch mit einer 5-5-5-15 T2 Taktung bei 2.1V DRAM Spannung mit 1066 MHz laufen. Eine entsprechende Einstellung im BIOS des Boards (man muss das DRAM Profil 2 wählen und die Spannung auf 2.1 Volt hochsetzen) führte bei uns aber trotz mehrstündigen Anläufen und unterschiedlichen BIOS-Einstellungen nicht zum Erfolg. Hier kommt man über das BIOS nicht hinaus – der Versuch, Opensuse zu installieren scheitert umgehend.

Mit RAM-Profil 1 (einer seltsamen Taktung die 800 MHz entspricht) und der Standardspannung von 1.8V kann man zwar eine Installation beginnen. Es ergeben sich aber immer wieder Schwierigkeiten und Instabilitäten schon während der Installation von Opensuse 11.1. Diese Instabilitäten legen dann die graphische Installationsroutinen von Opensuse lahm oder führen zu Abbruch der Installation mit Fehlermeldung. Sehr frustrierend, wenn man nach Installation von 2GB Software schließlich doch havariert!

Die erste wirklich stabile Einstellung mit 8GB war folgende:

Bus 333 MHz. Faktor CPU 8,5. (8+0.5 im Bios)
DRAM: Profile 2 5-5-5-15 bei einem Bus-Faktor von 2.4 ! Dies entspricht einem reduzierten Betrieb mit 800 MHz.
DRAM-Spannung 2.1 Volt (ging aber auch mit 1.9 V).

Damit haben wir uns aber nicht zufrieden gegeben.

Nach ein paar weiteren Versuchen fanden wir nämlich heraus, dass das Board mit nur 4 GB (also nur zwei besetzten Bänken) auch mit Profil 2 und dem Faktor 3.5 für 1066 MHz halbwegs stabil lief. Es funktionierte nur nicht bei Vollbesetzung der Speicherbänke im Dual Channel Mode !

Die Wurzel des Übels lag letztlich in der BIOS -Version F3 des Boards. Ein Update auf die BIOS-Version F7 und später Version F8 brachte endlich das gewünschte Ergebnis:

* Profil 2 für 1066 MHz (Bus-Faktor 3.5)
* DRAM-Spannung 2.06Volt (das Board neigt zu höherer realer Spannung – gemessen wurden bei dieser Einstellung faktische 2.11 Volt !)
* 8 GB Vollbesetzung

und alles voll stabil! Auch nach tagelangem Betrieb von Opensuse 11.1 keine Stabilitätsprobleme. Übrigens bislang auch keine Temperaturprobleme.

Wir freuen uns nun auf unser neues Arbeitsgerät !

Zweites Alpha-Release 64 Bit Flashplayer

Posted on by

Ich habe heute das zweite alpha-Release des 64Bit-Flash-Plugins von Adobe für Linux ausprobiert.

Der größte Fortschritt ist für mich war, dass dieses Plugin nun auch mit Konqueror KDE 4.2 funktioniert !

Ich habe meinen ursprünglichen Beitrag

https://linux-blog.anracom.com/2009/01/26/kurztest-der-64-bit-version-des-flash-plugins-von-adobe/

zum ersten Release abgeändert und so aktualisiert, dass die Installation auch mit dem neuen Release funktioniert.

Getestet habe ich unter aktuellen Versionen von Konqueror, Firefox und Opera (alles 64 Bit unter Opensuse 11.1 mit KDE 4.2 (Factory Repository)). Sieht ganz gut aus !

Weiter so Adobe ! Endlich habt ihr begriffen, dass Innovation über Linux und nicht über Micro-Software läuft ! Dann macht es ja vielleicht in naher Zukunft sogar wieder Spaß, Flash-Applikationen zu entwickeln!

KDE 4.2, Firefox, Checkboxen und Radiobuttons

Posted on by

Ein paar Bekannte haben beim Einsatz von Firefox unter KDE 4.2 das gleiche Problem mit Web-Formularen, das auch ich nach dem Umstieg auf KDE 4 hatte:

Die Checkboxen und Radiobuttons funktionieren optisch im Firefox 3 nicht richtig – zumindest nicht auf einer Default-Opensuse-11.1-Installation, die um KDE 4.2 ergänzt wurde. Man kann Checkboxen z.B. zwar anklicken – danach sieht man aber keinen Haken. Dieser taucht erst wieder auf, wenn man im Formular an anderer Stelle mit der Maus klickt. Ziemlich irritierend, weil man nicht direkt sieht, ob eine Checkbox/Radiobutton nun aktiv ist oder nicht.

Das ist aber kein Firefox-Problem, wie man meinen könnte, sondern ein GTK-Thema. In etlichen Kubuntu-Blogs wird zum gleichen Thema empfohlen, einen vernünftigen GTK-Style über die KDE 4 “Systemeinstellung” zu wählen. Das reicht nach meiner Erfahrung unter Opensuse leider nicht – man benötigt nämlich noch ein paar notwendige Bibliotheken, die nicht in ihrer Gesamtheit installiert sind.

Essentiell bei SUSE sind grundsätzlich die Pakete gtk und gtk-qt-engine – letzteres für KDE. Das korrekte Anzeigen der Checkboxen hängt aber an zusätzlich benötigten GTK2 Bibliotheken. Man benötigt deshalb auch die Pakete “gtk2”, “gtk2-engines”, “gtkhtml2”, “libgtkhtml”, “qtcurve-gtk2”, “qtcurve-kde4” und ggf. für die Einstellung von GTK-Themen “gtk2-themes”, “kde4-kcm_gtk”.

Als GTK-Theme oder Stil habe ich über das KDE 4.2-Konfigurationszentrum
“Systemeinstellungen (system-settings)-> Erscheinungsbild->GTK-Stile und Schriftarten”
übrigens “QtCurve” gewählt. Das ist auch eine notwendige Bedingung für das Beseitigen der Probleme mit den Checkboxen!

Ferner habe ich “KDE-Schriftarten in GTK-Anwendungen verwenden” aktiviert. Das zwar für das Checkboxen-Thema unerheblich, trägt aber zu einem besseren Aussehen bei.

Danach sieht der Firefox ganz ordentlich aus und die Checkboxen in Formularen funktionieren anstandslos.

P.S.: Liste an GTK-relevanten Paketen
Der Vollständigkeit halber hier eine vollständigere Liste von gtk-relevanten Paketen, die bei mir (aus verschiedenen Gründen u.a. Entwickung) auf einer Workstation installiert sind:
glib, gtk, gtk-32bit, gtk2, gtk2-32bit, gtk2-branding-openSUSE, gtk2-devel, gtk2-engines, gtk2-engines-32bit, gtk2-lang, gtk2-theme-openSUSE, gtk2-themes, gtkglext, gtkglext-32bit, gtkhtml2, gtkhtml2-devel, gtkhtml2-lang, gtkmm2, gtkmm2-devel, gtk-qt-engine, gtk-gt-engine-32bit, gtk-sharp2, gtk-sharp2-32bit, gtk-sharp2-32bit, gtksourceview18, gtkspell, gtkstyle, gxine, kde4-kcm_gtk, libgtkhtml, libgtkhtml-32bit, libgtkimageview0, libsexy, libwebkit-1_0-1, perl-Gtk2, phat, python-gtk, python-qt, qtc, qtcurve-gtk2, qtcurve-gtk2-32bit, qtcurve-kde4

———————————————————

Eigene Ergänzung II vom 22.02.2009:
*********
Muss mich nochmal entschuldigen für die Verwirrung, die ich mir selber und evtl. anderen heute durch meine erste heutige Ergänzung (s.u.) bereitet habe. Nach ein wenig Nachdenken und weiteren Checks lässt sich das Checkbox-Problem von Firefox 3.0.6 unter KDE 4.2 (Factory-Repository von Opensuse 11.1) doch beheben:

1) Ich habe bei den letzten Updates einen Fehler begangen und das Paket “qtcurve-kde4” leider aus dem Unstable-Zweig und nicht aus dem Factory-Zweig installiert. Das war eine der Ursachen dafür, dass die oben vorgeschlagene Problemlösung zwischenzeitlich nicht lief (s. meinen Einschub unten). Mit der aktuellen Version von KDE 4.2 aus dem SUSE Factory-Repository und der zugehörigen Version 0.60-2.2 von “qtcurve-kde4” ist alles wieder OK.

2) Ich habe zu meiner Schande zudem vergessen, das Paket “qtcurve-kde4” in den Listen der erforderlichen Pakete oben mit einzufügen. Ohne dieses Paket geht aber gar nichts. Diesen Fehler habe ich nun korrigiert und das Paket oben in fetter Schrift
hervorgehoben.

Ich hoffe, dass ihr das Problem nun unter Berücksichtigung der übrigen Hinweise des originalen Beitrags in den Griff bekommt ! Sorry nochmal – ich hätte gleich sorgfältiger arbeiten müssen.

[
Inzwischen irrelevante Ergänzung I vom 22.02.2009:
*********
Sorry, liebe Leute:
Der obige Artikel zur Lösung des Checkbox-Problems in Firefox stimmt leider nicht mehr. Nach einer weiteren Update Runde mit Firefox (3.0.6) und KDE 4.2 aus dem Factory Repository von SuSE ist das Problem mit den Checkboxen und Radiobuttons von Firefox wieder da – auch wenn man die oben empfohlenen Bibliotheken installiert hat und QtCurve als GTK-Scheme eingestellt hat.
]