(because it's way more awesome than using just a Wiimote)

For this to work, you will need an up-to-date cwiid installation, the most important part is commit b54bd05.

Next, check out neverball svn and apply tilt wii.patch.

Build it (make ENABLE_TILT=wii), then run ./neverball and press the Balance Board's red sync button.

If everything works out, the Power LED should turn on. Now you can use the mouse / keyboard to select the level to play, and then control the level itself using the Balance Board.

There's a (really low-quality) Video (also on Youtube) available. I hope to have a higher resolution and less laggy one by saturday.

For the record, the complete patched tilt wii.c is also available.

Update:
I've got a new Video! (also on Youtube). As you can see, controlling neverball this way is pretty hard :)

With the most recent Patch, you can control the level with the balance board and the camera and menus with the wiimote. Usage: Start neverball, connect wiimote, wait 'til the leds stop blinking, then connect balance board. There are some timing issues right now, so if it crashes while connecting the devices, just try again.

Als Person, die nichts mit Mikrocontrollern am Hut hat, fragt man sich ja immer, was für eine Wissenschaft das eigentlich ist. Man hört von gefährlichen Fusebits, kaputtgeflashten Chips, hat vielleicht auch schonmal jemanden mit ISP/JTAG-Gedöns rumfummeln sehen und stellt insgesamt fest, dass das alles unheimlich kompliziert aussieht.

Das schöne an der Sache ist: Wenn man sich erstmal mit beschäftigt, merkt man schnell, dass es viel simpler ist, als man denkt. Genaugenommen sind die ersten Schritte dank Internet, insbesondere mikrocontroller.net sehr einfach.

Programmer und Chips

Zunächst mal vorweg: Alles folgende bezieht sich auf die Atmel AVR-Prozessoren.

An AVR-Programmier- und -Testboards gibt's mehr als genug, z.B. das Arduino-Projekt. Da kann man sich irgendwas aussuchen, von dem bekannt ist, mit welchen Methoden welche Arten von Chips programmiert werden können. Aus der Menge der programmierbaren Chips besorgt man sich ebenfalls ein paar Stück und schon kann man loslegen.

Es ist übrigens auch möglich, AVR-Chips direkt am LPT-Port zu programmieren, für den Anfang ist ein fertiges Board aber deutlich empfehlenswerter. Da hat man nämlich ein paar LEDs und Taster am µc dranhängen, so dass man direkt rumspielen kann, ohne erst eine Schaltung zu löten.

Atmelboard von Pollin

In meinem Fall wurde es das Atmel-Evaluationsboard. Das ganze gibt's als Bausatz oder auch Fertigmodul, und mikrocontroller.net und der Entropia haben auch Artikel darüber.

Das Atmelboard von Pollin unterstützt mehrere verschiedene AVR-Typen, ich hab mir ein paar ATtiny2313-Chips geholt, mit 1.95 Euro pro Chip kann man bei denen nicht viel falschmachen. So ein ATtiny ist zwar sehr eingeschränkt (2kB ROM, 128 Byte RAM, 128 Byte EEPROM), aber für erste Testprogramme reicht er locker, und später wird man ohnehin feststellen, dass auf so einen µc viel mehr draufpasst, als man denkt.

Software

Wenn man nun sein Board hat, braucht man die nötige Software, i.d.R. reicht es dazu aus, avrdude und avr-libc (sollten gcc-avr und binutils-avr mitziehen) zu installieren. Ziel ist jedenfalls, dass man einen funktionierenden Compiler für den AVR-Plattform (gcc-avr) und ein Proramm zum Flashen des Chips (avrdude) hat.

Vorbereitung

Für alles weitere empfiehlt sich auch sehr, einfach mal durch AVR-Tutorial und AVR-GCC-Tutorial durchzuklicken, da steht alles (und noch viel mehr), was man wissen muss.

Man kann schonmal einen Chip in den Programmer stecken und ihn an Strom und PC anschließen. Je nach Interface (USB / Seriell) wird er meist als /dev/ttyUSB0 oder /dev/ttyS0 angesprochen. Beim Pollinboard ist unbedingt zu beachten, dass das serialle Kabel an den ISP-Anschluss und nicht RS232 kommt. Letzterer macht nichts kaputt, tut aber auch nichts für uns.

Nun fehlt nur noch eine Methode, um Code zu kompilieren und auf den AVR zu spielen, und etwas Code zum Testen.

Ich selbst bevorzuge C-Code, welcher mittels eines Makefiles kompiliert und dann (ebenfalls vom Makefile) auf den µc programmiert werden kann. Siehe dazu Beispiel Makefile. Ich verwende die korrigierte Fassung aus dem Artikel (direktlink).

Man muss in dem Makefile nur noch drei Dinge einstellen: Den verwendeten Chip (MCU), den Programmer (AVRDUDE_PROGRAMMER) und den Port (AVRDUDE_PORT). Für meine Konstellation wäre das:

MCU = attiny2313
AVRDUDE_PROGRAMMER = ponyser
AVRDUDE_PORT = /dev/ttyS0

Dinge tun!

Damit wäre die Vorbereitung fertig. Für einen ATtiny auf dem Pollinboard gäbe es noch dieses simple Testprogramm (main.c):

#include <avr/io.h>

int main (void) {

    DDRD = (1 << PD5);
    PORTD = (1 << PD5);

    while (1);

    return 0;
}

Dieses Programm mit make kompilieren und anschließend mit make program auf den AVR übertragen lassen. Man sieht nun jede Menge Ausgaben von avrdude, ganz unten sollte jetzt stehen, dass alles geklappt hat.

Das Programm tut nichts anderes, als den I/O-Pin PD5 auf Output zu setzen, einzuschalten und dann zu loopen. Auf dem Board ist an PD5 eine LED angeschlossen, diese sollte nun leuchten.

Das war's dann auch schon. Falls der Controller funktioniert ist alles schön, falls nicht einfach mal auf mikrocontroller.net und in den Kommentaren des Makefiles rumwühlen, wahrscheinlich stimmt irgendeine Einstellung nicht. Ich selbst kam in das Glück, nicht debuggen zu müssen.

Und so weiter

Für alles Weitere (und sehr gute Erklärungen dazu, was die einzelnen Codezeilen des Beispiels genau tun) sei noch einmal auf das AVR-GCC-Tutorial ( sowie sämtliche andere Artikel auf der Seite :p ) verwiesen. Das Tutorial behandelt im Gegensatz zu meinem Blogpost auch so ziemlich alle Methoden, mit denen man was tun kann.

Man sieht jedenfalls, dass "Mikrofoo" eigentlich ziemlich simpel ist, man sollte sich nur nicht von der Länge der Howtos oder den Fachbegriffen erschlagen lassen.

Ein Wort zu Fuses noch: Solange man einfach nur rumspielt, kann man die meist komplett ignorieren. Somit hat man auch keine Möglichkeiten, seinen Controller kaputtzuflashen, schlimmstenfalls hängt man ihn durch einen Programmierfehler auf, was mit 'nem einfachen Reset / Flashen einer korrigierten Programmversion behoben wird.

Ich teste gerade für die geplante Lichtdecke im Chaosdorf ein paar LED-Halogenersatzbirnen... und ich muss schon sagen, soo schlecht sind die Teile gar nicht.

Zum Test da sind zwei kaltweiße 1W-Birne (96lm, entspricht ca. 10W Halogen), zwei kaltweiße in 2.4W (160lm, ca. 20W Halogen) und zwei warmweiße in 2.4W (140lm, ebenfalls ca. 20W Halogen).

Im Vergleich zu den 300 bis 600 Lumen einer 30W-Halogenbirne sind sie natürlich noch dunkel, aber die kaltweiße 2.4W-Birne sieht schon so aus, als könnte man sie tatsächlich als Arbeitslicht benutzen.

Hier mal ein paar Bilder der Lampen, aufgrund verschiedener Kameraeinstellungen taugen sie nicht wirklich als Vergleich, aber geben zumindest 'ne grobe Idee.

Ganz kalt bleiben die Leuchten im Betrieb nicht, aber die Temperaturentwicklung hält sich sehr in Grenzen. Zumindest konnte ich sie nach 'ner halben Stunde Betrieb noch schmerzfrei anfassen.

Auf der Rückseite ist übrigens deutlich mehr Elektronik, als man erwarten würde:

Mal schauen, was draus wird. Tolle Spielzeuge sind so LED-Lampen schonmal.

Die datenschutzkritische Spackeria ist ja schon länger ein Thema... da komm ich nicht umhin, auch mal meinen Braindump dazu ins Netz zu pusten ;-)

