onli blogging

Ich bin über ein Video gestolpert, in dem das Framework-Laptop näher gezeigt wird:

Das Framework-Laptop ist so modular, wie sie es hinbekommen haben. Das Gerät hat zuerst ein potentiell auswechselbares Mainboard, aufsteckbaren Ram und SSD, natürlich eine wechselbare Batterie.
Damit könnte ein guter Thinkpad jetzt fast noch mithalten. Aber mit den auswechselbaren Anschlüssen an der Seite nicht. Die sind nicht etwa fest eingebaut, sondern werden ebenfalls eingesteckt. Basierend auf USB-C kann so USB-C, USB-A, HDMI, Displayport, ein SD-Kartenleser und hoffentlich in Zukunft auch Ethernet frei gewählt werden. Und sogar Speicherplatz mit 250GB oder 1TB kann statt einem Anschluss eingebaut werden. USB-C 3.2 ist dafür schnell genug, wer mehr Speicherplatz haben will ohne den Aufpreis für extra-große SSDs zu bezahlen, für den ist das eine tolle Option.

Leider sind es nur vier Seitenanschlüsse, aber es ist auch nur ein 13.5"-Gerät. Es ist schade, dass der Prozessor nicht in einem Sockel sitzt, wie es früher auch bei Laptops üblich war. Bei dem R50 konnte ich noch den Prozessor wechseln, was ein nettes Upgrade war. Aber vielleicht war das mit Intels modernen Laptopprozessoren nicht mehr möglich. Dass es generell nur Intel-Prozessoren sind ist ebenfalls schade, AMD-Prozessoren sind auch für Laptops derzeit stärker. Und die farbigen Monitor-Bezels, die auf der Webseite z.B. in Orange zu sehen sind, gibt es noch nicht.

Sollte ich derzeit einen Laptop brauchen würde ich angesichts des regulären Preis vorher auch bestätigt haben wollen, dass Kühlung, Monitor, Tastatur und Touchpad so gut sind wie sie auf den ersten Blick wirken. Aber im Zweifel käme der hier ganz oben auf die Liste – vielleicht neben das günstige Pinebook Pro, falls auch ein schwächerer Laptop ausreichen würde. Ich finde das Konzept toll.

Man kann das Gerät in den USA und Kanada bereits vorbestellen, weitere Länder sollen später dieses Jahr folgen, wobei dann auch Deutschland dabei sein müsste. Die Webseite lässt bei der DIY-Version auch wirklich recht frei auswählen, welche Bestandteile sie liefern sollen und welche man selbst kauft. Inklusive des Betriebssystems, als Linuxer kann also der Preis für Windows gespart werden, den andere Kunden voll zahlen – so soll es sein.

Unepic ist ein 2D-Platformer-RPG von 2011. Viele von euch könnten es durch diverse Bundles schon in der Sammlung haben. Wer es aber wie ich bisher ignoriert hat darf sich freuen, denn es nachzuholen ist ziemlich spaßig.

Plötzlich Computerspielfigur

In Unepic spielt ihr Daniel, der eben noch auf dem Klo saß und plötzlich in der Spielwelt aufwacht. In diesem Schloss wird er direkt von einem körperübernehmenden Schattenwesen angegriffen, das aber mit Erschrecken feststellt, den jungen Mann nicht kontrollieren und seinem Körper auch nicht entfliehen zu können. Die Rolle des Begleiters ist damit besetzt, wobei das Schattenwesen wenig hilfreich an einem schnellen Ableben des Spielers interessiert ist.

Es gilt, Abschnitt für Abschnitt das Schloss zu erkunden. Überall lauern Gegner. Sie zu erledigen bringt Erfahrung, bei einem Levelaufstieg können die Fähigkeiten Daniels erhöht werden. Zum einen sind das die Waffenfähigkeiten, jede Waffengattung hat ihre eigene Stufe und man sollte sich spezialisieren. Dazu kommen Konstitution, das Brauen von Tränken und das Tragen von Rüstungen, was jeweils mehr Tränke bzw Rüstungen aktivierbar macht. Nach einer Weile stolpert Daniel zudem über Magie, z.B. Feuer- oder Schutzmagie, was ebenfalls gesteigert werden kann und ihn dann zusätzliche Zaubersprüche wirken lässt.

Spielinhalt: Mehr als Humor

Das Schloss ist eigentlich keins – die Abschnitte sind zu divers, so kommt man ziemlich direkt am Anfang in eine Mine. Aber es gibt Wächter, große Monster die einmal besiegt Schlüssel fallen lassen, mit denen dann der nächste Abschnitt geöffnet werden kann. Sie zu besiegen ist oft Knobelarbeit. Wie besteht man zum Beispiel gegen ein fliegendes Gehirn, das Daniel dazu bringt alle Tränke im Inventar auszukippen, während dessen er blockiert ist und kontinuierlich Schaden nimmt? Aber auch außerhalb der Bossgegner gibt es viele kleine Rätsel zu lösen und Tricks herauszufinden. Dazu kommen Nebenquests, die von teil sehr merkwürdigen Charakteren vergeben werden.

Denn das ist eine des Besonderheiten dieses Spiels: Unepic nimmt sich nicht besonders ernst. Oder zumindest pflegt es einen Humor, den das Spiel selbst als nerdig bezeichnet. So ist Daniel sehr lange davon überzeugt, dass er in einem Drogentrip festhängt und nichts was er erlebt echt ist, entsprechend reißt er Sprüche und scheint lange nur durch seinen distanzierten Übermut weiterzukommen.

Fazit: Mehr als erst sichtbar

Unepic hat minimale Hardwareanforderungen und ist damit ein guter Kandidat, falls man keine dedizierte Grafikkarte besitzt und trotzdem etwas spielen will. Die 2D-Grafik ist weit entfernt von einem Hollow Knight (und auch die Atmosphäre reicht nicht an diese schwerere Alternative heran), aber sie funktioniert und ist – anders als so mancher Pixellook – nicht abschreckend. Die Steuerung ist das schon eher. Bei mir funktionierte die im Menü aktivierbare Controllersteuerung gar nicht, aber das Interface ist sowieso 100% auf Bedienung per Tastatur ausgelegt. Das liegt mir bei diesem Genre nicht, aber bei Unepic man kann sich in die Tastatursteuerung reinfinden.

Das Spiel mag im ersten Moment so wirken als wäre es zu sperrig. Doch Unepic entpuppt sich dann als ein ziemlich solider Genrevertreter, der anfangs abgesehen von der Steuerung eher simpel ist, dann im Spielverlauf mit Leveldesign, Items und den Magiesystemen sich ausbaut. Der Ton des Spiels mag humorig sein, aber der Spielinhalt ist völlig ernst und auch die Story wird gut erzählt. Empfehlenswert.

Nach dem Artikel mit dem Gource-Video habe ich mich gefragt, welchen Effekt es für diesen Blog und seinen Bandbreitenhunger hat wenn ich hier Videos hoste.

Das Gource-Video war 77MB groß. Ich schrieb noch im Artikel, dass das für zweieinhalb Minuten zu viel ist. Aber Im Vergleich zu was sonst so im Internet oft auf Seiten sitzt ist das ja winzig. Es kleiner zu kriegen hatte mich zwar interessiert und meine Versuche dazu waren daher Teil des Artikelinhalts, aber das war technische Neugier, keine gefühlte Notwendigkeit. Sieht man so ein Video eines bisher kommentarlosen Artikels überhaupt in der Bandbreitennutzung dieses Blogs?

