Heute habe ich mir endlich einmal die Zeit genommen, um zu testen, ob ich Zak McKracken 2 unter Linux zum Laufen bewegen kann.

Vorweg: es läuft - einzig den Sound in den Videosequenzen bekomme ich mit der z.Zt. mit Hardy Heron ausgelieferten Wine-Version “0.9.59-0ubuntu5″ nicht aus den Boxen.

Weitergeholfen hat mir der Beitrag von ’Hallerich’ im Zak2-Forum.

Man benötigt neben dem Zak2-Installer (den man beispielsweise auch bei Winboard herunterladen kann) noch ffdshow, die Datei “avifil32.dll“, sowie den MP3-Codec von Frauenhofer.

Ich gehe davon aus, dass Wine installiert und winecfg schon einmal gelaufen ist.

In diesem Fall startet man nun die setup.exe aus dem Zak2-Installationsverzeichnis. Die Installation benötigt weder DirectX noch XVID, statt des XVID-Codecs sollte man ffdshow benutzen (das wird auch von den Entwicklern empfohlen).

Die ffdshow-Installation kann im Anschluss an die erfolgreiche Einrichtung von Zak2 gestartet werden.

Es reicht, nur das VFW-Interface (”Video For Windows”) für die Installation zu markieren. Danach habe ich der Einfachheit halber alle Videoformate für die Benutzung mit ffdshow markiert - eigentlich sollte xvid reichen. Die Kompatibilitätsliste für den Video- und den Audio-Dekoder habe ich auf “nicht begrenzen” gestellt, sonst müsste man Zak McKracken danach noch manuell zur Verwendung mit ffdshow freigeben.

Um Wine beizubringen, die im Spiel eingebetteten Videos ruckelfrei abzuspielen, entpackt man jetzt die “avifil32.dll” nach ~/.wine/drive_c/windows/system32.

Und damit auch Ton aus den Lautsprechern kommt, fehlt noch die Installation des MP3-Codecs aus der “l3codecx.exe”.

Nun ist Zak fast startbereit. Es würde auch schon laufen, allerdings käme es noch zu einem ziemlich langen Hänger beim Spielstart und zu Rucklern im Spielverlauf.

Um das zu verhindern, sollte man über winecfg “zak2.exe” unter “Anwendungen” hinzufügen und “Windows 98″ als Windows-Version voreinstellen. Abschließend sollte Wine außerdem unter “Bibliotheken” angewiesen werden, die gerade einkopierte avifil32.dll zu verwenden, und nicht die im Emulator integrierte.

Einfach eine “Neue Überschreibung” für avifil32 hinzufügen und als “Native, Builtin” konfigurieren.

Fertig:

Das Spiel läuft, auf diese Weise installiert, bei mir einwandfrei. Einzig der Ton in den Videos macht Probleme. Nach ca. einer Sekunde bricht der Ton ab, auf der Konsole erscheinen dann Meldungen, wie:
fixme:wavemap:wodWrite Not all src buffer has been written, expect bogus sound
fixme:mpeg3:III_get_side_info_1 big_values (418) too large!
fixme:wavemap:wodWrite Got 0 length
Eine kurze Internet-Recherche ergab, dass das wohl ein Problem mit der in Ubuntu eingesetzten Wine-Version sein muss. Ein aktueller RC zur Version 1.0 sollte den Fehler wohl nicht mehr aufweisen.

Aber das auszutesten, ist mir für ein Spiel dann doch zu viel Aufwand. Über Erfahrungsberichte hierzu würde ich mich natürlich freuen.

Wer die Zwischensequenzen mit Ton sehen möchte, findet diese nach der Wiedergabe im Spiel im TMP-Unterverzeichnis von Zak2. Das Programm löscht die Dateien nämlich nach dem Abspielen nicht - und legt bei jeder Wiedergabe eine weitere Kopie des Videos an. Es empfiehlt sich also, tmp ab und zu mal zu entmisten …

So, jetzt möchte ich dem Spielvergnügen nicht weiter im Wege stehen - Viel Spaß

Wie kann man nur in eine “LTS”-Version von Ubuntu eine Beta-Version vom Firefox integrieren?

Dauernd stürzt das Teil ab. “Flash an, Firefox aus” sozusagen.

Naja, der Rest scheint aber stabil und fehlerfrei zu rennen.

Eigentlich hatte ich ja schon Anfang des Jahres vor, mir KDE 4 anzusehen.

Nur irgendwie motiviert es nicht wirklich, ein halbfertiges System zu installieren.

Jetzt ist jedoch die erste Beta von KDE 4.1 veröffentlicht. Schon vollständiger als die Vorversion.

