Ein dezentrales Web ist gut: Alle Projekte sind umgezogen

2018-06-11

All meine Software-Projekte sind nun umgezogen worden auf diesen Server hier. Die weitere Entwicklung wird hier stattfinden, neue Releases werden hier veröffentlicht werden.

Hier ist die Projektliste:

/git/

Alle anderen Quellen sind bitte als obsolet zu betrachten. Hier ist das neue Upstream.

Jedes Projekt hat jetzt seine eigene Projektseite, welche über /git/$projekt/ erreicht werden kann, also zum Beispiel:

Oben auf diesen Seiten befindet sich eine git clone ...-Zeile, die angibt, wie man das jeweilige Repository auf den eigenen Rechner klonen kann.

Man beachte auch, dass es einen Atom-Feed für jedes Projekt gibt. Sollte dein Browser Feeds nicht mehr standardmäßig anzeigen, dann kannst du sie manuell über /git/$projekt/atom.xml erreichen, beispielsweise:

Die README eines jeden Projekts enthält diesen Link:

https://www.uninformativ.de/bugs.html

Dort ist knapp beschrieben, wie man Bugs meldet oder Patches einschickt. Keine Angst, ist nicht schwer: Einfach mir eine E-Mail schicken.

Warum wurde das gemacht?

Weil ich es kann. Die eigentliche Frage ist ja: Warum ist das nicht schon früher passiert? Ich wollte den ganzen Kram schon seit Jahren umziehen, war bisher nur zu faul dafür.

Ich glaube fest daran, dass ein dezentrales Web eine gute Sache ist. Wenn du die Kenntnisse und Mittel dazu hast, einen eigenen Server zu betreiben, solltest du es tun. Man gewinnt dann maximale Kontrolle darüber, welche Software dort läuft und was mit den eigenen Daten passiert. Klar, alles hat seine Grenzen – und was man veröffentlicht, ist öffentlich. Einen eigenen Server zu betreiben bedeutet aber größtmögliche Unabhängigkeit und es fällt mir schwer, dagegen Argumente zu finden.

Warum würde man von noch einer weiteren großen Firma abhängig sein wollen? Was hat man davon?

Wie gesagt, ich war faul und ich schätze, das ist der Knackpunkt. Einen Dienst zu benutzen, der von jemand anderem bereitgestellt wird, heißt meistens weniger Arbeit für einen selbst. Okay. Oder wenn man ein sehr großes Projekt betreibt, will man vielleicht von der Erfahrung und Expertise eines großen Hosters profitieren. Okay.

Ich bin aber eine Einzelperson und schreibe nur so ein bisschen Software vor mich hin. Mir sollte es möglich sein, mein eigenes Webhosting zu machen. Rein technisch betrachtet, profitiere ich auch quasi nicht von der Benutzung kostenloser Hosting-Plattformen.

Wenn es dann um Dinge wie „Aufmerksamkeit“ oder „Sichtbarkeit“ geht, sprengen wir den Rahmen dieses Blogposts. Da spielen so viele Faktoren mit rein. Ich glaube zum Beispiel, dass ein Großteil der Sichtbarkeit aus dem System der „Follower“ resultiert und das ist eine rein soziale Frage, keine technische. Du kannst auch außerhalb von großen Plattformen Leuten „folgen“, zum Beispiel über RSS-/Atom-Feeds. Spielt auch eigentlich keine Rolle für mich, da ich mit meiner Software kein Geld verdienen will und daher quasi nie in die Statistiken schaue.

Damals, ganz tief in der Steinzeit bevor ich Versionskontrollsysteme benutzt habe, habe ich dasselbe gemacht: Das Zeug, was ich erstellt habe (Programme, Bilder, Tutorials, …), habe ich auf meinen „Server“ hochgeladen. Das war aber kein „Root Server“ so wie heute, sondern einfach nur Webspace, auf den ich mit FTP zugreifen konnte. Damals hat das gereicht. Ich habe dann Tarballs hochgeladen. Und überhaupt hatte ich viel weniger Projekte als heute. Wir reden da von vier bis fünf kleinen Dingen, die ich auf den Webspace getan hatte.

