Technikzeugs - 49

Noctua hat mir ein Plastiksäckchen mit Inhalt geschickt und bei mir damit sehr viele Sympathiepunkte gewonnen:

Es handelt sich um das Upgradekit NM-A90. Mit ihm kann die Ausrichtung des Noctua NH-U12P SE2 auf Mainboards mit dem Sockel AM3+ geändert werden, sodass der Luftstrom statt zum Deckel ans Ende des Gehäuses gelenkt wird.

Der Kühler kommt normalerweise mit zwei dieser Metallplatten, eine ist hier schon abgeschraubt. Wird er an sie montiert geht der Luftstrom nach oben oder unten.

Das Upgradekit beinhaltet zwei lange Streben, welche die kleinen ersetzen können.

Dadurch steht er dann quer, der Lüfter transportiert die Luft nach hinten.

Warum ist das wichtig? Es kann die Kühlung verbessern, vor allem in Gehäusen ohne Lüfter im Deckel, sodass stattdessen der Luftstrom direkt zum Exhaust-Kühler hinten geht. In meinem Fall soll die neue Kühlerausrichtung helfen den VRM des Mainboards zu kühlen. Irgendetwas überhitzt in meinem PC, laut dem Internet ist der VRM bei meinem Board ein möglicher Schwachpunkt. Da ich kürzlich sowohl Prozessor als auch Grafikkarte gewechselt habe ist das durchaus eine mögliche Ursache.

Noctua verschickt das NM-A90 kostenlos. Es muss nur dieses Formular ausgefüllt werden, wobei die Rechnung des Mainboards und die Rechnung des Kühlers gebraucht wird. Alternativ reicht auch ein Foto des Kühlers, samt einem Papier mit Datum und Unterschrift. Das ist ziemlich toll, vor allem, da Kühler wie Kit auf der Liste veralteter Produkte stehen und daher nicht mehr produziert werden dürften. In Deutschland wird das Kit auch nur noch bei reichelt verkauft, für 6,90€ plus Versand, was mir Noctua so erspart hat.

Noctua macht generell ziemlich gute Kühler und Lüfter und wird auf Reddits /r/buildapc hoch geschätzt. Ich hatte das bisher für übertrieben gehalten – manchmal basiert die Zuneigung der Community dort eher auf Wunschdenken. Und Noctuas Produkte sind ziemlich teuer, Arctics Lüfter beispielsweise sprechen mich über die Preis-Leistungs-Ebene mehr an. Und im High-End hätte ich statt dem NH-D15 durchaus eher den Dark Rock Pro 4 in Erwägung gezogen.

Aber scheinbar ist Noctua seinen Preis wert: Zusätzlichen zu den guten Kühlern gibt es dann auch noch Dreingaben wie diese. Da ist die Wertschätzung wohl verdient.

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 kopiere von Dirk und schreibe auf, womit ich 2018 gearbeitet habe. Tatsächlich hat sich ein bisschen was getan, nur Bruchstücke davon sind hier dokumentiert. Schreibe ich ein paar Jahre lang am Jahresende einen solchen Artikel könnte der Rückblick später nett sein.

Hardware

Auf der Arbeit benutze ich einen mir gestellten Laptop, der an einen 1440p‑Breitbildmonitor angeschlossen wird. Ich hatte da keinen Einfluss drauf, bin aber mit beiden Geräten sehr zufrieden. Nur eine ergonomische Maus (eine M618) hatte ich mir speziell gewünscht und erhalten.

Daheim ist mein Hauptwerkzeug mein Desktoprechner. Derzeit ist das ein AMD FX‑8320E, den ich günstig gebraucht gekauft habe, mit einer ebenfalls günstig gebraucht gekauften Radeon RX 580. Ryzen und das Platzen der Cryptoblase sorgten gegen Ende des Jahres für richtig nette Preise bei diesen Komponenten. Die FX‑Reihe ist nicht toll gewesen, der 8320E reicht als Prozessor für meine Zwecke aber völlig aus – und im Gegensatz zum Phenom II X6 kann er Deus Ex: Mankind Divided starten... Es blieb beim GA‑990FXA‑UD3 als Mainboard, mit mittlerweile 20GB Arbeitsspeicher, zur 120GB SSD kam eine 500GB SSD hinzu, dafür wanderte die 500GB HDD in einen anderen Rechner.
Der Monitor ist ein Dell U2312HM, 23.6", 1080p, IPS‑Panel. Er ist an sich sehr gut, hat aber inzwischen ein paar Macken in der Beschichtung und piepst bei runtergeregelter Helligkeit. 2019 könnte er ersetzt werden.

