Wenn man unter Debian das Paket “sun-java6-jre” installiert hat, meldet sich anschließend nach einem “java –version” immer noch

java version "1.5.0"
gij (GNU libgcj) version 4.3.2

Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

statt dem eigentlich erwarteten JRE. Damit das funktioniert, hilft ein

update-alternatives --config java

mit dessen Hilfe man die Möglichkeit hat, die gewünschte Java-Installation zu wählen. Anschließend spuckt “java -version” das gewünschte

java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

aus.

Das Einspielen der Critical Patch Updates (CPUs) in eine Oracle-Datenbank erfolgt mittels des Oracle-eigenen Utilities “OPatch”, welches standardmäßig im Verzeichnis “$ORACLE_HOME/OPatch” zu finden ist. Eine Übersicht der Funktionsweise und Bezugsquellen von OPatch findet sich in der “OPATCH FAQ” im Oracle Metalink.

Grundlegende Informationen zur eingesetzen Datenbank lassen sich im laufenden Betrieb über eine einfache SQL-Abfrage ermitteln:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Solaris: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

Eine Auflistung aller bisher einsgespielten Patches gibt es über den Befehl

opatch lsinventory

ermitteln, der aber leider nur die Patch-Nummern, nicht aber die Klartextnamen (wie z.B. “CPU April 2008”) ausgibt. Wer nur die letzte große Änderung an seiner Datenbank wissen will - mittels einer SQL-Abfrage wie

SQL> select action_time, comments, id from dba_registry_history;

ACTION_TIME                   COMMENTS                    ID
------------------------------------------------------------
20-JUN-07 02.31.54.218693 PM  CPUApr2007             5901891

gelangt man an die Information.

Weiterlesen

Nachdem jahrelang eigentlich alles wunderbar funktioniert hat, streikt nach einer Neuinstallation von Debian der Sound auf meinem Asus L8400C. Zwar findet ‘alsaconf’ die richtige Karte und trägt das richtige Modul ein, anschließend erscheint aber ein ernüchterndes

Loading driver...
Setting default volumes...
amixer: Mixer attach default error: No such file or directory
Saving the mixer setup used for this in /var/lib/alsa/asound.state.
/usr/sbin/alsactl: save_state:1497: No soundcards found...

auf dem Bildschirm, so daß man das anschließende

Now ALSA is ready to use.
For adjustment of volumes, use your favorite mixer.

Have a lot of fun!

nicht so wirklich ernst nehmen sollte. Ein Blick in die Ausgabe von ‘dmesg’ bringt glücklicherweise einen Fingerzeig in die richtige Richtung, nämlich daß mit der Firmware für das Sounddevice irgendetwas faul ist:

[  542.091061] firmware: requesting ess/maestro3_assp_kernel.fw
[  542.172605] ACPI: PCI interrupt for device 0000:00:06.0 disabled
[  542.172605] Maestro3: probe of 0000:00:06.0 failed with error -2

Da es auf den Debian-Servern keine neuere als die installierte Version des Firmware-Paketes gibt, ist Herunterladen des aktuellen alsa-firmware-Pakets von den Seiten des Alsa-Projects sowie der anschließende, altbekannte Dreisatz

./configure
make
sudo make install

gefragt, nach dem ‘alsaconf’ zwar immer noch über eine nicht gefundene Soundkarte meckert (liegt wohl an der Debian-Verzeichnisstruktur), ein Blick auf ‘dmesg’ aber nur noch

[ 2809.890462] firmware: requesting ess/maestro3_assp_kernel.fw
[ 2809.960641] firmware: requesting ess/maestro3_assp_minisrc.fw

ausspuckt und der anschließende Hörtest ebenfalls positiv ausfällt.

Will man die Installationsaufforderung für Plugins im Firefox loswerden, so gibt es hierfür leider keine Einstellung in den “Einstellungen”.

Stattdessen kann man aber nach Eingabe von “about:config” in der Adressleiste den Wert von “plugins.hide_infobar_for_missing_plugin” auf “true” setzen.

Sollte der Versuch ein Modul mittels ppm zu installieren mit einem “ppm install failed: Can’t find any package that provide perl for [Modulname]” quittiert werden, so lohnt sich meist ein Blick in die zugehörige ppd-Datei. Dort ist im Normalfall eine Zeile wie

<REQUIRE NAME="perl" VERSION="5.004" />

zu finden, die das Problem verursacht und nach deren Löschung die Installation problemlos gelingt.