Stranger Than Usual

Ich habe mich immer für jemanden gehalten, der gut mit Einsamkeit klarkommt. Immerhin habe ich (gefühlt mehr als andere) häufig das Bedürfnis, allein zu sein.

Aber diese Isolation die es bedeutet, jetzt von zu Hause aus arbeiten zu müssen, die treibt mich echt in den Wahnsinn. Hinzu kommt, dass mein Arbeitsplatz meine Wohnung infiltriert hat. Ich habe keinen eigenen Raum für Heimarbeit, nicht einmal eine eigene Ecke. Ich kann nur den Tisch nehmen, den ich normalerweise zum Spielen nehme. Das ist schlecht.

Ironischerweise, trotz aller Warnungen Gesellschaft zu meiden, und nur für das Notwendigste das Haus zu verlassen, war es heute auf dem Markt und im Supermarkt voller als sonst.

Und kann mir mal jemand das mit den leergekauften Regalen im Supermarkt erklären? Nur weil jetzt alle zu Hause sitzen wird doch nicht sooo viel mehr gegessen, oder? Und wenn ja, warum ist dann diese Nahrungsaufnahme so viel mehr fokussiert auf den Kauf von Mehl? Ich habe wirklich kein Vollkornmehl mehr gekriegt (was es umso ärgerlicher macht, dass ich im Januar alles Mehl bei mir zu Hause wegen Schädlingsbefall weggeworfen habe).

Aber wo ich das mit dem Mehl noch irgendwo erklären kann (ich arbeite nicht zu Hause, gehe also nicht mehr jeden Tag essen und muss dementsprechend selber mehr kochen — das gilt also vermutlich auch für andere, auch wenn das nicht den Fokus auf Mehl erklärt), die Sache mit dem Toilettenpapier geht mir echt nicht in den Kopf. Warum? Wird so viel mehr verbraucht? Oder sind das Panikkäufe? Wenn es letzteres ist, was ist die Idee dahinter? Falls die Versorgung der Bevölkerung wirklich so weit zusammenbrechen sollte, dass es kein Klopapier mehr gibt, ist Klopapier vermutlich das geringste Problem.

Der Vorteil der ganzen Pen & Paper-Rollenspielrunden, die jetzt online stattfinden ist ja, dass ich jetzt bei jeder Runde Tee trinken kann.

Donald Trump hat die USA ja jetzt offiziell aus der WHO ausgetreten. Begründung: Sie soll zu spät auf die Covid-19-Pandemie hingewiesen haben usw.

