Linux - 27

Hinter meinem Computerbildschirm kleben die LEDs eines Lightpacks und seit einer Weile sorgt hyperion mit boblight-X11 dafür, dass sich die Farben der LEDs dem Bildschirminhalt anpassen.

Als ich damals hyperion installierte fand ich einen Hinweis auf hyperion-x11, aber keinerlei Infos dazu wie das zu benutzen ist oder wo sich das versteckt. Jetzt suchte ich nach einer Möglichkeit, die schwarzen Balken eines Videos zu ignorieren und stolperte wieder darüber. Mit boblight-X11 bleiben die LEDs beim Balken ja schwarz, aber es wäre vielleicht schöner wenn sie sich nach dem Videobild darunter richten würden. Ich las, dass hyperion das lösen würde, und es gibt eine Konfigurationseinstellung dazu:

    "blackborderdetector" : 
    {
        "enable" : true,
        "threshold" : 0.01
    },

Das gehört in die ~/.hyperion.config.json. Aber mit boblight-X11 als Bildschirmgrabber bewirkt das nichts. Aber diesmal fand ich hyperion-x11: Es wurde bei der letzten Kompilierung von hyperion miterstellt und lag in hyperion/bin/ des Kompilierungsordners. Und tatsächlich: Ohne Kommandozeilenargument statt boblight-X11 gestartet belieferte das sofort die LEDs mit Daten, nach ein paar Sekunden wurden die schwarzen Balken des Videos erkannt und daraufhin ignoriert.

Das hervorragende Caffeine-Bundle hatte ich als Besonderheit wahrgenommen, als ein nur ausnahmsweise mal wieder für Linux-Spieler interessantes Humblebundle. Um das dann später nicht zu unterschlagen will ich daher das aktuelle Paradox-Bundle erwähnen, obwohl ich es nicht kaufen werde. Es sind gute Spiele dabei, insbesondere

1. Age of Wonders II und III, die in die Richtung von Heroes of Might and Magic gehen,
2. Magicka 2, für Fans von Koop-Spielen,
3. Crusader Kings 2, in das man viele Stunden versinken kann, und es kommt in der zweiten Preisstufe sogar mit dem wirklich netten DLC "The Old Gods",
4. Europa Universalis IV, das wohl Crusader Kings II ähnelt, aber auf einer etwas anderen Ebene spielt.

Für mich lohnt es sich nicht. Crusader Kings samt der Erweiterung war schon im 2018er-Bundle, genauso Magicka 2. Wobei ich von Magicka nur den ersten Teil einmal kurz angespielt habe. In Age of Wonders III bestritt ich bereits die Kampagne. Europe Universalis III schließlich verstaubt bisher ungetestet in meiner Steam-Bibliothek, da brauche ich mir den Nachfolger nicht zulegen.

Aber wer diese Spiele noch nicht hat, für den sind mindestens die ersten beiden Preisstufen ein gutes Angebot.

Tyranny aus dem Caffeine-Humblebundle ist Pillars of Eternity wirklich ähnlich. Wie PoE ist es ein Rollenspiel, das den klassischen Vertretern des Genres wie Baldur's Gate 2 nacheifert. Tyranny aber hat zwei Besonderheiten: Ersten ist man in der Ausgangsposition Rechtsprecher eines bösen Overlords, zweitens gibt es viele Entscheidungen, die auch tatsächlich den Spielverlauf ändern. Die betreffen vor allem die Parteien, von denen es einen ganzen Haufen gibt. Mit den zwei großen bösen Armeen kann in der Handlung gegen die jeweils andere agiert werden. Natürlich gibt es auch die Möglichkeit gegen beide zu rebellieren – aber klassisch den Guten zu spielen erschien mir zumindest für den ersten Spieldurchlauf witzlos. So viele Entscheidungen in einem etwas anderen Szenario zu haben ist klasse, denn dadurch wird das Rollenspiel tatsächlich zu einem Rollenspiel, in dem die gewählte Rolle getestet und durchgezogen werden kann.

Es gibt wieder Fähigkeiten, die in Gesprächen und der Umgebung eingesetzt werden. Im Grunde sind es nur drei: Lore, Athletik und Subterfuge. Weil die Balance verkackt wurde ist das aber leider anspruchslos. Nur ganz am Anfang gab es eine Situation, in der mein Charakter nicht genug Punkte in Athletik hatte, danach passte es das ganze Spiel hindurch in wirklich jeder Situation, immer. Immerhin sind in Gesprächen die so bewachten Optionen gar nicht immer die beste Wahl. Und es gibt auch noch den eigenen gewählten Charakterhintergrund, die Entscheidungen im Intro und Spielverlauf sowie die Meinung der Fraktionen und einzelner wichtiger Charaktere. All das hat in Gesprächen viele Auswirkungen und ermöglicht ebenfalls bestimmte Antworten. Und immer reagieren die Begleiter auf Entscheidungen mit Veränderungen in ihrer Loyalität mir gegenüber, und auch wenn eine Entscheidung den Zorn meines Arbeitgebers erweckt teilt das Spiel mir das mit. Immerhin ist es ja meine Aufgabe, das Gesetz eines rechtschaffen bösen Herrschers durchzusetzen. All das vorherzusehen und für mich akzeptable Lösungen zu finden wird durchaus komplex.