Tatsächlich tut man das sehr deutlich. Zwischen dem Server und dem Internet sitzt Cloudflare. Cloudflare misst den Trafficverbrauch und zeichnete mir diesen Graphen:

Das simple Video verzehnfachte den Verbrauch, von normalerweise etwa 400MB auf 4GB.

Kurioserweise sieht vultr, der Hoster des Blogs, ganz andere Werte. Auch bei dessen Messung ist eine deutliche Trafficspitze zu sehen:

Aber die Zahlen sind deutlich geringer.

Ich kann den Unterschied nicht erklären. Cloudflare wirkt zwar auch als Cache. Aber den Daten zufolge ist das Video nicht richtig von Cloudflares Cache aufgegriffen worden, die Cachenutzung war nur minimal erhöht:

Wo sind die restlichen Gigabyte geblieben?

Trotz des Unterschieds zeigen die Graphen welchen enormen Effekt es haben kann, Videos im Blog hochzuladen. Bei meinem Inklusivtraffic ist da zwar noch viel Luft bis zur Grenze, ab der ich dann draufzahlen müsste. Aber sie scheint erreichbar. Wäre der Eintrag beliebter gewesen und mehr geteilt worden wäre auch das Video öfter heruntergeladen worden. Und dann will man das vielleicht nicht nur einmal machen, sondern veröffentlicht mehrmals im Monat ein neues Video. Bei Bloggern mit generell mehr Besuchern würde so der Trafficbedarf auch mit der regulären Besucherzahl ein Thema werden. Bei Videos im Blog lohnt sich also schnell ein Hostingpaket mit mehr freiem Trafficverbrauch.

Oder man packt es eben einfach auf YouTube oder PeerTube. Was ich bewusst nicht getan hatte: Bei beiden ist das ewige Fortbestehen des Videos nicht gerade sicher. Aber bei mehr Besuchern und mehr oder größeren Videos überwöge schnell der Nutzen dieses Bedenken.

Wenn mehrere YouTube-Videos auf einer Seite landen wird diese ziemlich schwer. Zumindest, wenn man den Einbindungscode nutzt den YouTube selbst vorschlägt. Da das hier im Blog schnell mal passiert, so wie jetzt, da mehrere Artikel mit Videos auf der Hauptseite sind, habe ich mich nach Alternativen umgesehen.

Normalerweise sieht das Iframe so aus:

<iframe width="560" height="315" src="https://www.youtube.com/embed/XhG-4zdVx0I" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Auf den ersten Blick harmlos. Das Problem ist all das Javascript, das in diesem Iframe dann bezogen wird. Was sofort geschieht, da nach dem Laden die Iframe-Zielseite sofort den Player initialisiert.

Auf dev.to schlug Arthur vor, stattdessen ein alternatives Iframe zu nutzen:

<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/XhG-4zdVx0I"
srcdoc="<style>*{padding:0;margin:0;overflow:hidden}html,body{height:100%}img,span{position:absolute;width:100%;top:0;bottom:0;margin:auto}span{height:1.5em;text-align:center;font:48px/1.5 sans-serif;color:white;text-shadow:0 0 0.5em black}</style><a href=https://www.youtube.com/embed/XhG-4zdVx0I ?autoplay=1><img src=https://img.youtube.com/vi/XhG-4zdVx0I/hqdefault.jpg><span>▶</span></a>"
frameborder="0"
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
></iframe>

Das ist schon von mir leicht verändert und der Artikel beschreibt verschiedene Zwischenschritte auf dem Weg zu dieser Lösung. Schaut euch das ruhig im Originalartikel an.

Aber die Kernidee ist, dass in dem Iframe der Videoplayer erst nach einem Klick auf das Vorschaubild geladen werden wird. Statt einem halben MB an Code ein kleines Bildchen zu laden geht beim ersten Laden der Seite wesentlich schneller. Und da das Video nach einem Klick wie zuvor sofort startet, dank dem autoplay=1, wird dem Seitenbesucher der Unterschied kaum auffallen. Denn das ist das Ergebnis:

Einfluss auf die Seitenperformance

Ich stolperte über diese Baustelle, als ich die neue Version Googles Pagespeed testete. Beim Prüfen dieses Blogs hier erschrak ich über das miserable Ergebnis:

Gut, die Mobilvariante des Tools ist häufig sehr hart, aber so schlecht hatte ich meinen Blog nicht gesehen. Ein Blick auf die Problemliste zeigte dann deutlich, dass Youtube-Videos die Ursache sind:

Was schlicht daran liegt, dass derzeit mehrere Artikel mit Videos von Youtube hier auf der Startseite sind.

So sieht das Ergebnis jetzt aus, da alle diese Videos mit den neuen Iframes ersetzt sind:

Viel besser! Sogar für Telefone wird die Geschwindigkeit der Seite als hervorragend bewertet. Wie es bei einem einfachen Blog ja auch sein soll.

Serendipity-Plugin

Ich wollte die regulären Iframes nicht per Hand ersetzen. Und generell wollte ich den originalen Code beibehalten. Ich gehe davon aus, dass die Kompatibilität mit dem derzeitigen Einbindungscode fast für ewig erhalten bleiben wird. Während bei dem angepassten Iframe Annahmen drin sind die sich ändern könnten, vor allem der Pfad zum Vorschaubild.

Deswegen habe ich ein Plugin geschrieben, das die normalen Iframes umwandelt. Der Blogger schreibt also ganz normal seinen Artikel, bezieht den normalen Einbettungscode von Youtube, und das Plugin serendipity_event_lazyoutube wandelt dann automatisch diesen Code von Youtubes lahmen Standard-Iframe zu der hier gezeigten schnellen Alternative um, die den Videoplayer erst nach einem Klick auf das Vorschaubild lädt.

