Stranger Than Usual

Normalerweise sind die Rollenspielszenen hier immer taufrisch, aber ich habe gerade eine Notiz aus dem Dezember 2020 gefunden, ich ich posten wollte:

Im Jahr 2007 habe ich das erste Mal dauerhaft eine Linuxinstallation auf meinem Computer gehabt. Ich hatte schon vorher mit Linux experimentiert, bin aber immer gescheitert, üblicherweise an der Bootloaded Dual-Boot-Konfiguration mit Windows. Damals war das ei SuSE Linux. Nach einem Jahr hatte ich die Schnauze voll von SuSE und bin auf Gentoo umgestiegen. Ich habe in der ersten Woche mit Gentoo mehr gelernt als in einem Jahr mit SuSE, und habe einen Freund dermaßen zugetextet, dass er meinte, ich solle doch ein Blog anfangen. Also habe ich ein Blog angefangen.

Ich nutze Linux also seit gut 19 Jahren. Und obwohl ich auf meinen Laptops seitdem immer nur Linux hatte (meinen ersten Laptop habe ich erst nach meinem Abitur, vor Beginn meines Informatikstudiums bekommen), habe ich trotzdem immer noch eine Kiste gehabt, auf der im Dualboot Windows und Linux liefen.

Warum Windows? Ich komme mit Linux viel besser klar, und kam auch 2018 schon mit Linux viel besser klar. Für alles, was ich mit einem Computer machen wollte, gab es unter Linux ein Programm, mit dem ich genausogut oder besser klar kam. Browser? Der gleiche Browser (obwohl ich ein paar Probleme mit Flash und Java-Applets hatte, aber die gehören ja mittlerweile der Vergangenheit an). Abspielen von Audiodateien? Kein Problem. DVDs anschauen? libdvdcss. Programmieren? Fast alles davon läuft besser unter Linux. Es lief also alles. Außer Computerspielen.

Ich spiele immer wieder gerne. Und Spiele sind nicht wie Browser, oder Audioplayer, oder Videoplayer. Wenn dir ein Spiel gefällt, gibt es üblicherweise keine Open-Source-Alternative. Abgesehen davon war der Grafikkartensupport unter Linux immer scheußlich. Nun, letzteres hat sich geändert, nicht zuletzt, weil zunächst Cryptocurrency-Bros und „AI“-Rechenzentrum plötzlich genau diese Art von Rechenleistung brauchten. Die Kompatibilität der Spiele blieb ein Problem. Gut, es gab Wine, aber das lief nur so mäßig gut.

Darum also Windows. Und warum möchte ich jetzt so dringen davon weg? Nun, mein Spielerechner von 2019 läuft noch mit Windows 10. Und für ein Update zu Windows 11 fehlt ihm ein Trusted Platform Module-Chip der Version 2. Ansonsten würde die Hardware das ohne Probleme schaffen. Außerdem gibt es einige andere Unannehmlichkeiten mit Windows 11: Man braucht einen Microsoft-Account, um sich auf dem Rechner lokal einzuloggen, Microsoft stopft es voll mit „AI“-Tools, die ich nicht will (Stichwort MS Recall)… die Liste lässt sich fortsetzen.

Jetzt möchte ich meinen Spielerechner aber eigentlich behalten. Die Hardware ist noch völlig ausreichend für alle Spiele, die ich spiele. Neue Hardware ist teuer, insbesondere weil ein paar gehypete Konzerne allen RAM auf dem Markt gekauft haben (oder zumindest versprochen haben, sie würden das tun). Steam hat die „Steam Machine“ angekündigt, ein Standrechner auf Linuxbasis, mit dem man alle möglichen Steam-Spiele spielen kann. Aber das wird ja auch teuer…