Die Gruppe fasst vier Recken, es gibt aber sechs Begleiter im Spiel. Da die ihren eigenen Charakter haben und fleißig das Geschehen kommentieren ist auch da viel Wiederspielwert. Denn in meinem Spiel wollte ich zwischen den Begleitern nicht hin- und herwechseln, zu gut funktionierte meine Gruppe mit den drei ersten Begleitern: dem Disfavored-Ritter Barik als Tank, Verve aus dem Scarlet Chorus als Schadensausteilerin, der Gelehrte Lantry war mein Magier und Heiler. Mein eigener Charakter war auf Wurfwaffen und Feuermagie spezialisiert. In D&D wäre das noch eine Dual-Klasse gewesen, hier geht diese Kombination problemlos regulär. Die fehlende Spezialisierung sollte Nachteile haben, aber die gab es nicht. Die Kämpfe nach dem ersten Akt waren eher auf der einfachen Seite, und dass die Fähigkeitsprüfungen kein Problem waren erwähnte ich ja schon.

Mir hat das Spiel insgesamt sehr gut gefallen. Ja, es gibt Schwächen: Der letzte Akt ist zu kurz, statt Portraitphotos in Gesprächen Charaktermodelle zu zeigen sieht richtig schlecht aus, die Begleiter haben keine eigenen Quests, mehr Gespräche hätten vertont und die Kämpfe taktischer sein sollen, die Story das Klischee "Du bist der Auserwählte" vermeiden können. Aber trotz all dem macht das Rollenspiel dank seinen Entscheidungen und dem ungewöhnlichem Szenario sehr viel Spaß. Tyranny saugt den Spieler in seine ganz eigene Welt, die des Overlord Kyros, samt magischen Edikten und einer Invasion, die ich gewinnen will und in der meine Entscheidungen schon vor dem Outro riesige Konsequenzen hatten. Und auch wenn mich das Auserwählt-Sein als Klischee stört, ist das mit der wachsenden eigenen Macht verbundene Fortschrittsgefühl in kaum einem RPG so fesselnd umgesetzt worden.

Wie schade, dass die Entwickler nicht noch ein paar Monate mehr in das Spiel investiert haben. Mit etwas mehr Feinschliff, mehr Inhalten rund um die Begleiter, sinnstiftenden Inhalten für das Edikt-System und der eigenen Behausung in dem nahezu fehlenden dritten Akt hätte Tyranny eines der ganz großen Vertreter seiner Genres sein können. Aber auch in diesem Aspekt ähnelt es eben Pillars of Eternity: Tyranny ist ziemlich toll, aber es könnte so viel besser sein. Mit all dem verschenkten Potential erreicht es dann leider nicht mehr die Klasse eines Baldur's Gate 2 oder Fallout 2.

Es ist schon eine Weile nicht mehr passiert, doch dieses Humble Bundle ist mal wieder ein Volltreffer für Linuxspieler. Auf bitblokes gibt es eine Vorstellung aller Linux-Spiele des Bundles, ich will die zwei im $12-Segment herausstellen. Beide habe ich noch nicht gespielt, aber beide waren auf meiner Wunschliste.

Tyranny

Tyranny ist ein RPG im Stile von Baldur's Gate, aber anders als der Vorgänger Pillars of Eternity nimmt es sich mehr Freiheiten. Es hat vor allem ein anderes Setting: In dieser Welt hat der Oberböse gewonnen, man selbst ist ein Handlanger desselben. Es muss viele Entscheidungen mit vielen sichtbaren Auswirkungen geben. Wenn du dir unsicher bist, schau dir den Gamersglobal-Test oder Jörg Langers Let's Play der ersten Stunde an:

Ich war überzeugt, Tyranny war für mich ein klarer Kandidat für den nächsten Steam-Sale, ich wollte nur des Ende von Witcher 3 abwarten.

Shadow Tactics: Blades of the Shogun

Commandos in modern in Japan. Auch dieses Spiel habe ich noch nicht gespielt, aber so kann man den GG-Test zusammenfassen. Auch, wie gut es sein soll, denn Commandos war damals wirklich kein schlechtes Spiel. Dass dann noch eine native Linuxversion dabei war platzierte es direkt auf meine Wunschliste, nur dass ich noch nicht dazu kam es auch zu kaufen. Hier ein das Spiel besprechendes Gamestar-Video:

Die beiden Spiele alleine machen das Bundle einen Kauf wert. Der Preis stimmt auch: Weder Tyranny noch Shadow Tactics war (zumindest im deutschen Steam-Store) je für einen so niedrigen Preis zu haben. Und beim Bundle sind noch weitere Spiele dabei: Headlander, GoNNER, Treadnauts, Dear Esther: Landmark Edition, This War of Mine, Ken Follett's The Pillars of the Earth. Die beiden letzteren war sogar auch schon auf meinem Radar, besonders This War of Mine klingt interessant. Beide sowie GoNNER haben eine Linuxversion.

Schaut euch das an:

You NEED multi colorized brackets in your IDE, it will change your life! pic.twitter.com/ehqonnSyy8

— Souvir 💡 (@Souvir) January 10, 2019

Zusammengehörige Klammern immer farbig zu markieren ist eine tolle Idee. Die Funktion gibt es als Plugin für VSCode und atom, und natürlich auch für vim und emacs. Für Geany habe ich leider kein entsprechendes Plugin gefunden. Kennt da jemand eines, das diese Funktion nachrüstet?

Gerade passierte es mal wieder: Um einen Verzeichnisnamen im Terminal lesen zu können lehnte ich mich nach vorne und kniff die Augen zusammen. Dunkelblau auf schwarz ist schwer zu lesen. Das passierte schon tausendmale, diesmal hatte ich den einzig richtigen Gedanken – änder es es halt. Mit dem Ergebnis bin ich zufrieden.

Unter Geany benutze ich das dunkle Farbschema Solarized. Das kann man auch für urxvt aktivieren, dieser Forenpost erklärt wie:

