Linux

Ich musste heute bedauerlicherweise feststellen, dass Vims Syntax-Folding sowie die Klammernauflösung (und damit Funktionen von "%", "]}", etc.) unter Verwendung von bedingten Präprozessor-Anweisungen in C-Code gnadenlos versagen. Gerade wo der Code etwas unübersichtlicher wird, lässt Vim einen etwas im Stich, was die Navigation angeht. Hier ein einfacher Beispiel-Snippet, mit dem man das Problem reproduzieren kann:

for (i=0; i<somevar; i++) {
#ifdef SOME_PARAM
      for (k=1; k<limit_one; k++) {
#else
      for (k=1; k<limit_else; k++) {
#endif
      //do something
      }
}

In diesem Fall "weiß" Vim nicht, dass nur eine öffnende Klammer aus dem #ifdef-#else-Block von Bedeutung ist und macht stures Auflösen nach dem Schema "auf eine öffnende Klammer gibt es eine schließende" weiter.
Einen fertigen Workaround habe ich bisher nicht gefunden - schade...

In einigen Fällen laufen gleichzeitig mehrere Xsessions mit verschiedenen Benutzern. Oft ist das Problem bei Umgebungen ohne Soundserver wie Pulseaudio oder ESD, dass ein Benutzer das Ausgabegerät blockiert und andere somit ohne Audio-Wiedergabe zurecht kommen müssen. Auch falls ein Musik-Daemon wie MPD über eigenen Benutzer läuft, kann es mit dem Xsession-Benutzer eine Schlacht ganz nach "wer zuerst kommt, mahlt zuerst" um das Gerät geben.

Eine mögliche 3-Schritte-Lösung für ALSA setzt auf der Benutzung des dmix-Plugins auf:

Also, warum? Dieser Screenshot wurde an einem Intranet-Server mit Debian Stable als Betriebssystem erstellt. Auf dem Rechner laufen neben einer PHP-Seite noch etliche Plone/Zope-Portale. Man sieht die Uptime von 197 Tagen. Übrigens, das Ausrufezeichen neben Anzahl der Tage ist ein Easteregg in htop.

Die 197 Tage für einen Server (zumindest in der *nix-Welt, hehe) sind ja sicherlich mickrig, keine Frage. Aber dieser Rechner dient auch noch als meine (fast) alltägliche Workstation, auf der X-Applikationen wie Firefox, Thunderbird, Newsreader Pan, Eclipse und anderes kleineres Zeug laufen. Sogar die Verwendung propriäterer Software wie Skype war kein Hindernis für das Uptime. Alles funktionerte einwandfrei auch nach regelmäßigen Upgrades ohne Neustart des Systems. Ich weiß, so sollte es auch bei allen Distribution theoretisch "by Design" sein. Allerdings ist es in der Praxis nicht immer der Fall.
Sicherlich, kriegt man auch mit anderen Distributionen sogar höheres Uptime hin. Aber ich wollte es unbedingt in Verbindung mit Debian erwähnen.

Auf allen meinen privaten Rechnern benutze ich zur Zeit aus einigen Gründen kein Debian. Aber zugegebenermaßen bereue ich es ab und zu (gaaaanz selten ).


Dass Debian die erste Wahl für einen Server ist, weiß eh jeder und bedarf keiner Diskussion, denke ich.

Aber auch auf den Workstations hat Debian Stable seine Berechtigung, sobald man von der Feature-Geilheit loslässt.

P.S.: Hey, die Windows- und Mac-Benutzer haben auch keinen Rolling-Release und müssen sich bis zum Release Monate und Jahre gedulden, bevor sie neue Features kriegen!

Jeder, der sich schon mal eine Linux-Distribution auf einem Notebook installiert hat, kennt das Problem, dass die Hardware-Tasten nur mit (sehr) viel Glück out of the box laufen. Oft greift man dann auf Tools zu, die einen unterstützen, auf eine relativ bequeme Art, die Tasten zum Funktionieren zu bewegen.

Allerdings hat dieser Ansatz einen Haken: sie binden einen in den meisten Fällen an eine (und nur die eine) Desktop-Umgebung, sei es Gnome, Xfce, KDE oder was auch immer.
Eigentlich ist es ein Problem nur für die Wenigsten. Und zwar nur für die, die mehrere Desktop-Umgebungen nutzen. Ich z.B. nutze, je nach dem was ich vor habe, Gnome oder ion3.

Nun hat man die Wahl, ob man für jede Umgebung eigene Konfigurationen bzgl. der key bindings oder sich die Mühe macht das ganze DE-unabhängig zu machen.
In diesem Artikel werde ich versuchen zu beschreiben, wie ich meine Hardware-Tasten auf einem x41t DE-unabhängig an Operationen gebunden habe.