Software

If using terminal multiplexer screen, one can easily attach a session which is not detached with

screen -x

That way it is possible to attach the same session to multiple clients. By default you are able to view different screen windows per client which attached that session.

In tmux the default behavior differs. Though you can also attach the same tmux session to multiple clients e.g. with

tmux attach-session

it will let you view the same tmux window in all clients that attached that tmux session. When tmux instance starts it creates automatically one tmux session. Such a session is presented equally to every client.

Create independend tmux sessions for the same window set

A user creates a new tmux session with

user@clientA$ tmux new-session
## create some more windows
## work

The user decides to work with the same window set in another terminal independend:

user@clientB$ tmux list-sessions
0: 8 windows (created Tue Dec 13 20:55:56 2011) [136x49] (group 0) (attached)

user@clientB$ tmux new-session -t 0

That creates a new session which uses the same window set as group 0 listed above and attaches clientB to it. Two independent sessions working on the same set of windows are running. Very close to screen behavior.

Output of tmux list-sessions looks now like:

0: 8 windows (created Tue Dec 13 20:55:56 2011) [136x49] (group 0) (attached)
1: 8 windows (created Wed Dec 14 21:53:44 2011) [101x33] (group 0) (attached)

While attached to a tmux session tmux lets you change your session interactively with <C-b s>. Closing sessions is done e.g. by

tmux kill-session -t <sessionnumber>

To enable case insensitive token matching in Notion's menus like "Attach Window" (META-A) and "Go to Window" (META-G) add this line to any "dopathed" file in the notion configuration:

mod_query.set{ caseicompl = true }

That will save some time while navigating or layouting your workspaces.

Notion with case insensitive Goto-Query

Use case: You are using (La)Tex to create your document and include some big non-vector graphics or high-quality scanned documents via \includepdf{} from pdfpages package. You could resize/size-optimize your included parts one by one to make your resulting PDF document smaller. Or you could compile your document and then use a trick to reduce the size of the final compiled document as PDF at once:

That way I managed to reduce the document size from 22MB to 4MB. Of course, the effect depends on the material included in your document. Give it a shot.

Update (2012/01/20):

If the hint above is still not enough you might want to try to reduce the final size with gs via PDFSETTINGS option described in the Ghostscript Documentation:

-dPDFSETTINGS=configuration
 Presets the "distiller parameters" to one of four predefined settings:
   /screen selects low-resolution output similar to the Acrobat Distiller
           "Screen Optimized" setting.
   /ebook selects medium-resolution output similar to the Acrobat Distiller
          "eBook" setting.
   /printer selects output similar to the Acrobat Distiller 
          "Print Optimized" setting.
   /prepress selects output similar to Acrobat Distiller 
          "Prepress Optimized" setting.
   /default selects output intended to be useful across a wide variety of 
           uses, possibly at the expense of a larger output file. 

You can apply the desired parameter using ps2pdf:

ps2pdf -dPDFSETTINGS=/screen finaldoc.ps finaldoc_reduced.pdf

or gs:

gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite \
-dPDFSETTING=/screen -sOutputFile=finaldoc_reduced.pdf finaledoc.ps

Since it will lower the quality of the document it is advisable to check whether the document will still meet the requirements for the usage intended.

Some months ago Eclipse EE (Indigo) started to crash whenever Java EE view was active and I selected the menu entry "Window->Web Browser". Somewhere in the WWW I've found a solution by adding following lines into eclipse.ini:

Damit man im Vimperator gefühlt noch schneller browsen kann, die Scrollweite hochsetzen mit dem Eintrag in .vimperatorrc:

Vor einigen Tagen wollte ich größere Menge von restructured text Dokumenten (reST) nach Mediawiki Markup konvertieren. Eine Recherche ergab, dass es noch gar keine Werkzuege gibt, die das so machen, wie ich es haben wollte. Für sehr einfache reST Dokumente könnte sich Pandoc eignen. In vielen Fällen bei meinen Dokumenten, hatte es keine ordentliche Ausgabe hingekriegt.

Basierend auf Wikir (reST zu GoogleCodeWiki) und docutils habe ich einen Python-Skript geschrieben, der die Konvertierung so macht, wie ich es haben möchte. Bei Bedarf kann der Skript nicht nur reST nach Mediawiki Markup überführen, sondern auch das Dokument in eine minimale XML-Struktur "verpacken", so dass die Ergebnisse über die Import-Spezialseite importiert werden können. Der Code wird keinen Schönheits-Award gewinnen, seinen Zweck erfüllt er aber bei mir und, hoffentlich, kann es jemandem auf eine Weise behilflich sein.