Einen der Hauptgedanken versteh ich ja als "Wenn man schon Daten ins Netz stellt, dann sollte man sich auch nicht wundern, wenn sie benutzt werden", bzw. sobald Daten irgendwie die eigene Kontrolle verlassen (z.B. auch an Bekannte weitergegeben werden), ist es letztendlich immer möglich, dass sie öffentlich im Netz landen.

Eigentlich ist das Problem mit den freilaufenden Daten ja gar nicht so neu.

Wenn man mal einen Vergleich aufbaut, hat man das auch bei ganz normaler Kommunikation: Person A erzählt Person B von Dingen. Wenn das einfach nur belangloses/unwichtiges Zeug ist, ist es auch egal, ob es weitererzählt wird. Wenn es sich bei den Dingen aber um irgendetwas privates handelt, sollte Person A schon sehr gut wissen, wem sie es erzählt und wem nicht. Und muss im Zweifelsfall auch damit rechnen, dass die Informationen trotzdem (ggf. noch verändert) weitergetragen werden und z.B. Gerüchte entstehen. Und dass man solche Gerüchte nicht "löschen" kann, sollte klar sein.

Heutzutage: Person A lädt z.B. Bilder für Person B hoch. Auch hier muss sie sich (wenn es potentiell kompromittierendes Material ist) darauf verlassen, dass diese Bilder bei Person B bleiben. Auch hier kann es passieren, dass diese Bilder plötzlich an weitere Personen verbreitet werden und letztendlich "im Internet" landen. Wo man sie, wie hoffentlich jeder weiß, auch nicht mehr rauskriegt (irgendwer hat immer 'ne Kopie gespeichert). Und auch hier können die Bilder verändert ("gephotoshoppt") werden, womit wir dann bei Gerüchten wären.

Von daher: Sobald ich die alleinige Kontrolle über irgendetwas, sei es nun Gedankengut (reale Unterhaltung) oder Daten (Bilder, Videos, whatever) mit Anderen teile, besteht immer die Gefahr, dass diese Anderen mein Vertrauen verletzen und die Daten weiter tragen, als ich will. Es steht jedem selbst frei, zu entscheiden, bei welchen Daten und Personen(gruppen) er dieses Risiko eingeht, und bei welchen er es lieber sein lässt.

Leute dürfen gerne Youtubevideos oder peinliche Partybilder hochladen und als privat / nur einer gewissen Personengruppe zugänglich markieren. Es muss nur zum Allgemeinwissen werden, dass es in solchen Fällen verdammt leicht passieren kann, dass die Bilder dann plötzlich sonstwo landen und dort auch nie und nimmer mehr wegzukriegen sind. Wenn allen Leuten dieses Risiko bewusst ist, werden wir vielleicht auch direkt weniger Datenschutzdrama haben :-)

