Technikzeugs - 51

Ein paar von euch hatten ja Pipes ausprobiert. Ich bin derzeit sehr am Überlegen, wie sich die Seite im nächsten Jahr entwickeln soll. Ich habe ein paar Ideen, will aber gar nicht zu sehr beeinflussen, denn: Ich habe zum Ideensammeln eine Umfrage angelegt. Wer ein bisschen Interesse an der Seite hat sei hiermit herzlich gebeten, die (sehr kurze!) Umfrage auszufüllen oder mir auf sonstigem Wege seinen Eindruck oder seine Ideen zukommen zu lassen.

Später schreibe ich dazu bestimmt noch etwas mehr.

Damit der Hardwareempfehler seine PC-Builds zusammenstellen kann muss pc-kombo vier Aufgaben auf einmal erledigen:

1. Er muss sich eine Liste aller möglichen Komponenten zusammenstellen.
2. Dann muss er herausfinden, was wieviel kostet.
3. Um dann aus diesen Komponenten zu wählen zu können muss er wissen, welche Hardware wie schnell ist.
4. Schließlich kann er zusammenpassende Builds zusammenstellen, also per Algorithmus optimieren und dabei bedenken, welche Hardware zusammenpasst (welche Prozessor in welches Motherboard, welche Grafikkarte in welches Gehäuse, welches Netzteil stark genug ist etc).

Ich sitze derzeit daran, das weiter aufzusplitten. Natürlich ist es jetzt schon in einer gewissen Weise aufeteilt: Die Webanwendung holt ja nicht bei jeder Anfrage alle Komponenten aus Crawlern und die Preise von den APIs, sondern erledigt vieles vorher im Hintergrund (die Preiserfassung gar per Micoservice). Aber letzten Endes ist es doch eine Seite, eine Interface, ineinander greifende Arbeitsschritte. Stattdessen möchte ich am Ende drei spezialisierte Seiten haben – eine namensgemäße Kombination von Anwendungen erschaffen.

Eine PC-Hardwaredatenbank

Sie soll alle Prozessoren, alle Grafikkarten, alle Motherboards usw umfassen, samt ihren Spezifikationen, Reviews und was sonst noch anfällt. Der Clou: Das soll offen werden. AGPL-lizenzierter Code, API-Zugriff auf die Datensammlung. Denn als ich pc-kombo startete war das Sammeln der Hardware eine unvermutete Mammutaufgabe, wofür es keinen guten Grund gibt. Das sind keine Geschäftsgeheimnisse, keine geheimhaltungswürdige Informationen. Und doch gibt es da eine kleine Industrie drumrum, die solche Daten sammelt und zu Mondpreisen verkauft.

Mit dieser Datensammlung und der API wäre nicht nur pc-kombo gedient, sondern viele andere Projekte könnten davon profitieren. Für pc-kombo und mich wäre es aber besonders praktisch: Ein zentraler Ort für die Hardwaredatensammlung. Wo ich nochmal Zeit und Arbeit darein investieren kann, die Datensammlung besser und einfacher zu gestalten. Gleichzeitig immer im Blick halten kann, auf jeden Fall auch das zu sammeln war das Empfehlungssystem mindestens braucht.

Für die Einzelansicht einer Grafikkarte habe ich bereits einen Entwurf:

Nebenbei: Statische Seiten zu generieren entstammt als Ansatzpunkt natürlich dieser Projektidee.

Falls jemand als Mitentwickler einsteigen will, gerne! Einfach in Kontakt treten. Softwaretechnisch wird das ein statischer Seitengenerator in Ruby; Das, sowie HTML, CSS und vielleicht Javascript muss geschrieben werden, und mit dem angedachten Backend und der Datensammlung gibt es nochmal eine ganz andere Aufgabe zu bewältigen.

Eine Metabenchmarkseite

Der Metabenchmark verdient mehr Aufmerksamkeit. So oft wollen Leute wissen, wie gut Prozessoren und Grafikkarten im Vergleich mit anderen sind, welche Spiele und Anwendungen sie wie gut bewältigen. Und viel zu oft schauen sie dabei auf die falschen Daten: Künstliche Vergleiche von Spezifikationen oder Ergebnisse artifizieller Benchmarks, die über die Praxis fast nichts aussagen. Echte Benchmarks der Zielanwendungen sind der viel bessere Weg, Prozessen und Grafikkarten zu vergleichen.

Gleichzeitig ist das nicht einfach. Verschiedene Benchmarks mit teils disjunkten Teilnehmerlisten vergleichbar zu machen ist komplizierter, als ich anfangs dachte. Doch mittlerweile meine ich, das Problem algorithmisch so gut gelöst zu haben wie möglich. Wenn es mal offensichtlich falsche Ergebnisse gibt, dann liegt das mittlerweile immer an fehlenden Daten. Was sehr selten geworden ist.

Und doch beobachte ich für den Benchmark wenig Popularität, außer ich stoße Leute drauf. Deswegen soll der Metabenchmark seine eigene Seite bekommen, mit einer besseren Oberfläche, und so besser sichtbar werden. Und ebenfalls eine API bekommen, sodass andere Projekte ihn benutzen können. Wobei er selbst seine Prozessoren und Grafikkarten aus der API der Hardwaredatenbank ziehen würde.

Und wie gehabt: Ein PC-Builder

An pc-kombo würde sich laut diesem Plan erstmal gar nicht viel ändern. Die Daten der anderen Seiten benutzt er ja jetzt schon und bräuchte sie auch weiterhin. Aber mit einem kleineren Kern, besserer Automatisierung und reduzierten Ansprüchen an die Datenbank kann ich vielleicht ein paar der Verbesserungen umsetzen, zu denen ich bisher nicht kam.

