onli blogging

Das Reboot von 2013 ist das erste Spiel der Serie, das ich gespielt habe. Eines der Originale war mal in einer Spielesammlung, aber die auf die CD gepresste Spielversion war fehlerhaft. Klar kennt man Lara Croft und ich hatte damals Tests gelesen, aber so richtig wusste ich nicht was ich erwarten sollte.

Klettern, ein paar Rätsel und sehr viel mehr Schießen als von der Story her angelegt, damit hätte ich richtig gelegen. Dabei ist Tomb Raider in erster Linie sehr gut gemacht. Die Grafik ist toll, die Inszenierung ist besser. Es explodiert, die Kamera wackelt, Türme und Ruinen brechen zusammen, Lara springt von einer Extremsituation in die nächste, wird vom Storyverlauf immer wieder hart getroffen. Das wird fast etwas repetitiv, es ist voll und ganz unrealistisch, aber es ist doch unterhaltsam.

Zu Spielbeginn lässt ein Sturm das Schiff kentern, mit dem die junge Archäologin und ihre Crew zu einer Insel gelangen wollten. Überraschung: Sie stranden auf der richtigen Insel. Echte Überraschung: Sie sind nicht alleine auf der Insel. Die Gruppe wird getrennt, der Spieler lernt die Grundmechanismen und die Waffen kennen. Ohne zu viel von der relativ belanglosen Story verraten zu wollen geht es dann darum, der Insel zu entkommen.

Die Kämpfe können oft schleichend begonnen werden, Einzelsituationen so gelöst werden, aber das geht nicht immer und oft sind dann sehr viele Gegner zu besiegen. Dafür hat die Grabräuberin mehrere Waffen: Pfeil und Bogen, Pistole, Schrotflinte und Maschinengewehr. Auch Nahkampf ist eine Option, mit Axtangriffen und Quicktime-Events nach dem Ausweichen können Gegner erledigt werden. Da spielen stark die Fähigkeiten rein, die an den Lagerfeuern erworben werden können, Erfahrungspunkte werden dafür im Spielverlauf oder für Sammelobjekte vergeben. Die Balance aus solchen Nebenbeschäftigungen und dem eigentlichen Spielablauf fand ich gelungen. Ich hätte das Sammeln aller der Dokumente, Relikte und Materialien auch übertrieben erstnehmen und mir den Spielspaß kaputtmachen können, aber das Spiel forderte im Grunde nur, etwas aufmerksamer durch die Landschaft zu laufen.

Oder zu klettern. Denn das ist der andere Spielinhalt: Wege entdecken, an Seilen und Felsen entlang waghalsig zum nächsten Missionsmarker zu gelangen. Anders als in Enslaved sind diese Kletterpartien meist etwas anspruchsvoller. Dazu kommen noch kleinere Rätsel, besonders in den versteckten Grabkammern, in denen als Belohnung ein Schatz und damit Erfahrungspunkte und Ausrüstungsaufrüstungsmaterialien warten.

Als nervig empfand ich manche der Quicktime-Events, an ein paar Stellen bin ich ihretwegen mehrfach hintereinander gestorben. Unnötig. An ein paar Stellen fiel auch auf, dass die Kamera und die Inszenierung Gefahr und Spannung vorgaukeln wo keine war, ich als Spieler nur eine Bewegungstaste gedrückt hielt. Das waren aber nur kurze Abschnitte, normalerweise war dann doch immer mehr zu reagieren. Und es ist kein Spiel, das zur besseren Immersion Zwischensequenzen vermeidet. Das machen andere Computerspiele eleganter, selbst wenn die unsteuerbaren Abschnitte meist gut gemacht waren.

Nett dagegen: Das Interface bleibt sehr dezent, eingeblendet werden nur die gerade notwendigen Informationen. Das hilft dem Spiel, immer wieder mehr wie ein Film als wie ein reguläres Computerspiel auszusehen.

13 Stunden brauchte ich für die Story ohne übermäßig zu sammeln, das Outro schrieb ich habe 79% entdeckt, dabei wird es bleiben. Ich musste unter Proton spielen, die Linuxversion wollte mal wieder nicht starten. Das Spiel lief stabil, nur an einzelnen Stellen luden die Texturen von Personen einen Moment verzögert.

Ich fühlte mich die Spielzeit über sehr gut unterhalten. Tomb Raider wirkt auf mich wie ein gutes Beispiel für die Stärke von AAA-Spielen. Sowas kann nur ein großes Studio umsetzen, die Grafik, die Inszenierung, das Leveldesign. Hier ist das gelungen, ohne sich in einer Open-World voller Sammelaufgaben und Nebenmissionen zu verrennen. Ein gutes Spiel für einen Erstkontakt mit der Serie.

Nachdem ich erst vor kurzem LineageOS 16.0 auf dem LG G3 installiert hatte war ich mit dem Upgrade auf 17.1 zögerlich. 16.0 sollte ja noch Updates bekommen und ich hatte mich gerade erst an das System gewöhnt. Jetzt aber wollte ich es hinter mich bringen. Das Update war problemlos und relativ einfach.

Ich bin der generischen Upgradeanleitung gefolgt, beim G3 gibt es wohl keine Überraschungen. Das Telefon mit per USB-Kabel mit dem PC verbinden, in den Entwickleroptionen Root Access Options auf ADB Only oder Apps and ADB setzen. Die neue Lineageversion herunterladen und mit adb installieren (ohne Google, also ohne gapps):

onli@fallout:~/Downloads$ sudo killall adb
onli@fallout:~/Downloads$ sudo adb reboot sideload
* daemon not running; starting now at tcp:5037
* daemon started successfully
'adb root' is required for 'adb reboot sideload'.
onli@fallout:~/Downloads$ adb root
restarting adbd as root
onli@fallout:~/Downloads$ sudo adb reboot sideload
onli@fallout:~/Downloads$ sudo adb sideload lineage-17.1-20200423-nightly-d855-signed.zip
serving: 'lineage-17.1-20200423-nightly-d855-signed.zip'  (~47%)    adb: failed to read command: Success
onli@fallout:~/Downloads$ sudo adb reboot

Man beachte die vertrauenserweckenden 47% Endfortschritt samt Fehler: Erfolg-Meldung, aber trotzdem startete das neue System.

Was hat sich geändert? Nach dem Einschalten und dem ersten Entsperren hängt das System einen längeren Moment. Es gibt jetzt wieder ein System zur Designauswahl, daran erinnere ich mich von früheren Cyanogen-Experimenten, geht zumindest in die Richtung. Die Oberfläche fühlt sich schneller an, die Icons in der Schnellkontrolle oben sind umorganisiert worden.

Das Changelog liest sich auch eher wie das eines Updates mit begrenztem Umfang, aber das ist bei Android als stabilem System wohl schon ein paar Versionen so üblich.

Aber dann habe ich die Gestennavigation entdeckt (via, wobei die Seite bei mir gerade nicht lädt). Die gab es auch schon in Android 9, meine ich, aber da funktionierte sie für mich nicht. Warum genau weiß ich nicht mehr. Aber die Implementation in Android 10 funktioniert hervorragend! Android hatte ja vorher das Navigationssystem von webOS gekapert, mit der Übersicht der Fenster. Mit dem neuen System haben sie jetzt die auswendig zu lernenden Gesten als Kern der Navigation übernommen, wofür es unten einen angedeuteten Gestenbereich gibt. Das ganze ist bei Android aber optional und zusätzlich zu den Wischgesten unten muss für die Aktion Zurück von der Seite des Bildschirms eine Wischgeste gestartet werden, egal auf welcher Höhe. Sie haben das System also weiter auf Android angepasst. Der Fokus auf die Gesten, dass es dafür einen dedizierten Bereich gibt und welche Bewegungen gefordert werden wurde übernommen, aber die Appfensterliste ist nicht mehr feste Station der Navigation, außerdem ist (clever!) der Gestenbereich Teil des Bildschirms.

Es funktioniert so: In Settings -> System -> Gestures -> System Navigation auf Gesture Navigation umstellen. Danach verschwinden die drei Buttons unten, sie werden ersetzt durch einen weißen Strich (wieder: wie beim webOS-Palm).

Ins Appmenü führt eine Geste von unten nach oben, die gleiche führt auch wieder zum Desktop zurück, auch wenn statt des Menüs eine App offen war. Zurück in einer App geht über die Seiten. Zwischen Apps wechselt eine Bewegung von links nach rechts oder von rechts nach links, auszuführen im Bereich unten. Für die alte Appfensterübersicht muss man von unten halb nach oben und dann nach links wischen, die Liste bietet sich während der ersten Hälfte an. Das klingt vielleicht erstmal kompliziert. Ich weiß aber von meinem HP Veer, dass solche Gesten sehr schnell gelernt werden und dann sitzen, auch Jahre später. Toll!