Was natürlich hilft, ist, Daten direkt für alle öffentlich zu machen. Das ist dann ein anderer Post-Privacy-Gedanke, dass irgendwann einfach sämtliche Daten öffentlich sind, und wenn jeder Mensch peinliche Sachen im Netz stehen hat, ist es für den einzelnen auch egal, da gesellschaftliche Norm. Aber bis sich unsere Gesellschaft dahin entwickelt (wenn sie es denn tut), wird es vermutlich noch ziemlich lange dauern. Von daher empfehle ich dringend, damit jetzt noch nicht anzufangen ;-)

Ein Problem hätte mein Vergleich übrigens: Dateneinbruch.

Gedanken kann niemand aus meinem Kopf stehlen, Daten von meinem PC allerdings sehr wohl. In dem Fall kann man allerdings auch nur zwei Dinge tun — Hoffen, dass die meisten Menschen den Anstand haben, nicht in fremde Systeme einzubrechen und Daten kopieren ("stehlen" ja i.d.r. nicht), und selber seine Systeme sichern. Aber das ist dann wieder ein anderes Problem.

Um bei diesem ganzen Geschwurbel mal zu 'nem Punkt zu kommen: Post-Privacy und die Spackeria sind überhaupt nichts Neues, das Problem, dass Gedanken/Daten in fremde Hände kommen können, wenn man die Kontrolle darüber abgibt, ist uralt. Es wird endlich Zeit, dass die Menschheit sich damit abfindet, anstatt rumzuweinen.

