Stranger Than Usual

Notizen von Congressen und Camp

Ich war seit 2015 jedes Jahr auf dem Chaos Communication Congress. Sofern der statgefunden hat, es gab da drei magere Jahre wegen der COVID-19-Pandemie. Letztes Jahr war ich auf auf dem alle vier Jahre stattfindenden Chaos Communication Camp (ich habe dazu auch gelegentlich etwas geschrieben, über die Tags am Ende des Artikels sollte das auffindbar sein).

Ich habe mir bisher jedes Jahr Notizen gemacht, zu vielem was ich dort interessant fand. Die meisten Notizen habe ich hinterher nicht mehr gelesen, das war so ein bisschen wie mit Spickzetteln: Alleine dass man es aufgeschrieben hat sorgt dafür, dass man sich besser erinnern kann. Ein paar dieser Notizdateien habe ich heute noch irgendwo herumfliegen.

Dieses Jahr ist der 38C3, und ich habe es mit Müh und Not geschafft, ein Ticket zu bekommen. Es geht also wieder los. Und da mir gestern noch einmal eine der Notizdateien von vergangenen Congressen aufgefallen ist, dachte ich mir, ich schreibe hier einfach mal, was da so drin stand. Leider habe ich nocht alle Dateien gefunden, und ich erinnere mich auch, manche dieser Dateien bearbeitet zu haben (i.d.R. weil es eine Art ToDo war und ich das abgehakt hatte). Personenbezogene Daten schreibe ich hier natürlich auch nicht hin. Als Bonus gibt es aber zu den Congressnotizen auch Notizen vom Chaos Communication Camp letztes Jahr.

In allen Fällen kann es sein, dass ich über die Sachen in diesem Blog schon einmal geschrieben habe. Dann wiederhole ich mich halt. Der Inhalt hier ist auch wild durcheinandergewürfelt, wer einen gut geschriebenen Artikel möchte, sollte diesen hier nicht lesen.

33C3

Von meinem ersten Congress, dem 32C3, habe ich leider keine Notizen mehr gefunden. Vielleicht sind die noch irgendwo, aber nicht da, wo ich gesucht habe. Also direkt zum 33C3. Die Notizen sind meist Stichpunkte, weil ich sie schnell auf einem Smartphone geschrieben habe. Ihr kriegt die Version mit etwas Interpretation meines heutigen Ichs:

  • „kein Spiel“: Hier ging es darum, dass es auf dem 33C3 kein Spiel gab. Ich bin ständig Leuten begegnet, die herumgelaufen sind und es nicht gespielt haben. Ich selber habe mich aber nie näher damit beschäftigt, kann also nicht mehr dazu sagen
  • anscheinend war mir das Matrix-Protokoll damals neu, ich hatte mir das aufgeschrieben, um mich damit auseinanderzusetzen. Der 38C3 hat übrigens auch einen Matrix-Chat
  • „löten“: Ich wollte mich mal wieder mehr mit Elektronik beschäftigen, oder einfach auf dem Kongress etwas zusammenlöten
  • „n26“: Es gab einen Vortrag zu Sicherheitslücken bei N26, einer reinen Online-Bank
  • fairSIM, ein Projekt zu freien Algorithmen und anderen Resourcen zu Structured Illumination Microscopy. Davon habe ich wohl in einem Vortrag, möglicherweise auch in einem lightning talk gehört und fand es cool.
  • greenlightformakers.org
  • „feinstaubmessung“, ich glaube, da ging es um förderierte Feinstaubmessungen, möglicherweise luftdaten.info
  • „attraktor hamburg“, ein Makerspace in Hamburg. Ich wollte mir das mal anschauen. Ich habe siebeneinhalb in Hamburg gelebt und habe das nie durchgezogen. Ich erinnere mich, dass die an der Assembly des Attraktors eine Live-Cam von einem Ameisennest in irgendeinem Blumenkübel hatten.
  • spresso.me, ein dezentraler, datenschutzfreundlicher single sign-on. Hauptproblem bis heute: fast keine Seite, bei der man sich mit SSO einloggen kann, unterstützt das.
  • „http referrer“ – keine Ahnung, warum ich das aufgeschrieben habe. Vermutlich, um mal Datenschutzkrams zu checken
  • ein paar Links zu Seiten, die jetzt tot sind und ich habe keine Ahnung mehr, was das war
  • einen Raspberry Pi mit Power over Ethernet betreiben
  • „ingenico coupon security“ – vermutlich habe ich von irgendwelchen Sicherheitsproblemen mit Gutscheinen oder bei Ingenico gehört. Da unser Kunde auch Ingenico-Geschenkkarten benutzt, wollte ich da wohl was überprüfen
  • Maker Faire Ruhr. Ich bin nie da hingegangen
  • ich wollte mir mal die Food Hacking Base-Assembly anschauen
  • nach einem Vortrag (oder lightning talk) wollte ich mir mal wieder das von der Anno-Reihe inspirierte Spiel Unknown Horizons anschauen
  • dasselbe gilt für openage, nur kann ich mich hier noch an Fetzen des Talks erinnern, es ging um das Format, indem sie Daten abgelegt haben so dass das Spiel gut modifizierbar ist. Heute wird openage auf der Website nicht mehr als von Age of Empires inspiriertes Spiel präsentiert, sondern als „cross-platform RTS game engine that provides the mechanics of Age of Empires“. Scheint, als wären sie noch mehr in die Richtung von „gut modifizierbar“ gegangen.
  • tomu.im „a group of tiny boards designed to fit inside your USB port“. Daran erinnere ich mich überhaupt nicht mehr, aber ich verstehe, warum ich mir das aufgeschrieben habe
  • keyless klau, über unsichere elektronische Schließsysteme, speziell Keyless-Go/Keyless-Entry bei Autos
  • Techniktagebuch, ein Blog, dass ich mir noch anschauen muss.
  • ein Twitter-Benutzername. Bei der Shitshow, die Musk aus Twitter gemacht hat, traue ich mich nicht, nachzuschauen (ohne Login kriegt man sowieso nicht mehr viel angezeigt)
  • „datassette“ – vermutlich steckte dahinter mehr als nur ein plötzliches Interesse an diesem archaischen Speichermedium
  • lisamission.org LISA: „Laser Interferometer Space Antenna“. Auf dem 33C3 gab es eine Menge Astronomie- und Raumfahrttalks
  • „Michael Büker (Buch)“ Der Typ ist Wissenschaftskommunikator, ich glaube, ich habe nie eins der Bücher gelesen
  • Damals war gerade meine Leidenschaft für rust entflammt, und Dropbox hatte gerade berichtet, gute Erfahrungen mit rust gemacht zu haben
  • neveragain.tech, eine Absichtserklärung von Angestellten von US-Technikunternehmen, ihre Unternehmen dazu zu bringen, Datensparsam zu betreiben, insbesondere im Rückblick auf die Tatsache, dass IBM mit ihren Lochkartenmaschinen geholfen haben, den Holocaust zu organisieren

34C3

Uff… so viele Erinnerungen, so viele interessante Dinge, die ich nie weiter verfolgt habe… Naja, die Notizen vom 34C3 sind, glücklicherweise oder unglücklicherweise, deutlich kürzer

  • Der Lizenzhinweisgenerator, um korrekte Lizenzhinweise für CC-lizensierte Inhalte von Wikipedia zu erzeugen
  • ein Hinweis zu interessanter eInk-Technik (mittlerweile veraltet)
  • „ipfs“ „Interplanetary File System“, in dem Jahr hatte die katalanische Piratenpartei das genutzt, um gesperrte Websites zum katalanischen Unabhängigkeitsreferendum online zu halten
  • Borg Backup, damals war ich auf der Suche nach einem brauchbaren Backup-Tool
  • Telefonnummern (Congressintern) und Matrix-Adressen von Freunden und Bekannten auf dem Congress
  • PrivacyScore, ein Tool, um Datenschutz auf Websites abzuschätzen. Das Projekt sieht zuemlich tot aus, seit Jahren (seit 2018) ist nichts daran passiert
  • ein Hinweis auf das Buch „Dinge geregelt kriegen - ohne einen Funken Selbstdisziplin“ von Kathrin Passig und Sascha Lobo
  • eine Erinnerung, dass ich endlich meinen Freifunkrouter aufstellen muss, der seit Jahren in meiner Wohnung Staub sammelt

Chaos Communication Camp 2023

Für den 35C3 und den 36C3 habe ich keine Notizen gefunden. Also springen wir fünfeinhalb nach vorne, zum Chaos Communication Camp. Hier weiß ich, dass ich ein paar erledigte Sachen gelöscht habe, aber ich habe ja auch schon mehrere Artikel über das Camp geschrieben.

  • Dect-Nummern von Freunden und Bekannten
  • basebanana.org, benutzt „banana words“ (Wörter, in denen alle Silben aus einem Konsonanten und einem Vokal bestehen, so wie „Banane“) um Nummern, Zahlen oder ähnlich schwierig zu merkende Daten in ein einfach auszusprechendes Wort zu übersetzen (und zurück). Ich wollte das mal in Rust implementieren, bin aber bisher noch nicht dazu gekommen.
  • Notizen zu lightng talks, die ich nicht mehr einordnen kann
  • Open Steno Project, ein Projekt, Stenografie freier und zugänglicher zu machen
  • StopDataPorn, eine Initiative, Daten über sexuelle Vorlieben von Internetnutzern besser zu schützen
  • ich hatte zwei Mal das Wort „hanggliding“ ohne Kontext und habe keine Ahnung, was ich damit gemeint habe
  • ein lightning talk über bug bounty triage, eine Hackerin, die gemeldete Bugs überprüfen muss, ob sie einer Bug Bounty würdig sind
  • Datenschutzmythen
  • „chatkontrolle“
  • Notizen von einem Workshop zu Pen & Paper-Rollenspiel-Sicherheit bei den Haecksen, wenn ich das richtig verstanden habe ist die Haeckse, die den Workshop gemacht hat, auch am Podcast „Plus 1 auf Podcast“ beteiligt. In den Podcast muss ich einmal reinhören
  • Notizen zu den Hackern, die bei Chaos West die Anstecker gemacht haben, vermutlich, damit ich ihnen eine Karte per Chaospost schicken konnte
  • Verweis auf einen WLAN-Ausfall (oder Netzwerkausfall allgemein?) gegen 21:00 Uhr an Tag 4. Am nächsten Tag stellte sich heraus, dass die Italian Hacker Embassy dafür verantwortlich war
  • Tipps vom LaTeX-Helpdesk zu meinem persistenten Problem, dass ich keine vollständige Unicode-Unterstützung in LaTeX kriege. Hinweis: Mit spezieller Schriftart müsste das gehen, bei luatex eigentlich sogar out of the box

