Shuttle

Das wandboard hat leider nicht lange durchgehalten: schon gegen Ende des Sommers machte es durch ein leises Summen auf sich aufmerksam (ein Geraeusch, das man von einem luefterlosen Geraet einfach nicht hoeren moechte), dazu kamen in immer kuerzeren Abstaenden spontane Reboots. Nachdem die durchschnittliche Uptime auf unter 2 Stunden gefallen war, habe ich mich also nach Ersatz umgeschaut. Nach den Erfahrungen mit ARM-Geraeten (Hardware nur teilweise unterstuetzt, abenteuerliche cross-compile-Arien mit zweifelhaften Resultaten usw.) bin ich wieder heimgekehrt ins Reich der x86 und habe mich fuer einen Shuttle entschieden: luefterlos, fuer 24/7 freigegeben. Mit einer SSD und 4GB RAM braucht er bei mir im Mittel ca. 6 Watt, wobei der Verbrauch bei Vollast bis etwa 11 Watt hochgeht. Der uebliche Benchmark:

mathias@shuttle:~$ time echo "scale=5000; a(1)*4" | bc -l > /dev/null
real 0m42.464s

Also gut 3mal so schnell wie das wandboard, bei ca. doppelten Stromverbrauch – fairer deal.

Der Umzug von dns/dhcp war etwas schwieriger, mittlerweile legt Ubuntu einem da so einige Steine in den Weg (muss ja mit NetworkManager, resolvconfd, dnsmasq usw. alles schoen automatisch gehen – wehe dem, der da manuell eingreifen will.)

Nach der Huerde waren owncloud, dovecat, getmail, tiny-rss, munin, sslh und apache dann recht pflegeleicht.

Die Datenhalde sollte eigentlich auf ein NAS (im Moment ein Synology DS214) – das spielt aber nicht so richtig mit: urspruenglich sollte es per iscsi angebunden werden, damit dort ein luks-Volume drauf kann, welches per samba exportiert wird. Bei iscsi geht das NAS aber nie in den suspend – was ein Spielverderber. Also ein normales Volume draufgelegt, mit einer Container-Datei gefuellt, die als loopback gemountet und dort das luks drauf: durch die Brust ins Auge. Nicht schoen, funktioniert aber.

Ein klein wenig Aerger bereitete dann noch ein Ubuntu-Update, nach dessen Einspielenn der Rechner alle naselang einfach runterfuhr. Den logs war nur zu entnehmen, dass der systemd per dbus die Anweisung genau dazu bekommen hat. Auch hier wieder: wehe dem, der da Fehler suchen muss. Irgendwann war dann der lightdm enttarnt: nach dem update crashed der haeufiger, und upstart interpretiert das Ende des lightdm als Signal, den Rechner runterzufahren. Offenbar ist es in der Linux-Welt mittlerweile recht ungewoehnlich, dass sich mehrere Leute auf einem Rechner anmelden oder ein Rechner neben dem gui noch andere Dienste anbietet.

Das Backup macht jetzt auch der shuttle: ein kleines Script schaut sich die blkid angeschlossener Platten an, wenn es eine als Backup-Platte erkennt, mountet er die und start das Backup (per rsnapshot). Einfach USB-Platte anschliessen, Script per screen starten und laufen lassen.

Qt Developer Days 2014

Mit etwas Abstand moechte ich mich mal an einer Art Fazit versuchen. In den letzten 5 Jahren habe ich leider etwas den Kontakt zu Qt verloren, mich hier wieder auf den aktuellen Stand zu bringen war einer meiner Hauptmotivatoren fuer den Besuch dieser Veranstaltung.

Die Veranstaltung

Die Organisation war erstklassig, falls irgendwann mal irgendetwas nicht geklappt haben sollte, ist es mir entgangen. Einziger Kritikpunkt aus meiner Sicht (und das trifft auch gar nicht die Organisatoren): einige Vortraege wurden von Leuten gehalten, deren technische Kompetenz ganz sicher ueber jeden Zweifel erhaben ist, die aber ihre Inhalte einfach nicht verstaendlich rueberbringen konnten. Programmieren und Praesentieren sind halt zwei voellig unterschiedliche Dinge.