Ich selbst tendier ja auch in Richtung post-privacy, zumindest findet man auf about auch meine Tweets, Software und meinen Musikgeschmack. Und via PGP und die Web2.0-Seiten auch sehr schnell mein soziales Umfeld. Über last.fm kann man sogar grob darauf schließen, wann ich aufstehe und wann ins Bett gehe. So what?

Just a quick note: feh v1.13 has been released yesterday. Download.

Its main feature is Xinerama-aware background setting. That is, if you have two or more monitors, feh --bg-fill and the likes will no longer behave as if you just had one display connected, but instead set the image properly scaled on each monitor. This is a bgs feature I've been wanting to implement for quite a while.

If you have a wallpaper which is designed for your multimonitor setup, you can use the --no-xinerama switch to get the old behaviour, e.g. feh --no-xinerama --bg-fill foo.jpg.

The only background option which does not support Xinerama is --bg-tile. The reason for this is that if you use tiling, you probably have a wallpaper which repeats itself and does not care where on the monitor it starts/stops, so there should be no need to care about the monitor setup.

What's also new in this release: When you call feh without file arguments, it will now simply display all images in the current directory instead of exiting. To save you typing those two extra characters after the feh options :-)

As for bugfixes: Reloading finally works properly and not only after the second try (stupid Imlib2 caching...), and you can now use %h and the likes in --title without feh segfaulting when encountering an unloadable image.

That's about it. Now on to feh 1.14. :p

As part of the Chaosdorf Admin Team, I recently wrote (and today overhauled) check_websites. You give it a URL and it checks if it is reachable under certain constraints.

All of this can also be achieved with check_http. However, since the Icinga configuration format is extremely verbose, I prefere to configure just one service which then uses check_websites to do all of this in one run.

Right now, it does actually not support that much. To quote its help:

-a, --auth=STRING
  Verify that URL requires auth (HTTP 401)
-o, --ok=STRING
  Verify that URL exists (HTTP 200)
-r, --redirect="FROM TO"
  Verify that FROM is a redirect (HTTP 301) to TO

In our case, we're calling it the following way:
/usr/local/lib/nagios/plugins/check_websites --extra-opts=@/etc/nagios/chaosdorf_websites.ini

On a side note: Nagios::Plugin is really, really awesome.

Okay. I decided to have as much website redundancy as one can get with one VM (steel) and one homeserver (aneurysm). I don't really know I got this idea, but it's probably my general backup and redundancy obsession ;-)

Now, the setup is as follows:

• aneurysm.derf0.net stores data only on aneurysm (/tmp and the like)
• steel.derf0.net stores data only on steel (/tmp for other files)
• derf.homelinux.org is the main website, hosted on aneurysm. It is built by ikiwiki and automatically mirrored to steel, where it is reachable as finalrewind.org. Now I just have to decide if I stick to derf.homelinux.org or use finalrewind.org as "main url" for my website...
• feh.finalrewind.org is also managed by ikiwiki. It is built on aneurysm, automatically mirrored to steel, and served from steel
• man.finalrewind.org is generated by custom stuff and hosted from aneurysm. Not mirrored yet, will be fixed.
• lib.finalrewind.org hosts large images and is therefore served from steel. Its "base" is also on steel, aneurysm regularly mirrors from there

This time, I'm using rsync instead of unison to do the syncing, mostly because all the websites have the generation scripts only on one host, so it does not make sense to do a two-way sync. The vhosts are managed by lighttpd with mod_evhost.

