Linux - 23

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.

Gitter ist ein Gruppenchat mit ein paar netten Funktionen, ähnlich wie Slack. IRC ist das von vielen bevorzugte Chatsystem, auf jeden Fall mit Freenode im Bereich freier Software. Für das Portier-Projekt wollten wir beides zugleich nutzen. Also muss der IRC-Chatraum mit dem Gitter-Chatraum synchronisiert werden. Der große Vorteil davon ist, dass man dadurch ein persistentes Log samt Emailbenachrichtigungen bekommt, etwas, was IRC sonst fehlt (und wofür Bouncer eine schlechte Krücke sind).

Matterbridge kann diese Synchronisierung. Dem Namen nach ist es für mattermost gedacht, noch ein anderes Chatsystem, aber es funktioniert davon unabhängig. Dies sind die nötigen Schritte:

Gitter-Bot erstellen

Ein Gitterbot ist ein Nutzeraccount, der über sein Api-Token gesteuert wird. Zuerst muss ein neuer Nutzer auf Github erstellt werden. Der wird dann in Gitter eingeloggt. Um das API-Token zu sehen, muss die App-Seite im Entwicklerbereich aufgerufen werden. Ganz wichtiger letzter Schritt: Der Bot muss manuell dem Channel beitreten, also eingeloggt bleiben, den Channel aufrufen und auf "Join Channel" klicken. Matterbridge funktioniert sonst nicht, ohne Fehlermeldung. Das hat mich Stunden gekostet.

IRC-Bot erstellen

Kleiner Witz. Ein IRC-Bot muss natürlich nicht erstellt werden, schließlich hat IRC kein geschlossenes Nutzersystem. Matterbridge macht das automatisch.

Matterbridge starten

Matterbridge findet sich als Binary auf Github. Ich musste nur die fürs System passende Datei herunterladen und die Konfigurationsdatei conf.toml erstellen. Die sieht so aus:

[IRC]
    [irc.freenode]
    Server="chat.freenode.net:6667"
    Nick="matterbridge"
    RemoteNickFormat="[{PROTOCOL}] <{NICK}> "

[gitter]
    [gitter.portier]
    Token="GITTER-TOKEN"
    RemoteNickFormat="[{PROTOCOL}] <{NICK}> "
    ShowJoinPart=false

[[gateway]]
name="gateway1"
enable=true
    [[gateway.in]]
    account="irc.freenode"
    channel="#channel"

    [[gateway.out]]
    account="irc.freenode"
    channel="#channel"

    [[gateway.in]]
    account="gitter.portier"
    channel="Projekt/Raum"

    [[gateway.out]]
    account="gitter.portier"
    channel="Projekt/Raum"

[general]

Plus=true

Dann fehlte nur noch ein ./matterbridge-linux64 -conf conf.toml. Wobei das natürlich dauerhaft laufen soll, daher erstellte ich auf dem Uberspace einen Eintrag mit den daemontools. Was direkt etwas problematisch war, denn svc -d scheitert daran, die Matterbridge zu beenden. Das musste ich beim Neustarten also selbst machen. In der Praxis muss das aber kein großes Problem sein, solche Software startet man ja nicht oft neu.

Drei verschlüsselnde Messenger im Praxistest, ein Teil meines Versuches, die Datenhygiene zu verbessern.

Versuch 1: Ring

Der erste von mir ausprobierte Messenger war Ring. Ring klingt genial. Es hat Clients für Windows, Mac OS und Linux, sowie für Android. Es ist nicht nur freie Software, sondern gar ein GNU-Projekt. Zwar noch nicht als stabile Version veröffentlicht gibt es immerhin eine zweite Beta, die Grundlagen sollten also da sein.