Nur: Wenn Steam es schafft, Windows-Spiele auf der eigenen Linux-basierten Plattform zum laufen zu bringen, dann ja sicher auch auch meinem eigenen Linux-System. Ich bin ja kein großer Steam-Fan, aber dass Steam seit 2012 Linux unterstützt kann ich ihnen wirklich nur hoch anrechnen. Nicht nur haben sie einen Linux-Client, nein, sie haben auch viele eigene Spiele (z.B. Portal) nach Linu portiert und Spieleentwickler dazu ermutigt, das auch zu tun. Und sie haben Wine genommen und es zu Proton weiterentwickelt, so dass es eine Kompatibilitätsschicht zwischen Windows-Spielen und Linux-Betriebssystemen gibt.

Also habe ich mich am Montag daran gesetzt. Ich hatte das alte Linux von 2019 sträflich vernachlässigt und nicht geupdated, also habe ich es mir einfach gemacht und die Linux-Partition mit einem neuen Ubuntu 2026.04 überbügelt. Und Steam installiert. Erste Tests liefen erfolgreich. Aber ein etwas aufwändigeres Spiel (Sea of Thieves) konnte ich erst gestern ausprobieren, weil das 130 GiB zum Download sind und ich den Download tagsüber nicht laufen lassen kann, weil ich von zu Hause arbeite (deutsches Internet halt).

Ich musste zunächst ein bisshen herumfummeln (die Proton-Version auf die letzte stabile Version fixieren anstelle die Unstable-Version zu nehmen) aber danach lief Sea of Thieves ohne Probleme. Und Proton funktioniert ja nicht nur mit über Steam installierten Spielen. Ich kann also meine alten Spiele, oder Spiele, die ich über andere Anbieter bezogen habe, auch spielen. Vielleicht probiere ich auch den Heroic Games Launcher aus, ein Open Source-Projekt, dass das noch etwas einfacher machen soll (ist bastle zwar gerne, aber bei manchen Sachen möchte ich, dass sie einfach funktionieren).

Also Das ist es. Nach 19 Jahren Linux kann ich endlich Windows verlassen. Good riddance!

Die Demoszene betreibt eine Kunstform, mit möglichst geringen Resourcen möglichst beeindruckende Kunstwerke zu schaffen. Animiert, mit Ton, was auch immer. Es gibt viele verschiedene Kategorien von Demos. Aber eine Sache ist gleich: Selbstauferlegte Beschränkungen.

Und das ist teilweise wirklich beeindruckend. Neulich habe ich diese Matrix-artige Demo gefunden. Da flackern für eine ganze Zeit Buchstaben auf dem Bildschirm auf (und wenn die Bildschirmfarbe grün ist, dann auch in grün), so ähnlich die die fallenden Buchstaben im Film „Matrix“. Dazu ein gruseliger, metallisch klingender, aber auch rhythmischer Soundtrack.

Das Besondere: Es braucht nur 16 Byte (Sechzehn Byte! Nicht Kilobyte. Byte.) an Programmcode. Das Programm läuft unter MS-Dos und macht sich Eigenschaften von Speicherlayout, Grafikspeicher und Audiogeräten zu nutze. Der Autor hat in einem Blogpost beschrieben, wie das Ganze funktioniert.

Sechzehn. Byte.

Eine Zipbombe (oder Archivbombe) ist eine komprimierte Datei, die zu einer extrem großen Datei entpackt wird. Normalerweise erstellt man Zipbomben direkt durch genaue Kenntnis des Kompressionsverfahrens ohne tatsächlich Daten zu komprimieren. So kann man zum Beispiel eine 42 kiB große Datei auf 4,5 Petabyte aufblähen.

Die billigere Variante ist, einfach sehr gut zu komprimierende Daten zu nehmen und sie zu komprimieren. Deutlich weniger elegant und 4,5 Petabyte wird man damit nicht hinkriegen. Dennoch ganz lustig. Ein Nutzen für eine solche Datei ist zum Beispiel, Scraper, die sich nicht an Regeln halten (z.B. and die robots.txt) halten, abzustrafen.

Meine eigene billige Zipbombe

