Technikzeugs - 44

Panik am Sonntag: Die Webseite ist nicht erreichbar, weil ihr Zertifikat abgelaufen ist. Eingeloggt auf dem Server steht der Cronjob zum Erneuern desselben eigentlich, aber der Test zeigt, dass der genutzte Client simp_le nicht mehr funktioniert:

AttributeError: 'module' object has no attribute 'openssl_md_meth_names'

Also erstmal simp_le aktualisiert. Keine Änderung. Google meint, hashlib fehle und müsse installiert werden. Dort scheitert die Installation:

TypeError: 'frozenset' object is not callable

Hier hat Stackoverflow eine Lösung, das Löschen der Datei /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so (wtf?). Tatsächlich hilft das, hashlib wird installierbar. Doch ändert sich für simp_le gar nichts.

An dem Punkt wurde es mir zu doof. Certbot ist der ursprüngliche Letsencrypt-Client. Dort das Release heruntergeladen, fünf Minuten den richtigen Befehl herausgesucht, ausgeführt, nginx zum neuen Zertifikat gelinkt und die Seite war wieder online.

Meine Lektionen:

1. Python ist nicht die richtige Sprache für solche Anwendungen. Man sollte etwas möglichst ohne weitere Abhängigkeiten haben, oder etwas das zumindest in einem stabilen Ökosystem agiert. Bash wäre okay, Binaries wären ideal. Python aber ist instabil.
2. Mir ist bewusst, dass certbot ebenfalls Python benutzt. Aber das ist die zweite Lektion: Bei solchem Infrastruktur-kritischem Zeug ist es besser, das große Softwareprojekt zu nehmen. Wenn dort etwas bricht wird das große Projekt es schnell reparieren, während die sympathische light-Variante (denn das war simp_le) eben kaputt bleibt.
3. Das Zertifikat braucht sein eigenes Monitoring, die Uptime-Kontrolle hat das abgelaufene Zertifikat nicht bemerkt.

Update

Der certbot hat sich seit diesem Wechsel bei mir wirklich bewährt. Es gab keine Fehlermeldungen mehr, keine Probleme mit dem Code. Woran man aber denken sollte ist der Neustart von nginx. Das wurde vorher von dem Cronjob erledigt, der Cronjob den certbot anlegt aber erledigt das nicht. Man könnte den Aufruf von certbot also ebenfalls wieder in ein Skript packen, mit dem Skript den Befehl in der Crontab ersetzen, und dort regelmäßig den Webserver neustarten.

Nach den guten Erfahrungen mit den letzten Feral-Ports kaufte ich Shadow of Mordor zuversichtlich, es zumindest bald spielen zu können. Stattdessen lief das Spiel direkt. Zwar tauchte eine Warnung über nicht unterstützte Treiber auf, doch konnte ich keine Probleme mit dem freien Mesa-Treiber wahrnehmen. Freudige Überraschung, denn mein System ist schon prozessorseitig schwächer als die empfohlenen Anforderungen fordern, und eben entgegen den Anforderungen mit einer AMD-Grafikkarte ausgestattet.

Es ist ein AAA-Actionspiel im Tolkien-Universum. Man spielt einen Ranger, dessen Familie von Saurons Schergen in einem Ritual getötet wurde, an dessen Ende auch der Ranger sterben sollte, stattdessen aber von einem Geist besessen wurde. Ergo ist er unsterblich und kann Rache nehmen. Was das Ritual sollte, welche Motivation die Bösen haben, bleibt unerklärt, so wie auch der Rest der in den Hauptmissionen erzählten Geschichte völlig absurd ist

Als Spiel also ein Actionspiel, läuft man in einer von zweien mittelgroßen Welten umher. Überall gibt es Orks, und die greifen einen an. Man kann sich stattdessen durchschleichen oder wegrennen, man wird aber so oder so viel kämpfen, und die Kämpfe sind gar nicht schlecht. Angreifen mit linker Maustaste, Kombos bauen, Spezialattacken auslösen, dabei immer im richtigen Moment blocken, gelegentlich den Bogen benutzen - ich war anfangs ziemlich überfordert. Besiegte Gegner, gesammelte Kräuter und erfüllte Missionen bringen Erfahrungspunkte, mit denen der Charakter verbessert werden kann und mit denen neue Fähigkeiten - wie das Teleportieren zum Gegner - freigeschaltet werden. Mit einer anderen Währung gibt es passive Upgrades, wie erhöhte Lebensenergie, dadurch werden die Kämpfe trotz steigender Komplexität der Gegner (Schildträger und Berserker, die man erst lähmen muss, Speerwerfer, denen schwierig auszuweichen ist) im Verlaufe des Spiels eher leichter. Und man lernt ja auch als Spieler dazu.

Eigentlicher Reiz des Spiels ist das Nemesis-System. Manche der herumlaufenden Orks sind Captains, stärker als normale Orks und mit zusätzlichen Stärken und Schwächen. Besiegt dich so einer wird er stärker, und erinnert sich bei der nächsten Begegnung an dich. Ebenso können Normalo-Orks zum Captain befördert werden, wenn sie im Kampf den Ranger (er)schlagen. Captains können auch fliehen, und bekommen dann Narben von der vorherigen Begegnung, oder sie spotten über den Ranger, wenn man selbst weggerannt ist. Von den Captains gibt es drei Stufen, und obendrüber die Warlords, die nochmal stärker sind und eigene Bodyguards haben. Die zu besiegen ist jeweils eine Mission, aber es gibt dafür verschiedene Wege.

Generell will man gegen die Spezial-Orks ihre Schwächen einsetzen. Für die braucht man Infos, die man beim Herumlaufen findet, so können Orks ausgefragt werden oder befreite Gefangene Informationen weitergeben. Dadurch erfährt man z.B., dass ein bestimmter Ork gegen Fernattacken immun ist, aber mit einer Schleichattacke direkt getötet werden kann und Angst vor Feuer hat. Relativ schwierige Kämpfe werden so sehr viel einfacher, gerade die Warlords, die sowieso schon stark sind und dazu noch in orkbewehrten Festungen herumlaufen.