Im Grunde will ich nehmen, was pc-kombo sowieso schon macht, es besser kapseln, automatisieren und zugänglich machen. Dabei mir und anderen helfen, daher sind die APIs geplant und eine freie Lizenz für die Datenbank. Es muss sich natürlich erst noch zeigen, ob ich das wirklich gebaut kriege und dann auch so wird, wie ich mir das derzeit vorstelle.

Letzten Monat wurde die GNOME Foundation von einem Patenttroll verklagt, der via eines offensichtlich invaliden Patents Geld für Shotwell verlangte, GNOMEs Bildverwaltungsprogramm. Wahrscheinlich kein geschickter Schachzug. Und tatsächlich wehrt sich GNOME: Die Forderungen werden verneint, das Vergleichsangebot zurückgewiesen, das Patent angegriffen.

Sie schreiben es auch in der Ankündigung, aber es ist gleichzeitig der richtige und der harte Weg. Es ist kurzfristig riskanter und teurer, als sich erpressen zu lassen. Aber es sendet ein Signal an andere Patenttrolle, sogar über GNOME hinaus, das freie Software kein geeignetes Angriffsziel ist. Zu kämpfen schützt auch ganz konkret andere Projekte vor diesem Angreifer, indem seine Ressourcen gebunden werden, das Patent möglicherweise invalidiert wird. In früheren Fällen sind Betreiber solcher Patenttrolle auch schon ins Gefängnis gewandert.

Eine gute Aktion von GNOME also, völlig egal wie man zur Desktopumgebung selbst steht. Sie sammeln hier Spenden, um die Kosten tragen zu können. Ich habe mich daran gerade beteiligt. Jeder, der mit freier Software zu tun hat, sollte das wenn möglich ebenfalls machen. Und sei es nur aus Eigeninteresse.

Weil das System zu oft zurückspringt, dabei nicht konsistent ist und dem Nutzer nicht genug Steuerungsmöglichkeiten gibt. In Usability-Sprech: Das Prinzip der Steuerbarkeit und der Erwartungskonformität ist verletzt, so stark, dass die Aufgabenangemessenheit gefährdet ist. Ein Nachtrag mit Beispielvideos zu meiner Besprechung vom letzten Jahr.

Smartwatches zeigen die Uhrzeit, können aber noch viel mehr. Dafür startet man zumindest bei Google auch mit ihnen Apps, wie bei Telefonen. Aber bei den Uhren wird nach wenigen Sekunden der Bildschirm wieder dunkler. Und dann können zwei verschiedene Dinge passieren:

1. Manche Apps schalten in einen Ambiance-Modus. Sie werde farblos, um die Batterie zu schonen, aber sie bleiben aktiv:

2. Andere unterstützen diesen Modus nicht. Sie schließen sich ganz, es geht zurück zum Startbildschirm. Das ist ungeheuer nervig.

Vor allem, weil die große Frage dann ist: Wie kommt der Nutzer wieder zu der App zurück, die er eben noch nutzen wollte? Antwort: Er weiß es nicht.

Manchmal reicht es, den Bildschirm der Uhr wieder zu berühren. Dann wird er wieder hell und die App erscheint:

Aber das funktioniert nicht immer. Oft genug – je nach Speicherverwaltung? Wartezeit? – bleibt WearOS dann bei der Uhrzeitanzeige stehen:

Das passiert auch dann, wenn der Nutzer per Knopfdruck zur Uhrzeitanzeige gewechselt ist. Kein Berühren des Bildschirms und keiner der beiden Knöpfe führt dann zur vorher geöffneten App zurück:

Was man hier auch schön sieht: Wie viele meiner Wischgesten ignoriert werden. Auch das macht die Benutzung der Uhr frustrierend.

Die Bedienung der Uhr leidet schon unter anderen Erschwernissen. Die Oberfläche stockt gerne mal, der Bildschirm ist klein, damit auch die Bedienfläche. Das ist aber nicht das Hauptproblem: Es macht es nur noch unangenehmer, immer wieder in das Menü gehen und Apps neustarten zu müssen. Das eigentliche Problem ist die fehlende Task/App/Fensterverwaltung im Bedienkonzept. Das erinnert mich ein bisschen an die Anfangszeit von Android auf den Smartphones, als es ebenfalls genau in dieser Disziplin schwächelte und das später kopierte webOS zeigte, wie es richtig geht. Bei Smartwatches muss diese Inspiration wohl noch gefunden werden.

Mit 2.3.1 gibt es ein gar nicht so ganz kleines Patch-Release kurz nach der Veröffentlichung von 2.3.0. Es sind vor allem Schönheitskorrekturen wie das nun wieder mögliche Löschen mehrerer Mediendatenbankeinträge auf einmal. Gerade deswegen ist ein höchsterfreuliches Release, das Thomas in seinem Blog zusammen mit weiteren Entwicklungen näher beschreibt.

Die neue stabile Version 2.3 von Serendipity war nötig. PHP bricht einfach immer mehr als stabile Grundlage weg, überspitzt ausgedrückt – die Versionen werden weniger lange unterstützt und die neuen haben gravierende Änderungen. Also muss Serendipity angepasst werden und die Version mit diesen Anpassungen auch zeitnah erscheinen. In meinem Kopf ist 2.3 solch eine erzwungene Version. Denn nun kann Serendipity mit PHP 7.2, 7.3 und 7.4 laufen, bevor 7.1 wegbricht.