Cool, so etwas will ich auch haben. Ich habe aber nicht genug Kenntnis über Kompressionsverfahren um so etwas zu basteln, möchte keine vorgefertigte Zipbombe nehmen (deren Hash könnte ja auf einer ignore-list stehen) und hätte gerne eine Zipbombe, in der gültiges HTML steckt. Womit auch erklärt wäre, warum ich neulich eine große HTML-Datei möglichst schnell nach stdout schreiben wollte (dazu gibt es übrigens unten noch ein Update).

Ich habe drei verschiedene Kompressionsverfahren ausprobiert, die alle im HTTP-content-encoding header erlaubt sind: Brotli, gz und Zstandard. Ich habe jeweils die höchste Kompressionsrate gewählt (für gz allerdings nicht Zopfli, das wäre mir dann doch zu langsam gewesen, also nur herkömmliches gzip). Ich habe dann wie beschrieben eine etwa 42 GiB große Datei erzeugt und diese on-the-fly zur Kompression gegeben.

Die Messungen sind nur mit time gemacht, könnten also Ausreißer enthalten. genbig ist hier das Rust-Programm, das die HTML-Daten erzeugt. Das sind die Ergebnisse:

gzip

$ time  genbig | gzip --best --stdout > big.html.gz
real    1m15,029s
user    1m12,729s
sys 0m14,630s

Dauert eine Weile, und die Ergebnisdatei ist etwa 126 MiB groß. Eigentlich würde ich gz gerne mit reinnehmen, weil es am weitesten verbreitet ist (viele Bots unterstützen meiner Erfahrung nach überhaupt keine Transportkompression, ganz zu Schweigen von Brotli), aber 126 Megabyte sind mir zu groß, da werden auf meiner Seite zu viele Resourcen genutzt.

Brotli

$ genbig | brotli --force --best -o big.html.br
real    32m47,275s
user    32m36,105s
sys 0m16,348s

Das hat eine gute halbe Stunde gebraucht, also eine Größenordnung mehr als gzip. Autsch! Auf der positiven Seite: Die Datei ist angenehme 35 kiB groß. Damit kann ich arbeiten.

Zstandard

Und der Neueste im Bunde. Um hier die Performance vergleichen zu können, habe ich es einmal mit einem Kompressions-thread und einmal mit vier Kompressions-Threads laufen lassen. Es gab dabei jeweils immer noch einen separaten I/O-Thread. Zuerst die Version mit einem Thread:

$ time genbig | zstd -19 -T1 --no-content-size --size-hint=43009MiB -o big_single.html.zst
real    0m53,649s
user    1m4,932s
sys 0m19,570s

Dann die Version mit vier:

$ time genbig | zstd -19 -T4 --no-content-size --size-hint=43009MiB -o big.html.zst
real    0m20,540s
user    1m27,782s
sys 0m19,051s

Von der Zeit her also beides deutlich besser als gzip, ganz zu schweigen von Brotli. Das Ergebnis ist für beide Varianten gleich und etwa 3,7 MiB groß. Das kommt schon in eine brauchbare Richtung, ist aber Größenordnungen hinter der Brotli-Variante.

Fazit

Es war ganz lustig, das mal ausprobiert zu haben. Bisher habe ich diese Dateien noch nirgendwo im Einsatz, weil ich noch nicht genau weiß, wie ich sie einsetzen will. Ich möchte keine Suchmaschinencrawler abschrecken, und erst recht nicht, dass ein regulärer User aus Versehen auf diese Dateien stößt. Eher will ich LLM-Scraper bestrafen, die sich nicht an die robots.txt halten (die sie momentan aber noch nicht aus diesem Blog aussperrt) oder die ganzen Scanner, die bei mir nach Lücken suchen. Letztere können aber auch gutmütig sein, aber davon würde ich nicht unbedingt ausgehen.

Viele dieser Bots unterstützen wie gesagt sowieso keine Transportkompression, und die meisten, die es tun, kein Brotli. Und speziell die gzip-Datei ist mir zu groß für den Spaß. Trotzdem: War mal ganz lustig, das auszuprobieren.