On a side note: I had another DynDNS problem yesterday (the FritzBox did not update properly) and finally decided that a homeserver is a nice toy, but when one reaches the point where one has websites which are meant to be available all the time, it's really better to host elsewhere. I think I reached that point a year ago, so... yeah. About time.

The next logical step would be to sync the ikiwiki sources instead of the output and have the git repos etc. on both hosts, so when one goes down I can just push to the other (and maybe change the DNS records). But that's probably a bit overdone, especially for low-traffic sites like mine.

So. Ich hab jetzt die gesamte Website (abzüglich http://feh.finalrewind.org) von komischen Perl/Shell/Makefile-Gefrickel auf ikiwiki umgestellt. Damit ich endlich mal direkt Inhalt produzieren kann, ohne mich mit irgendwelchem Formatgedöns rumschlagen zu müssen.

Es gibt noch ein paar 404s (z.B. die Changelogs der Projektseiten), aber das Wichtigste sollte eigentlich funktionieren.

Nebenbei kann ich jetzt auch z.B. 'ne richtige Sidebar einbauen, wenn ich denn will.

This started as a proof-of-concept, but it turned out to be actually useful.

The idea: Hey, why not have some widgets. They're shiny (at least when properly designed, mine definitely ain't ;-) ), they show useful information, and you have a little more than just a boring wallpaper on your desktop.

However, I'm using a tiling window manager with pseudo-transparent urxvt terminals. I do see my wallpaper, but never my actual desktop. A widget would be totally useless there.

So, I decided to put the widgets directly onto my wallpaper. Each widget is a script producing a PNG image in /tmp, and those are then overlayed onto the wallpaper using ImageMagick. This has some obvious disadvantages (low update frequency, widgets are non-interactive), but besides that, I really like it. I'll not turn this into a project as I'm not sure how many other people find this useful, but for myself I'll definitely keep it.

Resources: widget list, update script (does some other things as well).

I recently started working on hashl (no project page yet), inspired by (hashcp)[https://github.com/craig/hashcp]. It creates a list of all files below a directory and also stores a hash of their beginning (by default the first 4 MiB, but that's configurable. For music, I usually use 512KiB).

This way, when you find an FTP server or whatever, you don't have to mirror everything and later check if you already have it, but you can tell hashl to scan all files on the FTP server, download only the first few kilo-/megabytes and use those to check if you possibly already have the file on your disk. This of course doesn't prevent having one file in several versions, but against pure duplicates (which are also common) it works well.

So, you don't have to worry about duplicates, and as a side effect, leeching is faster because you do not even transfer any duplicate files.

Or, my usecase: I have an external hard disk for all my videos, and a directory on my netbook containing just a few of them. New videos also end up on the netbook. The hard disk is mounted on /media/argon, the netbook dir is ~/lib/video. hashl stores its database in .hashl.db, /media/argon/.hashl.db is a symlink to ~/lib/video/.argon. ~/lib/video/.hashl.db also points there.

Now, I can use these neat commands:

# whenever I mount the external hard disk, I update the list
descent /media/argon > hashl update
# same, but more verbose
descent /media/argon > hashl -d ~/lib/video/.argon update

# Now, to find out which files in my netbook directory are new (not yet copied)
descent ~/lib/video > hashl find-new
# same
descent ~/lib/video > hashl -d .argon find-new

# As an advantage, I can also use this on remote servers. Let's say I have an
# FTP mounted on /tmp/ftp/foo and the external disk is not connected. I can
# still only leech the videos I do not yet have.
descent /tmp/ftp/foo > hashl -d ~/lib/video/.argon copy ~/lib/video

# And of course, to sync netbook <-> hard disk
descent ~/lib/video > hashl copy /media/argon/filme/incoming
descent ~/lib/video > cd /media/argon
descent /media/argon > hashl update

For me, this tool is a great help, and I'll maybe add some more fun features too (merging databases? Marking a file from a non-connected external storage for retrieval? Moar automation for things I cannot think of yet?). So, stay tuned for the first release, whenever it will happen :p