So far I like what Valve has been doing with Steam on Linux. Obviously there’s always a lot to be improved, but they try and it works pretty well for me.
Since they don’t have a native 64 bit steam client yet and I don’t want to clobber my Slackware64 install with multilibs and other 32 bit garbage I still have my old 32 bit Slackware-current install mounted that I can chroot into and run 32 bit garbage.
Running steam for me looks a bit like:
root@steammachine:~# su benv
<gibberish after which steam pops up>
A bit of a hassle but it works, and I need that 32 bit chroot for running windows garbage in wine32 anyway.
Lately I noticed a lot of games that have a linux version under Steam crashed. When running them a window pops up, disappears, and your last played date is set to “Today” in steam. Trying to run the game on the console shows something like this:
Set current directory to /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew
Found path: /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew.x86
Mono path = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Managed'
Mono path = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono'
Mono config path = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono/etc'
Aborted (core dumped)
The reason was simple, but took me a lot of digging through strace etc to figure out. (gdb didn’t help since the included libmono that caused this segmentation fault was obviously stripped). At some point the program tries to read from /sys/devices/, which failed since I hadn’t bothered to mount /sys in my chroot. My mistake. (note that I did bother to mount /dev to get gamepad support etc).
[pid 16978] openat(AT_FDCWD, "/sys/devices/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Conclusion: make sure that Steam for Linux games have access to /sys/devices/ 😉
Some days shit is just weird. Like this morning.
Somehow my mutt managed to get disconnected from our mailserver, so I restarted it. Mutt goes “Hej, good morning, how about I connect to your mailserver, one moment please”.
“Sure sure”, I think, not really paying attention. After a while it still said “Loggin in…” though. Huh, why is this taking forever?
After checking strace and seeing it wait on a read(3, …) call I figured maybe the connection was somehow weird. However, after killing and restarting mutt a few times (since that always works, right? :-p) it still got stuck on “Logging in…”.
Obviously the first thing I should have done was think “What changed since it last worked properly?”, but I didn’t and went ahead to check out all the logs and other junk on my mailserver. It had one positive (I think) effect: I upgrade my Dovecot from 2.1.6 to 2.1.15 😉
Other than that everything worked great on my mailserver. (Which a working webmail and no complaints from clients confirmed)
Long story short: It’s not the mailserver, dummy.
What changed since yesterday when everything was still great?
Slackware had an upgrade for libopenssl to version 1.0.1d, to fix some security issues. Apparently it introduced a new bug. Bugger.
Meanwhile they fixed that library again, so now we’re at version 1.0.1e. Guess what.
After upgrading to 1.0.1e Mutt magically works again 😉
Moral of the story:
Don’t touch OpenSSL if you don’t have to. This thing causes more headaches than brain cancer.
Yay a new Xen version. Well, it’s not that new, but I’m upgrading to it today. And while we’re at it, Jeremy got his pvops kernel almost to version 3.1.0 (it’s at rc9 today, good enough for me atm).
So what’s new in this latest Xen version? First of all it has finally ditched the xm command for good. Well, it’s still there, but it’s really deprecated now because it has been replaced by xl. For a nice overview of what has been improved since Xen 4.0, they have a nice list over here.
One cool thing in the later Xen releases (that is: 4.0 and up) is the integration of Remus. We’ll test that out later. (continue reading…)
Some days after tinkering for a little bit you come to the realization that it might be better to stop doing anything with devices and just wait for the day to pass, because everything you touch breaks in the most spectacular ways. Of course this never stopped me from breaking even more, but I’m stupid like that.
Today is a day like that it seems. First our ADSL line at home received an upgrade to FTTH (aka a fiber connection), boosting our internet speed from a lousy 8Mbit down to 50Mbit down, and from less than 1Mbit upstream to 50Mbit upstream. (continue reading…)
Another round of updates came along on Slackware64-current and since I was playing around with ffmpeg I figured I might as well update that. Since ffmpeg is one of those products that has a bunch of really active developers it gets updated about every 5 seconds.
This means that whenever they release a new version it’s instantly obsolete. However, that also means that when you’re trying to run the latest version from git, you’ll often run into software that uses the older functions/symbols/garbage and therefore won’t compile. (continue reading…)
So I still run Slackware Linux on pretty much all of my machines, which I often smile upon when I see another Ubuntu/Debian/Pokemon update break stuff (that I then get to fix, details). However, running bleeding edge Slackware-current also draws some blood every now and then. (continue reading…)
Hej look! A new WordPress release…. 3.4…. and it automagically updates, nice going guys 🙂
What’s new? A bunch of stuff I don’t care about, a few more rounded corners … meh.
And apparently they’re green. Oh well. I can be green too, see? 😉
Back to stuff I do care about: Check MK released a new major version a few days ago – it’s now on version 1.2p1.
Among the new stuff some shiny interface updates (you know, rounded corners and the like), a ton of fixes and new agents/checks (postgresql is among them), a Logwatch Pattern Analyzer and tons more.
Last week we bought a new toy — a Canon EOS 600D (including a lens with about the same pricetag). So far I’m happy with it, it’s nice to play with a ‘real’ camera for a change. (our previous one is a simple Samsung TL205. Apples and oranges.) (continue reading…)
Earlier I reported on my first World of Warcraft under 64 bits wine experience. It somewhat worked but couldn’t play the game because it got stuck on the loading screen.
Just now I decided to give it another shot and pulled the latest wine from git. Currently we’re on wine version 1.4-rc4. Before building that I upgraded my NVIDIA driver to their latest as well, 295.20.
After compiling and installing the new wine release candidate the results are in:
So it seems like the guys working on Wine did some good work!
Loading the initial screen is still a bit slower than the 32 bit version, but apart from the it seems good. Haven’t tried any dungeons yet, so I have no reports on ingame performance, but I might complain on that later if it sucks 🙂
If not I have another reason to move my old 32 bits slackware partition to the shredder.