1. Füge in die Datei ~/.Xresources die Zeile

   URxvt.intensityStyles: false

   hinzu.
2. In die gleiche Datei gehören die Farbanweisungen aus Xresources.dark, aus dem Githubrepo solarized/xresources.
3. Ich musste in meine ~/.xinitrc noch die Anweisung hinzufügen, diese Datei noch zu laden:

   [[ -f ~/.Xresources ]] && xrdb -merge -I$HOME ~/.Xresources

4. Stelle sicher, dass in der ~/.Xdefault keine anderen Farbanweisungen für urxvt gesetzt sind. Ich hatte dort zum Beispiel URxvt*background: black gesetzt.

Jetzt entweder aus- und einloggen oder die neuen Farbanweisungen laden:

xrdb ~/.Xresources

Schon wird jedes neugestartetes urxvt-Fenster in der dunklen Variante des Farbschemas Solarized erscheinen.

Ich habe die Linuxdistribution auf meinem Heimrechner gewechselt, von Funtoo zu Void. Das mache ich echt nicht häufig, im Grunde ist es erst das zweite mal: 2016 habe ich Ubuntu mit Funtoo ersetzt, wobei Funtoo ein Gentoo-Fork ohne systemd ist.

War Funtoo also die falsche Wahl? Soweit würde ich nicht gehen. Ich habe eine bei mir dann instabil laufende Grafikkarte gekauft, die ich mit einer anderen Distribution testen wollte (Ergebnis ist noch ungewiss). Im Vorfeld dessen sind mir aber auch ein paar Probleme bei Funtoo sauer aufgestoßen. Es sind zwei Kernprobleme:

1. Obwohl es auf Gentoo basiert sind die Pakete gar nicht besonders neu. Um eine aktuelle Variante von Mesa zu bekommen musste ich beispielsweise ein noch nicht veröffentlichtes xorg-kit aktivieren.
2. Wenig überraschend ging mir das dauernde Kompilieren auf den Nerv. Aber auch, dass portage beim Berechnen der Abhängigkeiten minutenlang rödelte. Das können andere Paketmanager besser und hängt gar nicht mit dem Kompilierungsansatz zusammen

Ich hatte immer mal wieder andere kleine Probleme wie Konflikte zwischen den Paketen, die mir den Eindruck eines überforderten Projekts vermittelten. Ob das jetzt von Gentoo oder Funtoo kommt kann ich gar nicht sagen. Funtoo aber scheint sich definitiv noch zu finden, wobei die Neuorganisationen nicht immer problemlos verlaufen. Und: Anders als bei Ubuntu hatte ich immer das Gefühl, dass die für mich relevante Ankündigungen mich nicht automatisch erreichen. Manchmal saß ich also da und wunderte mich über die ausbleibenden Updates, ohne zu wissen ob die an einer von mir nicht umgesetzten notwendigen Änderung hängen.

Trotzdem, auch wenn es oben nicht so klingt: Funtoo war eine positive Erfahrung und ich hatte den Großteil der Zeit einen schnellen und stabilen Desktop, mit dem ich noch dazu einiges spielen konnte. Dass Void es besser macht ist noch gar nicht gesagt.

Warum Void und nicht XY?

Der Großteil der gängigen Distributionen fällt durch systemd raus, leider auch interessante Ansätze wie Solus. Aus der Liste der Möglichkeiten fiel mir dann Void ins Auge: Es wurde auf Hacker News mehrfach positiv erwähnt, es hat die für die Grafikkarte gewünschten neuen Versionen des Kernels und Mesa, und es bietet vorkompilierte Pakete an. Interessanterweise ist es kein Fork einer anderen Distribution, aber das ist kein Faktor dafür oder dagegen. Das wirkt nur indirekt, weil so systemd vermieden werden kann.

Wie Void wirkt

Ich kann bisher nur einen Ersteindruck geben. Am Samstag habe ich es installiert, gerade ist es Sonntag (du liest das hier wahrscheinlich frühestens am Montag). Ich hatte nach der Installation ein paar Probleme mit der DRI-Beschleunigung, aber letztendlich lag das an einer aus dem Backup übernommenen Umgebungsvariable, nicht an Void.

Bisher sieht mein Desktop so aus:

Das bedeutet: Es hat sich praktisch nichts verändert. Ich musste ein paar Programme auswechseln, aber es war alles Kleinzeug, Dinge wie kupfer statt grun.

Genau das ist eigentlich beachtenswert!
Denn Void ist eine unabhängige Distribution mit Binärpaketen. Ich mag eine Vielzahl von selten benutzten Programmen, trayer-srg und icewm zum Beispiel, Zeug für meinen eigenen Linuxdesktop. Auch das Benachrichtigungsprogramm dunst war im Repo, das ich erst mit Funtoo kennengelernt hatte und für etwas exotisches hielt. Ich habe damit gerechnet, einiges selbst kompilieren zu müssen. Stattdessen ist das Repository von Void absolut umfangreich genug um auch exotischere Setups wie meines zu unterstützen. Und noch dazu sind die Programme aktuell, inklusive Firefox, Mesa und dem Kernel. Also wo es zählt.

Die Ausnahme war das Iconset Numix-Circle, das habe ich von Github geladen. Das absolut notwendige und hervorragende Grafikkartenkontrollprogramm radeon-profile war im Repo auch nicht verfügbar, aber generell scheint das nur in Arch vorhanden zu sein. Mein eigenes simdock, im Screenshot zu sehen, war natürlich auch nicht in den Quellen, aber genau dafür habe ich ja jetzt das AppImage. Izulu hat keine besonderen Abhängigkeiten, die Anpassung des Desktops ans Wetter wird wieder funktionieren sobald ich es aktiviere.

