quintus scribet - OSBN
2023-12-02T21:09:23+01:00
https://mg.guelker.eu/feeds/osbn.atom
Einstellung von ruby-xz
urn:fdc:mg.guelker.eu:20211107:blog:de:rubyxz
2021-11-07T10:55:00+01:00
Marvin Gülker
<p>
Ich stelle die Entwicklung von ruby-xz ein.
</p>
<p>
Mein Open-Source-Projekt <a href="https://github.com/Quintus/ruby-xz">ruby-xz</a> stellt Ruby-Bindings für die
C-Programmibliothek für Kompression der <a href="https://tukaani.org/xz/">XZ-Utils</a> bereit. Das Projekt
begleitet mich schon seit über zehn Jahren; der erste Commit datiert
auf den 16. März 2011. Damals stand ich noch vor meinem Studium. Meine
berufliche Laufbahn hat sich seitdem erheblich anders entwickelt als
damals vorherzusehen war und ich habe das Projekt in den letzten
Jahren eher schlecht als recht nebenher behandelt. Auf der
GitHub-Seite sammelten sich offene Tickets und Pull Requests an, die
ich oft monatelang, zuletzt jahrelang liegen ließ, weil ich für das
Projekt selbst keinen Nutzen mehr hatte und meine Zeit knapp ist.
Daher habe ich heute entschieden:
</p>
<p>
Ich gebe ruby-xz auf.
</p>
<p>
Das ist mir nicht leicht gefallen, denn ruby-xz dürfte mit Abstand
meine meistgenutzte Software sein. <a href="https://rubygems.org/gems/ruby-xz">rubygems.org listet für ruby-xz
über fünf Millionen Downloads</a> (Stand 7.11.2021 sind es 5.298.643
Downloads). Dennoch muss ich den Nutzern gegenüber ehrlich sein. Ich
habe weder die Zeit noch die Energie, das Projekt weiter in meiner
Freizeit zu betreiben. Ich bin nur noch ein Hobbyprogrammierer,
hauptberuflich ein Rechtswissenschaftler an einem Lehrstuhl an der
Universität Passau. Vielleicht ist mein Projekt eines von <a href="https://xkcd.com/2347/">diesen</a>,
vielleicht auch nicht. Was wirklich hinter den fünf Millionen
Downloads steht, kann ich nicht sagen. Jedenfalls stelle ich die
Entwicklung hiermit dauerhaft ein. ruby-xz steht unter MIT-Lizenz,
daher wird sich hoffentlich jemand finden, der das Projekt fortführt.
</p>
<div class="NOTE" id="org1a29aac">
<p>
<b>Nachtrag v. 13.11.2021</b>:<br />
Freundlicherweise hat <span class="name">Alex Gittemeier</span> alias <span class="name">win93</span> das Projekt
übernommen. Er pflegt es in <a href="https://github.com/win93/ruby-xz">diesem GitHub-Repository</a> und hat von mir
auch das RubyGem <code>ruby-xz</code> übernommen. Für Nutzer sollten dadurch
keine Unannehmlichkeiten entstehen.
</p>
</div>
CUPS: IPP-Drucker unter Linux (weitgehend) ohne mDNS einrichten
urn:fdc:mg.guelker.eu:20210925:blog:de:ipp
2021-09-25T15:12:00+02:00
Marvin Gülker
<p>
Ein Beitrag zur Frage, wie man unter Linux einen IPP-Drucker
einrichtet, wenn man nicht auf Avahi (mDNS, Zeroconf, Bonjour)
zurückgreifen möchte. Zugleich eine kurze Übersicht über das
Zusammenspiel von CUPS, Avahi und IPP.
</p>
<div id="outline-container-org8914c29" class="outline-2">
<h2 id="org8914c29">Das Problem</h2>
<div class="outline-text-2" id="text-org8914c29">
<p class="first-para">
Neuere Netzwerkgeräte veröffentlichen ihren Netzwerkstatus über ein
Netzwerkprotokoll namens <a href="https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS" class="first-para">mDNS (auch Bonjour oder Zeroconf)</a>, welches
unter Linux clientseitig der Daemon <a href="http://avahi.org/">Avahi</a> implementiert. Das betrifft
Netzwerkdrucker und seit noch jüngerer Zeit sogar Netzwerkscanner. Im
Idealfall führt das dazu, dass man seinen PC nur an ein Netzwerk
anschließen muss und schon kann man mit den vorhandenen Geräten
drucken oder scannen. Das liegt daran, dass aktuelle Versionen von
<a href="http://www.cups.org/">CUPS</a>, dem Druckermanagement-System von Linux, die Liste gefundener
Drucker von Avahi abrufen. Außerdem spielt dabei eine Rolle, dass
herstellereigene Druckertreiber zumindest für Netzwerkdrucker seit
einiger Zeit zugunsten eines allgemein unterstützten
Standardprotokolls namens <a href="https://de.wikipedia.org/wiki/Internet_Printing_Protocol">Internet Printing Protocol (IPP)</a>, welches
auch in einer TLS-verschlüsselten Variante namens IPPS existiert,
verdrängt werden. Da die Linux-Unterstützung von Druckerherstellern
meist eher stiefmütterlich war, führt das Vordringen von IPP für Linux
zu einer signifikanten Verbesserung der Nutzungsqualität.
</p>
<p>
So jedenfalls der Idealfall. Probleme entstehen, wenn jeweils für sich
auf Benutzerfreundlichkeit getrimmte Programme unabhängig voneinander
entwickelt werden. Die Standardlösung zur Verbindung mit Netzwerken
unter Linux, der <a href="https://wiki.gnome.org/Projects/NetworkManager">NetworkManager</a>, hat mit Zeroconf nichts am Hut. Das
ist zwar aus der Warte dieses auf Netzwerkkonnektivität
spezialisierten Programms richtig, führt im Zusammenspiel mit mDNS
aber mitunter zu kuriosen Situationen. Um dem Benutzer eine möglichst
zuverlässige Verbindung zur Verfügung zu stellen, bucht NetworkManager
einen Computer soweit möglich sowohl in ein kabelgebundenes LAN als
auch in ein kabelloses WLAN ein. Nun ist es aber – ebenfalls aus
Gründen der Usability – so, dass heutzutage WLAN und LAN in
Heimnetzwerken üblicherweise auf dem Router in ein einzelnes
Netzwerksegment vereinigt werden (<a href="https://de.wikipedia.org/wiki/Bridge_(Netzwerk)">Bridge</a>). In Kombination führt dies
alles dazu, dass dass derselbe Drucker <em>mehrfach</em> in CUPS auftaucht:
einmal für die LAN- und einmal für die WLAN-Schnittstelle.
</p>
<p>
Das wäre an sich nicht weiter schlimm, wenn das nicht dazu führen
würde, dass diese Drucker je nachdem, welches Interface zuerst
hochgefahren ist, unterschiedliche Namen bekämen. Manchmal scheint es
auch, als ob CUPS schlau genug ist, herauszubekommen, dass es sich um
ein und denselben Drucker handelt und legt nur einen Drucker an.
Manchmal taucht er aber auch unter einem ganz neuen Namen auf. Kurzum:
der Name des Druckers ist damit letztlich bei jeder Verbindung mit dem
Netzwerk zufällig. Für automatisiert arbeitende Skripte, die den
Druckernamen per Kommandozeilenschalter <code>-d</code> an <a class="manlink" href="https://manpages.debian.org/lp.1">lp(1)</a> festlegen,
ist das nutzlos. Es arbeitet auch nicht gut mit dem Festlegen eines
Standarddruckers in CUPS zusammen.
</p>
</div>
</div>
<div id="outline-container-orgfb05f80" class="outline-2">
<h2 id="orgfb05f80">Automatische Lösung mit Avahi</h2>
<div class="outline-text-2" id="text-orgfb05f80">
<p>
Man kann das Problem umgehen, indem man sich nicht auf die
automatische Druckererkennung von CUPS verlässt, sondern den Drucker
manuell hinzufügt (im Webinterface von CUPS <em>Verwaltung → Drucker
hinzufügen</em>). Dort wählt man den mit „driverless“ gekennzeichneten
Netzwerkdrucker aus (nur IPP-Drucker werden so gekennzeichnet) und
vergibt ein für allemal einen eigenen Namen. Damit schafft man das
Problem aus der Welt. Fügt man den Drucker auf diese Weise hinzu, dann
wird er allerdings weiterhin insoweit über mDNS angesprochen, als dass
die intern natürlich stets notwendige Feststellung der IP-Adresse des
Druckers weiterhin über Avahi abgewickelt wird.
</p>
<p>
Das kann gewünscht sein, muss es aber nicht. mDNS funktioniert nur,
wenn Avahi installiert und aktiv ist, und es kann Gründe geben, Avahi
zu deaktivieren. Zu denken ist dabei etwa an große Firmennetzwerke, in
denen zahlreiche Netzwerkgeräte mDNS unterstützen und auf diese Weise
Avahi derart viel zu tun bekommt, dass der Akkubetrieb des eigenen
Laptops darunter leidet. Da man einen Großteil dieser Geräte sowieso
nie nutzt (wer will schon auf dem Drucker des Kollegen im Gebäude
gegenüber drucken?), schaltet man Avahi schlicht ab. Nur kann man dann
gar nicht mehr auf einem mDNS-Drucker drucken.
</p>
</div>
</div>
<div id="outline-container-orgb206eb5" class="outline-2">
<h2 id="orgb206eb5">Manuelle Lösung (weitestgehend) ohne Avahi</h2>
<div class="outline-text-2" id="text-orgb206eb5">
<p>
Auch hierfür gibt es aber eine Lösung. IPP funktioniert ja nicht nur
über mDNS, sondern auch mit herkömmlicher DNS-Auflösung. Dazu fügt man
den Drucker in CUPS <a href="https://wiki.debian.org/CUPSDriverlessPrinting#Creating_a_Driverless_Print_Queue_with_the_CUPS_Web_Interface">manuell</a> als IPP-Netzwerkdrucker hinzu und wählt
als Treiber den Eintrag mit den Worten „driverless, cups-filters“ aus.
Diess führt dem Debian-Wiki <a href="https://wiki.debian.org/CUPSDriverlessPrinting#generator1">zufolge</a> dazu, dass CUPS auf Basis der
IPP-Spezifikation eine PPD-Datei generiert und – anders als der
Treiber „IPP Everywhere“ – noch einen Filter davorschaltet, der einige
typische Bugs von IPP-Implementierungen von Druckern auffängt und
einige weitere Funktionalität hinzufügt. Anders formuliert: Der
Treiber „IPP Everywhere“ konvertiert den Druckauftrag direkt in
IPP-Format und verschickt ihn dann unmodifiziert an den Drucker,
wohingegen der Treiber „driverless, cups-filters“ noch den Auftrag
etwas kuratiert, bevor er an den Drucker über IPP abgeschickt
wird.
</p>
<p>
Als Verbindungs-URI gibt man im CUPS-Webinterface folgendes an:
</p>
<pre class="example" id="orgb5d35f8">
ipp://hostname:631/rpath
</pre>
<p>
Die Portnummer ist auf 631 standardisiert und sollte daher nicht
geändert werden. Statt <code>ipp://</code> kann man – wenn man sicher ist, dass
der Zieldrucker ein gültiges und vom eigenen System anerkanntes
TLS-Zertifikat verwendet – auch <code>ipps://</code> verwenden, um eine
verschlüsselte Verbindung zu erreichen. Gerade in kleinen Heimnetzen
ist der Vorteil, Druckaufträge verschlüsselt über das Netzwerk zu
versenden, aber ein eher theoretischer.
</p>
<p>
Bei <code>hostname</code> handelt es sich um den Host-Namen des Druckers, wie er
dem DNS-Server des lokalen Netzwerkes vorliegt; alternativ kann auch
eine IP-Adresse angegeben werden, wenn man sichergestellt hat, dass
diese sich niemals ändert. Dies lässt sich entweder durch statische
IP-Adress-Konfiguration im Drucker oder durch Konfiguration des
Routers derart, dass er dem Drucker stets dieselbe IP-Adresse zuweist,
erreichen.
</p>
<p>
Mehr Probleme als der Hostname bereitet der URI-Bestandteil <code>rpath</code>.
Wie instruktiv das Debian-Wiki <a href="https://wiki.debian.org/CUPSPrintQueues#deviceuri">ausführt</a>, wurde dieser sogenannte
“resource path” nie standardisiert. Theoretisch dient er wohl dazu,
dass professionelle Druckmaschinen mehrere Pfade anbieten könnten,
aber im praktischen Heimgebrauch wird man auf solche Drucker wohl
niemals stoßen. Wählt man für <code>rpath</code> einen falschen Wert, erhält man
folgende nichtssagende, weil auf das Pfadproblem in keiner Weise
Bezug nehmende Fehlermeldung in <code>/var/log/cups/error_log</code>:
</p>
<blockquote>
<p>
W […] Backend returned status 7 (retry job immediately)<br />
E […] Der Druckauftrag wurde nicht angenommen.
</p>
</blockquote>
<p>
Den korrekten Pfad entnimmt man im Idealfall der wohlgepflegten
Dokumentation des eigenen Druckers. Da erfahrungsgemäß eine solche
meistens nicht vorliegt, kann man stattdessen entweder raten – das
Debian-Wiki, anders als das auch hier wenig hilfreiche
CUPS-Webinterface, schlägt für aktuelle Geräte <code>/ipp/print</code> vor – oder
man benutzt <code>avahi-discover</code>. Dieses Programm wertet die
mDNS-Bekanntmachungen im lokalen Netzwerk über Avahi aus und zeigt sie
in einer graphischen Benutzeroberfläche an. Dort sucht man den
gesuchten Druckereintrag für „Internet Printer“ (IPP) oder „Secure
Internet Printer“ (IPPS) heraus und notiert sich die
Werte für <code>Address</code> und <code>TXT rp</code> (<b>Abb. 1</b>). Für diesen
Vorgang ist es notwendig, Avahi einmalig zu starten; danach kann er
wieder deaktiviert werden.
</p>
<figure id="orgeb8be30">
<img src="../../data/blog/ipp-avahi.png" alt="ipp-avahi.png" />
<figcaption><span class="figure-number">Abbildung 1: </span>Anzeige von Avahi-Discover</figcaption>
</figure>
<p>
Der Wert von <code>TXT rp</code> ist der gesuchte Ressourcenpfad. Im gezeigten
Beispiel lautet er tatsächlich <code>/ipp/print</code>. Daraus ergibt sich
folgende URI für CUPS:
</p>
<pre class="example" id="org7e99345">
ipp://hostname:631/ipp/print
</pre>
<p>
Mit dieser Konfiguration sollte der Drucker nun auch ohne Avahi
funktionieren.
</p>
</div>
</div>
<div id="outline-container-org1a86719" class="outline-2">
<h2 id="org1a86719">Zusammenfassung</h2>
<div class="outline-text-2" id="text-org1a86719">
<p>
Man kann IPP-Drucker unter Linux mit CUPS auf drei Arten betreiben:
erstens mit vollständig automatischer Erkennung durch CUPS und Avahi,
was sich nur für die einfachsten Fälle anbietet. Zweitens durch
halbautomatische Einrichtung, indem man in CUPS einen eigenen,
unveränderlichen Druckernamen vergibt, man sich für die konkrete
Namensauflösung aber weiterhin auf die automatischen Dienste von Avahi
verlässt. Endlich drittens durch vollständig manuelle Konfiguration,
die auf Avahi – vom einmaligen Abrufen der Parameter abgesehen – im
laufenden Betrieb vollständig verzichten kann. Alle drei Methoden
stellte dieser Beitrag vor und gab eine kurze Übersicht, wie sie
miteinander zusammenhängen und welche Rolle CUPS, Avahi und IPP dabei
spielen.
</p>
</div>
</div>
Kurztipp: In LaTeX auf Pandoc prüfen
urn:fdc:mg.guelker.eu:20210620:blog:de:lpandoc
2021-06-20T09:27:00+02:00
Marvin Gülker
<p>
Zur Unterscheidung von Pandoc und LaTeX in einem LaTeX-Dokument.
</p>
<p>
Es kann gelegentlich sinnvoll sein, in einem LaTeX-Dokument danach zu
unterscheiden, ob es es mit einem „gewöhnlichen“ LaTeX-Prozessor wie
<code>pdflatex</code> oder <code>lualatex</code> verarbeitet wird oder mit <a href="https://pandoc.org/">Pandoc</a>. Das ist
allerdings nicht ganz einfach, da Pandoc ein entsprechendes Makro, das
mit innerhalb von LaTeX prüfen könnte, nicht <a href="https://stackoverflow.com/a/63980840">bereitstellt</a>. Gleichwohl
gibt es eine Möglichkeit, die sich der erst kürzlich in Pandoc
implementierten LaTeX-Booleans bedient und die hier kurz vorgestellt
werden soll.
</p>
<div id="outline-container-org7b7c01f" class="outline-2">
<h2 id="org7b7c01f">Abstraktes Vorgehen</h2>
<div class="outline-text-2" id="text-org7b7c01f">
<p>
Der Grundgedanke besteht darin, Pandoc vor dem eigentlichen
LaTeX-Dokument ein kleines Vordokument verarbeiten zu lassen. Dieses
Vordokument definiert einen LaTeX-Boolean, den man dann im
Hauptdokument abfragen kann. Damit das Dokument gleichzeitig mit einem
gewöhnlichen LaTeX-Prozessor verarbeitbar bleibt (und nicht wegen
eines nicht definierten Booleans zurückgewiesen wird), muss dieser
LaTeX-Boolean allerdings auch, und zwar negativ, im Hauptdokument
definiert werden. Da das aber dazu führen würde, dass auch Pandoc bei
der Verarbeitung den Boolean negativ festlegt, muss die Festlegung so
konstruiert werden, dass sie nur bei der Verarbeitung durch LaTeX
ausgeführt wird. Dazu wiederum kann man sich <code>\providecommand</code>
bedienen. Dieser etwas unbekanntere LaTeX-Befehl definiert ein
Kommando nur dann, wenn es nicht schon definiert ist. Ob Pandoc diesen
Befehl nun schlicht ignoriert (weil es <a href="https://github.com/jgm/pandoc/issues/6096#issuecomment-580339219">nicht weiß</a>, welche Kommandos
bereits definiert wurden) oder ihn korrekt ausführt, kann ich nicht
sagen, aber jedenfalls hat er den erwünschten Effekt: wenn im
Vordokument der entsprechende Befehl definiert ist, wird er im
Hauptdokument nicht noch einmal definiert.
</p>
</div>
</div>
<div id="outline-container-org1458733" class="outline-2">
<h2 id="org1458733">Praktische Umsetzung</h2>
<div class="outline-text-2" id="text-org1458733">
<p>
Konkret lassen sich diese etwas abstrakten Überlegungen wie folgt
umsetzen. Zunächst ein minimales Vordokument <code>pandoc-pre.tex</code>. Dieses
wird ausschließlich an Pandoc übergeben:
</p>
<div class="org-src-container">
<pre class="src src-latex"><span class="org-keyword">\newcommand</span><span class="org-function-name">\defpandocbool</span>{
<span class="org-keyword">\newif\ifrunsinpandoc</span>
<span class="org-keyword">\runsinpandoctrue</span>}
</pre>
</div>
<p>
Dies definiert den neuen Befehl <code>\defpandocbool</code>, führt ihn aber noch
nicht aus. Wird er ausgeführt, wird ein neuer LaTeX-Boolean namens
<code>runsinpandoc</code> definiert und auf <code>true</code> gesetzt. Die Syntax zur
Erstellung reiner LaTeX-Booleans abseits des Pakets <code>ifthen</code> ist etwas
gewöhnungsbedürftig, weil <code>\newif</code> den nachfolgenden Befehlsnamen am
<code>if</code> zerlegt; Einzelheiten können bei <a href="https://de.wikibooks.org/wiki/LaTeX-W%25C3%25B6rterbuch:_newif">Wikibooks</a> nachgelesen werden.
</p>
<p>
Im Hauptdokument geht man in der Präambel dann so vor:
</p>
<div class="org-src-container">
<pre class="src src-latex"><span class="org-keyword">\providecommand</span><span class="org-function-name">\defpandocbool</span>{
<span class="org-keyword">\newif\ifrunsinpandoc</span>
<span class="org-keyword">\runsinpandocfalse</span>}
<span class="org-keyword">\defpandocbool</span>{}
</pre>
</div>
<p>
Da in einem „normalen“ LaTeX-Lauf ohne Pandoc der Befehl
<code>\defpandocbool</code> nicht zur Verfügung steht, wird er mithilfe von
<code>\providecommand</code> erstmals definiert. In einem Pandoc-Lauf dagegen,
bei dem vorher <code>pandoc-pre.tex</code> verarbeitet wurde, ist er bereits
definiert und wird daher nicht neu definiert (oder Pandoc ignoriert
<code>\providecommand</code>, das kann ich nicht sagen). <em>Diese</em> Definition setzt
den Boolean auf <code>false</code>. Anschließend wird <code>\defpandocbool</code> sogleich
aufgerufen. Bei einem regulären LaTeX-Lauf ist der Boolean
<code>runsinpandoc</code> damit <code>false</code>, bei einem Pandoc-Lauf ist er <code>true</code>.
</p>
<p>
Anschließend braucht man nur noch an den Stellen, die unterschiedlich
behandelt werden sollen, den Boolean abzuprüfen. Dazu dient dann das
Konstrukt:
</p>
<div class="org-src-container">
<pre class="src src-latex"><span class="org-keyword">\ifrunsinpandoc</span>
Ausführung mit Pandoc.
<span class="org-keyword">\else</span>
Ausführung mit normalen <span class="org-keyword">\LaTeX</span>{}.
<span class="org-keyword">\fi</span>
</pre>
</div>
<p>
Das Hauptdokument könnte damit so aussehen:
</p>
<div class="org-src-container">
<pre class="src src-latex"><span class="org-keyword">\documentclass</span>[a4paper,ngerman,11pt]{<span class="org-builtin">scrartcl</span>}
<span class="org-keyword">\usepackage</span>{<span class="org-builtin">babel</span>}
<span class="org-keyword">\usepackage</span>[T1]{<span class="org-builtin">fontenc</span>}
<span class="org-keyword">\usepackage</span>[utf8]{<span class="org-builtin">inputenc</span>}
<span class="org-keyword">\providecommand</span><span class="org-function-name">\defpandocbool</span>{
<span class="org-keyword">\newif\ifrunsinpandoc</span>
<span class="org-keyword">\runsinpandocfalse</span>}
<span class="org-keyword">\defpandocbool</span>{}
<span class="org-keyword">\begin</span>{<span class="org-function-name">document</span>}
<span class="org-keyword">\title</span>{<span class="org-function-name">Test</span>}
<span class="org-keyword">\author</span>{Max Mustermann}
<span class="org-keyword">\date</span>{<span class="org-keyword">\today</span>}
<span class="org-keyword">\maketitle</span>{}
Dieses wird immer im Dokument stehen.
<span class="org-keyword">\ifrunsinpandoc</span>
Verarbeitung erfolgte mit Pandoc.
<span class="org-keyword">\else</span>
Verarbeitung erfolgte mit normalen <span class="org-keyword">\LaTeX</span>{}.
<span class="org-keyword">\fi</span>
<span class="org-keyword">\end</span>{<span class="org-function-name">document</span>}
</pre>
</div>
<p>
Zur Verarbeitung nutzt man dann wahlweise LaTeX:
</p>
<pre class="example" id="org0f3971b">
$ pdflatex test.tex
</pre>
<p>
Oder aber man benutzt Pandoc, wobei man darauf Acht gibt,
<code>pandoc-pre.tex</code> als erste zu verarbeitende Datei anzugeben.
</p>
<pre class="example" id="orgdbdffeb">
$ pandoc pandoc-pre.tex test.tex -o ergebnis.html
</pre>
</div>
</div>
<div id="outline-container-org196e601" class="outline-2">
<h2 id="org196e601">Ergebnis</h2>
<div class="outline-text-2" id="text-org196e601">
<p>
Es ist etwas umständlich, aber man kann ohne Zuziehung externer
Werkzeuge wie M4 feststellen, ob das aktuelle LaTeX-Dokument von
Pandoc verarbeitet wird.
</p>
</div>
</div>
Das Ende von Freenode – das Ende von IRC?
urn:fdc:mg.guelker.eu:20210619:blog:de:freenode
2021-06-19T10:49:00+02:00
Marvin Gülker
<p>
Der Beitrag ordnet die Ereignisse um Freenode und Libera.Chat in einen
größeren Kontext um das Thema IRC im Allgemeinen ein. Es wird die
Meinung vertreten, dass zwar viel Ungewissheit herrscht, aber speziell
das destruktive Verhalten der neuen Freenode-Operatoren IRC vielleicht
überraschenderweise mehr nutzt als schadet.
</p>
<p class="first-para">
Es war in allen Technikmedien zu lesen: Das IRC-Netzwerk Freenode ist
an internen Streitigkeiten <a href="https://www.heise.de/news/IRC-Netz-Freenode-ist-tot-es-lebe-Libera-Chat-6050724.html" class="first-para">zerbrochen</a>. Sogar die c’t berichtete (c’t
13/2021, S. 51). Der Blogpost versucht mit dem Abstand eines Monats,
eine größere Perspektive herzustellen, indem er zunächst über IRC im
Allgemeinen spricht (I.), danach die Ereignisse um Freenode
zusammenfasst (II.) und anschließend auf über Freenode hinausweisende
Schlussfolgerungen eingeht (III.).
</p>
<div id="outline-container-org84c7fb1" class="outline-2">
<h2 id="org84c7fb1">Zu IRC im Allgemeinen</h2>
<div class="outline-text-2" id="text-org84c7fb1">
</div>
<div id="outline-container-org92dcfd1" class="outline-3">
<h3 id="org92dcfd1">Der Fels in der Brandung</h3>
<div class="outline-text-3" id="text-org92dcfd1">
<p>
<a href="https://de.wikipedia.org/wiki/Internet_Relay_Chat">Internet Relay Chat</a> (IRC) ist ein Chat-Protokoll für
Sofortnachrichten, das in seinen Ursprüngen bis in die 80er Jahre
zurückgeht und als eines der wenigen noch in Gebrauch befindlichen
„alten“ Kommunikationsprotokolle nicht direkt amerikanischen, sondern
europäischen (genauer: finnischen) Ursprungs ist. 1993 wurde das
Protokoll zwischen den Clients und den Servern dann als <a href="https://datatracker.ietf.org/doc/html/rfc1459">RFC 1459</a> von
der IETF standardisiert. IRC hat damit alle später eingeführten
Chat-Dienste, seien sie proprietär wie ICQ oder frei wie XMPP,
überlebt. Bis jetzt erfreute sich IRC auch weiterhin insbesondere in
der Community für Freie Software und Open Source Software (FOSS)
großer Beliebtheit, wenngleich es namentlich durch optisch
aufgehübschte proprietäre Dienste wie Slack derzeit in Bedrängnis
gerät. Es ist aber nicht unwahrscheinlich, dass diese proprietären
Dienste ebenso schnell wieder verschwinden wie sie gekommen sind. Es
wäre nicht das erste Mal, dass IRC sich als Fels in der Brandung
erweist. Der Zeichner <span class="name">Monroe</span> hat das in seiner unnachahmlichen Art
wie aus <b>Abb. 1</b> ersichtlich <a href="https://xkcd.com/1782/">zusammengefasst</a>.
</p>
<figure id="org9ee383f">
<a href="../../data/blog/xkcd1782.png"><img src="../../data/blog/xkcd1782.png" alt="xkcd1782.png" /></a>
<figcaption><span class="figure-number">Abbildung 1: </span>Team Chat. © Randall Monroe, CC-BY-NC 2.5.</figcaption>
</figure>
<p>
IRC hat sich im Übrigen nicht nur gegenüber proprietären, sondern auch
gegenüber freien Protokollen als resistent erwiesen. <a href="https://de.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol">Jabber/XMPP</a>
konnte wegen seiner enormen Zersplitterung in <a href="https://xmpp.org/extensions/">zahlreiche Erweiterungen
(XEPs)</a> nie richtig Fahrt aufnehmen und gegenüber dem noch ganz neuen
<a href="https://de.wikipedia.org/wiki/Matrix_(Kommunikationsprotokoll)">Matrix</a> besteht der Vorbehalt einer Quasi-Monopolisierung beim primären
Server matrix.org, da offenbar kaum jemand bereit ist, den
ressourcenhungrigen Matrix-Server selbst zu hosten. Überdies fehlt dem
Protokoll eine festgelegte Spezifikation, was die Entwicklung
alternativer Clients abseits des offiziellen Element (ehemals Riot)
erheblich erschwert. Sowohl bei IRC als auch bei XMPP gibt es dagegen
eine Vielzahl verschiedener Clients, die jeden Geschmack bedienen.
Insgesamt wage ich bei Matrix die Prognose, dass es wegen seiner
Komplexität gemessen an IRC keine lange Lebensdauer haben wird.
</p>
</div>
</div>
<div id="outline-container-orgc373888" class="outline-3">
<h3 id="orgc373888">IRC als digitales Café</h3>
<div class="outline-text-3" id="text-orgc373888">
<p>
Es lassen sich mehrere Gründe für das Überleben von IRC anführen.
Zunächst einmal ist ein großer Vorteil von IRC ist seine technische
Einfachheit. Das verwendete <a href="https://datatracker.ietf.org/doc/html/rfc1459">Kommunikationsprotokoll</a> zwischen Client
und Server ist so einfach, dass so gut wie jeder Programmierer eine
Implementierung als Fingerübung innerhalb weniger Tage schreiben kann.
Aus Endnutzersicht mag das ein irrelevanter Vorteil sein, aus
technischer Sicht dagegen ist er die Basis für ein fortdauerndes
Interesse an der Implementation des Protokolls selbst. Eine Plattform,
deren Kommunikationsprotokoll technisch aufwendig zu implementieren
ist, wird notwendigerweise eine geringere Lebensdauer aufweisen als
eine, deren Protokoll schnell implementiert ist. Ganz ähnlich verhält
es sich etwa auch mit <a href="https://de.wikipedia.org/wiki/Gopher">Gopher</a>, das zwar längst keine Rolle mehr in der
Perspektive normaler Nutzer spielt, sich im technischen Bereich jedoch
gerade unter Minimalisten einer gewissen Beliebtheit erfreut. Mit
<a href="https://gemini.circumlunar.space/">Gemini</a> gibt es hier auch behutsame Weiterentwicklungsbestrebungen, die
in der IRC-Welt mit <a href="https://ircv3.net/">IRCv3</a> Parallelen finden.
</p>
<p>
Die technische Basis kann aber nicht der alleinige Grund für das
dauerhafte Überleben von IRC sein, da auch technisch gut
ausgearbeitete Protokolle kein Garant für deren Adaption sind; im
Übrigen darf man IRC als Protokoll mit Fug und Recht bescheinigen,
nicht mehr in jeder Hinsicht zeitgemäß zu sein. Die Antwort ist in der
konkreten Einsatzform von IRC zu suchen, den verschiedenen
IRC-Netzwerken. IRC profitiert als eines der ganz wenigen Medien im
Bereich sozialer Kommunikation vom Netzwerkeffekt, der sonst eher dazu
dient, Nutzer aus freien Kommunikationsmedien in verschlossene Silos
abzuziehen. Speziell Freenode war lange Garant dafür, dass sich zu
praktisch jedem beliebigen FOSS-Projekt dort ein Chat-Kanal fand, bei
dem es sich oft genug sogar um das offizielle
Echtzeitkommunikationsmedium des Projekts handelte. Selbst nachdem
eine bedauerlicherweise immer größer werdende Anzahl von
FOSS-Projekten ihre offiziellen Kanäle aus dem IRC abziehen und in
Silos wie Slack umziehen, finden sich oft genug immer noch
Begeisterte, die einen inoffiziellen Chat-Kanal im IRC betreiben
wollen, und das hieß bislang in aller Regel: bei Freenode. So konnte
man mit sehr hoher Wahrscheinlichkeit sagen, dass es genügte, auf
Freenode die Kanalnamen <code>#projektname</code> und <code>##projektname</code>
auszuprobieren, um auf eine Community zu stoßen, die sich mit dem
entsprechenden Projekt befasste. Freenode wurde damit zu einer Art
digitalem Café: man ging hin, um sich über ein bestimmtes Projekt zu
unterhalten, weil man wusste, dort entsprechende Leute zu treffen. Oft
genug – auch im Falle des <span class="name">Verf.</span> – haben sich aus diesen informellen
Treffen auch Freundschaften mit zuvor Unbekannten entwickelt, die über
den IRC hinaus auch im „echten“ Leben wertvoll waren und sind.
Außerhalb der FOSS-Community mag es sich für andere IRC-Netzwerke
ähnlich verhalten. Andere Plattformen konnten sich demgegenüber nicht
in derselben Weise etablieren; oft genug waren sie schon in der
Entwicklung von vornherein eher auf die Kommunikation unter Bekannten,
im Extremfall auf 1:1-Kommunikation, ausgelegt. IRC sollte dagegen von
Anfang an Treffen mit unbekannten, aber gleichgesinnten Personen
ermöglichen. Das spiegelt sich auch in der Terminologie wieder: nicht
umsonst spricht man im IRC nicht von Gruppenchats oder Chat-Gruppen,
sondern von Chat-Kanälen oder noch plastischer von Chat-Räumen.
</p>
</div>
</div>
</div>
<div id="outline-container-org7311679" class="outline-2">
<h2 id="org7311679">Die Ereignisse um Freenode</h2>
<div class="outline-text-2" id="text-org7311679">
<p>
Es gibt nicht <em>das eine</em> IRC, sondern es gibt eine <a href="https://netsplit.de/networks/">wahre Vielzahl
verschiedener IRC-Netzwerke</a>. Im Laufe der Jahrzehnte ist es um viele
IRC-Netzwerke still geworden, aber diejenigen mit Fokus auf den
FOSS-Bereich erfreuten sich bis dato weiterhin großer Beliebtheit:
</p>
<ul class="org-ul">
<li><a href="https://freenode.net/">Freenode</a> war lange das führende Netzwerk im FOSS-Bereich.</li>
<li><a href="https://www.oftc.net/">OFTC</a> war fast ebenso lange der kleinere Konkurrent von Freenode.</li>
<li>Im GNOME-Bereich hat <a href="https://help.gnome.org/users/gnome-help/stable/help-irc.html.de">GIMPNet</a> noch eine gewisse Bedeutung.</li>
</ul>
<p>
Es soll hier nicht die gesamte Geschichte von Freenode nachgezeichnet
werden. Einzelheiten lassen sich im <a href="https://ariadne.space/2021/06/14/the-end-of-freenode/">Blog von <span class="name">Ariadne
Conill</span> nachlesen</a>. Mit Fokus auf den jüngsten Ereignissen ist folgendes
geschehen:
</p>
<p>
Am 19. Mai 2021 hat der Unternehmer und koreanische Kronprinz <span class="name">Andrew
Lee</span> – er bezeichnet sich nicht nur selbst so, das ist tatsächlich
<a href="http://www.koreaittimes.com/news/articleView.html?idxno=86895">offiziell</a>, wenngleich die koreanische Königsfamilie seit der Abdankung
Kaiser <span class="name">Joseons</span> nach der Eroberung Koreas durch Japan 1910 keine Rolle
mehr in der Politik spielt – die Domain <code>freenode.net</code> übernommen,
woraufhin die bisherigen IRC-Operatoren in einer Art Meuterei
<a href="https://www.kline.sh/">weitgehend geschlossen ihr Amt niedergelegt haben</a> (Link mwN) und das
neue IRC-Netzwerk <a href="https://libera.chat/">Libera.Chat</a> gegründet haben. Die Ereignisse bis zu
diesem Zeitpunkt sind für Außenstehende schwer nachvollziehbar und
wurden von der c’t soweit nach Sichtung der veröffentlichten
Chat-Schnippsel ersichtlich korrekt als „medial[e] Schlammschlacht“
(c’t 13/2021, S. 51) eingeordnet. Es soll in dieser Geschichte um
Verrat durch eine frühere IRC-Operatorin (Halterin der Domain
<code>freenode.net</code>), verletzte Kindheitsträume, die Verwandlung von
Freenode in ein kommerzielles Unternehmen, gezielte feindliche
Übernahmen (ein Vorwurf, den beide Seiten sich übrigens gegenseitig
machen), Bestechung und vieles andere mehr gehen. Licht ins Dunkel
dieser Geschichte können nur die unmittelbar Beteiligten geben, womit
aber auf absehbare Zeit nicht zu rechnen ist. Da die öffentlich
zugänglich gemachten Chatlogs vor allem durch gegenseitige
Beschimpfungen auffallen, lohnt es sich auch nicht, die Wahrheit an
dieser Stelle zu ergründen. Das wird dereinst wohl Aufgabe von
Internethistoriken werden. In diesem Zusammenhang ist es jedenfalls
wohltuend, die <a href="https://ariadne.space/2021/05/20/the-whole-freenode-kerfluffle/">neutralen</a> <a href="https://ariadne.space/2021/06/14/the-end-of-freenode/">Ausführungen</a> von <span class="name">Ariadne Conill</span>, der
seinerzeitigen Entwicklerin der von Freenode langährig eingesetzten
IRC-Serversoftware <code>Charybdis</code> (bzw. <code>ircd-seven</code>, der auf <code>Charybdis</code>
basiert), lesen zu können, die zum Zeitpunkt des Geschehens nicht mehr
aktiv bei Freenode involviert war.
</p>
<p>
Die nach dem 19. Mai folgenden Ereignisse standen dagegen öffentlich
im Fokus. Nach einem holprigen Start wechselten innerhalb weniger Tage
zahlreiche FOSS-Projekte und Nutzer das Netzwerk von Freenode nach
Libera.Chat. Der Wechselprozess ist noch nicht abgeschlossen und kann
<a href="https://netsplit.de/networks/statistics.php?net=Libera.Chat">in den Statistiken von netsplit.de</a> live nachvollzogen werden.
Mittlerweile ist auch der Rückgang in den Zahlen von Freenode
<a href="https://netsplit.de/networks/statistics.php?net=freenode">statistisch sichtbar</a> geworden. Man sollte sich aber vergegenwärtigen,
dass netsplit.de nur die von den IRC-Servern angegebenen Zahlen
graphisch aufbereitet; ob die IRC-Server wahrheitsgemäße Angaben
machen, kann man nicht wissen. Die Statistiken von netsplit.de werden
durch die <b>Abb. 2</b> und <b>Abb. 3</b> mit Stand vom 19. Juni 2021
wiedergegeben.
</p>
<figure id="org9efcb7e">
<a href="../../data/blog/netsplit-stats-liberachat.png"><img src="../../data/blog/netsplit-stats-liberachat.png" alt="netsplit-stats-liberachat.png" /></a>
<figcaption><span class="figure-number">Abbildung 2: </span>Statistik libera.chat</figcaption>
</figure>
<figure id="org3f23f51">
<a href="../../data/blog/netsplit-stats-freenode.png"><img src="../../data/blog/netsplit-stats-freenode.png" alt="netsplit-stats-freenode.png" /></a>
<figcaption><span class="figure-number">Abbildung 3: </span>Statistik freenode.net</figcaption>
</figure>
<p>
Am 26. Mai wurde ein mit IRC-Operatorenrechten ausgestatteter Bot
namens <code>freenodecom</code> auf die noch bei Freenode bestehenden Kanäle
angesetzt (<a href="https://gist.github.com/pushcx/ab2a1d5b1d18e964c581ef18ccb3a79f">hier am Beispiel von <code>#lobsters</code></a>). Dabei wurden den
Verwaltern sämtlicher Kanäle, deren Kanalthema das Wort „Libera“
enthielt, ohne Vorwarnung sämtliche Zugriffsrechte entzogen und die
Kanäle umbenannt. Begründet wurde das mit einem automatisierten
Hinweis auf einen angeblichen Verstoß gegen Freenodes (offenbar just
zu diesem Zweck <a href="https://www.devever.net/~hl/freenode_abuse2">kurz zuvor geänderte</a>, Link mwN) Policy, die Werbung
für fremde IRC-Netzwerke untersagt. <span class="name">Lee</span>, der unter dem Nickname
<code>rasengan</code> auftritt, hat sich für diese Rasenmähermethode allerdings
<a href="https://freenode.net/news/post-mortem-may21">entschuldigt</a>. Immerhin waren auch Kanäle betroffen, die im Kanalthema
lediglich klarstellten, dass man sich in betreffs Libera.Chat noch
unsicher sei.
</p>
<p>
Danach herrschte für einige Wochen relative Ruhe. Am 11. Juni kündigte
dann die Free Software Foundation (FSF) an, aufgrund eines bereits
früher gefassten Beschlusses ihre IRC-Kanäle von Freenode nach
Libera.Chat <a href="https://www.fsf.org/news/fsf-and-gnu-move-official-irc-channels-to-libera-chat-network">umzuziehen</a>. Wie <span class="name">Amin Bandali</span> <a href="https://lists.gnu.org/archive/html/info-gnu/2021-06/msg00005.html">berichtet</a> gilt dasselbe für
das GNU-Projekt. Die FSF und das GNU-Projekt haben im Bereich Freier
Software eine erhebliche Bedeutung, sodass Freenode damit einen
maßgeblichen Betreiber von IRC-Kanälen verliert. Dennoch ist das an
sich keine überraschende Nachricht, zumal mit der erwartbaren
Begründung, dass man mit den bisherigen IRC-Operatoren weitgehend gute
Erfahrungen gemacht habe. Erstaunlich an der Sache ist, was <em>nach</em>
dieser Ankündigung in den noch als Hülse auf Freenode verbliebenen
Kanälen <code>#fsf</code> und <code>#gnu</code> passierte. Laut der Ankündigung sollten
diese Kanäle noch bis zum 25. Juni 2021 mit einem Hinweis auf den
Wechsel versehen werden, was im Einvernehmen mit den neuen
Freenode-Operatoren beschlossen worden war. Stattdessen tauchte am 13.
Juni eine ganze Gruppe von IRC-Operatoren in <code>#fsf</code> auf und entzog der
FSF ohne Vorwarnung <a href="https://www.fsf.org/news/update-to-the-fsf-and-gnus-plan-to-move-irc-channels-to-libera.chat">die Kanalverwaltungsrechte</a>. Ein in der
Authentizität nicht prüfbares <a href="http://techrights.org/wp-content/uploads/2021/06/fsf-channel-canceled.txt">Chatlog</a> soll den Vorgang wiedergeben. Es
steht exemplarisch für die beiderseitige Emotionalität des Themas:
sowohl Freenodes IRC-Operatoren als auch FSF-Vertreter beschimpfen
einander. Weil die IRC-Operatoren am längeren Hebel sitzen, erhält ein
FSF-Vertreter (ebenderselbe <span class="name">Bandali</span>, der die Ankündigung für das
GNU-Projekt schrieb) am Ende ein K-Line (Bann).
</p>
<p>
Vorerst letztes Kapitel in der Saga ist die nicht auf der Webseite,
sondern am 15. Juni nur <a href="https://www.devever.net/~hl/freenode_suicide">per Global Notice angekündigte Ausrollung
einer neuen Serversoftware</a> unter Löschung der bisherigen Datenbanken.
Da die alten Server teils noch funktionieren, liegt damit ein von den
IRC-Operatoren mutwillig herbeigeführter sog. <em>Netsplit</em> vor: die
unterschiedlichen IRC-Server eines Netzwerks haben eine
unterschiedliche Meinung darüber, welche Nicks und Kanäle es gibt.
</p>
</div>
</div>
<div id="outline-container-org43c2611" class="outline-2">
<h2 id="org43c2611">Schlussfolgerungen</h2>
<div class="outline-text-2" id="text-org43c2611">
<p>
Es liegt auf der Hand, dass Freenode, wie wir es bisher kannten, nicht
mehr existiert. Insoweit sei jedem empfohlen, entweder nach OFTC oder
nach Libera.Chat zu wechseln. Diese rein praktische Empfehlung ist
aber nicht der Grund für diesen Beitrag, zumal sie mittlerweile jedem
bekannt sein dürfte. Hier soll es um einen etwas weiteren Blickwinkel
gehen.
</p>
</div>
<div id="outline-container-org94b57d4" class="outline-3">
<h3 id="org94b57d4">Zur Zukunft von Libera.Chat und Freenode</h3>
<div class="outline-text-3" id="text-org94b57d4">
<p>
Zunächst stellt sich die Frage, ob Libera.Chat sich neben Freenode
überhaupt etablieren kann. Es drängt sich die Befürchtung auf,
Libera.Chat werde es vom Ansehen her ähnlich ergehen wie LibreOffice:
die Freiwilligen wenden sich vom Inhaber der Namensrechte ab und
versuchen jahrelang weitgehend erfolglos, den Nimbus des alten Namens
(OpenOffice) zu erwerben. Nach zwölf Jahren ist der Name LibreOffice
weiterhin außerhalb von Linuxkreisen nicht allgemein bekannt. Legt man
diese Messlatte an Libera.Chat an, steht dem Netzwerk eine
jahrzehntelange Durststrecke bevor, während Freenode allein von der
Bekanntheit seines Namens getragen wird und unabhängig von der
inhaltlichen Ausrichtung Nutzer anzuziehen vermag. Jedoch gibt es
bereits jetzt Anzeichen dafür, dass dieses Szenario sich nicht
verwirklichen wird. Dafür muss man nicht auf derart abwegige
Denkweisen wie <a href="https://lobste.rs/chat">„This channel was originally created … on
freenode, and stayed with the network on 2021-05-19 after that domain
was lost“</a> verfallen<sup><a id="fnr.1" class="footref" href="#fn.1" role="doc-backlink">1</a></sup>, sondern es genügt, sich die <a href="https://netsplit.de/networks/statistics.php?net=Libera.Chat">Statistiken</a>
<a href="https://isfreenodedeadyet.com/">anzuschauen</a> und <a href="https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacked.html">den</a> <a href="https://libera.chat/news/one-week-of-libera-chat">Exodus</a> <a href="https://www.fsf.org/news/fsf-and-gnu-move-official-irc-channels-to-libera-chat-network">prominenter</a> <a href="https://archlinux.org/news/move-of-official-irc-channels-to-liberachat/">Projekte</a>.
</p>
<p>
Zusätzlich scheint es, als versuchten die neuen IRC-Operatoren von
Freenode, dieses wirklich nachhaltig zu zerstören. So hat man dem
geschilderten provozierten Netsplit attestiert, er führe effektiv zum
<a href="https://www.devever.net/~hl/freenode_suicide">„Selbstmord“ des Netzwerks</a>. Das allein mag nicht überzeugend sein (auf
Seiten von Freenode spricht man lieber davon, man <a href="https://freenode.net/news/taking-irc-further">entwickle IRC
weiter</a>), aber die Moderationsqualität der neuen Freenode-Operatoren
ist der zuverlässigste Garant für ein mittelfristiges Verwaisen des
Netzwerks. Die oben geschilderten Fälle – der Bot <code>freenodecom</code> und
die manuelle Zwangsregulierung von <code>#fsf</code> – lassen erkennen, dass den
Beteiligten Führungsqualitäten fehlen. In beiden Fällen kam es jeweils
nicht nur innerhalb kürzester Zeit zur moderationstechnischen
Höchstrafe (K-Line bzw. zwangsweiser Kanalentzug), sondern dieses
geschah auch noch ohne jede Vorwarnung und ohne die Einhaltung
irgendeiner Form von Eskalationsleiter. Das ist kein professioneller
Umgang mit Verletzungen von Netzwerk-Policies, ganz besonders, wenn
diese kurzfristig zuvor geändert wurden. Mit Recht hat man kritisiert,
die neuen IRC-Operatoren von Freenode betrieben diesbezüglich
<a href="https://www.devever.net/~hl/freenode_abuse">Machtmissbrauch</a>. Als wäre das alles nicht schon schlimm genug, sonnt
man sich in der eigenen technischen Machtposition und lässt dies
andere in geradezu herablassender Weise wissen, wobei man deutlich
macht, an dieser Machtausübung auch noch Spaß zu haben. Das oben
erwähnte <code>#fsf</code>-<a href="http://techrights.org/wp-content/uploads/2021/06/fsf-channel-canceled.txt">Chatlog</a> macht das deutlich (Nicks mit
<code>staff</code>-Markierung und der Nick <code>root</code> sind IRC-Operatoren von
Freenode):
</p>
<pre class="example" id="orgce5e4b9">
2021-06-13 06:04:23 → TheRedHorseman (~bagira@freenode/staff/phanes) has joined #fsf
[…]
06:43:07 → Foxy (znc@freenode/staff/foxy) has joined #fsf
06:43:46 → job (job@gateway/shell/tilde.team/x-dhtjyelnzoocvubg) has joined #fsf
06:44:04 → root (root@internet.relay.chat) has joined #fsf
06:44:19 → azend (~quassel@unaffiliated/azend) has joined #fsf
06:44:20 job oh no
06:44:26 root sudo su
06:44:35 TheRedHorseman o/
06:44:37 ← fling (~fling@fsf/member/fling) has quit (Ping timeout: 245 seconds)
06:44:50 Foxy \o
06:45:02 * TheRedHorseman trots around in a circle, eyes gleaming red in the dark
06:45:16 → altwulf (~altwulf@64.227.64.196) has joined #fsf
06:45:46 ← wolftune (~aaron@75.164.131.0) has quit (Quit: Konversation terminated!)
06:45:53 → wolftune (~aaron@75.164.131.0) has joined #fsf
06:45:57 -- Mode #fsf [-o ggoes] by OperServ
06:46:50 ggoes never a dull moment
06:46:56 bandali ^
</pre>
<p>
Das nachfolgende Geschehen ist von beiden Seiten nicht mehr
zitierwürdig, aber so geht man keinen Konflikt an. So lässt man andere
wissen, dass man sie als minderwertig erachtet. Das schafft ein Klima
von Angst und Misstrauen, dem sich niemand freiwillig aussetzen wird.
Es dürfte deshalb nicht weit hergeholt sein, Freenode zu bescheinigen,
eine Art digitales <a href="https://lotr.fandom.com/wiki/Khazad-d%25C3%25BBm">Khazad-dûm</a> xzu werden. Anders als es bei Oracle mit
OpenOffice der Fall war, wird der bestehende Ruf des Namens durch die
Namensinhaber in erheblicher Weise beschädigt. Das wird Libera.Chat
damit schon deshalb Auftrieb geben, weil es eben nicht Freenode ist.
</p>
<div class="NOTE" id="org3d8cc5f">
<p>
<b>Nachtrag v. 26.06.2021</b>:<br />
<a href="https://gerikson.com/blog/"><span class="name">Gustaf Erikson</span></a> hat mir freundlicherweise seine Chatlogs des
fraglichen Tags von <code>#fsf</code> und <code>#freenode</code> zur Verfügung gestellt. Ich
konnte mich davon überzeugen, dass sie mit den oben zitierten Angaben
übereinstimmen.
</p>
</div>
</div>
</div>
<div id="outline-container-org70df334" class="outline-3">
<h3 id="org70df334">Was wird aus IRC?</h3>
<div class="outline-text-3" id="text-org70df334">
<p>
Freenode war bis zum 19. Mai 2021 das größte noch bestehende
IRC-Netzwerk, weshalb sein Zerfall unweigerlich die Frage nach sich
zieht, ob damit auch IRC an sich am Ende ist. Einige Projekte haben
sich entschieden, statt nach Libera.Chat oder OFTC auf ein gänzlich
anderes Medium zu migrieren; NixOS etwa <a href="https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos-org-migrating-from-freenode/13166">migriert nach Matrix</a>. Die FSF
und das GNU-Projekt hatten diese Option in ihrer Entscheidung dagegen
bewusst <a href="https://www.fsf.org/news/fsf-and-gnu-move-official-irc-channels-to-libera-chat-network">verworfen</a>, da Matrix ihren Ansprüchen an Softwarefreiheit
nicht genügt<sup><a id="fnr.2" class="footref" href="#fn.2" role="doc-backlink">2</a></sup>. Auch angesichts der schwierigen
Entwicklungssituation bei Matrix (s.o. <a href="#org92dcfd1">II.1</a>) dürfte das eine sinnvolle
Entscheidung sein. Wenn nur genug Projekte den Freenode-Zusammenbruch
als allgemeinen Anlass sehen, sich von IRC insgesamt abzukehren, dann
wird der 19. Mai 2021 als der Anfang vom Ende von IRC in die
Internetgeschichte eingehen.
</p>
<p>
Sorgen bereiten muss weiter die Erwägung, ob die Entscheidungen der
neuen Freenode-Operatoren den Ruf von IRC insgesamt beschädigen. Die
Hacker-Community gilt bekanntlich ohnehin als schwierig und man
benötigt im Umgang mit ihr ein dickes Fell. <span class="name">Torvalds</span> legendärer
<a href="https://www.pro-linux.de/news/1/18489/linus-torvalds-wettert-gegen-nvidia.html">öffentlicher Ausfall</a> gegenüber NVIDIA steht hierfür exemplarisch. Der
Name Freenode stand seit gut zwanzig Jahren für <em>den</em> Ort, an dem man
sich über FOSS austauscht, wenn es etwas schneller und informeller
zugehen sollte als in den Foren und Mailinglisten der einzelnen
Projekte. Wenn dieser Ort nun nach Gutsherrenart geführt wird, könnte
das dem Medium IRC und sogar dem Ruf der Hacker-Community insgesamt
massiv schaden. Das lässt sich zum gegenwärtigen Zeitpunkt leider
nicht ausschließen. Zu hoffen bleibt, dass die neuen IRC-Operatoren
von Freenode entweder ihre diesbezügliche Verantwortung erkennen oder
aber die Destruktion des verbleibenden Rumpfnetzwerks so konsequent zu
Ende führen, dass in der öffentlichen Wahrnehmung eine Lücke entsteht,
die Libera.Chat füllen kann, bevor ein größeres Gebilde einstürzt.
</p>
<p>
Momentan sieht es allerdings danach aus, als ob sich letzteres
verwirklicht. Auch wenn die genauen Abläufe zum Vorlauf des 19. Mai
herum letztlich im Dunkeln bleiben, muss man den Libera-Operatoren
Anerkennung für ihr Husarenstück zollen. Just an dem Tag, an dem <span class="name">Lee</span>
seinen Einfluss auf Freenode ausnutzt, springt in einer koordinierten
Aktion der Großteil des Freiwilligenstabs ab und hat sogleich ein fast
voll funktionales Alternativnetzwerk anzubieten. Dieser doppelte
Streich hat eine gehörige Medienaufmerksamkeit generiert, die das
betagte Medium IRC seit langer Zeit einmal wieder ins Licht der
Öffentlichkeit gerückt hat. Das hatte auch ganz unmittelbare
Konsequenzen: Wer in den ersten Tagen die Chat-Verläufe im Metakanal
<code>#libera</code> mitverfolgt hat, konnte eine Menge Leute beobachten, die
sich entweder erstmals oder doch erstmals wieder seit langer Zeit mit
IRC auseinandersetzten und ob der Lebendigkeit des Medium erstaunt
waren. Ob dieser Effekt von Dauer sein wird, muss sich allerdings noch
zeigen. Das IRCv3-Projekt jedenfalls täte gut daran, die unverhoffte
Aufmerksamkeit für IRC zu nutzen.
</p>
<p>
IRC hat schon viele andere Protokolle und Dienste kommen und gehen
sehen und es liegt nahe, dass auch die Ereignisse um Freenode nicht
genügen, um das Protokoll auf das Abstellgleis zu stellen.
</p>
</div>
</div>
</div>
<div id="outline-container-orgd58c58a" class="outline-2">
<h2 id="orgd58c58a">Fazit</h2>
<div class="outline-text-2" id="text-orgd58c58a">
<p>
Freenode ist am Ende, Libera.Chat am Anfang. Die Zukunft von IRC als
<em>das</em> Kommunikationsmedium in der FOSS-Szene ist ungewiss wie nie
zuvor: womöglich ist der Freenode-Zusammenbruch der Anfang vom Ende
von IRC, weil er zu einer großflächigen Negativ-Evaluation des Mediums
führt. Vielleicht, und das erscheint derzeit wahrscheinlicher, führt
aber die gesteigerte Medienberichtertattung gerade im Gegenteil dazu,
dass das alte Medium neue Aufmerksamkeit gewinnt und Libera wie IRC
überhaupt gestärkt aus der Angelegenheit hervorgehen.
</p>
</div>
</div>
<div id="footnotes">
<h2 class="footnotes">Fußnoten: </h2>
<div id="text-footnotes">
<div class="footdef"><sup><a id="fn.1" class="footnum" href="#fnr.1" role="doc-backlink">1</a></sup> <div class="footpara" role="doc-footnote"><p class="footpara">
Diese kaum verständliche Aussage findet eine Präzisierung in
<a href="https://lobste.rs/s/1z77ly/libera_chat#c_vwmpgx">dieser Sysop-Stellungnahme</a>: „The network is the people, not a domain
name“.
</p></div></div>
<div class="footdef"><sup><a id="fn.2" class="footnum" href="#fnr.2" role="doc-backlink">2</a></sup> <div class="footpara" role="doc-footnote"><p class="footpara">
Interessanterweise wird auch XMPP verworfen, und zwar mit dem
Argument, dass es gegenüber IRC einfach nicht genug neue Features habe.
</p></div></div>
</div>
</div>
Neue Mailingliste Emacs-Humanities
urn:fdc:mg.guelker.eu:20201227:blog:de:emacshum
2020-12-27T00:00:00+01:00
Marvin Gülker
<p>
Es gibt eine neue Mailingliste emacs-humanities für Geisteswissenschaftler.
</p>
<p class="first-para">
Der <span class="name">Verf.</span> gehört zu der leider viel zu kleinen Gruppe von nicht
naturwissenschaftlich ausgebildeten Personen, die die mächtigen
Werkzeuge der Techniker für sich entdeckt haben. <a href="https://www.gnu.org/software/emacs/" class="first-para">Emacs</a> ist ein Editor
zur Arbeit mit und am Text und bietet zum Umgang mit diesem
vielfältige Möglichkeiten. Gerade Rechtswissenschaftler, die ja kraft
Berufs tagein, tagaus mit dem Medium Text umgehen müssen, sollten sich
mit dem Werkzeug befassen. Wer sich im juristischen Studium auch nur
einmal über zerschossene Word-Layouts, repetetive Klickorgien in
überlangen Menübändern und die Frage, welche von fünf Dateikopien
jetzt die aktuelle Fassung ist, geärgert hat, wird sich über die
Möglichkeiten freuen, die ein professionelles Textbearbeitungswerkzeug
wie Emacs bietet.
</p>
<p>
Wie schon an <a href="https://irreal.org/blog/?p=9361">anderer Stelle bemerkt wurde</a>, hat das GNU-Projekt als
Infrastrukturorganisation hinter Emacs eine neue Mailingliste
<a href="https://lists.gnu.org/mailman/listinfo/emacs-humanities">„emacs-humanities“</a> eingerichtet, die sich speziell an
Geisteswissenschaftler richtet. Es kann dort über alle Fragen
diskutiert werden, die der Gebrauch von Emacs im
geisteswissenschaftlichen Bereich, zu dem man die Rechtswissenschaft
wohl auch zählen darf, mit sich bringt. Davon gibt es wahrlich genug
und bisher drängte sich der Eindruck auf, daß diese im
naturwissenschaftlich geprägten Entwicklerkreis der Software bisher
etwas stiefmütterlich behandelt wurden. Die neue Mailingliste könnte
eine Möglichkeit sein, daran etwas zu ändern. Daher sei denjenigen
unter den Lesern, die der rechtswissenschaftlichen Seite zuzuordnen
sind, ein Blick auf diese – leider englischsprachige – Mailingliste
nahegelegt.
</p>
<p>
Wer mit Mailinglisten fremdelt, weil er fürchtet, sein Postfach könnte
überflutet werden, der sollte sich einmal mit dem Einrichten
automatischer Filter befassen. Viele E-Mail-Anbieter, darunter in
aller Regel auch die Universitäten, ermöglichen automatisiertes,
serverseitiges Einsortieren von E-Mails in vorher festgelegte Ordner.
Damit gelangt keine E-Mail von der Mailingliste in den Hauptordner des
E-Mail-Kontos. Selbst, wenn der eigene E-Mail-Anbieter serverseitiges
Filtern nicht unterstützt, kann man mit einem E-Mail-Programm wie
<a href="https://www.thunderbird.net/de/">Thunderbird</a> auch klientseitig <a href="https://support.mozilla.org/de/kb/Nachrichten-Filter_Regeln_organisieren">automatisiert filtern</a>. Das unterliegt
naturgemäß der Einschränkung, daß die Filter nur aktiviert werden,
wenn man die E-Mails mit Thunderbird empfängt, was möglicherweise
nicht der Fall ist, wenn man auf sein E-Mail-Konto auch per Smartphone
zugreift. Soweit vorhanden, sollte man deshalb auf serverseitige
Filterung zurückgreifen.
</p>