Dann habe ich mich aber langsam an Subversion, Bazaar und Git gewöhnt. Sowas kann man einfach nicht sinnvoll hosten, wenn man nur FTP-Zugriff hat. Geht nicht. Also hatte ich mich damals für einen guten Git-Hosting-Service entschieden und meinen Krempel dorthin hochgeladen. So kam das überhaupt zustande, dass ich dort gelandet bin – aus rein pragmatischen Gründen.

Heute habe ich einen „richtigen“ Server mit Root-Zugriff gemietet. Nix mehr mit „nur FTP“ und daher auch kein Grund mehr für eine Hosting-Plattform.

In einer idealen Welt müsste ich auch noch nicht einmal einen Server anmieten, sondern könnte mir zu Hause einen Raspberry Pi oder so hinstellen. Diese Geräte haben mittlerweile genug Leistung, um das bisschen Traffic zu bewältigen, das ich so habe. Schnell genug sind die Internetleitungen an Heimanschlüssen auch. Da es aber die tolle Erfindung der „dynamischen IPs“ gibt, funktioniert dieser Ansatz nicht für alle Dienste. Leider.

Überall statischer Content

Wenn wir schon dabei sind, kann ich das Setup ein bisschen beschreiben.

Dieses Blog hier ist nur ein Haufen von HTML-Dateien. Ich schreibe jetzt nicht HTML mit der Hand, sondern mache das in Markdown. Das betrifft alle Seiten hier, nicht nur das Blog. Ich habe dann ein kleines Shellskript, was über alle Markdown-Dateien iteriert und mittels python-markdown HTML erzeugt. Ein anderes Shellskript iteriert über alle Blogpost-Dateien und erzeugt daraus die Index-Dateien, die dann im nächsten Schritt wieder in HTML umgewandelt werden.

Und das ist im Wesentlichen das ganze Blogsystem.

Die Bilder und Desktop-Screenshots sind eine Reihe von JPEG-Dateien in einem Verzeichnisbaum. make-html-index macht daraus dann Thumbnails und deren Index-Seiten – wieder nur statisches HTML.

Zu guter Letzt werden die Git-Repos jetzt über stagit anzeigbar gemacht. Das ist mal wieder ein schönes Tool aus der suckless-Community. Es ist nicht so mächtig wie cgit oder sowas großes wie Gitlab, aber es ist perfekt, um den Inhalt kleiner Repos mitsamt ihrer Historie anzuzeigen. Genau das brauche ich. Wenn du dann mit dem Code arbeiten willst, klonst du ihn dir auf deinen Rechner.

Die Git-Repos selbst kann man ja sowieso über HTTP klonen. Ich habe da also eine Liste an Repos, die ich veröffentlichen möchte, und noch ein Shellskript bearbeitet diese Liste etwa hiermit:

cd $webspace
mkdir $repo && cd $repo
git init --bare

cd $repo_source
for i in $public_branches
do
    git push --tags $webspace/$repo $i
done

cd $webspace/$repo
git update-server-info

Danach kann ich $webspace auf den Server rsyncen.

Weil das jetzt alles statisches HTML ist oder statische Git-Dateien, ergeben sich eine Reihe von Vorteilen:

Ich kann rsync benutzen, um alles in einem Schritt hochzuladen.
Ich brauche weder eine Datenbank zu betreiben, zu warten, noch Backups von ihr zu erstellen.
Überhaupt brauche ich keine Datenbackups: Der Server erzeugt keine Daten. Alle meine Daten leben auf meinen Rechnern daheim und der Server hat nur Kopien davon.
Ich brauche auf dem Server sowas wie Ruby oder Python nicht.
Ich muss mir keine Sorgen machen über etwaige Sicherheitslücken in den Skripten, die der Server ausführt, denn, naja, der Server führt keine Skripte aus.
Ich hoffe, dass rein statische Inhalte auch ein bisschen schneller sind, gemessen habe ich das aber nicht.

Einer der „Nachteile“ ist dann, dass ich keinen der üblichen Bugtracker hosten kann. Auf der anderen Seite haben meine Projekte aber alle so wenig Traffic, dass ich auch keinen brauche. Wieder Nerven gespart.

Abschließende Worte

Ich bin froh, das jetzt hinter mir zu haben. War lange überfällig.

Vielleicht setze ich noch stagit-gopher auf, um all das auch im Gopher-Space verfügbar zu machen. Gopher habe ich in letzter Zeit ein bisschen vernachlässigt …

Comments?