Außerdem kann man damit, angelehnt an oEmbeds, den Einbettungscode vom Plugin erstellen lassen – falls einem das Bewahren des Original-Iframes im Artikelquellcode nicht so wichtig ist. Statt dafür nur einen Link zu setzen geht das mit [Youtube-Link], also [https://www.youtube.com/watch?v=XhG-4zdVx0I] für das Video von oben.

Nur damit der zu erstellende Code einfacher zu erzeugen ist habe ich oben auch das Iframe angepasst. Im Original ist da noch an zwei Stellen der Titel des Videos drin. Aber um den abzufragen müssen wir mit der Youtube-API arbeiten oder den Artikelschreiber das eintragen lassen, beides wollte ich vermeiden.

Das Plugin ist ganz frisch und es fehlt mindestens noch der Versuch, gewählte Anfangszeiten zu unterstützen. Deshalb liegt es bisher nur in einem eigenen Github-Repo. Hier im Blog ist es aber schon aktiv und Tester wären mir hochwillkommen.

Drüben bei gnulinux.ch bin ich über Gource gestolpert. Gource braucht man nur ein Git-Repository zu geben, damit es aus der der dort gespeicherten Aufzeichung ein Video mit einer Visualisierung der Entwicklung erstellt. Tatsächlich kannte ich die Visualisierung aus einem Youtubevideo, aber ich hatte keine Ahnung, dass sie mit frei verfügbarer Linxusoftware erstellt wurde. Und mir gefiel die Konfiguration der Darstellung, die im Artikel vorgeschlagen wird.

Das ist die nicht ganz komplette Entwicklung von Serendipity:

Ich finde es toll zu sehen, wie viele Entwickler da am Wirken waren und wie Garvin von der Software ins Zentrum gestellt wird. Und natürlich bereitet es ganz besonders Freude, wenn der eigene Name auftaucht und den Dateibaum verändern beginnt.

So ein Video zu erstellen ist einfach. Gource war auch bei Void Linux in den Quellen. Einmal installiert, muss nur das Git-Verzeichnis erstellt, darein gewechselt, Gource gestartet und die Ausgabe an FFmpeg übergeben werden:

git clone git@github.com:s9y/Serendipity.git Serendipity.git
cd Serendipity.git
gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 18 gource.mp4

Tatsächlich habe ich aber viel Zeit in den Versuch versenkt, das zu optimieren. Ich wollte FFmpeg statt .mp4 erst .ogv und dann .webm mit VP9 erstellen lassen. Denn das mit H.264 gebaute und oben eingebundene .mp4 ist immerhin 77 MB groß.

Übrigens das erste mal seit langer Zeit, dass ich mir einen stärkeren Prozessor gewünscht habe. Videos zu enkodieren ist einfach heftig. Aber auch beeindruckend, dass die 4GB große .ppm problemlos auf unter 100MB gebracht werden kann.

Beim Versuch, eine kleinere Datei als die obige für diesen Artikel zu erhalten, orientierte ich mich an der Dokumentation von FFmpeg und den Hinweisen von Google. Aber die Videos waren entweder größer oder mit mehr sichtbaren Kompressionsartefakten. Und das selbst bei der Two-Pass-Enkodierung, die ich so versuchte:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o gource.ppm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 1 -row-mt 1 -an gourceq37.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -c:v libvpx-vp9 -b:v 0 -crf 37 -pass 2 -row-mt 1 -an gourceq37.webm

Das produzierte relativ große Dateien (hier 130MB), während die Google-Vorgaben sehr kleine (22MB), aber deutlich sichtbar komprimierte Videos erstellten:

ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4-y gource_google.webm
ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vf scale=1280x720 -b:v 1800k -minrate 900k -maxrate 2610k -tile-columns 2 -g 240 -threads 4 -quality good -crf 32 -c:v libvpx-vp9 -an -pass 2 -speed 4 gource_google.webm

Kein guter Startpunkt.

Die Single-Pass-Kodierung ist laut der Dokumentation nicht empfohlen, und tatsächlich lässt sich mit ihr zwar etwa die gleiche Größe erreichen:

gource -1280x720 --date-format %Y-%m-%d --seconds-per-day 0.025 --auto-skip-seconds 0.05 --no-time-travel --stop-at-end --highlight-users --max-user-speed 125 -r 30 -o - | ffmpeg -y -r 30 -f image2pipe -vcodec ppm -i - -vcodec libvpx-vp9  -preset medium -pix_fmt yuv420p -crf 30 -row-mt 1 gource.webm

Aber das Video sieht ein bisschen schlechter aus. Und mit schlechterer Qualitätsstufe (hier 35) leidet die Darstellung dann deutlich:

Wenn ich mir die Dateigrößen und die Qualität von ja oft deutlich längeren Youtube-Videos anschaue glaube ich, dass das besser gehen müsste.

Kommt VP9 generell schlecht mit dem Blur zurecht? Oder ist der Kodierer in FFmpeg subobtimal? Gibt es doch einen Weg, die Komprimierung des .mp4-Video bei visuell gleicher Qualität zu schlagen?

The Umbrella Academy ist eine Netflix-Serie. Mit relativ guten Kritiken ein Kandidat für die nächste Serie im Abendprogramm. Also schaue ich gerade die ersten Folgen.

Sie sind überraschend schwach.

So einen lahmen Serienstart habe ich lange nicht gesehen. Die Charaktere sind unsympathisch – weil sich unentwegt anfeindend –, nichts passiert, alles ist grau und braun. Man muss sich nur mal diese Szene anschauen, in der die unerträglich vor sich hinmurmelnde Vanya nochmehr angefeindet werden wird. Seit wann sind Badezimmer mit Schminkspiegel beleuchtet wie dunkelste Kellerräume? Und was passiert ist emotional genauso ansprechend wie die Inszenierung auch aussieht.

Und während die Männer sich mittlerweile in Bewegung setzen die Welt zu retten, haben die Frauen eine Beziehungsgeschichte aufzulösen. Muss das wirklich so sein?

Trotz allem: Ganz langsam wird eine Hintergrundgeschichte angedeutet die interessant klingt. Toter Vater starb wohl nicht einfach so, Apokalypse ist nächste Woche. Aber besonders, dass das letzte Thema im Raum steht und die Charaktere daraufhin bisher praktisch gar nichts machen ist bei ansonsten sowieso einschläfernden Serienfolgen unfassbar.

Man vergleiche das mit dem Anfang von Crazy Ex-Girlfriend, der sprechenden Butter und all der Interesse weckenden Verrücktheit im ersten Musicalsong. Klar, nicht das gleiche Genre – aber ich meine nur den Ansatz, in der ersten Folge Interesse wecken zu wollen vs die ersten Folgen es nichtmal wirklich zu versuchen.

Dass ich der Umbrella Academy noch etwas Zeit einräume liegt nur an den Bewertungen, denen zufolge die Serie deutlich besser wird. Auch bei den Tomaten wird die zweite Staffel viel stärker eingeschätzt. Vielleicht findet sich die Serie also noch. Aber sie müsste sich extrem steigern. Warnt mich bitte, wenn das nicht so ist und die Serie im Grunde so weitergeht.

Kleine Wasserstandsmeldung aus gegebenem Anlass.

Die Arbeit, um Serendipity mit PHP 8 kompatibel zu machen, ist noch nicht fertig. Aber sie ist weit vorangeschritten. Ich habe mittlerweile alle Backend- und Frontendfunktionen getestet und fast alle mit Standardtheme und vorinstallierten Plugins zum Laufen gebracht.

Ein wichtiger noch fehlender Baustein waren die Trackbacks. Die Kommentare bei Dirks Bloggeburtstag waren sicher der Anlass sie jetzt zu testen, auch wenn mir das gestern Abend gar nicht bewusst war. Es war eine Erinnerung, deretwegen ich den Test vorzog, an die ich in dem Moment nicht mehr direkt dachte. Ihr kennt das bestimmt.

Tatsächlich waren die Trackbacks kaputt. Die Korrekturen sind größtenteils Kleinigkeiten. Auf einem Server, der Warnungen verschluckt, würde wahrscheinlich auch jetzt schon alles laufen. Aber die Warnungen zu reparieren kann der Codequalität nur dienen und Warnungen werden eben nicht immer ausgeblendet, was dann Funktionen kaputtmachen kann.

Bei den Trackbacks speziell ist, dass der Browser ja gar keine Daten sendet. Das machen die Server unter sich aus, was im Zweifel schwer zu beobachten ist. Wir haben Logs, aber die zeigen bei PHP-Fehlern nur wo der Empfang abbricht. Um das richtig zu debuggen sendete ich den Trackback stattdessen mit curl:

curl -X POST -d 'type=trackback&entry_id=16&url=https://example.com/s9y_dev/index.php?/archives/19-trackbacktest-2.html&title=trackbacktest 2&blog_name=John Doe personal blog&excerpt=link2' https://example.com/s9y_dev/comment.php

So waren die Fehler schnell sichtbar und relativ einfach zu reparieren.

Es fehlt, das gleiche mit Pingbacks (ggf. via Wordpress) zu testen. Ansonsten müssten noch die restlichen Plugins und Themes durchgegangen werden. Ich habe mir vorgenommen, die mitgelieferten Plugins, die populären in Spartacus und die modernen Themes tatsächlich noch selbst anzusehen. Damit müsste eine PHP-8-kompatible Beta dann in Reichweite sein, wobei gerade die Plugins selbst bei Beschränkung auf die populäreren noch ein ziemlicher Brocken sein könnten.

Der animierte Film steckt voller Details, ist lustig und wird hochgelobt. Das Cinemawins-Video ist noch positiver als sonst, aber das sah ich nach dem Film, vorher war diese Einschätzung von ben_, die mich auch dazu bewog den Film anzusehen.

Mir hat er nicht gefallen.

Ja, oft witzig, technisch gut gemacht und voller Details. Aber er verlor mich, diesmal sogar uns beide, gegen Ende. Weil das Familienthema überbetont und tausendfach wiederholt wird. Da wird nicht einmal Vater und Tochter miteinander versöhnt, es passiert viermal und es nervt. Selbst die Stimme der Tochter wird unerträglich in diesen Momenten, dieses aufgesetzte "Ich spreche jetzt ruhig, weise und erwachsen".

Gut, ist es eben ein Film für Kinder. Aber eigentlich ist er dafür zu voll mit Kram, mit dem Kinder nichts anfangen können. Wie es eben so oft ist: Als Familienfilm soll er alle ansprechen, und wenn solche Filme gut sind kann man sie auch ganz ohne Nachwuchs sehen (Jumanji z.B.). Auch der Mitchells-Film hätte bis etwa zum letzten Drittel tatsächlich kein absoluter Kinderfilm sein müssen, wie ja auch Into the Spiderverse der gleichen Macher gut für Erwachsene geeignet war. Aber das Beharren aufs Wiederholen der Kleinkindemotionalität zerstört es – erklärbar nur mit dem Kinderfokus, alternativ halten die Filmmacher die Zuschauer für Idioten.

Bisschen schade. Denn wenn mit der gleichen Technik, Witz und Liebe zum visuellen Detail eine bessere Geschichte umgesetzt worden wäre hätte das echt ein guter Film werden können. Das Endspektakel eine Nummer kleiner machen um darauf achten zu können, dass die Geschichte in sich konsistent bleibt (wenn einmal etabliert ist wie stark ein Gegner ist wirft eine gute Story das nicht nach 10 Minuten um), und vor allem die Beziehungsebene mit einer einzigen Szene innerhalb der Handlung auflösen. Aber das ist leider nicht gelungen.

direkt

Bei meinem ersten Kontakt mit dem Pinetab funktionierte im Grunde noch nichts. Mein Fazit war entsprechend verhalten. So konnte ich mit dem Gerät wenig anfangen und mir auch nicht vorstellen, darauf oder dafür etwas zu entwickeln. Nach dem Artikel schaute ich ab und an mal nach Updates für Ubuntu Touch, aber da erschien nichts. Jetzt kam ich endlich dazu ein anderes Betriebssystem auszuprobieren und es ist wie von den Kommentatoren prophezeit: Das Pinetab steht gleich viel besser da.

postmarketOS als Rettung

Mein doch noch positiver Ersteindruck des Konzepts war mit der Zeit von der Unbrauchbarkeit der Software überlagert worden. Ohne den Blogartikel hätte ich ihn vergessen. Teilweise geht das nunmal fließend ineinander über: Wenn Youtube-Videos abzuspielen ruckelt, ist dann die Software schuld oder schlicht der Prozessor zu schwach? Im Fall des Pinetabs war die Software schuld, denn mit dem von postmarketOS (v21.03) bereitgestelltem Firefox funktioniert sowas. Wobei Firefox auch mit seiner besseren Performance und Adblocker generell das Internet nutzbar macht.

Plasmas Mobilvariante wirkt generell wie eine gute Oberfläche, aber es ist die Kombination mit postmarketOS und den zugänglichen Linuxprogrammen, die das Pinetab plötzlich wirklich brauchbar wirken lassen. Einen echten Editor zu haben ist Gold wert, dazu VLC und eben Firefox, schon ist das System nutzbar. Dazu kommt die nun funktionierende Tastatur. Wann immer die Toucheingabe zu nervig wird (was schnell passiert) wird eben die Tastatur angesteckt. Zusammen mit den Desktopprogrammen ist das Pinetab dann kein Tablet mehr, sondern ein kleiner Laptop. Das ist nicht nur nett, dafür könnte ich tatsächlich einen Nutzen haben.

Aktueller Eindruck der Hardware

Wird das Pinetab also ausschließlich von der Software zurückgehalten und ist ansonsten das perfekte Tablet/Laptopmischgerät? Nein, das nun auch nicht. Tablets sind für mich immer reine Multimediagerät gewesen (mit einer Ausnahme, als ich ein Notfallgerät für einen Urlaub brauchte), wofür das Pinetab sich nicht wirklich eignet, denn die Lautsprecher sind schlecht und zeigen nach hinten.

Zudem ist das Display an sich gut, aber die Displayhelligkeit etwas zu gering wenn sich die Sonne im Bildschirm blendet. Das schränkt die Nutzbarkeit als Multimediatablet noch weiter ein. Beides wird nicht durch Software gelöst werden können.

Bleibt der Laptopmodus. Hier könnten die beiden Hardwareschwächen eher ignoriert werden. Allerdings: So cool ich die Magnettastatur mit ihrem Faltständer auch finde, wabbelt sie beim Schreiben doch deutlich. Auch ist das Touchpad kein besonders gutes.

Das geht zur Not, ich könnte damit arbeiten, aber dass ich es nicht unbedingt ausprobieren will ist kein gutes Zeichen. Und ob die eingebaute Kamera nach Softwareupdates mal gut genug für eine Videokonferenz sein wird? Es fehlt auch schlicht ein Scharnier, um das Tabletlaptop zuklappen zu können, ohne das der obere Abschnitt auf die Tastatur kracht.

Dazu kommen generelle Qualitätsprobleme der in diesen Punkten dann prototypisch wirkenden Hardware. Wenn das Tablet aus ist will es manchmal nicht angehen, ich muss mehrfach – und unterschiedlich lange? – auf den Anschalter drücken. Vorhin wollte der Einrastmodus der SD-Karte einfach nicht greifen, bis es irgendwann doch ging. Auch die Abdeckung des SD-Kartenslots ist unglücklich gestaltet, zum einen schwer aufzumachen, zum anderen nur gesichert mit einem dünnen Plastikstreifen der garantiert irgendwann abreißen wird. Und dass das Ladegerät nicht USB-C ist: Schade; Dass es nichtmal Mikro-USB ist: Schwer verdaulich.

Diese frühe Version des Pinetab könnte sich auch mit bester Software am Markt nicht behaupten. Es fehlen ein paar Upgrades, eine Revision 2. Wobei solche Hardwarerevisionen tatsächlich in den Blogartikeln von Pine64 immer mal wieder erwähnt werden, ich habe nur nicht den Überblick auf welchem Stand die nächste ausgelieferte Variante sein wird.

Aktueller Eindruck der Software

Wobei die Software sowieso nicht fertig ist. Doch immerhin ist der Unterschied zur Anfangssituation mit der damaligen Version von Ubuntu Touch, dass ich damit nichtmal ansatzweise gewusst hätte wo man ansetzen müsste um das System fertigzustellen.

Bei postmarketOS mit Plasma sind die Macken klar und scheinen beherrschbar:

• Die Autorotation streikt wenn beim Start die Tastatur angesteckt war,
• Wlan verbindet sich nicht automatisch,
• die Pineingabe beim Login lässt sich nicht deaktivieren,
• im Firefox geht die Bildschirmtastatur nicht zuverlässig auf,
• es fehlen Icons in Programmen wie gedit,
• die Anzeige der Benachrichtigungen in komischen KDE-Fenstern ist hässlich.

In der Summe blockieren solche Probleme die komfortable Nutzung durchaus. Aber es ist nicht mehr zum Haare raufen. Zumal diese Fehler alle lösbar scheinen. Als Entwickler des Systems mit einem solchen Testgerät wäre mir klar, welche Probleme anzugehen sind. Dementsprechend ist es völlig möglich, dass Mobian und Phosh oder eine zukünftigen Variante von postmarketOS (ob mit Phosh oder Plasma) all diese Probleme lösen.

Das als erreichbar sehen zu können stimmt mich zuversichtlich. Nicht nur für die Zukunft des Pinetabs, sondern auch für Standardlinux als Alternative zu Android generell. Die Grundlage ist da. Mit einer soliden Grundauswahl an Apps wird das System als Alternative taugen. Und wie toll wäre es, neben Androidvarianten wie LineageOS und /e/ dann postmarketOS bei sustaphones aufnehmen zu können?

Fazit: Es wird

Die Softwareverbesserungen verwandeln das Pinetab. Vorher wurde der Reiz des Konzepts überdeckt von all den Problemen. Jetzt gibt es immer noch Macken, aber sie sind geringfügiger, sodass das Konzept wieder scheinen kann. So wird deutlich, was für ein nettes Gerät das Pinetab im Kern ist. Mit seiner ansteckbaren Tastatur und mit den außerhalb von Ubuntu Touch verfügbaren Linuxprogrammen wird es zum ultraleichten Laptop mit abnehmbaren Touchdisplay. Was ein Format ist, in dem GNU/Linux als Windows und Androidalternative eine gute Nische haben könnte.

Das Pinetab was ich hier habe ist eindeutig noch eine Entwicklervariante, unfertig und mit Macken die es vom Massenmarkt disqualifizieren. Aber so wie es jetzt ist kann es die Rolle eines Entwicklergeräts durchaus füllen. Wollte ich jetzt eine NewPipe-Alternative für mobile Linuxgeräte schaffen wäre das Pinetab nun ein gutes Testgerät dafür. Damit erfüllt es völlig sein erklärtes Ziel. Und erfüllte es vielleicht auch vorher schon, wenn es neben dem Pinephone, dem Librem 5 und den als Entwicklungsplattform genutzten Androidgeräten dazu beitragen konnte, dass die Entwickler von Plasma und postmarketOS und den anderen Alternativen diesen Stand erreichen konnten.

Das Softwareprojekt kann es nicht gewesen sein.

Der vermeintliche Verkauf von Audacity wirft weiterhin Fragen auf. Das kam jetzt wieder auf im Nachklang des Telemetrie-Debakels, als Audacity direkt nach der sogenannten Übernahme Telemetriedaten an Google und Yandex senden wollte. Doch was wissen wir über diese Änderung im Projekt überhaupt?

Was wurde berichtet

Caschy nannte es in seinem Blog eine Übernahme. Bei Audacity auf der Webseite wurde nur eine Mini-Nachricht gepostet, Audacity has just joined Muse Group. Das ist auch dort nur ein Zitat von Martin Keary (Tantacrul), der dort ein Projekt leitet und jetzt auch Audacity leiten soll. Er selbst hat dazu ein Youtube-Video veröffentlicht und das hat einen eindeutigen Titel: I’m now in charge of Audacity. Seriously.

Tantacrul kommt in dem Video positiv und überlegt rüber, interessiert am Projekt. Das ist nicht das Problem. Die Frage ist, wie diese Übernahme zustandegekommen sein soll. Er beschreibt das zu Beginn des Videos so:

Well, in short: Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of. And since things are going rather well at MuseScore, I was asked to step up and also manage Audacity in partnership with its open source community.

Was genau das ist, was auch bei der Audacity-Webseite als Zitat genommen wurde.

Was genau ist Muse Group? Sie beschreiben sich selbst auf ihrer Webseite. Es ist ein Unternehmen. Und in der Timeline steht auch, wie sie Audacity einordnen: Als acquired, also gekauft, oder zumindest unter der eigenen Kontrolle stehend.

Was, wie ich eingangs behauptet habe, nicht sein kann. Doch dafür müssen wir uns angucken, aus welchen Bestandteilen Audacity besteht und was davon kaufbar ist.

Audacitys Bestandteile als kaufbare Objekte

Ohne in irgendeiner Form bei Audacity involviert zu sein, ist das folgende mein Verständnis des Projekts.

Der Code

Die einfachste Variante bei einem proprietären Softwareprojekt wäre der Kauf der Rechte am Code, also dass jemand den Code einer Software und damit die Software selbst kauft. Doch das ist bei Audacity kaum möglich. Zuallererst, weil die Software unter der GPL 2 steht, wie die Webseite selbst verlinkt. Im Kern bedeutet diese Lizenz, dass jedem Nutzer der Software vier Freiheitsrechte zustehen:

1. Sie zu nutzen wie man will, für jeden Zweck
2. Die Software anzupassen
3. Die Software weiterzugeben
4. Die Software in veränderter Form weitergeben zu dürfen

Die GPL formuliert das anders und hat andere konkrete Klauseln bezüglich der Urheberauflistung etc, aber auf das läuft es hinaus.

Gleichzeitig hat die GPL die Klausel, dass abgeleitete Varianten der Software ebenfalls unter der GPL bzw kompatiblen freien Lizenzen stehen müssen. Was der Kernunterschied zu BSD- und MIT-Lizenzen sind, die insoweit "freier" sind, als dass bei ihnen die Freiheiten nicht für abgeleitete Werke gelten müssen.

Allerdings berührt die GPL nicht das Urheberrecht. Der Erschaffer ist weiterhin der Urheber. Das ist im deutschen Urheberrecht sowieso so, in den USA aber nicht, dort hat das massiv Bedeutung. Lizenzen wie die GPL nutzen das Urheberrecht, um die Rechte die sie einräumen wollen durchzusetzen.

Jetzt kann natürlich die Muse Group hingehen und das Urheberrecht kaufen. Bzw in Deutschland könnten sie die Verwertungsrechte kaufen. Allerdings stünde die Software weiterhin unter der GPL 2. Die Lizenz kann nicht nachträglich entzogen werden. Der Käufer hätte also Rechte an einem Produkt gekauft, das jedem Empfänger desselben umfassendste Rechte einräumt. Inklusive aller Verwertungsrechte, die bei proprietärer Software ein Käufer für sich beanspruchen würde, wie das Weiterverbreiten des Produkts zu einem beliebigen Preis bei zwingend offenem Quellcode.

Das komplette Urheberrecht zu besitzen könnte ihnen dann aber erlauben, neben Audacity unter GPL-Lizenz eine Variante unter einer anderen Lizenz zu veröffentlichen. Sogar unter einer proprietären. Solche Konstruktionen gibt es, sie sind nichtmal besonders unüblich.

Allerdings: Alleine auf Github werden 127 Mitentwickler gelistet. Bei einem so alten Projekt wie Audacity reicht der Quellcode noch viel weiter zurück als Github bekannt, die Liste ist in Wirklichkeit viel länger, endet Githubs Aufzeichnung doch bereits 2015. Es ist höchst unwahrscheinlich, dass bisher alle diese Entwickler ihre Urheber- bzw Verwertungsrechte an eine wie auch immer geartete bisher unbekannte Audacity-Institution übertragen haben. Denn zum einen ist diese Idee der Rechteübertragung bei FOSS-Projekten relativ neu. Zudem ist sie wahrscheinlich nicht über alle verschiedenen Rechtssysteme hinweg umsetzbar. Und außerdem finde ich dazu nichts in der Entwicklerdokumentation, während solche zu treffenden Erklärungen sonst normalerweise prominent erwähnt werden.

Es gab also höchstwahrscheinlich keinen einzelnen Ansprechspartner um den Code zu kaufen. Die Muse Group hätte mit jedem einzelnen Entwickler reden müssen, sie alle überzeugen und im Zweifel fürstlich bezahlen müssen. Unwahrscheinlich. Wenn das doch gelang bin ich beeindruckt.

Doch selbst wenn ich mich da vertue und seit zwanzig Jahren jeder einzelne Entwickler sein Urheberrecht nach US-Rechtssprechung auf eine natürliche Person oder ein Unternehmen übertragen hat: Selbst dann stünde noch die GPL. Und die kommerzielle Vermarktung einer solchen Desktop-Audiosoftware unter Doppelt-Lizensierung erscheint mir sehr schwierig.

Zusammenfassend: Rein praktisch war der Code und damit die Software nicht kaufbar, und selbst wenn dieser Kauf gelungen wäre hätte der Käufer in diesem Fall einer Desktopsoftware damit kaum praktisch verwertbare Rechte erworben.

Das Team

Manchmal ist bei Übernahmen gar nicht die Software das Ziel, sondern es sind die Entwickler, deren Arbeitsverträge gewonnen werden sollen. Auch das ist hier höchst unwahrscheinlich.

Zum einen passt es nicht zu dem Video. Was dort beschrieben wurde ist das Ziel, Audacity weiterzuentwickeln. Und das mit einem Ernst, Respekt und in einem Detailgrad, dass diese Ankündigung nicht das durchaus übliche Gelaber bei Silicon-Valley-Übernahmen zu sein scheint.

Zum anderen müssen dafür die Entwickler Teil einer kaufbaren Organisation sein. Gab es denn ein Unternehmen, das die Audacity-Entwickler beschäftigt hat? Ein solches Unternehmen wird zumindest weder auf Wikipedia noch auf der Webseite des Projekts erwähnt. Nein, Audacity wirkt wie die meisten FOSS-Projekte, bei denen die Entwicklung von wenigen Frewilligen getragen wird.

Von Paul Licameli zum Beispiel, der auch im obigen Video auftritt. Er ist zwar laut LinkedIn von einem audacity-Team beschäftigt. Dieser vermeintliche Arbeitgeber verlinkt aber nur zur Audacity-Webseite, die kein Impressum hat und keinerlei Unternehmensform auflistet.

Eine mögliche Konstruktion könnte sein: Es gab hier zwar kein Unternehmen. Aber es gab ein Team, das sich als moralischer Besitzer von Audacity gesehen hat. Und diese Entwickler werden jetzt von der Muse Group beschäftigt. Aber davon war bisher keine Rede. Und auch Paul hat bisher seinen Arbeitgeber auf LinkedIn nicht angepasst.

Und selbst wenn in irgendeiner Form die Kernetwickler gewonnen werden konnten: Selbst dann wäre Audacity selbst nicht Teil des Deals gewesen. Fortan Kernentwickler zu beschäftigen gibt in der Praxis Macht, aber es gibt dem Unternehmen am vorher geschaffenen keine Eigentumsrechte. Audacity wäre weiterhin rechtlich nicht Teil der Muse Group.

Intellectual Property

Intellectual Property (IP) gibt es eigentlich nicht, es ist eine Wahnsinnsidee bekloppter Kapitalisten. Aber okay, wenn es etwas als Idee gibt, dann existiert es eben doch. Und es gibt existierende legale Konstrukte, die so bezeichnet werden. Patente zum Beispiel. Es könnte eine Instutition geben, die mittelbar durch Audacity Patente besitzt. Audacity wurde 1999 an der Carnegie Mellon University gestartet und Universitäten sind berüchtigt dafür, solche diffuse Eigentumsrechte geltend zu machen. Vielleicht hat Muse diese Universität bezahlt, damit etwaige Ansprüche abgetreten wurden. Darauf gibt es aber keine Hinweise.

Ein anderes Beispiel für IP sind Marken (Warenzeichen). Und die sind hier wahrscheinlich im Spiel. Denn es ist auffällig, dass auf der Webseite von Audacity immer von Audacity® die Rede ist. Das ist sehr unüblich für nicht unternehmensgetragene FOSS-Projekte. Es sei eine registered trademark. Sowas wäre kaufbar. Und die Marke gibt es tatsächlich:

Dem Eintrag zufolge registriert von Dominic Mazzoni, einem der Gründer der Software, und jetzt im Besitz der uns bekannten Muse Group. Das einzige direkt greifbare Element im ganzen Puzzle, das gekauft werden konnte, wurde von der Muse Group tatsächlich erworben.

Nur ändert das nicht unbedingt viel. Denn die Marke zu besitzen bedeutet nur, die Marke zu besitzen. Es bedeutet nicht, zusätzliche Ansprüche an Quellcode oder an Loyalität der Entwickler zu haben; An dem Produkt, auf das sich die Marke bezieht.

Audacity wurde nicht verkauft

Mein Ergebnis ist, dass Audacity nicht verkauft wurde. Also nicht das Softwareprojekt. Es konnte nicht verkauft werden. Es gab keinen vorherigen klaren Besitzer und deswegen keine verwertbaren Eigentumsrechte.

Ich vermute es ist folgendes passiert: Die Leute im Audacity-Projekt und die Muse Group haben gesprochen. Und vielleicht waren die aktiven Projektteilnehmer auch wirklich daran interessiert, Audacity mit einer Firma zusammen zu entwickeln. Da könnten Absichtserklärungen abgegeben worden sein. Und an irgendeinem Punkt floss bestimmt sogar Geld. Aber alles, was damit praktisch gekauft werden konnte war die Marke Audacity.

Die Marke und damit das geflossene Geld gibt der Muse Group praktisch null Rechte. Sie könnten damit Forks der Software zwingen, einen anderen Namen zu benutzen. Aber es ändert nichts an den gewährten Freiheitsrechten via der GPL 2, nichts an den Eigentumsverhältnissen des Codes. Und auch nichts an der Machtstruktur im Projekt – außer praktisch, wenn sie die Adminrechte am Github-Projekt übertragen bekommen haben.

Muse Group kann aber natürlich trotz der fehlenden rechtlichen Bindung mit den FOSS-Entwicklern von Audacity zusammenarbeiten. Sie wollen Usability-Studien machen, scheinbar Usability als Prozess in die Entwicklung einbringen. Das könnte eine gute Sache sein.

Aber diese vermeintliche Übernahme gibt ihnen in Wirklichkeit wenig Macht über das Projekt. Muse hat wahrscheinlich nur eine fast wertlose Wortmarke gekauft. Nicht ganz wertlos, weil man ja mit einer so bekannten Marke doch irgendwie Geld verdienen kann. Aber doch fast wertlos, weil mit ihr kaum Kontrolle über das Produkt und Projekt selbst ausgeübt werden kann.

Nun frage ich mich: Wissen die das? Es ist zwar schwer vorstellbar bei einer Firma, die mit FOSS arbeitet, aber Fehler können immer passieren. Hatte die Muse Group vielleicht den Eindruck, wirklich das Audacity-Projekt zu kaufen?

Und: Wissen die Audacity-Entwickler, dass in Wirklichkeit weiterhin sie das Projekt kontrollieren könnten? Oder meinen sie wirklich, dass ihr Code und ihre Urheber-/Verwertungsrechte nun jemand anderem gehören?

Viel könnte hier auch einfach falsch kommuniziert worden sein. Vielleicht ist allen Beteiligten die Lage durchaus klar. Tantacrul könnte der Projektleiter des internen Audacity-Projekts bei Muse Group sein und das eigentliche Audacity-FOSS-Projekt gewillt, ihn mal eine Weile walten zu lassen. Geschenkter Usability-Arbeit sollte man nicht ins Maul schauen. Gekauft wurde nur die Marke, aber effektiv die Leitung aus Gutdünken eben auch überlassen, weil es sonst niemand machen wollte oder weil die Überzeugung da war, dass er das am besten kann. Wie es in einer Meritokratie eben passieren kann. Und als die Verlautbarungen dann erstmal missverstanden wurden hatte niemand Interesse daran, das sofort öffentlich auszudiskutieren.

Oder nur einer täuschte sich hier lautstark. Tantacrul schrieb ja selbst im Issue zur Telemetrie-Korrektur:

The first few questions are the ones most people want to know the answer to, I think. The only reason I'm not jumping on it right away is because I don't want to get any details wrong.

My role is product direction and design and I really want to publish a vision properly so it can be commented on more broadly. I'd prefer not to outline it all in text here.

I hope you understand. The issue I'm addressing in this discussion is super sensitive and I don't want to get anything wrong that might come back to haunt me. We are painfully aware there is a dearth of information and it is being sorting out.

Er hat also von dieser Übernahme gar nicht wirklich Ahnung. Wenn nur er missverstanden hat, wovon er jetzt tatsächlich der Leiter ist, wollte ihn vielleicht niemand blamieren.

Audacity wurde gekapert?

Wie auch immer: Ich bin ziemlich sicher, dass die Muse Group nicht wirklich der Besitzer des Softwareprojekts Audacity ist. Sie hätten dafür die urheberrechtlichen Verwertungsrechte aller bisherigen Entwickler kaufen müssen. Ganz vielleicht haben sie stattdessen eine Rechteabtretung der aktiven Kernentwickler und/oder die Absprache gekauft, ab jetzt das Projekt zu kontrollieren. Und wollen später mit proprietären Zusatzdiensten Gewinn erzielen. Das könnte funktionieren, wenn sie direkt oder indirekt Adminrechte auf der Webseite und im Github-Projekt haben und solange niemand mit ähnlicher praktischer Macht sie herausfordert, ist aber keinesfalls wasserdicht.

Der Kauf der Audacity-Marke wäre für eine solche Machtübernahme allerdings ein verwertbarer Baustein. Wenn das aber hier so gelaufen ist, dann ist es höchst bedenklich. Praktisch würde es bedeuten: Jedes Softwareprojekt kann von einer Firma gekapert werden, wenn die Firma alle Entwickler mit Adminrechten an der existierenden Entwicklungsstruktur (Github, Webseite) bestechen kann. Entwickler ohne solche Rechte hätten dabei kein Mitspracherecht. Nur bei der GPL könnten sie zumindest eine Lizenzänderung verhindern.

Ich könnte mich natürlich täuschen. Der Artikel ist auch deswegen so lang, weil ich im Laufe des Schreibens immer mehr Optionen gesehen habe, wie die Muse Group nun doch faktisch das Projekt kontrollieren könnte ohne der echte Besitzer zu sein. Ich bin daher gespannt, ob und wie sie die Übernahme erklären werden. Denn wenn es ein simples Kapern der Leute mit Adminrechten war: Dann stinkt die Aktion mehr als ich initial glaubte.

It just works, it just works,
Little lies, stunning shows
People buy, money flows, it just works

direkt

Über die Pandemie hinweg mögen sich bei uns die Einkaufsgewohnheiten durch Essenslieferungen und Online-Supermarktbestellung verändert haben, aber etwas anderes hat sich nur verstärkt: Wie selten wir Fleisch essen. Das selten zu halten ist bei mir volle ideologische Überzeugung. Die Katzen hier im Haus zu haben führt zu deutlich vor Augen wie komplex und fühlend Tiere dann eben doch sind. Gleichzeitig esse ich Fleisch gerne, darauf weitestgehend zu verzichten ist ein echter Verzicht.

Entsprechend attraktiv finde ich Fleischersatzprodukte. Für ein alternatives Steak mag es leider noch nicht reichen. Aber für einfacheres Essen wie für einen Burger vielleicht doch. Gerade bei den Burger-Hacksteaks habe ich aber den Überblick verloren, welche Alternative taugen und welche nicht – außer, dass die Halloumi-Grillkäse-Alternative für mich immer geht, aber das ist etwas ganz eigenes und nicht fleischähnlich.

Daher hier kurz protokolliert zwei Produkte, die ich toll finde und die in meinen Augen zeigen, dass diese Industrie wirklich gute Fleischalternativen herstellen kann.

Da wäre das Cordon Bleu von Rügenwalder Mühle. "Auf Basis von Soja" steht drauf und obwohl vegan, meint man wirklich beim Essen sowohl Käse als auch Schinken im panierten Fleischstück zu haben. Klar, es ist immer noch nur ein Supermarkt-Produkt, aber wenn ich wählen müsste zwischen einem günstigen normalen Cordon Bleu und diesem hier, ich würde auch rein vom Geschmack dieses vegane nehmen. Und wenn man sieht wie oft es im Supermarkt einfach nicht vorrätig war sehe nicht nur ich das so. Gut mit oder ohne Gemüse samt Nudeln und Soße oder Ketchup als schnelles Mittagessen.

Das Cordon Bleu hatten wir schon oft im Haus, die nächste Fleischalternative erst einmal: Vegane Hackbällchen von iglo. Aber ich fand die richtig gut. Besonders die Konsistenz war klasse. Die Köchin zweifelte meinen Eindruck zwar an, dass sie sehr Fleisch ähneln. Aber sie hatten auf jeden Fall nicht diese Konsistenz von locker gepressten Gemüse, die andere vegetarische Hackbällchen sonst oft haben. Und auch beim Geschmack war von Erbsen nichts zu merken, was positiv gemeint ist. Zusammen mit gut gemachten Reis fand ich diese Hackbällchen super und ebenfalls wieder auf einem Niveau, wo ich sie Hackbällchen aus Fleisch bei nicht deutlich besserer Qualitätsklasse vorziehen würde.

Knights of San Francisco ist ein Egamebook. Ein Computerspiel fürs Telefon (Android und iOS), das sich spielt als würde man in einem Buch Entscheidungen treffen. Man kennt das vielleicht von in echten Büchern erzählten Spielen, bei denen man dann je nach Entscheidung Seite X oder Seite Y aufschlagen soll. Ich erinnere mich noch heute, wie meine Grundschullehrerin mir ein solches Buch gab, ich es hinten in der Leseecke des Raums lesen durfte und ich es total faszinierend fand – sogar einzelne Textstellen und Entscheidungen sind noch deutlich in meiner Erinnerung. Es war wohl prägend und die Faszination ist bis heute nicht verschwunden.

Diese App will sogar mehr bieten, mehr Details simulieren und Entscheidungen mit interaktiven Auswirkungen haben als ein Textbuch es könnte. Und da es eben kein Buch ist kann wie in RPGs über Erfolg und Misserfolg per Würfel entschieden werden. Es gibt dazu einen tollen Trailer:

In dem Spiel ist man ein junger Totenbeschwörer auf der Suche nach seinem Bruder. Der ist in San Franciso verschwunden, bei einer uralten Pyramide. Doch direkt am Anfang wird man von einem wilden Goblin angegriffen und in den Folgeabschnitten lauern noch viel mehr Gefahren. Warum man den Bruder sucht? Das wählt man am Anfang selbst aus.

Mir hat die Geschichte gefallen und ich fand, dass die Umsetzung funktioniert. Wenn ein Goblin im Kampf ein Auge verliert, ich ihn danach wiederbelebe und er dann nicht die Augen, sondern nur das Auge aufmacht, zeigt sich wie die kleinen Details in den Texten beachtet werden. Genauso gibt es auch größere Entscheidungen, aber wie dynamisch die Geschichte wirklich ist – wieviel wirklich Simulation ist – um das zu herauszufinden müsste ich sie noch einmal durchspielen und auf die Änderungen achten. Aber selbst wenn der Großteil statisch wäre, wovon ich ausgehe, hatte es viel von einem Pen&Paper-Abenteuer in interaktiver Textform und schon das war einfach nett.

Knights of San Francisco lief auf meinem alten Android gut. Nur ab und an dauerte das Berechnen der Auswirkungen etwas zu lange. Die Musik könnte sich besser an die Spielsituation anpassen. Und das Spiel war an einem kurzen Nachmittag durchgespielt. Aber das ist jeweils kein starkes Manko, auf neuen Geräten wird es schneller entscheiden, die Musik ist nebensächlich und die Kürze war sowohl angekündigt als auch beim geringen Preis okay.

Wer das Konzept auch nur halb so interessant findet wie ich sollte wirklich einen Blick riskieren.

Dieser Blog hat neues CSS für die Druckdarstellung bekommen. Der Artikel zur Witcherserie als Beispiel sieht im Web so aus:

Ausgedruckt – bzw mittels der Druckfunktion zum PDF umgewandelt – und dabei auf ein Blatt herunterskaliert kommt das dabei raus:

Erreicht wird die angepasste Darstellung durch dieses CSS, das ich einfach der regulären CSS-Datei hinzugefügt habe:

@media print {
    #serendipitySideBarContainer {
        display: none;
    }
    #content {
        width: 100%;
    }
    #serendipityCommentFormC {
        display: none;
    }
    .shariff {
        display: none;
    }
    .dsgvo_gdpr_footer {
        display: none;
    }
    #siteNav {
        display: none;
    }
    body {
        font-family: Iowan Old Style, Apple Garamond, Baskerville, Droid Serif, Times, Source Serif Pro, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Times New Roman, serif;
        border: none;
    }
    html {
        background-color: white;
    }
    .serendipity_entry_body {
        column-width: 17em;
        column-gap: 3em;
    }
    .serendipity_entry_body a[href*='//']::after, serendipity_commentBody a[href*='//']::after {
        content: " (" attr(href) ")";
    }
    a {
        color: black !important;
        text-decoration: underline !important;
    }
    #serendipity_banner {
        display: none;
    }
    #mainpane::before {
        content: "onli-blogging";
        display: block;
    }
    .serendipity_title a {
        text-decoration: none !important;
    }
    .serendipity_title, .serendipity_date {
        break-after: avoid;
        break-after: avoid-page;
    }
    br + .serendipity_commentsTitle, .nocomments {
        display: none;
    }
    .serendipity_entryFooter, .serendipity_comment footer {
        display: none;
    }
}