Wenn man danach geht, sollten die USA eigentlich Trump feuern, weil er die Pandemie ja oft genug gegen besseres Wissen heruntergespielt hat, zu früh nach Öffnungen gedrängt hat, ein wissenschaftlich für diesen Zweck noch nicht genau untersuchtes Medikament (Chloroquin) entgegen aller Warnungen als Allheilmittel propagierte (aktueller Stand: das ist es nicht), die innere Anwendung von UV-Licht und Desinfektionsmitteln als Therapie vorgeschlagen hat (wer wollte nicht schon einmal einen Sonnenbrand in der Lunge) und die Situation anscheinend als Wettkampf zwischen Staaten betrachtet (und dementsprechend die Tests zurückfahren will, weil die hohe Zahl von Infizierten an den im Verhältnis zu anderen Ländern an der hohen Testrate in den USA lag (was erstens nicht stimmt und zweitens komplett irrelevant ist, weil man durch weniger Testen nicht weniger Infizierte bekommt, sondern nur schlechtere Daten).

Aber das ist eigentlich whataboutism. Wenn man betrachtet, wie gut oder schlecht sich die WHO gehalten hat, sollte man nicht damit ablenken, dass andere einen noch schlechteren Job gemacht haben.

Tatsache ist: Die WHO mag vielleicht wirklich ein bisschen langsam reagiert haben, und China hat vermutlich wirklich zu spät zugegeben, dass sie ein Problem mit einer Seuche haben. Aber China hat danach wirklich viel dafür getan, die Epidemie einzudämmen, und die WHO ist alles in allem eine wichtige Insitution im Kampf gegen eine Pandemie.

Kurz gesagt: Man löst nicht die Feuerwehr inmitten eines Stadtbrandes auf, weil sie ein bisschen zu spät auf den ersten Brand reagiert hat. Man kümmert sich erst darum, dass der Brand gelöscht ist und untersucht danach, was man an der Feuerwehr verbessern kann, damit die Reaktion beim nächsten Mal besser ist.

Ich habe mir vor drei Tagen Sea of Thieves gekauft. Das ist so eine Art Online-Piratenabenteuer-Simulator. Nette Grafik, schöne Piratenatmosphäre, viele Schätze zum Ausbuddeln.

Zwei Tage konnte ich ohne Probleme spielen. Gestern Abend begrüßte mich stattdessen eine Fehlermeldung, dass die Sea of Thieves-Dienste gerade nicht verfügbar seien, Fehlercode "Lavenderbeard".

Nach einigem Ärger stellte sich heraus, dass Microsoft mein eigens für diesen Zweck angelegtes, zwei Tage altes Konto gesperrt hatte und ich es erst einmal wieder entsperren musste, um wieder spielen zu können.

Wäre ja schön gewesen, wenn das Spiel mir das auch gesagt hätte. Hat es aber nicht. Bravo, Microsoft.

Es ist ja schon häufiger vorgekommen, dass Artikel auf Satireseiten (z.B. The Onion) für echte Nachrichten gehalten wurden, von Leuten verbreitet wurden, die sich den Artikel nicht angeschaut haben um dann einen riesigen Aufruhr zu verursachen oder sogar Verschwörungsmythen bestärkt

Dazu fällt mir immer Poe's law ein. Besagt, dass ein hinreichend extremer Standpunkt (klassischerweise politische oder religiöse Standpunkte) nicht von Satire unterschieden werden kann. Sowohl auf Seiten der Extremisten als auch auf der Seite derer, die gegen die Extremisten argumentieren wird es immer welche geben, die Satiren für real halten oder extreme Aussagen für Satire.

Das gilt anscheinend auch für absurde Verschwörungsmythen. So hat der Postillon (eine allseits bekannte Satireseite im Stil einer Nachrichtenseite) vor ein paar Tagen einen Artikel veröffentlich, nach dem eine Recherche ergeben habe, dass Attila Hildmann, Ex-Kochbuchautor und Verbreiter von absurden Verschwörungsmythen von der Regierung dazu bezahlt werde, um die Szene der Verschwörungsmythiker lächerlich zu machen.

Ergebnis: Laut FAZ-Artikel musste Hildmann jetzt seinen Fans erklären, dass Der Postillon eine Satireseite ist.

Insofern gehen sich die Verschwörungsmythiker jetzt gegenseitig an den Kragen, also keine schlechte Sache für den Rest von uns. Lustigerweise ist die Lage tatsächlich eine geschachtelte Version von Poe's law: Eine Satire darüber, dass jemand Verschwörungsmythen anhängt, die so absurd sind, dass sie nur eine Satire sein können, wird von Menschen als wahr interpretiert.

Facebook droht anscheinend damit, sich aus Europa zurückzuziehen, wenn sie nicht weniger reguliert werden (wozu natürlich u.a. auch Datenschutz gehört).

Naja, streng genommen behaupten sie, nicht zu drohen, sondern nur nicht zu wissen, wie sie denn weiterarbeiten sollen ohne all die Daten zu verwursten.

Dazu fällt mir nun eine Bemerkung in einem Vortrag auf dem 36c3 ein (die ich gerade nicht mehr im Wortlaut zusammen kriege): Wenn Facebook morgen weg wäre, wäre das überhaupt kein Problem.

Update (2020-10-07)

Kaum habe ich die Kommentare entfernt, kommt MJF und will kommentieren. Gut, Kommentare sind theoretisch ja nach wie vor möglich. Sie müssen halt nur an mich geschickt werden, und ich pflege sie manuell ein.

Im Grunde kein großer Verlust. Instagram würde ich persönlich vermissen, weil neben den ganzen Selfies und Influencern eine Parallelwelt der „ernsthaften Fotografieszene“ existiert.

Der Verlust von WhatsApp ist für Europa natürlich eine Katastrophe, wäre von mir aber sehr zu begrüßen.

Facebook würde ich im Grunde auch nicht hinterher trauern. Leider hat sich die 50er-Jahre-Szene darüber organisiert, nachdem MySpace gestorben ist. Und ich wüsste nicht, was Facebook ersetzen soll. Es ist (innerlich) hässlich und stinkt, funktioniert aber einfach sehr gut, um sich zu verabreden und zu organisieren.

Die Aussage „Wenn Facebook morgen weg wäre, wäre das überhaupt kein Problem“ ist natürlich überzogen. Aber Facebook (und andere zu Facebook gehörende Plattformen) können ersetzt werden-

Ich glaube zum Beispiel, dass das Internet ein ausreichend großer Ort ist, dass sich Leute dort auch ohne Instagram darstellen können.

Was die Organisation von Szenen angeht: Hier bin ich sicher, dass man Facebook ersetzen kann. Vor Facebook konnten sich Szenen auch schon organisieren. Es gab zum Beispiel Foren. Außerdem gibt es dezentrale soziale Netzwerke, die nicht so einen auf Datenkraken machen (können) wie Facebook.

Zugegeben, das geht nicht von heute auf morgen. Aber es geht, wie alleine schon daran zu sehen ist, dass z.B. die 50er-Jahre-Szene den Sprung von MySpace zu Facebook gemacht hat.

Ich arbeite ja gerade immer mal wieder an einer neuen Version dieses Blogs. Unter anderem muss da natürlich auch wieder der Newsfeed rein.

Momentan habe ich zwei feeds: einen rss feed und einen atom feed. Atom ist der Nachfolger von rss und ein besser durchdachtes Format.

Nun würde es mir Arbeit und Wartungsaufwand ersparen, wenn ich in Zukunft nur noch atom unterstützen müsste. Deswegen plane ich, den rss-feed einzustellen. Noch hat dieses Blog ja eine einfach Kommentarfunktion, wenn das jemandem Probleme bereitet, kann man das da gerne äußern.

Gesetzt natürlich den Fall, dass mehr als eine Handvoll Leute, die ich persönlich kenne, dieses Blog lesen.

Sooo… wenn alles gut läuft, kann ich das Blog am Wochenende umziehen. Es sind dann noch nicht alle geplanten Features drin, aber alle wichtigen.

Also kann es sein, dass dieses Blog hier am nächsten Wochenende offline ist. Falls es länger offline ist, hat irgendwas nicht funktioniert.

Das ist es. Der (zumindest von mir) lange erwartete Neustart meines Blogs. 2008 habe ich mein altes altes Blog bei bei einer Blogplatform aufgemacht. Das ist auch heute noch da, sieht immer noch genau so scheiße aus wie damals (dazu habe ich auch zu Genüge geschrieben) und hat sich allem Augenschein nach technisch auch nicht weiterentwickelt (benutzt u.a. noch XHTML). Nichtsdestotrotz ein Anfang, und ich habe immer noch vor, meine alten Blogposts mal ins neue Blog zu importieren.

Das hat etwa vier Jahre gehalten. Im Jahre 2012 habe ich mich dann in Ruby on Rails eingearbeitet und damit ein Blogsoftware geschrieben. Die hat etwa acht Jahre gehalten. Weiter unten schreibe ich noch, warum ich die jetzt ablöse. Jetzt aber erst einmal die wichtigsten Änderungen (abgesehen davon hat sich das Farbschema leicht geändert, weil ein Analysetool behauptet hat, die Schriftfarbe von Links habe zu wenig Kontrast mit dem Hintergrund und sei damit ein Problem für Menschen mit Sehbehinderung).

Wichtigste Änderungen

• Die Kommentarfunktion gibt es nicht mehr. Ich habe die alten Kommentare (minus die Spam-Kommentare) zwar aus dem alten Blog exportiert, weiß aber noch nicht, ob ich die je irgendwie ins neue Blog einbinden werde.
• Die URLs für das Archiv haben sich geändert. Bei den meisten URLs habe ich mir Mühe gegeben, dass sie gleich bleiben, beim Archiv nicht. Das Archiv war sowieso einem ewigen Wandel unterworfen, weil die neuesten Artikel auf der ersten Seite standen. Jetzt stehen die ältesten Artikel auf der ersten Archivseite, die neuesten am Ende. Damit bleiben alte Archivseiten-URLs in Zukunft konsistent
• es wird kein RSS-feed mehr angeboten. Das Atom-feed besteht weiterhin, wie angekündigt. RSS-Feed-Nutzer sollten auf das Atom-feed umsteigen.
• die Indexseiten für die gehosteten Dateien des Blogs (größtenteils Bilder) sind noch nicht implementiert. Die sind bisher auch kaum verlinkt. Sie kommen aber wieder.
• die QOTDs (insbesondere das Zitat auf der Startseite) sind noch nicht implementiert. Das folgt auch noch.

Weniger wichtige Änderungen

• vorerst werden die assets (favicon, css) nicht mit Hash ausgeliefert, was dauerhaftes Cashing schwieriger macht. Das folgt noch.
• Das CSS und die meisten HTML-Seiten sind kleiner. Die Kompression ist besser, weil die Dateien vorkomprimiert werden
• die Rendering-Zeit auf dem Server entfällt. Anfragen werden schneller beantwortet
• im Hintergrund arbeitet jetzt nginx anstatt apache2

Neue Software im Hintergrund

Die Idee, die Rails-Software für das Blog abzulösen, hatte ich schon länger im Kopf. Ich hatte damals kaum Tests für das Rails-Blog geschrieben, somit wurde jedes Update, jede Änderung zu einer Gefahr, dass danach nichts mehr geht. Und ich musste Updates machen, nicht zuletzt, weil in meinen Abhängigkeiten gelegentlich Sicherheitslücken gefunden wurden. Manche dieser Lücken konnten nur mit einem Update der Major-Version von Rails behoben werden. Die sind aber immer schwierig, und zuletzt hing ich immer noch hinterher.

Einen stabilen, sicheren Webserver zu bauen kostet aber Zeit. Andererseits war die Lage so nicht mehr haltbar. Irgendwann auf dem oder nach dem letzten Kongress (36c3) habe ich dann die Entscheidung getroffen, mir einen statischen Seitenrenderer zu bauen und ganz old-fashioned einfach nur HTML-Dateien auf einer Platte liegen zu haben und einen Standardserver, der sie ausliefert.

Eigentlich waren es zwei Entscheidungen:

• statisches Rendern vs. dynamisches Rendern
• bestehende Software vs. selbstgeschriebene Software

Warum statisch und nicht dynamisch?

Ein dynamisch gerendertes Blog hat ein paar Vorteile:

• man muss nicht alles sofort neu rendern, wenn grundsätzliche Änderungen am Layout gemacht werden
• man kann relativ einfach Funktionalität wie ein Formular zum Erstellen von Blogposts und Kommentaren einbauen
• man kann über eine Weboberfläche Inhalt pflegen, und Weboberflächen kann man von überall aus nutzen (außer in ländlichen Gegenden in Deutschland)

Statisches Rendering hat aber auch Vorteile:

• Es ist sicherer. Man muss sich keine Sorgen über Logins machen. Keine Sorgen über das sanitizen von Benutzereingaben. Keine Sorgen über Spam in den Kommentaren
• Man muss nicht mit Datenbanken und anderem Zeug herumhampeln, von dem man separat Backups erstellen muss
• Es ist schneller. Man rendert die Seiten ein Mal, danach werden immer wieder dieselben Seiten ausgeliefert. Keine Warten mehr darauf, dass der Server endlich fertig gerendert hat.
• Übertragungskompression ist einfacher. Man kann die Dateien vorher komprimieren. Das bedeutet, man kann sich mehr Zeit zum Komprimieren lassen und kriegt bessere Ergebnisse.
• Das CSS ist kleiner, weil man kein Styling für Formulare braucht. Da das Layout des Blogs recht simpel ist, haben die Formulare einen recht großen Anteil am Layout gehabt.

Da ich normalerweise sowieso nur von meinem Hauptrechner aus blogge (weil ich das PW immer vergesse und es auf anderen Rechnern nicht gespeichert ist) und die Kommentarfunktion seit gefühlt 2014 sowieso niemand mehr genutzt hat (außer Spambots), war die Antwort einfach.

Warum selbstgeschrieben?

Diese Frage ist etwas schwieriger. Eigentlich gibt es einige (dem Hörensagen nach, ich habe nicht alle ausprobiert) gute tools, um statische Seiten zu rendern. Beispiele sind:

• HUGO
• Cobalt
• Jekyll

Die haben soweit ich sehen konnte, alles, was man so braucht. Also warum habe ich sie nicht genommen?

Der Hauptgrund ist: Ich wollte nicht. Ich wollte die Software selber schreiben.

Weitere Gründe sind:

• Ich habe einen Haufen bestehender URLs, die ich erhalten möchte. Ich weiß nicht, ob das so einfach gewesen wäre.
• Ich habe ein paar Features, bei denen ich nicht wusste, ob ich sie mit bestehenden Tools behalten kann
• Ich möchte micht nicht von einer weiteren Software abhängig machen, die eventuell Probleme mit Updates bereitet (wobei ich zugegeben ein paar Abhängigkeiten in meinem selbstgeschriebenen Renderer habe. Aber ich verstehe den Renderer gut genug um diese Abhängigkeiten im Ernstfall zu ersetzen)

Würde ich jemandem empfehlen, selber einen Blogrenderer zu schreiben? Grundsätzlich nein (es sei denn, die Person in Frage hat Spaß daran). Würde ich jemandem empfehlen, meinen Blogrenderer zu benutzen? Nein. Mein Blogrenderer ist single-purpose. Die oben genannten Generatoren sind flexibel und darauf ausgelegt, die herausgegebenen Seiten für den eigenen Zweck anzupassen. Dieser Bloggenerator hier ist darauf ausgerichtet, genau dieses Blog hier zu rendern. Das macht die Entwicklung viel einfacher, weil man viel weniger Edge-Cases behandeln muss. Aber er ist nicht flexibel, denn Flexibilität hat ihren Preis.

Was gibt es noch zu erwähnen?

• die Blogposts werden jetzt in CommonMark, einer standardisierten Form von Markdown, geschrieben. Damit spare ich mir das Herumgehampel mit HTML in den Blogposts und die Posts sind auch im nicht gerenderten Zustand angenehm lesbar.
• das alte Rails-Repo ist jetzt archiviert, dahin kann nichts mehr gepushed werden
• das Repo für das neue Blog veröffentliche ich irgendwann demnächst
• die neue Software ist größtenteils in meiner Lieblingssprache rust geschrieben
• weil es jetzt wieder Spaß macht, an der Blogsoftware zu schreiben kommen wahrscheinlich in Zukunft auch noch ein paar andere Neuheiten in das Blog

Ich meine, da war auch noch mehr, was ich erwähnen wollte, das habe ich aber vergessen.

Soo, die Zitate sind wieder da! Auf der Startseite wird jetzt wie früher auch immer das neueste Zitat angezeigt. Außerdem sind die Zitatseiten zurück.

Die Zitatseiten sind pagebar und haben eine neue URL. Die alte URL ist nicht tot, sonder leitet auf die erste Seite der neuen Zitatseiten weiter.

Ob ich die Zitatseiten im Header verlinken will, muss ich noch überlegen. Außerdem gefällt mir das neue Layout noch nicht ganz. Das ist aber nicht so dringend.

Der worst case ist eingetreten: Donald Trump kommt mit seiner Covid-19-Erkrankung aus dem Krankenhaus zurück und hat nichts gelernt. Ersteres gönne ich ihm noch. Zweites zeigt sich in den Worten „Habt keine Angst vor Covid“. Mit anderen Worten: er macht direkt Politik daraus und verharmlost die Pandemie.

Mag ja sein, dass er es überstanden hat (das kann ich nicht beurteilen), aber als Präsident der USA hat er auch die vermutlich beste medizinische Überwachung und Versorgung, die verfügbar ist. Er hat eine experimentelle Behandlung mit Antikörpern bekommen, was auch nicht jedem zu Verfügung steht und i.d.R. nicht empfehlenswert ist. Trump hatte Glück.

Das Dumme an der Sache ist nur, dass er jetzt anscheinend die Schlussfolgerung zieht, die ganze Erkrankung sei nicht so schlimm. Trotz mittlerweile mehr als einer Million Toten (Dunkelziffer unbekannt). Trotz mehr als 200000 Toten in den USA. Trotz der Tatsache, dass gerade gefühlt sein ganzer Stab positiv auf SARS-CoV-2 getestet wurde.

Update

Ach ja, ganz vergessen: er kam dann auch noch mit dem Spruch um die Ecke:

We have developed, under the Trump Administration, some really great drugs & knowledge. I feel better than I did 20 years ago!

Klar. Seine Administration ist dafür verantwortlich. Donald Trump, der Wissenschaftsfeindlichkeit zur Kunst erhoben hat. Der klimawandelleugnende Trump. Der Trump, der bei seinen Entscheidungen nicht auf Fakten achtet, sondern auf was immer ihm gerade im Kopf herumschwirrt. Der Trump stellt sich jetzt als Ursache dafür da, dass jemand eine Therapie entwickelt hat (die, wie oben schon geschrieben, noch nicht ausreichend getestet wurde um ihre Wirksamkeit zu belegen).

Wenn er Zuckerkugeln genommen hätte und gesund geworden wäre, hätte er sich die Fortschritte der Homöopathie angerechnet. Diesem Menschen geht es nicht um Amerika, nicht um die Wissenschaft, nicht einmal um die konservativen bis radikal rechten Werte seiner Fans. Es geht im nur darum, so gut wie möglich dazustehen. Wenn etwas gut gelaufen ist, war das sein Verdienst. Wenn etwas schlecht gelaufen ist, waren es die Demokraten, die Medien, die Antifa oder wer sonst gerade verfügbar ist. Es geht ihm immer nur um sich selbst.

Premature optimization is the root of all evil.

— angeblich C.A.R. Hoare, ist aber umstritten

…aber manchmal macht vorzeitige Optimierung einfach Spaß. Ich habe auch so eine Art Kompressionsfetisch entwickelt (nein, nicht so eine Art Kompressionsfetisch). Zum Beispiel ist das favicon dieses Blogs eine auf 212 Byte herunterkomprimierte PNG-Datei. Der HTTP-Overhead diese Datei zu übertragen ist alleine größer als die Datei selbst. Doch zur Kompression später mehr.

Spätere Optimierung hingegen macht weniger Spaß, ist aber gelegentlich notwendig.

So auch bei der Blogsoftware, mit der ich dieses Blog hier generiere (seit Kurzem veröffentlicht auf github). Und ich gebe zu, ich habe auch tatsächlich eine vorzeitige Optimierung eingebaut, die ich später bereut und wieder entfernt habe: Ich habe das Parsen und das in-html-Umwandeln des Markdowns von Blogpost an eine Stelle verlagert, wo es eigentlich nicht hingehört, damit es nur einmal durchgeführt werden muss (anstatt von bis zu drei Mal: einmal für den Blogpost selber, einmal für die Archivseite und einmal für die Homepage).

Allgemein ist es in Rust relativ verführend, Optimierungen einzubauen. Man kann es aber auch sein lassen, und ist damit trotzdem meistens schnell genug. In manchen Fällen, wie zum Beispiel xml-rs vs. quick-xml habe ich in der Vergangenheit feststellen müssen, dass ich bei einer mehreren hundert MB großen Datei einen signifikanten Unterschied (ein paar Minuten vs. ein paar Sekunden) beim Parsen habe.

Ich habe an einigen Stellen aus Spaß optimiert, an anderen Stellen aber auch Sachen einfach kopiert. Im Endeffekt macht es wahrscheinlich keinen großen Unterschied: Ich lade mehrere hundert kleine Dateien und schreibe noch mehr kleine Dateien. Der größte Teil der Laufzeit dürfte also für IO draufgehen. Trotzdem läuft der Generator in ein paar Millisekunden durch:

$ time target/release/generator ../content ../dist

real    0m0,045s
user    0m0,028s
sys     0m0,017s

Und selbst wenn die Compileroptimierung abgeschaltet wird, läuft das Ding in einer Viertelsekunde durch:

$ time target/debug/generator ../content ../dist

real    0m0,244s
user    0m0,192s
sys     0m0,024s

Die Zahlen schwanken natürlich recht stark, je nachdem wie sich der Rechner gerade fühlt. Aber die Größenordnung bleibt gleich. Kurz gesagt, der HTML-Generator ist schnell genug. Und der ist nicht einmal parallelisiert.

Kompression

Ganz anders sieht es aus, wenn ich die Schritte danach betrachte: Da wird nämlich jede einzelne HTML-Datei (und auch ein paar andere Dateien) komprimiert, damit sie später bei der Übertragung per HTTP kleiner ist. Ich unterstütze hier zwei Kompressionsverfahren: gz und brotli.

Aber aufgrund des oben genannten Kompressionsfetisches kann ich natürlich nicht einfach gz nehmen und die Dateien komprimieren. Oh nein, ich muss Zopfli nehmen. Zopfli optimiert recht gut, braucht aber gefühlt ewig pro Datei. Ich könnte vermutlich sogar noch ein paar Bytes weniger herauskitzeln, aber das ist mir mein Kompressionsfetisch dann doch nicht wert. Das macht die gz-Komprimierung tatsächlich langsamer als die Brotli-Komprimierung, wobei letztere immer noch kleinere Ergebnisse liefert.

Die Sache mit Brotli hat nur einen Haken: Ich habe bisher noch keine einfache Möglichkeit gefunden, Brotli stabil als transfer-encoding für nginx einzusetzen. Es gibt dafür ein nginx-Modul von Google, aber das muss man manuell bauen, und zwar mit genau der richtigen nginx-Version und der richtigen nginx-Konfiguration. Ich müsste also vermutlich nach jedem nginx-Update manuell dieses Modul neu bauen, sonst segfaultet mir das noch um die Ohren. Alternativ gibt es ein offiziell unterstütztes Modul, aber nur für die Nutzer der kommerziellen nginx-Variante.

Ich erstelle also Haufenweise brotli-komprimierte Dateien ohne sie zu nutzen. Da haben wir sie wieder, die vorzeitige Optimierung, die am Ende nichts bringt.

Make to the rescue

Aber wie gesagt, die Kompression verschlingt eine Menge Zeit. Glücklicherweise benutze ich make, was anhand des Zeitstempels von Quelldateien und Zieldatei entscheiden kann, ob ein target (zum Beispiel eine Kompression) neu erstellt werden muss. Unglücklicherweise erstellt der HTML-Generator einfach immer alle Dateien neu, was dazu führt, dass make alles neu komprimieren will.

Oder sagen wir lieber „erstellte“. Hier kommen wir zur nachträglichen Optimierung. Ich habe dann den Generator so umgebaut, dass er sich auch die Quell-und-Zieldateien anschaut und danach entscheidet, welche neu gebaut werden müssen. Das macht den Generator zwar nur unwesentlich schneller (etwa Faktor 2, was in absoluten Werten nicht viel ist), verringert jedoch drastisch den Kompressionsaufwand, wenn nur wenig geändert wurde.

Auch hier gibt es einige Nachteile: Der Generator erkennt nicht, wenn er sich selber geändert hat und baut so nichts neu, auch wenn durch die Änderung alles anders aussehen würde. Da war ich zu faul, mir eine Lösung zu überlegen und muss jetzt semi-manuell die HTML-Dateien löschen. Ist meiner Meinung nach hier aber zu verkraften. Niemand außer mir benutzt den Generator, und ein Umbau um das Problem zu lösen würde noch einiges an Komplexität in den Generator bringen.

Ein weiteres Problem ist, dass make es nicht mag, wenn andere Programme während der Ausführung von make an den Quelldateien herumspielen. So wie ich make verstehe, wird ganz am Anfang entschieden, wwelche targets alle zu bauen sind. Das ist natürlich doof, wenn einige Quelldateien erst durch ein phony-Target (der Generator) erstellt werden. Ich habe ein paar Workarounds dafür drin, aber schön ist das nicht. Vielleicht ist make einfach nicht das richtige Werkzeug für diesen use case. Auf der anderen Seite ist es praktisch überall verfügbar, also bleibe ich erst einmal bei make.

Parallelisiert

Make kann nämlich auch parallelisieren. Da Make Abhängigkeiten zwischen targets auflöst, kann make auch sehr gut entscheiden, was parallel laufen kann. Und einzelne Dateien unabhängig von einander zu komprimieren ist ziemlich gut parallelisierbar. Schauen wir uns zunächst mal die unparallelisierte Version an:

$ time make

[…]

real    4m6,925s
user    4m4,581s
sys     0m2,326s

Ok, vier Minuten. Das ist viel. Das geht doch besser, oder? Probieren wir es mal mit maximal vier parallelen Prozessen (vorher natürlich einmal ein clean):

$ time make -j4

[…]

real    1m10,153s
user    4m38,362s
sys     0m2,114s

Ordentlich. Das ist fast eine vierfache Verbesserung. Probieren wir mal mehr.

$ time make -j8

[…]

real    0m56,804s
user    7m18,364s
sys     0m2,854s

Immer noch besser, aber nicht mehr ganz so viel besser. Mag daran liegen, dass ich nur vier physische Kerne habe. Oder dass das I/O der Festplatte nicht mitkommt. Vermutlich ersteres, denn das Einlesen der Dateien ist hier nur ein winziger Teil der Zeit die so ein Kompressionsprogramm zum Arbeiten braucht.

Wo kann man noch verbessern?

Im Großen und ganzen bin ich ziemlich zufrieden, wie der Krams läuft. Die Dateien kopiere mich mit rsync zum Server, wobei auch hier nur veränderte Dateien übertragen werden. Wenn man nicht viel geändert hat, geht das erstellen und Komprimieren des HTMLs auch ziemlich fix. Der Server liefert wann immer möglich komprimierte Dateien aus und beantwortet Anfragen wenn möglich mit einem 304 not modified.

Zwei Dinge möchte ich aber noch verbessern: Zum einen die oben erwähnte Brotli-Kompression (sobald ich einen Weg gefunden habe, sie mit nginx zu benutzen). Zum anderen sind da die assets.

Momentan ist die Ansage des Servers, dass alles fünf Minuten lang gecached werden darf. Für manche Dateien, zum Beispiel das css ist das aber viel zu wenig. Das kann man praktisch ewig cachen, wenn es sich nicht verändert. Allerdings will man auch, dass es tatsächlich neu geladen wird, wenn es sich verändert.

Und kluge Leute sind schon vor langem auf die Idee gekommen, wie man das löst: man hängt einfach einen hash des Dateiinhalts an den Dateinamen der asset-Datei (z.B. der css-Datei), verlinkt die Datei unter dem Namen mit Hash in der HTML-Datei und sagt dem Server, dass er den Clients sagen soll, dass sie diese Datei ewig cachen dürfen. Ändert sich der Dateiinhalt, dann ändert sich auch der Dateiname, und damit wird ab sofort eine neue Datei geladen, die alte im Cache wird ignoriert.

Die Sache hat nur zwei Haken: Zum einen müssen jedes Mal, wenn ich etwas am CSS ändere, alle HTML-Dateien neu generiert und komprimiert werden. Das ist aber zu verkraften, wenn man selten was am Layout ändert.

Zum anderen aber wird es mit meinem momentanen Setup eine unschöne Angelegenheit, diese Dateien mit Cache-Hashes zu generieren und gleichzeitig den Hash in den HTML-Generator zu bringen. Nicht unmöglich, aber unschön. Gegeben der Größe der CSS-Datei (<3kB unkomprimiert, <900 Byte komprimiert) könnte ich mir das auch sparen und erst umsetzen, wenn es ein Performance-Problem gibt. Das wäre der sensible Ansatz.

Aber ich kenne mich selbst zu gut. Ich werde nicht den vernünftigen Ansatz nehmen, sondern den, bei dem ich so viel wie möglich optimieren kann, ohne dass es wirklich notwendig ist. Das ist so eine Art Berufskrankheit.

Über vier Jahre (2008 bis Oktober 2011) hatte ich mein erstes Blog. Dann habe ich mir eine eigene Blogsoftware gebastelt und mir gedacht: „Bei Gelegenheit importiere ich mal die Einträge aus dem alten Blog in das neue Blog“.

Acht Jahre später habe ich die Blogsoftware ersetzt. In den ganzen acht Jahren habe ich den Import immer vor mir hergeschoben. Ein einziges Mal habe ich angefangen, dann aber die Lust verloren, weil die HTML-Struktur von blogger.de das Heraussuchen der Einträge so unschön macht.

Jetzt habe ich endlich die alten Blogeinträge importiert. Das heißt natürlich auch, dass mit meinen Archivseiten genau das passiert, was ich vermeiden wollte: Die Einträge auf den Archivseiten werden verschoben. Was vorher auf Seite 1 war ist danach auf Seite 36. Das wird aber in Zukunft nicht mehr passieren, weil ich keine neuen Einträge in der Vergangenheit hinzufügen werde.

Jeder alte Blogpost hat auch einen Link zum Original. Dort kann man auch die Kommentare dazu lesen, die ich aus mehreren Gründen nicht kopiert habe. Zum einen wäre das bei der gegebenen HTML-Struktur umständlich gewesen, zum anderen weiß ich nicht, wie es da mit dem Urheberrecht steht.

Technische Umsetzung

Die grundlegende technische Idee ist einfach: Ich schnappe mir die Daten vom alten Blog, transformiere sie in ein Format, das dem neuen Blog schmeckt und schiebe sie ins neue Blog.

Der Crawler

Praktisch gesehen fangen die Probleme natürlich schon ganz am Anfang an. Der Server des alten Blogs steht nicht unter meiner Kontrolle. Es gibt (soweit ich herausfinden konnte) keine Exportschnittstelle. Aber das ist ja eigentlich kein Problem. Ich schreibe seit Jahren immer mal wieder kleine Scripte, um irgendwelche Websites zu crawlen, da kann ich das hier ja auch machen.

So weit, so gut. Ich schreibe den crawler nicht in rust, sondern in Go, weil ich für meinen Job gerade sowieso ein bisschen Übung in Go gebrauchen könnte. Die alte Blogseite ist nicht utf-8 (oder überhaupt unicode)-codiert, sondern ISO-8859-1. Also erst einmal umcodieren. Dann parsen. Ist natürlich kein HTML5, sondern XHTML. Auch kein Problem, der XML-Parser von Go kommt damit klar.

Als nächstes muss man im HTML nach bestimmten Sachen suchen. Der „older stories“-Link ist recht einfach zu finden. Was weniger einfach zu finden sind, sind Titel uns insbesondere Text des Eintrags. Anstatt jeden Eintrag in einen eigenen Container zu stecken (in meinem neuen Blog ein schickes HTML5-<article>-Tag), wurde der Inhalt der Einträge einfach hintereinander gehängt. Die Überschriften sind formal nicht einmal Überschriften.

Das macht es natürlich kompliziert zu unterscheiden, welche Überschrift und welches Datum zu welchem Text gehört (umso mehr, da das <div> des eigentlichen Texts überhaupt keine Klasse hat). Glücklicherweise ist der Permalink zu einem Eintrag recht einfach zu finden. Also erst einmal alle Permalinks sammeln.

In der zweiten Phase geht der Crawler dann alle Permalinks durch. Jetzt sind Überschrift und Text ziemlich einfach zu finden, Datum und Zeit sind unglücklicherweise auf zwei Tags verteilt, die Kategorie ist überhaupt nicht vorhanden. Gerade als ich den Datumsparser fertig habe stelle ich auch noch fest, dass ich es einfacher hätte haben können, denn wie Datum und Zeit angezeigt werden sollen ist konfigurierbar.

Also habe ich jetzt: die Überschrift, Erstellungsdatum und den Inhalt. Fehlt noch die Kategorie. Die wird dummerweise nicht angezeigt. Außerdem ist der Inhalt nicht besonders schön. Keine <p>-Tags für Absätze, stattdessen harte Zeilenumbrüche wohin man blickt. Schöner wäre, wenn ich den Rohtext kriegen könnte, den ich mal dort eingetragen habe.

Glücklicherweise ist es ja mein Blog, also kann ich mich einloggen und die „bearbeiten“-Seite aufrufen. Dort findet mein Crawler jetzt die Kategorie und den Rohtext. Zumindest theoretisch.

Praktisch kommt mir da nämlich in die Quere, dass, sobald man eingelogged ist, zusätzliches HTML gerendert wird, das nicht XML-konform ist (ein < wird in einem Attribut verwendet). Die meisten Browser sehen über solche Fehler hinweg. Der Go-XML-Parser nicht, nicht mal, wenn ich ihn ganz lieb bitte.

Also erst einmal die komplette Seite abgespeichert. Sobald der Krams erst einmal heruntergeladen ist, kann ich offline damit herumbasteln.

Erstellen der Blogposts

Das Format meiner Blogpost-Dateien ist recht simpel: ein kurzer Header mit Name-Wert-Paaren und so Sachen wie Titel, Datum, Kategorie, Tags, usw., danach der Inhalt als Markdown.

Der meiste Header-Kram ist recht einfach zu transformieren. Datum habe ich. Tags gibt es keine. Titel war in einer kleinen Zahl der Fälle nicht vorhanden, da habe ich mir einen neuen Titel ausgedacht.

Bei den Kategorien musste ich tricksen: Ich habe im neuen Blog weniger Kategorien und wollte nicht alle Kategorien des alten Blogs übernehmen. Manche Kategorien, wie Ganz normaler Wahnsinn können einfach 1:1 gemapped werden.

Manche Kategorien, wie „Saftladen“, also alles, was mit ÖPNV und deutscher Bahn zu tun hat, kann ich guten Gewissens komplett unter Rant einsortieren. Da es im alten Blog keine Tags gab, kommt hier ein Tag „öpnv“ dran, um die Sache runder zu machen.

Manche Kategorien, von denen ich ausgehe, dass ich sie noch brauchen könnte, z.B. Bücher habe ich neu hinzugefügt.

Eine Sonderstellung nimmt die Kategorie TVTropes ein. Die hatte ich 2012 mit dem neuen Blog angelegt, aber nie verwendet. Einige Posts aus dem alten Blog gehören aber in diese Kategorie, also wird sie endlich genutzt!

Der größte Block ist der Inhalt. Der enthält zwei Sachen, die ich transformieren musste: HTML-Tags und Macros der blogger.de-Software, die Dinge wie Bilder und Dateien, die man dort hochgeladen hat, einbinden. Das war schon ein bisschen Arbeit. Die Dateien vom alten Blog habe ich in diesem Zug auch übernommen.

Trotz all den automatischen Konvertierungen musste immer noch ein Feinschliff gemacht werden, weil man einige Sachen einfach nicht automatisch entscheiden konnte. Also bin ich noch einmal durch etwa 540 Einträge durchgegangen. Hatte den Vorteil, dass ich mir noch einmal durchlesen konnte, was ich damals eigentlich geschrieben habe. Das ist ja alles acht bis zwölf Jahre her.

Einen Eintrag habe ich ausgelassen. Dieser ist nur ein Verweis auf das neue Blog (also dieses hier).

Was habe ich früher so geschrieben?

Was als erstes auffällt ist nicht was, sondern wie viel ich geschrieben habe. In den knapp fünf Jahren vor meiner eigenen Blogsoftware waren es etwa 540 Einträge. In den acht Jahren danach nur 217, wovon alleine 56 auf mein Kochprojekt 2014 fallen. Mehr noch, seit ich berufstätig bin hat sich meine Blogaktivität stark gesenkt (83 Einträge in knapp sechs Jahren). Oder ich vegetiere hier in Hamburg einfach nur so vor mich hin und habe nichts interessantes zu berichten.

Also, worüber habe ich denn nun geschrieben? Häufig über Kleinkrams, den man ohne Kontext nicht versteht. Es ist aber schön, mal wieder Sachen aus der Uni- und der Abi-Zeit zu lesen. Besonders ganz am Anfang kam viel zusammenhangloses Zeug zu meinen gentoo-Linux-Erfahrungen. Ich habe aber auch einige durchaus interessante Dinge geschrieben, sowie einige, bei denen ich heute anderer Ansicht bin.

Vielleicht mal ein paar Beispiele:

• hier habe ich mich über, wie es mir damals schien, typographische Allüren eines Freundes beklagt. Heute bin ich anderer Ansicht und muss zugeben, dass er Recht hatte.
• der erste Aprilscherz des Blogs ist hilarious in hindsight wenn man bedenkt, dass Microsofts azure-cloud Linux unterstützt
• In aktuellen Pandemiezeiten ist es ganz interessant zu wissen, dass Microsoft schon 2009 auf der Cebit eine Flasche Desinfektionsmittel in einem Gewinnspiel verschenkt hat. Rückblickend nicht einmal so abwegig, weil Bill Gates schon damals viel Geld in gemeinnützige Organisationen zur Weltgesundheit steckte.
• ich habe mich damals viel damit herumgeärgert, 64Bit-Java-Plugins für den Firefox unter Linux zu kriegen. Die Technik war damals schon am aussterben, wurde aber noch hier und da verwendet. Schlimmer war es mit adobe flash, was man damals besonders noch für Youtube brauchte.
• Übersetzungsmaschinen sind seit damals besser geworden. Das Beispiel, dass ich im Eintrag zu translation party gebracht habe, kommt jetzt unverändert wieder heraus.
• ich habe mir damals meinen ersten Raspberry Pi bestellt, nachdem ein Kommilitone mir seinen gezeigt hatte. Zu der Zeit nahm das gerade richtig Fahrt auf und ich hatte Glück, meinen halbwegs schnell zu bekommen (in etwa drei Wochen), während andere Kommilitonen kurz später Monate warten mussten.
• hier habe ich mich über die Nutzlosigkeit des großen ẞ ausgelassen. Die Energie hätte ich mir sparen können. Wobei es wirklich wichtigere Dinge gibt, die in den Unicode-Standard sollten. Emojis sind ja auch ganz nett, aber nicht alles ☺
• Export von Überwachungstechnologier an totalitäre Regimes ist immer noch aktuell

Was habe ich sonst noch so geschrieben? Rants über Netzpolitik, vieles davon leider auch heute noch ein Thema. Das gleiche gilt für freie Software und Gerätehoheit (auch wenn ich letzteren Begriff damals noch nicht kannte). Rants über den ÖPNV kommen in letzter Zeit nicht mehr so häufig, weil dieser zum einen in Hamburg besser funktioniert und ich ihn andererseits dank Fahrrad und kurzer Entfernungen nicht so häufig in Anspruch nehme.

Ansonsten habe ich das Blog oft als Ventil für Frust mit Hard- und Software benutzt.

Was mir auch aufgefallen ist: viele der Links in den alten Einträgen sind tot oder werden mittlerweile umgeleitet. Das ist schade. Ich selbst habe mir Mühe gegeben, alle wichtigen URLs meines Blogs zu erhalten (und habe das bei den Tags nicht geschafft). Viele andere Seiten sind aber verschwunden oder haben ihre Seite umstrukturiert, so dass man unter den alten URLs nichts mehr findet. Dazu kann ich mal den Artikel Cool URIs don't change von Tim Berners-Lee empfehlen.

Und da ich jetzt schon wieder knapp zwei Stunden an einem Blogpost gesessen habe, muss ich jetzt ins Bett.

Man kann in der aktuellen US-Wahl ja viel über die Demoskopen sagen. Das sie Trumps Wählerpotential schon wieder unterschätzt hätten, höre ich zum Beispiel häufig.

Was ich hingegen bisher nirgendwo explizit erwähnt gesehen habe ist, dass die Vorhersagen in einem Punkt recht gehabt haben: Wähler der Demokraten haben mehr Briefwahl gemacht als Wähler der Republikaner, und in den Staaten, bei denen das Ergebnis knapp ist (Wisconsin, Michigan, Nevada, Pennsylvania) sind unter den Briefwahlstimmen mehr Stimmen für die Demokraten als für die Republikaner.

Das wurde als blue shift vorhergesagt und ist in einigen Staaten deutlich zu sehen. Am Anfang der Auszählung hat Trump geführt, nach und nach hat Biden aber aufgeholt bzw. überholt. In Pennsylvania z.B. hatte Trump, als noch etwa nur 80% der Stimmen ausgezählt waren, einen Vorsprung von acht Prozentpunkten. Jetzt, bei geschätzten 89% der Auszählung, sind es nur noch drei Prozentpunkte. Wenn das so weiter geht, ist es also sogar möglich, dass Biden in Pennsylvania gewinnt.

Noch ist nichts entschieden, es sieht aber zunehmend danach aus, dass Biden gewinnt, wenn auch sehr knapp.

Was macht Trump also? Nein, nicht jetzt. Gestern schon. Er stellt es so dar, als ob es nur Betrug sein kann, dass plötzlich so viele Stimmen für die Demokraten einschlagen und droht damit, die Auszählung stoppen zu lassen.

In den Medienberichten, die ich dazu gesehen habe wird immer nur betont, dass Trump dazu nicht die Macht habe. Dass es empörend sei, dass er verlange, das regelkonform abgegebene Stimmen nicht gezählt werden. Das stimmt auch. Aber nirgendwo habe ich bisher gesehen, wie jemand gegen die zwei Kernthesen von Trump argumentiert hat:

1. „Es kann nur Betrug sein, wenn plötzlich so viele Stimmen für die Demokraten auftauchen“
2. „Es stimmen weiterhin Menschen ab, auch nach Schließung der Wahllokale“

Das ist absoluter Bullshit. Möglicherweise habe ich nichts darüber gelesen, weil es so großer Bullshit ist, dass sich niemand die Mühe gemacht hat, dagegen zu argumentieren, sondern nur gegen die daraus resultierenden Forderungen (Auszählungsstop, solange Trump noch vorne liegt).

Besonders der erste Punkte ist Bullshit. Es gibt sehr wohl eine Erklärung für die ganzen Demokratenstimmen, die später auftauchten. Der blue shift. Und diese Erklärung wurde nicht ad hoc erfunden, nein. Dieser Effekt wurde vorhergesagt. Insofern also weder eine Überraschung, noch ein Indiz für Betrug.

Habe ich gesagt „besonders der erste Punkt“? Denn der zweite Punkt ist ebenso Bullshit. Es kommen keine Stimmen nach dem 3. November dazu. In einigen Staaten werden anscheinend alle Stimmen gezählt, die bis zum 3. November bei der Post abgestempelt wurden (selbst wenn sie später eintreffen), aber das bedeute auch, dass sie nicht nach dem Wahltag abgegeben wurde. Trumps Forderungen, es dürfen keine neuen Stimmen abgegeben werden laufen also ins Leere, weil keine neuen Stimmen abgegeben werden. Es werden nur die (nach Gesetzt in den entrpechenden Staaten) rechtzeitig zum Wahltag abgegebenen Stimmen gezählt.

Und was eine geforderte Neuauszählung in Wisconsin angeht, wo Trump vermutlich ganz knapp verlieren wird? Diese Neuauszählung ist sein Recht, so wie ich es verstanden habe, weil der Abstand zu Biden so klein ist. Er soll dann nur die Schuld nicht auf andere schieben, dass es so lange dauert, bis ein Ergebnis feststeht.

Update (12:20)

Ok, politifact hat das Thema gut abgehandelt. Diesen Eintrag hatte ich als ich das oben geschrieben habe noch nicht gesehen.

Außerdem ist anzumerken, dass es durchaus Staaten gab, in denen Biden anfangs deutlich führte und sich der Vorsprung zumindest stark reduzierte. Red shift, könnte man sagen.

Sorry für den Titel, aber dieser Wortwitz schwirrt jetzt schon seit einem halben Jahr in meinem Kopf herum.

Die Auszählung der US-Wahl ist noch nicht komplett beendet, aber die Experten™ sind wohl der Ansicht, dass Biden in Pennsylvania gewinnen wird.

Ich muss sagen, ich bin unglaublich erleichtert darüber. Gut, Biden ist jetzt nicht alles, was ich mir für die USA gewünscht habe, aber ein „nicht ganz zufrieden mit dem Präsidenten“ ist um Größenordnungen besser als das „vollkommen verzweifelt über den Präsidenten“, dass wir in den letzten vier Jahren hatten.

Das grundlegende Problem in den USA ist natürlich nicht behoben. Ähnliche Probleme, die gefühlt in den letzten Jahren überall auf der Welt aufgetan haben und sich hierzulande in der AFD manifestiert haben. Verschwörungstheoretiker, Nationalisten, Klimawandelleugner, Rassisten sind überall laut.

Unter Biden hat die USA eine Chance. Und wenn die USA eine Chance hat, dann wirkt sich das auch auf andere Länder aus. Biden will sich im Klimaschutz engagieren. Biden will den WHO-Austritt der USA beenden. Biden gibt versöhnliche Worte und versucht, Amerika wieder zu einen.

Ich bin mir sicher, dass die USA auch weiterhin eine Menge Scheiße machen wird. Sie werden weiterhin weltweite Massenüberwachung praktizieren. Sie werden vielleicht auch weiterhin Angriffskriege führen. Sie werden weiterhin die eine oder andere Völker- oder Menschenrechtsverachtende Aktionen bringen. Da mache ich mir keine großen Hoffnungen.

Aber ich bin mir absolut sicher, dass unter Trump alles noch schlimmer geworden wäre. Die Demagogie, die Lügen, die Falschdarstellungen, die schamlose Selbstbeweihräucherung, die menschenverachtenden Kommentare, das Befeuern von Verschwörungstheorien und Rassismus… all das wird in Zukunft nicht mehr vom Präsidenten der fucking USA in die Öffentlichkeit gebracht.

Und das reicht mir vorerst.