Umzug auf Nikola
Als die Familie im Urlaub war und mich verantwortungsloserweise allein zuhause gelassen hat, habe ich die sturmfreie Bude genutzt und angefangen, den Familienblog, der de facto eher mein Blog ist, von Serendipity auf einen Static-Site-Generator umzustellen. Ich habe mich für Nikola entschieden. Die Geschwindigkeit vorher war auch nicht schlecht, aber schneller als jetzt geht es halt auch nicht.
Der Workflow ist anders, wobei ich sagen muss, dass es sicher daran liegt, dass ich die Einträge bislang nur konvertiert habe:
Ich erstelle eine Textdatei, …
… schreibe in die ersten paar Zeilen ein paar Metadaten …
… und in den Rest dann den Artikelinhalt.
Um einen Eindruck von der Formatierung zu bekommen, verwende ich lokal ReText, was sowohl RestructuredText wie auch Markdown versteht. Bin ich am Ende zufrieden, wird die Datei gespeichert und mittels nikola build die Änderungen seit dem letzten Build neu erzeugt. Die erstellten statischen Seiten muss ich dann auf den Webserver schieben. Perspektivisch überlege ich, ob nicht einfach ein Git-Repository nutze und da dann eine CI/CD-Pipeline ranbastele. Weiß aber gerade nicht, ob das aufwändiger wird.
Erste Schritte mit Flatpak
Ich habe die letzten Tage Spaß mit Flatpak-Paketierung gehabt. Meine Mädels wollten Dungeondraft haben, was für Linux wahlweise als .deb oder als .tar.gz angeboten wird. Aber ich habe ihre Rechner ja mit Silverblue aufgesetzt, und dort sind Flatpaks First-Class-Citizens. Klar, die tar-Balls hätten auch irgendwie funktioniert, aber warum nicht das Nützliche mit dem Lehrreichen verbinden? 😀
Das Paketieren hat super funktioniert. Ich hatte vor einiger Zeit mal mit Vicuna begonnen und den Flow jetzt ausgenutzt, Vicuna, Pattypan, Commonist, OpenRefine und Freemind flatpaketieren zu wollen, die bei WMDE Teil der Installation sind. Meine Recherche zu Freemind zeigte, dass die Software seit einigen Jahren schon nicht mehr weiterentwickelt wird. Ich fand dann Freeplane als Ergebnis meiner Recherche zu Mindmapping-Werkzeugen unter Linux, die noch weiterentwickelt werden. Und das gibt es auch schon als Flatpak, also musste ich da nichts mehr machen. OpenRefine ist ein Sonderfall, weil es lokal einen Server startet und die Bedienung dann im Browser stattfindet. Da weiß ich noch nicht, wie ich damit umgehen will. Vergleichbares kenne ich nur von Syncthing, aber das gibt es auch nicht "pur" als Flatpak, sondern nur mit dem einen oder andern Tray-Indicator. Aber Vicuna, Pattypan und Commonist habe ich erfolgreich paketiert gekriegt, im Falle von Vicuna sogar besser als lokal installiert, weil ich dem Flatpak ohne Probleme die passende JVM konfigurieren kann (alles über OpenJDK8 macht irgendwie Probleme mit der Konfigurationsdatei).
Der nächste Schritt wird sein, ein Repository aufzusetzen. Momentan habe ich ein lokales Repository.

