Archiv der Kategorie: Informatik

piCore: Zwischen Einplatinencomputer und Microcontroller

Der RaspberryPi ist ein Einplatinencomputer, der über GPIO Pins mit angeschlossener Elektronik kommunizieren kann. Mikrocontroller (µC) können das auch. Dafür hat der Pi ein ausgewachsenes Betriebssystem (meist Raspbian), ein Dateisystem, ein Netzwerk etc. Andererseits benötigt der µC wenig Strom und man kann ihn ohne Bedenken ausschalten. Der Pi mag das Ausschalten nicht so gerne: er möchte sauber heruntergefahren werden. Und auch sonst muss man sich mehr um ihn „kümmern“ – Software aktuell halten, ggf. das Betriebssystem aktualisieren.

Besonders der Punkt des Herunterfahrens störte mich bei vielen Pi-Projekten, die irgendwann in den Dauerbetrieb gehen sollen. Wenn ich eine LED-Wand damit ansteuere, möchte ich sie ausschalten können, ohne mich zuvor per SSH anmelden zu müssen.

Diese Lücke zwischen ausgewachsenem OS und µC-Firmware adressiert die Distribution piCore – ein auf TinyCoreLinux aufbauendes Linux, das komplett im RAM läuft. Mittlerweile gibt es schon Version 9 und ein aktives Forum mit Nutzern und Entwicklern. Das Basisimage von PiCore ist weniger als 40 MB groß und lässt sich daher schnell installieren. Eine Testinstallation bootete flott in weniger als zehn Sekunden. Weil alle Programme direkt im RAM laufen und es keine langsamen Zugriffe auf die SD-Karte gibt, verhält sich das System äußerst responsiv und flott. Da das OS von SD-Karte bootet und diese anschließend nicht mehr benötigt, kann der Pi ohne schlechtes Gewissen ausgeschaltet werden – alle Daten liegen ja im RAM. Sollen Daten das Ausschalten überleben und auch beim nächsten Bootvorgang erhalten bleiben, gibt es hierfür das Programm filetool.sh, das die Userdaten auf die SD-Karte schreibt.

Fazit: Die Grenzen von piCore liegen klar bei Anwendungen, die viele Daten schreiben – insbesondere, wenn diese Daten nicht mehr in der RAM passen und auch beim nächsten Bootvorgang erhalten bleiben sollen. Wer jedoch die umfangreiche Hardwareausstattung des Pi nutzen möchte und keine Sorgen mit dem Blinden Trennen von der Stromversorgung haben möchte, sollten einen Blick auf piCore werfen.

Gar nicht so schlaue Tradfri-Lampen von IKEA

Die Problemstellung ist eigentlich ganz einfach: In unserer Wohnung gibt es einen Flur ohne Fenster – der demnach immer recht dunkel ist. Wenn man durch den Flur hindurchgehen möchte, macht man das Licht an, geht in den nächsten Raum und mach dann das Licht wieder aus. Wie schön wäre es, wenn man einen Bewegungsmelder hätte, der diese Lampen automatisch ein- und ausschalten würde. Von Ikea gibt es nun eine Reihe Lampen und Zubehör, die sich miteinander über das Protokoll ZigBee verbinden lassen – genannt Tradfri.

Also bin ich losgezogen und habe mir ein solches Lampenset gekauft. Die Installation verlief ohne Probleme: Lampen werden in die Fassung geschraubt, man hält einen kleinen Bewegungsmelder in sehr kurzem Abstand direkt daneben, drückt auf einen Knopf und die beiden Geräte sind miteinander verbunden. Am Bewegungsmelder lässt sich einstellen, wie schnell die Lampen bei einer erkannten Bewegung wieder ausgehen sollen (nach ein, fünf oder zehn Minuten). Zudem kann man einstellen, ob der Bewegungsmelder  bei Tag oder nur bei Dunkelheit arbeiten soll. Das klappt alles ganz gut und auch so, wie ich mir das vorgestellt habe. Bei einem Preis von 15 € pro Lampe (E14-Sockel) und 18 € für den Bewegungsmelder ist der Spaß im Bereich der Smart-Home-Lampen im akzeptablen bis günstigen Bereich.