In der zweiten Welt kommt eine Erweiterung des Systems hinzu: Der Geist im Ranger kann plötzlich Orks übernehmen. So manipulierte Orks kämpfen für den Ranger, und das funktioniert auch mit Captains, denen man dann sogar Befehle geben darf. Andere Captains angreifen, zum Bodyguard eines Warchiefs werden und ihn dann hintergehen - der Captain gehorcht, und der Ranger sammelt seine Orkarmee. Nachdem man in den vorherigen zwei Dritteln des Spiels Orks bekämpft hat ist das eine nette Abwechslung, und ziemlich unerwartet. Es wird teil der Story, aber auch in der Spielwelt laufen dann viele der besessenen blau leuchtenden Orks herum, die den Ranger ignorieren und in einem Kampf sich gegen die anderen Orks stellen. Sehr angenehm.

Ob mit Ork-Manipulation oder ohne, insgesamt ist das Nemesis-System toll. Es trägt das Spiel, und kann sicher im kommenden Nachfolger sehr schön erweitert werden. Wenn Orks sich über die dritte Flucht in kurzer Zeit lustig machen, oder als ein überpowerter Bogenträger zu meiner Nemesis wurde - er killte mich bestimmt vier mal - und entsprechend selbstbewusst in den nächsten Kampf geht, ist die Rache ziemlich motivierend.

Shadows of Mordor jedoch hat auch seine Macken. Wie oben erwähnt ist die Story absurd, gerade für Herr der Ringe. Man muss das Ausblenden und es als reines Aktionspiel (mit Charakterupgrades) begreifen, aber auch dann ist es ein komisches. Die herumlaufenden Orks sind das Problem, die kommen nämlich immer und sofort wieder. Man ist also gerade dabei, alle Orks in einer Hausruine zu besiegen, hat vielleicht sogar ein paar Orks im Schleichmodus erledigt und vor dem Kampf ein paar Pfeile abgeschossen. Zwei Sekunden später sind die Orks wieder da. Und ich mein nicht, dass man weggegangen ist und wiederkommt und dann wieder Orks sieht - noch während man da steht kommen Orks von der Seite und nehmen die gleichen Positionen ein. Es gibt null Persistenz der eigenen Handlungen in der Welt, nur das Nemesis-System täuscht da ein bisschen drüber hinweg. Klar, dass macht viele Aspekte des Spiels einfacher, so sind auch immer Kämpfe möglich, aber es fühlt sich gerade anfangs sehr komisch an; später wird es nervig, immer wieder Orks auszuweichen oder schon wieder an der gleichen Stelle niederzumetzeln. Generell ist es eine vertane Chance, und etwas, das in Spielen wie Just Cause trotz ähnlicher Gegnermassen besser gelöst wurde.

Der Linux-Port ist bugfrei und kein einziges mal abgestürzt. Die Performance ist okay, ich konnte es mit meinem übertakteten Phenom 955 und einer Radeon HD 7950 auf unteren bis mittleren Einstellungen spielen. Nicht immer mit 60 FPS, das Spiel wirkte aber niemals rucklig. Für ein zweieinhalb Jahre altes AAA-Spiel auf Hardware unter den empfohlenen Systemanforderungen und mit nicht offiziell unterstützten freien Treibern war das hervorragend.

Was man alles hinkriegen kann, wenn man nur will! Unsere kleine Serendipity-Gemeinde hat sich nun schon zum dritten Mal in Essen im Linuxhotel getroffen, und es war toll. Mehr noch als beim vorherigen Treffen war es ein erfreuliches Wiedersehen, denn man kennt sich ja noch besser. Aber es war eben auch Thomas wieder mit dabei, der im Vorjahr fehlte.

Meiner Meinung nach haben wir die Zeit hocheffektiv genutzt. Zum einen, um im Haus Großjung und außerhalb gut zu essen, und dort und im Hotel über Allerlei zu reden. Aber außerdem auch ganz konkret mit Arbeit an Serendipity:

1. Die letzten Blocker waren gemeinsam schnell beseitigt, sodass die finale Version 2.1 veröffentlicht werden konnte.
2. Dabei haben wir den Anlass genutzt, den Releaseprozess zu analysieren. Viele kleine Aufgaben sind zu erledigen, eventuell können wir das nun etwas reduzieren.
3. Wir (nun, die anderen, denn Garvin und ich waren am Vorbereiten des Releases) sind durch die Plugins gegangen und haben geprüft, was davon überhaupt noch relevant ist und welche verbessert werden sollten.
4. Um neuen Entwicklern Orientierung zu geben, wurden geeignete Bugs im Tracker als #easyfix markiert. Die Bugs sind nicht alle super-einfach, aber erfordern kein umfassendes Vorwissen über die Interna von Serendipity und sind daher gute Einstiegspunkte.
5. Der Issue-Tracker wurde auch mit Ideen für die nächste Version bevölkert, und die bestehenden Ideen wurden weitergeplant, entsprechende Kommentare hinterlassen. Ich glaube, uns ist jetzt allen ziemlich klar, wo wir anpacken können wenn wir Zeit in s9y investieren.

Es gab außerdem eine wunderbare mitternächtliche Debugging-Session, als klar wurde, dass dieses erste Release der 2.1 tatsächlich einen natürlich weniger wunderbaren, ziemlich blöden und (wie sich später herausstellte) von mir gemergten Bug hatte. Aktivierte boolsche Pluginoptionen wurden als deaktiviert angezeigt. Den Bug fixten wir in Teamarbeit, und das war wirklich kein 5-Minuten-Fix. Dank dieser Arbeit konnten wir Sonntag morgens dann direkt das Patchfix-Release 2.1.1 veröffentlichen, sodass sicher niemand außerhalb unseres Teams von diesem Bug gebissen wurde.

Ich freu mich jetzt darauf, zusammen die nächste Version anzugehen. Ich möchte den Cache weiter verbessern und standardmäßig aktivieren, Garvin beim MySQL-UTF8-Problem helfen, echt skalierende (responsive) Bilder in Blogeinträgen haben und Unterstützung für rel="Trackback" einbauen. Und gerne wieder im nächsten Jahr beim Treffen dabeisein.

Die anderen haben auch geschrieben:

• Garvin den offiziellen Blogeintrag
• YellowLed unter #easyfix
• Thomas unter #s9ycamp2017 (ob die sich abgesprochen haben?)
• Mario unter S9YCamp 2017

Ich weiß nicht mehr, wie VoidExpanse auf meine Wunschliste gerutscht ist. Aber da war es nun mal, und als es kürzlich reduziert war habe ich es gekauft und gespielt. Die Steambewertungen sind durchwachsen, und in meinen Augen passt das gut zu dem Spiel: Es hat ein paar Macken, aber es macht trotzdem Spaß.