37C3

  • Links zur Euclid-Mission
  • vermutlich nach einem Talk zum Extremely Large Telescope (hieß früher „European Extremely Large Telescope“, bis jemandem aufgefallen ist, dass es nicht in Europa steht sondern in Südamerika): Der Hinweis, dass die Leute von dem Talk bei der SFT Assembly zu finden seien. Ich kann mich nicht erinnern, mit ihnen gesprochen zu haben, vermutlich habe ich sie nicht gefunden
  • „kill your phone workshop“, wo man sich eine Abschirmung für sein Smartphone zusammennähen kann. Nicht gegen irgendwelchen geschwurbelten Elektrosmog, sondern als Privacy-Tool
  • Stichworte, mit denen ich nichts mehr anfangen kann (wie immer)
  • meine Dect-Telefonnummer
  • Stichpunkte aus den lightning talks, darunter
    • InvenTree, eine OpenSource Inventar-Management-Software für Firmen und Privatanwender
    • saildart.org
    • Pocket Science Lab, ein Sammelsurium von Messgeräten auf einem Board, kann mit Smartphones verbunden werden, mit normalen Computern und die neueste Version kann auch ohne Verbindung Daten sammeln, um sie dann später abzufragen. Entwickelt von FOSSASIA. Klingt cool, ich will mir noch eins besorgen, das neue Modell konnte man damals aber noch nicht bestellen
    • Nationale Forschungsdateninfrastruktur](https://www.nfdi.de/)
    • „task tracker systems“, vermutlich jemand, der über task tracker geredet hat?
    • FIM, ein image viewer, der mit sehr verschiedenen Outputs arbeiten kann
    • analog computer
    • Das @all-Kollectiv
    • lernOS
    • der Schlüsseltechnologie-Podcast
  • ein Haufen ToDos, teils für den Congress, teils für die Zeit danach, die ich mittlerweile größtenteils abgearbeitet habe, darunter auch ein Verweis auf den Ultimate Gameboy Talk vom 33C3, den ich zufälligerweise unabhängig davon vor Kurzem endlich angeschaut habe.
  • Digitaldruide, eine Parodie auf Esoterik-Shoppingseiten, die bieten z.B. Code-Segnungszertifikate an. Dazu gab es eine Menge Aushänge auf dem Congress
  • und eine ToDo-Liste, was ich für den nächsten Congress vorbereiten muss. Ganz oben steht natürlich Pixelflut

Advent of Code 2024

Es ist wieder Advent of Code. Das heißt 25 Tage jeden Tag ein Programmierpuzzle während man Santas Elfen dabei zusieht, die Dinge auf eine etwas… eigene Art zu erledigen.

Nachdem man in den letzten Jahren Schnee machen, den Schlüssel von Santas Schlitten vom Meeresgrund fischen, Rentierfutter besorgen oder Santa vom Rand des Sonnensystems retten musste (und in einem Fall einfach mal Urlaub machen wollte), muss man dieses Jahr Santas Chefhistoriker finden, der sich irgendwo in der Weltgeschichte herumtreibt.

Das erste Puzzle war wie üblich einfach, und üblicherweise steigt die Schwierigkeit im Laufe des Monats im Schnitt an, die Puzzle sind also sowohl etwas für Programmieranfänger als auch für erfahrene Programmierer. Alle Puzzle können mit zehn Jahre alter Hardware in 15 Sekunden lösbar sein. Es gibt also immer eine halbwegs effiziente Lösung.

Man kann die Puzzle in jeder Programmiersprache (und theoritisch auch auf vöölig andere Weise als Programmieren) lösen. Ich schreibe meine Lösungen wir üblich in Rust, meine Lösungen sind wie üblich auf GitHub (falls mich jemand fragt: „Warum GitHub?“, die Antwort ist: Konsistenz. Meine anderen Advent of Code-Lösungen sind halt da. Neuere Projekte packe ich üblicherweise woanders hin).

Es gibt übrigens wie in den letzten Jahren auch Advent of Code-Comics von Gary Grady. Früher hat er die auf Twitter getweeted, mittlerweile ist Grady glücklicherweise auf Mastodon umgestiegen.

Advent of Code-Visualisierungsgif

Ein Highlight des Advent of Code-Community sind ja Visualisierungen der Puzzle. Bei manchen Puzzlen ist das naheliegender, bei anderen weniger. Manche Visualisierungen sind sehr konkret auf das Problem bezogen (z.B. der Pfad durch einen Irrgarten), andere eher abstrakt (z.B. das Verhalten von Knoten einer Graphendarstellung des Problems). Manchmal kann man den Lösungsweg an der Animation gut sehen, manchmal sieht man einfach nur eine Darstellung der Lösung. Auch der Stil unterscheidet sich erheblich, von bunten Puxeldarstellungen über Sprite-basierte Grafiken bis hin zu 3D-Grafiken.

Heute habe ich jemanden gefunden, der animierte Darstellungen aller bisherigen AoC-Puzzle als GIF-Dateien erstellt hat. Es lohnt, sich das anzuschauen. Viel Spaß!

Kann das hier mal jemand der CDU/CSU zeigen?

Die gesamte Politik ist in den letzten Jahren ja nach rechts gerückt. Im verzweifelten Versuch, der AfD Herr zu werden rücken die anderen Parteien, allen voran CDU und CSU immer weiter nach rechts. Die Idee: Die Themen der AfD aufgreifen, damit die Wähler wieder die CDU wählen anstatt der AfD.

Wie Politikwissenschaftler aber immer wieder gezeigt haben: Das funktioniert nicht. Die Wähler denken sich dann: „Oh, vorher wollte ich die AfD nicht wählen, weil sie zu extrem war. Aber die CDU hat die gleichen Themen, also ist das ja nicht extrem. Da kann ich dann ja auch die AfD wählen.“ Oder anders: Rechtsradikalität wird gesellschaftsfähig, da wählen die Leute lieber das Original.

Das hat auch die AfD selber erkannt. Die halten sich für „koalitionsfähig“. Kann jemand das den anderen bitte sagen? Ach warte, denen wurde das schon gesagt.

Ich frage mich, welche von den noch demokratischen Parteien als erste auf Landes- oder Bundesebene umkippt und mit der AfD koaliert. Ich würde ja auf CDU/CSU tippen. Und dann werden einige Leute hier in Deutschland ein böses Erwachen haben, die sich dachten, es wird schon nicht so schlimm mit der AfD. So wie die Trumpwähler, die nach der Wahl gegoogled haben was eigentlich Zölle sind und wie sie die Lebensmittelpreise beeinflussen.

Daniel Stenberg über IDN oder: Mehr Unicode-Weirdness

Daniel Stenberg (der Maintainer von curl) hat einen lesenswerten Artikel über International Domain Names (IDN) geschrieben. IDN sind Domainnamen mit Unicode code points außerhalb des ASCII-Bereiches.

Er konzentriert sich in dem Artikel auf Homoglyph-Attacken (er nennt die Homograph-Attacken, ich habe im Netz beide Schreibweisen gefunden) auf URLs. Die Idee dahinter ist, dass man in einer URL unterschiedliche Code Points benutzen kann, die gerendert ähnlich oder gleich aussehen. Eine bekannte Attacke, die von Browsern dadurch abgemildert wird, dass sie Domains mit Zeichen aus unterschiedlichen Sprachen escaped anzeigen, es also offensichtlich ist, dass man nicht auf der Seite ist, auf der man zu sein glaubt.

So weit nichts Neues. Curl hat natürlich keine solche Schutzmechanismen, und Stenberg möchte die Aufmerksamkeit darauf lenken, dass man URLs, die man mit curl aufruft, vorher noch einmal überprüft.

Für mich neu hingegen waren einige der konkreteren Szenarien. So habe ich z.B. gelernt, dass für IDN Zeichen normalisiert werden, also unterschiedliche code points auf ASCII-Zeichen übersetzt werden um die URL zu vereinheitlichen.

Dazu habe ich einige neue code points kennengelernt, deren Nutzen sich mir entzieht. So gibt es zum Beispiel zusätzlich zum regulären Schrägstrich / auch einen Schrägstrich für Brüche ⁄ (U+2044). Oder lateinische Buchstaben, die nur für römische Zahlen gedacht sind.

Letztere haben mich doch sehr verwundert. Das komische an den römischen Zahlen ist schließlich, dass sie die Buchstaben sind. Und dennoch wäre laut Unicode „MMXXIV“ nicht die korrekte Codierung von „2024“. Stattdessen wäre es „ⅯⅯⅩⅩⅣ“. Ich würde spontan behaupten, dass diese speziellen Codepoints für römische Zahlen so gut wie nie verwendet werden. Ich wusste nicht, dass es sie gibt, vermutlich weiß kaum jemand, dass es sie gibt und noch weniger Leute verwenden sie. Selbst der Wikipedia-Artikel zu römischen Zahlen benutzt einfach die ASCII-Zeichen.

Interessant ist es auch, sich den Unicode-Block anzuschauen, in dem die römischen Zahlen stehen. Dort gibt es natürlich die einzelnen Ziffern wie Ⅰ, Ⅴ, Ⅹ, usw, aber die Zahlen von 1 bis 12 haben sogar jeweils einen eigenen Code Point, auch wenn man sie als Kombination der anderen Zahlen schreiben könnte.

Ich frage mich ja, was die Geschichte dahinter ist. Ob die eingeführt wurden, um Kompatibilität zu einem anderen Zeichensatz herzustellen? Oder der Vollständigkeit halber, weil das Zahlen sind und keine Buchstaben und deswegen eigene Code Points verdient haben (ein Schlag ins Gesicht aller, die ihre Probleme mit der Han-Vereinheitlichung haben)? Jedenfalls kann doch niemand erwarten, dass diese Code Points ernsthaft verwendet werden, oder?

Update: Empfehlung des Unicode consortiums

Die Frage, wer zur Hölle denn die spezifischen code points für römische Zahlen verwendet, hat mir keine Ruhe gelassen. Ich habe noch einmal kurz nachgeschaut. Dabei habe ich diese Stackexchange-Antwort gefunden. Die verweist auf ein Spezifikationsdokument (Abschnitt 22.3, Seite 20 im verlinkten Dokument bzw. Seite 755 in der absoluten Seitenzählung). Kurz: In den meisten Fällen sollte man einfach die ASCII-Zeichen für die römischen Zahlen verwenden, nur in speziellen Fällen mit ostasiatischem Textlayout sollte man die spezifischen code points verwenden.

Advent of Code 2024: Rückblick

Der Programmierpuzzleadventskalender Advent of Code ist für dieses Jahr durch. Dieses Jahr war das zehnte Mal, dass dieser Adventskalender seine Türchen öffnete, und anlässlich dieses Jubiläums ging es in einer rasanten Tour durch Raum und Zeit, um die Orte zu besuchen, die man in den vorherigen Advents of Code schon einmal besucht hat.

SPOILER ALERT: Das hier ist ein Rückblick auf den Advent of Code 2024 und vielleicht auch auf vorherige Advents of Code. Wer sich die Geschichte und die Puzzle nicht spoilern möchte, sollte hier aufhören zu lesen.

Erst einmal ein paar allgemeine Anmerkungen. Wie schon am Anfang des Monats geschrieben musste man dieses Mal Santas Chefhistoriker suchen, der unbedingt bei Santas Schlittenstart zusehen möchte, aber leider gerade nirgendwo zu finden ist. Die Vermutung ist: Er wird sich irgendwo an historisch relevanten Orten herumtreiben (d.h. Orte aus vorherigen Jahren). Deswegen nehmen dich die anderen Historiker mit, um ihn zu suchen.

Was die Puzzle angeht: Ich habe mich an den ersten Tagen erstaunlich schwer mit den Puzzlen getan (sie waren nicht schwer, aber dafür habe ich doch ein paar Probleme gehabt). Auf der anderen Seite habe ich es seit 2020 zum ersten Mal geschafft, alle Puzzle am Tag ihrer Veröffentlichung zu lösen.

Die Community (hauptsächlich auf reddit) war wieder sehr aktiv. Egal, wie sehr ich weiter unten über komische Kommentare auf reddit lästere: Die Community ist hilfsbereit und kreativ, sowohl in den Lösungen als auch in Visualisierungen und Memes. Aufgefallen ist mir, dass es gefühlt weniger Posts mit „Meine Lösung funktioniert für das Beispiel aber nicht für den wirklichen Input“ gab. Es gab sie, aber es waren weniger als letztes Jahr. Auch wieder dabei: eine inoffizielle Erhebung zu den Teilnehmern des AoC.

Während die Historiker den Chefhistoriker suchen hilft man nur in seltenen Fällen dabei, sondern löst meist irgendwelche anderen Probleme, die die Leute vor Ort haben. Am Ende stellt sich heraus: Der Chefhistoriker war die ganze Zeit in seinem Büro und hat gerarbeitet und war ganz am Anfang nur kurz weg, um sich Kaffee zu holen.

Die Puzzle

Meine Lösungen zu den Puzzles

Tag 2: Auf oder Ab

Am zweiten Tag musste man in Teil 1 kurze Zahlenfolge auf bestimmte Eigenschaften überprüfen. In Teil 2 musste man herausfinden, welche ungültigen Zahlenfolgen gültig werden, wenn man genau ein Element entfernt.

Auf reddit eine Menge Leute, die das einfach brute-forced haben. Ich selber habe einen Ansatz gewählt, bei dem ich nur vier Optionen ausprobieren musste. Auf reddit gab es auch ein paar, die es mit drei oder sogar nur zwei Optionen geschafft haben.

Tag 3: Corrupted Memory

An Tag 3 musste man arithmetische Operationen wie mul(9,6) in einem kauderwelsch von korrumpierten Speicher finden. Da ich in rust ohne externe Abhängigkeiten arbeite, konnte ich das nicht mit regulären Audrücken machen, auch wenn es hilfreich gewesen wäre. Schwierig war es aber trotzdem nicht. Auf reddit natürlich Programmieranfänger, die sich in Regexes einlesen.

Tag 5: Absolute Ordnung

Am fünften Tag musste man den Elfen helfen, das Schlittensicherheitshandbuch auszudrucken. Weil die Elfen immer alles etwas komisch machen, sind die Seiten seltsam sortiert. Ich habe erst einmal einen primitiven Ansatz gewählt (Sortierfunktion der Standardbibliothek, mit selbstgeschriebener Vergleichsfunktion, die die komischen Regeln beinhaltet). Hat auf Anhieb funktioniert. Ich hatte auch eine sauberere Lösung im Kopf, aber wie sich herausstellte wäre das keine gute Idee gwesen: Die Seitenreihenfolge ist nämlich nicht absolut. Sie funktioniert nur, weil jede zu sortierende Liste keine widersprüchlichen Kombinationen enthält.

Auf reddit gibt es ein paar Leute, die keine Lust hatten und einfach Bogosort verwendet haben.

Tag 6: Vagabundierende Wachen

Eine kleine Zeitreise. Um ein Paradox zu vermeiden, muss man einer Wache, die sich nach bestimmten Regeln verhält und and Hindernissen immer nach rechts abbiegt, ein zusätzliches Hindernis in den Weg legen, damit sie im Kreis läuft. Meine Brute-Force-Ansatz, einfach alle möglichen Positionen für ein Hindernis (also alle Positionen auf dem normalen Pfad der Wache) auszuprobieren lief in 1.5s durch, also habe ich mir keine Mühe gemacht, das weiter zu optimieren.

Tag 7: Gestohlene Operatoren

Dieses Mal musste man Gleichungen lösen, indem man die richtigen Operatoren einfügt. Die wurden nämlich von Elefanten gestohlen (makes just as much sense in context). Ich habe es wieder brute-forced, und es lief sogar schneller durch als meine brute-force-Lösung vom Vortag. Einzig ein dummer Tippfehler in Teil 2 hat mich Zeit gekostet.

Tag 9: Defragmentieren

Am neunten Tag musste man Flohkrebsen dabei helfen, ihre Festplatte zu defragmentieren. Meine Lösung ist eher unsauber (mir ging es nicht gut an dem Tag), funktioniert aber ohne Probleme. Auf reddit hingegen sind viele Leute darüber gestolpert, dass es Datei IDs größer als 9 gibt, wobei ich nicht einmal verstanden habe, warum das ein Problem ist. Stellt sich heraus: die haben auf Strings gearbeitet da kann jede Speicherzelle und einen code point als ID haben. ASCII-Codepoints reichen aber nicht aus für die Anzahl der Dateien. Anstatt eine ordentliche Lösung zu machen, sind einige Leute auf Unicode-IDs umgestiegen. Ich konnte nicht umhin anzumerken, wie viele Probleme dieser Ansatz bringt. Das war ungefähr auf dem Niveau der „twoneight“-Probleme aus dem letzten Jahr.

Tag 10: Lesen hilft, falsch lesen hilft mehr

Ein Pfadesucheproblem, bei dem man im ersten Teil alle Ziele, die man von einem Startpunkt erreichen kann, ausfindig machen muss. Ich habe es zuerst falsch gelesen und alle Pfade gezählt. Der Bug war leicht behoben. In Teil 2 musste man dann aber alle Pfade Zählen. Der Bug war ebensoleicht unbehoben wie ich ihn vorher behoben habe und ich war in fünf Minuten mit Teil 2 fertig.

Tag 11: You blink, you miss it

An Tag 11 musste man Steine zählen, die sich mit jedem Blinzeln nach bestimmten Regeln verfielfältigen. Exponentiell. Teil 2 war dann wie Teil 1, aber man blinzelte häufiger. Ein klassisches „und jetzt mach das gleiche noch einmal mit dieser riesigen Zahl“-Problem. Mit dynamic programming aber kein Problem.

Tag 12: Zäune ziehen

Dieses Mal musste man den Umfang von Gärten berechnen, damit Zäune gezogen werden können. In Teil zwei dann nicht den Umfang, sondern die Anzahl der Seiten. Meine Lösung ist hässlich und sie zu schreiben war frickelig. Wenn ich, wie einige Leute auf reddit, auf die Idee gekommen wäre dass die Anzahl der Ecken gleich die Anzahl der Kanten ist, wäre es vermutlich schöner geworden.

Tag 13: Lineare Gleichungen

Wieder eins von den Puzzeln, bei denen beim zweiten Teil eine unmöglich große Zahl gefordert wird. Ich habe einfach auf dem Papier eine generelle Lösung für das geforderte Gleichungssystem aufgestellt und die dann in das Programm übertragen. Hat auf Anhieb funktioniert, was mich selber erstaunt hat. Ich war mir sicher, ich hätte mich irgendwo verrechnet.

Tag 14: Weihnachts-Easteregg

Die Historiker müssen auf Toilette und der beste Ort dafür ist aus irgendeinem Grund das Osterhasenhauptquartier. Dort darf man sich als Weihnachtself natürlich nicht erwischen lassen, also musste man die Positionen der Wachroboter voraussagen.

In Teil 2 hat man dann vermutet, dass die Roboter vom Nordpol gestohlen oder kopiert wurden. Dazu musste man ein Easteregg finden (ironischerweise), bei dem sich die Roboter irgendwann in Form eines Tannenbaums gruppieren. Leider kriegt man keine Beschreibung, wie der Tannenbaum aussieht. Ich dachte zunächst, der Tannenbaum würde so aussehen wie der von 2015 und habe überschlagen, dass ich 30 Roboter in einer Reihe erwarten kann, wenn der Tannenbaum zu sehen ist.

Nun, diese Annahme war falsch, weil der Tannenbaum komplett anders aussah. Allerdings hatte er einen Rahmen, der diese Bedingung erfüllte, also war ich gerettet. Auf reddit haben sich viele über die ungenaue Spezifikation beschwert, auf der anderen Seite gab es aber auch eine Menge kreativer Methoden, den Tannenbaum zu finden. Von statistischen Analysen der Varianz der Roboterpositionen über groß angelegte Plots bis hin zu so einfachen Heuristiken wie meiner.

Tag 16: Rentierrennen

Den kürzesten Pfad für ein Rentier in einem Irrgarten finden. Das Besondere: Abbiegen ist viel, viel teurer als geradeaus laufen. Erster Einsatz von Dijkstra dieses Jahr.

Tag 17: Codeanalyse

Wieder eins von diesen Problemen wo man einen eigens erdachten Maschinencode ausführen muss. In Teil zwei musste man dann einen Input finden, der das Programm zu einem Quine macht. Dieser Input war natürlich wieder riesig, zu groß, um ihn per Brute Force herauszufinden. Also musste man das Programm analysieren (ich habe dafür einen Disassembler geschrieben um das Programm einfacher verstehen zu können). Dann konnte man Schritt für Schritt einen Input konstruieren, der die Lösung findet.

Mein Ansatz lag zuerst daneben, aber nicht weit daneben. Deswegen konnte ich den Rest doch mit Brute Force machen. Als ich das geschafft habe, habe ich in Ruhe noch die Bugs in meinem ersten Ansatz behoben, dann ging es.

Tag 18: Ein einfacher Einschub

Im Verhältnis zu den vorherigen Tagen war Tag 18 sehr einfach. Erst einen kürzesten Pfad mit Einheitskosten finden (BFS), dann herausfinden, ab welchem hinzugefügten Hindernis kein Pfad mehr zum Ziel führt. Mit binärer Suche einfach und effizient.

Tag 19: Handtücher in Heißen Bädern

Man muss herausfinden, wie bestimmte Streifenmuster mit vorgegebenen gestreiften Handtüchern zu bilden sind. Teil 2 war wieder effizient mit dynamic programming lösbar.

Tag 20: Schummelrennen

Eigentlich ein schönes Puzzle: Man musste einen kürzesten Pfad finden, wenn man ein mal für eine bestimmte Zeit Hindernisse ignorieren kann. Ein einfaches kürzeste-Pfade-Problem, aber leider ist für Teil 2 (man darf deutlich länger schummeln als bei Teil 1) der Suchraum wieder explodiert. Ich habe einen unbrauchbaren Ansatz gewählt und komplett implementiert. Dann habe ich noch einen unbrauchbaren Ansatz gewählt und komplett implementiert. Dann habe ich einen guten Ansatz gefunden, hatte aber einen Bug. Und noch einen Bug, und noch einen Bug. Der erste Tag, an dem ich richtig gelitten habe.

Tag 21: Robots all the way down

Einer der Historiker hat sich auf Santas Reindeer-Class-Raumschiff verirrt. Man muss ihn retten, indem man Mit Pfeiltasten einen Roboter steuert, mit Pfeiltasten einen Roboter zu steuern, der mit Pfeiltasten einen anderen Roboter steuert, der Code in ein Nummernpad eingibt.

Man soll die Länge der kürzesten Folge von Befehlen finden, die den letzten Roboter den richtigen Code eingeben lässt. Klingt einfach, oder? Ist es aber nicht. Es gibt viele subtile Probleme, hauptsächlich ist es wichtig, in welcher Reihenfolgen man die Befehle für eine Taste eingibt. Ich habe für Teil 1 ewig gebraucht.

Teil zwei war das gleiche, nur mit 25 Robotern an den Pfeiltasten anstatt nur zwei. Die Liste von Befehlen würde so lang, dass sie nicht mehr in den Speicher passt. Im Verhältnis zu Teil 1 habe ich das aber recht schnell mit – mal wieder – dynamic Programming gelöst, weil mir aufgefallen ist, dass man bestimmte Befehle unabhängig voneinander betrachten kann. Vermutlich das schwerste Puzzle dieses Jahr.

Tag 22: Bananen und Affen

Ein Affe hat den Raum-Zeit-Teleporter der Historiker geklaut. Um ihn zurückzukriegen muss man ihm Bananen geben, die man sich von anderen Affen erhandelt. Einfaches durch-die-Gegend-schieben von Zahlen, eine Erleichterung nach dem vorherigen Tag.

Tag 23: Die LAN-Party

Man muss direkt vernetzte Computer in einem Netzwerk finden. Ein Cliquenproblem, wie ich gelernt habe, das NP-Vollständig ist. Ich habe mal geschaut, wie man so etwas löst und bin auf den Bron-Kerbosch-Agorithmus gestoßen. Für den gegebenen Input hat das auch ziemlich schnell funktioniert.

Tag 24: Plus

An Heiligabend musste man zunächst Inputs durch einen logischen Schaltkreis (ohne Schleifen) schicken. Einfach. In Teil 2 stellte dich dann heraus, dass der Schaltkreis eigentlich addieren soll. Nach einigem Überlegen bin habe ich mir den Schaltkreis einfach geplotted (mit Graphviz und die Fehler manuell gesucht, das ging schneller. Ich habe bis jetzt keine allgemeine Lösung, aber warum auch? Es war Heiligabend, ich hatte nicht viel Zeit für den AoC. Mit meiner manuellen Lösung hatte ich ironischerweise meinen bis dahin besten Rang erreicht.

Tag 25: Schlüssel-Schloss

Heute musste man dann schauen, welche Schlüssel auf welche Schlösser passten. Sie mussten nicht einmal genau passen. Ich konnte jeden Schlüssel und jedes Schloss als 64-bit Integer darstellen und konnte so das Problem effizient mit bitweisem AND lösen.

Jetzt bin ich durch und habe meinen persönlich besten Rang für die Lösung aller Puzzle in einem Jahr erreicht.

38C3 Illegal Instructions

Vom 27.12.2024 bis zum 30.12.2024 war der 38. Chaos Communication Congress (38C3), dieses Mal unter dem Motto „Illegal Instructions“. Karten zu kriegen schien mir dieses Mal überdurchschnittlich schwierig, ich habe es aber geschafft. Ich war also wieder dabei und habe eine Menge erlebt. So viel, dass ich das wieder in mehrere Blogposts aufteilen muss. Jetzt erst einmal kommen hauptsächlich Sachen, die nicht mit irgendwelchen Talks auf dem Congress zu tun haben.

Ich habe sogar ein paar Fotos gemacht, was ich selten mache. Die Foto-Policy auf den Chaosevents ist immer: niemanden ohne ausdrückliche Erlaubnis fotografieren, auch nicht für rein private Bilder. Ich habe darauf geachtet, dass bei den Fotos keine anderen Menschen zu sehen sind.

House of Tea

Wieder mit dabei war das House of Tea, (ehemals Tea House), ein Bereich mit niedrigen Tischen und einer Teezubereitungsecke. Dann macht man Tee und trinkt ihn, entweder alleine oder mit anderen zusammen.

Eine Teekanne und ein Teeschälchen auf einem Plastiktablett. Im Tee spiegeln sich bunte Lichter.

Morgens ist es dort meist recht leer, so kann man gemütlich und in Ruhe einen Tee trinken. Später wird es dort ziemlich voll. Wenn man sich mit neuen Leuten unterhalten möchte, aber schüchtern ist wie ich, hat dazu am meisten Chancen, wenn es halbwegs voll ist, aber nicht überfüllt. Ist es leer, setzen sich alle an unbesetzte Tische. Ist es komplett voll, wird es zu eng, zu laut und es ist kein Platz mehr.

Ist es hingegen nur halbwegs voll findet man vielleicht einen Platz an einem Tisch mit anderen Leuten und mit ein bisschen Glück ergibt sich ein interessantes Gespräch.

Das House of Tea war wie immer eine „No shoe zone“. Es gab Regale für die Schuhe, aber… naja:

Klebebänder auf dem Boden. Auf ihnen steht „Emergency exit ↓Keep clear! ↓ No shoes on floor ↓ Use shelves“. Darum herum stehen Schuhe auf dem Boden.

Datenelch

Auf dem 37C3 war der Datenelch in vielen Aushängen vorhanden. Dieses Jahr weniger, aber gelegentlich hat man ihn doch angetroffen:

Ein Aushang. Dort steht: „WARNING DATENELCH WAS SPOTTED PLEASE HUG YOUR LOVED ONES“. Daneben ein Aufkleber mit zwei Datenelchen, die an einem Tisch sitzen und ein Glas Wein trinken.

OpenStreetMap

Wie gab es eine OpenStreetMap-Assembly, und wieder war jemand da, bei dem man sich Kartenausschnitte in DIN A1 drucken konnte. Ich habe das bisher nie genutzt, mit dieses Jahr aber mal eine Karte meines Wohnortes ausdrucken lassen, gegen eine Spende selbstverständlich.

CO₂-Sensor

An der Assembly eines Hackerspaces aus Darmstadt gab es Bausets für Kohlendioxid-Sensoren zum Zusammenlöten.

Ich habe mir einen besorgt, ihn aber erst zwei Tage später zusammengelötet. Vorher war dort einfach zu viel los, was auch daran lag, dass sie LED-stripes für die auf dem Congress weit verbreiteten 3D-gedruckten Katzenohren gab. An Tag 3 waren die dann ausverkauft, also war wieder ein bisschen Platz an den Lötstationen.

Der Sensor könnte eine gute Ergänzung für meinen bestehenden Raumluftsensor ergeben. Bisher habe ich die Firmware aber noch nicht eingerichtet.

Auf einem Tisch liegt eine Platine, an die ein paar Drähte gelötet sind. Daneben liegt Lötzinn, drumherum Antistatitktüten und elektronische Bauteile.

Die RPG-Assembly

Ein Freund von mir hat dieses Jahr aus der inoffiziellen RPG-Assembly letztes Jahr dieses Jahr eine offizielle RPG-Assembly gemacht. Ich habe leider vergessen, Fotos zu machen.

Pixelflut

Letztes Jahr habe ich ja Pixelflut für mich entdeckt. Dieses Jahr gab es wieder Pixelflut, und ich war vorbereitet. Aber nicht gut genug.

An Tag 1 hatten die Pixelflutleute Hardware-Probleme, ich habe nicht gespielt. An Tag 2 lief eigentlich erst einmal alles gut: Mein Client hat stabil Bilder angezeigt, mein kleines interaktives Projekt (man kann mit einem Controller eine Spielfigure über den Screen wandern lassen) funktionierte auch recht gut… auf meinem Rechner.

Ich hatte aber auch einen Raspberry Pi vorbereitet, auf dem ich dieses Spiel laufen lassen wollte. Die Idee: Ich lasse das Teil da liegen, dann kann jeder, der Spaß daran hat, die Figur steuern.

Hat leider nicht gut funktioniert. Obwohl ich alles vorher getestet habe, hat sich die Figur nicht bewegt. Ich habe dann in Ruhe Fehleranalyse betrieben und das Problem behoben, und gegen einen lokalen Pixelflut-Server lief das Ding auch gut. An Tag 3 jedoch hatte die Konkurrenz dermaßen an Stärke gewonnen, dass es dem Raspberry Pi unmöglich war, noch eine Figur anzuzeigen. Irgendwann habe ich aufgegeben.

Sonstiges

Ich habe noch viele andere Sachen erlebt. Ein angeregtes Gespräch mit einer Rollenspielerin, viele Aushänge, ein paar Kunstinstallationen, Vorträge, etc. Dazu kommt teilweise noch mehr in anderen Posts. Fürs Erste muss ich mich jetzt erst einmal ausruhen.

Vorträge auf dem 38C3

Wie neulich schon im Post über den 38C3 angekündigt, hier eine Übersicht über die Vorträge, die ich mir angehört habe bzw. die so interessant klangen, dass ich sie noch anhören will. Die lightning talks behandle ich dann vielleicht später noch einmal in einem separaten Post.

Alle Aufnahmen der Talks stehen wie immer auf media.ccc.de.

libobscura: Cameras are difficult

Einer der ersten Talks des Congresses. Ich bin vorher schon einmal unabhängig über die Seite des Autors gestolpert, und über libobscura selbst habe ich glaube ich zum ersten Mal über This Week in Rust gestolpert, vielleicht aber auch über Mastodon.

Libobscura ist eine Kamerabibliothek für Linux, geschrieben in Rust. Der Vortrag ist unterhaltsam gemacht und berichtet davon, wie das Projekt entstanden ist, mit welchen Detailproblemen man sich bei der Entwicklung von Kamerasoftware herumschlagen muss und wie die Zukunft des Projektes aussieht.

Clay PCB

Zu diesem Talk haben die Hackerinnen auch die Ergebnisse ausgestellt. Eine Gruppe Hackerinnen aus Österreich wollte resourcenfreundliche und nachhaltige PCBs herstellen und haben sie in lokal gefundenen Ton gestempelt und gebrannt. Ein interessanter Vortrag, aber ich sehe das mehr als proof of concept als etwas, was wirklich sinnvoll einsetzbar ist.

Viele Leiterplatten aus gebranntem Ton in Holzrahmen. Die Leiterplatten sind jeweils gleichseitige Sechsecke, in Rillen sind silbern Leiterbahnen zu sehen. Einige von ihnen haben Microcontroller aufgelötet.

An open-source guide to the galaxy: Our journey with Ariane 6

Ein Talk über zwei voneinander unabhänige Teams, die jeweils einen Satelliten mit derselben Ariane 6-Rakete in die Umlaufbahn haben schießen lassen. Die beiden Vortragenden haben sich auf dem Congress kennengelernt und dann einen Talk darüber gemacht.

Warum Nutzende Logins nerven

Von diesem Talk habe ich mir mehr versprochen. Für Leute, die noch nicht mitgekriegt haben, dass Benutzername/Passwort-Logins keine gute Idee sind aber vielleicht ein guter Einstieg. Für mich ein bisschen zu oberflächlich.

How to Spec - Fun with dinosaurs

Ein Vortrag von einem Paläokünstler (paleoartist), also jemandem, der anhand von wissenschaftlichen Erkenntnissen Bilder von ausgestorbenen Lebewesen erschafft (in diesem Talk mit einem Fokus auf Dinosaurier).

Den Talk kann ich uneingeschränkt empfehlen, er behandelt ein Thema über das man kaum nachdenkt, beleuchtet die vielen Probleme (unvollständige Funde, ständig neue Erkenntnisse, Spekulationen, etc) und ist auch noch gut gemacht.

Wir wissen wo dein Auto steht

Die sprichwörtliche Bombe, die am ersten Tag des Congresses geplatzt ist. Es waren noch ein paar Slots frei Programm. Die wurden freigehalten, weil erst am selben Tag dieser Spiegel-Artikel erschienen ist.

Im Vortrag am selben Abend wird dann schön erläutert, wie VW mal wieder auf ganzer Linie verkackt hat. Unter dem Vorwand, das Ladeverhalten von E-Auto-Batterien zu optimieren haben die jedes Mal, wenn ein Auto einer VW-Tochter geparkt wurde, die GPS-Daten des Autos hochgeladen. Verkacker 1: Diese Daten hätten nicht erhoben werden sollen.

Diese Positionsdaten hätten dann eigentlich gekürzt werden sollen, so dass sie nur noch auf etwa 10km genau sind. Das wurde aber in etwa ⅔ der Fälle nicht gemacht.

Dann wurden die Positionsdaten auch noch mit den Kundenaccounts verknüpft, so dass man auch noch verfolgen konnte, wem denn nun das Auto gehört.

Das alleine wäre schon schlimm genug. Damit weiß VW alles über das Auto und vieles über den Kunden. Aber dann ist natürlich noch der GAU passiert: Eine Kopie mit den Datensätzen von hunderttausenden von Autos stand nahezu frei im Netz verfügbar. Dass ist der Grund, weshalb man Datensparsamkeit praktizieren muss: Daten, die nicht erhoben werden, können nicht leaken.

Immerhin wurde die Lücke schnell behoben. In Reaktion auf die Berichterstattung führte VW natürlich wieder die üblichen Beschwichtigungen ins Feld, dass das ja nicht so schlimm sei, dass die Lücke nicht so einfach ausnutzbar gewesen wäre, etc. Bullshit. Wenn eine Hackerin das alleine hinkriegt, kriegen es auch Geheimdienste hin. Ach ja: Daten von Autos von BND-Mitarbeitern wurden auch geleaked. Kann also niemand behaupten, Geheimdienste würden sich nicht dafür interessieren.

Illegal instructions by legal – Anweisungen für den anwaltlich begleiteten Rechtsbruch

Bei diesem Titel ist es relativ klar, dass es von dem Vortrag keine Aufzeichnung gab. So viel Rechtsbruch war da aber auch nicht drin, es ging mehr um Grauzonen. Zwei Anwältinnen, eine von der Seenotrettungsorganisation Sea-Watch und ein von… ich weiß nicht mehr, könnte aber FragDenStaat gewesen sein.

Ein guter Vortrag, ein Tipp, der bei mir hängengeblieben ist: Setze eine Person an die juristisch relevante Position, die viel in der Öffentlichkeit steht und wenig andere Angriffsfläche bietet (d.h. weißer, mittelalter Mann mit viel Publicity). Da stehen die Chancen gut, im Ernstfall mit einer milden Strafe davonzukommen.

Fearsome File Formats

Ein Talk über Dateiformate und wie man Dateien erstellen kann, die mehrere unterschiedliche Dateitypen gleichzeitig sind (mit gültigem Inhalt). Technisch interessant und security-relevant, weil man so eventuell die automatische Dateityp-Erkennung austricksen und Scans umgehen kann.

The master key

2010 wurde der (bzw. ein) HDCP master key veröffentlich. In diesem Vortrag treten die dahinterstehenden Personen zum ersten Mal an die Öffentlichkeit und berichten, wie sie das geschafft haben.

Biological evolution: writing, rewriting and breaking the program of life

Ein Talk von zwei theoretischen Biologen über Modelle und Simulationen, wie Einzeller damit angefangen haben könnten, zusammenzuarbeiten. Also quasi der erste Schritt in Richtung Mehrzeller.

Knäste hacken

Ein Talk von Lilith Wittmann. Das sollte eigentlich schon ausreichen um zu sagen, dass er sehenswert ist.

Es geht darin zum einen um die Versorgung von Gefängnissen mit Telefon- und Internetinfrastruktur (wobei es zu einem Datenleak über die Telefongespräche von Gefangenen mit ihren Freunden, Verwandten und Anwälten kam), die in Deutschland in der Hand von nur einer Firma liegt, die verklagt werden musste, um auch nur halbwegs angemessene Preise anzubieten und über Verwaltungssoftware in Gefängnissen, die auch zu wünschen übrig lässt.

Mit OpenType ein X für ein U vormachen

Dazu habe ich keine Aufzeichnung gefunden. In dem Talk berichtete jemand, der Schriftarten entwirft, mit welchen Tricks man arbeiten kann und wie man Glyphen effektiv nach regulären Ausdrücken durch andere ersetzt. Gedacht ist das eigentlich für Ligaturen und so, theoretisch kann man es aber auch für Manipulationen und Gaslighting verwenden.

All Brains are Beautiful! – The Biology of Neurodiversity

Ein schöner Talk darüber, was die biologischen Unterschiede in nicht-neurotypischen Gehirnen sind und welchen evolutionären Sinn das haben könnte.

Security Nightmares

Die Security Nightmares. Ein Klassiker.

Decentralize Your Internet with Self-Hosting

Hier beginnen die Talks, die ich mir erst nachträglich angeschaut habe. Dieser hier handelt davon, wie man sich zu Hause eine kleine, sichere, aus dem Internet erreichbare Nextcloud-Instanz aufbaut.

Wann klappt der Anschluss, wann nicht und wie sagt man Chaos vorher?

Eine statistische Analyse, unter welchen Bedingungen bei der deutschen Bahn wie wahrscheinlich Verspätungen sind. Kurz zusammengefasst:

  • Zu Stoßzeiten sind Verspätungen wahrscheinlicher
  • Fernverkehr hat größere Verspätungen als Nahverkehr
  • Je länger ein Zug schon gefahren ist, desto höher die Wahrscheinlichkeit für Verspätung
  • wenn die Bahn eine Verspätung ankündigt ist die Wahrscheinlichkeit groß, dass diese sich noch erhöht

Mit den Daten haben sie außerdem ein Modell trainiert, so kann man sich eine Verbindung heraussuchen, bei der die Verspätungswahrscheinlichkeit gering ist: bahnvorhersage.de.

Fnord-Nachrichtenrückblick 2024

Die Fnordshow ist wieder da, war leider viel zu spät in der Nacht. Fall jemand eine Übersicht über die Absurditäten von 2024 braucht. Dieses Mal leider ohne Frank Rieger, dafür mit einem running Gag, der eine Supporthotline beinhaltet.

Hacking yourself a satellite - recovering BEESAT-1

Ein cooler Vortrag, wie ein Hacker den Satelliten BEESAT-1 wieder unter Kontrolle brachte. Der war über zehn Jahre vorher plötzlich mehr oder weniger ausgefallen, weil er wichtige Parameter überschrieben hat, wie sich herausstellte. Nur: Wie patched man das, wenn die Software auf dem Satelliten das eigentlich nicht vorsieht?

Och Menno - How NOT to build a submarine

Ein unterhaltsamer Vortrag. Zuerst kommt ein kurzer Rückblick auf historische Fehlkonstruktionen bei U-Booten, dann ein ausführlicherer Bericht über die Fehler und die Arroganz bei der Konstruktion des TITAN U-Bootes.

Der Titel dieses Talks ist ein Verweis auf den sehenswerten Talk „How to build a submarine and survive“ vom 37C3, wo sich Leute im Hof ein funktionsfähiges U-Boot zusammengebastelt haben.

„Konnte bisher noch nie gehackt werden“: Die elektronische Patientenakte kommt - jetzt…

Dieser Vortrag hat mich dazu gebraucht, meiner ePA doch noch zu widersprechen. Selbst wenn alle in dem Talk genannten Sicherheitslücken behoben würden scheint mir die Entwicklung daran so aus dem Ruder gelaufen, dass ich kein Vertrauen habe, dass hier in Zukunft nicht noch mehr Mist gebaut wird.

Für alle, die sich noch nicht entschieden haben: Man kann den Widerspruch zur ePA jederzeit wieder aufheben. Umgekehrt kann man jederzeit Widersprechen und die bis dahin gesammelte ePA löschen lassen. Sollte alles kein Problem sein, es sei denn, die Daten sind bereits geleaked. Ob man widerspricht, ist eine persönliche Risikoabwägung von Datenschutz vs. dem Vorteil, dass Ärzte einem unter Umständen schneller oder besser helfen können.

Vorträge, die ich noch nicht angesehen habe

Hier noch eine Liste der Vorträge, die noch interessant klingen, die ich aber noch nicht angeschaut habe:

Doppelte Staatsbürgerschaft

Anlässlich von Friedrich Merz' jüngster durchs Dorf getriebener Sau, man müsse deutschen Bürgern mit doppelter Staatsbürgerschaft bei Straffälligkeit die deutsche Staatsbürgerschaft entziehen können, hat eine Freundin in einer Chatgruppe geschrieben:

ich kann mir die doppelte staatsbürgerschaft nicht aberkennen lassen
falls ich kinder kriegen würde, würden diese auch eine doppelte staatsbürgerschaft haben
falls diese wiederrum kinder kriegen, haben auch sie eine doppelte staatsbürgerschaft

Es gibt halt Länder, bei denen man die Staatsbürgerschaft nicht einfach ablegen kann. Wollen wir Menschen, die ihr ganzes Leben in Deutschland gelebt haben, ihrer Staatsbürgerschaft entziehen und rauswerfen?

Ok, das ist eine rhetorische Frage, deren Antwort offensichtlich „nein“ ist, aber wenn man ins rechte Lager schaut, ist dort die Meinung ganz offensichtlich „ja“.

Was mich wirklich ärgert, ist, dass der Merz schon wieder Wahlkampf für die AfD macht, mit Themen, die nur die AfD stärken und die eigentlich kein Problem sind. Einwanderer sind kein Problem für Deutschland. Natürlich gibt es hier und da Probleme, aber nicht mehr als mit nicht-Einwanderern. Wir haben jede Menge echte Probleme. Die AfD verkauft keine Lösungen, sondern Probleme. Indem Merz diese vermeintlichen Probleme aufgreift, verleiht er ihnen Legitimität.

Dabei bleiben jede Menge echte Probleme liegen. Aber die echten Probleme sind auch schwieriger zu lösen. Deswegen kann man sich lieber einfache Probleme wie „die Ausländer sind schuld“ ausdenken, und sie mit „Ausländer raus!“ lösen. Denn seien wir mal ehrlich: nichts anderes ist gemeint, wenn es darum geht, Menschen die deutsche Staatsbügerschaft zu entziehen: jemand wird, nach irgendwelchen seltsamen Ideologien, nicht als „echter Deutscher“ betrachtet, und wird damit zum Bürger zweiter Klasse, für den man nur ein Ausrede braucht, um ihn auszuweisen.

Ich sehe echt schwarz für die nächste Bundestagswahl. Und braun.

Leopards ate my face

Ich habe in den letzten Wochen nicht viele Nachrichten gehört oder gelesen, weil es mir einfach zu schlecht dafür ging. Und jedes Mal, wenn ich es doch getan habe, habe ich es bereut. Diese Shitshow in den USA schlägt mir wirklich auf den Magen.

In den USA geht gerade der Ausdruck „Leopards ate my face“ herum, nach einem Tweet aus 2015:

'I never thought leopards would eat MY face' sobs woman who voted for the Leopards Eating People's Faces Party.

Es geht darum, dass ein Haufen Trump-Wähler jetzt schockiert darüber ist, was Trump gerade treibt. Dabei ist nichts davon eine Überraschung. Klar, die Details waren vorher unbekannt, aber Trump macht das, was er gesagt hat das er machen würde. Niemand sollte davon überrascht sein. Denn selbst wer den warnenden Stimmen der Gegenseite nicht zugehört und stattdessen Trump geglaubt hat: Trump hat offen angekündigt, was er jetzt macht.

Entsprechend wenig Mitleid habe ich mit Trump-Wählern (oder absichtlichen Nichtwählern) in den USA. Und entsprechend Mitleid habe ich mit den anderen, in den USA und weltweit.

Aber das hilft uns nicht weiter. Bei uns in Deutschland steht jetzt auch eine Wahl an. Und weit über zehn Prozent, vielleicht sogar über zwanzig Prozent der Stimmen werden an eine rechtsextreme Partei gehen, die ebenfalls eine ganze Menge Maßnahmen durchführen will, die den meisten Leuten im Land schaden.

Falls die CDU wirklich ihr Wort brechen und mit der AfD koalieren sollte (gegeben Merz' kürzliche Wortbrüche halte ich das nicht für ausgeschlossen), dann darf sich niemand, der die AfD oder die CDU gewählt hat, beschweren, dass Leoparden sein (oder ihr) Gesicht gefressen haben. Die AfD hat das offen angekündigt. Die CDU hat es zwar nicht, aber die hat ihre Glaubwürdigkeit spätestens vor ein paar Wochen verloren.

Nicht akzeptabel, nicht in Ordnung

Menschliche Wesen sind ungeheuer anpassungsfähig, und bis zur Mittagszeit hatte sich das Leben um Arthur Dents Haus herum bereits wieder normalisiert. Es war Arthurs allseits anerkannte Rolle, platschend im Matsch zu liegen […]; es war Mr. Prossers allseits anerkannte Rolle, Arthur ab und zu mit neuen Finten zu attackieren […].

Dieses Zitat stammt aus dem bemerkenswerten Buch Per Anhalter durch die Galaxis. Arthur Dent, der Protagonist, liegt vor seinem Haus im Matsch um einen Bulldozer daran zu hindern, sein Haus abzureißen. Eine außergewöhnliche Situation, aber wie das Zitat oben beschreibt, gewöhnen sich alle recht schnell daran.

Worauf will ich hinaus? Wir befinden uns politisch in den letzten Jahren auch in so einer Situation, in der Dinge normal werden, die vor ein paar Jahren noch undenkbar gewesen sind. Beispielsweise gab es vor einem Jahr noch riesige Demonstrationen gegen die AfD und andere rechte Akteure, weil sie eine Konferenz abgehalten haben, auf der sie die Abschiebung von Millionen von Deutschen forderten, die ihnen in irgendeiner Weise nicht deutsch genug waren. Dieses Jahr forderte Friedrich fucking Merz den Entzug der Staatsbürgerschaft für Straffällige.

Ich möchte hier daran erinnern, dass so etwas nur dadurch, dass es immer wiederholt wird und man sich langsam daran gewöhnt, nicht richtig wird. Und egal wie „normal“ etwas geworden ist, es ist weiterhin nicht aktzeptabel und nicht in Ordnung, z.B.

  • als Spitzenpolitiker Menschen das Demonstrationsrecht abzusprechen
  • als demokratisch gewähltes Staatsoberhaupt einer rechtsextremen (d.h. demokratiefeindlichen) Partei zu gratulieren, bei der Wahl im Nachbarland zweitstärkste Kraft geworden zu sein
  • der Hitlergruß zu zeigen, schon gar nicht auf einer öffentlichen Veranstaltung und erst recht nicht, wenn man der reichste Mensch der Welt ist
  • Menschen im Mittelmeer ertrinken lassen
  • die Zerstörung rechtsstaatlicher Institutionen als „Bürokratieabbau“ zu bezeichnen
  • die Existenz von Transmenschen zu leugnen

Das sind nur ein paar Beispiele aus den letzten Tagen. Es ist sehr wichtig, dass wir nicht vergessen, dass so etwas vor Kurzem noch nicht normal war, und dass es nur dadurch, dass es „normal“ geworden ist nicht richtiger oder akzeptabler wird.

Denn was wir hier beobachten ist eine Baseline, die verschoben wird. Das ist jetzt das neue Normal. Wir alle verwechseln „normal“ gerne mit „akzeptabel“ und „in Ordnung“. Gegen diese schleichende Akzeptanz müssen wir kämpfen. Und zwar, indem wir widersprechen, wenn jemand etwas nicht Akzeptables sagt. Indem wir diese neue Baseline zurückweisen, in unserem Kopf, aber auch nach außen hin. Wir lassen uns nicht stillschweigend in eine schlechtere, unmenschlichere und intolerantere Welt verschieben! Wir kämpfen dagegen!

Denn diese shifting baseline kann auch für gute Zwecke eingesetzt werden. Vor zwanzig Jahren waren Transgenderpersonen noch etwas ganz Unnormales. Vor zehn Jahren konnte man erkennen, wie die Gesellschaft langsam anfing, umzudenken. Heute sind Transmenschen normal, auch wenn einige reaktive Elemente versuchen das wieder zurückzudrehen.

Kämpfen wir also, indem wir gute, menschenfreundliche Gedanken laut aussprechen und menschenfeindlichen, demokratiefeindlichen Gedanken offen widersprechen. Sorgen wir dafür, dass wir ein „normal“ haben, in dem wir und wohl und sicher fühlen können!

Skype

Microsoft stellt Skype im Mai 2025 ein. Siehe dazu auch den Nachruf auf heise online.

Ich schaue da mit gemischten Gefühlen drauf. Auf der einen Seite habe ich selber Skype schon seit Jahren nicht mehr gestartet (aber immer noch installiert). Es ist, und war immer keine freie Software. Es wurde schlussendlich an Microsoft verkauft, und ich hatte damals Sorge, dass darunter der Linux-Client leiden würde.

Auf der anderen Seite war Skype halt einer der ersten verbreiteten Dienste, mit denen man einfach Audio- und Videocalls am Computer machen konnte. Und es hatte auch eine Instant-Messaging-Funktion. Als ich angefangen habe, Skype zu benutzen, lief die Popularität von ICQ langsam aus, also hatte ich viele Online-Kontakte über Skype. Es war einfach zu bedienen, und das Verb „skypen“ hat es sogar in den allgemeinen Wortschatz geschafft, so beherrschend war die Marktstellung.

Nach und nach haben andere Dienste Skype verdrängt, wie z.B. WhatsApp (benutzt es nicht!) oder Signal, oder Discord. Andere haben es versucht, aber nie geschafft (z.B. Jabber für Instant Messaging).

Was bleibt sind also einige Erinnerungen und einige Kuriositäten. So hatte z.B. Rupert Murdoch Skype verklagt, weil er meinte, das Markenrecht auf das Wort „Sky“ zu haben (dazu habe ich damals auch geschrieben. Die Ruhr-Universität Bochum hatte zu meiner Studienzeit die Anweisung herausgegeben, Skype auf Rechnern im Uninetz nicht immer im Hintergrund laufen zu lassen, sondern nur zweckgebunden zu starten, weil Skype-Instanzen, die länger liefen sich zu einer Art Hub entwickelten und eine Menge Traffic versursachten.

Am Ende bin ich froh, dass Sype weg ist, auch wenn ich einige Kontakte nur über Skype gepflegt habe. Leider ist nicht jeder Ersatz freie Software, am beliebtesten ist momentan Discord, und da kommt man an vielen Stellen leider nicht drum herum.

Support zum Kundenverjagen

Gestern habe ich eine Werbepostkarte von der deutschen Bahn bekommen. Ich will keine Werbung bekommen, also wollte ich die mal eben abbestellen. Glücklicherweise ist der Weg dazu auf der Postkarte aufgedruckt:

Wenn Sie künftig unsere Informationen und Angebote nicht mehr per Post erhalten möchten, kontaktieren Sie uns bitte über das Kontaktformular auf bahn.de/kontaktformular

Also bin ich auf bahn.de/kontaktformular gegangen und wurde direkt weitergeleitet zu bahn.de/hilfe#. Die Überschrift ist „Hilfe & Kontakt“, die Unterberschrift „Hier finden Sie Informationen, Links zu unseren Self-Services und Kontaktformulare.“

Einen DRECK habe ich gefunden. Es gab einige Unterthemen zu Hilfe mit jeweils einigen Unterunterthemen. Keins davon hatte in irgendeiner Weise mit unerwünschter Werbung zu tun. Es gab kein einziges Kontaktformular irgendeiner Art.

Es gab ein Suchfenster. Die Suche ergab auch keine hilfreichen Ergebnisse, die meisten Ergebnisse hatten nicht einmal mit Hilfethemen zu tun.

Darunter war ein Link zu einer Seite mit Telefonnummern. Ich habe also die Supportnummer angerufen. Dort wurden mir erst zwei Mal sämtliche Optionen vorgelesen , von denen keine zu dem passte, was ich wollte. Dann kam die Ansage, dass ich fünf Minuten warten müsse (immerhin keine 15 Minuten). Dann kam die Durchsage, dass einige dieser Anrufe aus Qualitätssicherungsgründen aufgezeichnet werden. Diese Ansage wurde unterbrochen von einer anderen Ansage, dass einige dieser Anrufe aus Qualitätssicherungsgründen aufgezeichnet würden und ich die 1 pressen soll, um das zu bestätigen. ALLES WÄHREND ABSOLUT NERVIGE, KLIRRENDE WARTEMUSIK GESPIELT WURDE. Dann kam ein Mensch in die Leitung.

Dem habe ich mein Anliegen erklärt. Der konnte mir nicht helfen, hat mir aber eine E-Mail-Adresse genannt, an die ich mich wenden soll: fahrkartenservice@bahn.de. Das habe ich dann gemacht. WARUM MAN DIESE ADRESSE NICHT DIREKT AUF DER HILFESEITE ANGEBEN KANN IST MIR UNKLAR.

Und das wirklich Schlimme ist: Das ist nicht das erste Mal, dass mir das passiert. Es ist bei größeren Unternehmen eher der Regelfall. Es ist nicht nur die Bahn. Microsoft zum Beispiel macht es auch so. Es wird dem Kunden möglichst schwer gemacht, irgendeinen Menschen zu kontaktieren, der dem Kunden dann das geben kann, was ihm von Recht aus zusteht. ICH HABE DIE SCHNAUZE VOLL!

Update 6.3.2025

Ich habe eine Antwort bekommen:

[…] vielen Dank für Ihre E-Mail.

Wir können Ihr Anliegen nicht bearbeiten.

Bitte wenden Sie sich an die Kollegen unter Telefonnummer: 0621 30 983-199

Mo.-Fr. 09:00 - 17:00 Uhr(außer 24.12., 31.12. und an Feiertagen)

oder per E-Mail: bahnshop@mycybergroup.com […]

Wollt ihr mich eigentlich verarschen? Euer eigener Support hat mir die Mailadresse geschickt. Könnt ihr das nicht wenigstens intern weiterleiten?

Nein, können sie natürlich nicht. Stattdessen soll ich mich an eine Mailadresse senden, die mycybergroup.com als Domain hat. Klingt total seriös und überhaupt nicht nach einem unterfinanzierten Startup, an das nervige Kunden abgewimmelt werden.

Passend zum Thema habe ich übrigens diesen sehr treffenden Comic gefunden.

Update 9.3.2025

mycybergroup.com hat sich gemeldet und mir nach ein paar Nachfragen gesagt, dass sie dafür nicht zuständig sind. Klingt plausibel. Das ist ja nicht die deutsche Bahn (anscheinend machen sie nur den Merchandise-Shop der DB). Als Ansprechpartner haben sie mir die Telefonnummer der DB angegeben, die ich ursprünglich angerufen habe wo mich die Person an fahrkartenservice@bahn.de verwiesen hat.

Also habe ich noch einmal diese E-Mail-Adresse angeschrieben und denen gesagt, dass mycybergroup nicht zuständig sei. Das war am Freitagvormittag, also vor zwei Tagen. Bisher keine Antwort.

Update 23.3.2025: Die Sache ist endlich geklärt

Nachdem ich eine Woche lang keine Antwort bekommen habe, habe ich die Mail am 16.3.2025 noch einmal abgeschickt. Vorgestern (21.3.2025) hat sich endlich etwas getan. Ich habe eine E-Mail von p.d-datenschutz@deutschebahn.com bekommen. An die wurde meine Anfrage intern weitergeleitet. Die haben mir gesagt, dass sie die Sache erledigt haben. Endlich. Für den Support würde ich die Schulnote 5 geben. Eine 6 ist es nur deswegen nicht geworden, weil ich am Ende doch noch zu meinem Recht gekommen bin.

Golang

Neulich hat mich ein Vereinskamerad aus dem Kanuklub nach meiner Meinung zur Programmiersprache Go gefragt. Ich habe da nur kurz antworten können, weil ich weg musste, aber mir sind so viele Sachen eingefallen, dass ich hier noch etwas dazu schreiben möchte.

Zunächst erst einmal: Ich habe gemischte Gefühle zu Go, und die Gründe dafür werden sich hier durch den ganzen Blogpost ziehen. Ich habe mich Ende 2014 zum ersten Mal mit Go beschäftigt, und war damals begeistert. Kurze Zeit später wurde Go bei mir aber von Rust verdrängt.

Ich habe seitdem in verschiedenen Programmiersprachen gearbeitet, auch beruflich, und ich kann sagen, dass ich Go immer noch vielen Sprachen vorziehen würde, darunter Java, Javascript, je nach Anwendungsfall Python oder C oder C++ und in jedem Fall PHP (in den meisten Fällen würde ich allerdings dann eher in Rust schreiben als in Go). Aber schlüsseln wir das mal auf.

Die Grundkonzepte

Go ist typsicher und kompiliert, viele Fehler fallen deshalb schon beim kompilieren auf. Go hat einen Garbage Collector und keine externe runtime, dafür sind Go-binaries schnell ein paar Megabyte groß. Go lässt sich gut in Container (z.B. Docker) verpacken, und zwar minimale Container, die nichts enthalten außer der Go-Binary.

Besonders an Go ist, wie selbstverständlich nebenläufige Programmierung in die Sprache eingebettet ist. Goroutinen sind leichtgewichtig zu starten (anders als Threads in den meisten anderen Sprachen), channels ermöglichen Kommunikation zwischen Goroutinen ohne mit Locks herumhantieren zu müssen (die gibt es auch, für Spezialfälle).

Go hat eine umfangreiche Standardbibliothek, so kann man zum Beispiel ohne externe Abhängigkeiten einen Webserver aufsetzen, inklusive HTML-Templates und JSON-Serialisierung/Deserialiserung von und in Go-structs.

Tooling

Go hat schon standardmäßig einiges an Tools. Da ist zum Beispiel gofmt, um Quellcode zu formatieren. gofmt ist opinionated, hat also genaue Vorstellungen davon, wie gut formatierter Code auszusehen hat und lässt sich nur schwer davon abbringen. Ich zähle das als positiven Aspekt. Dadurch hat jedes Go-Projekt die gleiche Formatierung. Klar, die gefällt mir nicht an allen Stellen, aber ich muss keine Energie darauf verschwenden, mir Gedanken darüber zu machen.

Go hat keinen eigenen Paketmanager. Abhängigkeiten werden üblicherweise über Git-Repos geladen. Lange hatte Go auch keine Möglichkeit, explizit Abhänigkeiten anzugeben, man musste alle zum Projekt gehörigen Sachen in einem Pfad haben, den man durch die Umgebungsvariable $GOPATH definiert hatte. Das war umständlich und fehleranfällig. Seit einigen Jahren gibt es Modules, die den Umgang mit Projekten, Abhängigkeiten und deren Versionen vereinfachen.

Tools für automatische Tests (insbesondere unit tests) sind auch von Haus aus mitgeliefert und bieten ein paar Komfortfunktionen, es gibt also keine Ausrede, keine Tests zu schreiben.

Error-Handling

Go hat kein System von Exceptions. Jede Funktion kann mehrere Rückgabewerte haben, Funktionen, die Fehler erzeugen können, geben einfach neben dem eigentlichen Rückgabewert noch einen Fehlertyp zurück. Wenn es keinen Fehler gab, ist der nil.

Dadurch vermeidet man eine ganze Reihe von Problemen, die man mit Exceptions hat. Insbesondere kann man direkt sehen, in welcher aufgerufenen Funktion ein Fehler auftreten kann und wie damit umgegangen wird.

Der Nachteil ist, dass Errorhandling in Go sehr verbose ist. Man hat praktisch immer ein

a, err := foo
if err != nil {
    return err
}
// [Erfolgsfall]

In Rust zum Beispiel gibt es für dieses Konstrukt ein Kürzel. Außerdem ist es in Go recht einfach, den Fehlerfall aus Versehen zu übergehen und mit dem anderen Rückgabewert weiterzuarbeiten. In dem steht aber im Fehlerfall üblicherweise nur Müll. Das kann zu den lustigsten Fehlern führen. Alles schon erlebt.

Eine weitere Schwäche hier ist, dass man üblicherweise nur den Typ error zurückgibt. Das ist alles was ein error-Interface implementiert. Man kann also nur sehr umständlich herausfinden, welcher Error jetzt speziell gerade zurückgegeben wurde. Wenn man je nach Fehlertyp unterschiedlich handeln will, muss man eine Menge Extracode schreiben.

Für schwerwiegende Fehler, mit denen das Programm nicht umgehen kann (z.B. Division durch 0) gibt es auch noch panic. Das funktioniert ähnlich wie in rust und ist prinzipiell erst einmal nicht recoverable. Man sollte also vermeiden, dass es ein panic gibt.

Typsystem

Das Typsystem von Go ist erst einmal nicht schlecht. Man hat strikte Typisierung, einen Haufen grundlegender Typen und kann mithilfe von struct neue Typen definieren. Vererbung, virtuelle Funktionen und dergleichen gibt es nicht. Das verbuche ich auch positiv. Interfaces gibt es schon, also kann man wenn nötig eine gewisse, nützliche aber harmlose Art von Polymorphie haben.

Aber es gibt eine ganze Menge an Dingen, die ich an dem Typsystem auszusetzen habe.

The Billion Dollar Mistake

Es gibt in Go auch pointer (die immerhin memory-safe sind). Aber diese Pointer können auch nil sein (null oder None in anderen Sprachen). Es gibt keine nonnull-pointer. Mit anderen Worten: Überall, wo man Pointer verwendet (manchmal kommt man nicht darum herum) muss man überprüfen, ob der Pointer nil ist.

Außerdem werden hier zwei semantische Konzepte vermischt: Auf der einen Seite das Konzept der Referenz: Ein Wert, der auf einen anderen Wert verweist. Auf der anderen Seite das Konzept der Optionalität: Ein Wert, der entweder da ist oder eben nicht. Vielleicht möchte ich auch ein nicht-Referenz, die Optional ist. Oder eine Referenz, die nicht optional ist. Geht nicht.

Erschwerend kommt noch hinzu, dass nicht alle nil-Werte gleich sind und man beim Vergleichen zweier nil-Werte ein false bekommt.

Oh, aufgrund einiger komischer Zusammenhänge (s.u. unter „Nerviges“) ist nil eine leere slice und man kann Sachen dranhägen. Für Wörterbücher gibt das hingegen einen Fehler.

Default-Werte

Uninitialisiere Variablen sind gefährlich, also hat Go sich das Konzept der Defaultwerte ausgedacht. Das ist z.B. 0 für Integer-Typen, false für boolean, der leere String für Strings usw. Structs werden per default mit den Defaultwerten ihrer Member initialisiert.

Das führt dann zu Problemen, wenn man einem struct einen neuen Member hinzufügt. Wenn man dann nicht alle Stellen anpasst, an denen dieses Struct initialisiert wird, wird einen der Compiler nicht warnen und stattdessen dort einfach den Defaultwert reinschreiben. Versucht mal, den Fehler zu finden.

Array-Slices werden per default mit nil initialisiert, aber das ist eigentlich kein Problem, weil man trotzdem noch Sachen dranhängen oder die Länge abfragen kann. Lustigerweise gilt das für map (ein Wörtberbuch) aber nicht: Das wird standardmäßig mit nil initialisiert und jede Interaktion damit führt zu einer panic.

Ein weiterer Punkt, wo die Default-Werte nervig sind, ist beim Deserialisieren von JSON: Wenn ein Feld in dem Struct, in das deserialisiert wird, nichtim JSON vorkommt, wird es einfach auf den Defaultwert gesetzt. Ich habe da schon die lustigsten Probleme mit gehabt:

Fall 1: Wert ist verpflichtend, Aufrufer vergisst ihn

In diesem Fall wird einfach angenommen, der Aufrufer hätte eine 0 oder so angegeben. Besser wäre hier, dem Aufrufer einen Fehler zurückzugeben.

Fall 2: Wert ist optional, ist aber im struct nicht als pointer definiert

In diesem Fall muss man hoffen, dass der Defaultwert kein gültiger Wert ist. Ich habe schon einmal Code gesehen, der immer eine leere Liste zurückgegeben hat, weil der optionale Wert so etwas wie max_results war, mit dem man angeben konnte, ob die Anzahl der Ergebnisse beschränkt sein soll.

Wenn der Defaultwert kein gültiger Wert ist, kann man natürlich einfach dagegen testen. Schön ist das aber nicht

Fall 3: Wert ist optional, ist im struct als pointer definiert

Für die Schnittstelle ist hier alles fein. Fehlt der Wert im JSON, ist der Wert im struct nil und man weiß, dass er nicht da ist.

Lustig wird es, wenn man in einem Struct einen Pointer auf einen primitiven Typ hat und dann versucht, das Struct zu initialisieren. Geht nicht ohne weiteres, weil man keinen Pointer auf z.B. ein uint32-Literal machen kann. Man muss zuerst eine gesonderte Variable anlegen und kann dann per Pointer darauf verweisen.

Meiner Meinung nach schaden Default-Werte also mehr als sie nützen und sind insbesondere in der Kombination mit nil-Werten bzw. mit den fehlenden Optional-Typen nervig.

Immutability

Es gibt keine gute Möglichkeit, Werte in Go immutable zu machen. Man kann immer alles überschreiben. Die einzige Lösung wäre, in einem Struct alle Member private zu machen und jede Menge Get-Funktionen zu schreiben. Macht aber keiner, weil es jede Menge Boilerplate erzeugt und wir ja gerade von Java wegwollen.

Generics

Lange Zeit gab es in Go keine Generics. Die Begründung war immer, dass man die ja nicht so dringend braucht. Auch mein ehemaliger Chef, ein großer Go-Fan, fragte immer: „Wann habt ihr das letzte mal etwas geschrieben, wo ihr Generics gebraucht habt?“.

Klingt nach einem fairen Punkt, verfehlt aber das Problem: Wenn man Anwendungen schreibt, braucht man meist keine Generics. Wenn man Bibliotheken schreibt sind sie hingegen oft sehr, sehr nützlich. Ein anderes Team in meiner alten Firma hatte dann eine Bibliothek benutzt, die einen fucking Code Generator dabei hatte, um typisierte Go-Dateien zu erzeugen. Lächerlich.

Und die Bibliotheken wird man früher oder später brauchen, wenn einem auffällt, dass man mit Arrays und Wörtberbüchern zwar sehr weit kommt, es aber immer Fälle geben wird, in denen man Containertypen braucht, die nicht in der Standardbibliothek drin sind (außer in Rust, an dieser Front ist Rust wesentlich besser aufgestellt als Go).

Nerviges

Ein paar Dinge sind keine große Sache, nerven mich aber doch ein bisschen. Da wäre zunächst:

Privacy

Wie manche andere Sprache auch hat Go ein Konzept von privaten Werten und Funktionen. An sich finde ich die Implementierung ganz nett: Innerhalb eines Moduls kann man auf alles zugreifen, was dort definiert ist, außerhalb nur auf die öffentlichen Sachen.

Was mich ein bisschen nervt ist, wie private Werte deklariert werden: Großbuchstabe am Anfang? Public. Kleinbuchstabe? Private.

Datums-/Zeitformatierung

Die meisten Sprachen bzw. Datumsbibliotheken von Sprachen haben eine Funktion, mit der man ein Datum in ein Textformat bringen kann. Die haben dann abstrakte Platzhalter, z.B. %m für den Monat. Golang hat einen anderen Weg genommen. In Golang gibt es ein Referenzdatum (in einem sehr ungewöhnlichen Format noch dazu): 01/02 03:04:05PM '06 -0700".

Ein Datumsformatstring muss dann die richtigen Zahlen aus diesem Datum zusammenpicken, ggf. noch auf eine 24-Stundenanzeige umrechenen und eingeben. Ein RFC3339-Datum sähe dann zum Beispiel so aus: 2006-01-02T15:04:05Z07:00.

Ich kann mir denken, was der Gedanke dahinter war: Hey, dann kann man direkt sehen wie das Datum am Ende aussieht. Praktisch gesehen ist das aber nicht der Fall. Wie soll ich mir merken können, ob 01 jetzt der Monat oder der Tag ist? Wie soll ich mir die ganzen anderen Zahlen merken können. Ich muss jedes Mal nachschauen, was denn jetzt das Referenzdatum ist.

arrays und slices

Go hat Arrays, die eine feste größe haben und slices, die auf einen Ausschnitt eines Arrays zeigen und Funktionen haben, mit denen man sie wachsen lassen kann. Für ein slice s kann ich also folgendes machen:

s = append(s, 4)

So wird der Wert 4 an das Slice angehängt. Leicht ungewöhnliche Syntax, aber daran könnte ich mich gewöhnen, wenn es wenigstens konsistent mit irgendeinem anderen Kontrukt in der Sprache wäre.

Wirklich fies wird es aber erst, wenn man mehrere Referenzen auf die slice hat. Sollte bei append das der Slice zugrundeliegende Array nicht groß genug sein, wird ein neues allokiert, die Daten aus dem alten rüberkopiert und der neue Wert hinzugefügt. Ansonsten wird nur der neue Wert hinzugefügt.

Preisfrage: Wenn man jetzt mehrere Referenzen hat, was passiert dann mit der alten Slice? Wenn ich in der jetzt etwas ändere (ein Feld ander zuweise), ändert sich dann die neue slice auch?

Die Antwort ist: Kann man nicht sagen. Das hängt davon ab, ob ein neues Array allokiert wurde. Wenn nein, dann ändert man auch die neue slice. Wenn doch, dann bleibt das neue slice unbehelligt.

Die einzige Lösung ist also: auf keinen Fall mehrere Referenzen auf dieselbe slice.

Kein map/filter/reduce

Was ich in Rust ja sehr schön finde ist die umfangreiche Sammlung von Funktionen, die man auf Iteratoren durchführen kann. Golang hat so etwas nicht. Keine map()- Funktion, kein filter(), kein reduce(). Aber hey, vielleicht kann man das ja per Bibliothek dazuladen?

Mittlerweile vielleicht. Lange Zeit ging das nicht oder nur mit erhöhtem Aufwand, denn es gab ja keine Generics.

Tiefe Kopien

Es gibt keine einfache Möglichkeit in Go, tiefe Kopien von etwas zu erstellen. Das habe ich schon on Java gehasst. In C++ geht es immerhin halbwegs einfach (mit ein bisschen Handarbeit in manchen Fällen), in Rust ist es trivial.

Unicode-Handling

Go-Quellcodedateien sind strikt UTF-8. Strings in Go… sind eigentlich nur unveränderbare uint8-Arrays. Man kann praktisch jeden Müll dort hereinschreiben. Klar, es gibt Funktionen um auf gültiges UTF-8 zu testen. Die meisten anderen Entwickler nutzen sie nur nicht und sind sich nicht einmal des Problems bewusst.

The Ugly

An meinem ehemaligen Job gab es im Slack im #Go-Channel immer ein schönes Spiel. Irgendein Kollege hat ein Stück Go-Code geposted, das ganz harmlos aussah und gefragt: „Was gibt dieser Code hier aus?“.

Worauf ich hinaus will: Go hat einige wirklich fiese Gotchas. Keine Speicherkorruption, so weit sind wir hier nicht, aber einige Sachen, die in Rust definitiv nicht möglich sind, aber auch in vielen anderen Sprachen wie z.B. Java oder Python. Hier ein Beispiel (für Go-Versionen vor 1.22):

func main() {
	f := make([]func(), 5)
    for i := 0; i < 5; i++ {
        f[i] = func() {
            fmt.Println(i)
        }
    }
    for _, f := range f {
        f()
    }
}

Was gibt der Code aus? 55555. Warum? Nun, die Variable i wird in der closure eingefangen. In der for-Schleife wird sie aber weiter hochgezählt. In den meisten Sprachen würde man davon ausgehen, dass hier der Wert in die Closure kopiert wird. Wird er aber nicht. Es wird die Variable eingefangen. Wenn die Closures dann nach Ablauf der Schleife ausgeführt werden, ist i überall auf 5.

Das Verhalten wurde glücklicherweise in Version 1.22 geändert (was ich bis vorhin nicht wusste). Bis dahin mussten wir uns immer auf zusätzliche Linter verlassen, die uns davor gewarnt haben.

Unglücklicherweise habe ich keinen Zugriff mehr auf die ganzen anderen Gotchas aus dem Slack-Channel. Ich vermute mal, dass einige andere auch durch diese Änderung behoben wurden. Trotzdem… dass es so lange gebraucht hat dafür, ist ein schlechtes Zeichen.

Fazit

Ich bevorzuge Rust gegenüber Go in fast allen Fällen. Die Sicherheiten, die mir Rust bietet, vermisse ich in Go einfach zu sehr. Trotzdem würde ich weitaus lieber in Go schreiben als zurück zu Java zu gehen. Und ich kann nicht leugnen, dass es in Go viel einfacher ist, einen kleinen Webserver aufzusetzen als in Rust. Für Rust muss man einen Haufen Abhängigkeiten installieren. Für Go… nichts.

Terry Pratchett

Heute vor zehn Jahren ist Terry Pratchett gestorben. Seine Bücher, allen voran die Scheibenweltromane, haben mich sehr geprägt. Ich kann nicht glauben, dass das schon zehn Jahre her ist. Damals hatte ich gerade meinen ersten Vollzeitjob in Hamburg angefangen.

Heute haben einige Fans an GNU Terry Pratchett erinnert. In eigener Sacht möchte ich darauf hinweisen, dass dieses Blog seit fast zehn Jahren GNU Terry Pratchett-kompatibel ist.