Stranger Than Usual

I'm on the server floor of a "highly secure data center with 24/7/365 surveillance, direct access control and robust perimeter security".

An actual duck just walked by. 🦆

The panic is absolutely glorious. I think this just became one of the highlights of my life.

Pepjin

CSS, grau, grey und gray

Aus der Serie „Dinge, die ich nie über CSS wissen wollte aber herauszufinden gezwungen war“: Neulich habe wollte ich mal verschiedene mögliche Varianten einer SVG-Datei mit transparentem Hintergrund vor verschiedenen Hintergründen darstellen. Zuerst nur schwarzer und weißer Hintergrund, aber dann habe ich mir gedacht, ich könnte ja eigentlich auch ein paar Grauwerte ausprobieren.

Ich fand es schöner, das mit den CSS-Farbnamen zu machen als mir manuell die Grauwerte herauszusuchen. Dabei habe ich zwei Dinge gelernt.

Erstens: Es gibt in CSS sowohl grey als auch gray. Eine kurze Recherche ergab: Beide sind gültig, beide referenzieren denselben RGB-Farbwert #808080 und wurden vermutlich eingeführt, damit sich Briten und Amis nicht in die Haare geraten, wie es zum Beispiel auf Wikipedia passiert ist. Es wird aber geraten, sich in einer CSS-Datei auf eine Variante zu einigen. Diese doppelte Benennung gibt es auch für andere Grautöne, wie lightgrey und darkgrey Aufgefallen ist mir das, weil ich in einer Liste die RGB-Farbwerte nachgeschaut und je nach Grauton eine unterschiedliche Schreibweise gefunden habe.

À propos lightgrey und darkgrey: Die zweite Sache, die ich gelernt habe ist, dass darkgrey heller ist als grey. Ich hatte mich schon gefragt, ob ich irgendwo falsche Klassen vergeben oder im CSS Mist gebaut habe. Aber nein. Ich wollte drei Blöcke haben, mit immer dunkler werdenden Grautönen und hatte stattdessen #D3D3D3 (lightgrey), #808080 (grey) und #A9A9A9 (darkgrey). Ich weiß nicht, wer sich, das ausgedacht hat, aber es ist sehr kontraintuitiv. Ich habe dann als dunkelsten Grauwert doch manuell einen Wert eingegeben, #444444.

So, und jetzt werde ich mich wieder den schöneren Seiten widmen. Zum Beispiel, dass man heutzutage viele frühere CSS-Hacks durch sauberere, moderne Lösungen ersetzen kann.

PeerPressure: Videos

In meinem kürzlichen Post über mein kleines PeerPressure-Kunstprojekt habe ich ja versprochen, dass noch ein Video kommt. Das kommt jetzt auch. Vorher aber ein paar kleine Anmerkungen dazu.

Meine Güte war es schwierig, die Videodatei klein zu halten. Aber fange ich mal vorne an.

Änderungen am Ablauf

Beim letzten Mal hatte ich ja etwa 100.000 Rechenschritte gemacht. Ich habe das Programm danach erweitert und eine Obergrenze bei einer Million gesetzt, wobei das Programm vorzeitig abbrechen sollte, wenn nur noch eine Farbe auf dem Spielfeld ist (weil sich dann nichts mehr verändert). Außerdem habe ich nur noch von jedem 10. Schritt ein Bild abgespeichert.

Wann (ob?) dieser vorzeitige Abbruchpunkt erreicht ist, ist unterschiedlich. Ich habe mich am Ende für einen Durchlauf entschieden, wo nach weniger als 428.240 Schritten abgebrochen wurde. Ich hatte also 42825 Bilder. Und damit kommen wir zum Encoding.

Video-Encoding-Herausforderungen

Letztes Mal hatte ich eine WEBM-Datei mit VP9 als Encoding verwendet. Das hatte zwei Probleme: Erstens hat es mit dem Ecndoing ewig gedauert, zweitens gab es hinterher bei der Darstellung ganz scheußliche Kompressionsartefakte.

