Author: tsukasa

Es gibt noch mehr Experimente zum Thema Touchscreen. Und ich muss sagen: Es wird immer verlockender, sich sowas auch selber evtl. mal zu bauen…

Vielleicht sollte ich zum Wochenanfang noch ein paar Worte über Solaris und ZFS verlieren. Ich habe Samstag und heute sowohl mit ZFS Fuse als auch Solaris (Distro: NexentaOS) selber gespielt.

Ich sehe viele großartige Ansätze und Ideen; insbesondere zum Thema ZFS wird es in den nächsten Tagen nochmal einen etwas ausführlicheren Artikel geben, der die Konzepte etwas beleuchtet, die Einrichtung und Verwaltung am praktischen Beispiel aufzeigt und auch einige Fehler und Klippen in, ich mutmaße mal, der ZFS Fuse Adaption aufzeigen.

Zu Solaris selber kann ich leider noch nicht genug sagen, X.org, Bash, KDE… alles weder neu noch ein Problem für einen halbwegs geübten Pinguin. Ich muss schauen, ob die bis jetzt auftretenden Fehler tatsächlich auf Solaris selber oder eher auf die Distro zurück zu führen sind. Das Konzept der Zones finde ich zumindest mal absolut genial, das System fährt um Längen schneller hoch als es Debian tut — dafür zehnmal langsamer herunter. Die Liste der Software in Nexenta kann sich sehen lassen, viele alte Bekannte und neue Gesichter. Ich hätte mir jedoch gewünscht ein etwas “roheres” System zu haben, dass nicht den Ubuntupragmatismus des minimalen Klicks mit dem Alphasoftwareproblem des minimalen Erfolges verbinden. DPKG und Aptitude sind allerdings genau die richtige Wahl für ein Paketmanagement 🙂 .

Ansonsten bin ich stark beeindruckt von SUNs Technologien. Jonathan Schwartz Kampfansage an Linux ist kein leeres Versprechen, sondern sollte durchaus als Drohung wahrgenommen werden. Bis jetzt kann sich Linux einer gewissen Beliebtheit erfreuen, da es einfach einzurichten, einfach zu benutzen und einfach zu erweitern ist. Sobald die ersten polierten Solarisdistros erscheinen und “mehr” Software vollständig geportet ist (wobei das Groß sowieso schon vorhanden ist), ist Solaris für Linuxfreunde evtl. einer ernsteren Betrachtung wert. BSD Anhänger werden dem System vermutlich nicht viel Mehrgewinn abringen können; der *BSD Kernel enthält bereits viele der Technologien aus Solaris — einen Umstieg rechtfertigen die 2-3 Features dann nicht.

Das Ganze ist natürlich nur mein erster Eindruck. Ich kann vollkommen daneben liegen; der Wahrheit letzter Schluss liegt immer bei jedem selber und aufgrund von 2 Tagen Solarisnutzung ein finales Resume über das Pro und Contra zu ziehen halte ich für voreilig, wenn ich vorher 2 Jahre Linux benutzt habe.

Und so wird aus dem Wochenende der Wochenanfang und ich habe wieder viele Flausen im Kopf, was ich nochmal ausprobieren möchte/wollte/müsste/sollte…

Da probiere ich nach langer Zeit mal wieder verschiedene X Server für Windows aus, zum Teil auch kommerzieller Natur, und was sehe ich?

Xming ist immer noch der Beste.

X-Win32 hat mich am meisten enttäuscht. StarNet fällt bei Trayicons auf die Nase, Amarok erstellt nur einen Eintrag in der Taskleiste und das war es dann auch. Kein Fenster, kein nix.

Naja, was erwarte ich auch 😉 .

Mal fix nen Domaincontroller mit Samba hochgezogen (wenn man die Software eh installiert hat…), Windowsrechner in die frische Domäne reingehängt und dann dumm aus der Wäsche geschaut als ich die Gruppenrichtlinien aufgrund meiner mangelnden Konfiguration nicht setzen konnte. Ah ne, da war ja was…

Dafür gibts jetzt Log-on Scripte in VBScript (mit diesem Editor und etwas Vorkenntnissen aus meiner VBA-VBS-Ich-baue-mir-eine-Katastrophe Zeit einfach und intuitiv zu schreiben), zentralisierte Nutzerverwaltung (Logins gehen sowohl unter Windows als auch Linux, ist das mal Ownage?) und… ne, das wars eigentlich schon. Die Group Policies scheinen nicht zu funktionieren, die Samba Dokumentation gibt Aufschluss warum: Die Features sind experimentell und unvollständig.

Na gut, dann halt nötige Änderungen am All Users ausführen, alle Nutzer zurücksetzen, ausprobieren… und aufs Maul fallen. Die NT Groups sind nicht verfügbar, mein Domainadministrator darf nichtmal Media Player starten 😉 . Das ist so die Situation, wo ich von der Konsole doch gerne in eine GUI wechseln würde, und sei es nur um mal alle Optionen in geordneter Form auf einen Blick zu haben. Aber psst, das bleibt unser Geheimnis!

Es ist jedoch angenehm zu sehen, dass man solche vermeintlich zeitraubenden Stunts auch nebenher in 30 Minuten mal eben aus dem Kessel schütteln kann, wenn es tatsächlich gehen soll. Okay, ja… die Qualität meiner Einrichtung ist mies, aber es geht hier eher um die große Vision als das mickrige Ergebnis. Die SSH Seite funktioniert übrigens hervorragend. Linuxnutzer können sich problemlos mit den korrekten Rechten anmelden und haben dann “normalen” Zugriff. Also ists nur mickrig bei Microsoft; ein Umstand, den man sicherlich zum Teil auch selber mit zu verantworten hat.

Active Directory wird also weiterhin leben, Windows Server wird sich weiterhin verkaufen und ich habe gelernt, dass man für eine handvoll Rechner keine eigene Domäne braucht. Das wussten wir aber eigentlich alles schon vorher. Nullrunde halt; wozu ist Wochenende? 😉

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.

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

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.

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 😀 …

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? 😉

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

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 / //interne.ip:80/
ProxyPassReverse / //interne.ip:80/
ProxyPreserveHost On

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) //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.

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.

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

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