Der Skript steht auf Github zur Verfügung.

Kurz der Stand der Dinge:

• reST nach GoogleWiki kennt:
• title
• code block
• strong + emphased text
• bullet + enumeration lists
• paragraph
• references
• reST nach Mediawiki kennt:
• title
• code block
• inline literals
• strong + emphased text
• image
• bullet + enumeration lists
• definition lists
• paragraph
• comment
• keine interne Links (todo)
• minimale XML-Struktur für Mediawiki-Import

Möglicherweise werde ich in der nächsten Zeit etwas verbessern, oder sogar, wenn ich Zeit finde, Mediawiki-Support im Wikir ordnungsgemäß einpflegen.

Anwendungsbeispiel

user@host $   cd /path/to/directory_with_rest_documents
user@host $   mkdir ../docs.mediawiki
user@host $   for i in *; do echo "processing '$i'"; /path/to/rest2wiki.py \
           -w mediawiki \
           -f "$i" > ../docs.mediawiki/"$i".mediawiki; done

Aufruf von rest2wiki.py -h listet weitere mögliche Argumente auf.

Vorschläge und Patches sind sehr willkommen.

Da ständig in #ion und #notion Leute nach dem Workaround fragen, wie man Flash-Videos im Vollbild unter ion3 anschauen kann, soll hier es kurz zusammengefasst werden, da über google man nicht sonderlich schnell eine kompakte Lösung findet.

Kurz zum Problem selbst: Flash-Videos (z.B. auf youtube) verlassen den Vollbildmodus seit Flashplugin-Version 9.x (?), wenn kurz nach dem Vollbildmodus-Aufruf der Fokus auf des Video-Fenster verschwindet. Resultat: keine Fullscreen-Flash-Videos für ion3-Nutzer.

Zumindest nicht ohne einem üblen Hack, den es hier zum Runterladen gibt (lokale Kopie). Diesen kann man direkt in cfg_kludges.lua oder in einer beliebige andere Datei, auf die dopath() angewandt wird, reinkopieren.

Nun muss man noch die Winprops korrigieren, damit die Workaround-Funktionen auf das richtige Fenster angewandt werden. Dazu muss man zuerst die class und instance des Fullscreen-Flash-Fensters rauskriegen. Dazu kopiert man diesen Lua-Snippet (hier gefunden) in ion's Lua-Code Prompt (Mod+F3):

ioncore.get_hook('clientwin_do_manage_alt'):add(
    function(cwin, table)
    ioncore.write_savefile("windowinfos", cwin:get_ident())
end)
 

Flash im Vollbildmodus aufrufen und die Ausgabe im ~/default-session-0/windowsinfos.lua betrachten. Die class und instance müssen in den zugehörigen cfg_kludges.lua übernommen werden (auch wenn da auf den ersten Blick etwas sinnloses wie "<unknown>" steht).

Falls man alles richtig gemacht hat und trotzdem keinen Erfolg hat, kann es durchaus helfen die Zahl in der Zeile

timer:set(200, function() cwin:goto() end)

zu erhöhen.

For the logs - heute aus Not kurz überlegt, wie man ein PHP-Skript eigentlich über cron laufen lässt, wenn das PHP-Skript Includes mit relativen Pfaden aufweist. Das Problem ist, dass crons Arbeitsverzeichnis nicht dem Verzeichnis des Skripts entspricht und die relativen Pfade somit auf Falsches verweisen.

Über Bash-Skript den Job zu wrappen wäre auch nicht das Wahre. Ein nahezu universeller PHP-Ein-Zeiler vor den Includes hat es getan:

#!/usr/bin/php
<?
chdir(dirname(__FILE__)); // <-- 
include_once("../../relative.php");
// ...
exit(0);
?>

Natürlich wäre in der crontab auch etwas wie

1 */30 * * * * user cd /pfad/zum/skript; php-skript.php

möglich, allerdings in anacrons cron.{hourly|daily|weekly|monthly}, in den man bequemerweise nur einen symbolischen Link zum Skript anlegt, ist so eine Anweisung nicht machbar.

Anmerkung: die Verwendung von chdir() Funktion kann problematisch werden, wenn "safe mode" gesetzt ist. Die Verwendung von "safe mode" ist aber seit PHP 5.3 sowieso als veraltet markiert.

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...