Und genau das stimmt nicht. Ring funktioniert schlicht gar nicht. Die erste Enttäuschung war der Linux-Client, den ich erst gar nicht installiert bekommen habe, und der wohl auf DBus und Pulseaudio aufsetzt, also auch unbrauchbar wäre. Dann der Android-Client. Der sieht zwar erstmal hübsch aus und ist installierbar, aber einen Kontakt hinzufügen, das klappte nur in einem von zwei Testversuchen reibungslos. Im Problemfall brauchte es viele Versuche und funktionierte erst mit mehrtägiger Verzögerung, dabei waren wir im gleichen Raum. Immerhin funktionierte es. Aber miteinander schreiben, das funktionierte dann wieder nicht immer. Oft genug kamen Nachrichten nicht an, musste Ring neu gestartet werden, damit dann neu gesendete Nachrichten ankommen konnten. Sprachnachrichten oder gar Video, das funktionierte nur kurz oder gar nicht, dann brach die Verbindung weg oder stürzte das Programm ab, oder das Bild blieb schwarz. Störend auch einfachste UX-Fehler, beispielsweise wird beim Schreiben einer Nachricht das Keyboard ausgeklappt, aber danach im Nachrichtenfenster nicht zum Ende zurückgescrollt, während des Chattens müsste man also nach jedem Senden einer Nachricht nach unten scrollen.

Versuch 2: Tox

Der zweite Messenger war Tox. Tox klingt auf der Webseite ebenfalls sehr gut. Normale Anrufe und Videoanrufe werden unterstützt, es sei verschlüsselt, dezentral und frei. Es gibt eine Vielzahl von Linux-Client, was wirklich sehr sympathisch ist, wobei qTox auch unter Windows und OSX funktionieren soll, generell die Multiplattformfähigkeiten von qt ausnutzt. Aber für Android, für Android gibt es nur Antox. Und Antox, darüber hätte ich mir meine Meinung per F-Droid bilden können, das dessen Installation gesperrt hat, weil das Programm zwar kompiliere aber nicht wirklich funktioniere.

Denn genau so ist es. Antox, dann aus dem Play Store installiert, stürzt einfach ab, und das immer wieder. Anruf starten -> Absturz. Miteinander schreiben -> Absturz. Das Chatten stürzt nicht immer ab, die Oberfläche des Programms wirkt sonst auch gut, das Hinzufügen war nicht ganz so problematisch wie bei Ring, wenn auch nicht reibungslos. Aber trotzdem ist es unmöglich, es so als Messenger zu nutzen. Und, was es dann auch als Chatclient kaputtmacht: Ist der Gesprächspartner offline, was scheinbar automatisch passiert wenn Antox eine Weile nicht benutzt wurde, kann man ihm keine Nachricht schicken. Tox ist also auch unbrauchbar, zumindest auf Android.

Versuch 3: Kontalk

Der dritte Versuch lief dann mit Kontalk, und der läuft noch. Ich kann also gleich vorwegnehmen: Das ist eine andere Liga und funktioniert ganz gut. Vielleicht ist das nicht so verwunderlich, denn anstatt das Rad neu zu erfinden nutzt Kontalk XMPP, wohl mit eigenen Erweiterungen. Es ist ebenfalls frei, und es gibt Clients für Android und die drei großen Desktops, per Java. Zusätzlich zu älterer Technik im Hintergrund ist das Projekt in seinen Ansprüchen also wesentlich bescheidener. Mir soll es recht sein, wenn es denn gut funktioniert.

Darüber kann man nun etwas streiten. Das Hinzufügen meines Kontaktes lief problemlos. Die Telefonnummer funktioniert als Identifikator, anonym ist es also nicht, aber immerhin komfortabel. Miteinander schreiben, das funktioniert auch einwandfrei. Allerdings gibt es keine Anruffunktion, der Button dafür ruft den Gesprächspartner schlicht über die Simkarte an. Videoanrufe gibt es dann natürlich auch nicht. Sprachnachrichten können dafür wie eine Chatnachricht gesendet werden, war zwar nett ist, aber trotzdem eine Krücke bleibt. Kontalk ist also ein guter Ersatz für einen einfachen Chatclient, aber kein Ersatz für Skype.

