Four tonnes of firewood arrived on Friday afternoon. It took my family of four a little over five hours to carry it to the storage shed. I had a reference because my autism demanded stimulation.

The shed has about 3.5 x 6 x 1.5 metres of usable volume. That amount of firewood lasts us the entire heating season with a bit left over.

(edit: replaced photo with a smaller one)

I'm watching Mandy's old RING 2 stream VODs (because I like watching grown men fail at slide puzzles, don't judge) and he lost it when the Lowry chat started posting gifs and photoshops of Morrow. I know that every single Lowry post is an incomprehensible rabbit hole of in-jokes and references, but I have nothing on Mr. Morrow other than the one appearance in his SOMA video. What context am I missing?

@who@feddit.org pointed me to the solution. Since XInput is implemented using SDL2, it can be told to selectively ignore devices by setting the SDL_GAMECONTROLLER_IGNORE_DEVICES environment variable. The value should be a hexadecimal VID/PID pair separated by /, or a comma-separated list of VID/PID pairs for multiple devices.

For the 2026 Steam Controller:

SDL_GAMECONTROLLER_IGNORE_DEVICES='0x28de/0x1304'

For other devices using a USB cable or dongle, the VID/PIDs can be listed using this command:

lsusb | sed -E 's/.*: ID ([a-z0-9]{4}):([a-z0-9]{4})/0x\1\/0x\2/'

cross-posted from: https://lemmy.world/post/47349151

There are some non-Steam games that I can't run through Steam because of its sandboxing (bubblewrap, Steam Linux Runtime, pressure-vessel and such). For those, I've set up SISR to capture the SC's input and remap it to a virtual controller.

While SISR itself works (and quite well with both the touchpads and the gyro), the game ends up receiving inputs from both the virtual and the physical controllers simultaneously.

Running wine control joy.cpl shows both the real SC and the virtual Xbox 360 controllers as DirectInput devices. The XInput list is empty, but the XInput tab shows that it receives input events from both the SC and the virtual controller. Disabling hidraw or the individual DInput devices has no effect.

I'd like to find a way to either hide the device from Wine's XInput driver, or to prevent the XInput device (within Wine) from sending input events to the game. So far, no luck. Any help would be appreciated.

@who@feddit.org pointed me to the solution. Since XInput is implemented using SDL2, it can be told to selectively ignore devices by setting the SDL_GAMECONTROLLER_IGNORE_DEVICES environment variable. The value should be a hexadecimal VID/PID pair separated by /, or a comma-separated list of VID/PID pairs for multiple devices.

For the 2026 Steam Controller:

SDL_GAMECONTROLLER_IGNORE_DEVICES='0x28de/0x1304'

For other devices using a USB cable or dongle, the VID/PIDs can be listed using this command:

lsusb | sed -E 's/.*: ID ([a-z0-9]{4}):([a-z0-9]{4})/0x\1\/0x\2/'

There are some non-Steam games that I can't run through Steam because of its sandboxing (bubblewrap, Steam Linux Runtime, pressure-vessel and such). For those, I've set up SISR to capture the SC's input and remap it to a virtual controller.

While SISR itself works (and quite well with both the touchpads and the gyro), the game ends up receiving inputs from both the virtual and the physical controllers simultaneously.

Running wine control joy.cpl shows both the real SC and the virtual Xbox 360 controllers as DirectInput devices. The XInput list is empty, but the XInput tab shows that it receives input events from both the SC and the virtual controller. Disabling hidraw or the individual DInput devices has no effect.

I'd like to find a way to either hide the device from Wine's XInput driver, or to prevent the XInput device (within Wine) from sending input events to the game. So far, no luck. Any help would be appreciated.

I started playing in version 0.9.0j and the number of hardware failures made it feel like the whole infrastructure was held together by chewing gum and prayers. I had one or two things to fix every day, which was a great source of tension because I was always under the threat of having to stay out in the dark to keep the place operational.

A few days ago I updated to 0.9.0n and (by entirely my fault) had to start a new save. It's been six in-game days and not a single fault occured (other than scripted events). No server faults at base or any radio dishes, not one blown fuse on the coordinate radars. I can comfortably get my dailies done before noon and collect signals and clean the base all day.

Did anyone else experience this? Was this an intentional change? Or did I just have shit luck on my first save?

The controller is un-bricked! All thanks to this user: https://redlib.catsarch.com/r/SteamController/comments/1tc3ua9/arrived_today_wont_connect_update_failed_bricked/

Symptoms:

• The firmware update failed.
• Turning on the controller causes the LED to flash red.
• The device takes charge from both the Puck and USB.
• Can't connect wirelessly to the Puck.
• When connected using a USB cable, the device shows up as "Valve Software Steam Controller Bootloader" in lsusb's output.

How to fix:

1. Start Steam in developer mode by using the -dev argument.

2. Open Settings -> Developer

3. Under Hardware Updates, press the Update all devices now button.

Steam will go through the usual firmware update steps and flashes all connected devices. This failed for me one more time, then worked fine once I switched to a proper USB C-to-C cable.

4. You might need to flash the Puck too, then pair it with the controller.

Original post:

The controller worked fine until I started Steam. It showed the firmware update popup, I did as instructed, the puck was updated fine, but the controller failed. Now the LED flashes red when I turn it on, it doesn't react to button inputs, doesn't connect wirelessly, isn't recognised as a controller when connected through USB, and shows up only as "Valve Software Steam Controller Bootloader".

I think it's reasonable to assume that the firmware is cooked. Naturally I'm opening a support ticket with Valve, but I'm wondering if anyone has any idea on how to resolve it without waiting, potentially for months, for a replacement.

I recently decided to rebuild my homelab after a nasty double hard drive failure (no important files were lost, thanks to ddrescue). The new setup uses one SSD as the PVE root drive, and two Ironwolf HDDs in a RAID 1 MD array (which I'll probably expand to RAID 5 in the near future).

Previously the storage array had a simple ext4 filesystem mounted to /mnt/storage, which was then bind-mounted to LXC containers running my services. It worked well enough, but figuring out permissions between the host, the container, and potentially nested containers was a bit of a challenge. Now I'm using brand new hard drives and I want to do the first steps right.

The host is an old PC living a new life: i3-4160 with 8 GB DDR3 non-ECC memory.

• Option 1 would be to do what I did before: format the array as an ext4 volume, mount on the host, and bind mount to the containers. I don't use VMs much because the system is memory constrained, but if I did, I'd probably have to use NFS or something similar to give the VMs access to the disk.

• Option 2 is to create an LVM volume group on the RAID array, then use Proxmox to manage LVs. This would be my preferred option from an administration perspective since privileges would become a non-issue and I could mount the LVs directly to VMs, but I have some concerns:

  • If the host were to break irrecoverably, is it possible to open LVs created by Proxmox on a different system? If I need to back up some LVM config files to make that happen, which files are those? I've tried following several guides to mount the LVs, but never been successful.
  • I'm planning to put things on the server that will grow over time, like game installers, media files, and Git LFS storage. Is it better to use thinpools or should I just allocate some appropriately huge LVs to those services?

• Option 3 is to forget mdadm and use Proxmox's ZFS to set up redundancy. My main concern here, in addition to everything in option 2, is that ZFS needs a lot of memory for caching. Right now I can dedicate 4 GB to it, which is less than the recommendation -- is it responsible to run a ZFS pool with that?

My primary objective is data resilience above all. Obviously nothing can replace a good backup solution, but that's not something I can afford at the moment. I want to be able to reassemble and mount the array on a different system if the server falls to pieces. Option 1 seems the most conducive for that (I've had to do it once), but if LVM on RAID or ZFS can offer the same resilience without any major drawbacks (like difficulty mounting LVs or other issues I might encounter)... I'd like to know what others use or recommend.

"Is this the one?"
"Yeah, that's the one."
Yank!

As the last of the servers died with a pathetic beep, I think I heard the poor electrician, still holding the unlabeled end of the rack's power line, invoke the name of Jesus.

(Obviously dramatized, but mostly accurate.)

The virtualization servers came back online with some fuss, but they at least look functional. My tasks for the day are set: wade through about 400 error messages, verify the functionality and integrity of 117 virtual machines, restore backups as needed, and verify the SMART status on every physical hard drive.

(edit 1) High Availability tried to migrate all of one host's VMs to the other, but it isn't worth much if both HA hosts are on the same circuit and die within seconds of each other. Now all but a few VMs are running on a single host.

(edit 2) Some of the PhDs are angry because their long-running ML projects got interrupted. They didn't set up checkpoints or live backups, so entirely their fault.

(edit 3) Five hours later, only one VM needed manual intervention (apart from migrating the VMs back to their original hosts), and all the hard drives are in good condition for their age. This turned out to be a really boring disaster.

I mean all the unnatural, wireframe-like features. It's a fascinating design and I was hoping that some quests would elaborate on the lore of how that area came to be like that. I'm caught up on the archon quests and have just finished Nightingale's Song... not a word so far.

Is there a world quest that at least mentions it? Or was there some limited event that I missed?

Obviously things didn't turn out like that, and I'd love to know if any quest touches on the topic, because the wacky geometry is just way too cool of a detail to just drop and never elaborate.

Right now I'm moving my stuff from Floorp over to Librewolf and noticed that some of my bookmarks are ones that were auto-created by Manjaro.

Manjaro was the first Linux distro I used as a daily driver (after Windows Update ate my boot partition) around the spring of 2022. I know that four years is not a long time, but within context, I've wiped and reinstalled my PC at least six times (soon to be seven) and moved from Firefox to Brave to Floorp to Librewolf, and those bookmarks survived everything.

Archived article: https://archive.md/HONwC

They'll release one more update (my guess is whatever release-ready content they've already got), then the servers will shut down next Thursday.

