Stranger Than Usual

Ich muss gerade einen meine Raspberry Pis neu aufsetzen. Den mit den Raumklimasensoren. Schuld daran ist ein fehlgeschlagenes Update. Also ein Backup gezogen, ein aktuelles OS-image geladen, das image entpackt, und auf die Karte kopiert:

$ sudo dd if=2025-12-04-raspios-trixie-arm64-lite.img of=/dev/mmcblk0 bs=32M
89+0 records in
89+0 records out
2986344448 bytes (3.0 GB, 2.8 GiB) copied, 9.68393 s, 308 MB/s

Wunderbar. Nur… ich habe keine Tastatur, keine Maus, keinen Bildschirm für das Ding. Ich habe es bisher auch immer headless aufgesetzt. Kein Problem. Ich muss nur irgendwelche Konfigurationsdateien an die richtige Stelle legen, oder? Wie war das noch gleich. Mal eine Internetsuche machen.

Die Ergebnisse sind furchtbar. Alle wollen, dass ich mir irgendein komisches UI-Tool herunterlade, um die SD-Karte zu beschreiben und die Einstellungen zu machen. Aber ich will doch nur die Wifi-Einstellungen, SSH aktivieren, einen public key hinterlegen und die SSH-Config anpassen. Macht das doch nicht komplizierter, als es ist.

Ich weiß noch, dass da irgendwelche magischen Dateien waren, die man an die richtigen Stellen legen musste. Aber welche, und wohin? Da, endlich ein aktuelles Suchergebnis (von 2026), das mir sagt, wohin ich die Datei legen muss, und was drinstehen muss:

Create a new text (.txt) document on your computer, similar to the image below, under the SD Card storage section.

Ok, aber auf der SD-Karte sind zwei Partitionen, die erste, die Bootpartition ('bootfs' laut Gnome) und die zweite, mit dem ganzen Rest (rootfs). Also auf welche muss es? Ist nicht genannt. Aber da ist ein „Screenshot“. Und damit meine ich, dass jemand den Bildschirm abfotografiert hat, auf dem ein Dateimanager geöffnet ist, anhand dessen ich darauf schließen kann, welche Partition gemeint ist. Und dann faselt die Anleitung auch noch irgendwas davon, mit über vscode SSH zu benutzen. Ich würde ein LLM vermuten, aber ein LLM hätte einen besseren Screenshot gemacht.

Ich habe die Schnauze voll. Ich verlinke nicht auf den Artikel. Ich schreibe jetzt meine eigene Anleitung. With Blackjack! And Hookers! Hauptsächlich, damit ich das beim nächsten Aufsetzen eines Raspberry Pis hier wieder nachschlagen kann.

Die Anleitung

Schritt 1: Image herunterladen und aufspielen

