Leider fehlt mir jede Erinnerung, wo genau ich zum ersten mal von Spagetthi-Code gelesen habe. Vermutlich im Linux Magazin oder in der c't. Vor ein paar Tagen stieß ich dann auf eine nicht zu 100% ernsthaft gemeinte Erläuterung, was denn Spaghetti Code sei. Die weniger bekannten Alternativen Lasagna-Code (Blockhafter aber strukturierter Code, schwer zu pflegen) und Ravioli-Code (die Idealform, kleine Pakete, die miteinander in Beziehung stehen aber unabhängig sind in der Pflege).

Dies führte mich zu der Überlegung, wo denn die gis-tools.py einzuordnen wären. Ich kam recht schnell dazu, daß es sich um eine Unterart der Lasagne handeln muß, den Cannelloni (Bild auf Wikipedia). Längliche Rohren von in etwa 2cm Durchmesser, die man dann nebeneinander legt ansonsten aber ähnlich wie Lasagne mit lekkerem Inhalt befüllt.

Genau so war der Code bisher. Drei riesige Pakete, an beiden Seiten offen, an sich leicht zu warten, da sich quasi alles innerhalb der Röhren abspielte, aber man ahnt es schon, fast immer die gleiche Soße drin.

Zu Ravioli habe ich schon immer eine besondere Beziehung gehabt. Als ganz kleiner Junge fiel es mir schwer mir diesen seltsamen Namen 'Ravioli' zu merken, das waren eindeutig zu viele Vokale auf einmal für eine bis dahin von Fremdsprachen unbefleckte Zunge. Aber es gab da etwas viel besseres. Und zwar habe ich einen kleinen Schlumpf, der auf einem roten Kissen sitzt, den habe ich immer noch! Und dieses Kissen war in Form und Größe genauso beschaffen wie die Ravioli, und damit waren das für mich keine Ravioli mehr, sondern Schlumpfkissen, die rote Farbe besorgte ja die lekkere Soße.

Ich werde also Kissencode schlumpfen. Freue mich schon auf die Kissenschlacht, und Schlaubys erhobenen Zeigefinger.

So etwas nervt!

Lange Zeit war ich selber ein Fan vom Firefox Browser, weil er im Vergleich zum IE wirklich besser war und wohl immer noch ist.

Aber mit Entsetzen mußte ich feststellen, daß dieses Blogdesign vom Firefox falsch umgesetzt wird. Die Schriften waren viel zu klein, insbesonde die Kennungenwolke (aka tagcloud) war kaum erkennbar. Jeder Browser hat Stärken und Schwächen, aber ich muß doch bitten, Schriftgrößen sollten kein Problem mehr bereiten, oder?

Tun sie aber. Und hier mal der einfachste Grund weshalb ich Opera und Konqueror so schätze gegenüber den anderen Browsern:

Opera

Firefox

Da verstehe ich den Hype um den Browser wirklich nicht mehr. Aber wie sagte der alte Fritz so schön:
In meinem Staate kann jeder nach seiner Fasson selig werden.
Friedrich der Große 1740 zum Thema Toleranz gegenüber Religionen in Preussen.

Leider haben es die übrigens sehr freundlichen Jungs von grokthis.net leider nicht geschafft mir zu antworten und da mir die Zeit davon rennt, mehr dazu in Bälde, habe ich mich entschlossen die Liste der django-freundlichen Webhoster nochmal anzuschauen:
webfaction.com waren auch darunter.

Dort hat man ebenfalls sehr schnell geantwortet. Und mittlerweile bin ich ja ein gebranntes Kind war mein erstes Anliegen natürlich, ob denn nun eine Kreditkarte nötig sei, da man auch hier die Wahl zwischen jener und paypal hatte. Und siehe da, es ist egal, ob man zum Kreis der Kreditkartenbesitzer gehört oder sein Geld auch ohne horrende Transfergebühren auszugeben willens ist.

Also bin ich mal gespannt, wer von den beiden nun mich schließlich noch überzeugen kann.

Teil drei sollte sich eigentlich bereits vorgestern damit beschäftigen, wie das Hochladen von Daten (Wegpunkten, Routen, 'tracks') klappt. Es funktionierte wider Erwarten nur halbwegs. Ich vermutete zunächst etwas in der Bedienung von gpsbabel übersehen zu haben, weshalb immer nur ein Wegpunkt hochgeladen wurde, anstatt alle vorgegebenen auf einmal.

Aber das war es nicht, also mal die allzu bekannte Suchmaschine genutzt und siehe da: der Treiber für Garmin (garmin_gps) wird auf gpsbabel ein reibungsloses Funktionieren treffenderweise als "depressingly uncommon situation" beschrieben. Also blieb mir nur über die angebotenen Lösungswege auf Gentoo Linux anzuwenden

Als erstes nutze ich die Gelegenheit den unweise fest in den Kernel kompilierten Treiber zu entfernen, was mir die mühsamen Umwege erspart den Treiber davor zu bewahren überhaupt geladen zu werden. Ich halte es auch für die sauberere Lösung das Ding direkt zu entfernen, da es nachweislich nicht korrekt arbeitet.

Im wesentlichen reichte es dann unter:
/etc/udev/rules.d/ die Datei 51-garmin.rules anzulegen. In diese Datei kommt folgende Zeile:
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", GROUP="plugdev", MODE="660"

Nun konnte ich mittels QGIS eine neue .gpx-Datei anlegen und mit lustigen Wegpunkten befüllen. Auch Routen ließen sich problemlos erzeugen und als normaler Nutzer ohne root-Rechte mit folgendem Befehl auf das GPS-Gerät hochladen:
gpsbabel -r -i gpx -f test.gpx -o garmin -F "usb:"

