everflux

Bei Ubuntu wurde der Bereich zum „Anfassen“ der Fensterrahmen auf sagenhafte einen Pixel verkleinert – möchte man ein Fenster nun breiter ziehen muss man schon gut zielen.

Komfortabler geht das derzeit lediglich, wenn man über eine Maus mit drei Tasten verfügt (oder die mittlere Taste simuliert): Hält man die „Alt“ Taste fest, kann man mit der mittleren Maustaste quasi beliebig ins Fenster klicken, und die Größe anpassen. Das ist am Anfang etwas ungewohnt, geht jedoch sogar noch schneller als erst den Fensterrahmen anzusteuern – selbst wenn dieser etwas breiter ist (oder wieder wird).

Schon seit einem guten Jahr nutze ich das US Tastaturlayout unter Ubuntu als Standardlayout. Gerade zum Entwickeln konnte ich wegen der besseren Position von Semikolon und geschweiften Klammern schnell einen Produktivitätsgewinn feststellen.

Doch dann kamen auch die Rückschläge: Euro Zeichen, Paragraphenzeichen (§) und Umlaute sind nicht mehr verfügbar. Für Umlaute behelfen sich einige mit Unicode Eingabe, oder Copy-Paste-Vorlagen. Ich habe mir bisher damit geholfen, dass ich die Rechtschreibkorrektur einfach „ue“ in „ü“ habe umwandeln lassen. Hilft jedoch nicht z.B. beim „§“-Zeichen.

Und da habe ich jetzt das Feature „Compose Key“ gefunden. Damit kann man – fast wie bei LaTeX – Buchstaben zusammensetzen. Dazu aktiviert man erstmal die Einstellung ein „Compose Key“ auf der Tastatur zu haben, ich habe dazu die rechte Alt-Taste verwendet. (System->Preferences->Keyboard, Layout auswählen, „Options“)

Anschließend kann man mittels <compose>-<u>, und <„> ein „ü“ zusammensetzen. Das Paragraphenzeichen geht z.B. über <compose>-<s>, <o>

Nicht immer genuegt es, wenn man ein Servlets auf andere Pfade oder Patterns mappt, manchmal möchte man bereits auf den Context Root ein Servlet mappen. Der übliche Work-Around sieht so aus, dass man bspw. in einer „index.jsp“ einen redirect auf eine tatsächlich einem Servlet zugeordnete URL (über den Pfad oder Datei Extension) macht, das könnte so aussehen:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:redirect url="/myServlet"/>

Das ist aber nicht immer praktikabel – nun soll es darum gehen ein Servlet direkt auf den „/“ Pfad zu mappen – dafür gibt es mehrere Möglichkeiten:

1. Das Default Servlet ersetzen, dazu wird auf den Root Pfad „/“ in der web.xml ein Mapping angelegt:
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
2. Ab Servlet Spezifikation kann auch ein Servlet in der welcome-file-list in der web.xml gemappt werden:
   <welcome-file-list>
<welcome-file>myServlet</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Im folgenden beschreibe ich die Vor- und Nachteile der verschiedenen Ansätze, und welche Erfahrungen ich mit verschiedenen Web Containern dabei gemacht habe. Weiterlesen »

Nachdem für Ubuntu Intrepid der Support ausgelaufen ist, blieb nichts anderes übrig: Ein Upgrade auf Lucid ist nötig, um weiterhin Sicherheitsupdates für Ubuntu zu bekommen. (Und wann hat man dazu schon so gut Zeit, wie zu Weihnachten…)

Nach einigen Zwischenstationen über u.a. Jaunty und Karmic samt Kernel Oops wegen ACPI und APIC Problemen auf dem alten Nvidia Board war dann endlich Lucid auf der Platte. Allerdings ohne AVM Fritz Treiber – AVM hat den Support eingestellt und es gibt (natürlich) keine OpenSource Treiber. Glücklicherweise gibts im Ubuntuusers-Wiki eine wunderbar funktionierende Anleitung. Für Ubuntu Lucid habe ich folgende Schritte durchgeführt (die Build Abhängigkeiten waren noch von Intrepid vorhanden)

wget https://belug.de/~lutz/pub/fcpci/fritz-fcpci-src-2.6.31_untested.tar.bz2
tar -jxf fritz-fcpci-src-2.6.31_untested.tar.bz2
cd fritz-fcpci-src-2.6.31_untested
make clean
make all
mkdir /lib/modules/`uname -r`/extra
cp fcpci.ko /lib/modules/`uname -r`/extra/

Die letzten beiden Schritte werden wohl nach jedem Kernel Update faellig. In der /etc/modules steht das fcpci Modul noch drin, so dass es beim Systemstart automatisch geladen wird.
Danke an Lutz Willek dem wir das gepatchte Paket zu verdanken haben.

Für Asterisk und Capi sollte das Ubuntu Paket asterisk-chan-capi den entsprechenden Channel fuer Asterisk bereitstellen. Leider ist in Lucid 10.04.1 das Paket defekt, es wurde mit anderen Compileroptionen übersetzt als Asterisk und kann daher nicht geladen werden.
Ein einfacher workaround sieht so aus:
apt-get install asterisk-dev
apt-get source asterisk-chan-capi
cd asterisk-chan-capi-1.1.4
dpkg-buildpackge -b
cd ..
dpkg -i asterisk-chan-capi_1.1.4-1_i386.deb