Die Technik

Auf der technischen Seite gibt es auch nur Erfreuliches zu berichten: mit den QtQuick.Controls machen QtQuick und QML jetzt auch aus meiner Sicht Sinn. Ansonsten entwickelt sich alles ordentlich weiter, sowohl auf die Entwicklung von C++ als auch auf die Veraenderungen der zahlreichen Plattformen wird reagiert. Nicht immer so schnell wie man es sich wuenschen wuerde, aber es ist klar, das die Qt-Leute die Herausforderungen erkennen und in Angriff nehmen. Aus meiner Sicht durchweg zufriedenstellend.

Der Kommerz

Die kommerzielle Seite macht mir die meisten Sorgen und das ist nicht besser geworden. Digia kennt das Problem (natuerlich, sie sehen ja die Verluste als erste). Aus meiner Sicht faehrt Digia hier eine zweigleisige Strategie: zum einen wird versucht, Aufwand an die Community auszulagern, zum anderen echten Mehrwert auf der Bezahlseite anzubieten. Z.B. den QtQuick-Compiler gibt es ausschliesslich fuer kommerzielle Kunden. Beides schmeckt mir nicht besonders, wenngleich ich den Schritt durchaus gut nachvollziehen kann.

Aus meiner Sicht ist das (die finanzielle Situation) ein echtes Problem bei der Einfuehrung von Qt in Unternehmen. Natuerlich werden die BWLer die Techniker fragen, warum sie in eine Technologie investieren sollen, die dem Hersteller Verluste bereitet. Aus Sicht des BWLers kann das keine Zukunft haben.

Ein zweites Problem ist die C++-Basis. In der langen Leidenszeit vor C++11 hat die C++-Community enorm an Substanz verloren. Und da Schulen und Universitaeten nach wie vor konsequent auf andere Programmiersprachen setzen, wird es wohl noch lange Zeit sehr schwierig sein, C++-Programmierer zu finden. Und, nicht zuletzt bedingt durch die Sprache selber, noch sehr sehr viel schwieriger, gute C++-Programmierer zu finden.

Beide Probleme wurden thematisiert (fand ich gut), die Antworten blieben aber (fuer mich) unbefriedigend (nicht gut).

Das Bleibende

Interessant war vieles, einiges ragte dann aber doch hinaus: link-time-dispatch kannte ich gar nicht, mit QtQuick habe ich mich versoehnt, QRemoteObjects muss ich mir genauer anschauen. Und ueberhaupt sollte ich wieder mehr mit Qt machen. Das Zeug macht halt einfach Spass.

Cross compile mit OpenSuse

Mittlerweile sind die ARMs stark genug, dass man darauf kompilieren kann (“make -j4 uImage modules” in 15min auf dem wandboard vs “make -j8 uImage modules” in 17min auf einem  AMD FX(tm)-8350 mit qemu).

Der Nachteil der OpenSuse liegt auf der Hand: während man anderswo einfach das passende cross-gcc-package installiert, muss man bei OpenSuse eine chroot-Umgebung aufbauen, in die ein mehr oder minder komplettes Arm-Suse reininstalliert wird. Die arm-executables werden dann per qemu gestartet. Hat andererseits den Charme, dass man seine Programme auch gleich an Ort und Stelle ausprobieren kann und per “zypper in” fehlende Pakete einfach nachinstalliert werden können.

http://en.opensuse.org/HCL:Chroot hält die passende Doku bereit – ich musste eine ganze Weile suchen…

Wenn man das aber einmal durch hat, läuft es gut. Und wandboard hat jetzt endlich auch einen Kernel, der cifs und nfs kann. Wie es sich (zumindest bei nfs) für einen Server ja wohl gehört.