Richtiges Image auf der Raspberry-Pi-Seite herunterladen. Dann entpacken (xz -d) und aufspielen (aufpassen, dass man das richtige Gerät für die SD-Karte nimmt:

sudo dd if=2025-12-04-raspios-trixie-arm64-lite.img of=/dev/mmcblk0 bs=32M

Keine Ahnung, ob 32M als block size vernünftig ist, aber irgendwann wird das fertig.

Schritt 2: WLAN-Konfiguration

Hier ist es schwieriger als früher. Früher konnte man einfach eine passende wpa_supplicant.conf.txt (fragt mich nicht, warum da noch ein .txt am Ende ist, ich weiß es wiklich nicht) in der Boot-Partition ablegen, der Pi hat dan den Rest gemacht. Das stand auch in der oben erwähnten Müll-Anleitung. Tatsächlich findet man jetzt aber auf der offiziellen headless-Installationsanleitung (die für mich auch nutzlos ist, weil sie auf diesem UI-tool basiert) folgenden Hinweis:

Previous versions of Raspberry Pi OS made use of a wpa_supplicant.conf file, which could be placed into the boot folder to configure wireless network settings. This functionality isn’t available from Raspberry Pi OS Bookworm onwards.

Danke für den Hinweis. Ich habe auch nicht gerade eine Stunde damit verplempert herauszufinden, warum sich das Teil nicht verbindet. Aber man kann das WLAN ja noch anders konfigurieren. Aber im Ernst: vergesst es.

Ich habe es lange genug versucht. Die WLAN-Konfiguration selber ist noch harmlos. Aber dann muss man noch das WLAN-country setzen (aus regulatorischen Gründen, ich vermute mal es geht darum, welche Frequenzen erlaubt sind). Dieser Artikel einer Informatikerin hat mir sehr weitergeholfen zu verstehen, wie der ganze Krams über die UI konfiguriert wird (der einzige brauchbare Artikel übrigens. Die Autorin hat die Autoconfig auseinandergenommen um zu sehen, wie sie funktionier. Darauf aufbauend konnte ich dann tiefer graben).

Aber wenn man meint, das gesetzt zu haben, ist das WLAN-Modul immer noch durch rfkill blockiert, und um das zu entsperren muss man… naja, ich dachte ich hätte einen Weg, der /var/lib/systemd/rfkill/platform-3f300000.mmcnr\:wlan und ein Kommandozeilenparameter für den Kernel beinhaltete, aber das hat nicht funktioniert.

Die viel einfachere Lösung: Schließt den Pi per Kabel ans Netzwerk an, startet ihn, logged euch ein und konfiguriert das WLAN-Country und das WLAN dann mit raspi-config. Christ on a stick!

Schritt 3: SSH-Konfiguration

Zuerst eine magische Datei in der Boot-Partition (erste Parition, bootfs) anlegen:

touch ssh

Die ist magisch, die braucht keinen Inhalt. Die ist nur dafür da, damit der Pi SSH startet, was er nicht per default macht, weil das gefährlich ist. Und weil das gefährlich ist, müssen wir das absichern. Das geht auf der anderen Partition, rootfs. Dort, wie gewohnt, den eigenen öffentlichen SSH-Schlüssel in /home/pi/.ssh/authorized_keys eintragen.

Dann etc/ssh/sshd_config bearbeiten. Wichtige Zeilen:

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys .ssh/authorized_keys2

PasswordAuthentication no

Diese Zeilen sind per default auskommentiert, PasswordAuthentication sollte man auf no setzen. Niemals SSH mit password authentication!

Schritt 4: Benutzerkonfiguration

Und dann booten und… nicht? Keine Verbindung? Früher konnte man immer darauf verlassen, dass es den Benutzer pi gab. Den gibt es augenscheinlich immer noch, allerdings blockt der Raspberry Pi und meldet sich nicht im Netzwerk an. Es fehlt noch ein Benutzer.

Also noch eine Datei, userconf.txt auf bootfs anlegen. Dort muss dann eine Zeile sein:

pi:<password>

Wobei pi irgendein Benutzername sein kann und <password> ein SHA512-gehashtes Passwort, das kann man mit openssl passwd -6 erzeugen. Ich habe einfach ein sehr langes, zufälliges Passwort gewählt, das man unmöglich raten und das ich mir noch unmöglicher merken kann. Aber ich muss es mir ja nicht merken, ich will mich ja mit meinem SSH-Key anmelden. Fun Fact: Das sudo-Password ist immer noch nicht gesetzt, dafür brauche ich das Passwort also auch nicht.

Schritt 5: Andere Kleinigkeiten

Man kann auch noch /etc/hostname anpassen, um den Hostname des Raspberry Pis zu ändern.

Schritt 6: Booten

Nach dem Booten das Übliche an Raspi-Konfiguration machen (sudo raspiconfig), dann die üblichen Verdächtigen installieren, Daemons beschwören, yadda yadda… Was man halt mit dem Pi so machen will.

Fazit

Meine Güte, haben die es schwierig gemacht, den Raspberry Pi headless aufzusetzen. Über die Jahre wurde es immer schwieriger. Zunächst konnte man noch sagen: Ok, das ist ein Sicherheitsfeature (SSH ist standardmäßig deaktiviert). Aber dass der Pi nicht einmal mehr fertig bootet, wenn man keinen Benutzer angelegt hat, oder dass es praktisch unmöglich ist, das WLAN zu konfigurieren… das ist echt Kacke. Es ist einfach alles grundlos viel komplexer gemacht worden. Ich will doch nur meinen Pi.

Ach ja, und der mittlerweile nicht mehr ganz neue Pi gerät gelegentlich in Bootschleifen. Vermutlich hat das was mit der SD-Karten-Halterung zu tun. Sehr unpraktisch, wenn man das Ding headless startet und nie sicher sein kann, dass es dieses Mal dann endlich korrekt bootet.

Ich bin jetzt am Ende meiner Nerven, aber der Pi läuft. Mal sehen, ob ich zumindest noch schnell die Datenerfassung für das Raumklima wieder angeworfen kriege. Der Webserver zur Anzeige kann dann später kommen.

This morning, I just wanted to look up if one number is a prime number. Lacking a console tool for that, I searched the internet on duckduckgo.com. But the search suggestions threw me off a bit:

Where do the suggestions come from? Are they actual search requests?

Anyway, I found this prime number checker to be useful. It even does a probabilistic check for large numbers.

Regular readers of this blog know that I have some kind of non-sexual fetish for image size optimization. So this morning I stumbled over a recent Mastodon post by Daniel Stenberg:

The SVG logo on the curl.se front page shrunk from 8658 to 2787 bytes with @vsz's magic, with no visual difference!

Cool. SVG optimization! But even cooler: Another person got it down to 898 bytes (883 bytes after removing line breaks) and later to 858 bytes, with only minor visual differences. And that was before using an optimization tool like svgo.

I looked at it, and it looked pretty good. But I still noticed some possible room for improvement: In my experience, <style> elements and style attributes in SVGs can often be replaced by shorter SVG attributes. I had to fiddle around with SVG groups a bit, but in the end I got it down to 800 bytes:

<svg viewBox="0 0 343 103" xmlns="http://www.w3.org/2000/svg">
<g fill="none" stroke="#093754" stroke-width="11.5" stroke-linejoin="round">
<path stroke-linecap="round" d="m51,44c0,0-18,0-20,0-2,0-7-0-10,2-3,2-8,6-10,8C9,56 6,59 6,64 6,68 6,74 6,77c0,4 1,6 4,9 5,4 7,6 10,8 3,2 5,3 11,3 6,0 20,0 20,0
M68,44c0,0 0,41 2,46 2,5 4,6 9,7 3,1 6,1 11,0 8-4 15-10 23-14V97 44
m18,0v53l0-34c0,0 12-11 19-16 2-2 5-3 8-3 3,0 5-0 8,0 4,0 6,1 8,4 2,2 2,6 2,10
m4-38h17v77h-17 34"/>
<path d="M251,89 295,14"/>
<g stroke-width="4">
<circle cx="229" cy="34" r="7"/>
<circle cx="229" cy="66" r="7"/>
<circle cx="247" cy="94" r="7"/>
<circle cx="297" cy="9" r="7"/>
<g stroke="#0f564d">
<circle cx="284" cy="94" r="7"/><circle cx="334" cy="9" r="7"/>
</g>
</g>
<path stroke="#0f564d" d="M287,89 331,14"/>
</g>
</svg>

Optimized with svgo, that goes down to 709 bytes:

<svg viewBox="0 0 343 103" xmlns="http://www.w3.org/2000/svg"><g fill="none" stroke="#093754" stroke-width="11.5" stroke-linejoin="round"><path stroke-linecap="round" d="M51 44H31c-2 0-7 0-10 2s-8 6-10 8-5 5-5 10v13c0 4 1 6 4 9 5 4 7 6 10 8s5 3 11 3h20m17-53s0 41 2 46 4 6 9 7c3 1 6 1 11 0 8-4 15-10 23-14v14-53m18 0v53-34s12-11 19-16c2-2 5-3 8-3h8c4 0 6 1 8 4 2 2 2 6 2 10m4-38h17v77h-17 34"/><path d="M251 89l44-75"/><g stroke-width="4"><circle cx="229" cy="34" r="7"/><circle cx="229" cy="66" r="7"/><circle cx="247" cy="94" r="7"/><circle cx="297" cy="9" r="7"/><g stroke="#0f564d"><circle cx="284" cy="94" r="7"/><circle cx="334" cy="9" r="7"/></g></g><path stroke="#0f564d" d="M287 89l44-75"/></g></svg>

Nice. But on Mastodon, the discussion continued and switched to compression. So I compressed the file, one time with Zopfli and one time with Brotli. The results: 378 bytes with zopfli, 354 bytes with brotli. This is the result, which looks identical to the 858 byte version:

Update 2026-01-11

I noticed that I missed one style=stroke: attribute (for complicated trial-and-error reasons). Originally, my optimized version was 805 bytes in size and 715 with svgo (in contrast to 800 and 709 respectively).

2025 habe ich zum ersten Mal seit 2020 den Advent of Code nicht im Dezember abgeschlossen. Tatsächlich habe ich ihn immer noch nicht abgeschlossen. Das klingt wie ein Fehlschlag. Für mich ist es aber auch ein Erfolg. Warum?

Seit 2018 habe ich jedes Jahr am Advent of Code teilgenommen. Jedes Mal habe ich mir vorgenommen: Wenn es zu stressig wird, höre ich auf. Ich habe es nie eingehalten. Das ging so weit, dass ich schon überlegt habe, 2025 den AoC komplett ausfallen zu lassen. Dann aber hat Eric Wastl angekündigt, nur 12 Tage zu machen.

Also habe ich den AoC trotzdem angefangen. Mittendrin begann dann aber auf der Arbeit ein neues Projekt, und neue Projekte sind am Anfang immer besonders anstrengend (auch, weil man weniger programmiert und mehr von Pontius nach Pilatus rennt um von verschiedenen Leuten alle möglichen informationen zu kommen). Dann kamen zwei schwierigere Tage, und… Ich habe erst einmal aufgehört. Insgesamt habe ich von den Tagen 9 und 10 den zweiten Teil nicht, Tag 12 komplett nicht und Tag 11 erst ein paar Tage nach dem 12. Dezember gelöst.

Und das ist in Ordnung. Zudem sind trotz allem nur wenige Puzzle übrig, so dass ich die vermutlich irgendwann dieses Jahr mal machen kann. Ich wollte auch schon eins auf der Fahrt zum Congress machen, aber im Zug hatte irgendein Kind sein Hörspiel ohne Kopfhörer abgespielt, und das war so störend, dass ich mich nicht konzentrieren konnte.

Trotzdem ein paar Anmerkungen zu den Puzzeln dieses Jahr. SPOILER ALERT: hier werden Lösungsansätze und Geschichte des Advent of Code 2025 behandelt, ihr seid gewarnt.

Im Großen und Ganzen ging es darum, immer tiefer in die Nordpolbasis vorzudringen um alles zu dekorieren, während man hier und da helfen konnte und auch mal einen Gabelstapler durch eine Wand fahren durfte.

Tag 1 war wieder ziemlich einfach, es ging darum, zu zählen, wie oft ein Rad an einer Nullstellung vorbei kommt. Off-By-One Fehler sind hier naheliegend, aber schwierig ist das nicht mit ein bisschen Modulo.

Tag 2 war auch einfach, es ging darum, Zahlen nach bestimmten Mustern herauszufiltern.

Tag 3 war auch wieder einfach, wenn man minimal mit Zahlen umgehen kann.

An Tag 4 durfte man dann nach einem einfach Puzzle den Gabelstapler durch die Wand fahren.

Tag 5 war auch wieder einfach, solange man Subtraktion beherrscht und keinen Zaunpfahlfehler macht. Wenn man Subtraktion nicht beherrscht, könnte man hier ziemlich lange dran rechnen.

Tag 6 hatte hauptsächlich die Schwierigkeit, ein ungewöhnliches Input-Format zu parsen, um mal wieder jemandem bei den Mathehausaufgaben zu helfen.

An Tag 7 wurde es langsam interessant. Teil zwei benötigte ein bisschen Denken, um nicht viel zu viel Rechenzeit zu verschwenden.

An Tag 8 habe ich es mir leicht gemacht und einfach eine ganze Menge Werte gespeichert und sortiert.

Tag 9 war der erste Blocker. Teil 1 war noch ziemlich einfach. An Teil zwei bin ich erst an der Geometrie gescheitert, und dann ist mir die Zeit ausgegangen. Trotzdem ist Teil 2 vermutlich nicht so schwer.

Tag 10 war ähnlich: Teil 1 war einfach, Teil 2 war im Prinzip ein lineares Gleichungssystem, mit mehreren Lösungen. Die Koeffizienten sind alle 1, aber ich muss die Summe der Variablen minimieren. Primitive Methoden rechnen hier ewig, ich muss mir noch einen mathematischeren Ansatz überlegen.

Tag 11 war irgendwas mit gerichteten azyklischen Graphen und Kombinatorik. An sich ganz einfach, wenn darauf achtet, dass in Teil 1 der Startknoten nicht der erste Knoten des DAG ist.

Tag 12 habe ich noch nicht gemacht, sieht aber irgendwie aus wie ein Variante 2D-Knapsack-Problem. Hoffentlich aber nicht, denn das könnte eine ganze Weile dauern, das zu berechnen. Es sei denn, gerade diese Variante ist ein Spezialfall, für den es eine bessere Lösung gibt.

Satire ist tot. Auf office.com zeigt Microsoft jetzt folgendes an:

Ich bin letzte Tage auf das Konzept von Stone Websites gestoßen, und zwar dank diesem Blogpost, der das Thema erläutert. Beide beziehen sich auf den Artikel „This Website is designed to last“. Es dreht sich also um die Langlebigkeit von Websites.

Ich werde das hier nicht alles wiederholen, lest am besten die verlinkten Posts selber durch. Ich mache hier nur eine Schnellzusammenfassung und gebe meinen Senf dazu. Es geht darum, dass Websites dauerhaft sein sollen, damit man auch Jahrzehnte später noch die Informationen darin lesen kann. Man hat damit also „Stone Websites“, das digitale Äquivalent davon, Texte in Stein zu meißeln.

Dafür hat Caio Lente ein paar Regeln aufgestellt:

1. Use pure HTML/CSS.
2. Don’t minimize HTML.
3. Prefer one page over many.
4. Stop hotlinking.
5. Use native fonts.
6. Compress your images.
7. Reduce the risk of rotten links.

Use pure HTML/CSS

Kein Javascript, kein Webassembly, keine dynamisch geladenen Inhalte. Keine Abhängigkeiten. Das ist nicht immer machbar, aber wo es machbar ist, ist es gut. Mein Blog benutzt auch kein Javascript. Ich würde die Regel erweitern: Wenn Javascript, dann sollte es die Funktionalität der Website nicht beeinträchtigen, wenn es fehlt. Höchstens sollte dann ein paar Komfortfunktionen wegfallen. Ich habe mich schon vor 15 Jahren über Javascriptabhängigkeit aufgeregt. Ich habe seitdem beruflich gezwungenermaßen an Single-Page-Apps gearbeitet, die ohne Javascript nicht einmal eine Überschrift anzeigen konnten. Aber das ist eine andere Geschichte.

Wichtig ist: Je weniger komplex eine Website ist, desto einfacher wird es, sie über einen langen Zeitraum zu erhalten. In diesem Blog hatte ich zum Beispiel schon nach ein paar Jahren Ärger mit Ruby on Rails, während mein static site generator seit Jahren zuverlässig läuft und mein Blog weiter bestehen kann, selbst wenn der Generator über Nacht aufhören würde zu arbeiten.

Don't minimize HTML

Die Idee ist, dass minimalisiertes HTML (ohne technisch überflüssige Leerzeichen wie z.B. Einrückungen) schwieriger zu lesen, schwieriger zu debuggen und damit schwieriger zu warten ist, aber (wenn es auch noch komprimiert wird), kaum kleiner ist.

Ich sehe den Punkt. Aber als Gegenargument: Es ist wirklich leicht, einen HTML-Formatter zu finden (oder zu schreiben), besonders, wenn man gültiges HTML geschrieben hat. Man kann also jedes minifizierte HTML ohne Probleme wieder lesbarer machen.

In diesem Blog erzeugt die HTML-Template-Bibliothek automatisch HTML mit minimalen Leerzeichen. Einzig der Markdown-Renderer fügt regelmäßig Zeilenumbrüche (aber auch keine Einrückungen ein). Ich sehe da kein großes Problem.

Wenn ich mir mein CSS anschaue… Das ist eine andere Sache. Ich nutze derzeit SCSS, auch wenn ich es für diese Seite eigentlich nicht brauche. Das ist natürlich auch eine Abhängigkeit, aber es hat auch den Nebeneffekt, dass mein CSS minifiziert wird, und ich als Kompressionsfetischist will bei meinen knapp 2.2 kiB (686 Byte Brotli-komprimiert) jedes Byte einsparen!

Prefer one page over many

Es geht darum, dass eine Seite leichter zu warten ist als mehrere, und man leicht die Links dazwischen zerstört. Mein Blog hält diese Regel absolut nicht ein. Kategorienseiten, Tag-Seiten, Archivseiten, jeder Blogpost hat noch eine Seite, und es gibt die Seiten für die Quotes… Dank meines statis site generators alles gut managebar, aber sollte der einmal aufgeben (z.B. weil die Abhängigkeiten offline genommen werden), hätte ich ein Problem.

Stop Hotlinking

Hotlinking, also direktes Einbinden von Inhalten anderer Seiten (Bilder, Style-Dateien, Schriftarten, Javascript, you name it) sorgt dafür, dass deine Seite kaputt geht, wenn die Seite, auf die du verlinkst nicht mehr existiert oder ihre URLs ändert. Außerdem ist es ein potentielles Sicherheitsrisiko, wenn ein Angreifer eine der toten Links übernimmt und darüber z.B. gefährliches Javascript in deine Seite einschleust.

Dieses Blog hat kein Hotlinking. Direkt eingebundene Resourcen liegen auf demselben Server wie das Blog, ansonsten wird regulär verlinkt. Wenn dann die Seite dahinter kaputt geht, habe ich zwar einen toten Link, aber ansonsten ist meine Seite nicht beeinträchtigt.

Use native fonts

Heutzutage kann man einfach Schriftarten vom Server laden, wenn sie auf dem Zielrechner nicht existieren. Früher musst man hoffen, dass die Schriftart existiert, deswegen wurde oft geraten, sich auf Fonts zu verlassen, die auf praktisch jedem Rechner zu Verfügung stehen, oder man hat einfach Font-Familien angegeben (z.B. „serif“).

Heutzutage kann man Schriftarten dynamisch laden, aber sie neigen dazu, auch komprimiert noch groß zu sein. Zudem wird häufig die Hotlinking-Regel verletzt, wenn man sie z.B. von Google lädt.

Generell ist es eine gute Idee, eine Website so zu bauen, dass die auch dann gut aussieht, wenn nicht genau die richtige Schriftart gefunden wurde. Dieses Blog ist da recht unkompliziert, lädt keine Schriftarten nach und sieht selbst in einem textbasierten Browser noch in Ordnung aus.

Compress your images

Da rennt er bei mir offene Türen ein. Ich bin ein Kompressionsfetischist. Ich habe dazu oft genug geschrieben. Hat aber imho weniger mit Langlebigkeit zu tun, außer, dass die Seite dann einfacher zu archivieren ist.

Lustig ist, dass Lente zwar gegen HTML-Minimierung ist, aber SVG-Minimierung stark empfiehlt, wobei minimierte SVGs praktisch nicht mehr in eine gut lesbare Form zurückgewandelt werden können.

Reduce the risk of rotten links

Hier geht es darum, Warnmechanismen aufzubauen, falls bestimmte Pages oder die ganze Seite nicht mehr erreichbar ist. Habe ich nicht, aber wäre vielleicht mal wert, darüber nachzudenken. Auch, was externe Links angeht.

Aber was ist mit dem Server?

Meine Seite kann, meiner Meinung nach, rein technisch noch Jahrzehnte bestehen. Die größte Gefahr ist, dass aus irgendwelchen Gründen mal mein Server abgeschaltet wird (z.B. weil ich keine Lust mehr habe, ihn mir nicht mehr leisten kann oder mir etwas zugestoßen ist). In diesem Fall wäre die Seite weg.

Ich archiviere grundsätzlich jeden neuen Blogpost hier auf archive.org. So sind diese Posts auch noch verfügbar, wenn diese Seite nicht mehr existiert. Weil ich die Seite minimal gehalten und die Bilder gut komprimiert habe, nimmt sie dort auch nicht zu viel Speicher weg und kann im Gegensatz zu single-page-apps auch sehr effektiv archiviert werden.

So, das hier wird vorerst der letzte Post zum 39C3. Ich habe zwar noch zwei bis drei kleine Themen auf Lager, aber dafür muss ich erst einmal von anderer Seite Input kriegen.

Ich wollte noch ein paar Eindrücke, Erfahrungen und Ähnliches vom 39C3 posten. Dinge, die sonst nirgendwo hereingepasst haben. Das kommt jetzt.

Glatteis

Besonders an Tag 0, wo ich noch nicht auf dem Congress war, sondern erst abends in Hamburg angekommen bin, aber auch an den folgenden Tagen war es draußen sehr glatt. Die Art von Glätte, bei der der Boden nur feucht aussieht, aber gefährlich rutschig ist. Ich habe den Tag über schon Glättewarnungen auf Mastodon gesehen. In Hamburg angekommen war ich also vorgewarnt. Ich habe, beladen mit zwei schweren Taschen, nur kleine Schritte gemacht. Das hat eine Ewigkeit gedauert, aber ich bin sicher angekommen.

Damit sich auch sonst niemand verletzt, gab es auch dem Congress auch Warnhinweise, wie zum Beispiel diesen hier:

Assembly-Haltestellen

Die Schilder für die Assemblies waren dieses Mal im Stil von Bushaltestellenschildern:

Sampleflut

Analog zu Pixelflut gab es dieses Jahr auch Sampleflut. Anstelle auf einen Canvas zu schreiben schreibt man hier in einen Audiobuffer, der dann abgespielt wird. Ich selber habe es aber nicht gespielt.

Coaxolotl

Bei einer Assembly gab es verschiedene Kreaturen, die aushingen. Darunter dieser Coaxolotl (das Licht war komisch, ich habe die Farben nachträglich angepasst, damit man mehr erkennt):

Die anderen Kreaturen habe ich nicht fotografiert.

Creaturedex

Nach und nach tauchten auch andere Kreaturen auf. Sie hatten einen RFID-Chip und man konnte sie scannen, um seinen Creaturedex zu vervollständigen. Das Schöne: Jeder konnte Kreaturen hinzufügen. Ich habe das Spiel nicht gespielt, aber wenn es nächstes Jahr wieder so etwas gibt, möchte ich es mal ausprobieren.

Cheat Sheet

Der Congress ist immer etwas unübersichtlich. Glücklicherweise gab es ein cheat sheet:

Gestickte Karte

Es gab aber auch ernsthaft hilfreiche Informationen. So gab es zum Beispiel eine gestickte Karte für Sehbehinderte:

Eine interessante Geschichte dazu habe ich erst auf der Closing Ceremony erfahren: Das c3tactile-Team hatte alles Mögliche mitgebracht, aber die 3D-Gebäudekarte vergessen. Da ist dann eine Assembly mit Stickmaschine in die Bresche gesprungen und hat einfach gestickte Pläne gemacht, die man mit den Händen lesen kann.

Vehikel

Es ist kein vollständiges Chaosevent, wenn nicht zumindest eine Person mit einem schrägen, selbstgebauten Vehikel herumfährt. Sei es ein Matekasten, ein Sessel oder ein Landkajak. Dieses Jahr war es ein recht einfaches Gefährt:

Immerhin weiß ich jetzt, dass diese Aludinger mir den Rillen „Aluminiumprofilrahmen“ heißen.

Klopferlight

Ein weiterer häufiger Gast auf Chaosevents sind LED-Matrizen in irgendeiner Form. In diesem Fall wurden kleine Schnapsfläschchen (der Marke „Klopfer“) verwendet:

Diese Installation heißt passenderweise Klopferlight. Der Hacker, der das gemacht hat hat direkt zwei davon gebaut, man kann auf denen auch kompetitiv Tetris spielen. Er hat auch nicht alle 400 Klopferflaschen ausgetrunken, er hat sich einfach eine größere Menge davon ohne Füllung gekauft.

Creature ChroniCles

Dann gab es das Creature ChroniCles-Projekt. Das hat am Anfang für ein bisschen Wirbel gesorgt, wegen der Foto-Policy (keine Fotos von Personen ohne explizite Einwilligung). Das Projekt lässt sich aber sicher auch mit der Fotopolicy durchführen. Die Idee war: Hacker_innen fotografieren und dann die Körper mit allen möglichen interessanten Kreaturen übermalen, so dass man die Person nicht erkennt.

Am Ende sind nur ein paar Bilder herausgekommen. Ich würde mich aber für dieses Projekt fotografieren lassen :)