Ich sitze die Beta-Phase jetzt noch die zwei Monate aus, im Juli soll die finale Version dann erscheinen. Und dann bekommt KDE evtl. noch einmal eine Chance, als Gnome-Alternative auf meinem Desktop Platz zu finden.

So langsam wird es grotesk.

Energiekonzerne, Krankenkassen oder Banken (um nur ein paar der großen Absahner zu nennen) verdienen sich dumm und dusselig und Vater Staat schraubt sich mehr Steuern rein, als die Volksvertreter selbst erwartet hätten.

Zeitgleich kämpfen verschiedenste Gewerkschaften mit ausufernden Streiks darum, dass die arbeitende Bevölkerung zumindest mit einer an die Teuerungsrate des Landes angepasste Beteiligung am aktuell spürbaren Wirtschaftsaufschwung teilhaben darf.

Familien werden finanziell immer härter drangsaliert, dabei wird offen, auch aus Reihen der Politik davor gewarnt, dass immer mehr Bürger (auch aus der Mittelschicht) an den Rand der Armutsgrenze abrutschen.

Steuererleichterungen oder Zuwendungen aus dem Staatssäckel an die Bürger werden durch Minister Steinbrück kategorisch abgelehnt, die Sanierung des Staatshaushaltes habe Vorrang.

Zumindest wird werbewirksam, wir sind ja in Zeiten des Wahlkampfes, über eine Erhöhung der Renten diskutiert.

Und da wollen sich die Abgeordneten in Berlin mal eben klammheimlich eine 15-prozentige Diätenerhöhung bis 2010 zuschanzen.

In Politikerkreisen werden Diäten “Abgeordneten-Entschädigung” genannt, ich frage mich, wofür wollen die denn entschädigt werden.

Und nachdem nun vorerst hektisch zurückgerudert wurde, was soll das Thema auch im Wahlkampf, werden direkt Kommentare von Seiten der CDU laut, frei formuliert hört sich das dann so an:

“Die Leute meinen noch, wir wären gierig, wenn wir unsere Diäten erst um 15% erhöhen wollen, diese Entscheidung dann aber zurücknehmen können.”

Also wird das Thema auf später verschoben, wenn auch für den Bürger unangenehme Entscheidungen durchgedrückt werden können, nämlich kurz nach den Wahlen.

Und dabei sollte man nicht davon ausgehen, dass keine Anpassung der Abgeordnetenbezüge vorgenommen würden. 2008 waren das 4,7%, Anfang 2009 kommen noch einmal knapp 4,5% obendrauf. Das macht weit über 7000 Euro monatlich im Portemonnaie eines jeden Abgeordneten.

Dazu passend auch die Reaktionen von Politikern zu einer Umfrage der Zeitschrift “Capital”. Die wollten sowohl von Wirtschaftsbossen, als auch von den Spitzenpolitikern in Deutschland wissen, was diese denn so an Steuern abdrücken.

Aus der Wirtschaft kamen, trotz der z.Zt. sowieso schon schwierigen Fahrwasser zur Frage der Gehaltsklassen in den Chefetagen, auch Antworten.

Die Manger von Konzernen wie Adidas gaben bereitwillig Auskunft und nannten Zahlen, bei denen Ottonormalverbraucher schwindelig wird.

Volksvertreter wie Frau Merkel jedoch, oder auch Herr Schäuble verweigerten die Aussage. Das macht nachdenklich. Sehr nachdenklich. Die Begründung von Herrn Schäuble hierzu möchte ich garnicht erst nennen, denn das würde wieder einen dunklen Schatten über die ansonsten so offen zur Schau gestellte Datensammelleidenschaft des Ministers werfen.

Da bewahrheitet sich auf jeden Fall wieder:
Diäten, bei denen man selbst bestimmen darf, wieviel es zu essen gibt, funktionieren einfach nicht.

(gesehen auf aptgetupdate.de)

Gerade auf [pimp my shell] gefunden:

sprunge.us ermöglicht es, direkt aus der Shell einen Beitrag auf dem “nopaste-Service” zu posten, sprunge.us liefert die URL zurück auf die Shell.

Auf sprunge.us steht, wie es geht.

Ich habe mir das ganze noch ein wenig vereinfacht und ~/bin/nopaste mit folgendem Inhalt angelegt:
#!/bin/bash
curl -F 'sprunge=< -' http://sprunge.us

Jetzt kann ich simpel mit
$ echo foobar | nopaste
“nicht einfügen”.

Sehr praktisch.

Mittlerweile habe ich endlich alle Debian-Systeme patchen können, das Beheben der openssh-Sicherheitslücke war mit
# aptitude update && aptitude dist-upgrade
und dem Erzeugen ein paar neuer Schlüssel und Zertifikate wirklich kein Hexenwerk.