Alternativen

Kontalk funktioniert also, ist aber nicht ideal. Es gäbe ja durchaus noch ein paar Alternativen. Whatsapp verschlüsselt nun standardmäßig, ist aber nicht frei und hat daher mein Vertrauen nicht. Signal klingt super, verlangt aber so viele Rechte auf Android, dass ich denen auch gleich das Telefon samt Passwort per Post zuschicken könnte. Die Empfehlung von Snowden ist zwar mehr als nett, aber dass sie nicht mit einer Version auf F-Droid einhergeht verstört mich. Telegram klingt ebenfalls gut und ist auch frei, aber dessen Verschlüsselung wurde damals heftigst kritisiert. Threema ist nicht kostenlos, aber vor allem nicht frei.

Neben Telegram sind also insbesondere Wire und Riot auf meiner Liste. Die sind in der gleichen Größenordnung wie Ring und Tox, also mögliche Skype-Alternative. Silence als optionaler SMS-Verschlüssler klingt auch nett, das könnte gegebenenfalls eine einfachere Alternative für Kontalk sein.

Wer kennt noch mehr Alternativen, und hat eventuell sogar eigene Erfahrungen?

12 is better than 6 ist ein schneller 2D Top-Down-Shooter. Man spielt einen mexikanischen Revolverhelden, der im Süden der USA gejagt wird. In vielen kurzen Missionen gilt es jeweils, das Ende der Karte zu erreichen und dabei viele Gegner zu besiegen. Das ist gar nicht so einfach, denn sowohl die Gegner, Kugeln als auch die eigene Figur sind sehr schnell, und schon ein voller Treffer tötet. Gleichzeitig müssen Waffen manuell geladen, Revolver sogar nach jedem Schuss gespannt werden. Das erfordert Übung.

Gerade am Anfang ist es hilfreich, dass Gegner auch schleichend mit einem Messer erledigt werden können, das macht manche Karten wesentlich einfacher. Außerdem kann man Dynamit werfen, um mehrere Gegner auf einmal auszuschalten. Später im Spielverlauf gibt es Upgrades zu kaufen, z.B. eine Panzerweste oder mehr Platz für Munition.

Es ist ein mittelmäßiges Spiel. Die Spielmechanik selbst ist spaßig und fordernd, die gezeichnete Grafik originell, die Musik ebenfalls, wenn sie sich auch zu oft wiederholt. Die Story ist dagegen nur ansatzweise motivierend, das Ende sogar richtig schlecht, als sei dem Entwickler die Zeit ausgelaufen. Von den Upgrades hätte es mehr geben können. Am meisten stört mich, dass es für die Zufallsbegegnungen auf der Weltkarte zu wenige, sich daher immer wiederholende Karten mit fester Gegnerpositionierung gibt. Wobei die schlecht geschriebenen Gespräche vielleicht noch störender sind. Dafür läuft das Spiel mit dem freien Radeon-Treiber einwandfrei unter Linux. Die 2€, die es zur Zeit im Sondarangebot auf Steam kostet, ist es daher durchaus wert.

Nachdem durch die Treiberverbesserungen der dritte Teil gut lief, startete ich den vierten in der Erwartung, wieder etwas warten zu müssen. Dem war nicht so. Saints Row 4 läuft mit dem freien Radeon-Treiber noch besser als der dritte Teil und sieht gleichzeitig besser aus. Ein toller Einstieg ins Spiel!

Saints Row 4 ist Saints Row, nur komplett durchgedreht. Ich schrieb über den zweiten, dass es absurd sei, über den dritten, dass es noch absurder sei, und der vierte toppt nochmal alles. Komplett abgehobene Story, die dem Spieler Superfähigkeiten gibt, was eine hervorragende Idee ist, denn als Superheld durch die Stadt zu sprinten oder zu fliegen und Gegner mit Eisbällen einzufrieren oder mit Telekinese Panzer durch die Luft zu werfen macht eine Menge Spaß. Tatsächlich passen im Kontext der absurden Story viele Nebenmissionen viel besser in die Logik des Spiels als bei den Vorgängern.