Wer das in seinen eigenen Serendipity-Blog übernehmen will müsste manche der Klassen wahrscheinlich anpassen, denn mein Design basiert mit codeschmiede auf älteren Code, den ich selbst nach HTML5 umgewandelt habe. Deswegen gibt es ein paar Unterschiede bei den Klassennamen zu 2k11 und anderen modernen Themes. Aber die Grundideen sind:

Ausgeblendete Seitenleiste und andere Elemente

Wer einen Artikel ausdrucken will kann auf dem Papier mit den Links in der Seitenleiste nichts anfangen, daher konnte die weg. Dazu habe ich den Header, der bei Einzelartikeln nur den Artikeltitel doppelte, den Footer des Blogs, die Artikelunterzeile und das Kommentarformular ausgeblendet.

Links ohne Farbe

Links sind hier im Blog normalerweise farblich markiert. In der Druckversion sind sie stattdessen schwarz, aber unterstrichen, und ihnen folgt das Linkziel als Text.

Serif-Schriftart

Für das richtige Papierdesign. Übernommen vom systemfontstack – es war gar nicht so einfach, passende Systemschriftarten für Serif- statt Sans-Serif-Schriftarten zu finden – aber leicht angepasst, denn Times New Roman war mir zu prominent platziert.

Spaltenansicht

Der Artikel wird wenn Platz ist in Spalten aufgeteilt. Auf dem Bild oben sind mehr Spalten als normal, da die Skalierung auf 60% reduziert war. Normalerweise sind es bei Din-A4 zwei Spalten im Querformat und nur eine, wie am Monitor, im Hochformat. Die Idee habe ich von sitepoint übernommen.

Titel hinzugefügt

Damit der Blogname trotz ausgeblendetem Header wenigstens irgendwo auftaucht wird er als Pseudoelement vor den Artikel gepackt.

---

Ganz bewusst nicht ausgeblendet sind die Kommentare, denn die könnten ja zum Artikel beitragen bzw das sein, was jemand ausdrucken wollte. Und auch das Videoelement ist absichtlich noch da, denn ohne es würde dieser Abschnitt des Artikel fehlerhaft wirken. Man kann es zwar nicht anklicken, aber sieht so zumindest dass es da war.

Insgesamt ging es also darum die Artikel auf dem Papier lesbarer zu machen, interaktive Elemente möglichst zu entfernen und auch die angezeigten Farben auf ein Minimum zu reduzieren. Damit wenn schon etwas ausgedruckt wird, es möglichst sparsam geschieht und das Ergebnis so lesbar wie möglich ist.