Der negativste Teil meines bisherigen Eindrucks war die Installation (Quelle des Screenshots). Der Installer ist schlicht nicht besonders gut gemacht. Damit meine ich nichtmal, dass er im Terminal lief: Das war bei Ubuntu früher nicht anders, trotzdem war Ubuntu damals besser. Es gibt zu wenig Benutzerführung, Hilfe bei der Auswahl der Partitionierung und des Tastaturlayouts beispielsweise. Besonders kritisch ist das nicht automatische Bewältigen der nötigen Unterschiede zwischen Systemen mit BIOS oder UEFI. Ubuntu könnte meine Mutter selbst installieren, Void garantiert nicht.

Ich habe ansonsten nur noch ein Problem: Schrift im Firefox sieht auf manchen Webseiten komisch aus. Ich muss noch schauen, ob die falschen Fonts genutzt werden oder ob da fontconfig versagt. Dessen Konfiguration hatte ich ja für Funtoo erst kürzlich angepasst, vielleicht muss das für Void anders. Ich bin zuversichtlich das noch hinzukriegen. Ich vermute auch, dass ohne mein Backup einzuspielen und beim Verwenden einer gewöhnlichen Desktopumgebung dieses Problem nicht auftreten würde, kann es also Void nicht anlasten.

Mein Eindruck von Void ist bisher positiv. Es scheint eine Distribution mit aktuellen Paketen zu sein, deren Paketmanager ordentlich funktioniert, über ein großes Binärrepo verfügt und die konsequent systemd vermeidet. Auf diese Eigenschaften kommt es für mich gerade an. Ich bin gespannt wie viele Jahre ich dabei bleiben kann.

Den Vortrag von Bryan Lunduke habe ich diesmal wieder sehr gemocht:

Linux sucks ist eine jährliche Vortragsreihe von ihm, die ich gerade anfangs total toll fand. Damals gab es auch noch wirklich viel zu kritisieren, und Bryan hatte eine erfrischend klare Sicht auf die Dinge. Später empfand ich das Konzept als etwas betagt, und die Videoaufzeichnungen waren auch oft technisch ziemlich schlecht. Daher hatte ich im April die 2018er-Ausgabe ignoriert. Jetzt darf ich feststellen, dass es mit dem neuen Fokus auf die Politik rund um das Projekt wieder ziemlich interessant geworden ist. Gerade für jemanden wie mich, der viel davon auch kritisch sieht.

Das erste von mir mit Steams Proton durchgespielte Windows-Spiel ist Dishonored. Es war schon länger auf meiner Liste, weil es viel von dem bietet was ich an Deus Ex mag: Verschwörungen, alternative Lösungsoptionen und die Möglichkeit, schleichend und ungesehen die Missionen zu erfüllen.

Proton funktionierte größtenteils gut. An einigen wenigen Stellen gab es FPS-Einbrüche, an anderen fehlten ein paar Texturen. Das Spiel blieb aber durchweg spielbar, lief stabil und lud schnell. Sonstige Bugs sind mir nicht aufgefallen.

In Dishonored spielt man als Corvo, der gescheiterte Leibwächter der Kaiserin. Die von ihr vorher beherrschte Stadt wird von einer Rattenseuche heimgesucht. Es herrscht Chaos, zur Krankheit kommen Ränkespiele in der nun despotischen Regierung. Das alles ist in einem Art Steampunk-Szenario gehalten, in dem Technik von vor 200 Jahren mit moderner und Magie vermischt wurde.

Spielerisch ist es eine Mischung aus Deux Ex, Thief und Bioshock (und damit auch System Shock). Es gab beim Entwickler Arkane Studios mindestens auf der Führungsebene Verbindungen zu Ion Storm, also zum Macher der offensichtlichen Vorbilder. Man merkt es an vielen Ecken, aber am deutlichsten wird es an der Mischung aus RPG-Elementen und First-Person Shooter, wozu dann die angelegten alternativen Lösungsmöglichkeiten kommen.

Allerdings hat Dishonored da vielleicht die Balance nicht ganz richtig getroffen. Es pusht einen in Hinweisen und im Ladebildschirm immer wieder, die Missionen ohne Gewalt zu lösen. Das habe negative Auswirkungen auf das Ende, aber auch innerhalb des Spiels auf spätere Missionen, die dann schwieriger würden. Diese Beeinflussung ist aber nur deshalb nötig, weil Corvo ziemlich mächtig wird. Mit seiner Ausrüstung und Magie kann er die Gegner eben sehr gut mit Gewalt ausschalten, vor allem wenn er dabei ein bisschen mit Bedacht vorgeht und die Versteckmöglichkeiten nutzt. Und das macht Spaß, oft mehr als Wege zu suchen die Gegner zu umgehen. In Deus Ex war das anders: Dort war es noch der Spieler, der für sich entschied ob er schleichen will oder nicht, ohne dass das Spiel dazu eine ersichtliche Meinung hatte.
Muss man das vielleicht hinnehmen, darf ein Spiel nicht seinen gedachten Spielstil vorgeben? Das darf es schon, aber Thief zeigt dafür einen besseren Weg. Dort nämlich sind die Gegner wirklich stark und Schleichen daher der einzig erfolgversprechende Ansatz.

Mir kommt zugute, dass ich gerne schleiche und die beworbene Spielweise mir daher ganz gut passt. Aber dass Dishonored da im Spieler einen Konflikt auslöst halte ich für schlechtes Spieldesign.