Die Grafikkarte ist noch ziemlich neu hier, ich habe seitdem Stabilitätsprobleme (zum Glück nur beim Spielen), die mit der Temperatur zusammenhängen zu scheinen. Ich vermute das Problem inzwischen allerdings beim Mainboard und werde versuchen, es mit mehr und etwas schneller laufenden Gehäuselüftern zu lösen.

Peripheriegeräte sind eine mechanische Cherry‑Tastatur (G80-3000), eine generische ergonomische Maus von CSL und der Logitech UE 6000, der sich als komfortabler als der Superlux HD 681B entpuppt hat, den ich auch sehr mochte und viele Jahre trug.

Das Wileyfox Spark+ ist weiterhin mein Smartphone, ich benutze es aber für die Arbeit nur um in Notfällen erreichbar zu sein, ansonsten unterwegs privat (Pokemon Go, Firefox, Google Maps). Leider wird es nicht mehr ordentlich mit Updates versorgt, es hat Android 7.0, der Stand der Sicherheitsupdates ist Januar 2018. Das ändere ich bald, Lineage wird installiert werden. Aber das Telefon soll auch dann nur noch als Backup dienen, der Ersatz steht schon bereit.

Am Ende des Jahres war ich lange im Urlaub. So lange, dass ich einen Weg haben wollte, Emails abzurufen und im Notfall die Server neustarten zu können. Das HP Touchpad wurde dafür auserkoren, mit Termux und K9‑Mail war alles notwendige auch unter Android verfügbar. Auch zum Browsen auf dem Sofa war das super. Alternativ hätte ich das Thinkpad R50 mitgenommen, aber es war mir für diesen Zweck zu schwer. Trotz langer Suche habe ich kein vernünftiges (=auswechselbare Batterie, 14" oder weniger, ordentlicher Bildschirm, linuxkompatibel), kleines, leichtes und bezahlbares Laptop gefunden.

Zwischendurch und wegen der Arbeit hatte ich eine Smartwatch getragen. Ich stellte dann aber fest, dass mich das tägliche Aufladen nervt und ich echte Uhren schöner finde. Seitdem trage ich wieder eine meiner Chinauhren.

Software

Im Büro

Der Arbeitslaptop lief dieses Jahr mit Windows. Ich wollte bewusst im neuen Job erstmal mit der vorgegeben IT‑Infrastruktur arbeiten und hatte anfangs versucht mit VMs zurechtzukommen, sobald Linux doch gebraucht wurde. Da nur wenig programmiert wurde und dann auch noch in Android Studio ging das bis jetzt ganz gut. Ansonsten war da wenige spezielle Software dabei, viel Office, am Ende etwas Axure – für Mockups und Prototyping scheint es erstaunlicherweise wenig geeignete Linuxsoftware zu geben!

Den Laptop nach Linux umzuziehen steht aber gerade ganz oben auf meiner Agenda, das neue Jahr soll etwas anders laufen. Und die VMs waren mir für den Desktopbetrieb weiterhin zu langsam, gerade beim Scrollen im Firefox.

Linux

Daheim ist am allerwichtigsten der Editor, wie die Jahre zuvor war das Geany mit dem Farbschema Solaris (dark). Pipes, pc‑kombo und all meine FOSS‑Arbeit entstand in Geany. Mehr brauche ich fast nicht: Trojita ist der Email‑Client, Firefox der Browser, urxvt das Terminal, der Linuxdesktop ansonsten weiterhin zusammengestückelt (IceWM, conky, simdock, trayer) und damit die einzige Besonderheit.

Die Linuxdistribution habe ich von Funtoo zu Void gewechselt. Wie immer ist so ein Umzug nicht ganz ohne, immer noch läuft nicht alles so gut wie vorher. Aber ich bin trotzdem sehr zufrieden: Void bietet aktuelle Pakete und erspart mir das dauernde Kompilieren der Updates, was mich nach einer Weile einfach zu sehr genervt hat.

Android

Unter Android läuft nicht viel erwähnenswertes, Firefox Beta ist die Hauptapp. F‑Droid ist installiert, genutzte Messenger sind derzeit Hangout und Telegram, aber auch SMS (wenn auch mit Silence) waren 2018 noch wichtig. Ich habe den DB‑Navigator entdeckt und kann nun Tickets und BahnCard damit vorzeigen, ein Quantensprung.

Web

Duckduckgo ist die Suchmaschine an den PCs, wobei ich noch oft !g eintippen muss um die Suche nach Google zu lenken, leider sind gerade die nicht‑technischen oder deutschen Suchergebnisse noch zu schlecht. Deshalb teste ich auf dem Telefon derzeit Qwant, was mir dort sehr gut gefällt.

Als Feedreader habe ich einen kostenlosen Account bei feedly.

Hoster sind auch wichtig, derzeit sind das Hetzner (pipes), scaleway (pc‑kombo, dieser Blog) und uberspace (Entwicklungsinstallationen und Emails).

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.

Intel hat mit dem i9-9900K einen sehr schnellen, aber auch teuren und heißen Prozessor veröffentlicht. Der i7-9700K und der i5-9600K sind gewöhnlichere Neuerscheinungen, die im Meta-Benchmark von pc-kombo aber auch sehr gut abschneiden:

Ich bespreche mehr Details der neuen Prozessoren im Blog von pc-kombo.

Seit ich Xiaomis elektrischen Tretroller M365 besitze bin ich einige Kilometer mit ihm gefahren. Anfangs dachte ich noch, dass ich ihn modifizieren werde und davon einiges hier im Blog landen würde, aber letztendlich funktionierte er einfach und es war nichts zu tun. Bis jetzt. Er hatte einen Platten und eignete sich nur noch als Katzenablage.

Nun bin ich nicht der geschickteste Mechaniker, aber einen Fahrradreifen flicken kann ich. Beim M365 sollte das ein ähnlicher Aufwand sein: Reifen abnehmen, inneren Luftschlauch entfernen, Loch finden, zukleben, wieder alles zusammensetzen. Oder einfach den Schlauch wechseln, er kam ja mit zwei Ersatzreifen inklusive Schlauch. Jedoch scheiterte ich hieran.

Anfangs hatte ich noch Glück. Im Reifen steckte nur ein kleiner dünner Metallstift, den ich mit einer Pinzette entfernen konnte. Damit war die Ursache des Plattens geklärt und beseitigt, nur das Loch im Luftschlauch war noch zu beheben. Aber dann fingen die Probleme an.

Erstmal war das Entfernen des Reifens gar nicht einfach. Bei einem Fahrrad ist da eine Schraube zu lösen, vielleicht die Kette wegzuheben. Beim M365 ist diese Schraube durch eine Plastikabdeckung verdeckt, die selbst mit zwei kleineren Schrauben befestigt ist, und diese Schrauben sind durch einen transparenten Plastikstreifen abgeklebt, auf dem ein roter Film aufgelegt ist.

Also muss man mit einem dünnen Messer unter den Plastikstreifen um ihn aufzuhebeln, im Idealfall ohne die rote Folie zu beschädigen, für die Optik später. Dann mit einem kleinen Inbusschlüssel die zwei Schrauben lösen (der mitgelieferte ist zu groß), Abdeckung abnehmen, dann die Schraube des Reifens lösen. Für diese Schraube braucht man wieder einen größeren Inbusschlüssel, größer auch als der mitgelieferte. Hier zu sehen (der Zweck des Ventilschlüssels rechts wird weiter unten erklärt):

Das muss auf beiden Seiten gemacht werden.

Dann hatte ich den Reifen in der Hand und wollte dieser Anleitung folgen:

Wie bei einem Fahrradreifen hebelt er da den Schlauch aus dem Reifen. Es ging bei mir absolut nicht. Der Reifen war für mich und mein Werkzeug viel zu hart. Auch nach mehreren Versuchen kam ich nicht ansatzweise an den Luftschlauch heran, keine Chance den aus dem Reifen zu entfernen. Also auch keine Chance, das Loch zu flicken.
Ich war erstmal ratlos, der Roller stand eine Weile kaputt in der Ecke.

Schließlich erinnerte ich mich an Methode 2: Der grüne Schleim.

Der grüne Schleim ist ein Reifendichtungsmittel, er wird in den Reifen gefüllt, am besten bevor er ein Loch hat – aber auch nachträglich kann er manchmal noch funktionieren. Er soll Löcher automatisch schließen, verdichtet sich sobald ein Fremdkörper eindringt. Da das Einfüllen ohne Rausnehmen des Schlauchs geht vermeidet er die ganze Arbeit, die ich vorher schon gemacht hatte und die Aufgabe, an der ich nun scheiterte. Tatsächlich finden sich einige Empfehlungen dafür dies beim M365 bei der Inbetriebnahme zu machen, nur dachte ich naiverweise, dass ich den Reifen sicher auch so repariert bekommen würde.

Statt auf Amazon das Slime aus den Videos zu kaufen ging ich zu Rewe und kaufte die Variante von Fischer, war etwas günstiger und ging schneller.

Was ich anfangs nicht verstanden hatte: Um das Zeug einzufüllen muss man das Schlauchventil rausschrauben, dass das geht war mir gar nicht klar. Beim Reifendichtungszeug war dafür ein Plastikaufsatz dabei. Der brach sofort ab, woraufhin ich die Plastikteile mühselig mit einer Pinzette aus dem Ventil herausfischen musste. Im Fahrradladen holte ich mir daraufhin einen kleinen Ventilschlüssel. Das war ein Fehler, ich brauchte einen mit Griff um das festsitzende Ventil lösen zu können, was sie netterweise später im Laden für mich erledigten.

Danach folgte ich im Grunde diesem Video, minus der Spritze:

Stattdessen hatte ich ausgerechnet, das ~30ml ausreichen sollten, was in etwa einem Zehntel der Flasche entspricht. Ich war zuversichtlich das mit ein paar Hilfsmarkierungen an der Flasche abschätzen zu können.

Also: Reifen wieder einbauen, Ventil herausschrauben, 30ml grünen Schleim einfüllen (bei mir wurde es etwas mehr), Ventil wieder reindrehen, Reifen drehen, aufpumpen. Ich machte das vorne (dort reiche zum Glück der kleine Ventilschlüssel) und hinten und fuhr dann direkt mit dem Roller los, das Dichtungsmittel soll sich ja gut verteilen.

Das scheint tatsächlich funktioniert zu haben. Auch nach der Testfahrt ist der Reifen noch prall gefüllt.

Diese Aktion trübt meinen Eindruck vom M365 ziemlich. Dass er einen Platten hatte ist an sich kein Problem, dafür kann er nichts. Mir war das Risiko bewusst, die Vorteile eines Reifens mit Luftschlauch überwiegen in meinen Augen. Aber der M365 ist schon verdammt blöd zu reparieren. Es gibt keinen Entschuldigung für die verschiedengroßen Schrauben, die den Zugang zum Reifen blockieren. Und wenn ein Produkt schon einen Luftschlauch im Reifen hat, dann muss der auch mit vernünftigem Aufwand entfernbar und ein Ersatz wieder montierbar sein. Vielleicht fehlte mir das richtige Werkzeug zum Entfernen des Schlauchs, da braucht man vielleicht härtere, für Autos/Roller gedachte Aufhebler. Aber wie in manchen Videos zu sehen zum Draufmontieren die Reifen vorher in die Mikrowelle stecken zu müssen kann doch nicht die richtige Lösung sein.

Man könnte sagen: War eben ein billiges Chinaprodukt. Aber soo günstig war der M365 gar nicht, und billig wirkt er ansonsten kaum. Außerdem ist es ja nicht so, dass es vernünftige Alternativen gäbe – zumindest meines Wissens nach. Es gibt ein paar europäische Kickroller bzw regulär in Europa verkaufte, aber die sind entweder maßlos überteuert oder viel schlechter als der Xiaomi. Und ob die teuren Modelle besser reparierbar sind? Reparierbarkeit wird von einem höheren Preis nicht garantiert, da braucht man sich nur Apple anzuschauen.

Ich hoffe jetzt einfach, dass die nächste Reparatur einfacher wird und die Reifen mit dem grünen Schleim lange halten werden.

Wieder mal ein Artikel, der auf beide Blogs gepasst hätte. Ich habe ja inzwischen einige Webanwendungen mit Sinatra geschrieben, bin aber auch in einige Probleme gelaufen, von denen einige ja auch hier dokumentiert wurden. Eine kleine allgemeinere Sammlung landete nun im Blog von pc-kombo, daher hier als Hinweis ein Link und ein Auszug:

The PC hardware recommender pc-kombo is written with Ruby and Sinatra, a very comfortable and powerful small framework to build web applications. Web applications is where Ruby shines in general, the language got popular together with the more complete (and opinionated) Ruby on Rails framework.

Sinatra is very nice to work with initially, but over the years it became clear to me that not everything works as good as it should. I’d still recommend it, but would urge beginners to be aware of its limitations.

Ich liste typische Probleme wie die nicht immer so offensichtlichen Routen-Evaluation, fehlende Funktionen, das verwirrende Rack-Ökosystem und auch die von Ruby selbst kommenden Limitierungen bei der Performance.

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.

Wieder tut sich etwas bei der Blogsoftware, die auch diesen Blog trägt. In Version 2.1.4 fixt Serendipity vor allem ein ziemlich ungefährliches Sicherheitsproblem. Die neue Alpha bringt dagegen eine ganze Reihe von Verbesserungen. Ich finde die Unterstützung von PHP 7.2 besonders wichtig, freue mich aber auch, die neue Galleriefunktion und die responsiven Bilder hier im Blog zu testen.

Es ist noch eine Alpha, weil schlicht nicht alles fertig geworden ist. Besonders meine Überarbeitung des internen Codes der Mediendatenbank ist nicht komplett. Ich hatte die Zugriffskontrollen und die Pluginevents herausgerissen, die sollten vor der Beta da erst wieder rein. Etwas mehr Praxistests wird dem Code ebenfalls gut tun.

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.