Nachteil des Ganzen: Vehikel werden unnötig, und die totale Überlegenheit noch krasser. Da kommen dann zwar stärkere Feinde, aber nach ein paar Upgrades können die schnell nicht mehr mithalten. Es spielt sich zwar immer noch toll, ist voller guter Ideen (der Sidescroll-Fighter, die Mass-Effekt-Parodie, Anspielungen auf They Live), die Rollenspielelemente motivieren, die Inszenierung ist klasse und der Ausgang der Story, den wollte ich dann schon sehen. Es hätte bei mir eine sehr gute Bewertung bekommen und ist absolut spielenswert.
Trotzdem reicht es jetzt auch. Das nächste Spiel muss etwas anspruchsvoller sein.

Izulu war übers Wochenende kaputt, es wurden zwar noch die Hintergrundbilder gewechselt, aber das basierte nicht auf dem realen Wetter. Denn der Server, der als Wrapper für die Wetter-API dient, war kaputt. Im Grunde wurde er nur für Wartungsarbeiten neugestartet, aber ich hatte etwas falsch konfiguriert und kam dadurch nicht mehr rein. Leicht ärgerlich.

Den Digitalocean-Droplet habe ich abgeschaltet und lasse den Serverdienst jetzt stattdessen auf dem Server für diesen Blog laufen. Es funktioniert also wieder alles.

Bald nach Saints Row 2 wollte ich den dritten Teil anspielen, aber es war absolut unspielbar. Komplette Diashow. Mich hat das etwas überrascht, denn obwohl schon der zweite Teil auf dem System (Radeon HD 7950) nicht toll lief, hatte ich gelesen, dass der dritte besser optimiert sei. Aber da ging nichts.

Vor ungefähr einem Monat, nach einigen Systemupdates, funktionierte Saints Row 3 dann plötzlich. Es lief nicht toll, aber es war gerade so spielbar – auf minimalen Einstellungen und 1280×720, mit massiven FPS-Schwankungen je nach Geschehen auf dem Bildschirm, nach erneutem Übertakten des Prozessors. Und heute, pünktlich zur finalen Mission, läuft es flüssig. Auf Full-HD und in mittleren Einstellungen. Es ist einfach nur großartig, dabei zuzusehen, wie sich der Linux-Desktop in eine valide Spieleplattform verwandelt.

Der folgende Screenshot ist von heute, der weiter unten schon etwas älter. Ich meine man kann deutlich erkennen, wie viel schlechter die Grafikqualität im zweiten ist. Eine solche Änderung durch einen kleinen Treiberupdate, das ist beeindruckend.

Und Saints Row 3 selbst? Es ist wieder ein gutes Spiel. Ich fand es schwieriger hineinzukommen, und ein paar der Nebenmissionen wieder ätzend. Aber man findet dann doch hinein und dann ist es wie der zweite, nur viel überdrehter und absurder. Mit GTA hat das nicht mehr viel zu tun, und das ist gut so, denn es ist schlicht spaßiger.

Wieder gibt es eine Story, in der mehrere gegnerische Banden bekämpft werden müssen. Die sind direkt mit einem überbösen Syndikat verbündet, später kommt dann noch mit STAG das (Scifi-)Militär hinzu. Die vorherigen Kollegen sind wieder mit dabei, wobei Shaundi ziemlich verändert wurde. Die Missionen gleiten alle ins absurde, wenn eine sich anfangs wie eine normale Mission eines GTA anfühlt, kann man sicher sein, dass drei Sekunden später laserschießende Weltraumtentakelmonster aus der Kanalisation kriechen. Wieder gibt es Upgrades, Waffenupgrades, Kleidung und Tattoos, und der Charakter kann ziemlich angepasst werden. Doch anders als im vorigen Teil – man ahnt es – ist es kein Problem, einen völlig absurden Charakter zu erschaffen, z.B. ein hell-blaues Monster statt eines Menschen. Und dem kann dann noch ein Hotdogkostüm angezogen werden. Oder eine Toilette.