Mir ging es ja vor allem darum, eine aktuelle Version eines freien Betriebssystems samt Sicherheitsupdates auf dem Telefon zu haben. Bei dem Ziel ist es bereits ohne solche Verbesserungen super, wenn das G3 weiterhin von einer großen Android-Distribution unterstützt wird. Von daher freue ich mich über das erfolgreiche Update auf Android 10/LineageOS 17.1.

Eines der meistgespielten Spiele aus meiner Spielesammlung wird gerade im Humble Bundle (wer möchte: Affiliate-Link) samt einiger Erweiterungen verkauft.

Cities: Skylines ist ein Simcity-Klon, der damals kurz nach einem gescheiterten Simcity-Reboot startete, den Macken wie eine verpflichtend dauerhaft bestehende Internetverbindung plagten. Skylines vermied solche Spielerdrangsalierungen und wurde so der Fanfavorit, die sympathischere Alternative.

Über Skylines habe ich mittlerweile einiges geschrieben und nichtmal nur im Blog. 2016 stellte ich hier das Spiel vor, lobte es und ging auf ein paar Schwachstellen ein. 2017 erweiterte ich das in einem Artikel über die bei mir auftretenden Simulationsfehler (die mittlerweile meinem Eindruck nach weniger spielblockierend sind). Vor einem Jahr folgte ein Artikel auf GamersGlobal über die Erweiterungen. Im Laufe der Jahre bekam Skylines einige davon. Ich habe für GG alle damals veröffentlichten und spielrelevanten vorgestellt und getestet.

Was meine ich mit spielrelevanten? Es gibt drei Arten von Erweiterungen für Skylines. Content Creator Packs, Radioerweiterungen und die anderen. Die ersten beiden halte ich für nicht relevant für normale Spieler. Content Creator Packs geben nur zusätzliche Assets, also z.B. neue Gebäude, die einem bestimmten Stil entsprechen. Ohne weitere Funktionen kann man damit nur seine Städte aufhübschen, wenn man sie gezielt einsetzt. Radioerweiterungen bringen neue Musik, was nett ist, aber man kann auch einfach seine eigene Musik im Hintergrund laufen lassen. Aber die anderen Erweiterungen, die sind relevant, denn sie bringen neue Funktionen wie z.B. neue Fortbewegungsmittel und lockern so den Spielablauf auf, wenn man das Grundspiel schon durch hat.

Mit dem Hintergrund ein paar Worte zum Bundle. Wer das Spiel noch nicht und auch nur minimal Interesse am Genre hat hat sollte auf jeden Fall zuschlagen. Die erste Stufe kostet 1€ und beinhaltet das Grundspiel sowie ein paar Musikstücke für das Ingame-Radio. Mit dem Grundspiel kann man sich schon locker 30 Stunden beschäftigen, ohne dass andere Erweiterungen nötig wären.

In der zweiten Stufe kommen dann ein paar echte Erweiterungen hinzu. Concerts, Snowfall und Natural Disasters. Doch ich muss warnen: Die sind nicht richtig toll. Concerts ist nett, aber eine kleine Erweiterung, in der ein Konzertgelände platziert und verbessert werden kann. Snowfall hat das Potential toll zu sein, denn der Wintereinbruch sieht nett aus und hat Auswirkungen auf den Verkehr und den (mit Snowfall eingeführten) Heizbedarf, aber es ist leider vermurkst: Es gibt nur ewige Schneekarten oder die gewöhnlichen, in denen nie Schnee fällt. Es bringt also enttäuschenderweise keinen dynamischen Jahreszeitenwechsel. Und Natural Disasters schließlich hat Zufallskatastrophen wie Kometeneinschläge, gegen die man Schutzgebäude wie Bunker und Warnsysteme bauen sollte. Das unterhält etwas, aber nicht lange. Snowfall und Natural Disasters sind zwei der ältesten Erweiterungen (After Dark gab es davor, ist aber inzwischen fast komplett im Grundspiel mit dabei), bei denen die Entwickler in ihren Erweiterungsmöglichkeiten scheinbar noch sehr beschränkt waren.

Wer mehr als die erste Stufe kaufen will sollte direkt zur dritten Stufe springen. Die Erweiterungen hier sind hervorragend. Mass Transit, Green Cities, Campus und Industries bringen alle gute neue Spielelemente. Mass Transit hat viele neue Transportmöglichkeiten, und da ein großer Teil des Spiels die Verkehrsplanung umfasst sind die angenehm spielauflockernd. Green Cities bringt alternative umweltschonende Zonen, was die Stadt aufhübscht und immer wieder eine nette Alternative ist, mit Vor- und Nachteilen. Campus bringt riesige Universitätsgebäude, die statt der Standarduniversität gebaut werden können. Diese Gebäude sind in einer Zone zusammengefasst, wobei diese Zone dann auflevelt und neue Gebäude freischaltet, was wiederum die Universität und umliegende Anwohnerzonen verbessert. Und schließlich Industries, was wahrscheinlich die beste Erweiterungen ist. In Industries wurde das Wirtschaftssystem überarbeitet. Statt wie zuvor einfach Industriezonen zu markieren und höchstens noch einen Industriezweig vorzugeben, können nun einzelne größere Fabriken und Betriebe platziert werden. Die fördern dann Rohstoffe oder verarbeiten sie, in mehrstufigen Abfolgen. Die Holzindustrie z.B. fällt Bäume, es gibt dann Bretter und Sägemehl, Möbel, Pellets und Papier, samt Bedarf für Produkte anderer Industriezweige. Was gut in das Spiel eingreift, denn gleichzeitig werden so Arbeitsplätze geschaffen und muss der dadurch entstehende Verkehr geleitet werden.

Wer das meiste aus den Erweiterungen ziehen will aktiviert sie nacheinander. So gibt es stufenweise neue Ergänzungen, die man in seine Stadt einbauen kann. Wer direkt mit den Erweiterungen anfängt wird sich an ihnen weniger erfreuen.

Es sei erwähnt, dass dieses Bundle nicht komplett ist, es gibt mit Parklife eine weitere gute ältere Erweiterung und mit Sunset Harbor ist die neueste nicht dabei, die ich auch selbst noch nicht getestet habe. Es ist auch durchaus möglich, dass Skylines nicht mehr ewig lange gepflegt wird und das Bundle ein Signal ist, dass bald ein Nachfolger angekündigt werden wird. Da weiß ich nichts genaues drüber, habe aber entsprechende Spekulationen gelesen. Das muss nicht vom Kauf abhalten, aber wer lieber auf einen Nachfolger warten wollte sollte sich dem bewusst sein.

Skylines läuft gut unter Linux, es ist eines der wenigen Linuxspiele die ich nicht mit Proton laufen lassen muss. Auch eine Bemerkung wert: Das Spiel hat die andere Person im Haus beim Zuschauen so fasziniert, dass sie das Computerspielen aufgenommen hat und Skylines jetzt auch selbst spielt. Alternativ oder zusätzlich zu den Erweiterungen gibt es eine aktive Modszene, die das Spiel gut erweitert hat. Wirklich einen Blick wert.

Viele gute Schauspieler in einem modernen Detektivkrimi, wobei dieser Detektiv namens Benoit Blanc (Daniel Craig) nicht wirklich die Hauptrolle ist. Das ist dagegen Marta Cabrera (Ana de Armas, das Hologram aus Blade Runner!), die Pflegerin des kürzlich verstorbenen Familienpatriarchs. Ein Selbstmord, oder nicht? Und wem wird das Erbe zufallen? Jeder in der dysfunktionalen Familie hat an ihm Interesse.

Knives Out ist einfach hervorragend gemacht. Klar angelehnt an die alten Detektivfilme wie Miss Marple und Poirot ist der Detektiv (unfassbar, dass das James Bond ist) mindestens so schrullig wie die Familienmitglieder und man könnte das alles erst für eine kleine Komödie halten. Würde dann aber verpassen, wie gut alles durchkonstruiert ist. Jede Szene hat eine Bedeutung, wenn etwas beiläufig erwähnt wird, wenn ein Objekt in irgendeiner Form vorkommt, wird es später wichtig werden.

Dabei schafft es die Story zu überraschen ohne unfair zu werden. Man hätte drauf kommen können, der Zuschauer bekommt alle notwendigen Hinweise. Das ist ein schöner Unterschied zu den älteren Varianten dieser Art von Film, wobei die auch nicht diese Art von Komödie waren, nicht zwischendrin das Gerne wechseln konnten. Knives Out ist zurecht ein großer Erfolg gewesen.