Nun endlich kann ich in Vorbereitung für Hattuscha die wesentlichen Strukturen vorab auf das Gerät laden. Übrigens Routen und 'tracks' eignen sich hervorragend, um Gebäudeumrisse nach zuzeichnen.

Und wieder ein Problem gelöst :)

Klingt komisch, ist aber so. vermutl. Armin, 'Sendung mit der Maus'.

Warum einfach wenn es auch kompliziert geht?

Eigentlich hatte ich gehofft, an dieser Stelle schreiben zu können, daß alles nun bei einem webhoster online ist, aber das Leben ist hart. Wozu bietet man eigentlich eine Zahlungsweise mit paypal als Alternative zu einer Kreditkarte an, wenn man für die Identifikation dann doch wieder eine Kreditkarte braucht? Die anfängliche Freude über den webhoster grokthis.net ist teilweise verflogen, denn genau dort ist so ein Unfug bei der Zahlungsweise normal. Ich verstehe einfach nicht wo das Problem liegt, eine Zahlung per Vorkasse via paypal zu akzeptieren. Einfach so.

Und so wird es noch ein wenig länger dauern bis ich endlich dieses (oder ist es diesen) Blog online erreichbar habe ohne auf dynamisches DNS zurückgreifen zu müssen.

Wie immer habe ich vor dem Kauf von Geräten für den Rechner geschaut, wie es denn um die Linux-Unterstürzuung bestellt ist. So auch bei dem Digitalisiertablett Bamboo von Wacom. Ein höschst schlichtes und einfaches Gerät, da ich damit eigentlich nur digitalisierte Rasterkarten in QGIS oder GRASS GIS vektorisieren wollte. Also nicht einmal die Druckstärke spielt eine Rolle für mich.

stille Wasser gründen tief

Und nachdem es mich doch einige Nerven gekostet hat und es offiziell doch noch nicht unterstützt wird, möchte ich hier eine kleine Beschreibung bieten, wie es dann doch geklappt hat. Ich habe es bisher nur unter Gentoo Linux 2.6.23 x86 und linuxwacom-0.7.8-3 getestet. Im wesentlichen habe ich mich an das HowTo Wacom Tablet vom Gentoo Wiki gehalten. Was die allgemeine Intallation zunächst betraf. Hier ist insbesondere die Konfiguration von udev ausführlich erklärt, so daß ich das hier nicht weiter aufgreifen werde. Die zweite wichtige Quelle für mich war: Support-for-wacom-bamboo-one-with-device-id-0x0069.

Das Bamboo One ist anscheinend nicht im Kern Bestandteil der Bamboo-Serie, sondern vermutlich im Kern ein Volito 2. Nur schmückt es sich mit einer anderen id, nämlich der Nummer 0069.

Also für den Fall, daß
cat /proc/bus/usb/devices | grep -A5 056a | grep Driver | grep wacom kein Ergebnis wie dieses: I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=wacom liefert, aber der Treiber vom Kernel oder linuxwacom wie im HowTo beschrieben installiert ist, dann spricht einiges dafür, daß der Treiber das Bamboo One noch gar nicht erkennen kann.

Das liegt an der Produkt-Nr. 0069, was man mit folgender Zeile recht schnell überprüfen kann:
cat /proc/bus/input/devices | grep 056a, diese sollte folgendes ausgeben: I: Bus=0003 Vendor=056a Product=0069 Version=0200.

Ich habe an den Kernelquellen nicht herumgebastelt, sondern den linuxwacom-Treiber manipuliert, so daß er erstens die Produkt-Nummer 0069 erkennen kann und außerdem das Bamboo One als GRAPHIRE anspricht und die gleichen Eckkoordinaten erhält wie das größere Volito 2

Dazu habe ich die Datei src/2.6.19/wacom_wac.c im Verzeichnis des linuxwacom-Quellcodes angepasst. Welche Bereiche kann man am besten aus der oben genannten zweiten Quelle entnehmen: Support-for-wacom-bamboo-one-with-device-id-0x0069.

Danach wäre zwar der Treiber mit dem Gerät verbunden, aber das Mapping ist noch falsch und der Stylus tanzt wie verrückt; an ein Arbeiten ist so nicht zu denken.

Also muß man nun in Ergänzung zu den Angaben von Frederik M.J. Vestre noch in der oben erwähnten wacom_wac.c-Datei die Auflistung ändern, leicht zu finden wenn man nach "Bamboo" sucht. Ich habe hier die Bamboo-Zeile auskommentiert und dafür eine neue für das Bamboo One eingefügt. Vermutlich kann man die Kommentierung auch entfernen.
{ "Wacom PenPartner2", 8, 3250, 2320, 255, 63, GRAPHIRE },
/*{ "Wacom Bamboo", 9, 14760, 9225, 511, 63, WACOM_MO },*/
{ "Wacom Bamboo One", 8, 5104, 3712, 511, 63, GRAPHIRE },
Das ganze mit folgendem Befehl übersetzen lassen:
./configure --prefix=/usr/ --enable-wacomdrv --enable-wacdump --enable-xsetwacom --enable-dlloader --enable-wacom --enable-tabletdev --enable-input --enable-mousedev --enable-evdev && make && sudo make install
und danach den im Verzeichnis unter src/2.6.19/wacom.ko erstellten Treiber anstelle des vom Kernel bereitgestellten Treibers einfügen, man sollte die dort vorhandene Datei gegebenenfalls sichern.
cp wacom.ko /lib/modules/2.6.23-gentoo/kernel/drivers/input/tablet/wacom.ko
Hier muß der Pfad an die eigene Installation angepasst werden.

Ich wünsche viel Erfolg :)