Andererseits ist das der neuen Version gegenüber gar nicht fair. Denn einige der Änderungen – weniger zur Alpha, sondern zur letzten stabilen Version – sollten ziemlich bedeutsam sein und Serendipity deutlich verbessern. Mehr noch, wenn sie in der Zukunft noch mehr Feinschliff erhalten und sich alles mehr noch zu einem organischen Ganzen zusammenfügt. Wo ich mitspielte meine ich damit unter anderem: Die Galleriefunktion (Interface), responsive images (Feintuning), den Maintenance-Modus (für Upgrades) und den neuen voku/simple-cache (Redis!).

Was auch für das Release spricht ist die Commitliste: Es sind viele Verbesserungen vieler Autoren drin. Unter anderem, jeweils ein Beispiel: Mario hat das Timeline-Theme unter PHP 7.2 repariert, Don Chambers es generell aktualisiert, Thomas hat an mehr Stellen Patches beigesteuert als mir klar war (und nebenbei den Überblick behalten auch für 2.1.x sowie das Release gestemmt!), hannob Sicherheitslücken aufgedeckt, Matthias das HTML der Bildunterschriften modernisiert, Garvin die Überarbeitung der Mediendatenbank fertiggestellt und so überhaupt erst möglich gemacht, Mitch hat den Trackbackfresser gefunden und Stephan Brunker nl2br/nl2p verbessert.

HeuteGestern war ich auf der Froscon! War der Anlass eigentlich nur, Dirk über den Weg zu laufen (der am Sonntag einen Workshop über Regexpressions halten wird) besuchte ich doch auch drei Vorträge.

How not to use OAuth

Daniel Fett erklärte viel zu OAuth, argumentierte gegen eine Variante (den implicit Grant) und zeigte generell Sicherheitsprobleme und Lösungen. Supergut vorgetragen und für mich hochspannend, weil das größtenteils auch OIDC und damit das von Portier verwendete Protokoll betrifft. War ein toller Start in die Konferenz.

Matrix

Oleg Fiksel erklärte was Matrix ist und was sich im letzten Jahr getan hat. Für mich ein Blick über den Tellerrand (und vielleicht etwas für eine Integration in Pipes?) und ein ordentlicher Vortrag, als Nicht-Matrixnutzer für mich nicht ganz so spannend wie die OAuth-Erklärungen. Aber trotzdem nett.

Privacy by design

Die Vortragende redete weniger über Pricacy by Design als vielmehr über die Auswirkungen der DSGVO auf Softwareentwicklung im Unternehmen. Ohne gemein sein zu wollen: Das war mir ein bisschen zu unstrukturiert und zu wenig auf die Softwareprojekte anwendbar, an denen ich arbeite. Mit der Verordnung habe ich mich vorher durchaus schon befasst und ich konnte daher hier wenig neues lernen. Erschwerend: Die Publikumsfragen und Diskussionsversuche fand ich teilweise dem Thema nicht angemessen. Aber ist vielleicht auch schwierig bei einem Thema, das als juristisches außerhalb der Komfortzone der Teilnehmer einer IT-Konferenz liegen dürfte und bei dem das Wunschdenken stark ist. Doch so funktionierte der Vortrag für mich leider nicht.

Ansonsten wollte ich noch den Geany-Leuten am Stand Hi sagen und sie für den tollen Editor loben (und vorschlagen, die Funktion mehrere Zeilen auf einmal zu editieren auszubauen), der Platz war aber leider nicht besetzt. Dafür war das Zusammensitzen, Essen und Trinken am Abend ziemlich nett.

Strong Customer Authentication (SCA) – schon vor einer Weile hatte Stripe vielen Kunden und auch mir geschrieben, dass dadurch Änderungen anstehen. Zukünftig werde das vorgeschrieben sein (schon im September) und daher musste die Stripe-Integration von Pipes angepasst werden. Heute kam noch einmal solch eine sehr warnende Email, ich habe mir das angeschaut und tatsächlich den Bezahlvorgang angepasst.

Aber trotz eigentlich geringen und positiven Entwicklungsaufwands war der Gesamtprozess nicht toll. Stripe verweist auf diese Dokumentation und erklärt dort ganz viel, aber wenig konkretes. Mich interessieren doch nur zwei Dinge:

1. Was muss ich tun, damit Nutzer von Pipes weiterhin ein Abonnement abschließen können?
2. Muss ich etwas tun, damit bestehende Abonnements weiterhin monatlich/jährlich abgebucht werden?

Das ist für Stripe sicher schwierig im Voraus zu beantworten, weil die Antwort nicht bei jedem Kunden gleich ist. Aber die Dokumentation scheint mir auch nicht auf die Beantwortung dieser Fragen ausgelegt. Damit bin ich etwas unzufrieden.

Wie auch immer, der erste Schritt war in meinem Fall relativ einfach. Pipes nutzt Stripe Checkout. Das ist eine recht komfortable Softwarelösung, ein bisschen Javascript und etwas Servercode und schon hat man dieses vielleicht bekannte Kreditkarteneingabefenster und kann damit bezahlen bzw Zahlungen entgegennehmen. Also wird das automatisch aktualisiert und Checkout-Integratoren müssen nichts machen? Nein! Stattdessen ist das kleine Fenster jetzt die Legacy-Variante, das neue Checkout funktioniert etwas anders, löst aber die Authentifizierung.

Und genau das hätte mir Stripe in der Email oder der SCA-Dokumentation auch direkt sagen können. Stattdessen ist es in der Checkout-Doku versteckt.

Dabei ist die neue Lösung nichtmal schlecht. Sie sieht hübsch aus und es ist weniger eigener Code notwendig.

Es gibt eine vernünftige Wechselanleitung. Aber im Grunde wechselt man erstmal das Javascript aus. Vorher basierte das auf einem Formular:

<form action="/subscribe" method="POST">
<script
    src="https://checkout.stripe.com/checkout.js"
    class="stripe-button"
    data-key="pk_test_..."
    data-name="pipes.digital"
    data-description="Regular Plan"
    data-amount="20"
    data-currency="eur"
>
</script>
</form>

Jetzt wird eine Funktion aufgerufen:

<script src="https://js.stripe.com/v3">
<button id="checkout-button">Subscribe

<script>
    var stripe = Stripe('pk_test_...');

    var checkoutButton = document.querySelector('#checkout-button');
        checkoutButton.addEventListener('click', function () {
            stripe.redirectToCheckout({
                items: [{
                    plan: 'regular_v1',
                    quantity: 1
            }],
            customerEmail: 'customer@example.com',
            successUrl: 'https://pipes.digital/sub_success',
            cancelUrl: 'https://pipes.digital/pricing'
          });
        });

</script>

Klar, bei mir liegt das alles in erb-Templates und sieht daher etwas anders aus.

Vorher musste auf dem Server dann noch das Abonnement angelegt werden:

post '/charge' do
    customer = Stripe::Customer.create(
        :email => authorized_email,
        :source  => params[:stripeToken]
    )

    subscription = Stripe::Subscription.create(
        :customer => customer.id,
        :items => [
            {
              :plan => params[:plan]
            },
        ],
    )
end

Nun:

Das entfällt völlig! Da das neue Checkout auf eine Seite bei Stripe weiterleitet wird alles dort erledigt.

Trotzdem muss noch auf dem eigenen System darauf reagiert werden, dass der Nutzer etwas bestellt hat. Bei Pipes wird ein Datenbankeintrag angelegt. Dafür gibt es einen Webhook (einen Ort, an dem ein anderer Server einen POST hinsenden kann), der in der Doku wieder gut erklärt wird. Prinzipiell aktiviert man ihn im Stripe-Dashboard und fängt ihn dann so:

# webhook endpoint for stripes
post '/webhook' do
    payload = request.body.read
    event = nil

    # Verify webhook signature and extract the event
    # See https://stripe.com/docs/webhooks/signatures for more information.
    sig_header = request.env['HTTP_STRIPE_SIGNATURE']
    begin
        event = Stripe::Webhook.construct_event(
            payload, sig_header, endpoint_secret
        )
    rescue JSON::ParserError => e
        # Invalid payload
        warn "invalid webhook payload"
        status 400
        return
    rescue Stripe::SignatureVerificationError => e
        # Invalid signature
        warn "invalid webhook signature"
        status 400
        return
     end

    # Handle the checkout.session.completed event
    if event['type'] == 'checkout.session.completed'
        session = event['data']['object']
        # Fulfill the purchase:
        plan = session['display_items'][0]['plan']['id']
        if plan == 'regular_v1' 
            User.new(email: session['client_reference_id']).promoteToRegular(subscription_id: session['subscription'])
        end        
    end

    status 200
end

Es gibt natürlich noch viel mehr Events, die man mit diesem Webhook fangen könnte, zum Beispiel wenn Zahlungen fehlschlagen.

Und die zweite Frage? Ob bestehende Abonnements weiterlaufen blieb mit bisher unklar. Es gibt da zwar einen Abschnitt für, aber ob dieses Grandfathering passieren kann hängt wohl davon ab, ob das Abo so erstellt wurde:

By passing a token, source, or payment method to a Customer

Ihr saht den Code oben, ist das bisher passiert? Der verlinkte Beispielcode sagt ja, aber nichts davon wird explizit im Code erledigt.
Meine jetzige Annahme ist, dass beim Erstellen von Abonnements gemäß des alten Checkout-Verfahrens die Zahlungen weiterlaufen sollten. Man müsste aber wohl eigentlich auf Nummer sichergehen und eine Seite bauen, die über die Stripe-API den Kunden die Möglichkeit gibt, die Authentifizerung nachzuholen. Eine so simple Lösung wie Checkout gibt es dafür aber nicht. Im Fall von Pipes würde sich das Abtauchen in die API kaum lohnen, im Fall der Fälle würde ich dann eher die Nutzer bitten, nochmal neu zu abonnieren.

Naja, spätestens im September wird sich das aufklären.

Wer irgendwie Tech-News verfolgt (oder im Blog bei pc-kombo mitliest) wird mitbekommen haben, dass AMD mit Ryzen 3000 gestern eine richtig gute neue Prozessorserie veröffentlicht hat. Verfügbar sind (teils mit ein paar Tagen Lieferverzögerung):

1. Ryzen 3 3200G und Ryzen 5 3400G, zwei neue APUs. Von ihnen gibt es noch keine Reviews, aber es sind wieder 4-Kerner mit 4 bzw 8 Threads und nun mit leicht höherem Takt. Damit, der evenutell höheren Performance per Takteinheit und der sicher weiterhin guten integrierten Grafik werden sie für manche Einsatzzwecke wieder toll sein.
2. Zukunftssicherer sind jedoch die neuen 6-Kerner mit jeweils 12 Threads und ohne integrierte Grafikkarte, Ryzen 5 3600 und 3600X. Von letzterem gab es kaum Reviews, aber der kleinere 3600 wurde ausgiebig durch Benchmarks getrieben und schnitt hervorragend ab.
3. Obendrüber folgt der Ryzen 7 3700X. 8 Kerne, 16 Threads, aber auch mit 350€ deutlich teurer als der 3600X. Vergleichen sollte man ihn wohl eher mit dem Intel Core i9-9900K, der in Spielen noch etwas schneller, in sonstigen Anwendungen aber eher langsamer ist. Und nochmal 100€ bis 150€ mehr kostet, was er selbst in Spielen nicht wert ist.
4. Es gibt auch einen Ryzen 7 3800X. Von dem gibt es noch keine Reviews, aber er scheint nichts anderes als ein im Turbo 100 MHz schnellerer 3700X zu sein, der dafür 70€ mehr kostet. Übersehe ich da nichts darf man den wohl getrost ignorieren.
5. Nicht ignorieren kann man den Ryzen 9 3900X. Sieht erstmal zu teuer aus mit 520€, er hat aber 12 Kerne und 24 Threads bei einem Turbo von 4,6 GHz. Ein ziemliches Monster, das bei Programmen wie Videokodierung mit den Threadripper-Prozessoren mithalten kann und auch bei weniger gut verteilbaren Anwendungen wie Spielen ziemlich schnell ist. Für den heimischen Rechner für PC-Spiele, Webseiten und Netflix sicher weniger interessant, aber wer seinen Prozessor auslastet schaut hier sicher zweimal hin.

Worauf ich aber eigentlich hinweisen wollte sind die Vorgängermodelle, die gerade nochmal im Preis fallen. Wer für weniger Geld aufrüsten sollte den Preisverlauf weiter beobachten: Händler könnten die älteren Ryzen-Prozessoren nun endgültig loswerden wollen, und die 2000-Serie muss gegen die 3000-Serie positioniert werden und wurde daher gerade ein paar Euro günstiger. Spannend sind die 6-Kerner wie der Ryzen 5 1600 und der Ryzen 5 2600, wobei in Deutschland der Ryzen 5 1600 meist viel zu nah beim schnelleren 2600 sitzt. Aber vielleicht ändert sich das ja jetzt, wenn das Lager leerwerden soll. Und ob nicht auch ein paar Modelle der Ryzen 7-Reihe angesichts des Ryzen 7 3700X massiv im Preis fallen werden?

Schon jetzt gibt es absurde Angebote wie einen Ryzen 3 1200 (immerhin ein Vierkerner!) für 47€. Da DDR4-Ram und ein passendes B350 oder B450 Mainboard auch gerade günstig sind landet man so bei einem kompletten Plattformupgradekit für unter 200€. Wer noch einen Phenom, FX-Prozessor oder irgendeinen Zweikerner (wie die älteren i3s) im Rechner hat könnte sich das überlegen.

Für GamersGlobal habe ich einen Nutzerartikel zu Skylines geschrieben. Es geht um die Erweiterungen: Was taugen die und wie stark ändern sie das Grundspiel?

Das unter Linux gut laufende Spiel hat ja einige DLCs, ganz günstig sind sie aber nicht. Ich hatte für mich selbst versucht herauszufinden, welche heutzutage kaufenswert sind, aber dazu keine guten Antworten gefunden. Daher der Artikel, für den ich alle Erweiterungs-DLCs (also nicht die Radiosender und Content-Packs) nach und nach hinzufügte und eine lange Zeit spielte. Da ging wirklich viel Zeit für drauf – ich wollte gründlich sein und die Frage so fundiert wie mir möglich beantworten.
Spoiler: Die neuesten drei Erweiterungen Industries, Parklife und Campus gefielen mir gut.

Steam hat schon vor Jahren einen P2P Shader-Cache für OpenGL und Vulkan eingeführt. Kürzlich ist er auch für Proton/DXVK aktiviert worden, jetzt auch auf meinem Linux-Rechner in der stabilen Version von Steam.

Worum geht es hier? Was sind Shader?

DXVK wandelt Aufrufe von DirectX, der unter Windows genutzten Grafik-API, nach Vulkan um. Zusammen mit wine können damit Windows-Spiele besonders gut unter Linux laufen. Aber es werden eben auch die Shader umgewandelt, das konnte bisher einen Moment dauern.

Shader sind nicht das Level, auf dem ich programmiere und Ahnung habe. Aber sie sind meinem Verständnis nach Grafikeffekte als Code, hier ein Beispiel. Sie müssen kompiliert werden, umgewandelt werden von Code in etwas, was direkt von OpenGL bzw Vulkan nutzbar ist. Siehe auch diese Erklärung, warum das unter Linux derzeit besonders problematisch ist.

Auf jeden Fall kann es einen Moment dauern und das ist natürlich potentiell schlecht, denn dann stockt das Spiel. Für die meisten Spiele geht es hier nur um die ersten Sekunden nach dem ersten Start, aber bei anderen passiert das kontinuierlich während des Spielens.

Wie funktioniert der Cache?

Es ist geteilter Cache aller Steam-Nutzer. Nach dem Spielen analysiert Steam, welche Shader kompiliert wurden. Die werden dann hochgeladen und an die anderen Nutzer verteilt. Die sparen sich dann den Kompilierungsschritt, wodurch ihr Spiel flüssiger läuft. Und Steam kann sich jetzt auf der Ebene bewegen, auf der das Spiel lebt: Ein DirectX-Spiel, das per Proton/DXVK unter Vulkan läuft, produziert auf dem Linuxrechner Vulkan-Shader. Steam kann genau die Cachen, nicht die vorgelagerten DX-Shader (die wahrscheinlich sowieso vom Entwickler vorkompiliert wurden), die durch die Grafik-Pipeline dann nochmal umgewandelt werden müssten.

Die von Valve dafür genutzte Software heißt wohl Fossilize. Das besonders nette ist: Der Entwickler des Spiels muss dafür nichts tun.

Wenn ich das richtig verstehe landen übrigens nicht die Shader selbst im Cache, die wären grafikkartenspezifisch. Sondern eine Zwischenrepräsentation, die dann immer noch einmal kompiliert bzw von Vulkan/OpenGL interpretiert werden muss. Ich bitte um Korrektur, falls das nicht stimmt.

Welche Spiele betrifft es?

Unter Linux im Grunde alle, denn entweder nutzen sie OpenGL oder Vulkan direkt oder indirekt per DXVK. Leider zeigt Steam in der Oberfläche nicht an, welche Spiele bereits Shader-Cachedateien heruntergeladen haben. Aber es betrifft jetzt eben auch Proton-Spiele, also Windows-Spiele, die unter Linux mit Steams Kompatibilitätshelfer laufen. Ich habe Downloads für Witcher 3 und Path of Exile gesehen, Downloads der Shader werden nämlich doch angezeigt.

Funktioniert es?

Vielleicht. Ich habe gestern zum ersten mal Dark Souls 2 gestartet, da war der Cache gerade eingeführt. Ich beobachtete tatsächlich keine Ruckler, auch nicht beim ersten Laden des Hauptmenüs. Und normalerweise konnte man an dieser Stelle bei diesen Protonspielen schon bemerken, dass sie nicht nativ unter Windows laufen, durch ein Ruckeln am Anfang. Das ist jetzt wohl weg.

Es gibt da aber ein Problem: Normalerweise wird ein solcher Shader-Cache wenige MB groß sein. Aber manche Spiele wie Path of Exile benutzen sehr viele Shader und Kombinationen derselben, die (schon durch den DXVK-Zwischenschritt) auch nicht bei Spielstart, sondern während des Spielens geladen werden. Das führte bisher zu Rucklern. Und auch mit dem neuen Cache stottert es noch, mehr sogar als bei meinem ersten Spieldurchlauf – was aber eher an den Änderungen im letzten Spielupdate liegen dürfte, den neuen Gegner in den Startgebieten mit mehr grafischen Effekten. Oder da geht etwas anderes schief. Auf jeden Fall half der Cache bisher nicht. Was eben auch an seiner Größe liegen dürfte: Gestern hat Steam alleine für PoE mal eben 700MB an Shader-Cacheinhalten heruntergeladen. Jetzt gerade läuft der nächste 1,1 GB große Download. Ich bin gespannt, ob sich irgendwann der Cache auf eine finale Größe einpendelt und ob er dann die kleinen Ruckler des Spiels beseitigt.
Er könnte ja auch selbst zum Problem werden. Wenn er nicht für so große Datenmengen gebaut wurde führen bei diesem Spiel vielleicht die Cache-Abfragen selbst zu Rucklern.

Auf jeden Fall ist es grundsätzlich eine gute Sache. Es zeigt: Auch wenn Steam proprietäre Software ist, ist es eben der eine Spieleshop, der an Linuxspieler denkt. GOG, die eigentlich bessere DRM-freie Alternative, könnte so etwas gar nicht umsetzen, da ihr Linux-Client nicht existiert.

Android Studio kann Anwendungen im Emulator oder auf verbundenen Geräten ausführen. Die werden dann per adb herübertransportiert. Bei der Huawei Watch 2 ging das problemlos, und auch auf dem Pixel-Smartphone gab es keinerlei Probleme. Normalerweise muss nur das Telefon oder die Uhr mit dem Kabel mit dem Laptop verbunden werden, bei der Uhr geht das über die Ladeschale. Bei der TicWatch Pro dagegen stellte sich Android Studio quer. Es sei gar keine Uhr, das ist natürlich Quatsch.

Ein adb devices erklärte das echte Problem:

malte@jet:~$ adb devices
List of devices attached
720EX91180144	no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]

Es fehlten die per udev vergebenen Zugangsrechte. Um sie herzustellen legt man die Datei /etc/udev/rules.d/51-android.rules mit diesem Inhalt an:

SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="90bc" MODE="0666", GROUP="plugdev", SYMLINK+="android%n"

Die Werte für ATTR{idVendor} und ATTR{idProduct} verrät ein lsusb:

malte@jet:~$ lsusb
... 
Bus 003 Device 004: ID 05c6:90bc Qualcomm, Inc. 
...

Was ich allerdings nicht weiß: Warum ist das bei manchen Android-Geräten notwendig, bei anderen aber nicht? Wird da von udev oder der Distribution (in dem Fall: Ubuntu) eine eigene Whitelist gepflegt?

Path of Exile (PoE) ist ein kostenloses Hack'n Slay. Es ähnelt Diablo 2 sehr, greift an manchen Stellen gar explizit auf Storyelemente der Genregröße zurück, es hat aber auch viele Eigenständigkeiten.

Erstmal gibt es natürlich wieder Unmengen an Gegner. Die sind in einer Spielwelt verteilt, die regelmäßig neu generiert wird. Portale verbinden diese mit der Stadt und speichern so den Spielfortschritt, in der Stadt gibt es Questgeber und Händler sowie die Truhe für Gegenstände zu schade zum Verkaufen. Aber zuerst muss ein Charakter gewählt werden. Zur Auswahl stehen nicht ganz die üblichen Archetypen, sondern leichte Abwandlungen davon, ironischerweise ist genau das mittlerweile typisch. Ich entschied mich für die oben zu sehende Jägerin (im Spiel Ranger genannt). Ein großes Böse lauert irgendwo, verseucht die Welt und verursacht die Monsterhorde – das ist der reguläre Plot, aber es fehlen die Blizzard-typischen Renderfilme, die aus der ebenso platten Handlung von Diablo 2 etwas mitreißendes gemacht haben.

Aber nun zu den Besonderheiten. Fähigkeiten wie Zaubersprüche und Spezialangriffe beispielsweise werden nicht mit Skillpunkten gelernt. Sie werden gefunden, fallen als Juwelen von toten Gegnern, liegen in Truhen oder sind Questbelohnungen. Um sie zu nutzen müssen sie in die farblich passenden Sockel der angelegten Ausrüstungsgegenstände gelegt werden.

Haben diese mehrere Sockel und sind diese verbunden, können dann zusätzlich Unterstützungsjuwelen eingesetzt werden. Bei meinem Charakter war das sehr wichtig: Die Hauptattacke ist Pfeilregen, der eine ganze Fläche beharkt, verbunden ist er mit einem Schattenklon, der die gleiche Attacke mehrfach nochmal ausführt und sich selbständig seine Ziele aussucht. So konnte ich mich besonders bequem durch die Spielwelt schnetzeln. Trägt man diese Fähigkeiten mit sich herum werden sie im Laufe der Zeit stärker.

Die zweite Besonderheit ist der riesige Fähigkeitsbaum:

Dort werden passive Fähigkeiten gelernt. Es gibt da simple wie erhöhter Schaden und bessere Attributswerte, aber auch seltenere mit großen Vor- und Nachteilen: Beispielsweise erlernte meine Jägerin eine, die ihre Ausweichfähigkeit um 30% erhöht, Energieschild und Rüstung aber ensprechend verringert. Das beeinflusst dann welche Ausrüstung sie nutzen sollte. Die Auswahl erschlägt natürlich, aber es macht schon Spaß einen Pfad auszuwählen und in eine Richtung zu optimieren.

Desweiteren ist das Konzept besonders. Es ist Free2Play ohne Gängelungen, was besonders in Kontrast zu Diablo 2 auffällt, das als Vollpreisspiel ja keine Gängelungen nötig hatte. Und doch waren damals (historisch begründete?) direkt fühlbare Einschränkungen wie beim Platz in der Schatztruhe vorhanden. PoE hat diese nicht im gleichen Umfang und macht die Truhe dann gleich noch allen Charakteren zugänglich, sodass man einfach Gegenstände tauschen kann. Stattdessen ist das Konzept, mit optionalen Mikrotransaktionen Geld zu verdienen. Da sind dann auch Komfortverbesserungen dabei, aber der Großteil ist wohl Kosmetik. Das funktioniert nur wenn Spieler das Spiel mögen und lange spielen, daher wird versucht das Spiel durch regelmäßige Verbesserungen unendlich lange spielbar zu machen. Auf der GDC gab es dazu einen Vortrag:

Wegen dieses Vortrags habe ich das Spiel jetzt überhaupt nochmal angeschaut, vor Jahren war es schon einmal installiert. Zum einen weiß ich von League of Legends (das ich mittlerweile vor Jahren mehrere Jahre gespielt hatte), dass so etwas gut funktionieren kann und sehr spielerfreundlich ist. Es macht Spaß, ein Spiel wachsen zu sehen. Zum anderen hatte ich PoE damals ausprobiert und zwar nett gefunden, aber nicht richtig toll und trotz des Fähigkeitsbaums etwas simpel. Ich war gespannt zu sehen wie es sich seitdem entwickelt hatte.

Tatsächlich erkenne ich nur wenig wieder, zu kurz war die Spielzeit damals. Es fällt aber schon auf wie viele Mechaniken über dem regulären Spiel drüberzuliegen scheinen. Da gibt es hier Portale eines vergesslichen Geistes zu Mini-Dungeons, in denen Stabilisatoren Erinnerungsfetzen freischalten, die dann in einem Nexus auf einer Karte zu einem Pfad zusammenkombiniert werden können, um andere Dungeons mit dem Potential für besonders gute Items zu erreichen. Dann ist im zweiten Akt ein Jäger, der als Begleiter bestimmte Gegner besiegen hilft und sie dann für eine Arena einfängt. Später gibt es dann eine Spielerbehausung, in der Items magische Effekte bekommen können (und mehr? Ich habe mich mit der nicht stark beschäftigt) und eine Mine, die bestimmte Ressourcen braucht um in die Tiefe zu gelangen (=mehr Items). Und das ist noch lange nicht alles.

All das ist sichtbar gewachsen und macht das Spiel schon tiefer, aber es überlagert auch die Hauptstory. Ich habe dazu den Eindruck, dass die vielen Zusatzinhalte das Balancing zerstören. Lange Zeit zumindest ist das Spiel schlicht zu einfach, was auch an den vielen Erfahrungspunkten und besseren Ausrüstungsgegenständen dieser Zusatzbeschäftigungen liegen könnte. Später kommen dann schwierigere Inhalte, aber teilweise unvermittelt. Dass der Trial of Ascendancy schwieriger ist als die vorherige Spielwelt was angesichts des Namens und der Optionalität noch nachvollziehbar. Aber nicht okay fand ich die Unmöglichkeit, bei einem der ersten Bosse des vierten Akts nicht zu sterben, da dort zufällig verteile Feuerbälle auf die Arena niederregnen und meiner Jägerin einfach zu viel Schaden zufügten. Da konnte ich mich durchsterben, aber mit meinem Build (ohne besonders viel Leben oder Elementarschutz) konnte kein Skill der Welt das überstehen. Da war alles zuvor fairer, ein Tod immer meine eigene Schuld in der konkreten Situation.

Vielleicht wird hier langsam auch für mich spürbar, dass es unter Linux mit Proton in diesem Spiel doch noch Einschränkungen gibt. Viele Spielstunden lang lief das Spiel hervorragend. Aber erfahrene Spieler berichten, dass es später rucklig wird. Das Problem sind wohl die Shader: PoE benutzt wohl gerade später davon Unmengen, sie müssen unter Proton aber bei Bedarf gebaut werden, was zu Rucklern führe. Ruckler aber könne man sich später nicht leisten. Immerhin speichert DXVK/Proton sie auf der Festplatte zwischen, leider reicht das bei den vielen Effektskombinationen später wohl nicht mehr. Und tatsächlich bin ich jetzt trotz DXVK_USE_PIPECOMPILER=1, was etwas zu helfen schien, zuletzt nur wegen eines doofen Rucklers gestorben.

Das ist durchaus schade, denn bis ungefähr Akt 4 lief es fast immer butterweich. Und PoE hebt sich von den anderen modernen Genrevertretern ab, die ich bisher gespielt habe. Victor Vran setzte mehr auf Skillchallenges in der düsteren Spielwelt, was zwar auch Wiederspielwert, aber ein deutlich kleineres Spiel bot. The Incredible Adventures of Van Helsing hatte eine ganze Prise mehr Charme, aber viel weniger Wiederspielwert. Ähnlich Torchlight, das zwar nett ist und gute Spielelemente hat, mich dann aber irgendwann nicht mehr fesseln konnte. Hier wäre noch ein Vergleich mit Tochlight 2 und Diablo 3 interessant, vielleicht in den Kommentaren?

Für meinen Teil bin ich jetzt wohl wieder an dem Punkt angelangt, an dem das Spiel erstmal weiterreifen muss – diesmal bräuchte es keine Spielinhalte, sondern eine innovative Lösung auf Seiten von wine/DXVK/Proton (bis jetzt heißt es allerdings, das Problem sei unlösbar) oder eine native Linuxversion.

Es mag den einen oder anderen überraschen, aber ich bin bzw. war auf Facebook. Facebook ist eine Datenkrake, aber als ich damals in Siegen gestrandet war überwogen für mich die Vorteile.

Jetzt habe ich mich ausgesperrt. Die 2-Faktor-Authentifizierung war an, nutzte aber wohl noch meine alte französische Nummer. Die hatte ich aber am Anfang des Jahres nach einer längeren Übergangszeit gekündigt. Ausgeloggt wurde ich erst jetzt, wahrscheinlich durch den wegen der Firefox-Addonprobleme deaktivierten Facebook-Container.

Und hier wird das mit der Datenkrake wieder wichtig: Facebook bietet mir nicht etwa an, einen vorher gespeicherten Code einzugeben oder mir den Code an meine Email-Adresse (die ich angegeben hatte) zu schicken. Stattdessen soll ich einen Ausweisscan hochladen. Sicherheitstechnisch ist das schon richtig so. Aber es geht hier um Facebook, die Firma, die entgegen eigener Versprechungen und jeglicher Ethik die für die 2-Faktor-Authentifizerung eingetragene Handynummer für personalisierte Werbeanzeigen benutzt. Das hatte meinen letzten Rest Vertrauen in Facebook zerstört, zusammen mit Facebooks Idee, Nutzer nach ihrem Email-Passwort zu fragen.

Daher würde ich den meisten anderen Firmen in dieser Situation einen Scan meines Ausweises schicken, Facebook aber nicht.

Vielleicht findet sich später eine andere Lösung. Es könnte sein, dass mein alter Laptop noch eingeloggt ist, wobei mich das wundern würde. Es könnte einen Weg geben, den Login doch mit Passwort und Email durchzuführen. Facebook wäre schon immer noch praktisch, manche Kontakte erreichte ich nur darüber. Aber bis jetzt sehe ich keine akzeptable Lösung. Und ein Teil von mir sagt auch, dass es eigentlich gut so ist. Es gibt viele gute Gründe dafür, nicht auf Facebook zu sein, wahrscheinlich sollte ich daher diese Entwicklung einfach akzeptieren.

Digital Foundry hat ein Video zu Raytracing in Minecraft hochgeladen, das hervorragend aussieht:

Es zeigt besonders schön, was diese Technologie kann und warum sie interessant ist.

Mit dem Kniff, das in Minecraft einzubauen funktioniert diese Präsentation viel besser als das, was Nvidia bei der Vorstellung der RTX-Karten gemacht hat. Minecraft als grafisch besonders simples Spiel profitiert von der Technologie einfach extrem, und da jeder Minecraft kennt ist auch jedem klar welche grafischen Effekte vom Raytracing kommen und welche nicht. Nvidia dagegen hatte in ihrer Demonstration der neuen Grafikkartengeneration samt Raytracing-Support mit selbstgebauten Aufbauten gearbeitet – bei denen man den Effekt genausogut mit einfacheren Mitteln hätte erreichen können – und dann Raytracing-Effekte in einem damals noch nicht veröffentlichtem Battlefield gezeigt – die daher niemand einordnen konnte und die in einem modernen 3D-Spiel auch nicht herausragend besser als die normalen Methoden wirkten. Besonders gut hatte Gamers Nexus das besprochen:

Hätte Nvidia Raytracing dagegen mit Minecraft oder einem ähnlichen simplen Spiel gezeigt hätte das anders laufen können. Es hätte nur einmal das Spiel in Normalform und dann mit Raytracing gebraucht, und letzteres einmal mit dem FPS-Einbruch der Softwareversion und dann nochmal einmal unter Verwendung der Hardwarekerne in schnell. Dann noch versprechen, durch die neue Hardwareunterstützung sowas nicht nur performanter, sondern auch für Entwickler einfacher umsetzbar zu machen. Dann wäre viel besser klar geworden, wie stark die Technologie in Spielen wirken kann und warum jetzt der Zeitpunkt ist, die altbekannte Technik in moderne Spiele zu bringen.