Als weiteres Feature der Lampen habe ich von der Kompatibilität mit Philips Hue Bridges gehört. Also habe ich das auch einmal mit einer alten Hue Bridge der ersten Generation ausprobiert. Leider klappte das nicht wie gewünscht. Verschiedene Blog-Artikel weisen darauf hin, dass die Lampen erst ab einer gewissen Firmware Versionen mit den Bridges kommunizieren können. Um die Lampen auf eine neue Firmware zu aktualisieren oder gar auszulesen, benötigt man jedoch ein weiteres Gerät von Ikea: ein Tradfri-Gateway. Dieses Gateway ist, zumindest hier im Ruhrgebiet, derzeit überall ausverkauft und mit 30 € auch einigermaßen teuer. Die Verbindung der Lampen mit dem Gateway ist mir daher leider nicht gelungen.

Da die Lampen aber dennoch das tun, was sie sollen – auch ohne eine Kommunikation mit einem zentralen Gateway – werde ich sie behalten und weiter testen. Für die Integration über ein Gateway und damit auch als Schnittstelle mit anderen Geräten würde ich jedoch wieder auf Lampen zurückgreifen, die den Standard besser unterstützen.

CI/CD mit Gitlab

Gitlab ist neben github eine der großen Plattformen für Softwareentwickler, um Quelltext in Git-Repos zu verwalten. Mir hat immer gut gefallen, dass die Plattform keine Probleme mit privaten Repos hat – github stellt sich etwas an und möchte hier nur ein privates Repo pro Nutzer kostenlos zur Verfügung stellen. Auch die Terms of Service von github bereiten mir zunehmend Bauchschmerzen. Hinzu kommt, dass sich github nicht auf eigener Infrastruktur hosten lässt. Gitlab dagegen bietet eine mächtige Community-Edition an. Das Projekt edugit des Teckids e.V. ist ein Vorstoß in die Richtung, diesen Dienst datenschutzkonform auch im Bildungsbereich in Deutschland anbieten zu können.

Zurück zu den Vorzügen von Gitlab. Ein tolles mir neues Feature sind sogenannte Runner. Das sind virtuelle Maschinen, Rechner oder Docker-Container, die meinen Quelltext automatisch prüfen können. Dieses Feature heißt CI/CD (für Continuous Integration/Continuous Delivery) und wird durch die Datei .gitlab-ci.yml konfiguriert. Ein Beispiel, das einen Pythontest in einem Python-Container auf alpine-Basis ausführt, sieht so aus.

image: python:alpine  # Das Basisimage des Containers

before_script:  # Wird vor jedem Task ausgeführt
 - echo nothing to do

tests:    # Ein Task mit Namen 'tests'
 script:  # Das Script hat mehrere Befehle
 - find ex.py test.py
 - python3 test.py
 - python3 -m doctest ex.py

Sobald nun Quelltext in das Repo gepusht wird, läuft ein sogenannter Runner und führt die Tasks einzeln aus. Gitlab selbst stellt auf seiner Plattform verschiedene Runner zur Verfügung, die von Digital Ocean gesponsert werden und in ihrer Laufzeit auf generöse 2000 CPU-Minuten pro Monat und User beschränkt sind. Wem das nicht reicht, der kann auch selbst einen Runner bei sich installieren, laufen lassen und darin die Tests ausführen. Wem Gitlab nicht behagt, der kann auch einen Runner mit drone.io betreiben. Diese haben den Vorzug, nicht auf Gitlab beschränkt zu sein und integrieren sich auch in andere Plattformen wie etwa gitea oder gogs.

MiniGameJam #3 gebar die StarFeetAcademy

