lol terror

Uuuh, da ham’se ja wieder die ganz harten teuflischen Jungs zu fassen bekommen.
Die ham’ ne teuflische Bombe gebaut, aber das schlaue BKA hat da ja aus teuflischem Nitro Glycerin einfach teuflisches Mineralwasser gemacht und hat dann “chuhuhuhu” gelacht.

Klasse Arbeit, es wären bestimmt hunderte, wenn nicht tausende oder gar hunderttausende Unschuldige gestorben… an teuflischer Langeweile.

Und ganz großes Kino, dass der BKA Sprecher das ganze Schauspiel immer als einen “teuflischen Plan” betiteln musste. Den Sinn dahinter kann selbst der Ottonormalverbraucher gerade noch entschlüsseln. Aber danke für den Versuch.

Nitty Gritty: Konsolen, Terminals

Martin Ankerl vergleicht die Performance von verschiedenen Terminals.

Kein überraschendes Ergebnis: gnome-terminal ist das schnellste Terminal unter den getesteten.

Ebenso nicht verwunderlich: Windows’ cmd.exe liegt zusammen mit Putty recht weit abgeschlagen. SecureCRT wäre interessant zu testen gewesen, da die Anwendung ja als besonders flink verkauft wird.

Verwunderlich: Grafische Terminals sind schneller als Framebuffer. Hätte ich persönlich nicht gedacht, aber who cares 🙂 .
Klasse Sache, und bestätigt natürlich mein Nutzverhalten null, da ich eh auf gnome-terminal setze (zu faul für neue Shortcuts 😉 ).

WSDL + .net = Mach2

Egal wie sehr ich mich über .net manchmal aufrege, das Framework ist in vielen Hinsichten einfach genial einfach (wunderbares Konstrukt, oder?).

Wenn erstmal die Datenbankverbindung steht (das ist echt eine Qual), dauert die Umsetzung einer einfachen Abfrage nur 30 Sekunden und lässt sich dankbarerweise auch direkt im Browser testen. Auch die WSDL Beschreibungen werden direkt erstellt. Dann einfach C# anfeuern, WSDL als Webverweis importieren und man ist fertig.

Webservice in 3 Zeilen einbinden und abfragen:

UpdateAPI.Service UpdateServer = new UpdateAPI.Service();
UpdateAPI.UpdateInfo UpdateData = UpdateServer.Update_Check(“Acrobat Reader”, “8.10”);
textBox1.Text = UpdateData.ToString();

Alles vollkommen automatisch. Und dafür hab ich mich mit dem XMLTextReader rumgequält, wenn es doch in diesem Fall viel einfacher geht… 😉 .

Besonders schön: Ich kann dank Verwendung von C# auch wieder mit Structs arbeiten. Die somit erstellten Typen erscheinen auch in der WSDL Datei und somit konsequent auch im IntelliSense von VS.net. Erleichtert die Entwicklung erheblich und reduziert unnötigen Overhead an Zeitverbrauch nur für die Redefinition von toter Masse, die man bei der Entwicklung des Webservice eh schon geschrieben hat.

Mehr .net, mehr Linux, mehr Spaß

Habe ich schonmal erwähnt, dass in .net 1.1 zu entwickeln eine Qual und eine niederträchtige Heimsuchung ist?

Ich habe auf der Arbeit keine Rechte um auf meinen lokalen Webroot zu schreiben. “Okay”, dacht ich mir als Schönheit vom Lande, “schreibst du dir halt fix nen eigenen kleinen Server in .net, der nichts weiter tut als ASP.net Services zu pipen”. Also einen Vormittag lang untersucht wie das am Besten umzusetzen geht. Dann eine gute Lösung gefunden, die mir gefiel. Also dann, kleines HTTP Servergerüst geht ja fix… ja, ne. Eben nicht. In .net 2.0 geht es sehr wohl fix über System.Net.HttpListener. In .net 1.1 ist diese Klasse nur leider nicht verfügbar.

Von daher: Irgendwer erlöse mich von .net 1.1, es ist nicht das erste Mal in den letzten 3 Wochen, dass ich einen Schritt zu kurz gehe wegen den Unzulänglichkeiten.

In einer positiven Nachricht: Linux macht Spaß. Linux macht auch Spaß, wenn man 10 CDs durchprobiert (Ubuntu *g*), der Onkel Kasi sagt “Nehmt doch Debian, das geht”, am nächsten Tag mit Debian ankommt und – man staune – es geht einfach. Ubuntu – Linux for Human beings. Halt nicht wirklich für Leute, die tatsächlich damit arbeiten wollen. Jetzt hab ich den Spruch endlich verstanden.