Das ist nur begrenzt nützlich. Die Flatpaks für meine Kinder will ich lokal bei mir verteilen, die Flatpaks für WMDE sollten für die damit bespielten Rechner erreichbar sein. Ich muss mir da noch was mit GPG-Signaturen und so anlesen und wie ich das dann tatsächlich verteilen soll. Ein pacman-Repository war ja recht simpel, aber ich habe noch keine Ahnung, wie das mit Flatpaks läuft.
Natürlich könnte ich die WMDE-Flatpaks auch bei Flathub einreichen, aber einer der Vorteile von Flatpaks gegenüber Snap ist ja eben, dass man das dezentral aufsetzen kann und keine zentrale Autorität braucht.
Und Dungeondraft und Wonderdraft sind kommerzielle Software, die ich nicht einfach irgendwo herunterladen lassen kann. Für die Verwendung in der Familie finde ich das noch fair, was ich mache, auch wenn ich mich rechtlich sicher in einer Grauzone bewegen sollte. Wenn Megasploot drauf bestehen sollten, kaufe ich eben zwei weitere Lizenzen dafür. Für eine Verwendung in der Familie sehe ich da aber nicht akut Handlungsbedarf.
Spotifys Familientarif
Es kam jetzt schon mehrmals vor, dass ich auf dem Heimweg Musik über Spotify hörte und plötzlich die Musik ausging. Ich konnte sie zwar wieder starten, aber kurz danach war sie wieder weg.
Zuhause hat $Familie nämlich Spotify über Google Home gestartet.
Jetzt dachte ich mir, so viel mehr kostet Spotify Premium Family auch nicht, da gönn ich mir das mal, und jede*r kriegt eigene Playlists und Verläufe …
Aber, ich habe die Rechnung ohne Spotify gemacht. Spotify bietet eine App an, Spotify Kids. Die Rezensionen ließen nichts Gutes ahnen, also dachte ich mir, ich erstelle einen normalen Account für $Kind1. Tja, Spotify verlangt ein Geburtsdatum. Gebe ich das korrekte Datum an, verweigert Spotify den Account mit Verweis darauf, dass man zu jung sei für Spotify.
Okay, also probiere ich doch erstmal die Kids-App. Melde mich dort mit meinem Konto an und erstelle ein Kids-Konto. Dann die Ernüchterung: Ich kann der App nur sagen, sie soll sich per Bluetooth mit irgendwas verbinden. Keine Auswahl der Abspielgeräte. Aber es soll ja eben die Musik über Google Home abgespielt werden!
Najut, denke ich mir, Spotify bietet Kids-Konten für 0-6 Jahre und für 5-12 Jahre an. Dann mache ich sie eben 3 Jahre älter und erstelle ein normales Konto … aber Pustekuchen! Auch dann gilt sie noch als zu jung.
Also suche ich nach dem Mindestalter für Spotify und finde: »Um die Spotify-Dienste nach diesen Allgemeinen Nutzungsbedingungen nutzen und auf Inhalte zugreifen zu können, (1) müssen Sie 18 Jahre alt oder älter sein, oder 16 Jahre alt oder älter sein und das Einverständnis Ihrer Eltern oder Ihres Vormunds zu der Vereinbarung besitzen,[…]«
Es gibt also für Kinder von 13 bis 16 Jahren keine Möglichkeit, Spotify zu nutzen, da sie zu jung für ein Konto und zu alt für ein Kids-Konto sind. Das sie selbstverständlich nutzen könnten, aber erklärt mal einem Teenager, dass sie ein Kinderkonto nutzen sollen. Zumal es gegenüber dem regulären Spotify kuratiert, limitiert und technisch beschnitten ist. Jedenfalls motivieren mich diese Einschränkungen nicht, mehr Geld für den Familientarif zu zahlen.
Grundsätzlich frage ich mich, welchen Sinn der Familientarif überhaupt hat, wenn die Hauptnutzerïnnen im Alter von 12 bis 16 Jahren den Dienst nicht nutzen können, wie sie wollen. Und Familienmitglieder über 18 Jahre am selben Wohnort sind eine verschwindend kleine Gruppe. Viele Kinder können es gar nicht erwarten auszuziehen, selbst wenn ich meinen Kindern anbiete, dass sie bis zum Ende ihres Studiums bei uns wohnen können, was wohl so mit 24 Jahren sein dürfte.
Soziale Videokonferenzen
Gestern kam endlich die Mail vom Chef: Die Weihnachtsfeier wurde abgesagt!
Sehr beruhigend. Ich habe ja darauf gehofft und damit gerechnet, so dass ich mir schon Gedanken gemacht habe, wie wir die Feier dann virtuell abhalten können. Klar, per Video, aber Teams ist denkbar ungeeignet zum Socialisen. Was gibt es denn so an Alternativen, die nicht alle strunzlangweilig aussehen?
Als erstes fiel mir https://wonder.me ein, das ich auch schon benutzt habe. Ich mag die dynamische Erstellung von kleinen Plauschzirkeln, das kommt einer Party-Dynamik näher als das umständliche Erstellen von Breakout-Räumen. Negativ fällt mir auf, dass die Areas von wonder.me leider nicht weiter anpassbar sind und auch ansonsten eher keine Funktion erfüllen.
Vor einem halben Jahr oder so stieß ich aber noch auf einen anderen Dienst, dessen Name mir aber nicht mehr einfallen wollte. Tipp: Wenn etwas so halbwegs interessant ist, anmelden und Newsletter abonnieren. Dann vergisst man das nicht mehr. Jedenfalls habe ich mich auf die Suche nach Alternativen zu wonder.me gemacht und fand dann auch https://gather.town wieder. Da kann man aus Vorlagen auswählen oder mit einem Tile-Editor eigene Räume im 8-Bit-Stil entwerfen. Einfache Interaktionen mit der Karte sind auch möglich.
Unter https://www.hyhyve.com/ gibt es einen weiteren Dienst, der ähnlich wie wonder.me funktioniert, aber rudimentäre Karten bietet. Ich habe jetzt nicht gesehen, dass man da eigene hochladen kann, aber ab 499 USD kann man sich welche von denen designen lassen.
https://spatial.chat/ wirkt wie Gather Town auf Steroiden. Bislang habe ich da noch keinen Test durchführen können – mir wurde noch kein Raum bereitgestellt. Die Optik auf deren Website sieht jedenfalls schnieke aus. Inwiefern das anpassbar ist, kann ich derzeit aber noch nicht sagen.
Die Website, die mich mit all diesen Links versorgt hat, https://www.micestens-digital.de/tools-fuer.../, erwähnt aber auch einen Dienst namens "Unhangout". Hangout, wissen wir, hat Gruppen-Videochats ja erst so halbwegs populär gemacht, weswegen der Name meine Neugierde geweckt hat. Es handelt sich um eine Open-Source-Lösung, die am MIT entwickelt oder zumindest dokumentiert wird: https://unhangout.media.mit.edu/. Mit den anderen hier genannten Lösungen hat es jetzt nicht so viel gemein, aber als Alternative zu Big Blue Button kann man es sich mal anschauen.
Erwähnenswert ist auch noch https://www.butter.us/, das ich, glaube ich, mal im Rahmen einer Veranstaltung eines Freundes kennenlernen durfte. Es sticht durch zahlreiche Integrationen von Anwendungen heraus.
https://www.welo.space/ habe ich dann schon nicht mehr weiter angeschaut, könnte aber auch interessant sein.
Update 2021-12-01 21:45: Eine ehemalige Kollegin machte mich auf https://workadventu.re aufmerksam. Nice. Die Video-Einbindung ist nicht so transparent wie bei den anderen, aber für komplett open-source ist das schon beeindruckend. Für die Video-Komponente wird auf Jitsi Meet zurückgegriffen. Ich bin gespannt, ob das von deren Ansible-Playbook mitinstalliert wird oder ob ich das selbst bereitstellen muss.
Inkscape: Grafische Editoren, Beschreibungssprachen und ihre Tücken
Eine Kugel wurde da bspw. als Menge aller Punkte definiert, die einen Abstand r von einem Punkt z haben. Damit war eine Kugel wirklich eine Kugel und keine Menge an Dreiecken, die nur in Annäherung eine Kugel ergeben.
Wenn ich eine Differenz zwischen der Kugel und einer Ebene durch den Mittelpunkt der Kugel bildete, bekam ich eine Halbkugel. Ebenso bei der Schnittmenge in diesem Fall, dann jedoch die andere Halbkugel.
Es hat sich in vielerlei Hinsicht als sinnvoll erwiesen, die Objekte im Ursprung zu entwerfen und erst am Ende zu skalieren und zu translatieren (bewegen). Eine Kugel, die bei <0,0,0> definiert ist, verhält sich nämlich anders als eine Kugel, die bei <1,0,0> definiert ist. Skaliere ich beide Kugeln um 2, bleibt erstere mit ihrem Mittelpunkt an Ort und Stelle, letztere bewegt sich um den Skalierungsfaktor entlang der x-Achse, da all ihre Punkte um den Faktor skaliert werden. Und Translationen finden dann ganz zum Schluss statt, wenn das Objekt die passende Größe hat, denn eine Skalierung am Ende würde auch die Translation skalieren.
SVG wiederum ist XML. XML ist eine Auszeichnungssprache. Das heißt grob, dass mit XML irgendwelche menschenlesbaren Texte oder Werte ausgezeichnet werden, damit sie maschinenlesbar und -interpretierbar sind. Schon MathML zur Auszeichnung mathematischer Ausdrücke hat mich in seiner Unleserlichkeit schockiert, SVG ist nur graduell besser. Beide Sprachen kranken meiner Meinung nach daran, dass sie den Gegenstand des Interesses (mathematische Ausdrücke einerseits, 2D-Vektorgrafik andererseits) krampfhaft in XML verpacken wollten. Aber jut, so isses halt. Vermutlich ging es darum, mittels CSS und JavaScript auf die jeweiligen Dokumente zugreifen zu können, und das DOM existierte ja schon für (X)HTML. Ich habe aber auch nur sehr wenige MathML- und SVG-Inhalte im Web gesehen und noch weniger dynamisch mit JavaScript manipulierte. Wobei das ziemlich cool wäre. Aber ich vermute HTML5's canvas-Element hat SVG hier überflüssig gemacht

