Not sure if this helps with your particular situation, but you can change the title of a window with the WM_NAME atom. I edited the previous version of this post because I provided a long example that did this with XSetWindowProperty(), but it turns out there's a dedicated function XFetchame() that does this much more easily. The documentation is here:
https://www.x.org/releases/current/doc/ … E_Property
If you first need to identify the windows that need their name changed, you can use XGetClassHint() to get the unaltered application name. (Terminals will usually update the title with the working directory, etc.)

Weird, I have Devuan and firefox-esr on four different systems now, and all of them work fine with bare ALSA. One thing I've noticed, though, is that the ALSA mixer on a new installation always starts out with deranged settings that give me no sound. Channels are muted, or set to zero, or multiple combinations thereof. On a new system, before I try to use audio, I add my user to the audio group, open alsamixer, max out everything, and make sure all switches are un-muted.

It's impossible to damage a modern CPU by disabling the fan. They have built-in thermal protection that will immediately throttle or completely shut down the device if a safe operating temperature is exceeded. It's one of the upsides of the spooky "management engine" they put in processors now. I've seen videos where people forget to apply thermal compound, a mistake that would have instantly killed older CPUs, but the only sign was that the system booted and ran extremely slowly. There is no known exploit that can disable this feature; it's beyond the control of the OS or BIOS, for good or ill.

I've never heard of a Linux remote exploit that could corrupt the NVRAM, but I suppose it's possible. However, anyone with sufficient knowledge to deploy such a sophisticated attack would almost certainly be aware that simply disabling the CPU fan would not cause any permanent damage. I would expect them to go after a softer target, like the hard disk.

I have had systems where the NVRAM because inexplicably corrupted, sometimes repeatedly and seemingly at random. In at least one instance, I'm positive it wasn't due to a remote exploit, as the machine had never been connected to the network. A power surge, static discharge, or bad motherboard component could be to blame. Intermittent BIOS faults are the worst, and almost impossible to diagnose. Often it's easier to just replace the motherboard. And I say that as someone who hates giving up!

Oh, I've had this specific problem as well, and I think you're right. The brightness keys were working on XFCE with the nouveau driver, but stopped when I installed the nvidia driver. I think it's because the nvidia driver moves the brightness controls to a weird location. Most drivers have them under /sys/class/backlight/acpi_video0/, but nvidia puts them under /sys/class/backlight/nv_backlight/. Dedicated utilities such as brightnessctl and xbacklight have no trouble finding them there, but DEs don't seem to be coded as intelligently.

USB tablets should still work, even if very old. Only tablets with a serial interface were deprecated, and only in post-2022 version of X11.

I've had similar problems on several different laptops. The keyboard backlight keys dodn't work, and evtest doesn't even show them emitting scancodes in the console. I suspect it might have something to do with the brightness_switch_enabled kernel setting, but I've never been able to figure it out. I always end up just binding my own custom hotkeys to scripts that set the backlight via brightnessctl. I find my own key bindings more convenient anyway!

@aluma hey, nice work! That's great memory usage, especially considering you've got some KDE stuff running. I looked up the ps_mem utility you guys are using, and it gave me a chance to try out installing a Python package with pipx. Here's what I get with basically nothing but an xterm window open. Not sure why my Xorg is so memory-hungry. Maybe lots of fonts?

ntpd is a surprise. Maybe I should have installed the OpenBSD ntp daemon instead. dunst is supposed to be a lightweight desktop notification server. I guess it's lightweight compared to GNOME. I have no idea what's going on with exim4, it must be misconfigured. I just installed it because cron said it needed a mail handler for system alerts, and it's supposed to be the "light" version!

Private  +   Shared  =  RAM used       Program

148.0 KiB + 112.5 KiB = 260.5 KiB       seatd
224.0 KiB + 122.5 KiB = 346.5 KiB       sh
176.0 KiB + 184.5 KiB = 360.5 KiB       init
424.0 KiB + 124.5 KiB = 548.5 KiB       cron
388.0 KiB + 221.5 KiB = 609.5 KiB       dbus-launch
  1.0 MiB +  36.5 KiB =   1.0 MiB       ssh-agent