Das Asterisk Capi Channel Modul sollte in /etc/asterisk/modules.conf unterhalb von res_features eingetragen werden, z.B. so:

load => res_features.so
load => chan_capi.so

Danach muss Asterisk noch neu gestartet werden.

Ubuntu eignet sich hervorragend als Entwicklungsumgebung für Java Anwendungen. Sei es auf dem Desktop oder auf dem Server, bei Ubuntu bekommt man ein aktuelles Sun JDK oder OpenJDK, einen planbaren Releasezyklus. Auch ist ein Unix-artiges Betriebssystem in meinen Augen zum Arbeiten angenehmer als z.B. Windows.

Hat man auf einem entfernten Server, der aber per Netzwerk (oder VPN) erreichbar ist, einen Java Applikationsserver, wie z.B. Glassfish, laufen, so bietet sich JMX zum Monitoring und Management an. Besonders die „VisualVM“ Anwendung macht die Arbeit dabei sehr leicht und übersichtlich. Der Start erfolgt einfach per „jvisualvm“, anschließend können lokale Anwendungen sofort analysiert werden, für entfernte Rechner ist eine JMX Verbindung erforderlich.

Für VisualVM gibt es auch ein Plugin für Glassfish, dies kann über „Tools -> Plugins“ installiert werden. Danach fügt man den entfernten Host hinzu, hier kann man den Hostnamen oder eine IP Adresse eintragen: Weiterlesen »

Ich wollte eigentlich nur etwas ganz simples: Continuous Deployment. Das ist der neueste Trend nach Continous Integration habe ich mir sagen lassen. Und gerade wenn man in einem Team arbeitet ist es schon vorteilhaft, wenn man einen stabilen Build staendig deployt hat.

Hudson ist mein bevorzugter Buildserver (auch wenn Bamboo wirklich ansprechender ist, aber eben auch eine Ecke teurer und nicht OpenSource) – und es gibt auch ein Plugin fuer Hudson, mit dem man ein Deployment anstarten kann: http://wiki.hudson-ci.org/display/HUDSON/Deploy+Plugin
Leider funktioniert das bei dem Glassfish nicht, wenn Hudson nicht auf dem selben Server läuft, wie der Glassfish. (Das sollte/dürfte der Regelfall sein.)
Weiterlesen »

Immer wieder werde ich gefragt: Wie geht ein Youtube Download? Der Hintergrund: Nicht immer kann man Videos in Echtzeit abrufen, manchmal ist aufgrund einer längeren Reise oder anderen Gründen keine Internet Versorgung vorhanden. Youtube Videos zu speichern, wenn man sowas absehen kann, lohnt also. (Was rechtliche Aspekte angeht, bin ich jedoch überfragt, ich gehe davon aus, dass es in Deutschland legal ist – wir zahlen ja dafür Urheberrechtsabgaben auf alle Speichermedien  und PCs –  aber sicherlich in mindestens einem Land der Welt verboten ist.) Weiterlesen »

Firefox ist an sich ein recht ordentlicher Browser. Die Zeiten in denen er in Punkto Geschwindigkeit und „Schlankheit“ ganz vorne war, sind allerdings vorbei. Aber damit koennen viele gut Leben – Firefox ist recht stabil, die Geschwindigkeit ist auch nicht schlecht und vor allem die Flexibilitaet dank der beinahe unendlichen Fuelle an Erweiterungen (Extensions / Add-Ons) machen den Firefox Browser attraktiv.

Dabei spielt es keine Rolle, ob es um Entwickler geht, die Firebug mit den dafür ebenfalls verfügbaren diversen Erweiterungen nutzen, oder den Gelegenheitssurfer der dank Adblock-Plus schneller und weniger genervt das Internet konsumieren kann. Für andere Nischen und spezielle Bedürfnisse gibt es ebenso viele Plugins von „Spass“ bis „Produktivität“ ist alles vertreten.

Jedoch wuchs der Neid bei mir wenn ich auf Chrome / Chromium blickte – ich wollte Firefox auch etwas schneller haben. Bekannt für Nachteile bei der Performance sind eben gerade jene Erweiterungen, die einem das Leben so schön erleichtern. Also habe ich einige deaktiviert, es wurde in der tat etwas schneller. Damit war das erledigt. Erfolg!

Bis mir auffiel, dass irgendetwas nicht stimmte. Bei Downloads verschlang Firefox immense Mengen an Speicher – ein Vielfaches dessen, was die Datei selber haben würde. Und auch die CPU Belastung, vor allem bei Downloads, wuchs dramatisch.

Erst hatte ich das Flashplugin in Verdacht – in der Regel trifft man damit den Richtigen, genauso wie pauschal auf Windows schimpfen. Aber daran lag es nicht, ich hatte extra keine Flash Seiten aufgemacht.

