Visited the abandoned silver/copper/barite mine in Hallwangen, 72280 Germany. It’s a rather interesting one as it dates back to #medieval times and is still excavated by voluntary workers. The earliest record found dates back to 12C and the upper mining gallery “Himmlisch Heer” shows markings that are the result of hand tools while the second gallery “Irmgardsglück” has holes for explosives drilled with machines powered by compressed air. That part also has wider tunnels while the upper part is mostly crawl spaces.
The mine was abandoned and reopened several times for different reasons. The last activity was in 1912 and some stuff like an old rail for push carts and parts of electric installations can still be seen to this day.
I liked especially that we were allowed to walk through the mine at our own pace. I remember a visit to another mine where we were ushered along so fast that the children had trouble keeping up. Not so in this case. Our guide was very friendly and described everything in an exciting way so the children would even pay attention 😀
Speaking of, the guide noticed my interest in the medieval part of the mine and recommended me the De Re Metallica (yes, like the band 🤘) by Georg Agricola, which is apparently a treasure drove on historic mining operations (and myths) and lucky me: A translation in English is available on Project Gutenberg (as well as the original Latin text) – figures included.
I can totally recommend a tour. We got to see a lot of interesting stuff packaged with fascinating stories and explanations. Been to some mines in my life already but seldom did I get to see so many details in such tiny tunnels. Granted, most mines were rather modern and huge drilled exclusively with modern machines.
If you visit don’t forget to greet the tunnel at the entrance with the classic “Glück auf!” shout of the local miners for safe passage and fortune.
How it’s done? NMS does support a gamepad but it also reads/maps all gamepads to a single device. It makes no difference between multiple gamepads!
This leaves me with a very limited amount of possible buttons on the HOTAS after mapping that to one virtual gamepad using MoltenGamepad (I usually split that one up into multiple gamepads for braindead games).
So for additional buttons I used AntiMicroX to map the rest as keyboard presses.
Doing so I noticed that NMS does “look-around” on the right stick and this is where OpenTrack comes into the play. It offers a joystick output (using evdev) and that is also just… a gamepad! Needs some remapping though to get pitch and jaw to the proper axis for NMS. This is done via SDL env (basically what Steam does under the hood but boy their GUI for that sucks): SDL_GAMECONTROLLERCONFIG="000022e86f70656e747261636b206800,opentrack-to-nms,rightx:a3,righty:a4,platform:Linux,crc:e822,"
And there you have it. NMS with my trusty old X52 Pro and a DIY headtracker for 5 bucks 🤓
PS: I’m aware that the recording quality sucks. This was very spontaneous with a webcam sitting on my chair. I basically just finished my happy dance that this started working properly and decided to smash that recording button. PC was not even in “gamemode”.
Originally I was going to replace a disk on my hardware controlled RAID 5. That didn’t work out well. The controller supports hot-plugging but the LED indicator stayed on faulty. To debug this I had to boot into the controller to check for the error message and lo and behold it appears my spare has an invalid block size and the controller is too dumb to format it with another, unlike e.g. sg_format.
And this should have been the end of the story until I can reformat this on another SAS capable PC. Alas grub rescue greeted me on reboot with “error: disk `lvmid/foo/bar` not found.“
and I could not persuade it to boot the LVM member. The thing is that this disk is NOT under control of the hardware RAID controller. It’s plain SATA and it’s boot order is before the RAID controller so I really did not expect any trouble here.
Turns out I was running into this rare bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987008 where the words “time-bomb” and “critical” are dropped. The gist is that grub has a bug that prevents it from reading LVM meta data sometimes and this results in a broken bootloader.
This is not fixed with the usual reinstall dance from another boot-able medium. The trick is to manipulate the LVM meta data in some way, e.g. by adding another volume temporary.
This means running a vgscan after booting from another medium and *in my case executing* e.g. lvcreate -L 4M pve -n foo
The name doesn’t matter as it can be removed afterwards. Updating the initramfs should run without errors now and is a good indicator if this worked. Now it’s possible to reboot again.
The two problems have basically nothing to do with each other. It was just my lucky day to run into this sequence of chained issues during my free Saturday night 😩
Oh yeah, meanwhile the RAID recovered also. Another spare was added until I have time to take a closer look at the block size issue.
Wir landen immer mal wieder mit unserem Mailserver bei der #Telekom im Filter:
> refused to talk to me: 554 IP=$mailserverIP - None/bad reputation. Ask your postmaster for help or to contact tobr (at) rx.t-online.de for reset. (NOWL)
Darunter leidet vor allem mein Vater, der sich regelmäßig per Mail mit seiner Peer Group austauscht.
Beim letzten mal haben die ein Impressum gefordert, was ich lapidar mit WHOIS und der Rückfrage nach welcher RFC das bitte sein soll gekontert habe. “Ja, da kann ja jeder kommen”. Newsflash: Das ist der ganze Witz bei Mail. SPF, DKIM, rDNS… ist denen alles egal.
Jedenfalls ist hier der “Musterbrief”, mit dem er uns diesmal “freigekauft” hat, nachdem ich selbst einfach keinen Nerv hatte mich damit auseinander zu setzen und nur auf frühere Rants verwiesen habe:
Guten Tag. Meine Mails werden nicht weiter geleitet an den Empfänger. Dazu gibt es keinen Grund.
Dieses Problem hatten wir hier schon öfter und es sollte eigentlich nicht vor kommen.
Beim letzten mal haben Sie uns glaub auf ne Whitelist gesetzt.
Wir sind nur auf eine andere IP umgezogen. Der Mailserver ist der gleiche und früher ging das auch.
Das ist ein privater Server.
Wenn der Server wirklich Müll macht, und z.b. Spam verschickt, sollen die bitte entsprechende Beweise beilegen.
Mail _ist_ dezentral, wir erfüllen alle technischen Anforderungen die State Of The Art sind.
Einfach Blocken weil man die IP nicht kennt und den Anrufer abweisen weil er nicht im eigenen Telefonbuch steht. So funktioniert das Prinzip Mail nicht!
Als Beispiel hier eine abgewiesene Sendung, daraus ist ja für Sie alles ersichtlich: […]
Gleiche Mails über z.B. GMX laufen ohne Beanstandung.
Es wäre besser wenn wieder mehr Menschen ihre eigenen Mailserver betreiben würden und diese Kommunikationsmöglichkeit nicht in dritte Hände geben würden. Das ist auch wirklich nicht mehr so schwer wie vor 20 Jahren, als so was noch als Königsdisziplin galt. Das kann heute jede NAS nebenher erledigen.
Did some space pew pew like it’s 1999. This is X: Beyond The Frontier. One of the very first space games using a “so called” 3D card. Haha, those crazy peeps at Egosoft updated it in 2021 to make it compatible with Win11 which means it’s basically running on Linux PC out of the box as well. Mapped my joystick and dived into it once more. Doubt I’ll play it much but that was a nice excursion down memory lane
I still have the original CD-Rom but when I noticed that it’s on a Steam sale for -,99ct I didn’t even bother to look for a CD reader. What a surprise that this runs at all.
I also have some short video footage. I’ll never forget that glorious intro. “Here is how the ship navigates… and action. Bam. Here are 1000Cr, the most basic shield and no weapons. Go! Trade! ‘Maps’? ‘Earth’? What’s that? Oh and you have to pay those Cr back. With interest.”
I hacked a mod for X4: Foundations to get ship telemetry and targeting data to my “Primary Buffer Panel” via a socket. This is a demonstration of my simulated cockpit made from cardboard on a budget usually used to play Elite Dangerous now also used for X4: Foundations. This is work in progress.
My DIY cockpit for X4: Foundations (on Linux PC)
A Linux PC
A DIY Headtracker
A DIY Joystick (My Primary Buffer Panel)
A X52 Pro HOTAS
An AMD RX6700XT
…a lot of plumbing in Node-Red xD
This is loosely based on the Python Pipe Server mod for X4 that is sadly Windows only using Named Pipes. I fixed that for Linux PC by side-loading the library LuaSocket and starting a socket server directly in X4. That’s right, the Python Server is simply not needed now and companion tools may directly connect to the socket. It’s a nice bonus that LuaSocket also allows a UDP or TCP server depending on how it is started. That was some piece of work though and I’m still wrapping things up to publish my code changes. I’m also still looking for testers so if you’re interested get in touch!
Here are the humble beginnings of a working example to read the ship status of #x4foundations in a format very similar to the Status File of #EliteDangerous
Both games are quite similar and by using a “well established” format it should be possible to use this with existing companion apps – like my own #SimPit
It uses the “Named Pipe API” of “sn_mod_support_apis” – on #Linux PC 😁 This was not supported by this MOD so far but I made it work.
Well, at least on my machine 🤓
And yes, the pipe server works with some minor adjustments for other _existing_ apps as well. Here is a demo of #X4ExternalApp with a data feed directly from X4: Foundations – it does not use the #X4PythonPipeServer though, since that is not really needed, so I had to make some small adjustments in it’s connection routine but that was like 2 lines of code 🤷
This is heavily distilled early gameplay of X4: Foundations, where I started another play-through slowly expanding my little empire with trade, side missions, station building, border patrol (loosing the the “Misfit”, my good old starter-ship), a surprise Xenon attack on a station where I was just for shopping and eventually good old fashioned piracy with unexpected guest appearance of some Kha’ak trying to crash the party.
01:11 Setting up trade routes aboard The Law Abiding Windrunner 02:20 Switching over to the Misfit 03:05 Witnessing the death of a trading station (while escorting my own ships to safety) 03:50 Patrolling for money (and looting stuff) 05:48 Repairing satellites (in EVA suit) 07:32 Docking at the impressive Teladi ring station for shopping 08:45 Surprise attack on the ring station by a Xenon K (and it’s demise) 14:32 Extending my own station and buying more mining ships 11:26 Switching over to my frigate for border patrol (lots of pew pew) 14:30 Loosing the Misfit to Kha’ak (and avenging it) 16:07 Going for resupplies and preparing for piracy 16:39 Ambushing the prey, a fat water freighter looking for a new owner 17:59 Starting the boarding operation 18:40 Realizing I need more support to deal with surprises 18:58 Stumbling over mentioned surprises, Kha’ak trying to crash the party 19:51 Sending more boarders as the first group fails 20:22 Finally going home with the price, a “slightly banged up” L water freighter
I’m wondering how to present ultra wide screenshots for a while now, because most people will not have an ultra wide display at hand or not run their browser in fullscreen on such a device. A scaled down version with retained ratio also just don’t really cut it:
Now what if we could wrap this in some sort of 360° image? This isn’t really 360°, of course but you get the idea. A quick search usually yields JS libs like Pannellum (https://pannellum.org/), which look great for this use-case as well and yes we could also solve this in CSS by using an animation and go for a little camera ride.
What if we could optionally also make use of a gyroscope though? You know, that sensor every mobile phone, tablet and VR device comes along with. So the user could device where to look just by moving the device around?
This was when I stumbled over A-Frame (https://aframe.io), which is basically a library for building 3D AR or VR experiences and while I may only scratching it’s surface with my quick tests here it does deliver exactly what I was looking for.
I built demos for various games today and I don’t know how long I’ll host the files here but they all follow the very same code pattern that I’ll add in the end:
Please be aware that I’m loading a ~5mb blob of JS code directly from A-Frame in the demos so don’t check them out if that is a problem for you. The image asset adds another whopping MB so please be patient. The best experience is on a mobile phone where you should be able to look around by moving the phone left and right. It works on a desktop browser too where the mouse can be used to look around.
Feel free to copy this snippet and play around with it. Just keep in mind that you have to use _local_ assets too or they won’t show up. Make sure to read the documentation too and play with the built in inspector opened with the key combination ctrl + alt + i.
And yes I’ll happily take a CSS only variant too but I really doubt that’s possible without loosing features like gyroscope data usage.
I didn’t use my Steam Link for some time and was kinda surprised by the new UI in Big Picture Mode. And also very unhappy because it was a stutter feast with buffer artefacts all over the place. Once I could get a game running it was butter though so something was up with the streaming mode of the UI. I’ve no really an idea what’s going on there but this was always a problematic thing with my AMD GPU under Gnome using Wayland when it comes to streaming and remote play. I ticked off the basics and disabled the blocklist for unknown GPUs, made sure that AMD hardware acceleration was enabled for the host in the Big Picture setting and even tried to launch it with the old big picture mode but no dice:
steam pipewire -pipewire-dmabuf -oldbigpicture
After reading around a lot on the bugtracker at https://github.com/ValveSoftware I eventually learned that the hardware acceleration for remote play is usually done with VAAPI and that there is debug information in ~/.local/share/Steam/logs/streaming_log.txt and sure enough here it was:
ffmpeg verbose: libva: VA-API version 1.16.0
ffmpeg verbose: libva: User environment variable requested driver 'radeonsi'
ffmpeg verbose: libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: Found init function __vaDriverInit_1_16
ffmpeg verbose: libva: va_openDriver() returns 0
ffmpeg verbose: Initialised VAAPI connection: version 1.16
ffmpeg verbose: VAAPI driver: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64).
ffmpeg verbose: Driver not found in known nonstandard list, using standard behaviour.
ffmpeg verbose: Input surface format is nv12.
ffmpeg verbose: Compatible profile VAProfileH264Main (6) is not supported by driver.
ffmpeg error: No usable encoding profile found.
So the profile was missing and a check with vainfo confirmed this:
This was the moment when my brain did pull off one of it’s tricks and remembered me about the story about Fedora _disabling_ hardware acceleration for H264 due to proprietary concerns some months ago and yes I did recently upgrade to Fedora 37 🤯
Thankfully the community stepped in already and fixed mesa drivers are only one dnf install away on rpmfusion, so there is no need to recompile this with h264 support (and some others) manually. There is a caveat though because the swap command would happily delete the needed 32bit versions for Steam and only install the 64bit version of the swapped package. Keeping this in mind the required commands are basically this (and if this breaks your system I do not want to hear about it – use your brain!):