Der bekannteste XML-Verarbeitungshelfer im Rubyland ist sicherlich Nokogiri. Mit Nokogiri kann man schnell Informationen aus XML und HTML herausholen, per xpath oder CSS-Selektor. Ein Beispiel von der Webseite:

doc = Nokogiri::HTML(open('https://nokogiri.org/tutorials/installing_nokogiri.html'))

puts "### Search for nodes by css"
doc.css('nav ul.menu li a', 'article h2').each do |link|
  puts link.content
end

puts "### Search for nodes by xpath"
doc.xpath('//nav//ul//li/a', '//article//h2').each do |link|
  puts link.content
end

Gegen Nokogiri spricht eigentlich nur die Installation. Basierend auf der libxml, ist es desöfteren mindestens eine zusätzliche Abhängigkeit, an die man im Zweifel bei der Servereinrichtung denken muss. Manchmal führt es auch zu ganz komischen Problemen.

Hier setzt Oga an. Es hat diese Abhängigkeit einfach nicht. Das macht die Installation unproblematischer. Die API ist etwas anders als bei Nokogiri, einige der Unterschiede sind in einer Dokumentationsdatei beschrieben. Es ist aber schon sehr ähnlich:

onli@fallout:~$ irb
2.5.3 :001 > require 'oga'
 => true 
2.5.3 :002 > xml = Oga.parse_xml('<a><b test="def">abc</b></a>')
 => Document(
  children: NodeSet(Element(name: "a" children: NodeSet(Element(name: "b" attributes: [Attribute(name: "test" value: "def")] children: NodeSet(Text("abc"))))))
) 
2.5.3 :003 > xml.xpath('/a/b')
 => NodeSet(Element(name: "b" attributes: [Attribute(name: "test" value: "def")] children: NodeSet(Text("abc")))) 
2.5.3 :004 > xml.at_xpath('/a/b')
 => Element(name: "b" attributes: [Attribute(name: "test" value: "def")] children: NodeSet(Text("abc"))) 
2.5.3 :005 > xml.at_xpath('/a/b').get('test')
 => "def" 
2.5.3 :006 > xml.css('b')
 => NodeSet(Element(name: "b" attributes: [Attribute(name: "test" value: "def")] children: NodeSet(Text("abc"))))

Überraschenderweise bin ich mit Oga selbst noch in keinerlei Probleme gelaufen, seitdem ich beispielsweise das Blogsystem ursprung darauf umgestellt habe. Es fehlt allerdings an Dokumentation und Beispielen. Bei Nokogiri ist die offizielle Dokumentation auch schon spärlich, bei Oga ist es nochmal weniger, und es fehlen die zu Nokogiri vorhandenen vielen Stackoverflowantworten. Wie beim SAX-Parser, als ich für Oga in den Quellcode schauen musste um die implementierten Events herauszusuchen und Nokogiri wenigstens einen erklärenden Absatz auf der Webseite hatte.

Trotzdem etabliert sich Oga mittlerweile als Bestandteil meiner Rubyprojekte. Installationsprobleme zu vermeiden ist mir sehr wertvoll. Wem das ähnlich geht oder wer eine Alternative zu Nokogiri sucht sollte Oga eine Chance geben.

Vor kurzem schrieb ich darüber, wie ich mit dem SAX-Parser besser mit XML-Dateien umgehen konnte. Besser bedeutete, mit weniger Speicherbedarf schneller die gesuchten Informationen aus teils relativ großen XML-Dateien zu holen. Es half, aber der Server hatte immer noch spürbare Last durch die anderen Datenquellen: Den CSV-Dateien. Sie benutzen manche der Datenausgeber statt XML, und auch bei ihnen führte das naive Vorgehen zu extremen Speicher- und Prozessorbedarf.

Das naive Vorgehen war grob so:

hardwares = Database.instance.getHardwares
hardwares.each do |hardware|
    csv = cache.getset('csvApi') do
        csvGz = open("https://url/zur/csv.gz")
        unzippedCsv = Zlib::GzipReader.new(csvGz).read
        csv = CSV.parse(unzippedCsv, :headers => true)
        csv
    end
    return csv.detect{|line| line['id'] == hardware.id }
end

Es gab also ein Array mit den Bezugsobjekten, zu denen die Zeile mit ihrer ID aus der CSV-Datei gezogen werden soll. Optimiert ist da bereits, dass die CSV-Datei nicht mehrfach heruntergeladen wird. Dafür sorgt der lru-cache.

Wie geht es besser?

1. Speichereffizienter parsen

Der erste Schritt ist das Parsen der CSV-Datei. Der bisherige Code macht das in einem Rutsch und baut – ähnlich wie bei XML-Dateien – ein CSV-Objekt. Wenn wir stattdessen Zeile für Zeile durchgehen entsteht eine Chance, den Speicherbedarf zu reduzieren. Dalibor Nasevic hat dazu Codebeispiele und Benchmarkergebnisse. Der Code ändert sich so:

unzippedCsv = Zlib::GzipReader.new(csvGz)
csvFile = CSV.new(unzippedCsv, headers: true)
while line = csvFile.shift
     # do something
end

Der GzipReader liest nicht mehr die Datei auf einmal in den Speicher, mit diesem neuen Startpunkt geht der CSV-Parser zeilenweise durch die Datei. Wenn wir jetzt einfach das CSV-Objekt nachbauen bringt das nicht viel, aber es gibt uns die Möglichkeit etwas besseres zu bauen.

2. Mit fastcsv schneller parsen

Doch bleiben wir erstmal beim Parsen selbst. Derzeit benutzt der Code das in Ruby integrierte CSV-Modul. Doch es gibt Alternativen, insbesondere fastcsv. Das Gem kann in vielen Fällen das normale CSV-Modul direkt ersetzen und war in meinen Tests etwa doppelt so schnell.

require 'fastcsv'
csvFile = FastCSV.new(unzippedCsv, headers: true)

Nett, aber das Parsen der CSV-Datei war gar nicht das Problem. Das sparte ein paar Sekunden. Das eigentliche Problem war das spätere Durchsuchen des erstellten CSV-Objekts.

3. Mit Hash nicht suchen, sondern nachschlagen

Das ist eine Optimierung, die in jeder Sprache funktionieren wird.

Wenn CSV.parse ein CSV-Objekt erstellt, ist das im Grunde ein großes Array mit Arrays (headers: false) oder Hashs (headers: true) in den Arrayeinträgen. Entsprechend durchsucht der Code von oben dieses Array mit dem üblichen Enumerable.detect. Doch das bedeutet, dass für jedes Suchobjekt die CSV-Struktur durchgegangen werden muss, bis etwas gefunden wurde. Oder bis die Struktur durch ist und eben nichts gefunden wurde. Wenn es nur eine Datenstruktur gäbe, die für eine ID direkt die passende Zeile ausgeben könnte…

Die gibt es natürlich, genau das ist in Ruby der Hash. Da wir jetzt zeilenweise durch die CSV-Datei durchgehen und die Struktur selbst bauen können wir sie nutzen:

csv = cache.getset('csvApi') do
    …
    csv = {}
    while line = csvFile.shift
        csv[line['id']] = line
    end
    csv
end
return csv[hardware.id]

Das hier ist die große Optimierung. Anstatt mehrfach durch die riesige Datenmenge zu stöbern am Anfang mit etwas Mehraufwand die Hashstruktur zu erstellen spart danach so viel Zeit bei jedem Suchvorgang, dass minuten- bis stundenlange Prozesse in wenigen Sekunden fertig werden.

4. Ungenutzte Datenfelder rausschmeißen

Moment, da gibt es noch eine mögliche Optimierung, wieder völlig unabhängig von Ruby. Eventuell braucht es später gar nicht alle Felder, die in der CSV-Datei gespeichert sind. Vielleicht wird später nur nach price und available geschaut. Wenn dem so ist, dann ist genau hier der Moment die überflüssigen Felder zu entfernen und so den Speicherbedarf zu senken:

while line = csvFile.shift
    csv[line['id']] = line.to_h.keep_if{|k, _| k == 'price' || k == 'available' }
end

Die Kombination dieser vier Schritte ist sehr mächtig. Was vorher viele Minuten rödelte und Prozessorkerne voll auslastete ist in ein paar Sekunden erledigt. Aber es ist ja auch ein Idealfall. Es gab genau eine ID, wir in einer Hashmap als Key nutzen und dann nachschlagen konnten. Was, wenn es mehr als einen Key gibt?

5. SQLite für mehrere IDs

