The Long Dark Story Mode

Finally, The Long Dark has been released with the long awaited story mode.
Unfortunately since their last pre-release update "Faithful Cartographer", they also introduced a couple of bugs which I first didn't notice (and simply thought were intended changes in their UI). Searching for other players having these issues I found about this posting in the Steam Forums. The solution suggested there didn't work for me because it's rather hard to submit command line options to the game via the GoG scripts. So I tried a different approach and wrote a small script which fixes all the issues that have been described in that Steam Forum posting:

CODE:
#!/bin/bash

GAME_DIR="${HOME}/GOG Games/The Long Dark"
PREF_FILE="${HOME}/.config/unity3d/Hinterland/TheLongDark/prefs"
if [[ -f "${PREF_FILE}" ]] ; then
        sed '/Screenmanager Is Fullscreen mode/s|1|0|' \
                -i "${PREF_FILE}"
fi

cd "${GAME_DIR}" && ./start.sh




Also I used some different commands to find out the game's dependencies on Gentoo Linux and these commands revealed some more needed packages:

CODE:
> find ${HOME}/GOG\ Games/The\ Long\ Dark -type f -print0 | xargs --null --no-run-if-empty scanelf -L -n -q -F '%n #F' | tr , '\n' | xargs --no-run-if-empty readlink -f | uniq | xargs --no-run-if-empty qfile -CSq | sort -u | grep -v "^${HOME}"
dev-libs/glib:2
dev-libs/wayland:0
media-libs/alsa-lib:0
media-libs/libsdl2:0
media-libs/mesa:0
media-libs/openal:0
media-sound/pulseaudio:0
sys-libs/glibc:2.2
sys-libs/zlib:0
x11-libs/gdk-pixbuf:2
x11-libs/gtk+:2
x11-libs/libX11:0
x11-libs/libXScrnSaver:0
x11-libs/libXcursor:0
x11-libs/libXext:0
x11-libs/libXi:0
x11-libs/libXinerama:0
x11-libs/libXrandr:0
x11-libs/libXxf86vm:0
x11-libs/libxkbcommon:0

The Long Dark on Gentoo

Ever since I first saw a letsplay video of The Long Dark back in early 2015, I wanted to play this game myself. Unfortunately at that time the game was only available as early access through Steam. Yet Steam is something that I really don't want to have on any of my computers. I prefer to have fully control over the games I have purchased and Steam simply is a system that prevents users from having full control over their games they purchased through Steam.
Luckily Hinterland Studios offers the game through Good old Games for a while now without steam as requirement and so I just bought the game three days ago.
For Linux systems GoG provides a self extracting (makeself) shell file containing the game. Once being executed, the script fires up a GTK+-2 installation GUI which makes the installation of the game really easy.
Running the game was quite easy, too. The game comes with a start.sh script that takes care of all necessary settings to start the game either on x86 or amd64 systems.
The game can be played with a game controller or with the standard keyboard. I decided for the keyboard as I am used to play 3D games that way.
Performance is quite well on my AMD Radeon R9 285 graphics device although with the graphics details being set to Ultra the game is a bit laggy. This might be a problem of the open source amdgpu driver not using the card's full potential or perhaps the firmware files still need some improvements, I don't know. Time will tell. For now I'm fine with the game being set to "only" High graphics details and I'm now trying to manage not becoming too addicted by this really fine game from Hinterland Studios.
I've tried to get a list of packages the game is using on my system. Here's what I came up so far:
CODE:
:~> for lib in $(ldd ~/GOG\ Games/The\ Long\ Dark/game/tld.x86_64 | awk '{print $1}') ; do qfile -CSq "$(locate "${lib}" | grep 64 | head -n 1)" ; done | sort -u
dev-libs/expat:0
dev-libs/libbsd:0
media-libs/mesa:0
sys-libs/glibc:2.2
x11-libs/libdrm:0
x11-libs/libX11:0
x11-libs/libXau:0
x11-libs/libxcb:0/1.12
x11-libs/libXcursor:0
x11-libs/libXdamage:0
x11-libs/libXdmcp:0
x11-libs/libXext:0
x11-libs/libXfixes:0
x11-libs/libXrandr:0
x11-libs/libXrender:0
x11-libs/libxshmfence:0
x11-libs/libXxf86vm:0