Der Spieler startet in einem kleinen Schiff vor einer Raumstation. In dieser sitzt ein Auftraggeber, der ein paar Missionen anbietet, die aus dem ersten Sonnensystem ein Tutorial machen. Jedes Sonnensystem ist seine eigene kleine Karte, verbunden durch Stargates. In den Systemen fliegen viele Piraten umher, später auch feindliche Aliens, und es gibt Stationen der drei Fraktionen. Denen kann man sich anschließen und für sie Missionen erledigen, die dann durch die Hauptstory führen. Natürlich wird das Schiff durch bessere Versionen ersetzt, ebenso die Ausrüstung, und es gibt Erfahrungspunkte, mit denen der Charakter verbessert werden kann.

Als Spiel ist es sehr kampflastig. In wirklich jedem System fliegen Piraten herum, und vor allem später ist die erste Aufgabe in jedem neuen Sonnensystem, genug Piraten abzuschießen um einen sicheren Korridor zwischen dem Stargate und der Station oder den anderen Stargates zu zu bauen. Das ist nicht realistisch und nicht immer spaßig. Später werden die Piraten durch Aliens ersetzt, und dann war mein Hauptproblem, genug Reparaturmodule zusammenzubekommen. Aber an den Weltraumkämpfen ändert sich nicht viel. In meiner Story - ich schloss mich den Fanatics an - gab es auch keine Fraktionskämpfe, keine Übernahme oder den Bau von Stationen. Zwar könnte man die Türme bestehender Stationen aufrüsten, aber warum man das tun sollte erklärt das Spiel nicht. Eventuell etwas für den Multiplayer, aber es in der Kampagne als unnütze Option zu haben wirkt seltsam.

Trotzdem macht das Spiel Spaß. Vor allem wegen des sichtbaren eigenen Forschritts: Die Feinde werden schwerer, aber man selbst auch kontinuierlich stärker, durch die bessere Ausrüstung und investierten Fähigkeitspunkte. Es ist dann schon cool, Schiffskonfigurationen auszuprobieren und die schwächeren Piraten von vorher mit Gauss-Kanonen zu vernichten, und plötzlich mit den großen Alienschiffs mithalten zu können. Ich hatte Spaß daran, meine Fähigkeiten an die neue Schiffskonfiguration anzupassen, durch Fähigkeiten den Energiebarf der Waffen zu senken (und gleichzeitig einen besseren Reaktor zu kaufen). Oder eine Weile Artefakte zu sammeln, um von den Wissenschaftlern Spezialupgrades kaufen zu können. Auch der Story zu folgen ist nicht völlig daneben - zwar fehlen Überraschungen und sind die Missionen nicht wirklich abwechslungsreich, aber man will ja doch das Universum retten. Und bekommt hier die Chance.

Es lief bei mir einwandfrei mit stabilen 60 FPS mit AMD und den freien Mesa-Treibern. Auch Bugs habe nicht bemerkt, abseits einzelner Wegfindungsprobleme. VoidExpanse ist kein hervorragendes Spiel, aber es ist nett und hat mich durchaus eine Weile unterhalten. Für den nächsten Sale kann ich es empfehlen, und ich werde mir wohl noch die neue Erweiterung Pariahs' Bane holen.

Weg mit Unity, weg mit Ubuntu Touch, also weg mit dem Konvergenz-Ansatz und dem freien Ubuntu-Smartphone - es ist schon eine ziemliche Bombe, die Mark Shuttleworth angekündigt hat. Unity soll durch Gnome 3 ersetzt werden, dessen katastrophaler und nutzerfeindlicher Start damals wohl die Ursache für die Eigenentwicklung Unity war. Ubuntu Touch wird ganz gestrichen, das Telefongeschäft soll durch die funktionierenden Geschäftsfelder spezialisierter Cloudsoftware ersetzt werden, für Server und für die IoT-Blase.

Das gescheiterte Ubuntu-Smartphone

Zur Absage des Telefons ist es bemerkenswert, in welcher Tradition Canoncial hiermit steht. Es reiht sich ein in eine Serie von freien Betriebssystemen, die angeblich am Markt gescheitert sind, es aber nie wirklich auf den Endkundenmarkt geschafft haben. Zuerst wäre da das wundervolle WebOS, das von HP aufgegeben wurde bevor die Geräte verkauft wurden, nur um dann mit den auf den Markt geworfenen Geräten einen riesigen Verkaufserfolg zu verbuchen. Dann gab es Nokias Meego, das auf dem Nokia N9 lief. Von Kunden und Kritikern geliebt, wurde es wohl schon deswegen vom Microsoft-Abgesandten Elop zugunsten einer Windows-Strategie sabotiert, die dann nebenbei auch noch Nokia selbst eliminiert hat. Mozillas FirefoxOS is noch gar nicht so lange tot, aber es war schon vorher lange ein Zombie. Hier gab es zwar Geräte auf dem Markt, nicht aber auf dem heimischen und nicht auf nur ansatzweise konkurrenzfähigen Geräten, ein Fokus auf Schrottprodukte für Entwicklungsländer (statt: vernünftige Budgetmodelle für den internationalen Markt) konnte nicht funktionieren.

Und jetzt Ubuntu Touch, das es praktisch gar nicht auf den Markt schaffte. Dem Vernehmen nach waren die Hardwarehersteller nicht interessiert, definitiv aber hatten die Kunden hier kaum Einflussmöglichkeit, sieht man mal vom gescheiterten Kickstarterprojekt Ubuntu Edge ab, bei dem das Modell zu teuer ($700) und das Ziel (32 Millionen!) zu ehrgeizig war. https://www.ubuntu.com/mobile/devices zeigt 4 Geräte: BQ Aquaris E4.5, BQ Aquaris E5, Meizu MX4 und Meizu Pro 5. Das erste davon ist derzeit, so wie vorher schon andauernd, nicht auf Lager und konnte auch nur online gekauft werden. Aquaris E5? Nicht erhältlich. Meizu MX4? Da ist nichtmal mehr die Shop-Seite online. Schließlich also das Meizu Pro5? Nein, ebenfalls nicht erhältlich.