Bonus: I/O-Optimierung

Zstandard ist wirklich schnell, besonders mit mehreren Threads. Tatsächlich war es so schnell, dass ich dafür ein Rust-Programm optimieren musste, so dass es schneller nach stdout schreibt. Dummerweise war das Rust-Programm danach zwar deutlich schneller als die Python-Variante, aber immer noch zu langsam. Mit vier Threads:

real    0m51,731s
user    2m8,343s
sys 0m22,070s

Wenn man sich den Prozess während der Laufzeit anschaut, stellt man fest, dass genbig 100 % eines Kerns auslastet, und zstd kommt gerade mal auf 190 % (von den mit 4 + 1 Threads möglichen 500 %). Das verfälscht natürlich die Messung. Außerdem: Verdammt soll ich sein wenn ich kein Programm schreiben kann, das nichts tut außer immer wieder das gleiche nach stdout zu schreiben und dabei schneller ist als ein Programm, dass dieselben Daten von stdin liest und komprimiert. Das wäre peinlich.

Aber ich kann ja sicher etwas verbessern. Zum Beispiel werden sehr viele kleine Schreiboperationen durchgeführt. Die gehen zwar in einen Buffer, trotzdem muss nach jeder Operation auf Fehler geprüft werden. Wenn man das eine Milliarde mal macht, kommt da richtig Rechenzeit zusammen. Also habe ich mir gedacht, ich schreibe einfach mehrere Einheiten von dem sich wiederholenden Teil in einem write-Aufruf:

fn gen_body_part() -> String {
    // 8 kiB is the default buffer size of BufWriter
    repeat(REPEATED).take((1024 * 8 ) / REPEATED.len() + 1).collect()
}

fn main() -> Result<()> {
    let body_part = gen_body_part();
    let body_bytes = body_part.as_bytes();

    let mut out = BufWriter::new(stdout().lock());

    writeln!(out, "{}", PREFIX)?;

    let repeats = APPROX_SIZE / body_bytes.len();
    for _ in 0..repeats {
        out.write_all(body_bytes)?;
    }

    writeln!(out, "{}", SUFFIX)
}

Das Ergebnis ist besser, aber nicht wesentlich besser:

real    0m48,688s
user    2m4,117s
sys 0m20,982s

genbig ist immer noch bei 100 % Auslastung, zstd bei etwa 200 %. Aber ich habe ja auch einen Fehler gemacht: Ich habe das, was ich auf einmal schreibe, ein sehr kleines bisschen größer gemacht als den Buffer. Wenn ich also die Funktion oben ändere in

fn gen_body_part() -> String {
    // 8 kiB is the default buffer size of BufWriter
    repeat_n(REPEATED, (1024 * 8) / REPEATED.len()).collect()
}

Dann hat genbig zwischendurch endlich Zeit Luft zu holen, zstd rechnet auf allen Threads am Limit und die Laufzeit verringert sich auf… Trommelwirbel

real    0m20,540s
user    1m27,782s
sys 0m19,051s

Etwa 20 Sekunden. Eine deutliche Verbesserung.

Ich hätte natürlich auf die Buffergröße anpassen können. Vermutlich gibt es noch einen Haufen Optimierungsmöglichkeiten hier. Und das hier ist ein sehr kurzes Programm. Ich frage mich, wie viel Software ich geschrieben habe, die langsam ist, weil sie an irgendeinem dummen Flaschenhals feststeckt. Ich frage mich auch, wie viel Software da draußen viel langsamer ist, als sie es sein müsste, weil irgendjemand einen dummen Flaschenhals übersehen hat. Naja, jedenfalls habe ich wieder etwas gelernt.

Frohen Towel Day an euch alle! Wisst ihr alle, wo euer Handtuch ist?

Heute Abend habe ich mich online mit ein paar Freunden zusammengesetzt, um zusammen auf Alternativen zu großen Techkonzernen umzusteigen. So à la Digital Independence Day, aber halt nicht am ersten Sonntag des Monats wo ich diesen Monat weder Zeit noch Ideen hatte, was ich tun sollte.

