Möchte man einen bestehenden User auf einem Ubuntu System eine weitere Gruppenzugehörigkeit spendieren, so geht das auf 2 verschiedene Arten.

1. adduser <username> <groupname>
2. usermod -a --groups <groupname> <username>

Der Befehl der ersten Variante ist eher von High-Level Natur, der zweite hingegen von Low-Level. Gerade hier muß man aufpassen, dass der Parameter -a (append) gesetzt ist, sonst wird mit diesem Befehl die bereits bestehenden Gruppenzugehörigkeiten gelöscht!
Dies fällt überlicherweise auch erst nach einem Relogin auf.

Beim Starten eines Rechners passierte jahrelang ein komische Sache, die ich erst jetzt – bedingt durch einen Anfängerfehler – auf den Grund gehen musste.

Direkt nach dem Start meldet sich wie üblich das BIOS.. und hat keinerlei Probleme mit der USB-Tastatur.
Danach die Übergabe an den GRUB Bootloader – der auf einmal keinerlei Tastatureingaben mehr entgegennimmt. Bei der finalen Übergabe an das Betriebssystem (Ubuntu Linux, openSUSE Linux) wird die Tastatur wieder erkannt

Offengestanden habe ich aus Zeitmangel die eigentlich Ursache, oder das Zusammenspiel der Komponenten im Hintergrund nicht recherchiert, hier ist aber die Abhilfe an meinem System:

Im BIOS (Phoenix BIOS) die Option Enable Legacy USB im Menu Advanced aktiviert!

Beim Standarddateimanager von Ubuntu 12.04 Nautilus kann man in der Seitenleiste bekanntlich Lesezeichen (bookmarks) anlegen, deren Name und Zielverweis wählbar ist.

Voreingestellt sind unter der Rubrik Rechner bereits ein paar Ordner, bspw. Dokumente, Bilder, Musik, Videos. Das Zielverzeichnis dieser Einträge lässt sich in Nautilus selber nicht ändern.
Die Zielverzeichnisse holt sich Nautilus – wie auch andere Programme – vom Desktop-übergreifenden Projekt freedesktop.org, welches die Einträge in folgender Datei ablegt.

$(XDG_CONFIG_HOME)/user-dirs.dirs

also im Normalfall

~/.config/user-dirs.dirs

Dort ändert man bspw. das Verzeichnis für XDG_DOWNLOAD_DIR um das Zielverzeichnis für den Download-Ordner zu ändern.

Selten tritt im QtCreator ein merkwürdiges Phänomen auf. Man fügt im Optionen Dialog eine neue Qt Help Project Datei (*.qch) hinzu und die darauf hin automatisch startende Indizierung bricht sofort (klanglos) ab.
Man merkt den Effekt natürlich im Suchfeld, denn eine Volltextsuche auf diese Hilfe liefert keine Ergebnisse zurück

Den eigentlichen Fehler kann man nur entdecken, wenn man QtCreator auf der Kommandozeile startet – dann erscheint in diesem Fall

virtual void fulltextsearch::clucene::QHelpSearchIndexWriter::run() : Failed because of CLucene exception.

Einzigste mir bekannte Lösung ist das Erzwingen einaer Neuindexierung aller Files – durch ein löschen des Index Ordners
~/.config/<Qt-Eigentümer>/qtcreator/.qhelpcollection

<Qt-Eigentümer> muss natürlich durch “Digia” oder “Nokia“, ev. “Trolltech” ersetzt werden. Das kommt darauf an, wann der Basisordner erstmalig erstellt wurde.

Manchmal liegen Programme in verschiedenen Versionen vor und verlangen nach einem Ansatz der es erlaubt die verschiedenen Versionen relativ einfach zu starten.
Eine Möglichkeit ist es die PATH Umgebungsvariable so zu setzen, dass mehrere Verzeichnisse die das Programm beinhalten gelistet sind, z.B.

PATH=~/binNeu:~/binAlt

Ein fikives Programm testMe ,würde nun aus ~/binNeu starten. Wenn man nun temporär dieses Verzeichnis umbenennt, sollte testMe aus ~/binAlt gestartet werden.
Tatsächlich wird das auch vom which Kommando so angezeigt. Bei der Ausführung von testMe, gibt die bash erstaunlicherweise die Fehlermeldung aus, das ~/binNeu/testMe (!) nicht gefunden wird.

Grund dafür ist eine Cache-Hashtable welche die bash am Anfang anlegt um einen Programmstart zu beschleunigen. Und genau diesen muss man in diesem Fall mit folgendem Kommando löschen.

hash -r

Alternativ könnte man auch das File sourcen, welches direkt oder indirekt die PATH Variable setzt, oder schlicht die bash schließen und neustarten.

Manchmal möchte man auch ein spezielles Paket schnell einspielen oder deinstallieren – ohne Rücksicht auf die vorhandene SW Repository Struktur.
Ehrlicherweisse muß man dazu sagen, dass dieser Ansatz immer mehr an Bedeutung verliert, da diese Aufgabe einerseits von den (High-Level) Paketmanagern ebenso übernommen wird und andererseits schlichte grafische Frontends (im Dateimanager integriert) diese Aufgabe auch schnell meistern.
Wie auch immer, Ubuntu schickt dpkg für die Low-Level Aufgabe ins Rennen, während openSUSE rpm benutzt. Hier ein Vergleich der Systeme:

Hier geht kein Programm als Sieger vom Platz. Persönlich gefällt mir die Ausgabeformatierung von rpm meistens besser.
Andererseits scheint es so, dass dpkg manchmal filigranere Optionen anbieten. Beim Löschen eines Packages bspw. unterscheidet dpkg die Option -r (remove) welche nur die installierten binaries löscht (Paketstatus ist immer noch vorhanden: un) und die Option -p (purge) welches auch die vorhandenen Konfigurationsdateien löscht und damit das Package vollständig löscht.