Selbst wenn die Geräte verkauft worden wären, war Ubuntu Touch wohl noch nicht bereit, wobei die Reviews neuerer Modelle immer positiver wurden. Doch um ein mobiles Betriebssystem zu etablieren braucht es Jahre. Amerikanische/Angelsächsische Firmen denken in Viermonatstakt, es ist ein Klassiker, dass ihnen der lange Atem fehlt. Aber ohne eine Langzeitstrategie funktioniert dieser Markt nicht: Die Software muss perfekt sein, die Hardware muss stimmen, die unterschiedlichen Preissegmente müssen abgedeckt werden - oder zumindest eine profitable Nische ergattert. Das hat anfangs nichtmal das konkurrenzlose iPhone hinbekommen.

Aber wie Ubuntu es versucht hat kann es halt nicht funktionieren: Wenn die Kunden keine Geräte in die Hände bekommen, können sie kein Interesse entwickeln, dann können auch keine Hardwarehersteller motiviert werden. Ubuntu Touch scheiterte hier wohl ganz am Anfang mit dem Ubuntu Edge. Wäre das durchgegangen oder die gesammelten Millionen für ein kleineres Start-Smartphone benutzt worden, wären die Erfolgschancen wesentlich größer gewesen. Jetzt aber hätten neue Betriebssysteme schon deswegen keine Chance, weil mögliche early adopter zu oft verbrannt wurden - niemand wird je wieder glauben, dass eine Firma lange genug ihr alternatives mobiles OS unterstützen wird.

Der Wegfall Unitys

Die Entwicklung auf dem Desktop ist eigentlich weniger dramatisch, aber sie betrifft mehr Nutzer. Mit Ubuntu 18.04, also schon nächstes Jahr, soll zu Gnome 3 gewechselt werden. Das heißt natürlich auch, dass die Vielzahl an nötigen Unity-Verbesserungen nicht mehr kommen werden, wobei mir nicht ganz klar ist, wie weit die schon gebaute neue Unity-Version die bisherige verbessern wird.

Zu Gnome 3 zu wechseln ist aus einer gewissen Perspektive natürlich richtig. Es stellt die Leute zufrieden, die in Ubuntus Unity eine unnötige Fragmentierung des Linux-Desktops sahen. Auch wenn Gnome 3 angepasst wird werden müssen, ist das für Canonical doch sicher weniger Arbeit als die Entwicklung des eigenen Desktops, erst recht, wenn Mir mit aufgegeben wird. Und Gnome 3 von heute ist nicht das Desaster von damals, von dessen Regressionen und der stolz vorhergetragenen Nutzerfeindlichkeit seiner Entwickler Ubuntu schreiend weglief.

Allerdings ist es kein Schritt, den man mögen muss. Ubuntu hat viel Zeit und Energie darauf verwendet, eine Nutzerbasis zu schaffen, die Ubuntu mit Unity und eben nicht Gnome 3 benutzte. Viele - wie ich - werden Unity irgendwann zu schätzen gelernt haben. Jetzt also doch zu Gnome, nach all der Abwehrarbeit? Da werden einige nicht mitmachen. Auch, weil das Vertrauen in die Gnome-Entwickler, einen vernünftigen Desktop zu bauen - ohne kaputtsimplifizierten Dateimanager, ohne auf einem PC einfach nur fehlplatzierte Elemente wie Bildschirmrotationsbuttons und Wischgesten zum Login - bei mir zum Beispiel nicht da ist.

Das große Bild

Da der Schritt zu Gnome außerdem mit der Aufgabe der Konvergenz-Idee (das Smartphone als Desktop-PC zu nutzen) verbunden ist, verliert Ubuntu heute auch sein gesamtes Zukunftspotential. Statt eigenem Desktop und eigener Zukunftsvision gibt es in Zukunft das, was die anderen Distributionen auch anbieten, nur wahrscheinlich in grau-lila, und eine Zukunftsvision für den Desktop gibt es schlicht gar nicht mehr. Das mag realistisch, das mag für ein Arbeitswerkzeug angemessen sein, aber es hat keinen Charme.

Außerdem verliert Linux hier Vielfalt zu einem Zeitpunkt, an dem es meiner Meinung nach Vielfalt bräuchte. Gnome ist hoffnungslos verwoben mit systemd, und systemd ist ein Projekt, das aktiv versucht den existierenden Linuxdesktop zugunsten einer Monokultur zu zerstören. Nun war Ubuntu sowieso schon auf diesen Zug aufgesprungen - und ich daher auf meinem Hauptsystem kein Ubuntu-Nutzer mehr. Doch hatte ein eigenständiges Ubuntu mit Unity und Konvergenz und Mir wenigstens noch die Chance, eigene Agendapunkte zu setzen, im Fall der Fälle upstart zu reaktivieren oder ein anderen Initsystem zu verwenden, oder den Desktop ganz auswechseln, gar den Zukunfts-PC zu erfinden.

All diese Möglichkeiten hat Ubuntu jetzt nur noch sehr begrenzt - und vor allem hat das Projekt klar gemacht, dass es diesen Anspruch aufgibt. Ubuntu ist jetzt nur noch eine Distribution wie die anderen.

Hacker News Colors ist ein als Addon verpacktes Userscript. Es verändert Hacker News, indem es einen farbigen Balken (bisher) unter dem Upvote-Button zeichnet. Der Balken signalisiert durch seine Farbe, wieviele Upvotes ein Artikel hat. So sieht man schneller die besonders beliebten Artikel, die bei HN durch das Rankingsystem ja nicht unbedingt auf dem höchsten Platz sind.

Mit der neuen Version kommen zwei Verbesserungen dazu. Die erste ist Unterstützung für Multithread-Firefox, e10s. Es war fast ein bisschen ärgerlich, wie einfach das zu aktivieren war. Alles was es brauchte war ein Eintrag in der package.json:

"permissions": {
    "multiprocess": true
},

Da der Code sowieso nur die mod-page-Funktion des SDK benutzte war es bereits kompatibel. Hätte Mozilla das nicht automatisch erkennen können?

Farbige Kommentarzähler sind die neue Funktion, und das war etwas aufwändiger. So sieht es aus:

Die Balken zu zeichnen ist einfach, das ist wie bei den Upvotes. Aber die Option sollte ja optional sein. Dafür muss eine Einstellung hinzugefügt werden, damit die gelesen werden kann braucht es Kommunikation zwischen dem Addon und dem seitenverändernden Javascript - und zwar auch bei der Änderung der Einstellung, nicht nur bei der Initialisierung der Erweiterung, sonst wirkt die Änderung erst nach einem Neustart des Browser. Den entsprechenden Commit verlinke ich hier auch für mich zum späteren Nachschlagen.