Immerhin, das ist nur ein kleines Manko. Denn insgesamt macht es eine Menge Spaß. Was Dishonored toll macht ist die Wichtigkeit der Missionen herauszustellen. Hier wird keine Zeit mit kleinen Handlangern und Informantensuchen verschwendet, wie es ein Assassin's Creed machen würde. Stattdessen darf Corvo direkt seinen Rachefeldzug beginnen. Das motiviert. Diese Story vermischt das Spiel dann mit tollen magischen Fähigkeiten, hilfreicher Ausrüstung (die optional bleibt), gut gemachten Levels und viel Freiheit beim Durchlaufen derselben. Schade, dass es etwas kurz ist.

PS: Ich werde in Zukunft unter Linux per Proton gespielte Windows-Spiele nicht mehr der Linux-Kategorie hinzufügen. Das passte hier noch als Nachtrag zum Proton-Artikel, aber generell ist das zu wenig linuxspezifisch.

Marc Di Luzio hat ein nettes Video über Linuxspiele gemacht, alles native Ports:

Es gibt dazu einen Begleitartikel. Er baute das Video, bevor Valve Proton veröffentlichte, und wurde von dessen Release ziemlich getroffen. Daher diskutiert der Artikel die verschiedenen möglichen Auswirkungen: Bedeutet Proton das Ende der aktuellen Linux-Spielewelle, weil sich die Entwickler auf diesem Windows-Kompatibilitätslayer ausruhen werden? Sterben also die Portierer aus, Firmen wie Feral? Oder führt Proton einfach zu einer Zukunft, in der nahezu alle Spiele einfach unter Linux laufen, neue native ebenso wie für Windows gemachte? Linux daher zu der großen Spieleplattform wird?

Weder hier noch im Artikel gibt es Antworten, aber wir werden es ja sehen.

Schau hier:

Das ist ein Screenshot von Skyrim, gespielt unter Linux. Das ging auch vorher schon, aber es war selten einfach. Diese Installation dagegen lief perfekt: Herunterladen, auf Play drücken. Steams Proton funktioniert wie angekündigt.

Ich hatte noch gar nicht verstanden, dass es auch auf meinem System schon aktivierbar ist. Das geht so:

Erst Steam -> Settings auswählen. In den Einstellungen gibt es unten einen Eintrag namens Steam Play.

Dort kann Proton für alle Titel aktiviert werden, anstatt dass nur die Titel auf der Whitelist in der Linux-Library auftauchen.

Skyrim funktioniert, mich hat das sehr gefreut. Styx: Master of Shadows ging leider nicht, aber Proton wird sicher noch weiter verbessert werden. Auch schade: Bei Skyrim ist der Workshop kaputt, dem Steam-Forum zufolge ist das generell so. Die Mods über den Nexus zu besorgen war mir zu aufwändig, daher habe ich Skyrim dann gar nicht viel gespielt. Trotzdem, alleine dass dieses Windows-Spiel direkt startete ist ein tolles Zeichen.

Wer nicht alles selbst testen will, findet unter https://spcr.netlify.com/ eine Liste von Spielen samt ihrem Proton-Kompatibilitätsstatus. Ich werde jetzt Dishonored testen, laut der Seite soll es gut funktionieren. Das wäre ein Windows-Spiel, das ich schon eine ganze Weile spielen wollte.

Bei mir daheim fehlten die Pocket-Empfehlungen auf der Startseite in Firefox. Im Büro habe ich die schätzen gelernt, der Firefox auf dem Laptop zeigt sie an und es sind immer wieder tolle Artikel dabei, die so manche Pause füllen können. Daher wollte ich die Aktion gerne auch daheim aktiviert haben. Die Anleitungen dazu zeigen aber nur die Einstellungen über das Menü oder zur allgemeinen Pocket-Integration. Im Menü aber gab es keinen Weg, die Pocket-Empfehlungen auf der Tabstartseite zu aktivieren, der in der Anleitung erwähnte Dialog fehlt.

Die Lösung: In about:config die Einstellung browser.newtabpage.activity-stream.feeds.section.topstories auf true setzen. Schon sind die Empfehlungen da.

Allerdings sehen die Artikel noch nicht so aus, als seien sie an meine Vorlieben angepasst, und sie scheinen aus dem amerikanischen Sortiment zu kommen. Vielleicht weiß jemand, wie man auch das noch anpasst?

Nach dem heutigen Systemupgrade sahen manche Schriften nicht gut aus, besonders auffällig war das schlechte Kerning in den Tabtiteln von Firefox. Fontconfig hatte ein Upgrade bekommen, auf Version 2.12.4. Da war das Problem schnell einzugrenzen.

Als Ursache des Problems entpuppte sich meine ~/.config/fontconfig/fonts.conf. Dort war der Autohinter aktiviert. Das Arch-Wiki meint jedoch, dass bei vielen Schriften dieser mittlerweile zu schlechten Ergebnissen führt. Also musste er deaktiviert werden. So sieht meine gesamte .fonts.conf nun aus:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- /etc/fonts.conf file to configure system font access -->
<fontconfig>
<match target="font">
        <test qual="any" name="size" compare="more">
                <double>8</double>
        </test>
        <test qual="any" name="size" compare="less">
                <double>15</double>
        </test>
        <edit name="antialias" mode="assign">
                <bool>true</bool>
        </edit>
        <edit name="hinting" mode="assign">
            <bool>true</bool>
        </edit>
        <edit name="hintstyle" mode="assign" >
            <const>hintfull</const>
        </edit>
        <edit name="autohint" mode="assign">
            <bool>false</bool>
        </edit>
</match>
</fontconfig>