So, das waren jetzt zwei der drei Punkte aus dem Titel. Was kann sich wohl unter “mehr Spaß” verbergen? Nun, erstmal kommt Samstag um 22:00 Uhr auf 3sat Hagen Rethers Programm “Liebe”. Das ist schonmal fckn rad. Aber der wirklich schöne Knaller ist das hier (sorry für die miese Qualität, ich muss Speicher sparen 😉 ). Seamless RDP mit Individual Window Support. Sogar Compiz wobbled die Fenster durch die Gegend. Als XP Pro Benutzer mit nur 1 RDP Session bin ich dankbar, dass die Modifikationen von Fontis auch mehrere Aufrufe über einen Channel zulassen. Und dann gibts noch Leute, die Citrix benutzen… Pff 😀 …

Crontabs und Ubuntu

Ubuntu ist teilweise der größte Müll. Das merkt man ganz einfach daran, dass Crontabs von Haus aus nicht per User funktionieren.

Die Dateien /etc/cron.allow und /etc/cron.deny existieren nicht…

sudo echo “tsukasa” >> /etc/cron.allow
sudo touch /etc/cron.deny
sudo dpkg-reconfigure cron

Erst danach kann man per crontab -e Usercrontabs erstellen, die auch tatsächlich ausgeführt werden.

Unnötig zu erwähnen, dass Debian dieses Problem nicht hat, oder? 😉

Liferea: xdg-open, tabs and tips (and a patch of course)

Im IRC kam der Vorschlag, dass Liferea doch xdg-open aus den xdg-utils benutzen könnte; ein Wrapperscript, das jeweils die bevorzugte Anwendung für einen Datei- oder URL-Typ des jeweils aktiven Desktop Environments (via gnome-open [GNOME], exo-open [XFCE], kfmclient [KDE]) benutzt. Die Idee ist sehr gut, denn obwohl manuelle Konfiguration möglich ist, wäre es schön, wenn ich z.B. automatisch Konqueror benutzen könnte, wenn ich es denn wollte… und nicht erst in den Einstellungen rumspielen müsste.

Theorie und Praxis treffen jedoch an irgendeinem Punkt aufeinander und man merkt, dass manche Dinge noch nicht ohne weiteres möglich sind. Im Falle Liferea zeigt sich das ganz banal am Fehlen von nötigen Parametern. Liferea supportet Optionen, welche festlegen wie ein Link geöffnet wird: In einem neuen Fenster, in einem neuen Tab oder in einem bestehenden Fenster. Dort die richtigen Parameter automatisch zu finden – bei der Fülle der möglichen Browser und auf Hinblick dessen, was xdg-open leisten soll: Unmöglich.

Nun jedoch grundsätzlich zu sagen “xdg-open ist minderwertig” wäre etwas verwegen, da – oh Schreck – auch gnome-open als Option in Liferea zu finden ist. Darum: Warum nicht auch xdg-open hinzufügen? Weder gnome-open noch xdg-open verstehen New Tabs, xdg-open versteht jedoch welchen Browser ich gerne hätte.

Argumente wie “du checkst ja garnicht, ob xdg-open überhaupt vorhanden ist” sind hinfällig: Nicht jedes System hat Opera, Netscape… et cetera. Wenn man wirklich mag, könnte man beim ersten Start überprüfen, ob xdg-open vorhanden ist – wenn ja wird es als Standard gesetzt. Klingt wie ein fairer Kompromiss, oder?

Darum: 2 Minuten Copy & Paste und fertig sind wir auch an dieser Front (bis auf das Überprüfen ob vorhanden oder nicht).

Apache2 als Schleuse

Tja, wer kennt das Problem nicht: Die meisten Proxies sind sehr lasch mit Port 80, aber bei Port 81 ist alles immer gesperrt.

Das ist unter normalen Umständen ganz egal, nur leider nicht, wenn der Entwicklungsserver auf den man zugreifen möchte, auf eben diesem Port 81 läuft. Wenn man aber eh schon Apache am laufen hat, kann man auch mit ein paar Zeilen in der httpd.conf den Server von Port 81 als Subdomain auf Port 80 laufen lassen:

<VirtualHost *:80>
ServerName subdomain.server.com
ProxyPass / http://interne.ip:80/
ProxyPassReverse / http://interne.ip:80/
ProxyPreserveHost On

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) http://interne.ip:80/$1 [P]
</VirtualHost>

