About a decade ago I was playing a game on Linux and the game crashed and took the entire DE with it. So I went to a different tty and started a fresh x desktop session and started playing again until the game crashed again (I was running a bunch of mods so it would crash every couple of hours or so) and still didn’t feel like rebooting so I went to yet another tty and started yet another x desktop session. I did this about 3 times in total before I finally went “I should probably actually reboot because this has to be making a bigger mess of things”

Had a zfs array on an adaptec raid card. On reboot the partition table would get trashed and block the zfs pool from coming up, but running fdisk against the disk would recover it from the backup.

Had a script to run on reboot that just ran “fdisk -l” on every disk, then brought up the zfs pool. Worked great for years until I finally did a kernel upgrade that resolved it.

Prior to switching (upgrading?) to Wayland, Debian KDE crashed under X11 regularly when waking from hibernation and the taskbar would disappear. Restarting the plasma shell made it operable again, so I created an alias and regularly rebooted the DE shell 2-3x a day:

alias damnTaskbar='killall plasmashell ; kstart plasmashell &'

sssd didn’t work well with my company’s AD server, which would cause repeated authentication failures until I restarted sssd. I rigged up a bash script which would restart sssd any time xscreensaver logged an auth fail.

I’ve set Raspberry Pis to auto-reboot themselves at night if they are being used for headless network services that need to be available 24/7, just to clear out memory leaks or other things that may have gotten locked up. Not sure if that’s duct tape or just a standard practice. They aren’t the most stable things sometimes. They’re known for power supply and SD card issues.

This certainly isn’t of the same caliber as some of these other comments, but I found it to be fitting to the topic.

Last year I was having problems getting the game stellaris working on arch. (I use bazzite now, btw) My solution was the following:

1. download the game via steam.
2. switch it to use proton
3. switch it back to linux version
4. use the terminal to make the entire game folder read-only, so that steam couldn’t touch the game anymore and screw it up.
5. add the exicutable to PATH
6. start the game via terminal

If any one of those step was left out, it didn’t work. I’m no linux expert, so I didn’t have the skills to actuality find the real problem.

My mother uses some software that runs in the browser for her shop. It can print out receipts and scan items. To do these things it has a small “sattelite” application that runs on the system and interacts with the printer and scanner. This software only runs on Windows and Linux doesn’t have drivers for the scanner.

When I switched her over to Linux and found this out in the process I wanted to stop, give up and install windows.

But then I had a stupid idea. I could run the sattelite program in a Windows VM and pass through the USB devices for receipt printer and scanner. The webapp uses requests to localhost:9998 to communicate with the sattelite so I set up a apache server that proxies these requests into the VM. I also prevented the VM from acessing the Interner so Windows doesn’t update and screw everything up.

And it works. It has been in use for a week now and I’ve heard no complaints. I’m just praying to god it doesn’t break

I have a folder full of scripts tied to aliases that fix various things when they go wonky, and I’ve long since forgotten what any of them do. I just know if xxx app stops working, I type fix_xxx into the terminal and then it does a bunch of stuff and then it works again lol.

Also I have a bunch of aliases tied to common tasks, like e1 = reboot, e2 = shutdown etc. I have no idea where that habit came from.

Edit: ALSO, just the general mish-mash of apps. I won’t have anything to do with Snaps, but the rest of it is an unholy combination of native apps, things from the AUR, flatpaks, Appimages, Docker containers and wine setups, mostly (but not all) in Bottles.

Got fed up of Pipewire suspending (old receiver takes ~2 sec to work again after spdif stream is cut) that now I auto-run aplay to play a silent .wav on loop

I regularly recommend configurations to peers that are arguably impossible for normal humans. (Not on purpose! Sorry Dave!)

I love to run stuff on Raspberry Pi, and I fear no gcc compile flag. (Ok. That’s a bold faced lie, even I fear a couple of them.) So I frequently forget the bullshit I had to do to get something weird running on a random Pi.

Did a physical-to-virtual-to-physical conversion to upgrade and unbreak a webserver that had been messed up by simultaneously installing packages from Debian and Ubuntu.

Youtube doesn’t seem to inhibit idle for me for some reason, so my screen would always turn off with swayidle while watching youtube videos. So I made my lockscreen script (which is called by swayidle)

if [ "$(playerctl status)" = "Playing" ]; then
    exit 0
else
    exec "/path/to/lockscreen/script"
fi

(lockscreen script was just swaylock called with a bunch of arguments)

Not super crazy compared to some of the things people are saying in the comments, but also definitely not how you’re meant to handle idle inhibition when media is playing lol

Possibly my light/dark mode scripts. They change my Plasma theme, which is honestly most of the job, but also set the matching GTK theme, set the new theme in running Konsole sessions, do a bunch of manual sed edits on conf files for applications that don’t follow system theming, finally restarting plasmashell to clean up the occasional edge case where a tray icon is supposed to follow the theme but doesn’t.

My Nvidia card won’t properly resume the display after suspend with the default suspend script, but if I correct the script file, every time aptitude updates the nvidia drivers, it restores the bad version of the configuration file. If you set the file immutable with chattr, aptitude throws a fit and goes into a broken state when it can’t overwrite the file on a driver update.

So I keep a good copy of the script file in the directory, and in my pre-suspend script file I overwrite the main suspend script with the good version. Every single time.

Bootstraping.