Erst als ich alle von Firebug abhaengigen Erweiterungen (und nicht nur Firebug selber) deaktiviert hatte, sowie TamperData und LiveHttpHeaders war endlich alles wie es sein sollte. Firefox brauchte weder Unmengen an Memory noch ging die CPU Last bei Downloads in die Höhe. Welches Plugin tatsächlich verantwortlich war, habe ich nicht mehr untersucht. Vermutlich ist es nicht gut, wenn man Plugins, die Firebug benötigen, aktiviert lässt, aber Firebug selber deaktiviert.

Um mir Arbeit zu sparen (wer moechte schon immer alle Erweiterungen ein- und ausschalten) habe ich mir mittels eine zweiten Firefox Profils das Leben leichter gemacht: Es gibt jetzt ein „dev“ Profil für Entwicklung, da ist dann alles aktiviert, dass sich der Web-Entwickler wünscht. Daneben sind auch deutlich weniger, bzw. andere Bookmarks gesetzt: „Führe mich nicht in Versuchung“.

Um den Entwicklungs-Firefox zu starten, habe ich mir eine zusaetzliche Verknuepfung (mit Werkzeug-Symbol) in der Ubuntu Linux Taskbar angelegt, diese ruft folgendes Kommando auf:
firefox -no-remote -P dev

Mittels „-P“ kann man das Profil auswählen, welches verwendet werden soll, das „-no-remote“ verhindert, dass bei einer bereits gestarteten Firefox Instanz (z.B. des default Profils) lediglich ein neues Fenster aufgemacht wird.

Probiert es mal aus – Kommentare und Feedback erwünscht!

Ubuntu ist für mich das Arbeitstier schlechthin – mit keinem anderen Betriebssystem würde ich derzeit längere Zeit arbeiten wollen. Auch wenn ein kleiner Blick gen OpenIndiana schweift – an OpenSolaris habe ich immer bewundert, wie gut sich das System unter Last noch anfühlt. Genau das vermisse ich bei Ubuntu: Wenn ein Maven-Build läuft, Netbeans meint es müsse mal wieder tüchtig scannen oder ich dabei noch ein paar Kleinigkeiten machen will, wird es schnell mal duster. Im wahrsten Sinne des Wortes: Applikationen, die durch IO blockiert sind, bekommen dunklere Fenster auf dem Desktop.

Und das ist nicht gerade selten der Fall, bestes Beispiel ist Firefox wenn ich auf eine Seite gehe, auf der 20 verschiedene Flash Applets eingebunden sind (z.B. Google Adsense Review Center, also keine Game Seiten). 10 Sekunden Bedenkpause mindestens. Von virtualisierten Maschinen die parallel laufen mal ganz zu schweigen – diese haben eine eigene Festplatte spendiert bekommen.

Nun hat es mich also interessiert, wie kann es sein, dass bei gleicher Hardware ein Solaris so viel flotter von der Hand geht? Sicherlich hat der Scheduler was damit zu tun, und vielleicht sind die Treiber auch optimiert – aber das kann nicht alles sein. Richtig: Denn es gibt nicht nur Scheduler für die CPU Zeit, sondern auch für die IO Zugriffe. Alle Lese- und Schreiboperationen werden von dem Betriebssystem nach einem bestimmten Prinzip abgearbeitet. Der einfachste Scheduler tut einfach nichts („noop“) und reicht die Anfragen direkt an die Hardware weiter. Das macht z.B. bei SSD Speichern und virtuellen Maschinen Sinn: Bei SSD Festplatten zahlt man keinen direkten Strafzoll in Form von langsamen Kopfbewegungen bei der Festplatte für weit entfernt liegende Datenblöcke, und virtuelle Maschinen greifen sowieso nicht direkt auf die Hardware zu. Weiterlesen »

Shotwell wird in Ubuntu Maverick (10.10) f-spot als Photoverwaltung ablösen. Im Grunde finde ich das gut: Shotwell ist deutlich schlanker als f-spot und auch der Umgang mit RAW Bildern soll gut werden.

Auch an einen Import von f-spot Daten (vor allem Tags und Bild Kommentaren) wurde gedacht. Doch genau hier gibt es ein Problem: Shotwell hat ein massives Speicherleck. Das führt dazu, dass große Bildbestände nicht erfolgreich zu shotwell importiert werden können. (Dabei spielt es keine Rolle, ob diese von f-spot oder aus dem Dateisystem importiert werden.) Während im Issue Tracker von yorba noch diskutiert wird, wie man das Problem nach dem (erfolgreichen) Import in den Griff bekommt, ohne shotwell neu starten zu müssen, kann ich nicht mal den Import vollständig durchführen, da mir vorher der Speicher ausgeht.
Ich könnte ja auch mit 500MB oder 1GB Speicherverbrauch für eine große Bildsammlung leben, aber bei 6GB geht mein etwas betagter Arbeitsplatz nun mal in die Knie.

Damit ist in meinen Augen shotwell nicht geeignet das Standardprogramm zu werden, wenn das Programm nicht in der Lage ist, ohne linearen Anstieg von benötigten Ressourcen aus zukommen.