In meinem Anwendungsfall gab es manchmal neben der id noch die sku, also einen zweiten Key. Dann reicht ein Hash nicht, denn es gibt keine mir bekannte Möglichkeit, einen zweiten Key einzusetzen. Klar, wir könnten einen zweiten Hash erstellen. Aber würde das nicht den Speicherbedarf verdoppeln? Nein, es wäre besser einen zweiten Key als Index über die alte Hashmap zu legen. In Ruby wüsste ich nicht wie das geht (wenn du schon: Ein Kommentar wäre klasse!). Aber SQLite macht das mit links und ist in jeder Sprache verfügbar.

Die Idee also ist: Statt einer Hashmap erstellen wir eine SQLite-Datenbank im Arbeitsspeicher. Primary Key wird die id, aber für die sku baut SQLite einen Index. Das Durchsuchen geht dann mit ein bisschen SQL. YAML serialisiert die CSV-Zeile, die im Zweifel auch wieder wie in Schritt 4 speicheroptimiert werden könnte.

csv = cache.getset('csvApi') do
    …
    csvFile = FastCSV.new(result, :headers => true)
    db = SQLite3::Database.new(':memory:')
    db.execute "CREATE TABLE csv(id TEXT PRIMARY KEY, sku TEXT, line TEXT)"
    while line = csv.shift
        db.execute("INSERT OR IGNORE INTO csv(id, sku, line) VALUES(?, ?, ?)", line['id'], line['sku'], YAML::dump(line))
    end
    db.execute "CREATE INDEX csv_sku ON csv(sku)"
    db.execute "ANALYZE"
    db
end        

row = csv.execute("SELECT line FROM csv WHERE id = ?", hardware.id).first
unless row
    row = csv.execute("SELECT line FROM csv WHERE sku = ?", hardware.sku).first
end

if row
    return YAML::load(row[0])
end

SQLite ist unheimlich schnell, die CSV-Datei wird in sekundenschnelle durchsucht sein, je nach Größe natürlich.

Fazit

Wenn man es mal richtig macht… Ich fand das ein gutes Beispiel für einen Anwendungsfall von Informatik-Grundkenntnissen. Statt ein Array zu durchsuchen die Datenstruktur zu ändern und eine Hashmap zu nehmen ist Grundlagenstoff des Studiums, Standardbeispiel für O(1) statt O(n). Aber ich brauchte einen Moment um zu erkennen, dass das hier möglich ist, das komfortable CSV.parse hatte mir das versteckt. SQLite einzubauen und nach einem schnelleren Gem zu schauen ist dann vielleicht etwas mehr aus praktischer Erfahrung gezogen, aber liegt wenn man mal optimiert und und nach dem Datenbankkurs auch nicht mehr fern.

Mir hat dabei auch geholfen, diese Aufgabe als eigenes Projekt zu betrachten. Ursprünglich war das nur eine kleine Ecke im Code des Überprojekts (pc-kombo), schnell mal gebaut, abgewandelt aus Code der eine REST-API nach den Informationen fragt (wo solche Optimierungen nicht möglich sind). Jetzt ist die Ecke ausgelagert in ihr eigenes Git-Repository und der Code ist auf genau diese Aufgabe reduziert. Das macht es einfacher, solche Optimierungsmöglichkeiten zu sehen.

Auf jeden Fall lohnt sich der Aufwand. Zusammen mit der Reduzierung der Last durch XML-Dateien kann ich den großen Server bald wieder abschalten, der nach dem Scaleway-Umzug die temporäre Heimat dieses Mikroservice wurde. Aus dem Mikroservice wurde jetzt tatsächlich auch ein kleines Programm, das auf schmalerer Hardware wird laufen können. Das reduziert die Strom- oder die Hostingkosten dann schnell um ein paar hundert Euro im Jahr.

Enslaved ist ein Action-Adventure. In einer apokalyptischen Zukunft steuert der Spieler Monkey. Direkt in der Einleitung entkommt er seinen Entführern und trifft auf die junge Trip, die mit ihm einen Flugzeugabsturz übersteht. Danach aber nutzt sie einen Moment der Bewusstlosigkeit, um mit einem Halsband der Sklaventreiber Monkey zu versklaven. Er soll ihr helfen, ihre Heimat zu erreichen – fernab im Westen. Ob er will oder nicht.

Monkey kann ihr helfen, denn er kann kämpfen und klettern. Kämpfe gibt es zuhauf gegen die Mechs der Sklaventreiber, die in der ganzen zerstörten Welt stationiert zu sein scheinen. Und nur Klettern bahnt einen Weg durch die alten Ruinen. New York, wo das Flugzeug abstürzte, ist menschenleer und mehr Dschungel als Stadt.

Mit einzusammelnden Orbs können Monkeys Kampffähigkeiten verbessert werden, neue Angriffe, mehr Leben. Die Upgrades sind hilfreich, aber nicht unbedingt notwendig, auch können die Orbs kaum verpasst werden, so zahlreich sind sie.

Die Kämpfe funktionieren dabei ganz gut. Anfangs reichen die Standardangriffe, später muss man auf den Zustand des Gegners achten, ein Schild erst mit dem Betäubungsangriff deaktivieren, stärkere Angriffskombinationen gegen mehrere Gegner einsetzen. Dazu kommen Fernkampfangriffe, gegen die entfernteren Mechs oder um Kämpfe einfacher zu machen. Ich bin schon ein paarmal gestorben, aber das beschränkte sich auf einzelne schwierigere Stellen, der Großteil der Kämpfe war einfach.

Die Kletterpassagen sind die andere Hälfte des Spiels, aber sie sind ziemlich witzlos. Anders als in Prince of Persia kann man sich nicht vertun und ins Leere springen, sondern es gibt immer genau eine Möglichkeit weiterzumachen. Sie sind also praktisch nur Zierde. Erst spät kommt dann bei manchen Passagen Timing hinzu, dass z.B. eine Flamme manchmal ausgeht und man nur dann zum nächsten Punkt springen sollte.

Enslaved ist von 2010. Ich erinnere mich an die Reviews von damals, die das Spiel sehr gut, aber nicht perfekt fanden. GamersGlobal z.B. vergab eine 8.5. Ich fand es auch gut, aber schlechter als mich die Reviews von damals glauben machten. Die Dynamik zwischen Trip und Monkey ist simpel – sie ist jung, hübsch und braucht Hilfe, Monkey ist kein Monster. Die Spannung, die aus der Zwangssituation hätte entstehen können, wird dadurch nicht genutzt. Die Geschichte steuert auf ein anderes Finale um eine Pyramide zu, das aber zu unvermittelt kommt, sie ist nicht bis zum Ende gut strukturiert. Bis dahin motiviert sie aber doch, die Rettungsgeschichte am Anfang, die Versuche ein Verhältnis zwischen den beiden zu entwickeln, die Weltentdeckung, auch dass die Gespräche super vertont sind und so die Charaktere einem sympathisch werden hilft. Aber leider ist die Grafik der alten Konsolengeneration heutzutage ziemlich schlecht. Sie ist nicht direkt hässlich. Es gibt ein paar coole Umgebungen, in Farben und Design sieht man die Arbeit guter Grafiker. Aber technisch ist das Spiel angestaubt, die Texturen und Objekte detailarm, die Charaktermodelle klar aus einem älteren Videospiel.

Die Begleitersituation lädt zum Vergleich mit Bioshock Infinite ein. Und ich muss mich korrigieren: Infinite war nicht das erste Spiel, in dem das Problem der nervigen Begleiter gelöst wurde. Auch Enslaved schafft das, indem Trip fast nie direkt in Gefahr ist, auch nicht blöd herumläuft, sondern vorsichtig vom Spieldesign geführt und in Sicherheit gebracht wird. Das funktioniert, aber Trip hat nicht den direkten Einfluß, nicht den Charakter, den Elizabeth in Infinite im Spiel selbst entwickelt. Es fehlen die Animationen, die Kommentare, die zufällige Unterstützung im Kampf. Ein großer Fehler sind die wenigen Momente, in denen sie eben doch wie in alten Spielen sterben kann und dadurch dem Spieler nervig werden könnte. Dazu die ganze Kontrollgeschichte – nein, zu Infinite war es noch ein weiter Weg. Und doch: Nicht alleine durch die Spielwelt zu laufen, sondern mit jemandem, durch den Begleiter die Story getragen zu haben und die vielen Möglichkeiten für Gespräche, das funktioniert auch hier wieder. Ein erstaunlich mächtiges Instrument für Spiele, überraschend oft ungenutzt.

Ich habe Enslaved: Odyssey to the West zwar gerne gespielt und sogar durchgespielt, aber es ist nicht gut gealtert und hat bei Grafik, Story, Kämpfen und vor allem den Kletterpassagen viele Schwachstellen. Es sollte mit einem Controller gespielt werden und lief gut unter Proton. Einen Blick wert, aber wer es damals verpasste muss es heute nicht unbedingt nachholen.

