Stranger Than Usual

Heute ist wieder Digital Independence Day. Eigentlich hatte ich überlegt, mir heute mal Wero anzuschauen, ein europäischer Zahlungsdienst, der zum Beispiel Paypal ersetzten könnte (es momentan aber noch nicht tut).

Ich bin aber schon beim ersten Schritt gescheitert. Ich habe mich informiert, wie ich das anstellen soll. Zwar wird Wero von meiner Bank unterstützt, aber… nur mit einer Smartphone-App. Bzw. der Smartphone-App der Bank , die allerdings nur über den Google-Store installierbar ist. Den habe ich auf meinem Gerät aber nicht (und den zu installieren wäre ein Schritt gegen digitale Unabhängigkeit). Also kein Wero, nicht einmal zu Ausprobieren.

Mir gehen aber sonst so langsam die Sachen aus, wo ich noch sinnvoll umsteigen kann. Betriebssystem? Linux. Email: Posteo. Git: Codeberg. Gut, ich hätte noch einen alten Amazon-Account, den ich seit Jahren nicht genutzt habe, den könnte ich symbolisch löschen. Oder ich könnte mal versuchen, ob Wine bzw. Steams Wine-Fork Proton gut genug sind, dass ich auf meinem Spielerechner kein Windows mehr brauche (da ich dort kein Windows 11 installieren kann, wäre das sowieso überfällig). Das wiederum kostet aber Zeit, die ich heute nicht habe, weil ich endlich mal ein paar kleine Gartenarbeiten bei meiner Mutter erledigen konnte.

Meine Mutter ist in der Hinsicht übrigens erfolgreicher und hat ihrem Lebensgefährten einen Posteo-Account angelegt. Vielleicht schaffe ich es ja, noch irgendjemand anderen von einem Wechsel irgendwo zu überzeugen.

Im April mache ich übrigens nichts zum Digital Independence Day. Da bin ich im Urlaub, und gebe mein Bestes, an dem Tag keinen Computer (das schließt mein Telefon ein) anzufassen.

Im Mai mache ich dann vielleicht die Sache mit dem Spielecomputer…

Für die ganzen Darkmode-Fanatiker hat dieses Blog jetzt auch einen Darkmode. Ich habe da nicht super viel Arbeit reingesteckt, aber modernes CSS mit Variablen erlaubt mir, das recht einfach einzustellen.

Da ich hier und da transparente Bilder habe, die sich bisher auf einen hellen Hintergrund verlassen haben, habe ich Bildhintergründe grundsätzlich hell gemacht.

Falls ihr also im Browser oder OS bevorzugt den Darkmode ausgewählt habt, dann sollte diese Seite jetzt anders aussehen. Wie gesagt, ich habe nicht viel Arbeit hineingesteckt und hauptsächlich Farben vertauscht.

Seit 2012 benutzte dieses Blog scss für die Styles. Zunächst mit dem ursprünglichen Ruby-Sass-Präprozessor, später dann mit sassc. Aber auch sassc (basierend auf LibSass) wird nicht mehr weiter entwickelt. Ich müsste jetzt zur Dart-Version wechseln.

Nun versuche ich ja, unnötige Abhängigkeiten zu vermeiden. Und dieser notwendige Wechsel stellt mich vor die Frage: Brauche ich scss überhaupt noch für dieses Blog? Listen wir mal die Hauptsächlichen Vorteile auf, die mir SASS in diesem Blog bringt:

1. ich kann die Styles strukturiert auf mehrere Dateien verteilen
2. ich kann Selektoren verschachtelt einsetzen
3. ich kann Variablen (z.B. für Farben) verwenden, so dass ich bei einem Farbwechsel nicht überall Werte ersetzen muss
4. der scss-Präprozessor entfernt Kommentare und unnütze Whitespaces aus den Style-Dateien

Gehen wir kurz durch:

1. brauche ich nicht wirklich, mein CSS ist klein genug, dass ich auch so den Überblick behalte
2. es gibt jetzt natives CSS-Nesting
3. es gibt jetzt native CSS-Variablen

Bleibt Punkt 4. Und der macht, zumindest relativ betrachtet, einen großen Unterschied. Bisher waren mein CSS-Datei etwa 2,2 kiB groß, 844 B gz-komprimiert mit Zopfli, 686 B Brotli-komprimiert. Nach der Änderung waren es zunächst 5,1 kiB unkomprimiert, 1,7 kiB mit Zopfli und 1.4 kiB mit Brotli.

Das ist jetzt natürlich relativ betrachtet ein riesiger Unterschied. Natürlich gibt es andere CSS-Minifier, die ich hier ansetzen kann. Aber dann muss ich ja doch wieder eine Abhängigkeit hinzufügen. Vermutlich müsste ich die sogar über NPM installieren! Brrrr… Aber hey, absolut betrachtet sind alle diese Dateien immer noch ziemlich klein. Besonders, wenn ich an den Bloat anderer Websites denke, die für kleinste Layout-Aufgaben ein komplettes Bootstrap mit über 200 kiB an CSS und JS einbinden. Und zum Vergleich: die 686 B-Brotli-Datei zu übertragen überträge am Ende 1,26 kiB an Daten. Warum? HTTP-Overhead.

Also könnte ich das eigentlich auch so lassen. Aber ich wäre ja nicht ich, wenn ich nicht zumindest ein bisschen optimieren müsste. Also habe ich die Codeeinrückung (4 Leerzeichen) durch Tabs ersetzt und die Kommentare ein bisschen verkleinert. Und Schwupp: 4,2 kiB unkomprimiert, 1,6 kiB mit Zopfli und 1,3 kiB mit Brotli. Nicht viel besser (ich habe ja auch hauptsächlich gut komprimierbare Teile entfernt), aber auf jeden Fall ein bisschen besser.

Und dafür habe ich jetzt eine Abhängigkeit weniger. Das ist doch auch schön.

Ich will mir ja schon seit Jahren mal einen Staubsaugerroboter anschaffen. Aber einen, der sicher ist und nicht nach Hause telefoniert. Das tun leider die Geräte der meisten bekannten Hersteller. Manche Roboter öffnen (öffneten? ist ein paar Jahre her, dass ich das gelesen habe) zur einfacheren Konfiguration sogar ein kleines, offenes WLAN. Dass dann aber offen bleibt und auch volle Kontrolle über den Roboter ermöglicht, wenn man keine Internetverbindung einrichtet.

Nun gab es ja vor zehn Jahren schon den „Internet of Shit“-Begriff für viele Internet of Things-Dinge. Weil Geräte Internetverbindungen hatten, die ums Verrecken keine brauchten. Weil Die Hausbeleuchtung und die Heizung nach einem Jahr ausfällt, weil der Hersteller pleite geht und die Geräte nicht anders als über das Internet zu steuern sind. Weil Geräte einfach so bei Internetausfall verrückt spielen. Oder einfach weil die Hardwarehersteller keine Ahnung von IT-Sicherheit haben und z.B. alte Softwareversionen mit bekannten Sicherheitslücken verbauen, ohne eine Updatemöglichkeit zu bieten.

Zumindest im letzten Teil könnte man ja meinen, dass die Hersteller mittlerweile dazugelernt haben. Haben sie nicht. Ein Entwickler hat, mehr aus Zufall, Zugriff auf 7000 Roboter einer Marke bekommen, weil der Hersteller überall dieselben Credentials verwendet hat.

Ich habe einen netten Artikel gefunden: Whale Fall. Es geht darum, was mit großen Freie-Software-Projekten passiert, wenn sie sterben. Der Autor vergleicht das mit dem Phänomen des Walsturzes, also wenn ein Wal auf hoher See stirbt, in die Tiefsee absinkt und der Kadaver dort ein eigenes Ökosystem bildet. Analog dazu wird aufgezeigt, wie andere Projekte von so etwas beeinflusst werden.