Pacman-Bar

Ein paar Sachen waren auch im Klassichen Geek-Stil dekoriert, wie z.B. dieser Bartresen:

Das war's

Damit ist die Reihe von Posts über den 39C3 auf diesem Blog fast abgeschlossen. Mir hat der Congress dieses Mal außerordentlich gut gefallen und ich hoffe, ich kann auch nächstes Jahr wieder dabei sein.

An Tag 1 auf dem 39C3 ist mir dieser Aushang untergekommen:

Nun bin ich ein großer Fan von Terry Pratchett und den Scheibenweltromanen. Die Klacker (wie die einzelnen Geräte genannt werden, weil sie wegen der sich öffnenden und schließenden Klappen ständig klappern) kenne ich natürlich. Der „Grand Trunk“ ist in der deutschen Übersetzung der „Große Strang“, das Netzwerk dieser Klacker bzw. die Firma, die sie betreibt.

Das einzige Problem: Da stand kein Klacker. Naja, es war Tag 1, vielleicht kommt ja noch etwas. Und tatsächlich: An Tag 4 standen dort dann zwei Kästen, bei einem bewegten sich auch die Klappen:

Was man auf dem Bild nicht sieht: Oben auf dem Kasten ist noch eine Kamera angebracht.

Wirklich viel passiert ist da aber nicht. Später am Tag habe ich dann die Person erwischt, die das aufgestellt hat (Nickname „nomis“). Nomis hat mir erzählt, dass er nicht ganz fertig geworden ist, und dass er noch eine Weile daran arbeiten wird. Bis zum nächsten Congress sei es auf jeden Fall fertig, aber ob er da noch einen Stellplatz bekommt, sei dahingestellt.