Vom Code aus Bilder erstellen – da landet man dann schnell bei SVG. Um unter Ruby ein SVG zu erstellen kann victor benutzt werden. Das Readme zeigt direkt wie es geht. Dieser Code:

require 'victor'

svg = Victor::SVG.new width: 140, height: 100, style: { background: '#ddd' }

svg.build do 
  rect x: 10, y: 10, width: 120, height: 80, rx: 10, fill: '#666'
  
  circle cx: 50, cy: 50, r: 30, fill: 'yellow'
  circle cx: 58, cy: 32, r: 4, fill: 'black'
  polygon points: %w[45,50 80,30 80,70], fill: '#666'

  3.times do |i|
    x = 80 + i*18
    circle cx: x, cy: 50, r: 4, fill: 'yellow'
  end
end

svg.save 'pacman'

erstellt diese Grafik:

Cool: Der Code hinter dem gem ist ziemlich minimal, das ist fast nur eine intelligent gestrickte kleine API, die genau richtig den Funken Komplexität versteckt, wegen dem man SVGs anonsten nicht per Hand schreiben will. Samt hilfreichen Beispielen wird es ein praktisches Werkzeug.

Ich finde es toll, wie SVG immer wieder in Projekte von mir reinrutscht. Nicht, weil es bei mir besonders beliebt wäre, sondern schlicht weil es immer wieder gut ein Problem löst.

Mit dem neuen Acer CB242Y konnte ich jetzt zum ersten mal richtig Freesync unter Linux testen. Mein Ersteindruck: Das geht ja gar nicht, alles stürzt ab. Zweiter Eindruck nach Neukonfiguration: Funktioniert einwandfrei und ist nett. Halten wir mal fest, wie das einzurichten und zu testen ist.

Einrichten

Der Monitor muss mit dem Displayport verbunden sein. HDMI funktioniert unter Windows, derzeit aber nicht unter Linux. Phoronix schrieb im Oktober 2019, dass sich das ändern soll, aber bisher sah ich dazu noch nichts neues und bei mir funktionierte Freesync unter HDMI nicht.

Dann, klar, muss Freesync im Monitormenü aktiviert werden. Dafür gibt es normalerweise eine Option, manche Monitore sind doof und verstecken sie in einem Game-Modus.

Jetzt zur Linuxseite. Erstmal zu meinem System. Meine Grafikkarte ist eine Radeon RX 580. Kernel:

onli@fallout:~$ uname -a
Linux fallout 5.6.11_1 #1 SMP Wed May 6 19:42:50 UTC 2020 x86_64 GNU/Linux

Mesa:

onli@fallout:~$ glxinfo | grep "OpenGL core profile version string"
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.6

Eventuell musst du gar nichts konfigurieren. Im Terminal, prüfe die Ausgabe von xrandr --props und suche nach vrr:

vrr_capable: 1 
	range: (0, 1)

Hier ist Freesync also an, 0 wäre aus. Vorsicht: Es gibt einen eigenen Eintrag für jeden Monitoreingang, da kann man sich schnell vertun.

Ist es 0 sollte die xorg.conf angepasst werden. Dafür fügt man eine Konfigurationsdatei in xorg.conf.d/ hinzu oder editiert die bestehende:

onli@fallout:~$ cat /usr/share/X11/xorg.conf.d/10-amdgpu.conf 
Section "OutputClass"
	Identifier "AMDgpu"
	MatchDriver "amdgpu"
	Driver "amdgpu"
	Option  "VariableRefresh" "true"
	Option	"TearFree" "true"
EndSection

Mit einer Nvidia-Grafikkarte sähe das natürlich anders aus. Für den amdgpu-Treiber ist VariableRefresh die Option für Freesync, TearFree ist eine andere Rucklervermeidung wenn die FPS über der Monitor-Bildwiederholrate sind, optional.

Bei mir nicht optional: V-Sync. Ist das nicht an funktionierte Freesync nicht. Auch das mag sich noch ändern oder vom jeweiligen Spiel abhängen, aber bisher muss ich es systemweit erzwingen. Dafür setze ich beim Systemstart:

export vblank_mode=3

Jetzt sollten Programme im Vollbild(!) mit Freesync Ruckler und Tearing vermeiden.

Testen

Aber funktioniert es überhaupt in Praxis? Der Effekt ist normalerweise nicht so stark, dass man das direkt bemerkt. Spezielle Testsequenzen können es aber deutlich zeigen. Ein richtig gutes und absurderweise unbekanntes Programm dafür ist VRRTest. Es zeichnet graue Balken, die schnell von links nach rechts huschen. Wird die Bildwiederholrate des Monitors getroffen oder ist Freesync an ist das eine glatte Bewegung, ohne Freesync wird bei niedrigeren FPS deutlich unglatt, die Balken verursachen viel Tearing.

Es ist das einzige mir bekannte Programm, mit dem man Freesync unter Linux testen kann. Nett: Es hat ein AppImage! Installation ist also simpel. Lade von der Releaseseite das AppImage herunter und mache es ausführbar.

Bevor du es startest, solltest du deinen Compositor deaktivieren. Bei mir läuft picom, also beende ich den:

killall picom

Wenn GNOME oder KDE als Desktopumgebung benutzt wird haben die ihren eigenen Compositor integriert, der hoffentlich irgendwo in den Einstellungen deaktivierbar ist oder sich von selbst bei aktiven Vollbildanwendungen ausschaltet. Wayland unterstützt Freesync noch nicht, sagt auch das Arch-Wiki, gleichzeitig wird aber Unterstützung im Wayland-WM sway erwähnt, da scheint sich also gerade ein bisschen was zu tun. Im Zweifel: Wayland deaktivieren.

Dann kann vrrTest gestartet werden. Die Anwendung öffnet ihre Testoberfläche im Vollbild. Das sieht dann so aus:

Der Text oben links erklärt die Bedienung: Mit den Pfeiltasten die FPS auswählen. Ich fand es gut, erst auf die Monitorbildwiederholrate zu schalten, bei mir sind das 75, und mit b die genauere FPS-Zählung zu aktivieren. Wenn ich dann runtergehe wird es ohne Freesync ruckelig, mit Freesync bleibt es stabil, bis ich dann die 49 FPS erreiche und wohl die Freesync-Range verlassen wird.

Fazit: Kinderschuhe

Linux hängt hier doch deutlich hinterher. Kein Freesync über HDMI, keine einfache Aktivierung in einem grafischen Treiberverwaltungsprogramm, X konfigurierte ich seit vielen Jahren sonst nur noch zum Bugfixing in instabilen Distributionen. Blöd auch, dass die Funktion überhaupt so intransparent ist das Testprogramme nötig sind. Der Konflikt mit dem Compositor ist auch unpraktisch. Ich kann zudem gar nicht sicher sein, dass die Abstürze vom ersten Test nicht wiederkommen.

Aber immerhin: Freesync wird offiziell von AMD unter Linux unterstützt, es funktioniert verifizierbar in Praxis und der Effekt wenn es greift ist ziemlich cool. Ich freue mich, bei der Monitorauswahl auf die Funktion bestanden zu haben.

Update 17.05.: Ich habe im pc-kombo-Blog ein tiefgehenderes Review des CB242Y veröffentlicht. Mir wurde beim Schreiben desselben deutlich, dass das Panel weniger perfekt spielegeeignet ist als ursprünglich gedacht, wobei mein subjektiver Eindruck weiterhin positiv bleibt.

Mein Fazit nach dem Durchgehen der 1440p-Monitore sagte ja ziemlich deutlich, dass die 1080p-Modelle mir sinnvoller erscheinen. Ich bestellte dann tatsächlich einen aus der günstigeren Liste: Den Acer CB242Y in der Acer unbekannten bmiprx-Variante, also in schwarzem Plastik samt dem für Freesync unter Linux so wichtigem Displayport. Er hakt auf dem Papier alle Anforderungen ab, und auch in der Praxis macht er einen guten Eindruck. Mehr noch: Ein Volltreffer.

Verarbeitung und Details

Wenn ich den Acer mit dem HP 27q, dem Dell U2312HM und dem Übergangsmonitor vergleiche, einem alten Blaupunkt-Fernseher, sitzt der Acer zwischen dem Dell und dem HP. Er ist mit seinem schwarzen Plastik nicht ganz so schick, zwischen dem Panel und der dünnen Kante ist ein sichtbarerer Spalt. Aber es ist eben eine dünne Kante, nicht wie beim Dell ein dickes Stück Plastik an der Seite, und wie beim HP ist der untere Rand hervorgehoben, hier durch dickeres geriffeltes Plastik. Eine andere Variation des gleichen Designs. Das Material ist übrigens matt, kein Fingerabdruckmagnet, wobei Berührungen am Standfuß leichter sichtbare Spuren hinterlassen. Rechts unten ist eine kleine blaue LED, die sich leider nicht abstellen lässt. Den Großteil der Zeit kann ich sie ignorieren, aber manchmal stört sie mich, ich werde sie vielleicht abkleben.