748.0 KiB + 486.5 KiB =   1.2 MiB       su
636.0 KiB + 691.0 KiB =   1.3 MiB       dbus-daemon (2)
  1.2 MiB + 113.5 KiB =   1.3 MiB       udevd
920.0 KiB + 994.0 KiB =   1.9 MiB       getty (6)
  1.9 MiB + 107.5 KiB =   2.0 MiB       dhclient
  2.2 MiB + 133.5 KiB =   2.3 MiB       rsyslogd
  2.0 MiB + 655.5 KiB =   2.6 MiB       sshd
  1.5 MiB +   1.6 MiB =   3.1 MiB       bash (2)
  1.7 MiB +   1.7 MiB =   3.5 MiB       xdm (2)
  3.4 MiB +  97.5 KiB =   3.5 MiB       iwd
  5.8 MiB +   1.1 MiB =   6.9 MiB       xterm
  8.5 MiB +   5.1 MiB =  13.6 MiB       dunst
 15.7 MiB + 140.5 KiB =  15.8 MiB       exim4
 15.8 MiB + 971.5 KiB =  16.8 MiB       ntpd
 14.1 MiB +   6.2 MiB =  20.3 MiB       x-window-manage
 95.0 MiB +   2.0 MiB =  96.9 MiB       Xorg
---------------------------------
                        196.0 MiB
=================================

Edit: sorry, I didn't know this would post so big. I can remove this if it's too big for the thread, just let me know!

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

I haven't seen this one before, is this new?  The phrase "going behind [one's] back" implies deception, which really crosses a line.

I kept searching the web for instances of the error message, and eventually I found something helpful:
empty runlevels overide LSB defaults
It turns out that re-installing a script without first removing it can result in this error. So I merely did the following, and it ran without errors, installing the symlinks in the proper locations:

# update-rc.d -f iwd remove
# update-rc.d iwd defaults

The manpage for update-rc.d says that running the `remove' directive while the script is still present in /etc/init.d will result in errors. However, that didn't happen for me. In fact, it was exactly what I needed to do to fix the problem. It removed the symlinks in /etc/rc*.d, which then allowed me to reinstall the script with the default settings.

[Edit to clarify this paragraph] The manpage doesn't mention that running update-rc.d with the `defaults' directive when symlinks are already present in /etc/rc*.d will result in errors. There is a paragraph that says it "does nothing" if files exist at /etc/rc*.d/[SK]??, and I think this information is meant to apply to the `default' action, although the wording isn't really clear. But that's not really what happened either. In my case, installed kill scripts all over the place.

It's all very confusing, but I think I have the proper procedure figured out now.

Thanks GlennW, I tried changing the runlevels, but I'm still getting the message about empty runlevels. For some reason update-rc.d is not properly parsing the file. It's so strange! I also had to install a script for nftables, and it worked fine.

I wish I'd looked at the rc directories before changing the iwd script to see if it was installed wrong from the start. That could have been the problem from the beginning.

I've got the orphan-sysvinit-scripts package on all my systems now, that's a good one to have.

Edit - update:

I used `update-rc.d iwd enable [runlevels]` to force the service to start when I wanted it to. It still doesn't explain why the default method fails, but at least it works now, and the service starts at boot!

Thanks, I believe we may already be using the same script, as the /etc/init.d/iwd script that was installed on my system says it was generated by sys2dv:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.

I think the sys2dv script would work fine as it is, if it weren't for the known bug with the Atheros hardware, which was apparently fixed for the newer chipset (ath10k) but not my older system (ath9k.) This is a really old system (2008) and I don't think anyone at iwd or the kernel cares about fixing it anymore. I'll have a look at the sysd2v script source and see if I can figure out where I need to introduce the 2-second delay that the systemd unit fix would normally provide.

Some systems have capacitors that will hold the CMOS memory for up to an hour after you remove the battery. Others have non-volatile memory, though, and can't be reset that way. I have an old Dell laptop with an unknown admin password and I haven't found any way to reset it.