Die Installation/Deinstallation von Softwarepaketen unter Berücksichtigung von Abhängigkeiten zu anderen Paketen erfordert nicht nur ein simples Paketinstallationsprogramm auf unterer Ebene (Low Level) sondern ein Paketmanagementsystem auf oberer Ebene (High Level), welches die verfügbare Software mit Hilfe sog. Software-Repositories.
Ubuntu schickt dafür apt ins Rennen, während openSUSE zypp benutzt. Hier ein Vergleich der Systeme:

Beim Vergleich der zwei Paketmanagementsysteme gewinnt zypp.
Es liegt nicht nur am größeren Befehlssatz – bei apt muß man teilweise mangels Befehle direkt in den Konfigurationsdateien editieren – es ist auch die vorbildliche tabellarische Ausgabe die sich positiv von apt absetzt.

Paketscheine von Hermes bspw. enthalten immer einen Barcode.

Leider wird dieser nicht immer korrekt ausgedruckt, sondern teilweise punktiert – also völlig unbrauchbar – ausgedruckt.
Zuerst hatte ich CUPS, bzw. die Treiber/Filter im Verdacht. Tatsächlich scheint es aber an den Programmen zu liegen.

Korrekt ist der Ausdruck eigentlich nur in folgenden Kombinationen:

Adobe Reader 9 unter Linux (Farbe oder SW egal)
Adobe Reader 11 unter Mac OS X (nur mit der Option “In Graustufen (SW) drucken” des Adobe-eigenen Druckerdialogs)

Überhaupt nicht – unabhängig von der Einstellung Farbe/SW – funktioniert es mit:

Okular unter Linux
Evince unter Linux
Mac OS X Vorschau (10.6.8)

Warum das so ist? Ich weiß es zumindest derzeit nicht.
=> Jetzt weiß ich es! Siehe Kommentar #1

Was tun wenn eine ext2-formatierte truecrypt Partition repariert werden muss? Praktisch kann das schnell der Fall sein, wenn z.B. das Filesystem nicht mehr sauber ist und mittels Ext2FS für Mac OS X (Paragon) eingehängt wird.

Dann muß unter Linux e2fsck (fsck.ext2) ran, bspw.

e2fsck -a /dev/mapper/truecrypt1

D.h. der Befehl wird nicht auf die Partition selber, sonder auf den dm-Container ausgeführt. Das bereinigen der Partition funktioniert aber nur zuverlässig, wenn beim truecrypt mount unter “Optionen” die Checkbox “Do not mount” angehackt ist, d.h. der eigentliche Inhalt des dm-Containers wird unter keinem Mountpoint (normalerweise /media/truecrypt1) angelegt, trotz aktiviertem dm-Container.

Mir ist es jetzt schon zweimal passiert, dass die Clients untereinander die Synchronisation entweder komplett eingestellt haben oder nur noch teilweise Kalendereinträge anzeigten. Was war passiert?

Beim ersten Fall hatte ich in Mozilla Lightning einen Kalendereintrag mit einer speziellen (customized) Wiederholungsregel angelegt (letzter Mittwoch im Monat). Das schmeckt dem iOS Kalender (egal ob Version 4.x oder 5.x) gar nicht – genauso wenig wie dem Programm iCal (3.x) unter Mac OS X (Snow Leopard). In diesem Fall blieb mir nichts anderes übrig als auf diese Wiederholungsregel zu verzichten.
Darauf gekommen bin ich relativ schnell, da ich einfach die letzten Einträge die ich vorgenommen habe sukzessiv zurückgenommen habe.

Der zweite Fall war etwas schwieriger. Am Sonntag erzeugte ich noch munter Einträge (3 Wochen im Voraus) in Mozilla Lightning, alles ok. Beim Blick auf den iOS Kalender fiel mir nichts auf – ich hatte aber eh nur die momentane Woche in Beobachtung.
Das Problem bemerkte ich später wiederum an Lightning, der jetzt einige Einträge gar nicht mehr anzeigte – auch der laufenden Woche. Ausserdem waren die Einträge die ich am Sonntag vornahm, weg (die übrigens im iOS Kalender gar nicht auftauchten).
Was war den hier passiert? Eine Beobachtung des Apache Log ergab, dass sehr wohl alle Kalenderänderungen mit
"PUT /davical/caldav.php/<myCalender>/<current-ID.ics> HTTP/1.1 ..."
immer noch übertragen werden. Einträge löschen wurde übrigens noch sauber synchronisiert. Eine erstmalige Synchro auf einem Mac OS X Rechner mit iCal schlug fehl, nichts wurde übertragen.
Die Lösung brachte eine erstmalige Synchro mit dem KDE Kontact Kalender – der holte alle (auch die verschwundenen) Einträge hervor und zeigte sie an. Und in einem, der am Sonntag angelegten Einträge, befand sich im Beschreibungstext ein Sonderzeichen (falsche Kodierung), welches mit Copy/Paste von einem Webartikel reinkopiert wurde. Nachdem ich das Zeichen entfernte, klappte die Synchro anstandslos auf allen Clients. Daher kann ich nur empfehlen keine Texte aus einer Quelle zu kopieren, bei der die Zeichensatzkodierung nicht mit dem des Kalender-Clients übereinstimmt. Gerade auf Webseiten ist die Kodierung oft sehr unterschiedlich.
Die fast noch wichtigere Erkenntnis ist, dass schnelles Fehlertracking nicht mit einer SW Monokultur zu schaffen ist. Je heterogener die SW Landschaft (Clients) ist, desto robuster läuft der Netzwerkdienst.