Der Standfuß ist nicht so gut wie der vom Dell, aber besser als der vom HP. Wenn der Tisch wackelt, wackelt auch der Monitor etwas (seitlich), eben etwas mehr als nötig. Dafür steht er viel stabiler als der 27q, den ja der Kater umgeworfen hatte, dass sich das wiederholt ist unwahrscheinlich. Er ist höhenverstellbar, neig- und kippbar, ziemlich perfekt in der Hinsicht.

Das Netzteil ist integriert, was gut ist, so ist unter dem Schreibtisch ein Block weniger. Das OSD-Menü hat einen kleinen Kippschalter zum Steuern. Wesentlich besser als wenn der nicht da ist, nur eine Fernbedienung wäre noch besser.

Die Verarbeitung erscheint mir im Detail etwas schlampig, es sei mehr der Vollständigkeit halber erwähnt. Es ist eben ein Budgetmonitor, wenn man sucht merkt man das dann doch. An der Spalte zwischen Panel und Plastikrand sind ein paar Punkte, die bei entsprechendem Lichteinfall reflektieren. An der Kante seitlich sind ein paar Unregelmäßigkeiten, als ob da das Plastik nicht ganz sauber geschnitten worden wäre. In Makrofotografie würde das doof aussehen, normal davorsitzend ist es akzeptabel.

Bild und Panel

Mein Ersteindruck nach dem Einschalten: Perfekt. Alles sah gut aus, ich konnte kein Backlight-Bleeding feststellen. Ein Blick auf die Monitorkalibrierungsseite lagom zeigte dann: Ja, zumindest gut. Der Kontrasttest sah wirklich ordentlich aus. Dafür ist der Gammawert etwas daneben, die Bänder scheinen mir nicht bei der 2.2 zu verschmelzen (und die Einstellung dafür ist im Monitor auf 2.2, die 1.8 und 2.4 bewegen es nur weiter weg), sondern bei 2.3 oder 2.4. Beim Test für schwarz und weiß ist jeweils das schwierigste Quadrat für mich kaum (schwarz) oder nicht (weiß) zu erkennen. Ich habe ein bisschen mit den Einstellungen gespielt, aber bisher die Standardeinstellungen nicht verbessern können, nur die Helligkeit musste ich (wie immer) runterregeln.

Spieletauglich? Scheint so! Ich habe gestern eine ganze Weile gespielt und keinerlei Probleme bemerkt. Overdrive auf Normal, Freesync ist aus (dazu später mehr). Ich müsste es noch mit richtig schnellen Spielen testen, aber wenn ich bisher nichts negatives bemerkt habe werden die Reaktionszeiten garantiert für meinen Spielekonsum ausreichen. Die Bildwiederholrate ist durchgängig bei 75Hz, egal ob Freesync an oder aus ist.

Allerdings stellt sich dann im dunklen Raum bei einem dunklen Hintergrund heraus, dass da doch etwas ungleichmäßige Hintergrundbeleuchtung wahrnehmbar ist. Gerade in der rechten oberen Ecke wird das schwarz etwas grauer. Der Effekt ist nicht deutlich und viel geringer als beim HP, aber das Panel ist in der Hinsicht eben doch nicht so perfekt wie der alte Dell. Wichtig zu beachten (auch für mich): Der Effekt ist subtil, problemlos ignorierbar, was für einen modernen günstigen Monitor eher selten zu sein scheint.

Wie bei IPS üblich sind die Blickwinkel völlig ausreichend stabil. Ob ich direkt davor sitze oder quer im Stuhl liege: Das Bild bleibt wie es sein soll.

Sehr seltsam und meinem Eindruck nach komplett unbrauchbar ist der VRB-Modus. Visual Response Boost erklärt prad im Test eines anderen Acer-Monitors. Da werden also schwarze Frames eingefügt, um dem Auge schnellere Übergänge vorzugaukeln. Beim CB24 wird sobald ich die Funktion anmache das Bild grau (klar, die schwarzen Frames reduzieren die Gesamthelligkeit) und super-pulsierend, unerträglich. Overdrive auf Extrem ist auch nicht empfehlenswert, das sorgt für deutliche Artefakte (inverse ghosting?), aber Normal funktioniert.

Dass Spiele mit aktiviertem Freesync instabil waren lag sicher an Linux, das teste ich noch etwas mehr und schreibe dazu später einen eigenen Artikel. Der Monitor selbst konnte Freesync, ich konnte einen positiven Effekt von 75 bis 50 FPS feststellen (gut möglich, dass unter Windows Freesyncunterstützung bis zur spezifizierten Untergrenze von 48 FPS erreicht wird).

Fazit

Gut! Ich habe mit einem Coupon 120€ bei Galaxus bezahlt und dafür jetzt wieder einen spieletauglichen Monitor, der anders als der Übergangsmonitor keine Probleme hat Text darzustellen. Das Panel ist ordentlich, das Einstellungsmenü nicht hirnverbrannt, er hat die Anschlüsse die ich haben wollte (plus Audioeingang und -ausgang) und der Standfuß ist ziemlich gut. Die Platte des Standfuß ist vielleicht etwas groß, aber wenn das der Preis für katzensichere Stabilität sein sollte ist auch das okay.

Weiterhin ist wie erwartet der Sprung zurück auf 1080p nicht allzu schlimm. Ja, vielleicht war der Ersteindruck Der Text sieht weich aus nicht 100% nur der Kontrast zum blöden Postprocessing des Fernsehers, sondern auch die geringere DPI zum HP 27q. Aber unscharf oder schlecht aussehend ist da nichts. Scheint mir wirklich so, als müsse die DPI deutlich höher steigen um einen echten Effekt zu haben.
Vielleicht kommt das ja in ein paar Jahren mit dem Nachfolgemonitor. Jetzt ist erstmal für eine hoffentlich lange Zeit die Monitorsuche beendet.

Am 14. April schickte mir Scaleway diese Email:

C2 & ARM64 Instances end-of-life — Migrate now to Virtual Instances & Bare Metal cloud servers

Dear customer,

As of December 1 st, 2020, our C2 and ARM64 Instances will reach their end-of-life. The physical servers hosting them are indeed randomly affected by several stability issues, which prevent us from fully guaranteeing the overall quality of service. Rest assured, however, that we are committed to guiding you in your migration and provide you with the best matching resources for improved stability, performance and reliability.

Starting from April 14th, 2020, it is no longer possible to create new C2 and ARM64 Instances. In addition, their support will end on July 1st, 2020. As a result, our technical assistance will no longer address issues related to those instances. A price increase is also to be expected on July 1st, 2020. Lastly, C2 and ARM64 Instances will be completely deprovisioned as of December 1st, 2020.

Das betraf direkt alle drei meiner Scaleway-Instance. Ich hatte zwei kleine ARM64-Instanzen, von denen eine diesen Blog und die andere einen Microservice für pc-kombo betrieb. Die dritte war eine C2-Instanz, auf der pc-kombo selbst lief. Diese Email bedeutete für mich also vor allem Arbeit. Aber ich war gar nicht arg verärgert: Hosterwechsel oder zumindest Serverwechsel sind ja immer auch eine Chance, etwas schnelleres zu erwischen. Beides war richtig: Es war eine Menge Arbeit, und alle drei Projekte dürften jetzt schneller sein.

Blog: Scaleway zu Vultr

Den Anfang machte die unkritischste Seite, dieser Blog. Ich wollte wieder eine möglichst günstige Lösung haben. Spart Geld, aber nicht nur das: Ein Serverchen sollte für die Besucheranzahl dieser Seite auch wirklich ausreichen, zudem kann es für Serendipity nur gut sein, wenn ein weiterer Entwickler Performance auf schwächeren Servern durch den eigenen Blog im Blick hat.

Ich bin dann bei Vultr gelandet. Das waren die möglichen Angebote:

Als ich dann nach etwas Recherche feststellte, dass dank Cloudflare auch IPv4-Besucher die Seite erreichen würden, wählte ich das günstigste Angebot, das nur mit IPv6 auskommt.

Was ich da noch nicht wusste: Github kann kein IPv6. Serendipity will aber mit Github kommunizieren, um Plugins und sich selbst zu aktualisieren. Da hilft dann auch Cloudflare nicht. Aber so entstehen eben neue Serendipity-Entwicklungen: Es gibt jetzt einen Mirror auf Gitlab, der Pluginupdates ausliefern kann und der Code dafür ist im aktuellen Master. Jetzt fehlt nur noch, die Versionsprüfung und das Autoupdate-Plugin ebenfalls auf Gitlab zurückfallen zu lassen.