Rollenspielszene. Wir sind Punks in einem Eldritch-Zug. Wir leben dort. Es passieren immer wieder realitätsverzerrende Dinge. Deswegen ist Jack auch nicht zu sehr überrascht, als er plötzlich weit weg von seinen Freunden im Speisewagen sitzt, ohne die ohnmächtige Person, die er retten wollte, und ohne Fenster und ohne Türen.

Jack ist Künstler und kann mit seinen Graffiti besondere Effekte erzielen. Zum Beispiel kann er etwas, das er auf eine Wand sprüht, auch auf einer entfernten Wand erscheinen lassen, die er vorher schon gesehen hat.

Es funktioniert: Jacks Freunde sehen einen Schriftzug auf der Wand:

Mir geht es gut. Bin im Speisewagen.

Ein Problem nur: Jacks Freunde wissen genau, wo Jack ist. Jack ist vor ihren Auge ohnmächtig geworden, so wie die Leute, die sie retten wollten. Jack ist nicht im Speisewagen. Jack hat in einem Traum etwas an die Wand gesprüht, was dann in der wirklichen Welt erschienen ist.

Rollenspielszene. Das Amulett, das wir suchen, ist in einem Hobgoblinfort, das die Hobgoblins in uralten elfischen Ruinen gebaut haben. Soris der Druide hat in der Gestalt eines Stinktiers schon ein bisschen kundschaften können, aber wir brauchen andere Mittel, um an das Amulett zu kommen.

Also verkleidet sich unser Magier Prattle sich mit einem Zauber als hochranginger Hobgoblin (den wir beim letzten Mal bekämpft haben). Dumm nur: Prattle kann kein Wort der Goblinsprache. Am Tor des Forts tut er mürrisch, grummelt vor sich hin und wird von den Wachen hereingelassen.

Prattle zaubert sich einen Morastgestank an, um die Ursache seiner Unmut zu erklären und wird von einem Hobgoblin in Richtung Keller gewiesen. Während er unten durch die Gänge streift, kommt aus dem Raum des Hobgoblinbosses ein Magier heraus, der die Person, die Prattle verkörpert, wohl kennt und ihn anspricht.

Was tun? Mürrisch zu grummeln funktioniert nicht bei Gleichrangigen. Prattle hat die rettende Idee: Er fängt an, mit dem Magier auf der Feensprache Sylvan zu sprechen und behauptet, verflucht worden zu sein. Der Magier kauft ihm das ab und bietet auch noch an, für ihn beim Boss zu übersetzen.

Ein Arbeitskollege hat auf einem seiner Blogs mit WebGL eine Sonnenauf-/untergangssimulation eingebaut. Wenn man dort auf einen Link klickt, bewegt sich die Sonne und ändert auch die Farbe des Himmels. Das ganze sieht ziemlich gut aus. Ich habe auch ein kleines Video davon aufgenommen und auf Peertube hochgeladen. Mal sehen, welcher von den beiden Links länger überlebt. Schaut euch wenn ihr könnt lieber das Original an.

Das Schöne: Das gesamte Script dafür ist gerade mal um die 11 kiB groß, also recht klein. Und es stört die Funktionalität der Seite auch nicht, wenn man Javascript blockert. Dann kann man die Texte immer noch genau so gut lesen, verpasst halt nur diese Spielerei mit der Sonne.

Und da der Kollege noch keinen Post über die Implementierung der Sonne gemacht hat, verlinke ich stattdessen auf einen Post auf seinem anderen Blog (dieses Blog ist techniklastiger, wobei das andere eher erzählerisch-philosophisch ausgerichtet ist), wo er Schleimpilze simuliert. Auch mit WebGL, auch schön anzusehen. Und mit einer schönen Erklärung, wie es funktioniert.

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.

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.

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:

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.