"We don't need player counts to be super huge in order to be successful" is starting to ring hollow.

I've found the solution, and it's exactly as stupid and obvious as I was expecting.

The classroom computers were deployed using Clonezilla from an image that had the VirtualBox VM pre-configured. As a result of this, every VM had the same MAC address, which probably caused a lot of ARP collisions, since all the hosts and VMs were essentially on the same broadcast domain.

The solution was to simply randomize each VM's MAC address. After that, ICMP, SSH, and HTTP worked as expected. Thanks for the suggestions, but it was caused by my own oversight in the end.

(edit) I got around to reading the comments just now, @maxy@piefed.social was totally correct.

I know this isn't "selfhosting" as most people imagine it, but it is about hosting services on own hardware, hence why I'm posting in this community.

I'm supposed to help a teacher set up a networking exercise where pairs of computers are connected directly on a crossover cable and can access services (echo, HTTP, SSH, FTP) on each other. Every computer is identical: Windows 10 host, one VirtualBox VM running Linux Mint with a bridged adapter in promiscuous mode. Each host and VM has its own static link-local IP address.

The problem is, the VMs can't talk to each other, and I don't know why.

From one VM, I can ping itself, its host, and the remote host, but not the remote VM. Each host can ping itself, the local VM, the remote host, but not the remote VM. I've tried connecting both hosts to a layer-2 switch, with the same result.

Can someone point me at the one thing that I'm obviously doing wrong?

(edit) I've also tried to set the default gateway to the host's, remote host's, and remote VM's address, but nothing changed.

Running Linux on metal isn't an option. In the past, the classroom computers used to dual boot Windows and Ubuntu, but the Windows install got so bloated (the software too, not just Windows) that it needs the full SSD.