Ich jedenfalls hoffe sehr, dass er den bekommt, denn ich möchte das Ding gerne in Betrieb sehen. Ach ja: Die Klacker sind auch die Inspiration für GNU Terry Pratchett.

Heute ist der erste Digital Independence Day (ich hatte letzte Woche schon davon berichtet). Wird das was bringen? Ich weiß es nicht, aber ich probier das einfach mal aus.

Für heute habe ich das Repo dieses Blogs von Github nach Codeberg verschoben. Dazu habe ich mir auch einen Account auf Codeberg eingerichtet, was es für mich einfacher macht, zukünftige Entwicklungen auf Codeberg zu machen. Ich habe nicht alle meine Repos migriert, aber das Blog-Repo ist mit Abstand das meistbenutzte davon. Meinen Github-Account behalte ich auch, weil viele andere Projekte über Github laufen, wenn ich da also etwas einreichen möchte, brauche ich Github.

Warum weg von Github?

Github war eigentlich eine gute Software. Was mich immer gestört hat war, dass die dahinterliegende Software keine freie Software ist. Nachdem Github 2018 von Microsoft aufgekauft wurde, war ich schon ein bisschen besorgt. Viele sind damals schon z.B. zu Gitlab gewechselt. Ich habe das Repo bei Github behalten. Wenn es zu nervig wird, konnte ich ja immer wechseln, ich benutze ja keine speziellen Github-Funktionen.