Ich muss mich aber mit diesen Einstellungen nochmal beschäftigen. Neben dem nun reparierten Kerning sehen manche Schriften seit dem Upgrade einfach anders aus. Und ich fürchte, nicht besser. Leider scheint es kein verständliches ChangeLog zu geben, sodass mir nicht klar ist, was sich am Fontrendering durch das Upgrade geändert hat.

Edit:

Ich habe es jetzt erstmal so abgeändert:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- /etc/fonts.conf file to configure system font access -->
<fontconfig>
<match target="font">
        <edit name="antialias" mode="assign">
                <bool>true</bool>
        </edit>
        <edit name="hinting" mode="assign">
            <bool>true</bool>
        </edit>
        <edit name="hintstyle" mode="assign" >
            <const>hintslight</const>
        </edit>
        <edit name="autohint" mode="assign">
            <bool>false</bool>
        </edit>
        <edit mode="assign" name="rgba">
          <const>rgb</const>
        </edit>
        <edit mode="assign" name="lcdfilter">
         <const>lcddefault</const>
        </edit>
        <edit mode="assign" name="embeddedbitmap">
          <bool>false</bool>
        </edit>
    </match>  
</fontconfig>

Also die Bedingung entfernt, sodass die Anweisung für alle Schriftgrößen gilt, und den hintstyle auf hintslight gesetzt.

Wichtig sei ebenso das Setzen des Subpixel-Hintingmodus. Dafür wird die /etc/profile.d/freetype2.sh angepasst. In ihr steht:

# Subpixel hinting mode can be chosen by setting the right TrueType interpreter
# version. The available settings are:
#
# truetype:interpreter-version=35 # Classic mode (default in 2.6)
# truetype:interpreter-version=38 # Infinality mode
# truetype:interpreter-version=40 # Minimal mode (default in 2.7)
#
# There are more properties that can be set, separated by whitespace. Please
# refer to the FreeType documentation for details.

# Uncomment and configure below

export FREETYPE_PROPERTIES="truetype:interpreter-version=40"

Da könnte je nach Geschmack, Schrift und Bildschirm auch 35 oder 38 besser gefallen. Ich bin mir aber derzeit nicht mal sicher, ob der Unterschied zwischen den drei Modi überhaupt sichtbar ist (laut diesem Kommentar greift der Unterschied nur bei hintfull). Eventuell ist das auch schon wieder veraltet.

Edit 12.01.2019: Anweisungen zu lcdfilter, embeddedbitmap und rgba hinzugefügt sowie die freetype2.sh beschrieben.

Gestern war ich auf der Froscon. Nur kurz, es reichte für zwei Talks: Einmal eine nette kleine Einführung in node-red (was mich aufgrund von Pipes interessierte), dann noch in den englischen Let's talk about Desktop Linux Platform Issues. Ich ging da mit gemischten Gefühlen raus: Die Diskussion am Ende funktionierte nicht, aber der Sprecher wirkte nett und ehrlich an der Verbesserung von Linux interessiert. Er präsentierte AppImage als mögliche Lösung. Zwar weiß ich nicht, ob das Verfügbarmachen von Software per Binaries wirklich das große Problem des Linux-Desktops ist. Andererseits ist das Verteilen von Software unter Linux ja wirklich nicht so einfach wie es sein soll. Ich markierte mir also AppImage als Möglichkeit dazu vor.

Heute stolperte ich via Thomas über Please stop making the library situation worse with attempts to fix it. Im Artikel geht es nicht wirklich darum, dass AppImage und die anderen Versuche alles schlimmer machen würden, sondern darum, dass AppImage nicht richtig funktioniere. Bei aller (bewusst) zur Schau gestellten Naivität des Sprechers probono im Vortrag: Damit hatte ich nach der guten Darstellung nun nicht gerechnet. Also wollte ich mir das schon jetzt einmal selbst anschauen.

Mein Beispielprogramm ist simdock. Dem Programm könnte die Verteilung als AppImage helfen, es ist ein ziemlich gutes Dock, mit meiner Nischendistro fällt es mir aber schwer, es ordentlich für Ubuntu etc. zu verpacken. Ausgangssituation: Es gibt ein Github-Repo mit dem Quellcode, dort liegt auch ein debian-Ordner mit dem ganzen Boilerplate zum Bauen des .debs, zusätzlich gibt es ein ppa. Das Makefile ist simpel und listet alle Abhängigkeiten, sauber mit pkg-config. Es gibt sogar ein PKGBUILD im AUR. Einen besseren Kandidat für AppImage dürfte es nicht geben.

Hier ist die Anleitung. Es werden sechs Wege gezeigt:

1. Nutze den Open Build Service (OBS)
2. Konvertiere bestehende Binärpakete
3. Travis CI builds wiederverwenden
4. linuxdeployqt für Qt-Anwendungen
5. electron-builder
6. Ein AppDir erstellen

Nur eins oder zwei kann ich mir vorstellen. Travis CI benutzt simdock nicht. Simdock ist auch keine Qt-Anwendung. Electron passt sicher auch nicht, wir sind am anderen Ende des Stacks. Ein AppDir manuell zu erstellen wäre zum einen dauerhafte zusätzliche Arbeit (und die Aktion soll mich ja auf Dauer entlasten, nicht belasten), die Anleitung existiert aber auch nicht. Sie sei verschoben nach https://github.com/AppImage/docs.appimage.org/blob/master/source/packaging-guide/manual.md, das wirft einen 404. Wenn ich mich aber nicht vertue müsste ich dafür Binärpakete des Programms und der Abhängigkeiten von einer möglichst alten Distribution wie Ubuntu 14.04 besorgen, das wäre keine Option.