Also habe ich es mit MP4 als container unf H.264 als Encoding versucht. Das ging deutlich schneller, hatte kaum Kompressionsartefakte, aber die Datei war am Ende für etwa eine Stunde Laufzeit 1.1 GiB groß (1.5 GiB mit H.264). Habe ich erwähnt, dass die Auflösung 240p ist, als nur 426×240 Pixel? Zum Vergleich: Die rohen Bilddateien (PNG) waren nur weniger als 400 MiB groß. Wo soll ich denn bitte so ein Monster hochladen?

Ich vermute mal, dass das an den scharfen Kanten und den zufälligen Änderungen zwischen den Kanten lag. Also habe ich mal ausprobiert, die Bilder vorher zu glätten. Ein 3×3 Gaußfilter, so dass alles viel unschärfer aussieht. Man kann die einzelnen Zellen kaum noch erkennen, aber vielleicht sieht es ja trotzdem gut aus. Und die Kompressionsartefakte sollten auch nicht mehr so ins Gewicht fallen.

Unregelmäßige schwarze und weiße Flächen. Die Grenzen zwischen ihnen sind verwaschen.

Das Ergebnis war super: Die Videodatei (MP4, H.264) war nur noch 223 MiB groß. Immer noch ziemlich groß, aber schon deutlich besser. Mit VP9 wurde das Video in diesem Fall gröer als H.264. Nur: Das ist natürlich immer noch zu groß für Pixelfed, Youtube will ich eigentlich vermeiden, und für PeerTube brauche ich erst einmal noch ein bisschen Zeit, weil die Instanz meiner Wahl meinen Accountantrag erst prüfen will.

Also kommt jetzt erst einmal nur ein kurzes, dafür aber nicht geglättetes Video auf Pixelfed.