Dieses „wenn es zu nervig wird“ war nie ganz erreicht, auch wenn Github auf anderen Projekten wohl massiv mit LLM-Agenten genervt hat. Für mich selber hat es den Digital Independence Day gebraucht, um zu einer freien Alternative zu wechseln.

Warum nicht Gitlab?

Die Gitlab-Software steht zwar unter einer freien Lizenz (zum Selbsthosten), aber gitlab.com ist mir in der Vergangenheit negativ aufgefallen. Selber hosten möchte ich nicht, also wurde es Codeberg, das mit der ebenfalls freien Software forgejo läuft.

Fazit

Es ist nur eine Kleinigkeit, aber sie öffnet für mich ein paar Türen, weiter von Github bzw. Gitlab wegzukommen. Für alle anderen: Überlegt doch mal, was ihr zum nächsten Digital Independence Day macht. Das ist immer der erste Sonntag im Monat, der nächste ist also am 1. Februar.

Und wenn ihr wollte, dass die freien Alternativen auch durchhalten, überlegt doch mal, ob ihr nicht spenden wollt. Für Codeberg zum Beispiel kann man hier spenden.

Auf dem 39C3 sind mir auch zwei handgemalte Aushänge untergekommen von einer Person, die einen Daniel suchte. Halt, nein, nicht irgendeinen Daniel, es musste der richtige sein:

Der zweite Aushang hatte sogar ein Phantombild:

Ich habe keine Ahnung, was das war, aber ich hoffe, dass die suchende Person ihren Daniel gefunden hat.