Pünktlich zu Ostern fand ich endlich eine praktikable Lösung für das Synchronisieren meiner Kontakte, Aufgaben und Termine zwischen meinen Linux-Rechnern und Windows Mobile 6 Gerät (HTC Artemis). Und das, ohne meine Termine den Datenkraken anzuvertrauen. Die (Er)Lösung hat einen Namen: Funambol. Funambol bietet Clients für

Desktop-Applikationen wie Outlook, Thunderbird (mit Lightning Extension), Evolution, iPod

Mobile Geräte, darunter Windows Mobile, Symbian, Blackberry und iPhone.

Eine Synchronisation zu Gmail, Yahoo und etlichen Groupware-Servern wird ebenfalls unterstützt.

Neben den Clients gibt es auch eine Serverinstanz (als Bündel samt nötigen JRE, Hypersonic DB, etc.) zum Download, die man auf einem beliebigen Rechner installieren kann. Auch Installation auf einem entfernten Server ist möglich.

Funambol Server (stand 8.0.2) auf Linux einrichten im Schnelldurchlauf:

Funambol Server von der Download-Seite runterladen.

Server Installieren mit:

Empfehlenswert - Rechte anpassen, so dass man den Server nicht als root laufen lassen muss.

Wenn nicht über Dialog der Installation bereits geschehen, Server starten:

Admin-Oberfläche starten:

Wenn entfernter Server, sollte man zuvor mit "ssh -X" einloggen um X an ssh-client weiterzuleiten. Auch möglich wäre Funambol lokal zu installieren und das Admin-Tool auf die Instanz des entfernten Servers zugreifen lassen (habe ich persönlich nicht getestet).

Im Admin-Tool einloggen mit Initialzugangsdaten admin:sa.

Admin-Passwort ändern und neuen (Synchronisations-)Benutzer anlegen.

Bei Unklarheiten evtl. doch die Server-Dokumentation heranziehen.

(Meine) Clients Einrichten

Auf alle Linux-Rechner Thunderbird mit Addon Lightning installieren. Für Thunderbird 3 gab es von Funambol noch keinen Stable Release des Mozilla Plugins, dennoch bin ich nach kurzem Stöbern auf einen Entwicklungs-Snapshot gestoßen, der nun bei mir ohne Probleme läuft.

Für Windows Mobile nahm ich den funambol-pocketpc-sync-client-8.0.4.cab Installer.

In allen Clients muss das Synchronisationskonto konfiguriert werden mit den Daten des auf dem Funambol-Server erzeugten Benutzers und außerdem muss der Serverpfad standardmäßig eingestellt werden auf:

http://ip.oder.domain:8080/funambol/ds

Defaultmäßig war unter Windows Mobile die Synchronisation von Aufgaben ausgeschaltet - evtl. anpassen. Fertig!

Kein Erfolg auf Debian 64 Bit

Ich hatte etwas Zeit zwei Tage damit verbracht Funambol 8.0.2 (stable) und 8.5 (snapshot, 64bit-version) auf einer 64-Bit-Debian-Installation zum Laufen zu bekommen, leider ohne Erfolg. Auch mit JRE 1.5 und 1.6 aus der Debian-Repository (mit und ohne ia32-sun-java6-bin) startete Funambol zwar, hängte sich aber auf (oder die JVM) und ließ sich nicht mehr mittels "funambol stop" stoppen. Erst mit SIGTERM terminierte der Prozess.

Auf dem Archlinux war die Installation in 10 Minuten erledigt - da habe ich aber gestaunt.

Frohe Ostern!

Für Leute, die auf mehreren Computern arbeiten und Lesezeichen verwenden, gibt es Firefox Addon Xmarks. Die Lesezeichen können auf zwei verschiedene Arten abgespeichert werden:

• auf Xmarks Server (Account nötig)
• auf eigenem Server mit Zugriff via FTP oder WebDav

Ich versuche es zu meiden meine Daten Dritten zu überlassen, deswegen habe ich mich für die zweite Möglichkeit entschieden. Zugegriffen werden soll über WebDav.

Gerade über ein echt nützliches Feature gestolpert in meinem geliebten Vimperator. Und zwar, sobald der Cursor in einem Textfeld ist, drückt man Ctrl-I und schon öffnet sich gVim um auf bequeme Weise Text zu erstellen. Nach dem schließen des Editors wird der Text in das Feld eingefügt. Außerdem kann man natürlich alle anderen Vorteile von gVim nutzen. Gerade bei größeren Texten ist es sehr angenehm: gVim legt für jeden Text jeweils eine Datei im /tmp Verzeichnis ab. Damit kann man bequem speichern, bevor man im Browser auf "Ok", "Abschicken", oder ähnliches geht. Denn wer kennt das nicht - langen Text geschrieben, möchte es nun absenden und es kommt etwas wie "Ihre Sitzung ist abgelaufen, bitte tun Sie dies und das" - Text geht so oft flöten, wenn die Seite nicht klug programmiert wurde.