Ja, das Ganze nutzt mod_proxy und mod_rewrite. Da der Proxyzugriff allerdings nur auf die interne.ip gestattet ist… naja, ist es relativ sicher 😉 .

Wie sagt man so schön? Not macht erfinderisch.

Maus- und Keyboardsharing mit Synergy

Ich arbeite momentan parallel mit einem Windows- und einem Linuxsystem. Es ist dabei unglaublich störend, dass ich zwei Keyboards und Mäuse auf dem Tisch liegen habe (Platzverschwendung, anyone?). Eine sinnvolle Alternative bietet Synergy.

Wer kennt nicht dieses dolle Programm von Stardock, mit dem man seine Maus und sein Keyboard zwischen mehreren Rechnern teilen kann? Leider ist dieses Programm a.) kommerziell und b.) nur für Windows verfügbar, was für mich also schonmal total nutzlos ist, da ich hauptsächlich mit Linux arbeite. Hier greift das OpenSource Programm Synergy ein, welches sowohl für Windows, Linux als auch OSX verfügbar ist.

Nutzer von Debian können sich Synergy mit apt-get install synergy auf die Platte lutschen, Windows- und Macuser machen irgendwas anderes.

Nehmen wir an, ich will meine Eingabegeräte vom Linuxrechner mit der Windowsmaschine nutzen:

Zuerst touched man sich lokal im Homeverzeichnis eine .synergy.conf

Die Datei wird dann mit folgendem Inhalt gefüllt:

 section: screens
undine:
salamander:
end

section: links
undine:
left    = salamander
salamander:
right   = undine
end

section: options
heartbeat       = 5000
switchDelay     = 500
end

Einfach, oder? Unter Screens werden alle Rechner angegeben, die mit einbezogen werden sollen (Server mit Keyboard und Maus natürlich nicht vergessen!). Bei Links wird die Reihenfolge der Screens angegeben. Die Optionen kann man auch weglassen wenn man mag, ich finde sie aber recht nützlich.

synergys -f –config ~/.synergy.conf startet dann den Synergyserver, sobald man Clients (Rechner ohne Eingabegeräte) verbunden hat, kann man die Screens wechseln. Einfach und idiotensicher.

Funktioniert klasse und ich kann es nur jedem empfehlen, der mehrere verschiedene, non-Xserver basierte Systeme bei sich laufen hat.

Spaß mit X – Xdmx

Okay, das ist weniger ein sinnvoller Post als mehr ein Braindump für mehrere kleine Parts, an denen ich mal angesetzt habe.

Xdmx ist ein X Proxy, der mehrere X Server von verschiedenen Rechnern bündelt und z.B. große Wallinstallationen erlaubt (oder halt tausend Monitore nebeneinander 😉 ).

In Ermangelung ständig verfügbarer, mehrerer Monitore darum nur ein kurzer Abriss für KDE Nutzer:

Ich finde es am sinnvollsten eine eigene xsession für Xdmx in /usr/share/xsessions anzulegen:

 [Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=/usr/bin/startdmxkde
TryExec=/usr/bin/startdmxkde
Name=Xdmx (KDE)

…die das kleine Shellscript aufruft:

 #!/bin/bash

startx `which startkde` –      \
/usr/bin/Xdmx :1      \
-display :0  \
-display 192.168.1.3:0 \
-display 192.168.1.4:0 \
-xinerama \
-ignorebadfontpaths        \

…welches KDE startet, den lokalen X Screen als Hauptscreen ganz links anordnet und dann die zwei anderen Screens der im Netzwerk befindlichen Rechner rechts danebenschaltet. Aus Performancegründen ist die Option für Xinerama negativ (-xinerama) und somit deaktiviert, wer es braucht kann natürlich mit +xinerama arbeiten. Sinnvolle Ergänzung zu diesem Setup wäre irgendwas in Richtung Chromium.

Mal schauen, wann ich wieder genug Monitore zusammen habe für den nächsten Testrun 🙂 .

Spaß mit X – ESD

Letztes Mal gabs die Basisportion X Spielerei. Wobei natürlich einige Punkte wie z.B. ssh -CY bewusst nicht behandelt wurden. Ich entschuldige mich, ja, man kann sich auch per ssh mit den Parametern -CY einloggen und dann einfach ohne weitere Eingaben X Anwendungen starten.

Aber darum geht es dieses Mal nicht. Seit Ewigkeiten hatte ich lokal den Artikel zum Thema ESD – Sound über Netzwerk herumliegen.

Continue reading Spaß mit X – ESD