Wie schlug sich vultr selbst? Ziemlich gut. Die Verwaltungsoberfläche ist simpel und funktioniert, auch beim Server gab es keine Überraschungen. Der einzelne Prozessorkern war im Benchmark stärker als ein ARM64-Kern von Scaleway:

Scaleway:

root@onli-blogging-armv8:~# sysbench --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   619.61

General statistics:
    total time:                          10.0017s
    total number of events:              6202

Latency (ms):
         min:                                    1.55
         avg:                                    1.61
         max:                                   16.27
         95th percentile:                        1.70
         sum:                                 9977.69

Threads fairness:
    events (avg/stddev):           6202.0000/0.00
    execution time (avg/stddev):   9.9777/0.00

vultr:

root@onli-blogging:/var/www/html# sysbench --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   752.41

General statistics:
    total time:                          10.0013s
    total number of events:              7528

Latency (ms):
         min:                                    1.19
         avg:                                    1.33
         max:                                    8.34
         95th percentile:                        1.47
         sum:                                 9984.29

Threads fairness:
    events (avg/stddev):           7528.0000/0.00
    execution time (avg/stddev):   9.9843/0.00

Andererseits hatte die Scaleway-Instanz 4 dieser Kerne, war also insgesamt deutlich stärker. Im Betrieb aber fühlt sich die Seite seit dem Wechsel schneller an. Entweder, weil bei einzelnen Besuchern immer nur der eine stärkere Kern zählt, vielleicht ist die SSD schneller angebunden, oder es ist einfach die neuere Linuxversion.

Es gibt sogar ein affiliate-Programm, wer über diesen Link einen Account macht und selbst $10 ausgibt schenkt mir $10. Und derzeit läuft eine Sonderaktion, die dem sich darüber anmeldenden Nutzer für 30 Tage $100 gibt, der erste Monat also umsonst wäre. Nett.

Der Wechsel zu vultr war also gut, es war aber einiges an Arbeit weil die Emails nicht funktionieren wollten. Sie gingen einfach nicht raus, auch wenn ich mein Bestes versuchte die Konfiguration der Scaleway-Installation zu kopieren. Wahrscheinlich war der Port blockiert? Ich musste das neu einrichten, mit uberspace als Relay. Das herauszufinden kostete mich Stunden.

PC-Kombo: Scaleway zu Scaleway

Für pc-kombo bin ich nach einiger Recherche bei Scaleway geblieben. Ich brauchte folgendes:

1. Mehrere Kerne, damit problemlos mehrere Dienste parallel laufen können und auch Besucherspitzen abgefangen werden können.
2. Genug Ram, um weiterhin die Seite mit LRU-Cache und Memoization zu beschleunigen.

Natürlich kriegt man das auch anderswo, im Zweifel für viel Geld. Hetzner zum Beispiel hätte ohne hohen Preis gepasst, da liegt allerdings schon Pipes, zu riskant. Am Ende waren die Angebote bei Scaleway für mich die attraktivsten. Großer Pluspunkt: Die Migration innerhalb Scaleways sollte einfach sein, oder?

Falsch: Ich lief da ins offene Messer. Als ich die C2-Instanz herunterfuhr um mit dem Management-Interface ein Backup zu machen und dann komfortabel mit Scaleways Bordmitteln auf einer neuen DEV-Instanz die Seite wieder einzurichten, dieser Anleitung folgend, fuhr sie nicht mehr hoch. Scaleway hatte meine Instanz weggegeben oder ganz abgeschaltet und keine Reserven mehr über. Es gab eine üble und hektische Downtime, in der ich mittels meiner eigenen Backups (Gott sie dank hatte ich die!) die Seite wieder einzurichten versuchte und parallel den Migrationsanweisungen von Scaleway folgte, die dann nur mit Supporthilfe funktionierten. Zusammenschrieb hier.

Das war also Mist. Immerhin: Seitdem funktioniert die Seite auf der neuen DEV-Instanz ohne weitere Probleme.

Mikroservice: Scaleway zu Heimserver

Ich habe hier daheim zwei kleine ARM-Miniserver: Einen Pogo und einen CHIP. Erst wollte ich damit die Scaleway-Instanz mit dem Mikroservice ersetzen. Stellte sich aber raus, dass der CHIP nicht stabil läuft und der Pogo keine Kapazitäten mehr frei hat, dass der Speicher und Prozessorbedarf meines Services (Preisaktualisierungen laufen darüber, XML, JSON und CSV muss geparst werden) für die beiden auch etwas zu hoch ist. Aber worüber ich noch gar nicht geschrieben habe: Für die Wissenschaftlerin im Haus lag hier auch noch ein alter Dual-Xeon-Server rum, ein HP Proliant G6, mit 48GB Ram. Der wäre definitiv stark genug.

Für den Test mit dem CHIP hatte ich den Service schon so umgebaut, dass eine ausfallende Internetverbindung kein Problem ist, er wartet dann einfach. Schnelles Internet wird auch nicht benötigt. Kritisch war der Lärm. Ich verwandte etwas Zeit darauf, den Server so leise wie möglich zu machen: Stromsparmodus (sowieso eine gute Idee), die Xeons sind auch untertaktet stark genug, keine Redundanz der Netzteile. Dann brauchte ich noch einen Platz, der etwas Lärm frisst und sich nicht zu stark aufheizt. Es wurde ein Wandschrank mit jetzt nur noch angelehnter Tür.

Das ist vielleicht auf Dauer nicht die günstigste Lösung aufgrund des Stromverbrauchs. Andererseits ist es nett, mal etwas mehr (und ansonsten richtig teure) Rechenleistung zur Hand zu haben. Ich habe direkt noch weitere Aufgaben für ihn im Blick. Was die kleine Scaleway-Instanz noch überforderte ist für den alten Server ein Kinderspiel, er langweilt sich.

Die Migration ist beendet. Keine meiner Seiten/Projekte liegt noch bei Scaleways ARM-Instanzen, die sie abschalten. Für Scaleway nicht ganz so toll: Obwohl ich ihnen als Kunde erhalten bleibe ist meine Monatsrechnung dort jetzt geringer, zudem kommt mit vultr ein weiterer günstiger und solider Hoster zu den von mir getesteten und positiv befundenen (Scaleway, Digital Ocean, Hetzner Cloud, vultr). Trotzdem ist die Abschaltung sicher richtig: Auch ich sah vorher Instabilitäten, gerade der Mikroservice lief nicht sauber. Sowas zu bereinigen vermeidet Enttäuschungen. Andererseits schade, dass jetzt keine günstige Bare-Metal-Lösung mehr angeboten wird. Damit war Scaleway gestartet und Probleme durch lastverursachende Nachbarn zu vermeiden hat einen gewissen Wert.

Ein Western von Quentin Tarantino. Die Geschichte bleibt dabei länger im unklaren und wechselt dann die Zeitebene, was die Situation für den Zuschauer auflöst. Sogar für einen Film von Tarantino ist sie dabei besonders brutal.

Ich finde es ja immer toll, wenn Kurt Russel in einem Film auftaucht. Und auch die meisten anderen Tarantino-Schauspieler haben bei mir einen Bonus. Und doch: The Hateful Eight hat mich nicht gepackt. Zu unbarmherzig ist die Geschichte, keinerlei Sympathie ist möglich, und dabei ist das alles auch nicht so spannend, dass ich dem Film das verzeihen konnte.

Wäre vielleicht etwas anderes gewesen, wenn der Zeitebenen- oder Perspektivenwechsel als Kniff für mich neu gewesen wäre.

Ubuntu 20.04 integriert Snaps stärker als zuvor in das Gesamtsystem. Während Ubuntu wie Debian eigentlich .debs benutzt, um Programme und Updates zu verteilen, werden jetzt mehr Teile per Snap ausgeliefert. Und das ist eigentlich eine tolle Sache: Denn Snaps sind nicht auf Ubuntu beschränkt. Sie können auch auf anderen Distributionen laufen. Zudem enthalten sie ihre Abhängigkeiten, dass Software im Laufe der Zeit auf neuen Linuxumgebungen nicht mehr startet wird dadurch gelöst oder zumindest minimiert. Zudem waren .debs nicht besonders einfach zu bauen. In der Hinsicht sind Snaps ähnlich wie Flatpaks oder das hervorragende AppImage eine gute Verbesserung. Ich bin ein Fan des Konzepts.

Aber es gibt auch Nachteile. Manche sind konzeptbedingt, andere betreffen speziell die Umsetzung von snap. Um die soll es hier gehen.