Aber beinahe hätte ich mir trotzdem ein Eigentor geschossen. Denn neben den aktuellen openssh-Paketen rutschte auf einem Webserver auch ein Kernel-Update mit auf die Platte, das einen Neustart erforderte. Ich war schon fast beim “init 6″, als mir einfiel, dass ich doch besser nochmal versuchen sollte, eine ssh-Verbindung zum Server aufzubauen.

Und flups, da hieß es direkt:

Permission denied (publickey).

und im auth.log des Servers tauchte die Meldung:

May 17 10:37:43 localhost sshd[21441]: Public key b1:5f:68:94:45:0e:fb:4a:9e:1e:19:b3:cb:6f:2a:b3 blacklisted (see ssh-vulnkey(1))

Mir war zwar bekannt, dass das Upgrade das Paket openssh-blacklist mit auf das System gebracht hatte, dass aber eine Verbindung mit dem eigenen, noch verwundbaren Schlüssel direkt unterbunden wurde, hat mich dann doch überrascht.

ssh-keygen hat’s gerichtet, der Server bootet gerade neu.

Und die Moral von der Geschicht’: vergiss den eig’nen Client nicht

Wiedereinmal macht eine Sicherheitslücke Schlagzeilen (hier oder hier oder natürlich hier).

Diesmal ist OpenSSL in Debian betroffen, die mit den bisher ausgelieferten Versionen des Paketes seit 0.9.8c-1 generierten Schlüssel sind vorhersagbar.

Es ist dringend empfohlen, alle Systeme mit dem nun zur Verfügung stehenden Sicherheits-Update auszustatten, sowie alle betroffenen Schlüssel (SSH, OpenSSL, …) und x509-Zertifikate zu erneuern.

Hurra.

Zu lesen auch auf:

ende-der-vernunft-org

oder

roothausen.de

unixODBC macht mich echt fertig.

Nachdem ich die ODBC-Verbindung zu meiner Oracle-Datenbank scheinbar erfolgreich eingerichtet hatte, funktionierten die meisten DB-Funktionen mit dem danach installieren SquirreL SQL Client nicht.

Dauernd flog die Verbindung zum DBMS mit der Fehlermeldung: “[unixODBC][Driver Manager]Driver does not support this function” ab.

Ich schob den Fehler dem JDBC-Teil der Java-Anwendung zu (v.a. wg. der Meldung “Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.” und dem Umstand, dass der Fehler in einer testweise angelegten OOO-Base-Datenbank nicht auftrat), und richtete für das Programm dann die Verbindung über den “Oracle OCI Driver” ein. Das funktionierte auch einwandfrei.

Als ich jedoch gerade anfing, eine QT-Anwendung zu erstellen, die auch über ODBC an meine Oracle-Instanz andocken sollte, rieselte es wieder die “Driver does not support..”-Fehler.

Der Connect funktionierte, die Abfragen blieben allesamt hängen.

Und weil in der OSS-Version von QT keinen OCI-Treiber gibt, musste ich mich nun zwangsläufig mit dem Fehler auseinandersetzen.

Ein Trace der unixODBC-Verbindung ergab folgende Log-Einträge:

[ODBC][25990][SQLSetStmtAttr.c][243]
Entry:
Statement = 0×811f6d0
Attribute = SQL_ATTR_CURSOR_TYPE
Value = 0×3
StrLen = -5
[ODBC][25990][SQLSetStmtAttr.c][356]Error: IM001
[ODBC][25990][SQLGetDiagRec.c][710]
Entry:
Statement = 0×811f6d0
Rec Number = 1
SQLState = 0xbf916856
Native = 0xbf916860
Message Text = 0xbf916867
Buffer Length = 512
Text Len Ptr = 0xbf916864
[ODBC][25990][SQLGetDiagRec.c][747]
Exit:[SQL_SUCCESS]
SQLState = IM001
Native = 0xbf916860 -> 0
Message Text = [[unixODBC][Driver Manager]Driver does not support this function]

Endlich hatte ich Futter fuer meinen Freund Scroogle. Gleich im ersten Link des Suchergebnisses fand ich eine vermeintliche Lösung: die “aktuelle” Version 2.2.12 von unixODBC - immerhin auch schon fast zwei Jahre veröffentlicht - sollte meine Verbindungsprobleme lösen.

Ein Debian-Paket dafür war nirgendwo in Sicht, also musste ich wohl selber den Compiler anschmeißen.

Blöd dabei wieder:

Vom noch installierten unixodbc ist das immer noch für die Eclipse-Umgebungen für Aptana und QT benötigte Java-Runtime-Environment abhängig. Ich entschied mich vorerst gegen die Deinstallation und für eine Parallelinstallation der Version 2.2.12 nach /opt.

Nach dem Übersetzen und der Installation der Software trug ich, schnell und schmutzig /opt/unixodbc/lib als erste Zeile in die ld.so.conf ein und erneuerte den Cache.

Und siehe da: meine QT-Anbindung schmeißt keine Fehler mehr.

Dann werde ich das JRE wohl auch händisch installieren und die Ubuntu-Pakete von unixodbc und JRE vom System verbannen.

Marc hatte unter meinem letzten Blogeintrag (Oracle-ODBC-Zugriff für Debian und Ubuntu) das Datenbanktool “SQuirreL SQL” empfohlen.

Die Featurebeschreibung liest sich gut, also ging’s gerade direkt in die Testphase.

Das Programm ist in Java programmiert, ist somit weitestgehend Betriebssystem-unabhängig einsetzbar, und dank JDBC-Schnittstelle sind auch alle Datenbanken ansprechbar, für die ein entsprechender Treiber existiert.

Bei mir kommt naturgemäß nur ein Debian-Derivat als Basis in Frage, in diesem Fall musste Ubuntu 8.04 (Hardy Heron) dran glauben.

Die Installation ist schnell über

$ java -jar squirrel-sql-2.6.5a-install.jar

erledigt, beim anschließenden Aufruf von squirrel-sql.sh startet der Client auch schon.

Da ich auf meinem System bereits ein ODBC-DSN zu meiner Oracle-Datenbank eingerichtet hatte, und der entsprechende Treiber als einziger in SQuirreL SQL schon zur Verfügung stand, versuchte ich zunächst, die “JDBC-ODBC-Bridge” als Verbindungselement zu benutzen.

Als URL für den Datenbank-Alias TEST trug ich “jdbc:odbc:test” ein, der mit dieser Einstellung durchgeführte Verbindungsversuch zur Oracle-Testinstanz wurde positiv beschieden.

Ich konnte auch eine Sitzung mit dieser Konfiguration aufrufen. SQuirreL lud alle Schemes, Tables und weiteren Bestandteile der DB-Instanz und öffnete das Sitzungsfenster. Doch alle weiteren Versuche, auf der Datenbank zu arbeiten, wurden mit Fehlern, wie:

Error: [unixODBC][Driver Manager]Driver does not support this function

TEST: [unixODBC][Driver Manager]Connnection does not exist

oder

Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.
Das Eigenschaftenregister konnte nicht geladen werden.

quittiert.

Und weil ich nicht wirklich ein Faible für Java habe, und mich mit den Exceptions nicht weiter auseinandersetzen wollte, entschied ich mich für die sowieso sinnvollere Alternative, den “Oracle OCI-Treiber” einzurichten.

Und so funktioniert’s:

Download der Dateien

“instantclient-basic-linux32-10.2.0.3-20061115.zip” und

“instantclient-jdbc-linux32-10.2.0.3-20061115.zip”

von oracle.com.

Die entpackten Dateien habe ich nach nach “~/SQuirreL SQL Client/lib/oracle/” geschoben.

Das Startscript squirrel-sql.sh benötigt eine kleine Erweiterung:

# Squirrel home
SQUIRREL_SQL_HOME=’/home/stefan/SQuirreL SQL Client’

# stpe - Patch starts here
LD_LIBRARY_PATH=$SQUIRREL_SQL_HOME/lib/oracle:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

Die Bibliotheken aus der existierenden Oracle-XE-Client-Installation funktionierten mit den eben heruntergeladenen Jar-Dateien übrigens nicht, da diese in Version 10.2.0.3 vorliegen, das Debian-Paket des XE-Clients aber nur in 10.2.0.1 zu haben ist. Benutzt man die “alten” Libraries, stürzt Squirrel SQL reproduzierbar mit Fehlermeldungen, wie:

# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0×9e875776, pid=8838, tid=2677013392
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b22 mixed mode linux-x86)
# Problematic frame:
# C [libclntsh.so.10.1+0x327776]

ab.

In der Treiberkonfiguration des Datenbank-Tools trug ich die heruntergeladenen Jar-Dateien als alternativen “Class Path” ein:

Jetzt war der Treiber benutzbar, die damit angelegte Verbindung “jdbc:oracle:oci8:@ora_tst:1529/test” funktionierte fehlerfrei:

Vielen Dank von dieser Stelle aus nochmal an Marc, ich werde das Tool bei den nächsten Arbeiten am DBMS auf jeden Fall intensiver unter die Lupe nehmen.