Heute waren zwei schöne Sendungen im Briefkasten. Einmal ein gebraucht gekaufter Gameboy, den ich verschenken werde - dazu vll ein andermal mehr. Die zweite Sendung war eine Ausgabe der Screenguide. Die wurde mir geschickt, weil ich für diese Ausgabe des Magazins einen Artikel über Serendipity geschrieben habe. Online ist er nicht, aber der Anreißer ist außerhalb des gedruckten Magazins lesbar.

An euch zu urteilen darüber, ob es mir gelungen ist, aber die Absicht des Artikels war eine Vorstellung von Serendipity als Blogsoftware. Ich wollte und sollte gleichzeitig zeigen, was Serendipity ist, was es kann und warum es interessant ist. Und das Ganze mit ein paar schönen Screenshots untermauern.

Solch einen Artikel zu schreiben fand ich durchaus spaßig. Auf der einen Seite ist es doch nochmal was anderes als was ich bisher so schrieb. Anderseits passen all diese Dinge (Wissenschaftliche Artikel, Blogartikel, früher Wikiartikel bei UbuntuUsers) bei dieser Art von Text irgendwie zusammen. Alles wird wiederbenutzt.

Das nun auf Linux und mit Mesa laufende Adventure hat mir ziemlich gut gefallen.

Life is Strange baut eine sehr starke Atmosphäre auf. Zur Erinnerung: In dem Spiel steuert man in der Third-Person-Ansicht Max. Sie ist eine 18-jährige Studentin, die für ein Stipendium in ihre alte Heimatstadt zurückgekehrt ist. Das hauptsächliche Storyelement ist das zentrale Spielelement: In einer Extremsituation lernt Max gleich zu Anfang des Spiels, dass sie die Zeit zurückdrehen kann. Das Spiel nutzt das für alle möglichen Rätsel, aber auch für Kleinigkeiten. Zum Beispiel kann man ein Gespräch beginnen, darin eine neue Information lernen, daraufhin zurückspulen und die neue Information verwenden.

Hauptsächlich aber trifft man Entscheidungen. Ein Beispiel: Max wird Zeuge, wie ein Schulwächter eine Schülerin heftigst angeht. Sie hat nun zwei Optionen: Schießt sie ein Foto? Das nimmt ihr die Schülerin übel, aber das Foto könnte später nützlich sein. Oder geht sie dazwischen, um der ohnehin leidenden Schülerin den Rücken zu stärken? Dann ist der Schulwächter sauer auf sie.

Die kurzzeitigen Auswirkungen werden direkt gezeigt und Max spricht in ihren Gedanken mit sich selbst und dem Spieler, ist praktisch immer unsicher ob ihrer Entscheidung. Aber was langfristig deswegen passiert, das kann erstmal weder der Spieler noch Max wissen. Verlässt man das momentane Gebiet, dann sind die Entscheidungen fest. Man kann also erstmal ausprobieren, muss sich dann aber doch festlegen. Das macht die Entscheidungen nur noch schwieriger und reizvoller.

Dieses Ausprobieren und das dadurch vom Spieler festlegbare Tempo hilft bei der großartigen Atmosphäre. Gerade in der ersten Episode ist das Spiel voller Melancholie. Die Heimkehr in eine alte Heimat, das Wiederfinden alter Freunde und das Kennenlernen neuer Freunde, das alles in einer Schulatmosphäre und einer uns allen durchs Fernsehen vertrauten amerikanischen Kleinstadt. Zusammen mit der lichtdurchfluteten Grafik, den leicht abstrakten Texturen und der weichen Musik zaubert das Spiel unausweichlich seine eigene Stimmung in das Bewusstsein des Spielers. Sehr deutlich wird das im Intro:

Life is Strange wird dadurch richtig fesselnd. Als Episodenspiel muss das vor der Veröffentlichung der Folgeepisoden grausam gewesen sein.

Vor diesem Hintergrund entfaltet sich dann eine düstere und größere Story. Max rettet Chloe, die sich als eine alte Freundin und dem Storymittelpunkt des Spieles entpuppt. Chloes Freundin Rachel ist verschwunden, schon seit Monaten, ihr Verschwinden aufzuklären wird sehr bald zur Priorität. Gleichzeitig ist die Schule voller sozialem Drama, Life is Strange ist da nicht zimperlich: Selbstmord, Drogen, Sex, Abtreibung - alles wird thematisiert, und das nicht nur abseits der Story. Statt Melancholie wird es gegen Ende mehr eine Horrorstory.

Aber wie alle Geschichten mit Zeitreise ist die Story scheiße, richtig? Ja und Nein. Tatsächlich macht Life is Strange Zeitreisen anfangs vorbildlich. Da sie auf den derzeitigen Standort beschränkt und ihre Auswirkungen das hauptsächliche Spielelement sind gibt es nicht die sonst üblichen Inkonsistenzen. Es ist nicht verwirrend, nicht dumm, der Spieler wird nicht vor den Kopf gestoßen. Und der Rest der Story bleibt der interessante Fokus. Später ändert sich das leider. In späteren Episoden benutzen die Autoren Zeitreisen in größerem Umfang, ab dem Zeitpunkt wird es wirr. Letzten Endes sind eben doch alle Zeitreisegeschichten doof. Außerdem wird später die Geschichte arg düster und das ein ums andere Mal vergreifen sich die Autoren dabei im Ton. Dann ist besonders was Max so von sich gibt nicht mehr nachvollziehbar.

Und ja: Es gibt ein richtiges Ende und es gibt eine finale Entscheidung, die Entscheidungen vorher haben zumindest im kleineren Auswirkungen. Aber im großen ist die Story strikt linear und die Entscheidung am Ende wird dem Spieler durch die Inszenierung nahezu vorgegeben. Life is Strange verliert also später etwas von seiner anfänglichen Klasse.

Der Entwicklerkommentar, der dem Spiel beiliegt, ist nebenbei gesagt nicht gut gemacht. Es sind nur ein paar Videos, die im Hauptmenü ausgewählt werden können, die vorher als mehrere Gigabyte große Dateien heruntergeladen werden müssen. Besser als nichts, das schon, aber kein Vergleich mit der Vielzahl an Interna und Standortkommentaren, die z.B. in Deus Ex: Human Revolution direkt ins Spiel integriert wurden. An solchen Details merkt man, dass das Spiel letzten Endes dann doch keine so tolle Produktion ist.

Aber das soll nicht täuschen: Life ist Strange ist trotz der Kritikpunkte ein gutes Spiel, ein Kleinod. Technisch ist alles einwandfrei, das Spiel läuft mit dem freien Radeon-Treiber unter Linux absolut stabil, ich konnte keine Bugs beobachten. Die Story mag gaga werden, aber man will trotzdem ihre Auflösung wissen, sie kann zudem doch überraschen. Die Figuren werden toll gezeichnet, insbesondere Max und Chloe wachsen einem ans Herz. Spielerisch gibt es am Ende ein paar blöde Schleichpassagen, aber überwiegend ist das Entdecken der Spielwelt, die Zeitmanipulation, das Lösen der Rätsel; sind die Gespräche und die Entscheidungen interessant und spaßig und tragen durch die nicht zu kurze Spielzeit.

Mir wurden von Tuxedo fünf Ticketcodes zur Cebit in Hannover gegeben, die ich hier an euch weitergeben will.

© Deutsche Messe

Die Cebit läuft vom 20. bis zum 24. März, die Tickets sind jeweils für alle Veranstaltungstage. Wie immer geht es bei der Messe um Technik, auch digitale. Besonders interessant dürfte dieses Jahr das Gespräch mit Snowden werden. Ansonsten geht es aber in erster Linie um neue Produkte bekannter und weniger bekannter Hersteller. Das ist nicht für jeden, aber für Interessierte kann das schon sehr interessant sein. Das gleiche gilt bestimmt auch für das Open Source Forum.

Hinterlasse einfach einen Kommentar mit ausgefülltem Emailfeld in den Kommentaren. First come, first served.

Edit: Der letzte Code wurde gerade verschickt.

Vor etwas mehr als einem halben Jahr ist das Adventure Life is Strange für Linux veröffentlicht worden. Inzwischen sind auch die aktuellen freien Treiber soweit, um das Spiel mit einer AMD-Grafikkarte zu spielen – wobei natürlich auch möglich ist, dass zwischenzeitlich das Spiel ebenfalls gepatcht wurde. Denn bei den Hardwareanforderungen auf der Steamseite wird nun sogar die minimale Mesa-Version für AMD-Karten angegeben (11.2). Ich habe aber zwischendurch immer mal wieder getestet, lange funktioniert das Spiel mit Mesa noch nicht.

Die Befürchtungen wegen den verlangten hohen Hardwareanforderungen waren unnötig. Das Spiel läuft auf meiner mittelmäßigen Hardware gut, schnell und stabil. Feral hat wieder mal einen hervorragenden Port abgeliefert.

In Life is Strange folgt man einer 18-jährigen Fotografiestudentin in einer amerikanischen Kleinstadt. Sie kann die Zeit zurückdrehen, und es gibt immer wieder Entscheidungen zu treffen. Das Spiel verrät, wenn die Entscheidungen Auswirkungen auf die Story haben werden, aber nicht welche. Und natürlich löst die erste Episode alleine die Auswirkungen auch nicht auf.

Vor dem Spiel selbst muss ich daher warnen. Es ist ein Adventure, und ich mag keine Adventure. Aber es ist wirklich fesselnd gemacht. Ich halte die Story für klischeegeladen und unglaubwürdig. Doch trotzdem möchte ich nach dieser ersten Episode wissen wie es weitergeht. Die Warnung ist also eine vor der kostenlosen ersten Episode: Nicht spielen, wenn man den Rest nicht kaufen will. Das Komplettpaket der verbliebenen Episoden kostet noch 20€.

Update: Dieses Wochenende sind die übrigen Episoden auf Steam im Sonderangebot, sie kosten komplett 5€. Der Kauf ist wärmstens empfohlen.

Mein letzter Test verschlüsselnder Messenger für Android war nicht sehr erfolgreich. Mit Ring und Tox taugten zwei der drei Kandidaten nicht, und Kontalk ist zwar nett, aber ihm fehlen mir wichtige Funktionen wie Telefonie. In den Kommentaren wurde Riot als Alternative vorgeschlagen, das ich mir inzwischen näher angesehen habe.

Riot ist ein Messenger mit Chaträumen. Wer einmal IRC oder hippe Abwandlungen wie Slack benutzt hat wird sich schnell zurechtfinden. In den Chaträumen sitzen die Nutzer und können miteinander reden. Riot baut hierbau auf Matrix auf, und Matrix wiederum ist ein Protokoll, mit dem solche dezentralisierten Internetanwendungen gebaut werden können. Für den Nutzer ist das aber erstmal ziemlich irrelevant, wenn es denn funktioniert.

Und das tut es. Riot ist schlicht ein guter und vor allem kompletter Messenger. Als IRC-Ersatz wirkt es komplett einwandfrei, die Chaträume funktionieren und es gibt Nutzer. Als privater Messenger wird es ein bisschen komplizierter. Die UI versucht diesen Anwendungsfall zu unterstützen, am Ende landen die zwei Nutzer dann aber doch wieder sichtbar in einem Chatraum. Das macht nichts kaputt, ist nur ein bisschen verwirrend, ein UI-Problem. Dafür funktionierte alles: Das Hinzufügen der Nutzer, das Schreiben, das Empfangen von Nachrichten. Sogar Sprach- und Videotelefonie klappte, stabil, wobei die Auflösung des Videos nicht toll war.

Dabei konnte ich keine Trafficexplosion beobachten. Das ist kein Wunder, denn Matrix ist kein P2P-Protokoll für die Nutzer, sondern ein Protokoll in dem jeder Nutzer seinen eigenen Hauptserver hat (siehe FAQ) und die Server miteinander reden lässt. Für einen mobilen Messenger ist das sehr viel besser, denn P2P ist Gift für trafficbeschränkte Mobilfunknetze und die Akkulaufzeit.

Man kann bei Riot tiefer hinabsteigen, und dann wird es für Poweruser richtig interessant. Denn durch Matrix unterstützt Riot Bridges, um Räume in anderen Netzwerken zu spiegeln – ähnlich wie ich das mit Matterbridge für Gitter-IRC gemacht habe. Für IRC wird das viel verwendet, und wer einen der populären Chaträumen in Matrix beitritt bekommt dann schnell eine Nachricht vom IRC-Kontrollsystem. Von meinen früheren Erfahrungen auf dem Desktop mit dem Projekt, als Riot noch Vector hieß, weiß ich auch, dass sowas recht einfach einzurichten war.

Doch Moment: Verschlüsselung, viele Teilnehmer und verschiedene Protokolle? Wie hat Riot die ganzen Probleme damit aufgelöst? Antwort: Haben sie nicht. Riot unterstützt Verschlüsselung, doch erst seit kurzem. Sie muss manuell für jeden einzelnen Raum angemacht werden. Das ist also nicht der gleiche Sicherheitsstandard, den Ring, Tox, Kontalk und ihre Konkurrenz haben. Das ist sogar schlechter als was Whatsapp behauptet zu tun, Backdoor hin oder her. Für mich ist das ein massiver Kritikpunkt.

Doch insgesamt ist Riot ein ordentlicher Messenger. Bis auf die nicht standardmäßig aktivierte Verschlüsselung gibt es nichts dran auszusetzen. Besonders wenn Gruppen miteinander reden sollen ist es sicher eine gute Wahl. Ich persönlich habe mich inzwischen mit Kontalk und seinen Sprachmemos ziemlich arrangiert, werde Riot aber installiert lassen – es wird für uns vielleicht Skype ersetzen können, das ich ja auch nicht regelmäßig benutze.

Multiprozess-Firefox durch das Electrolysis-Projekt (e10s) ist ein ziemlicher Schritt vorwärts. Bei mir war das bisher nicht aktiviert, weil ich noch Plugins benutze, die nicht explizit als kompatibel markiert sind. Jetzt manuell angemacht ist der Effekt direkt sichtbar. Und er ist stark genug, um eindeutig kein Placebo-Effekt zu sein. Der zusätzliche Prozess beschleunigt den Browser merklich.

Von meinen Plugins scheinen alle kompatibel zu sein, außer einem Plugin namens SmoothWheel, welches das Scrollen weicher machte. Das bewirkte schlicht nichts mehr. Ich bemerkte sonst noch keine Instabilitäten, das kann natürlich noch kommen.

Weil ich solche Plugins benutze, musste ich e10s manuell aktivieren. Wobei das Aktivieren selbst nicht reichte, ich musste zusätzlich die Aktivierung erzwingen. Also in about:config browser.tabs.remote.autostart auf true setzen, und den Eintrag browser.tabs.remote.force-enable als Boolean anlegen und ebenfalls auf true setzen.

Mozilla hat in letzter Zeit für Firefox ein paar fragwürdige Entscheidungen getroffen. Aber Firefox selbst ist immer noch ein guter Browser. Es ist schön zu sehen, wenn er so wie hier (oder wie bei Android) gut verbessert wird.

Der dritte Teil der Shadowrun-Reihe ist der bisher umfangreichste. 35 Stunden habe ich bei Steam verbucht, die reale Spielzeit ist etwas kürzer. Dabei mitgerechnet sind die Inhalte der Extended Edition, die eine Zusatzkampagne nach der Hauptkampagne bietet.

Die Länge allein macht Hongkong weder zu einem anderen noch zu einem besseren Spiel als die Vorgänger, dem kurzen Serienbeginn Returns und dem stark erweiterten Dragonfall. Im Vergleich mit Dragonfall ist die Story etwas weniger interessant, und wie Dragonfall hat es mir zu viele unwichtige Textgespräche zwischen den Missionen. Aber die vielen Detailverbesserungen gegenüber den Vorgängern helfen, Hongkong mindestens so gut wie Dragonfall zu machen. Insbesondere gibt es nochmal mehr Möglichkeiten, Missionen mit den Attributen und in Gesprächen zu lösen. Aber auch die Matrix ist erweitert, Decking dadurch interessanter und für die Missionen sogar noch wichtiger.

Die Story ähnelt den Vorgängern: Eine Figur aus der Vergangenheit ruft den frisch erstellten Charakter zu sich, er habe eine wichtige Mission. Etwas geht schief, das Team wird in den kriminellen Untergrund getrieben. Dort erledigt es Aufträge, während nach und nach die Hauptstory aufgedeckt wird. In der zweiten Kampagne werden dann ein paar übriggebliebene Erzählstränge beendet, wobei die Missionen vom Schwierigkeitsgrad für die stärkeren Charaktere gemacht sind und es nochmal stärkere Waffen gibt. Diese Steigerung macht sie interessant.

Die Grafik hat sich nicht merklich verändert, die Technik war einwandfrei, auch die Unterstützung des freien Radeon-Treibers. Bugs bemerkte ich kaum, nur an etwa drei Stellen kam das Spiel mit meinen Entscheidungen durcheinander. Einmal beispielsweise zeigte sich mein Bruder Duncan traurig über meine Entscheidung, in der Mission zuvor einer Firma zu helfen, wobei ich in Wirklichkeit gegen die Firma entschieden hatte. Die anderen Charaktere hatten das auch richtig widergespiegelt. Das Kampfsystem ist solide, die KI nicht zu dumm, wobei ich geübt durch die beiden Vorgänger in den Kämpfen kaum Probleme hatte. Doch fand ich es wieder schade, in den Missionen nicht alle Begleiter dabeizuhaben. Da mein Hauptcharakter ein Schamane war, erschien es mir z.B. fast nie sinnvoll, den andere Schamanen im Team mitzunehmen. Von ihm bekam ich daher kaum etwas mit. Da war das Attributssystem mit seinen Fähigkeiten eine schönere Konstante, das gefiel mir wieder gut.

Gleiches gilt für das gesamte Spiel: Es ist ein sehr schönes RPG mit Rundenkämpfen, das mir wie seine Vorgänger viel Spaß gemacht hat. Ich hatte gelesen, dass Hongkong deutlich schwächer als Dragonfall sei. Dem war nicht so, eine erfreuliche Überraschung.

Wie sorgt man dafür, dass ein Serverprozess automatisch neugestartet wird? Man hat einen zweiten Prozess, der ihn neustartet, wenn er abstürzt oder wenn der Server neugestartet wird. Ein solcher Prozessmanager ist Supervisor, der unabhängig vom Initsystem läuft.

Mit supervisord kann man auch Ruby/Sinatra-Webanwendungen überwachen, klar. Allerdings gibt es da eine Reihe von Fallstricken, die von rvm und bundler kommen. Ein simples Skript wird weder die Ruby-Version noch bundler laden können, und dann daran Scheitern. Und benutzt die Anwendung Puma als Webserver, startet sie aber mit rackup, scheitert Supervisor am Beenden des Pumaprozesses.

Das Problem an Supervisor ist, dass die Umgebungsvariablen des Nutzers nicht geladen werden. Daher funktioniert dann rvm und bundler nicht. Zum Glück braucht es nur eine: $HOME. Die kann man im Startskript setzen, und dann die Hilfsprogramme laden:

 #!/bin/bash --login

HOME="/home/appuser"

echo "init local ruby environment"
if which ruby >/dev/null && which gem >/dev/null; then
        PATH="$(ruby -rubygems -e 'puts Gem.user_dir')/bin:$PATH"
fi

source /etc/profile.d/rvm.sh

export GEM_HOME=$(ruby -e 'print Gem.user_dir')
PATH="$(ruby -e 'print Gem.user_dir')/bin:$PATH"

echo "starting server"
cd /home/appuser/app
bundle exec puma --environment production -b unix:///tmp/puma.sock

Achte auch darauf, dass in dem Skript die Anwendung über puma und nicht über rackup gestartet wird. Dadurch kann Supervisor den Prozess des Webservers beenden. Ich sah keine Nachteile daran, nur Vorteile, denn Puma kann so auch umfangreich konfiguriert werden. Der hier genutzte Unixsocket zum Beispiel, der dann von Nginx gelesen wird, soll einen kleinen Performancevorteil bieten.

Dies ist die zugehörige Konfigurationsdatei für supervisor, die unter /etc/supervisor/conf.d/ liegt:

[program:webapp]
user = appuser
command = /home/appuser/bin/start_server.sh
autorestart = true
stopasgroup = true

Man könnte die Umgebungsvariable auch hier setzen, siehe das Beispiel in der Dokumentation.

Jetzt sollte alles funktionieren, und die Anwendung mit supervisorctl kontrolliert werden können:

supervisorctl restart webapp

Nicht vergessen, supervisor selbst bei einem Reboot ebenfalls neuzustarten, und dafür den Dienst im Initsystem einzutragen.

Vor etwa einem Jahr entdeckte ich Borg, ein Programm für inkrementelle Offsite-Backups. Der Artikel endete mit:

Bis jetzt bin ich sehr zufrieden damit, und es freut mich sehr, dass diese letzte gravierende Backuplücke endlich gefüllt ist. Nur automatisiert muss das noch werden.

Und klar: Natürlich kam ich nie zum Automatisieren. Ich hatte also Backups, aber hätte bei einem Festplattenausfall trotzdem noch Daten verloren. Auch beispielsweise hier nach den manuellen Backups geschriebene Artikel im Blog. Daran wurde ich jetzt durch den schmerzhaften Datenverlust bei Gitlab wieder erinnert.

Das Automatisieren war schwierig für mich, weil ich es im Kopf nicht richtig aufgedröselt bekam. Das SSH-Passwort zum rsync-Server soll nirgends im Klartext stehen, auch das Passwort für das Backup war mir zu wichtig. Wie also automatisieren? Heute habe ich mir die Zeit genommen das endlich zu lösen, und es ist im Grunde wirklich einfach. Das SSH-Passwort wird durch einen SSH-Key ersetzt, dann kann Borg sich ohne Passworteingabe mit dem rsync.net-Server verbinden. Das Backup-Passwort wird durch ein neues und nur dafür generiertes ersetzt. Dann kann das mit ins Backup-Skript, denn wer das liest hat sowieso schon Zugriff zu allen damit geschützten Daten. Im Detail ging es also so:

1. SSH-Key für Login aktivieren

Rsync hat eine Anleitung dafür, aber bei jedem anderen Borg-Server geht das genauso. Mein Desktop hat schon einen Key, auf dem Server musste noch einer erstellt werden:

ssh-keygen -t rsa

Zuerst schaltete ich meine Hauptmaschine auf dem Server frei:

scp ~/.ssh/id_rsa.pub USER@SERVER:.ssh/authorized_keys 

Ist dort schon ein Key gesetzt muss man den zusätzlichen Key, den des Servers, stattdessen hinten anhängen:

cat ~/.ssh/id_rsa.pub | ssh USER@SERVER 'dd of=.ssh/authorized_keys oflag=append conv=notrunc' 

2. Backup-Passwort setzen

pass generierte ein neues Passwort. Ich ging davon aus, die bestehenden Backups löschen zu müssen, um das Verschlüsselungspasswort ändern zu können. Doch das stimmt nicht, Borg kann das Passwort ersetzen:

borg change-passphrase USER@SERVER:backup_blog

Ansonsten würde das Passwort bei der Initialisierung abgefragt:

borg init --encryption=repokey USER@SERVER:backup_blog

Skript ergänzen und Cronjob erstellen

Das Backup wird durch ein kleines Skript (borg_backup.sh) durchgeführt. Das ist immer noch ziemlich identisch zu dem Quickstart-Beispiel. Jetzt musste es um das Passwort ergänzt werden:

#!/bin/sh
REPOSITORY=USER@SERVER:backup_blog
export BORG_PASSPHRASE='…'

~/borg-env/bin/borg create --stats --compression lzma,2        \
    $REPOSITORY::`hostname`-`date +%Y-%m-%d`    \
    /root                                       \
    /var/www/html                               \
    /etc/apache2                                \

borg prune -v $REPOSITORY --prefix `hostname`- --keep-weekly=2

Edit: Diese Datei sollte natürlich nur für den Backup-Nutzer lesbar sein, am besten Root, siehe Thomas Kommentar.

Dieses Backup sichert übrigens auch die Datenbank, denn die liegt als SQLite-Datei unter /var/www/html/. Mitsamt den restlichen Daten landet sie dank des finalen Puzzlestücks automatisiert und regelmäßig auf dem Backupserver, dem Cronjob:

 # m h  dom mon dow   command
0 2 * * * /root/borg_backup.sh

Und voila, knapp ein Jahr Verdrängung innerhalb weniger Stunden beendet. Wenn ihr noch keine habt, richtet Backups ein. Borg macht es einfach, und das Borg-Angebot von rsync.net ist nicht teuer. Wobei es dafür natürlich Alternativen gibt, beispielsweise tarsnap, siehe die Kommentare im vorigen Beitrag.