Das war fast zu viel für mich. Nicht immer ist alles witzig oder gelungen, es gibt einige Sequenzen (z.B. das Fallen aus dem Flugzeug), die spielerisch komplett anspruchslos sind. Aber Anspruch ist sowieso nicht das Markenzeichen von Saints Row. Es will absurd und spaßig sein, und kriegt das gut hin. Ich freu mich auf den vierten Teil, den ich im letzten Steam-Sale gekauft habe – mal schauen, ob für den ein weiteres Treiberupdate nötig ist.

Mit bluez5 wurde die direkte Unterstützung für Audiogeräte herausgeschmissen. Stattdessen müsse man Pulseaudio nutzen. Auf meinem Laptop habe ich das sogar gemacht, da dort Ubuntu ohne weitere Modifikationen läuft, aber es funktionierte nicht gut. Auf meinem Hauptsystem läuft einfach nur ALSA, und angesichts der konstanten Problemen mit Pulseaudio wird sich das auch nicht ändern. Und hier springt BlueALSA (vormals bluez-alsa) in die Bresche.

BlueALSA erstellt ein virtuelles PCM-Modul, das für das Bluetooth-Gerät steht. Wird dann dieses als Ausgabegerät gewählt, kommt der Sound aus dem Headset.

Vorbedingung ist, dass die Geräte gepairt sind. Dafür benutzte ich Blueman, alternativ kann man das auch gut in der Konsole mit bluetoothctl machen. Schwierigster Schritt war hier, herauszufinden, wie man das Headset in den richtigen Modus schaltet.

Dann BlueALSA installieren. Bei mir ist es noch als bluez-alsa bezeichnet:

sudo emerge bluez-alsa

Gestartet ist es schnell:

sudo bluealsa

Und direkt danach hat das Abspielen einer Audiodatei funktioniert:

aplay -D bluealsa:HCI=hci0,DEV=XX:XX:XX:XX:XX:XX,PROFILE=a2dp testdatei.wav

Um nur bluealsa angeben zu müssen, kann man die Parameter wie in der Readme erwähnt der ~/.asoundrc hinzufügen:

defaults.bluealsa.interface "hci0"
defaults.bluealsa.device "XX:XX:XX:XX:XX:XX"
defaults.bluealsa.profile "a2dp"

Ist jetzt alles gut? Leider noch nicht. Ich habe Firefox nicht überzeugen können, Sound über BlueALSA abzuspielen. Firefox war immer schon störrisch mit ALSA, hatte z.B. nie eine Möglichkeit, das Ausgabegerät auszuwählen. Auch scheint Mixing, also das unterstützen mehrerer Audioquellen auf einmal, noch zu fehlen. Generell sind wir hier in einem Bereich, in dem die ~/.asoundrc angepasst und eine gute Standardkonfiguration gefunden werden muss, da fehlt noch Dokumentation (wobei dies ein guter Ansatz ist). Aber BlueALSA wird aktiv entwickelt, ich bin zuversichtlich, dass das Projekt eine Lösung finden wird.
Hoffentlich bevor die Katze das Kopfhörerkabel durchgebissen hat.

Wir stellen heute Portier vor. Portier ist freie Infrastruktur für das Web. Es ist ein Loginsystem, das Seiten benutzen können, um Nutzern die Möglichkeit zu geben sich per Email anzumelden. Der Kniff dabei ist, dass die Seite keinerlei Passwort speichern muss.

Das folgende ist einfach zu verstehen, wenn du vorher die Demo ausprobierst.