Nun sind solche Probleme endlich Geschichte!

Dieser Artikel ist allen gewidmet, bei den Firefox nach dem Update auf Version 3.5 öfters auf Seiten mit Flash-Inhalten abschmiert.

Nach dem ich auf Firefox 3.5 gewechselt habe (Archlinux), musste ich mit zwei Problemen kämpfen:

• Firefox beendet sich ohne Fehlermeldung oder friert ein
• Firefox erzeugt 100% CPU-Last und reagiert dementsprechend langsam (auch ohne Flash, afaik)

Der Tipp den Flashplugin neuzuinstallieren half bei mir leider nicht und Gnash fand ich noch schlimmer als Flashplayer.

Wenn jemand einen Fuchs hat, der ebenfalls solche Symptome aufweist, soll einen einfachen Trick an ihm versuchen:

Datei pluginreg.dat im Firefox-Profilverzeichnis löschen.

Das Profilverzeichnis befindet sich normalerweise unter ~/.mozilla/firefox/. Einer der (möglicherweise) mehreren Ordner mit kryptischem Namen ist der Profilverzeichnis. Falls man nicht sicher ist, welcher von den es genau ist, einfach in allen Ordnern die genannte Datei löschen.

Keine Angst, die Datei wird wenn nötig von FF automatisch generiert.

Bei meinem Fuchs hat das "Wundermittel" sehr gut angeschlagen und ich kann nun unbesorgt wieder auf ihm im WWW rumreiten.

Viel Erfolg!

Update (22.08.09): Seit kurzem tauchten bei mir diese Symptome erneut auf. Deaktivierung vom Firefox-Addon "Noscript" behob das Problem.

Ich hatte heute die Gelegenheit mich etwas näher mit CSS zu beschäftigen und bin auf einen interessanten Aspekt gestoßen. Die meisten Hardcore-Webdesigner werden hier wohl keine neue Erkenntnisse finden, aber für den einen Gelegenheitscoder könnte dies durchaus nützlich sein.

Problem

Man hat drei verschiedene divs eingeplant, die gewisse Basiseigenschaften haben sollen, welche für alle drei divs gelten. Neben diesen "Basiseigenschaften" soll jeder div noch mit eigenen speziellen Style-Attributen versehen werden. Wie realisieren wir das? Gibt es Konflikte? Wenn ja, wie wird es gehandhabt?

Opera wird also 15. Als langjähriger Sympathisant von Opera möchte ich diese Gelegenheit nun als Anlass für diesen Artikel nutzen. Eigentlich verwendete ich es seit ca. 2 Jahren nicht mehr, genauer gesagt, seit dem ich das Firefox-Addons namens "Vimperator" entdeckt hatte. Bis zur letzten Woche - da fand ich nämlich eine Shortkeys-Konfigurationsdatei, das vim-Feeling nach Opera bringen soll. Das hat mich dazu bewegt Opera 9.64 noch eine Chance zu geben. Mit dem Opera Standard Slim Theme macht es "vimperopera" einem tatsächlich möglich ähnlich bequem wie unter Vimperator zu arbeiten.

Nein, es kommt auf keinen Fall an Vimperator ran, da es nur die primitivsten der primitiven Befehle abdeckt, lässt sich aber bestimmt gut als eine Vorlage für weitere Anpassungen nutzen. Dies soll aber auch nicht das Hauptthema des Artikels sein.

Insgesamt mein Ersteindruck von Opera:

- flott

- verbraucht weniger Speicher als FF3

- mit entsprechenden Cache-Einstellungen lässt Opera nicht bei jedem Seitenaufruf die Festplatte andrehen (im Gegensatz zu FF3 mit SQLite)

- im Zusammenspiel mit einer der vielen Blocklisten lässt sich der Werbespam auch in Grenzen halten

Als ein "Wiedereinsteiger" guckt man sich die Software von allen Ecken an. In der Rumklick-Orgie bin ich auf ein Feature unter "File"->"Synchronize Opera..." gestoßen. Na wenn das nicht vielversprechend klingt, gerade in den Zeiten von Mobile Computing!

Allerdings kam bald auch die Enttäuschung, weswegen ich eigentlich den Artikel schreibe.

Als ich den Account für dieses Feature anlegen wollte, musste ich zu meinem Bedauern folgendes im Lizenzabkommen lesen: