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:

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

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

gelangt man an die Information.

Vollständigen Beitrag lesen

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

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

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:

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

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

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

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

Versucht man nach der Installation ein paar der GNOME-Pakete (wie z.B. Evolution) loszuwerden, verunsichert apt mit dem freundlchen Hinweis, daß man mit diesem Schritt auch gleich die Pakete “gnome” sowie “gnome-desktop-environment” entsorgt:

Was auf den ersten Blick gefährlich aussieht, ist auf den zweiten Blick glücklicherweise harmlos, handelt es sich bei den beiden Paketen doch um sogenannte Metapakete, was auch erklärt, warum diese bei der Deinstallation eines ihrer Teile gehen müssen.

Gefährlich wird es erst nach der Deinstallation, denn dann meint apt jedesmal, etwas autoremove wäre angebracht:

und schlägt gleich noch vor

Wer sich auf den hilfreichen Hinweis verlässt, steht anschließend tatsächlich ohne Destktop da, denn u.a. ist in der obigen Liste auch das Paket “gnome-core” zu finden, ohne das wieder Tipparbeit am Terminal angesagt ist.

Sicherlich kann man einfach darauf verzichten, apt-get autoremove auszuführen - sicherer ist aber ein

das die aktuell installierten Pakete alle in die Rubrik “will ich behalten” einsortiert.