Portier funktioniert so: Auf der Webseite, in die man sich einloggen will, ist ein Loginformular, das nach der Emailadresse fragt. Der Nutzer gibt seine Adresse ein und schickt das Formular ab. Es wird zu Portier geschickt, dessen Aufgabe dann ist diese Emailadresse zu authentifizieren. Er prüft ob der Nutzer die Emailadresse wirklich kontrolliert. Dafür hat Portier zwei Möglichkeiten:

1. Er kann eine Email mit einem Bestätigungslink zurück zu Portier an die Adresse schicken.
2. Alternativ wird die OpenID-Authentifizierung des Email-Providers genutzt, also bei den meisten Google Sign-In. Das ist komfortabler, da komplett im Browser.

Weiß Portier dann, dass die Emailadresse wirklich dem Nutzer gehört, schickt er an die Seite eine signierte Bestätigung und leitet den Nutzer zurück. Die Seite kann den Nutzer dann einloggen.

Portier und Mozillas Persona

So etwas ähnliches gab es schonmal, es war ein Projekt von Mozilla. Es hieß anfangs Browserid, später war das dann nur noch der Name des verwendeten Protokolls und das Projekt wurde zu Persona umgetauft. Das war hochproblematisch, denn Persona war bereits der Name von diesen Firefox-Themes. Persona hatte noch mehr Probleme: Es war nicht einfach Infrastruktur, sondern sein eigenes Produkt, das Bekanntheit erlangen sollte und das größer war als ein einfacher Email-Bestätiger. Beispielsweise mussten Nutzer sich beim ersten Login auf der Persona-Seite einloggen und dafür ein Passwort wählen, und es konnte nur funktionieren, wenn Nutzer den Persona-Button einordnen konnten. In einem Nutzertest von mir hat keiner der Testpersonen den dafür nötigen Wechsel zwischen Browser, Emailprogramm und Tabs samt anschließendem Zurückwechseln zur Zielseite hinbekommen.

Das alles will Portier besser machen, wobei klar ist: Persona war eine in meinen Augen großartige Idee. Das Portier-Projekt ist ein Versuch, diese Idee weiterleben zu lassen und die Fehler, die Persona gemacht hat, nicht zu wiederholen.

