Warum ich mein Blog neu starte

Es gibt Projekte, die verschwinden nie ganz. Sie liegen nur irgendwann unter alten Backups, Datenbank-Dumps, Themes, kaputten Plugins und ein paar sehr fragwürdigen Entscheidungen aus einer anderen Zeit begraben.

Mein alter Blog war genau so ein Projekt.

Damals lief das Ganze unter blog.blix0r.de mit dem schönen, leicht nerdigen Slogan:

my private it universe

Und ja, deshalb heißen meine Server bis heute universe.

Das war nie ein Hochglanz-Blog. Es war eher ein privates IT-Notizbuch: Debian, Apache, Oracle, kleine Fixes, kaputte Setups, Tools, Apple-Kram, WebOps, manchmal auch völlig anderes Zeug. Nicht immer perfekt geschrieben, nicht immer sauber strukturiert, aber meistens echt.

Genau daran möchte ich wieder anknüpfen.

Nicht als nostalgisches Museum. Sondern als moderner Neustart mit derselben Grundidee:

Dinge dokumentieren, die ich wirklich ausprobiert, repariert, gebaut oder verstanden habe.

Warum überhaupt wieder bloggen?

Ganz ehrlich: Ich habe lange überlegt, ob sich ein eigener Blog heute überhaupt noch lohnt.

Es gibt YouTube, Reddit, Mastodon, LinkedIn, ChatGPT, Dokumentationen, Wikis, GitHub-Repos und mehr technische Artikel, als man in einem Leben lesen kann.

Das Problem ist nur: Vieles davon fühlt sich inzwischen gleich an.

Gleiche Einleitungen.
Gleiche “Best Practices”.
Gleiche fünf Tipps.
Gleiche SEO-Struktur.
Gleiche generische Zusammenfassungen.

Und am Ende fehlt oft genau das, was für mich eigentlich interessant ist:

• Was war das konkrete Problem?
• Was wurde wirklich getestet?
• Wo ist es schiefgelaufen?
• Welche Kommandos wurden genutzt?
• Was war die Nebenwirkung?
• Wie prüfe ich, ob es funktioniert?
• Wie baue ich es wieder zurück?

Genau solche Notizen waren früher für mich der eigentliche Wert von Blogs.

Nicht perfekt. Aber ehrlich.

Der alte Blog war mein privates IT-Universum

blog.blix0r.de war über Jahre mein Sammelplatz für alles, was irgendwie mit IT, Web, Datenbanken, Linux oder meinem eigenen Setup zu tun hatte.

Da waren kurze Posts dabei.
Da waren halbe Anleitungen dabei.
Da waren Oracle-Fehler dabei.
Da waren Debian- und Apache-Themen dabei.
Da waren auch Dinge dabei, bei denen ich heute sicher anders schreiben würde.

Aber der Kern war richtig:

Ich hatte ein Thema, habe es ausprobiert und dann aufgeschrieben.

Das klingt banal, ist aber genau der Punkt.

Viele gute technische Inhalte entstehen nicht, weil jemand einen perfekten Redaktionsplan hatte. Sie entstehen, weil etwas nicht funktioniert hat und man irgendwann verstanden hat, warum.

Warum jetzt XpressLabs?

XpressLabs ist für mich der Versuch, diesen alten Blog-Charakter in eine neue Form zu bringen.

Nicht mehr ganz so wild wie früher.
Nicht mehr komplett ungefiltert.
Nicht mehr 20 Kategorien und 400 Tags, die irgendwann keiner mehr versteht.

Aber auch nicht glattgebügelt.

Der neue Fokus ist klarer:

• Dinge, die ich gefixt habe
• Setups, die ich wirklich betreibe
• Tools, die ich getestet habe
• Infrastruktur, die nicht nur auf dem Papier existiert
• Datenbank- und Ops-Themen aus der Praxis
• kleine Workarounds, die im Alltag helfen
• größere Konzepte, wenn sie wirklich sauber durchdacht sind