Der Verweis zu OBS führt mich zu https://github.com/AppImage/AppImageKit/wiki/Using-Open-Build-Service. Dort steht auch, dass Inhalt verschoben wurde, nach https://github.com/AppImage/docs.appimage.org/blob/master/packaging-guide/obs.md. Aber das ist auch nur ein weiterer 404. Immerhin, der Link zum OBS-Buildservice führt mich auf diese Seite:

Aber das hilft mir nicht viel. Es ist mir überhaupt nicht ersichtlich, was ich dort tun kann. New Image vielleicht, obwohl ich nicht damit gerechnet hätte, dass die Funktion im OBS schon so heißt, und obwohl das Icon nicht wie der primäre Button der Seite aussieht. Dort kann ich dann auch tatsächlich AppImage als Template(?) auswählen, und unten meiner Appliance (ich dachte ich erstelle ein Image?) einen Namen geben. Der Button unten Create Appliance bleibt aber weiterhin ausgegraut. Das funktioniert also gar nicht.

Und ich glaube, ich scheiterte vor Jahren schon einmal an OBS, daran dass die Webseite einfach völlig kaputt war. Ich glaube das war, als ich dann stattdessen auf Launchpad ein PPA für simdock erstellte.

Bleibt der zweite Weg: Das Erstellen eines AppImages über das bestehende Paket. Da ich ein ppa mit .debs habe sollte das ja auch der einfachste Weg sein. Tatsächlich führt mich die Anleitung aber nur zu einem Bash-Script, ohne Erklärung wie es zu benutzen ist. Und zu Beispielen von yaml-Dateien, mit denen man wohl das Skript konfiguriert. Hier das von Geany, das sieht immerhin einfach aus und benutzt ein PPA. In dem Repo gibt es dann auch doch noch ein Beispiel dafür, wie man das Skript benutzt:

bash -ex ./pkg2appimage recipes/XXX.yml

Also habe ich das Geany-yaml genommen, auf simdock umgebogen, und den obigen Befehl ausgeführt. Das war das Ende der Ausgabe:

++ grep -e '^http'
./pkg2appimage: line 250: apt-get: command not found
+ URLS=

Das kann nicht gehen, ich habe weder Debian noch Ubuntu auf dem Rechner, natürlich findet es apt-get nicht.

Meine versuchte Erstellung eines AppImage für simdock war zu diesem Zeitpunk also erstmal gescheitert.

Warum das Steckenbleiben an diesem Punkt schade wäre

Bei seinem Vortrag hat probono viel davon geredet, dass Windows und MacOS eine Sache besser machen als Linux: Dort ist das Betriebssystem eine relativ stabile Plattform, sodass einmal darauf ausgelegt Programme fast dauerhaft dort laufen. Unter Linux dagegen müssen Programme sich immer wieder der sich ändernden Umgebung anpassen, vor allem, wenn ihr Quellcode nicht verfügbar ist (aber nicht ausschließlich nur dann, wie ich auch selbst mit simdock mehrfach schon erfahren musste). AppImage will das ändern, es ist als Erleichterung für Anwendungsentwickler gedacht. Aber in meiner Erfahrung funktioniert genau das eben nicht: AppImage erfordert von mir viel Arbeit, und es sieht absolut nicht einfach aus. Wo ist der Service, der ein Git-Repo nimmt, die Abhängigkeiten aus dem Makefile zieht, das Programm kompiliert und das Ergebnis als Makefile verpackt?
Stattdessen war ausgerechnet der klassische Weg in manche Distros einfach: Um das Programm nach Arch zu bringen musste ich gar nichts machen, ein Nutzer erstellte das PKGBUILD. Bei izulu – einem anderen Programm von mir – war es auch ein Nutzer, der es nach AUR packte. Ich weiß, dass es sehr einfach ist, für Gentoo ein overlay zu erstellen und es so verfügbar zu machen. Nur in die großen Distros komme ich mangels Popularität des Programms nicht, ohne mir Unmengen an Arbeit aufzuhalsen. Das Problem liegt also vor allem an Distributionen wie Debian, bei denen ich den Maintainer spielen müsste und zudem als Bittsteller auftreten würde, um in das Repository zu kommen.

Deswegen ist die Komplexität hinter AppImage schade: Ich würde mit sehr gerne davon helfen lassen, dann über AppImage wie per AUR meine Pakete in Distros verteilen können. AppImage scheint dafür aber derzeit der falsche Weg zu sein. Vielleicht liegt das an dem Fokus auf Binärpakete. Die zu vereinfachen, das scheint das große Ziel zu sein. Dafür will es Stabilität in den Library-Wirrwarr zu bringen, der im Vortrag auch sehr überzeugend gezeigt wurde. Meiner Erfahrung nach aber funktioniert in der Praxis aber nur der umgekehrte Ansatz: Mache es einfach, Quellcode zu kompilieren und direkt in die Distrospezifischen Pakete zu verpacken. Das erschlägt dann ebenfalls den Library-Dschungel, weil einfach immer der Quellcode entsprechend neu kompiliert wird.

Travis CI zur Rettung

Bevor ich diesen Artikel veröffentlichte habe ich mit den Leuten von AppImage Kontakt aufgenommen. Der einfachste Weg ging wohl an mir vorbei: Travis CI. Es ist einfacher als ich dachte bei jedem Commit den Kompilierungsvorgang zu starten, und AppImage kann sich hier reinhängen. Dann wird bei jedem Commit nicht nur automatisch das Programm erstellt, sondern auch das AppImage. Ich glaube allerdings nicht, dass ich ohne weitere Hilfe zurechtgekommen wäre, denn die Dokumentation ist auch dafür schwach (dafür weiß ich jetzt, dass eine neue Dokumentation gerade aufgebaut wird). Diese .travis.yml war der Startpunkt für Simdock:

language: cpp
compiler: gcc
sudo: require
dist: trusty

install:
  - sudo apt-get -y install pkg-config libglib2.0-dev libgconf2-dev libgtk2.0-dev libwnck-dev libwxgtk3.0-dev libxcb1-dev libxcb-ewmh-dev xcb-proto librsvg2-dev

script:
  - make -j$(nproc)
  - make install DESTDIR=$(readlink -f appdir) ; find appdir/
  - mkdir appdir/usr/share/applications/ ; cp simdock.desktop appdir/usr/share/applications/
  - mkdir appdir/usr/share/icons/hicolor/256x256/apps ; touch appdir/usr/share/icons/hicolor/256x256/apps/simdock.png # FIXME
  - wget -c -nv "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage"
  - chmod a+x linuxdeployqt-continuous-x86_64.AppImage
  - unset QTDIR; unset QT_PLUGIN_PATH ; unset LD_LIBRARY_PATH
  - export VERSION=$(git rev-parse --short HEAD) # linuxdeployqt uses this for naming the file
  - ./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -appimage

after_success:
  - find appdir -executable -type f -exec ldd {} \; | grep " => /usr" | cut -d " " -f 2-3 | sort | uniq
  - bash upload.sh Simdock.AppImage
  
branches:
  except:
    - # Do not build tags that we create when we upload to GitHub Releases
- /^(?i:continuous)/

Ich glaube, hier muss das Projekt noch arbeiten: Erstens die Dokumentation dafür verbessern, und zweitens vielleicht auch einen Weg finden, diese Integration mit weniger Code umzusetzen. Denn als Lösung ist dies ja nahezu perfekt: Sich in Travis CI zu integrieren bedeutet, sich in den Github/Gitlab-Entwicklungsflow zu integrieren. Läuft das einmal muss der Entwickler darauf kaum noch achten und es werden trotzdem immer aktuelle AppImages für das Projekt erstellt. Aber es ist noch ein bisschen viel Voodoo.

Nun rödelt Travis, die Warteschlange ist gerade voll. Wahrscheinlich kommt aus dieser Aktion aber ein funktionierendes AppImage für simdock heraus. Ich bin gespannt, ob das Programm dann auch tatsächlich funktioniert. Unter Ubuntu 14.04 habe ich es lange nicht getestet, und das wäre hier die Basis.

Es hat sich gezeigt, dass die Technik selbst funktioniert. Aber dass das Projekt noch an seiner Dokumentation arbeiten muss. Die notwendigen Kompetenzen um AppImage als Lösung zu etablieren scheinen definitiv vorhanden zu sein. Ich drücke die Daumen, und versuche mein AppImage für simdock beizubehalten.

Valve hat heute die Beta von Proton aktiviert (via). Proton ist ein (ebenfalls freier) Port von Wine und nutzt dazu DXVK, es ist also eine Software, mit der man Windowsanwendungen unter Linux starten kann. Bisher war es ja so, dass nur Linux-Ports mit Steam installierbar waren. Nicht alle waren echte Ports, man denke an Witcher 2. Aber es waren dedizierte Linuxversionen, wovon es deutlich weniger als reine Windowsspiele gibt.

Proton wird diese Situation ändern, da durch diese Software auch reine Windows-Spiele unter Linux laufen. Das wird nicht mit jedem Spiel funktionieren, und dass die so behandelten Spiele schneller als unter Windows laufen wird auch nicht die Regeln sein. Aber es vergrößert die Spielauswahl unter Linux, potentiell enorm. Noch dazu soll gerade DXVK hervorragend funktionieren. Ich habe es noch nicht selbst getestet, aber die Berichte über damit laufende Spiele waren beeindruckend.

Proton wird nicht auf gut Glück für alle Windowsspiele aktiviert, sondern Valve hat einige Spiele ausgewählt. Das ist die Anfangsauswahl:

Ich sage seit Jahren: Damit Linux auf dem Desktop gegen Windows bestehen kann braucht es Unterstützung für die kommerziellen Computerspiele. Es ist einer der zwei fehlenden Bausteine (der zweite ist arbeitsrelevante Software wie Adobe Photoshop, aber dort sind die freien Alternativen inzwischen hervorragend) für den Desktop. Seitdem hat sich viel getan, es gibt für Pinguinfans eine echte und gute Spieleauswahl. Genug, um Spielern und Linuxern wie mir Windows vollständig zu ersparen. Aber die größte Gruppe an überzeugten Computernutzern sind die Core-Gamer, und für die ist ein fehlendes Call of Duty, Battlefield oder was auch immer gerade angesagt ist ein zu großes Manko, um sich Windows zu sparen.

Natürlich: Wine gibt es schon länger. Und DXVK, das DirectX zu Vulkan umwandelt und so unter Linux lauffähig macht, funktioniert auch außerhalb Steams. Aber erstens hat Valve hier in die Entwicklung investiert, zweitens ist all das nur durch den von Valve getriebenen Push zu besseren Treibern möglich. Und drittens und vor allem geht es nicht nur darum, Spiele mit Arbeit und nur eventuell zum Laufen zu bringen. Sondern es muss komfortabel und zuverlässig funktionieren. Genau das kann die Steamintegration bewirken.

Der Rest des enormen Spielekatalogs soll später getestet und Spiele wo möglich aktiviert werden. Wenn das klappt wie erhofft, wird das eine große Erleichterung für Spielefreunde unter Linux bringen. Und dem Linux-Desktop mittelfristig einen wesentlich größeren Marktanteil.