Portier versucht nicht, ein Single-Sign-On-System zu sein, also dass ein Nutzer automatisch auf jeder Portier-nutzenden Seite eingeloggt sind, nur weil er auf einer einzelnen Seite sich mit Portier einloggte. Es gibt schlicht keine zentrale Instanz, in die der Nutzer sich einloggen muss. Es gibt nur den Portier-Broker, der keine Nutzerdaten speichert und von dem es viele verschiedene Installationen geben kann. Wir werden eine Instanz hosten (auf https://broker.portier.io/), aber theoretisch kann jede Seite seinen eigenen Broker haben. Auch praktisch werden wir versuchen das möglichst einfach zu machen – der Code ist überschaubar, das Protokoll möglichst simpel und nutzt mit OpenID existierende Standard, und mit der verwendeten Programmiersprache Rust können Binaries bereitgestellt werden.

Persona wird Ende November abgeschaltet. Es erreichte nicht die Bekanntheit, die Mozilla sich erhofft hatte. Portier eignet sich als Alternative, z.B. mein sinatra-portier-Gem kann direkt sinatra-browserid ersetzen, ohne dass groß der Code angepasst werden muss.

Das Portier-Projekt

Portier ist kein Mozilla-Projekt. Nach der Ankündigung der Abschaltung haben sich einfach ein paar Entwickler zusammengetan, um eine Alternative zu schaffen. Nach einer durchaus langen Planungsphase ist daraus Portier entstanden, das jetzt einsatzbereit wird. Es gibt noch viel zu tun (es gibt eine Roadmap): Arbeit am Broker, Verbessern der Dokumentation auf der Webseite, und generell das Bauen von Modulen für Webframeworks, um die Integration möglichst einfach zu machen. Da können wir Hilfe brauchen. Aber schon jetzt funktioniert Portier und kann allen Webentwicklern helfen, die Persona ersetzen müssen, oder die so etwas wie Persona nur als aktives Projekt haben wollen.

Ich könnte hier fast mein Review von The Incredible Adventures of Van Helsing nochmal schreiben. Victor Vran ist schlicht fast das gleiche Spiel. Auch es ist ein Hack'n Slay angelehnt an Diablo 2, wieder gibt es einen düsteren Held mit Hut und lustige Sprüche aus dem Off – hier durch eine Stimme im Kopf des Protagonisten statt der Begleiterin. Sogar Items und Spielwelt entstammen einer ähnlichen Mischung, nämlich dunkle Fantasie und Technik, also Vampire, Magie und Handfeuerwaffen.

Natürlich gibt es Unterschiede im Detail. Victor Vran kennt nur einen Hub, es gibt keinen kompletten Spielweltwechsel im Verlauf der Story, nur neue Gebiete der Stadt werden freigeschaltet. Es gibt keinen Fertigkeitsbaum, stattdessen mehr Waffenkategorien, die mit verschiedenen Fähigkeiten kommen. Spezialisierung kommt nur durch die ausgewählte Kleidung – mit unterschiedlichen Boni für verschiedene Spielstile – und durch die Schicksalskarten mit ihren passiven Boni ins Spiel. Je nach Kleidung lädt sich automatisch, durch Schaden austeilen, nehmen oder beidem eine Manaleiste auf, mit der dann Dämonenfähigkeiten (=Zauber) benutzt werden können.

Bei den Dämonenfähigkeiten erschienen mir manche klar besser als andere. Es gibt einige, bei denen Victor bei Benutzung ungeschützt stehenbleibt, all diese konnte zumindest ich nie ordentlich in meine Spielweise einbauen. Auch bei den Waffen hatte ich klare Favoriten, aber immerhin erscheint keine Waffenkategorie völlig unnütz, und sie sind samt ihren Fähigkeiten angenehm unterschiedlich.

Insgesamt hat mir The Incredible Adventures of Van Helsing besser gefallen, ich fand es witziger und zumindest im Mittelteil runder. Aber es war damals auch länger her, seit ich das letzte Hack'n Slay gespielt hatte, vielleicht verzerrt das meine Wahrnehmung. Denn Victor Vran hat Vorteile. Es gibt keinen zähen Endpart, kein ärgerliches Recyceln vorheriger Abschnitte. In allen Dungeons gibt es Zusatzherausforderungen, z.B. die Aufgabe, alle versteckten Schätze zu finden oder in den ersten X Sekunden Y-mal einen bestimmten Gegnertypen zu erledigen. Manche dieser Zusatzaufgaben sind ziemlich schwer und es werden später noch schwerere Herausforderungen freigeschaltet, da könnte man viel Zeit reinstecken. Auch der Multiplayer könnte nochmal reizvoll sein. Vor allem aber läuft Victor Vran unter Linux, es lief bei mir mit dem freien Radeontreiber bugfrei und sehr gut.

Wingo ist ein in Go geschriebener Fenstermanager. Github zeigt, dass er vor vier Jahren erstellt wurde, seitdem ist die Entwicklung auch deutlich ruhiger geworden. Allerdings ohne dass der Fenstermanager sonderlich bekannt geworden ist, wobei er immerhin viele Sterne auf Github hat.

Seine Beschreibung macht ihn für mich interessant: Fenstermanager sind nur noch selten aktive Projekte, das von mir genutzte IceWM z.B. scheint verlassen, ist aber eben immer noch vollständig und funktionell. Wingo will ebenfalls vollständig sein, unterstützt Skripting, ist mit Go in einer modernen Sprache geschrieben und wird scheinbar immer noch entwickelt, ohne komplett alpha zu sein. Das sind Eigenschaften, die ich sonst nur bei Tiling-Fenstermanagern sehen, die ich als nicht sehr benutzerfreundlich empfinde.

Wingo lag nicht in den Quellen und ich fand kein Overlay, also habe ich wie in der Anleitung beschrieben über Go installiert:

go get github.com/BurntSushi/wingo
go get github.com/BurntSushi/wingo/wingo-cmd # optional

Danach die Konfiguration schreiben lassen:

wingo --write-config

In der ~/.config/wingo/theme.wini musste ich direkt die Pfade zur Schriftart anpassen, denn /usr/share/fonts/TTF/ existiert auf meinem System nicht. Danach die ~/.xinitrc angepasst, IceWM beendet und mit startx Wingo gestartet.

Es begrüßte mich ein gesprochenes "Wiiingo!"und ein schwarzer Bildschirm. Ich finde das ja immer ziemlich unglücklich, wenn Fenstermanager nicht auf irgendeinem Weg ein Menü bereitstellen (rechte Maustaste z.B.), sondern sich darauf verlassen, dass der Nutzer die richtige Tastaturkombination finden wird. "Win + T" startete schließlich ein Terminal, mit dem ich anderen Programme starten konnte.

Und ja, viel weiter bin ich noch nicht. Ich konnte bereits sehen, dass Fenster ebenfalls kein Menü haben, dass ich eine Menge Tastenkürzel anpassen müsste, dass Simdock sich nicht ordentlich als Dock registrieren konnte, und der Mauszeiger auf dem Desktop ist ein hässliches X. Die Platzierung neu geöffneter xterms war nicht sonderlich intelligent, überlappend. Konfiguration und Skripting kann das alles noch rausreißen, aber bis jetzt macht Wingo auf mich nicht den Eindruck, besser als IceWM zu sein – und vollständig wirkt es definitiv nicht. Aber das kann täuschen.

Mercenary Kings ist ein 2D-Shooter. Seit ich vor ein paar Jahren GunGirl 2 durchgespielt habe mag ich solche Plattformer eigentlich. Und es war eine neue Gelegenheit xboxdrv auszutesten. Mercenary Kings aber ist durchwachsen.

Es ist eigentlich nett gemacht. Von einer Basis aus wählt man Missionen aus, die dann innerhalb eines Zeitlimits erledigt werden müssen. In der Basis können mit gesammelten Rohstoffen neue Waffen gekauft werden, deren einzelne Bestandteile man selbst zusammenstellen kann. Es gibt eine Hintergrundgeschichte, mittels derer Schritt für Schritt neue Spielelemente freigeschaltet werden. Das eigentliche Spielen in den Missionen macht auch Spaß.

Aber es läuft nicht stabil. Alle paar Level muss ich es neustarten, weil Leitern wieder nicht mehr benutzt werden können. Und jetzt speichert es Fortschritte nicht mehr – Upgrades und gesammelte Rohstoffe bleiben erhalten, aber gechaffte Level werden nicht mehr als solche markiert. Außerdem stört mich, dass immer wieder alte Level neu gespielt werden müssen. Da wird die gleiche Karte geladen, nur dass diesmal 20 Holzstücke gesammelt werden müssen anstatt den Endgegner zu besiegen. Das ist nur mäßig spannende Spielzeitstreckung.

Durchaus schade, denn im Kern ist es ein gutes Spiel, das mit etwas Fokus auch insgeamt gut hätte sein können.

Wie großartig: der Linux-Port vom neuen Deus Ex wurde bestätigt. Ich schrieb zur Preview noch, dass ich mich auf das Spiel freuen würde wenn es auf Linux liefe. Jetzt darf ich mich drauf freuen.

Wobei ich nicht sicher sein darf, dass es auf meiner Hardware laufen wird. Unter Windows hätte das noch gepasst, wenn auch nur mit 30 FPS. Das ist für die Linuxversion kein gutes Vorzeichen, brauchen diese doch öfter bessere Hardware.