Update, 2026-02-16: Hier kommt das geglättete Video auf Peertube. Unglücklicherweise sind dort beim Umcodieren doch wieder einige extreme Kompressionsartefakte eingefügt worden. Ich habe auch noch ein bisschen herumprobiert: H.265 wäre hier tatsächlich kleiner, allerdings sieht man deutlich ein paar Kompressionsartefakte (wenn auch nicht so schlimm wie auf der Peertube-Version. Und ein APNG, also eine animierte PNG-Datei (ungeglättet) ist noch kleiner und sogar verlustfrei (ich habe es aber nur mit 1000 Frames getestet). Aber eine APNG ist undhandlich, weil sie von Browsern wie eine Bilddatei und nicht wie ein Video behandelt wird. Also bleibt mir nur die Version mit Kompressionsartefakten. Mein nächstes Projekt wird wieder leichter komprimierbar sein, versprochen!

Statistik

Hatte ich erwähnt, dass ich auch mit jedem Bild abgespeichert habe, wie viele schwarze Pixel es im Bild gibt? Daraus habe ich dann für den Durchlauf, aus dem das Video oben stammt, eine Grafik gemacht:

Ein Graph. Die x-Achse hat den Titel „steps“ und geht von 0 bis etwa 450000. Die y-Achse hat den Titel „# black pixels“ und geht von 0 bis etwas über 100.000. Der Graph beginnt ziemlich in der Mitte der y-Achse, steigt zufällig an und ab, ist zwischendurch bei etwa 80.000, sinkt dann aber wieder, bis er bei etwa 450000 bei 0 ist.

Bonus: Wie glätte ich tausende Bilder?

Eigentlich geht das Glätten eines Bildes mit imagemagick ganz einfach (Warnung: mogrify überschreibt das Eingabebild. Verwendet convert, wenn ihr eine veränderte Kopie erstellen wollt):

mogrify -gaussian-blur 3x3 image.png

Oder mehr als 3x3, wenn man es stärker glätten möchte. Mehrere Dateien sind dann eigentlich ganz einfach:

mogrify -gaussian-blur 3x3 *.png

Hier gibt es aber ein Problem: in Bash wird der Wildcard-Operator * von der Shell ausgewertet und dann eine Liste von Dateinamenn and das Programm gegeben. Irgendwo ist aber mit der Anzahl der Dateinamen Schluss. Wenn man 100.000 Bilder hat, passiert, kriegt man den Fehler Argument list too long.

Manche Programme erlauben es, als Input ein Verzeichnis anzugeben. mogrify nicht, zumindest habe ich keine Möglichkeit dazu gefunden. Also habe ich einen Workaround genutzt:

find . -name '*.png' -execdir mogrify -gaussian-blur 3x3 {} \;

Das sucht alle Dateien, die mit .png enden im aktuellen Verzeichnis und ruft drauf den mogrify-Befehl auf. Nachteil: Der Befehl wird sehr oft aufgerufen, das erzeugt einen Overhead. Stattdessen kann man auch folgendes machen:

find . -name '*.png' -execdir mogrify -gaussian-blur 3x3 {} \+

Das ruft den Unterbefehl mit langen, aber nicht zu langen Listen von Treffern auf, so dass ein Mittelweg gefunden ist.

Kleines Kunstprojekt: PeerPressure

Ich habe neulich einen Blogpost zu Creative Coding gelesen. Der Post ist eine Einführung für Anfänger, wie man mit ziemlich wenig Code schon interessante Bilder erzeugen kann. Das hat mich motiviert, auch mal wieder aktiv zu werden und ein simples Programm zu schreiben, das mir schon länger im Kopf herumschwebt.

Im Prinzip ist das Programm ein einfacher zellulärer Automat, aber randomisiert. Die Wahrscheinlichkeit, dass Zelle im nächsten Schritt einen bestimmten Zustand hat, ist proportional zur Anzahl der benachbarten Zellen (inklusive der Zelle selbst), die in diesem Zustand sind. Beispiel: Eine schwarze Zelle mit vier schwarzen und vier weißen Nachbarn hat eine Wahrscheinlichkeit von 5/9, im nächsten Schritt schwarz zu sein und 4/9, weiß zu sein. Eine schwarze Zelle, die komplett von schwarzen Zellen umgeben ist, bleibt demnach auf jeden Fall schwarz.

Wenn der Anfangszustand so ist:

Die rechte Seite des Bildes ist schwarz, die linke Hälfte ist weiß, die Trennlinie ist scharf

…dann kann es nach 100 Schritten zum Beispiel so aussehen:

Die rechte Seite des Bildes ist schwarz, die linke Hälfte weiß, es gibt keine klare Trennlinie mehr.

…und nach 99999 Schritten so:

Überall im Bild gibt es schwarze und weiße Flächen die Trennlinien dazwischen sind unscharf. Insgesamt sind die schwarzen Flächen größer

Es hat mich etwa eine halbe Stunde gekostet, das grundlegende Programm dafür zu schreiben. Der Code ist auf Codeberg. Ich habe ein bisschen damit herumgespielt. Es hat etwa 80 Sekunden gedauert, 100.000 Schritte zu durchlaufen und für jeden Schritt ein PNG abzuspeichern. Das lässt sich sicher noch verbessern, aber ich sehe gerade nicht viel Sinn darin, denn der eigentliche Flaschenhals ist das Rendern eines Videos daraus. Denn eigentlich sieht das am Schönsten aus, wenn man sieht, wie es sich entwickelt. ffmpeg hat über 2,5 Stunden gebraucht, um aus den 100000 Bildern ein Video zu machen, und das ist nur ein 240p-Video (426×240).

Zudem gibt es in dem Video noch einige Kompressionsartefakte, die es unschön machen, es anzuschauen. Auch die Dateigröße ist ziemlich groß. Ich lade garantiert noch einmal ein Video dazu hoch, aber vorher muss ich ein bisschen mit Codecs und anderen Einstellungen herumprobieren. Vielleicht mache ich auch eine Version, in der ich vorher jedes Bild mit einem Gaußfilter glätte. Oder einen Zeitraffer, wo nur jeder 10. Zustand oder so ins Video kommt.

Fun Fact am Ende: Die 100.000 Bilder waren etwa 1,3 GiB groß. Mit optipng optimiert dann nur noch etwa 750 MiB. Mit zopflipng wäre das vermutlich noch ein bisschen weniger geworden, aber optipng, was schon recht schnell ist, hat mir schon zu lange gebraucht, mit Zopfli hätte das Stunden gedauert.

Rollenpielszenen: Treffen auf dem Dach

Rollenspielszene: Die Band Spice of Life ist in einer ikarischen Militärbasis, wo sie ihren ersten Auftritt haben soll. Dort sind auch ein paar unfreiwillige junge Soldat_innen (Wehrpflicht), die gegen unseren Auftritt protestieren.

Da wir Spione des Nachbarlandes, der Wasted Lands sind, wollen wir unsere geheimen Nachrichten an eine Kontaktperson übermitteln. Die geheime Botschaft haben wir in einem Musiktape verschlüsselt und erst einmal auf unserem Zimmer gelassen.

Nach dem Essen müssen wir auf unserem Zimmer feststellen: Das Tape ist weg! Nur eine Botschaft ist da: „Wenn ihr das Tape zurück haben wollt, trefft uns auf dem Dach“.

Cinnamon (kurz „Cin“) ist begeistert! Ein Stelldichein auf dem Dach! Sehr enttäuscht muss Cin dann aber festtellen, dass Penelope, eine der demonstrierenden Soldat_innen, keine Lust auf körperliche Freuden hat, sondern uns wirklich nur davon abhalten will, unser Konzert zu halten, im Austausch gegen unser Tape (von dessen wahrem Inhalt sie nichts weiß).

Maschinenlesbar

„Wir müssen digitalisieren“, das höre ich in der einen oder anderen Variante oft. Nicht selten bedeutet das aber, dass analoge Arbeitsabläufe 1:1 in Computer übertragen werden, obwohl die Arbeitsabläufe für den analogen Weg optimiert waren und man sie mit dem Computer vielleicht ganz anders gestalten sollte, um effizient und effektiv zu sein.

Ähnlich ist das auch bei der Datenhaltung. Öffentliche Daten sollten auch digital bereitgestellt werden, doch nicht selten bedeutet das, dass irgendwo Bilddateien, PDFs oder PDFs, die nur aus Bilddateien bestehen, hochgeladen werden. Was wir aber wirklich brauchen, sind maschinenlesbare Daten. Dummerweise gehen die Definitionen von „maschinenlesbar“ oft auseinander.

Auf stefan.bloggt.es hat der Blogautor einen Post veröffentlicht, in dem er den Begriff in verschiedenen Sichtweisen definiert, erklärt, was er findet, was wir brauchen, um öffentliche Daten sinnvoll zu nutzen und sich die Gesetzeslage dazu angeschaut. Lest es euch mal durch!

Rollenspielszenen: Kletternde Goblins

Rollenspielszene. Wir sind weiterhin in Goblingebieten und suchen jetzt nach einem Amulett, das uns vielleicht vor der Wilden Jagd verbergen kann. Auf dem Weg zu alten elfischen Ruinen wird eine Gruppe von Hobgoblins auf uns aufmerksam. Sie schicken mehrmals Goblintrupps hinter uns her, die wir aber immer verscheuchen können. Die Goblins sind auch nicht wirklich erpicht darauf, gegen uns zu kämpfen.

Irgendwann wird es den Hobgoblins zu bunt und sie schicken eine Gruppe Worgreiter los, die eine Gruppe von Goblins vor sich herhetzt. Dieses Mal sind auch die Hobgoblins selber dabei, inklusive eines Zauberwirkers.

Soris und Mavas sehen sich bald von Worgen umzingelt. Prattle ist auf einen Baum geklettert und wirkt von dort oben taktisch günstige Zauber. Die meisten. Eigentlich wäre er ein primäres Ziel, aber… die meisten Gegner sind wie gesagt mit Soris und Mavas beschäftigt. Nur die Goblins ohne Worg sehen die Gelegenheit: Sie klettern den Baum hoch, auf dem Prattle sitzt!

Oder eher: Sie geben vor, vergeblich zu versuchen, den Baum hochzuklettern, um ein Alibi dafür zu haben, nicht kämpfen zu müssen. Immer wieder fallen sie aus geringer Höhe herunter, fluchen und jammern, wie schade es doch ist, dass sie den Baum nicht hochkommen. Sonst würden sie sicher ehrenhaft gegen diesen Magier kämpfen, ganz klar!

Überwachungsinfrastruktur

Ich rege mich ja schon seit vor Beginn dieses Blogs über Überwachung und Datensammeln sowohl seitens des Staates als auch seitens privater Unternehmer auf. Aber warum eigentlich? Wäre es nicht gut, Überwachungskameras zu haben? Dadurch werden die Straßen doch sicherer. Ist es nicht wichtig, das Internet zu überwachen, um Terroranschläge zu verhindern? Ist es nicht praktisch, über Facebook mit allen möglichen Menschen in Kontakt zu treten, egal wie viel Daten das Unternehmen dahinter über mich sammelt? Was will Facebook schon mit den Daten, außer mir Werbung zu zeigen? Und dem Staat vertraue doch sicher gerne meine Daten an, oder?

In den USA kann man gerade sehr gut sehen, was damit alles passieren kann. Trumps Sturmabteilung (ICE) hat zum Beispiel eine Software, die mit Gesichtserkennung Leute erkennen kann. Mehr oder weniger zuverlässig. Private Ring-Überwachungskamers werden beschuldigt, Daten an das ICE weiterzugeben. Der Hersteller leugnet das zwar, aber gegeben dass in der Vergangenheit auch Tesla-Bordkameras als Beweismittel herangezogen wurden, oder die Aufnahmen von Alexa-Geräten (ihr wisst schon, diese Dinge, die scheinbar harmlos im Wohnzimmer herumstehen), sind zumindest Beweis dafür, dass der Staat darauf zugreifen könnte.

Worauf ich hinaus will: Es ist egal, mit wie viel guter Absicht die Daten gesammelt werden: in den falschen Händen sind sie gefährlich. Wenn die Nazis ein Land übernehmen, sollten sie es so schwierig wir möglich haben, gegen ihre Gegner vorzugehen. Selbst wenn ich der jetzigen Regierung traue, wer sagt mir, dass in drei Jahren nicht die AfD die Macht übernimmt? Selbst wenn Ich Google vertraue, meine Daten nur für Werbung einzusetzen, wer sagt denn, dass Trumps Regime nicht genug Druck machen kann, um an die Daten zu kommen? Selbst wenn ich mich durch die Überwachungskamera am Bahnhof sicher fühlen würde, wer sagt denn, dass mich in drei Jahren die AfD dabei überwacht, wie ich zu einer Anti-AfD-Demo gehe?

Die beste Möglichkeit, dass Daten nicht in falsche Hände geraten ist, sie überhaupt nicht erst zu erfassen. Und was machen wir stattdessen? Mit dem aktuell diskutierten digitalen Omnibus soll das Datenschutzrecht wieder eingestutzt werden. Die ewig untote Vorratsdatenspeicherung soll wieder aus dem Grab der verfassungswidrigen Gesetze geholt werden. Alle möglichen Bundeslländer wollen Verhaltensscanner einführen.

Sehen die denn nicht, wohin das führt? Der Sicherheitsgewinn dieser Maßahmen ist minimal. Aber das Potential für die Nazis, wenn sie an die Schalthebel gelangen, ist gewaltig. Die USA demonstrieren das gerade sehr gut. Wir, in Deutschland und in Europa, sollten, nein müssen uns dagegen stellen.

Digital Independence Day: Posteo statt Googlemail

Heute ist der zweite Digital Independence Day. Im Januar habe ich mein Blogrepo von github zu Codeberg umgezogen. Diesen Monat ziehe ich meine Email-Adressen um.

Ich habe seit 2012 einen Googlemail-Account. Damals habe ich mir den Account angelegt, weil ich mir mein erstes Mobiltelefon angeschafft habe und das ein Android-Phone war. Damals habe ich es ohne Googlemail nicht hingekriegt, meine Adressen auf das Telefon zu synchronisieren.

Ein paar Jahre später habe ich mir eine Posteo-Adresse zugelegt. Posteo ist sehr datenschutzbedacht, ganz im Gegensatz zu Googlemail. Nur habe ich die Posteo-Adresse zunächst nur für private Kommunikation verwendet. Wenn ich irgendwo in Onlineshops oder dergleichen Accounts anlegen musste, habe ich weiterhin Googlemail genommen.

Das hatte zwei Gründe: Zum einen wollte ich keinen Spam auf die Posteo-Adresse bekommen. Zum anderen gibt es bei Googlemail die Funktion, dass man nach einem + ein beliebiges Suffix an den lokalen Teil der Adresse hängen kann, die Mails aber noch ins selbe Postfach kommen. Zum Beispiel vorname.nachname+bahn@googlemail.com für die deutsche Bahn. So kann ich nachverfolgen, über welchen Weg E-Mail-Adressen geleaked wurden, wenn ich Spam bekomme.

Warum ändere ich das jetzt? Mehrere Gründe:

  1. Posteo kann jetzt auch das +suffix
  2. Ich wollte nicht, dass die ganzen Shopseiten meine Haupt-Email-Adresse kennen. Aber warum soll Google eigentlich wissen, wo ich einkaufe?
  3. Es hängen einige wichtige Accounts an der Googlemail-Adresse. Wenn sich Trump morgen entscheidet, Deutschland zu sanktionieren, bin ich von all diesen Accounts ausgeschlossen.

Ich habe also die am häufigsten genutzten Accounts von Googlemail zu Posteo umgezogen.

Was ändert sich nicht?

Ich werde den Googlemail-Account nicht löschen. Einige alte Bekannte haben vielleicht nur diese Adresse. Für die möchte ich weiterhin erreichbar sein. Außerdem gibt es noch einen Haufen kleinerer Seiten, die ich noch nicht umgezogen habe. Mein Plan: Ich ziehe sie dann um, wenn ich eine Email von denen bekomme oder ich mich auf deren Seiten einloggen will. Nach und nach.

Fun fact: Googlemail

Ich nenne es immer noch „Googlemail“, dabei heißt es eigentlich Gmail. Warum? Es gab in Deutschland eine Zeit lang einen Markenstreit, so dass Gmail in Deutschland Googlemail hieß. Als ich meinen Account erstellt habe, habe ich eine @googlemail-Adresse bekommen, und bin dabei geblieben.

Technology Connections über erneuerbare Energien

Ich bin gestern über diese Video des Youtube-Kanals „Technology Connections“ gestolpert. Es geht um erneuerbare Energien, mit einem besonderen Fokus auf Solarkraft und Batterien zum Speichern von Energie.

Das Coole an dem Video: Er hat es geschaft, eine sehr solide Argumentation für erneuerbare Energien auf die Beine zu stellen, ohne den Klimawandel erwähnen zu müssen. Alleine aus wirtschaftlicher Sicht sind Solar- und Windkraft fossilen Energieträgern weit überlegen. Das Video kann also auch die Spinner überzeugen, die den Klimawandel für eine Lüge halten.

Ich folge dem Kanal schon eine Weile. Normalerweise bringt er deutlich kürzere Videos, in denen mehr oder weniger alltägliche Technologien erklärt und demonstriert werden, zusammen mit ihren Vor- und Nachteilen. Der Kanal ist auf jeden Fall sehenswert. Das neue Video ist ziemlich lang, aber ihr solltet es trotzdem anschauen, selbst wenn ihr schon von Solar- und Windkraft überzeugt seid, denn es gibt euch vielleicht noch ein paar gute Argumente, um andere Menschen zu überzeugen.

Plesiosaurier

Die Westfälischen Plesiosaurier sind die Fossilien des Jahres 2026. Plesiosaurier sind übrigens keine Dinosaurier, sondern Reptilien, die aber zeitgleich mit Dinosauriern lebten.

Das verlinkte Blog ist das Beutelwolf-Blog, wo der Autor regelmäßig Tierarten vorstellt. Nicht nur ausgestorbene (wie der Name vermuten lässt), sondern, soweit ich es beobachtet habe, hauptsächlich rezente Arten. Kann sich lohnen, da mal ab und zu reinzuschauen.