Am Samstag, dem 10.2. ging der Mini Game Jam Dortmund in die dritte Runde. Wieder mussten Spielentwickler (Profis, Amateure und Dilettanten) an einem Tag in 8 Stunden ein Spiel erdenken und umsetzen. Es war das zweite mal, dass ich daran teilgenommen habe. Die Organisation war wieder einmal klasse und ich danke Moritz, der diese Veranstaltung immer wieder möglich macht. Mit Sven, Reinhard, Janis und Dominik haben wir uns diesmal als Team super ergänzt. Herausgekommen ist ein Multiplayer Spiel, das mit vier Spielern auf einer Tanzmatte auf einer LED-Matrix gespielt wird. Ein kräftiger Soundtrack erfüllte das Spiel mit Leben, so dass auch mir die ein oder andere Runde durchaus Spaß gemacht hast. 🙂 Mittlerweile gibt es sogar eine Umsetzung für Android. Der nächste Termin steht auch schon fest: am 12. Mai geht es weiter.

Docker auf dem RaspberryPi

Mit HyprioOS gibt es seit einiger Zeit ein Image für den RaspberryPi, das docker container auf den Pi holt. Man muss beachten, dass die docker images für ARM-Architekturen gebaut sind. Davon gibt es aber immer mehr – hypriot selbst stellt bereits einige zur Verfügung. Man kann z.B. mit einem schlanken alpine-Basisimage starten und sich darauf aufbauend mit Hilfe eines Dockerfile den Container für den eigenen Bedarf stricken.

$ docker build -t containername .

Mehrere Container können schließlich zu einem Service zusammengebaut werden. Das macht docker-compose und ein docker-compose-yml-File.

$ docker-compose up

Mehrere Services lassen sich schließlich zu einem Swam zusammenfügen und auf mehrere Pis verteilen. HypriotOS bringt alle wichtigen Tools mit und läuft zuverlässig.

Laptop selbstgebaut

Eigentlich ist es gar nicht so einfach, einen Laptop selbst zusammen zu stellen, da die Einzelkomponenten hochgradig integriert sind. Auf dem 34C3 ist mir jedoch ein Koffer begegnet, der genau diesen Versuch mit einem Rasperry Pi unternommen hat. Neben dem Pi, sind unter dem Plexiglas zwei Powerbanks verbaut, die das Display und den Pi mit Strom versorgen – und das über 16 Stunden lang. Daneben ist noch Platz für ein Steckbrett und kleinere Bauteile. Als mobile Hacking-Stations ist das Gerät also durchaus interessant.

Inspiriert wurde das Projekt von SpyPi, welches den Kofferansatz weitertreibt, mit zusätzlichen Auf- und Anbauten ausstattet ist und Teil einer 2017 fertig gestellten Abschlussarbeit ist. Die Hardware wird unter spypi.ch beschrieben.

USB-Sticks und SD-Karten validieren

Nicht immer funktionieren USB-Sticks und SD-Karten so wie sie sollen. Bei meiner letzten Bestellung aus China hatte ich den Verdacht, dass einige SD-Karten defekt waren – sie funktionierten für einen kurzen Zeitraum und gaben dann den Geist auf. Aus der c’t kannte ich das Programm H2testw, mit dem Flashspeicher geprüft werden kann. Dazu wird das Speichermedium mit Testdaten vollständig beschrieben und die Daten anschließend wieder gelesen. Wenn alles korrekt läuft, stimmen die gelesenen Daten mit den ursprünglich geschriebenen Daten überein. Das kann je nach Größe des Speichermediums durchaus eine Weile dauern.

Für Linux gibt es hierfür das Paket f3, das mit den Programmen f3write und f3read das gleiche tut. Für einen korrekten USB-Stick läuft das Programm wie folgt ab:

$ f3write /media/STICK/
Free space: 196.84 MB
Creating file 1.h2w ... OK! 
Free space: 0.00 Byte
Average writing speed: 6.76 MB/s

Anschließend werden die geschriebenen Daten wieder gelesen.

$ f3read /media/STICK/
                  SECTORS     ok/corrupted/changed/overwritten
Validating file 1.h2w ... 403128/        0/      0/      0

  Data OK: 196.84 MB (403128 sectors)