Was mich aber fuchst, ist die primitive Form der booleschen Operationen: Wenn ich einen Kreis mit einem Rechteck vereinige, dann werden beide Formen zu einem Pfad. Ihre ursprüngliche Natur geht dabei verloren und sie lassen sich auch nicht mehr ohne weiteres trennen oder auch nur in ihren Parametern verändern, es sei denn ich bearbeite die Knoten des Pfades manuell.
Eine andere Sache ist das Koordinatensystem. Zumindest bei Pfaden gibt es sowohl absolute als auch relative Angaben. Und Inkscape nutzt dynamisch, was gerade opportun ist: Ist der Pfad am Ursprung <0,0> definiert, sind es absolute, ansonsten zumeist relative Werte. Aber eben auch nicht immer. Manchmal wechselt Inkscape da auch einfach innerhalb eines Pfades. Tatsächlich kann ich keinerlei Grund für die Existenz absoluter Werte erkennen außer für den Startpunkt.
Ein Workaround wäre es vielleicht, alle Objekte in eine (eigene) Gruppe zu stecken. Denn gruppierte Objekte werden nicht mehr weiter angefasst bei Transformationen. Stattdessen erhält das Gruppenobjekt alle Transformationen wie Skalierungen und Translationen. Denn natürlich gibt es mehr als einen Weg, Objekten ihren endgültigen Ort zuzuweisen.
Eine zusätzliche Herausforderung sind die Farb-Definitionen (hier mal als Sammelbegriff für alles, was mit Konturfarben und Füllfarben zu tun hat). Ich weiß nicht, ob SVG das so erfordert, aber Inkscape macht es so: Alle komplexeren Farbinformationen wie Farbverläufe oder Filter werden nur im style-Attribut referenziert. Ihre tatsächliche Definition liegt in einem speziellen defs-Element. Und natürlich haben Verläufe absolute statt objekt-relativer Koordinaten. Wenn ich also programmatisch ein Element irgendwo hinsetze, dann muss ich auch seine referenzierten Definitionen entsprechend transformieren.
Die Probleme, die ich mit SVG habe (und ich bin eigentlich ein SVG-Fan, seit ich erstmals von SVG gehört habe), beruhen teilweise auf dem Format, teilweise auf Inkscape, was ich zur Erstellung nutze. Um SVG sinnvoll in einem programmatischen Kontext nutzen zu können, müssen allen Elementen id-Attribute zugewiesen werden, aber Inkscape erzeugt die für viele Elemente automatisch und erlaubt nur bei einer Teilmenge die manuelle Änderung der id. Aus einer Usability-Perspektive kann ich das nachvollziehen, zwingt mich jetzt aber dazu, entweder das erzeugte SVG komplett zu überarbeiten oder aber mir SVG-Fragmente aus meinem SVG zu nehmen und sie programmatisch erneut zu erzeugen, aber mit selbst definierten id-Attributen.
Und letzteres mache ich gerade für das D&D-Overlay. Vorbereitend erstelle ich das Gerüst nochmal sauber mit am Ursprung verankerten Koordinaten, ebenso alle Teilstücke. Dann entnehme ich die Teilstücke der SVG-Datei und füge sie in ein Pythonskript und vergebe id's vom Format "rangNzauberplatzM" als Präfix vor den drei Kreisen, aus denen die "Kugeln" bestehen. Am Ende ist das hoffentlich nur noch ein großes Puzzle, das ich wieder zusammensetzen muss. Wenn die Elemente und ihre referenzierten Definitionen alle am Ursprung entworfen sind, kann ich mittels einer abschließenden Transformation alles dorthin setzen, wo ich es brauche. Inkscape unterstützt solch einen Workflow leider nur mäßig. Andererseits kann ich mich ja auch dazu zwingen, alles einzeln in Inkscape zu entwerfen und erst am Ende zusammenzusetzen, wie ich es ja auch gerade tue.
Meine Erfahrungen mit Microsoft 365
Ich arbeite jetzt ja seit fast einem Jahr mit Microsoft 365 (alt: Office 365). Davor durfte ich bei Wikimedia Deutschland mit der G Suite (alt: Google Apps) arbeiten.
Ich bin ja durchaus ein Freund von Desktop-Clients, aber die Microsoft-Produkte haben mich das letzte Mal so um 2005 herum beeindruckt. Danach fiel es mir echt schwer, den Mehrwert für Microsoft Office zu erkennen. Es mag Einzelfälle geben, aber auf die stoße ich nicht.
Das Refaktorisieren und Reformatieren großer Textdokumente mache ich 1000 Mal lieber in Writer als in Word. Fairerweise gebe ich zu, dass Word die Anzeige benutzter Formatierungen besser gelöst hat. Aber wenn ich sowieso nur mit Formatvorlagen arbeite, brauche ich das auch nicht. Das lohnt sich spätestens dann, wenn ich beschließe, dass bestimmte Textabschnitte doch nicht mit der einen, sondern mit der anderen Schriftart setzen will.
Aber das war gar nicht die Auslöserin dieses Beitrags, sondern Outlook. Der Vergleich wird jetzt unfair. Während meiner Arbeit mit der G Suite habe ich lieber mit Thunderbird als mit der Gmail-Web-Anwendung gearbeitet, aber wenn ich etwas in meinen Mails gesucht habe, bin ich doch oft zu Gmail gegangen. Denn wenn Google eine Sache gut kann, dann suchen. Mittlerweile weiß ich auch, dass ich all meine Suchen auch in Thunderbird hätte ordentlich durchführen können (Schnellsuche ist nicht Suche ist nicht erweiterte Suche, und letztere habe ich nicht wahrgenommen, weil mittlere den Eindruck erweckte, das Beste in Sachen Suche bei Thunderbird zu sein). Aber was Outlook hier abliefert, ist einfach nur peinlich.
Will ich in Thunderbird alle ungelesenen E-Mails anzeigen lassen, dann klicke ich einfach "ungelesen" in der Schnellsuche an. Und schwupps werden mir in der Nachrichtenliste nur die ungelesenen Nachrichten angezeigt. Bei Outlook vermute ich hinter "Filter" eigentlich eine ähnliche Funktion. Wähle ich dort jedoch "ungelesen" aus, werden mir nicht meine 6 ungelesenen Nachrichten angezeigt, von denen ich die Hälfte sogar noch in der ungefilterten Ansicht sehen kann, sondern: gar keine!
Nach einem Neustart von Outlook funktioniert es dann aber doch. Sorry, aber das ist einfach nur Müll.
Über die Unterschiede von Microsoft 365 und der G Suite werde ich ein anderes Mal schreiben. So viel vorweg: Der einzige Grund für Microsoft 365 dürften die Office-Lizenzen sein.
Und damit mir nicht unterstellt wird, ich würde ja Microsoft nur hassen: Visio ist super. Ich habe noch nichts Vergleichbares finden können. Jedes Mal, wenn ich Diagramm machen will, denke ich wehmütig an meine Arbeit mit Visio zurück. Glücklicherweise sind Diagramme bei mir nicht an der Tagesordnung.
Mediale Teilhabe
Ich erinnere mich, in der Anfangszeit des Webs nutzten meine Freund*innen und ich intensiv E-Mail, um uns gegenseitig aufmerksam zu machen auf interessante Artikel und Links. Jede*r von uns hatte andere Interessen, Schwerpunkte und Aufmerksamkeiten, so dass der E-Mail-Verteiler mit einem bunten Mix an an lustigen, spannenden, nachdenklichen, empörenden Links gefüllt war.
Das war noch vor der ersten Dotcom-Blase. RSS-Feeds waren gerade erst erfunden und der breiten Masse noch nicht bekannt (heute hingegen sind sie der breiten Masse nicht mehr bekannt. Der breiten Masse waren sie ungefähr am 29. Februar 2010 bekannt). Viele Medien im Web waren genuine Web-Medien, ohne große Historie in der physischen Welt. Blogs hießen noch Weblogs und wurden in Nepal in Handarbeit hergestellt. Wikis waren abgekürzte Wikinger. Es war die gute alte Zeit.
Mit der Zeit drängten immer mehr Medien ins Netz. Immer mehr Leute kamen auf die Idee, Geschäftskonzepte mit Web-Inhalten zu verbinden. Ehrlich: Ich habe keine Ahnung, wie Internetcompanys in den Nuller-Jahren ihr Geld verdient haben, wenn sie nicht Amazon oder Ebay hießen. Facebook und Twitter hatten beide kein Konzept, aber die Investoren überschütteten sie mit Geld.
Ich pflegte meine Sammlung an RSS-Feeds. Ich hatte für den Desktop RSS-Reader, deren Namen ich längst vergessen habe, Liferea[1] oder Feedreader[1]. Und so wäre es vermutlich weiter gegangen, hätte nicht das mobile Internet dank Apples iPhone eingesetzt, denn auf einmal wollte ich auch mobil meine Feeds lesen. Für Palms Pre gab es den Tea-Reader[#RSS], derr gut mit dem Google Reader klarkam. Ich zog meine RSS-Feed-Sammlung zum Google Reader um, der dann aber Google Plänen zur Weltherrschaft vermittels Google+ zum Opfer fiel. Aber für einige Zeit konnte ich meine Feeds an verschiedenen Geräten lesen, der Lesestatus wurde dank Google Reader auf allen Geräten synchron gehalten. Vorher hatte ich mitunter 300 ungelesene Einträge auf meinem Desktop, die ich alle schon am Laptop gelesen hatte (als gelesen markiert, natürlich; ich lese ja nur den Teil, wo Titel und Anrisstext interessant klingen).
Google hob Google+ aus der Taufe, weil Facebook die Aufmerksamkeit seiner Nutzer*innen länger und häufiger binden konnte als Google. Google brauchte aber auch diese knappe Ressource, denn damit machen sie Geld. Für Facebook optimiert gab es dann Inhalte von Firmen, deren einziger Zweck es war, die Aufmerksamkeit der Nutzer*innen einzufangen, Buzzfeed, HuffPost und zahlreiche andere. Immer mehr Aufmerksamkeit fiel unter die Ägide vom Gatekeeper Facebook (und im geringeren Maße Twitter). Immer mehr Inhaltslieferanten boten ihre Inhalte auf Facebook feil, im steten Kampf um die Aufmerksamkeit der Nutzer*innen.
Ich habe mit der Einstellung des Google Readers meine RSS-Feed-Sammlung erst zu Feedly verschoben (lief gut), dann aber beschlossen, Tiny Tiny RSS selbst zu hosten (der Entwickler ist anstrengend, arrogant und teilweise geschichtsvergessen, aber die Software tut, was sie soll). Ich nehme gelegentlich Änderungen an der Zusammenstellung meiner Feeds vor, aber ich habe ansonsten eine relativ stabile Quelle an Quellen.
Angefeuert von der Aufmerksamkeitsökonomie in den sozialen Netzwerken verfielen immer mehr Anbieter auf kleine Informationshäppchen. Sicher spielte auch die Schwierigkeit der Monetarisierung von einzelnen Inhalten eine Rolle, im Endeffekt war es aber das gleiche: Viele kleine Beiträge, die möglichst hohe Reichweite erreichen mussten. Meine RSS-Feeds wurden voller und voller, die Abarbeitung der ungelesenen Beiträge wurde tatsächlich Arbeit von mehreren Stunden täglich. In den sozialen Netzwerken hingegen wird algorithmisch gesteuert die Aufmerksamkeit der Nutzer*innen so weit wie möglich angezapft mit Beiträgen, die ein höchstmögliches Potential an engagement besitzen, also der Eigenschaft, die Leser*innen zur Interaktion mit der Plattform zu bewegen. Bestimmt sitzen in den Firmen hochbezahlte und studierte Fachkräfte, die ganz eigene dafür Metriken haben.
Für die breite Masse aber war der algorithmisch gesteuerte Zugang ein Segen, erlaubte er es ihnen doch, an Nachrichten[2] zu kommen, die sie sonst nie erreicht hätten. Und natürlich wurde munter geteilt, was einen am meisten bewegt hat. Skandale, tatsächliche und erfundene, sind dafür hervorragend geeignet. Und in der algorithmisch befeuerten Newsfeed-Welt gibt es ständig Futter für Skandalsucht.
Ich denke, da draußen gibt es gar nicht wenige Menschen, die sich schon von Jugend an aus dem frei verfügbaren Nachrichtenangebot ausgeklinkt haben, da sie ihre Informationen aus ihrem persönlichen sozialen, digitalen Umfeld beziehen, ohne Chance auf ein Korrektiv, weil Korrektive nicht emotionalisieren, sondern moderieren, aber Mäßigung fühlt sich halt ein bisschen an wie Tod, während Emotion sich wie Leben anfühlt. Sie befinden sich in Kreisen, deren Quellen algorithmisch zusammengestellt sind auf Basis von Automatismen, die nicht breite Information zum Ziel haben, sondern Bindung an die Plattformen. Es war nur folgerichtig, dass Facebook WhatsApp gekauft hat, denn die Dynamik zwischen algorithmischen Newsfeed bei Facebook und persönlicher Empfehlung via Messenger wird Facebook nicht entgangen sein.
Meine mediale Teilhabe ist eine, der darauf beruht, dass ich das technische Wissen habe, um mir meine Infrastruktur aufrechtzuerhalten. Das ist kein Modell für die Masse. Ein Modell wäre der tägliche Besuch vereinzelter Medienangebote, also das digitale Äquivalent zum Blättern in der Tageszeitung, aber dabei sollte man im Hinterkopf behalten, dass die Bild über Jahrzehnte die auflagenstärkste Tageszeitung war. Dass ihre Auflage rückgängig ist, liegt nicht daran, dass die Ansprüche der Leser*innen gewachsen sind, sondern dass der Bild Konkurrenz im Web erwachsen ist, der sie nicht gewachsen ist. Facebook, und später auch Twitter, haben sich vom Konzept ungefilterter Newsfeeds verabschiedet, aber sie stellen das Modell dar, das den größten Erfolg hat. Es ist niedrigschwellig genug, dass auch ohne Technikkompetenz medial teilgehabt werden kann.
Ich bin sicher, mein Gedankenfluss hatte so manchen Sprung, manches hätte mehr Ausarbeitung verdient, aber ich bin es erst einmal los. Danke für die Aufmerksamkeit.
ufw: unnecessary firewall
Ach!, Canonical!
Die Leutchen von Big Blue Button haben sich auf Ubuntu als Grundlage ihrer Software entschieden. Das ist ihr gutes Recht, auch wenn ich anders entschieden hätte. Leider machen sie aber auch Gebrauch von Canonicals Eigenentwicklung, der ufw, der uncomplicated firewall. Die ufw ist nicht wirklich eine Firewall, sondern vielmehr ein Frontend für iptables und ip6tables. Und ich hätte es auch nicht Frontend, sondern eher Wrapper genannt, aber die Unterschiede sind wohl eher marginal.
Tatsächlich nutzt ufw im Hintergrund ip(6)tables, um ihre Regeln umzusetzen. Dummerweise scheint sich der uncomplicated-Teil des Namens auch nur auf unkomplizierte Umgebungen zu beziehen. Schon Containern Zugriff auf das Internet zu gewähren, erfordert es ein tieferes Verständnis von der ufw zu erlangen. Und wenn die Container untereinander sprechen können sollen, dann scheint es ohne Kenntnis von iptables schon gar nicht mehr zu gehen.
iptables sind nicht schön. Sie sind geradezu hässlich. Und ich werde drei Kreuze machen, wenn nftables oder bpfilter iptables ersetzen. Aber noch hässlicher als iptables ist das Zusammenspiel von ufw + iptables. Ich sehe keinen Gewinn für den angehenden Admin, sich mit zwei sehr unterschiedlichen Syntaxen auseinanderzusetzen, wenn sich auch mit einer alles erreichen lässt, zumal dann keine Kenntnis über irgendwelche impliziten Maßnahmen der ufw notwendig sind. ufw hat wirklich nur dort einen Existenzgrund, wo so simple Konstellationen auftreten, dass sie auch mit wenigen iptables-Befehlen umzusetzen wären.
Ich bin jedenfalls kurz davor, die ufw zu deaktivieren und komplett auf iptables zu setzen.
Big Blue Button, ufw und container
Since a few weeks, I rented a server for running Big Blue Button. Besides Jitsi Meet, Big Blue Button is one of the most feature rich free software video conferencing solutions.
Also, Big Blue Button is a bolted mess of many components running barely in any other environment than the one the developers intended. Actually, it's barely running. 🙂
To be fair, there are a lot of components involved. And there aren't many developers having the necessary insights, so progress is slow. Until a few weeks ago BBB had to be run on Ubuntu 16.04 Xenial, but they now have their install script adapted to Ubuntu 18.04 Bionic. Well, we are in 2021 already and a lot of people expect to be able to install BBB on Ubuntu 20.04 Focal. But as I said, progress is slow.
As there are many components, the team strongly recommends to firewall the server. Everyone does that, doesn't they, mh? Well, they decided to use ufw for that. That wouldn't be a problem if I didn't have the idea to setup some additional containers on the machine to make it a little bit more useful.
When mentioning containers almost everyone thinks of docker containers but there are at least two more technologies available on Linux. The aptly named lxc (Linux Containers) and systemd's approach nspawn. As the whole world uses docker and one of my favourite (ex) colleagues prefers lxc I decided to have some fun with nspawn. But I guess many of the problems I had would also appear with lxc or docker.
Actually, BBB makes use of some docker containers so that might have increased my problems but I'm not sure about that as no solution or workaround needed touching their config. I guess, their presence just made my problems seem more complex than they actually were.
The symptoms I observed were simple: My containers didn't get any IP. They had no network connectivity.
The main culprit of course was ufw. BBB's default firewall rules only allow ssh, http, https and a range of ports needed for WebRTC. ufw blocked all traffic from the containers, including DHCP. So I needed to allow DHCP. I wrote an application profile for that but that's mostly unnecessary as we only need to open TCP ports 67 and 68.
ufw allow 67:68/tcp
And my containers got their IP addresses!
But they still couldn't do anything. Okay, I could ping other IP addresses.
ping 8.8.8.8
Call me spoiled, but I'd expect ICMP to be blocked if default policy is to reject. But hey, I was thankful to see that something works at least. But name resolution didn't work. Allowing port 53 analoguosly didn't help. I could tcpdump my packets not reaching the bridge interface. The solution was to allow forwarding packets to this port:
ufw route allow 53
And now, name resolution worked. I left out the steps inbetween (I changed the default forward policy and reset it afterwards). That means I could ping by providing a hostname. Progress! But I couldn't curl. Not only because I had to install the curl package but also because the only open ports for my containers were … let me count … oh, port 53.
ufw route allow 80,443/tcp
And now I can curl.
Of course, there's room for improvement. I could limit the rules to my container subnet or even to single containers. But this last idea is doomed to fail because of DHCP. So I could still limit the forwarding rules to my subnet. As they are only valid for forwarding and I want to forward only to my containers there doesn't seem to any benefit in adding more complexity.
I guess I got all the search terms into this entry I tried while searching for a solution to my problem without getting any concrete results. Maybe someone in the same situation as me might find this helpful.
Error: Assertion failed for PostgreSQL Cluster
If you ever encounter this error message
Assertion failed for PostgreSQL Cluster cluster-name
or
Assertion failed on job for postgresql@11-cluster-name.service
after creating a cluster of the name "cluster-name" it might be because somewhere the hyphen is considered invalid. Just
pg_dropcluster <version> cluster-name pg_createcluster <version> clustername
to drop and re-create the cluster without hyphen.
I created this blog entry because I could not find any reference to this specific error with this specific reason. It might be some Debian specific error as PostgreSQLs initdb command is wrapped by pg_createcluster which again isn't mentioned by PostgreSQL. Searching the web shows mostly results in context of Ubuntu and Debian.