New Laptop or why I will never ever buy an NVidia GPU again

After my old Dell Precision M6500 died a slow death of overheating, I had to replace it and as I had quite a good experience with two Dell Precision notebooks, I wanted a more modern Dell Precision again.
Unfortunately these devices are quite expensive (Dell sells them as mobile workstations, so they are quite powerful), so I only could afford a used device.
My choice fell on a Dell Precison M7600 as these are powerful enough for running Gentoo on them and were in my financial range. While searching the internet for used M6700 devices it became clear quite soon that my only choice were used M6700 with NVidia Quadro GPUs. Although Dell provided M6700 with AMD Fire GPUs as well, it seems most of Dell's Precision notebook customers prefer NVidia GPUs over AMD GPUs and thus I couldn't find an M6700 with AMD GPU that was neither broken nor too expensive.

Since I had very good experience with all ATI/AMD GPUs and the open source radeon/amdgpu drivers in all of my computers, I had the hope that I could achieve similar results with NVidia + nouveau. Oh was I wrong about that...
Perhaps it's the combination of NVidia Quadro K3000M + nouveau + Xorg + KF5 that constantly freezes my system, I don't know it, but having a Desktop that freezes as soon as you have opened a couple of windows is everything but not useful for daily work.
Searching the freedesktop bug database for nouveau issues revealed lots of bugs that had similar reports to what I was suffering from and no indication that these issues might get fixed anytime soon.
The only "fix" for my issue was to disable render acceleration of the Xorg nouveau driver and change the rendering backend in KF5 from opengl to Xrender. Of course that means no opengl, so no nice shiny desktop effects in KF5 as well. Great!
I do not blame the nouveau developers for releasing crappy drivers. These guys did most of the development of this driver by reverse engineering and the very minimal hardware information NVidia provided. I'm honestly thankful for their work and that we have at least some driver that performs better than the former nv driver that perfomed horribly.
But I blame NVidia for still treating free software users as second class people. I don't care how good or advanced their binary blob drivers are. I don't want to use them! I want free software on my system! So I can only join Linus Torvalds and say "fuck you NVidia!", I will never ever buy one of their crappy cards again!
Unfortunately there are still some more drawbacks with my new notebook. Here's a summary of all issues I have:
  • The GPU doesn't work with open source drivers
  • No backlight on the keyboard (but fortunately can be purchased as spare part)
  • The screen's resolution is only 1920x1080 and not 1920x1200 as with my previous two Dell Precision notebooks
  • The battery cannot be removed/inserted while the notebook is operating with AC power because the notebook instantly shuts off

Issues with apache + nghttp2

For quite a while now, apache-2.4 can make use of the http2 (SPDY) protocol via nghttp2 package.
Unfortunately I had quite some trouble getting the protocol to work on my apache webserver and I couldn't figure out what the issue was until I enabled debugging for that module:
${EDITOR} /etc/apache2/modules.d/41_mod_http2.conf

Replace the line
# LogLevel http2:info
with
LogLevel http2:debug
and restart your apache server. Now try to access some site that should be served via HTTP2. After doing so, grep the apache log files for the following string:
grep -Fr "http2:debug" /var/log/apache2
and you should most likely find the problem with your HTTP2 setup.
Don't forget to disable debug logging again or else your log files will quickly become huge.

In my case it was a cipher combination that was not allowed to be used for HTTP2. After disabling the specific cipher, HTTP2 finally worked on my apache.

Replacing evdev with libinput

In Gentoo bug #601132 we want to switch from evdev as primary input driver for X to the shiny new libinput.
For me it turned out to be harder than expected as can be clearly seen in the bug.
Long story short, there's a couple of things users should keep in mind if they switch from evdev to libinput:
  • Remove any XKBRules entries from your xorg configuration files or else you can get very strange (and wrong) key mappings for your keyboard.
  • Packages that have the libinput USE flag shoud have it enabled and the package being re-emerged.
  • Additionally the evdev USE flag should be disabled for the very same packages.