Data LOST: 0.00 Byte (0 sectors)
          Corrupted: 0.00 Byte (0 sectors)
   Slightly changed: 0.00 Byte (0 sectors)
        Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 7.75 MB/s

 

Patterns und Antipatterns

In dem Vortrag Antipatterns und Missverständnisse in der Softwareentwicklung – Eine Geschichte voller Missverständnisse spricht fefe über Patterns und insbesondere auch Anti-Patterns aus der Sicht von Softwareentwicklern und devOps. Unterhaltsam, kurzweilig, mit einem breiten Themenspektrum und vielen Anekdoten und konkreten Beispielen aus der Praxis gespickt. Sehenswert.

Eindrücke vom 34c3

Der 34C3 ist nun vorbei und die ersten Eindrücke der Veranstaltung sind gemischt aber überwiegend positiv. Nach dem Umzug von Hamburg im letzten nach Leipzig in diesem Jahr war zu erwarten, dass der neue Ort Risiken und Chancen bieten würde. Die Hallen waren sehr groß und ließen für meinen Geschmack zu wenig Raum für kleinere intime Treffen und Gespräche. Häufig war man auf der Suche nach einem Platz, an dem man ungestört hacken arbeiten konnte. Die riesige Halle 2 mit all ihren Hackingspaces, dem Künstlerbereich und der Hardware-Hacking-Area haben dennoch nie einen Hauch von Langeweile aufkommen lassen.

 

In diesem Jahr habe ich mich erstmals als Engel eingebracht. Das empfehle ich jedem Besucher, der dies bisher noch nicht gemacht hat oder sich bisher nicht traute. Es lohnt sich. Man bekommt eine tieferen Einblick in die Veranstaltung und lernt vor allem viele nette Leute kennen.

Nach meiner Wahrnehmung waren in diesem Jahr mehr Künstler, politische Gruppen, Frauen und Kinder auf dem Kongress. Insbesondere die Künstler- und politischen Gruppen verschieben etwas den Fokus – was ich nicht schlecht finde, sich aber in Zukunft als problematisch erweisen kann, sobald Interessen zu stark divergieren. Ich warte das aber zunächst ab, bevor ich mich sorge.

Jetzt beginnt die Nachbereitung, in der viele Ideen und Projekte umgesetzt und die Aufzeichnungen der Vorträge anschaut werden wollen.

Mailboxen, Fidonetz und Netzwerke der 90er Jahre

Auf dem 34C3 gab es den interessanten Vortrag BBSs and early Internet access in the 1990ies – Modems, FIDO, Z-Netz, Usenet, UUCP, SLIP and ISDN. Harald Welte erzählt aus persönlichen Erfahrungen über die frühe Zeit der Modems und Akkustikkoppler der Pre-Internet-Ära. Er erklärt die frühen „Mail“-Programme wie CrossPoint und sinniert über Features, die es nicht in die neue Zeit geschafft haben. Ich kann diese Gedanken sehr gut nachvollziehen. In einer Live-Demo zeigt er aktuelle Mailboxen, über die man heute noch per Telnet oder sogar Telefonleitung zugreifen kann und wundert sich, dass diese noch aktiv genutzt werden. Die Seite Telnet BBS Guide stellt eine ausführliche Sammlung von Mailboxen zusammen.

Besonders spannend fand ich den Gedanken, dass mit dem Einzug des Internet auch der Grad der Selbständigkeit in der Verwaltung der Netzinfrastuktur sank. Mailboxenetze wurden damals vonPrivatleuten organisiert, die ihre Telefonanschlüsse zur Verfügung gestellt und darüber Nachrichten mit anderen Mailboxen geteilt hatten. Mit dem Aufkommen von ISPs ging eine Entmündigung einher, die heutzutage, zumindest teilweise, durch das Freifunkprojekt adressiert wird – jedoch nicht mit der gleichen Wirkmacht, die ein Fidonetz in den 90er Jahren entfalten konnte.