Der Name “Things I Fixed” passt deshalb ziemlich gut.

Nicht alles hier wird ein riesiger Deep Dive. Manchmal ist es nur ein kleiner Fix. Manchmal ein Script. Manchmal ein Setup-Runbook. Manchmal ein Kommentar zu einem Thema, das mir gerade über den Weg gelaufen ist.

Aber der Anspruch ist immer:

Es soll einen praktischen Wert haben.

Was hier nicht entstehen soll

Ich möchte hier keinen seelenlosen KI-Techblog bauen.

Kein “In der heutigen digitalen Welt...”
Kein generisches “Top 5 Tools für mehr Produktivität”.
Kein Clickbait.
Keine Artikel, die nur fremde Quellen umformulieren.
Keine Pseudo-Expertise ohne Test.

Wenn ich eine Quelle nutze, dann soll daraus mehr entstehen als eine Zusammenfassung.

Also eher:

• Quelle gefunden
• selbst ausprobiert
• erweitert
• Stolperfallen dokumentiert
• Grenzen benannt
• Fazit aus meinem Setup gezogen

Das ist für mich der Unterschied zwischen Content und einer brauchbaren Notiz.

Was sich geändert hat

Natürlich bin ich heute nicht mehr derselbe wie damals.

Ich schreibe anders.
Ich arbeite anders.
Ich betreibe Systeme anders.
Ich habe mehr Erfahrung, aber wahrscheinlich auch weniger Geduld für Bullshit.

Früher hätte ich vielleicht einfach einen Befehl gepostet und “Quelle” darunter geschrieben.

Heute will ich zusätzlich wissen:

Was macht der Befehl?
Warum brauche ich ihn?
Wie prüfe ich das Ergebnis?
Was kann kaputtgehen?
Wie rolle ich zurück?
Ist das offiziell dokumentiert oder nur ein Workaround?

Das macht die Beiträge vielleicht etwas länger, aber hoffentlich auch nützlicher.

Was bleibt

Trotzdem soll der alte Charakter bleiben.

Ein bisschen persönlicher.
Ein bisschen field-note-artig.
Ein bisschen “ich bin da gerade reingelaufen”.
Ein bisschen “kurz gesucht, gleich ausprobiert”.
Ein bisschen private IT-Welt.

Nur eben mit saubererer Struktur.

Das ist auch der Grund, warum ich den alten Slogan nicht komplett vergessen möchte. “my private it universe” war nicht perfekt, aber er war ehrlich.

Und genau dieses private IT-Universum wird jetzt nicht einfach gelöscht, sondern neu sortiert.

Welche Themen kommen?

Der grobe Rahmen steht schon.

Es wird hier unter anderem um folgende Themen gehen:

• Linux und VPS-Setups
• Apache, Reverse Proxy und WebOps
• Monitoring und Observability
• Datenbanken, vor allem Oracle und MariaDB/Galera
• Backup, Restore und Failover
• Security, Hardening und Firewall-Themen
• macOS- und Tooling-Fixes
• Ghost, WordPress und Self-Hosting
• kleine Scripts, die im Alltag helfen
• Dinge, die ich kaputt gemacht und danach verstanden habe

Also im Grunde genau das, was mich sowieso ständig beschäftigt.

Fazit

Der alte Blog war mein privates IT-Universum.

XpressLabs ist der Versuch, dieses Universum wieder sichtbar zu machen — nur mit mehr Struktur, mehr technischem Anspruch und hoffentlich weniger Altlasten.

Nicht perfekt.
Nicht glatt.
Nicht generisch.

Sondern praktisch.

Wenn hier ein Beitrag erscheint, dann sollte er im Idealfall eine einfache Frage beantworten:

Was wurde gefixt, gelernt oder ausprobiert?

Und wenn das gelingt, dann hat sich der Neustart schon gelohnt.