Die Problematik

Es gab jetzt in kurzer Zeit mindestens zwei populäre Artikel samt Thread auf Hacker News, die zusammen Probleme mit Snaps überzeugen vortragen. Der erste war Disabling Snaps in Ubuntu 20.04 mit dieser Diskussion, der zweite war Ubuntu 20.04 LTS’ snap obsession has snapped me off of it mit dieser.

Das Hauptproblem sind die Autoupdates. Snaps auf Ubuntu aktualisieren sich selbst. Sicherheitstechnisch begrüßenswert hat das einen Rattenschwanz von Problemen:

1. Snaps können ohne Vorwarnung und Lösung kaputtgehen. Wenn ein Snap-Ersteller ein fehlerhaftes Update veröffentlicht, bricht die Software bei all ihren Nutzern, ohne dass Nutzer das Update verhindern können.
2. Wie immer bei Autoupdates können sie im falschen Zeitpunkt auftauchen. Während einer wichtigen Präsentation beispielsweise soll der dafür genutzte Browser besser nicht updaten und dann einen Neustart einfordern. Mitten im Arbeitsflow gilt das gleiche für jede andere Software.
3. Nicht immer ist Traffic unbegrenzt verfügbar. Hänge ich am mobilen Internet, will ich wohl kaum, dass mein begrenztes Volumen von Snaps aufgefressen wird.

Diese Argumente sind für mich völlig überzeugend. Snaps, da jetzt Teil des Distribution, sollten genau wie .debs nur auf Nutzeranforderung (zu der das System eventuell aufforderte) aktualisiert werden. Leider verweigert sich das Projekt dagegen. kikoreis nennt drei Argumente pro autoupdates:

1. Browsers machen das sowieso schon.
2. Ubuntu macht das sowieso schon, seit 16.04 LTS
3. Snaps brauchen keine Rootrechte und ihre Updates sind daher weniger problematisch

Alle diese Argumente sind nicht korrekt. Browsers updaten sich selbst, aber eben nicht unter Linux – da macht das die Paketverwaltung unter Kontrolle des Nutzers. Ubuntu auf meinem Laptop im Büro hatte mich auch nach 2016 noch wegen der Updates gefragt. Und ob Updates mit oder ohne Rootrechte durchgeführt werden ändert an ihrer Problematik rein gar nichts.

Vor allem geht es am Thema vorbei: die Argumente adressieren keines der Probleme. Das Ursprungsproblem ist fehlende Konfigurierbarkeit. Um Nutzerbedürfnisse zu befriedigen und die Probleme zu lösen müssten die Autoupdates konfigurierbar sein. Sind sie es nicht, ist die Lösung ungeeignet.

In den Diskussionen kristallisieren sich weitere Probleme heraus. Eines davon finde ich beachtenswert: Ubuntu legt ~/snap an. Zwar ist klar, dass Snap ins Benutzerverzeichnis schreiben muss. Aber andere Software und auch proprietäre wie Steam ist wesentlich höflicher und versteckt sich, denn das Benutzerverzeichnis und sein Inhalt gehört dem Nutzer, der seine Organisation weitestgehend frei wählen darf. So liegt Steam unter ~/.local/share/Steam/. Genauso hätte es sich für Snap gehört.

Ubuntu hat weiterhin ein Problem mit fehlender Nutzerzentrierung

Es ist so schade, dass Canonical weiterhin seine Nutzerfeindlichkeit pflegt. Es war ja mal ganz anders: Linux for human beings wurde als Auftrag an größtmögliche Nutzerfreundlichkeit verstanden. Im Laufe der Zeit wurde daraus ein immer wieder durchschimmerndes Wir wissen es besser und eine Orientierung am unmündigsten aller Nutzer, um eigene Vorstellungen vorzugeben. Beispiel: Die Fensterverwaltungsbuttons nach links zu verschieben und damit die Nutzererwartung zu missachten wäre schon seltsam gewesen, sich dann aber sogar zu weigern die Seite grafisch konfigurierbar zu machen war einfach nur feindselig.

Genau diese Haltung bedroht jetzt auch Snaps: Denn eigentlich sind die eine gute Sache, gerade auch für Entwickler wie mich. Aber sie zu benutzen, um Zwangsupdates wie bei Windows durchzudrücken? Etwas, weswegen ein beachtlicher Teil der Linuxnutzer von Windows weggewechselt ist? Das missachtet grob Usability-Kriterien, hier vor allem die Aufgabenangemessenheit, und macht damit im Zweifel ein System für Nutzer unbenutzbar. Und das, obwohl Ubuntu 20.04 selbst wohl ein ziemlich gutes Release geworden ist.

Es erzeugt zudem völlig unnötigerweise einen Konflikt zwischen den Nutzern und den Machern des Systems.

Canonical hat gezeigt, dass sie es besser können. Die Fensterverwaltungsbuttonsseite war irgendwann wieder offiziell konfigurierbar, dann war auch die Standardeinstellung wieder korrekt. Aus Unity wurde mit solchen Verbesserungen im Laufe der Zeit eine gute Desktopumgebung, sodass als Ubuntu schließlich aufgab und zu Gnome wechselte dies bedauerlich war. Ich hoffe, dass die Organisation immer noch die Vernunft und die Kraft hat, auf die Kritik richtig zu reagieren. Dass Snaps konfigurierbar gemacht werden, wieder ultimativ der Nutzer sein System seinen Anforderungen entsprechend verwalten kann. Das wäre erfüllt, sobald Autoupdates optional werden und der sichtbare Snapordner verschwindet. Gut wäre es auch, wenn problemlos alte Snapversionen zurückgespielt werden können.

Hollow Knight ist ein wunderbar gelungenes Metroidvania.

Zu Beginn würde man das kaum glauben. Die Spielerführung anfangs ist mies. Die Spielfigur fällt vom Himmel, landet nahe einer kleinen Siedlung, die einen Zugang zu einer Höhle hat. Es ist der Eingang zur Spielwelt, doch gibt es keinen Grund sie zu entdecken, keine Story, keine Motivation. Macht man es trotzdem greifen immerhin recht schnell die üblichen Motivationsmechanismen des Genres: Dank neuer Fähigkeiten werden vorher unzugängliche Stellen erreichbar, mit zunehmender Stärke werden vorher fast unschlagbare Gegner besiegbar, Schritt für Schritt werden neue Abschnitte der Spielwelt aufgedeckt.

Im Spielverlauf ergibt sich dann so etwas wie eine Story: Dass etwas nicht stimmt in dieser dunklen Höhlenwelt und es änderbar wäre, ein Endgegner kündigt sich an, Verbündete tauchen wiederholt auf. Das erinnert dann durchaus an Dark Souls, mit dem es sich auch das Spielelement des Verlusts der Spielwährung beim Tod teilt, wobei dann noch eine Chance besteht, die gleiche Stelle zu erreichen und alles zurückzuergattern. Auch ist Hollow Knight nicht gerade einfach. Anderseits spielt sich so ein 2D-Plattformer ganz anders und der Vergleich ist bereits überstrapaziert. Und doch: Mit der Melancholie einer im Sterben liegenden alten Welt und dem häppchenweisen Andeuten einer Hintergrundgeschichte trifft das Mini-Entwicklerteam einen ähnlichen Ton.

Toll fand ich die Grafik. Einfach schön gezeichnet. Es erinnert mich dabei sehr an SNES-Spiele, oder eher: Wie die mit moderner Technik aussehen würden (eben nicht im Pixellook!). Dabei hat Hollow Knight durchaus seinen eigenen Stil. Sehr angenehm auch das Fortschrittsgefühl, wenn der Charakter merklich immer stärker wird, entweder direkt durch Upgrades seiner Waffe oder durch neue ausrüstbare Zauber, mehr noch durch neue Fähigkeiten wie den Wandsprung. Ein paar Witze sind enthalten, besonders einer spielt mit Genrekonventionen und hat mich beeindruckt, aber den will ich hier nicht spoilern.

Es ist nicht alles perfekt. So gibt es ein paar frustige Stellen. Bosse, die unfair schwer sind (teils, wenn bestimmte Upgrades noch nicht gefunden wurden). Und sogar optionale Bosse, die mir bis zum Spielende komplett unmöglich waren. Es gibt eine Sprungpassage, den White Palace, der ohne Youtube-Guide unmöglich gewesen wäre und auch mit viel Glück und Geduld erforderte, was dann nicht mehr spaßig war. Immer wieder die gleichen Gebiete durchwandern zu müssen passiert einen Tick zu oft.

Doch insgesamt: Richtig toll. Unfassbar, dass das Entwicklerstudio im Kern aus drei Leuten besteht.