Heute haben wir aber ein paar Sachen geschafft:

• Freundin A hat auf ihrem Smartphone eine googlefreie Android-Variante installiert und zum ersten Mal auch den Signal Messenger
• einem linuxinteressierten Freund B haben wir Informationen zu einem möglichen Umstieg/Teilumstieg auf Linux gegeben. Das war eine gute Arbeitsteilung: Ich, erfahrener Linuxnutzer, was möglich ist und wie man bestimmte Sachen macht. A konnte ihm Erfahrungswerte auch nichttechnischer Sicht geben (sie ist mit Linux Mint sehr gut klar gekommen). Freundin C konnte Hilfe bei der Installation anbieten (was für mich schwierig wäre, weil alle anderen drei in Hamburg wohnen und ich nicht).
• C hat mit dem Umstieg auf Posteo angefangen. Sie hatte schon einen Account, aber bisher noch keine Zeit gehabt, umzuziehen.
• Ich habe das alte Linux 19.10 auf meinem Spielerechner (auf dem außerdem noch Windows 10 läuft) mit Linux 26.04 überbügelt und erste Erfahrungen gemacht, wie gut Valves Wine-Fork Proton funktioniert. Erste Erfahrungen waren positiv. Als nächstes probiere ich anspruchsvollere Spiele. Dann kann ich auch B erzählen, was er dort erwarten kann.

Alles in Allem: Ein erfolgreicher Abend in angenehmer Atmosphäre.

PS: Wir haben das Ganze ironischerweise über Discord organisiert und durchgeführt. Das zu ändern steht auch noch auf der Agenda.

Rollenspielszene: Die Gruppe hat beschlossen, am nächsten Morgen früh aufzubrechen. Fredegar Stolzfuß, Barde, ist als erster wach. Um den anderen Gruppenmitgliedern ein schönes Aufwachen zu ermöglichen, weckt er sie mit einem fröhlichen Morgenlied.

Trotz seiner passablen Menschenkenntnis rechnete er nicht damit, dass das Thivuc überhaupt nicht gefallen könnte. Ein gezielter Wurf mit einem Stiefel, und Fredegar bricht das Lied ab. Banausen!

Ich habe heute mal ein bisschen herumgespielt, für dass ich eine große HTML-Datei brauchte, die möglichst einheitlich aussehen sollte. Also wirklich groß. Im Gigabytebereich. Diese Datei sollte dann auch nicht in eine Datei geschrieben, sondern direkt an ei verarbeitende Programm weitergegeben werden. Wozu? Dazu vielleicht später mal mehr.

Also habe ich mir ein sehr einfaches Python-Script geschrieben, das zuerst den Beginn des HTML-Dokuments nach stdout schreibt, zuletzt das Ende und dazwischen in einer Schleife einfach immer wieder dieselbe Zeile:

for i in range(approx_size // len(repeated_element)):
    print(repeated_element)

approx_size ist hier die ungefähre Zielgröße der Datei (eigentlich 42 GiB).

Mir ist dann aufgefallen, das je nachdem an welches Programm die Daten weitergereicht werden, das Zielprogramm die Daten schneller verarbeitet als Python sie schreiben kann. Also habe ich das gemacht, was jeder Rust-Enthusiast machen würde: Das ganze noch einmal in Rust geschrieben. Die Ausgabedaten zwischen den beiden Versionen sollten identisch sein. Das Rust-Programm ist auch sehr kurz (ein paar Konstanten mit dem HTML-Inhalt und der Anzahl der Wiederholungen habe ich vorher definiert).

fn main() -> Result<()> {
    let mut out = stdout().lock();

    writeln!(out, "{}", PREFIX)?;

    for _ in 0..REPEATS {
        writeln!(out, "{}", REPEATED)?;
    }

    writeln!(out, "{}", SUFFIX)
}

Also habe ich es ausgeführt und… es lief deutlich langsamer als die Python-Version. Ich habe das mal mit ≈ 42 MiB großen Dateien getestet, weil das deutlich schneller ging:

$ hyperfine "./genbig.py > /dev/null"
Benchmark 1: ./genbig.py > /dev/null
  Time (mean ± σ):     337.7 ms ±  15.5 ms    [User: 333.5 ms, System: 4.3 ms]
  Range (min … max):   324.1 ms … 373.2 ms    10 runs

$ hyperfine "target/release/genbig > /dev/null"
Benchmark 1: target/release/genbig > /dev/null
  Time (mean ± σ):     780.3 ms ±   9.1 ms    [User: 457.9 ms, System: 321.9 ms]
  Range (min … max):   773.5 ms … 805.2 ms    10 runs

Wtf? Das ist weniger als halb so schnell! Woran liegt das? Es ist der release-build, also liegt es sicher nicht an mangelnder Compileroptimierung. Ich habe auch den stdout-lock nur einmal ganz am Anfang geholt, damit das Programm keine Hindernisse zum Schreiben hat.

Ich bin ziemlich schnell auf den Gedanken gekommen, dass es am flushen liegen könnte. print() in python verhält sich nämlich unterschiedlich, je nachdem ob man auf eine Konsole schreibt oder irgendwoanders hin. Bei einer Konsole wird nach jedem print() ein flush gemacht (oder zumindest nach jedem Zeilenumbruch, ich habe das nicht genau nachgeschlagen). Mir ist das wieder eingefallen, weil in umgekehrt mal Probleme damit hatte, dass Python nicht geflushed hat, wenn ich es wollte.

In rust wiederum ist es bei stdout fix. In der Referenz zu stdout steht:

By default, the handle is line-buffered when connected to a terminal, meaning it flushes automatically when a newline (\n) is encountered. For immediate output, you can manually call the flush method.

Aha. Während Python also alles schön in einen Buffer schreibt und dann flushed, wird bei Rust in jeder einzelnen Zeile geflushed. Zum Vergleich: Wenn stdout die Konsole ist, dann sieht es schon ganz anders aus. Dann sind es bei Rust etwa 3 Sekunden und bei Python etwa 4,5 Sekunden (die Konsole ist sehr lahm).

Das Problem ist einfach gelöst: es gibt std::io::BufWriter. Damit wird irgendein Writer gebuffert und nur noch geflushed, wenn der Buffer voll ist oder man manuell flush() aufruft. Ich musste stdout also nur wrappen:

let mut out = BufWriter::new(stdout().lock());

und am Ende noch einmal flush() aufrufen (das passiert auch automatisch, aber dann werden möglicherweise auftretende Fehler ignoriert), und schon geht es deutlich schneller:

$ hyperfine "target/release/genbig > /dev/null"
Benchmark 1: target/release/genbig > /dev/null
  Time (mean ± σ):      26.5 ms ±   1.2 ms    [User: 25.8 ms, System: 1.1 ms]
  Range (min … max):    25.3 ms …  30.7 ms    93 runs

Cool. Also von weniger als halb so schnell zu mehr als zehn Mal so schnell. Es gibt noch ein paar andere Stellen, an denen ich Optimierungsmöglichkeiten sehe, aber das ist mir erst einmal schnell genug, schneller kann es die andere Seite eh nicht verarbeiten.

Fazit

Was lernen wir daraus? Einfach nur Rust zu verwenden löst keine Performanceprobleme, wenn man Flaschenhälse an völlig anderen Stellen hat. Gerade bei I/O sollte man ein bisschen hinter die Abstraktion schauen und dementsprechend optimieren. Zumindest, wenn man Optimierung braucht.

Genereller betrachtet trifft das auch auf andere Performanceprobleme zu. Zum Beispiel wenn man einen Algorithmus, der eigentlich in linearer Zeit laufen könnte, aus versehen quadratisch macht. Da hilft dann auch keine schnellere Programmiersprache.

Rollenspielszene. Wir haben erfolgreich Amulette erbeutet, die uns vor der wilden Jagd verbergen. Zwei Wochen später, nach langen Märschen durch die Marschen und Goblingebiete sind wir endlich wieder in der Zivilisation angekommen, in Flussauge, der Hauptstadt des Königreichs Havaria. Nach vielen Monaten das erste Mal in der Zivilisation ohne von der wilden Jagd verfolgt zu werden oder von einem durchgeknallten Magier die Stadt gegen sich aufzubringen. Das bedeuter Feiern!

Mavas hat jedoch andere Prioritäten. Erst muss er der elfischen Botschaft hier einen Besuch abstatten. Er weiß, dass Therith feiern möchte und will ihr anbieten, ohne sie zur Botschaft zu gehen er dreht sich um und…

Therith steht schon mit irgendetwas knusprig Gebratenem in der Hand neben ihm, das sie sich gerade gekauft hat.

Wer dieses Blog schon länger mitverfolgt weiß, dass ich einen gewissen… Fetisch für Datenkompression habe. Meine Bilddateien optimiere ich, soweit das verlustfrei geht. Die über HTTP ausgelieferten Inhalte dieses Blogs werden schon seit Jahren als Zopfli-optimiertes gz ausgeliefert, seit zwei Jahren auch Brotli-komprimiert (letzteres hat nur mangels Unterstützung der nginx-Version in Debian so lange gedauert).

Deswegen war ich gestern ein bisschen überrascht, dass es schon seit zwei Jahren einen weiteren Kandidaten auf dem Markt für HTTP-Content-Encoding gibt: Zstandard. Gibt es schon seit dem vergangenen Jahrzehnt und seit 2024 auch bei Chromium-basierten Browsern und Firefox als Content-Encoding. Wie konnte mir das entgehen? Und was kann diese „neue“ Kompression?

Glücklicherweise habe ich unter anderem diesen Blogpost über den Vergleich von ZStandard mit anderen Verfahren gefunden. Der Autor hat einen Kompressions-Tester für Websites geschrieben und analysiert, wie ZStandard im Verhätlnis zu Klartext, gzip und Brotli abschneidet.

Long story short: ZStandard ist sehr gut dabei, wenn es um Geschwindigkeit geht, bleibt aber bei höheren Kompressionsraten weit hinter Brotli zurück. Mit anderen Worten: Wenn man, so wie ich für dieses Blog, die Dateien nicht on-the-fly sondern im Voraus kompromiert (und sich dementsprechend ein bisschen mehr Zeit leisten kann), dann ist Brotli nach wie vor die beste Wahl. ZStandard glänzt hingegen dort, wo es auf Kompressionsgeschwindigkeit ankommt, z.B. bei dynamischen Inhalten. Für dieses Blog nicht relevant, aber ich behalte das mal im Hinterkopf.

Dieses Blog ist ja ein reines Hobbyprojekt. Der Kreis der Leser_innen dieses Blogs vermutlich sehr klein. Ich habe nie versucht, Geld damit zu verdienen. Trotzdem streichelt es meine Eitelkeit ein wenig, wenn ich mitbekomme, dass jemand mein Blog liest. Das war einer der Hauptgründe, warum ich irgendwann (vermutlich Ende 2020 / Anfang 2021 angefangen habe, Google Search Console zu verwenden um zu schauen, welche Seiten meines Blogs indziert sind (d.h. welche man theoretisch über Google finden kann) und welche meiner Blogposts tatsächlich von anderen über Google gefunden werden.

Besonders ersteres war immer interessant, denn mein Blog hat keine eigene Suchfunktion. Nur leider hat Google nie alle meine Seiten indiziert. Und Google ist sehr intransparent darüber, warum etwas nicht indiziert wird. Das machen sie, weil sie nicht wollen, dass SEO-Leute (Search Engine Optimization) Lücken im System nutzen um ihre Websites besser heraus zu bringen. Google will (oder wollte, ob das immer noch so ist, ist eine Frage, die ich hier nicht diskutieren will) Seiten anzeigen, die den Suchenden nützen, nicht den Gesuchten.

Wenn ich versucht habe, von Drittparteien Informationen zu bekommen, bin ich meist auf Seiten gelandet, die einen sehr starken Fokus aufs Geschäftliche haben und ein Blog meist nur als Produkt betrachten, das es zu vermarkten gilt. Das will ich aber nicht. Ich will nicht den Markt entscheiden lassen, über welche Dinge ich schreiben muss. Ich schreibe, was ich will, und das ist ein bunter Themenmix. Die andere Hauptkategorie, wie Google wohl Seiten bewertet ist, die Links auf eine Seite zu zählen. Die Idee: Je mehr Links, desto relevanter ist die Seite. Auch hier habe ich nicht viel vorzuweisen.

Also dümpelte meine Seitenindizierung so vor sich hin, und es war immer ein bisschen wie ein süchtig machendes Glücksspiel: Das nächste Mal, wenn ich mich einlogge, ist die Anzahl der Seiten vielleicht höher! Wenn ja: Endorphine. Wenn nein: Neues Spiel, neues Glück, ich schaue nächste Woche wieder vorbei. Ob das so gut für meine mentale Gesundheit ist? Vermutlich nicht.

Vor etwa einem Jahr ist dann die Indizierung stark zusammengebrochen, hat sich aber nach und nach erholt und schwankte stark. Vor etwa einem Monat ist sie aber extrem eingebrochen und von über 400 indizierten Seiten über wenige Wochen auf 0 (Null. Keine einzige) Seite runtergegangen. Warum? Keine Ahnung. Herausfinden kann ich es nicht. Ich weiß nur, dass selbst die (auf Google) erfolgreichsten Posts (nämlich der über aircrack-ng auf einem Raspberry Pi 5, der über Stempel aus Photopolymer und der über den Datenelch auf dem 36C3 auch alle deindiziert waren.

Was tun?

Zunächst einmal hat mich das ein bisschen geärgert. Dann habe ich es aber als Chance begriffen: Warum soll ich mich überhaupt darum kümmern, was Google mit meiner Seite macht? Ich habe viele Argumente dagegen

• Ich nutze Google als Suchmaschine selbst nur noch in Notfällen, fast imemr nutze ich DuckDuckGo.
• Google (oder eher: Alphabet, der Mutterkonzern) hat es nie groß mit dem Datenschutz gehabt. Scheiß auf Google!
• Nachzusehen, wie die Indizierungsstatistiken sind, glich bei mir eher dem zwanghaften Verhalten eines Spielsüchtigen. Nein danke.
• Um Google gegenüber sicherzustellen, dass die Domain tatsächlich mir gehört, musste ich in einen TXT-Eintrag (google-site-verification=[…]) in die DNS-Daten eintragen. Jeder konnte also sehen, dass ich Googles Bitch war.

Also habe ich jetzt die DNS-Einträge gelöscht und gehe auf harten Entzug. Auf DuckDuckGo ist mein Blog übrigens noch gut indiziert und neue Posts werden auch schnell hinzugefügt. Außerdem habe ich mich auf ein paar Bloglisten eintragen lassen, zum Beispiel auf Read Great Blogs. Dort werden dann über mein Atom-Feed auch aktuelle Blogposts gelistet.

Ich würde mich natürlich trotzdem immer freuen, wenn jemand mein Blog verlinkt, auch wenn ich davon wahrscheinlich so ohne Weiteres nichts mitkriegen würde. Umgekehrt habe ich dieses Jahr ja selber das Bloglinkprojekt laufen, in dessen Rahmen ich jede Woche auf einen Post eines (hoffentlich jedes Mal anderen Blogs) verlinke. Es gibt eine Menge WWW außerhalb der großen Plattformen. Es ist Zeit, das Netz zurückzuerobern!