Debian/Devuan unstable is not a rolling release like Arch, it it a playground for new packages before they move to testing. Unstable and testing are not subject to the same quality control as stable, they can and do break at any time, and they are categorically not recommended for inexperienced users.

Do you actually need a 6.x kernel? Unless you have a very good reason for running 6.x, you're only setting yourself up for problems - particularly when coupled with third-party trash like nvidia's proprietary driver, and even more so with a bunch of patches nobody else here would touch with a long stick piled on top as well.

Even my non-mission-critical-canary gentoo desktop is still running 5.15. Why you ask? Because unless you have bleeding-edge hardware, there's nothing whatsoever to be gained from a shiny-new-shit kernel except aggravation.

This again? Seriously? Please keep your political trolling out of support threads.

I distinctly recall you stating that you were leaving...
Staying for a spot of trolling perhaps, or was that all just more melodrama in keeping with your OP?

A blanket "don't use" is a bit FUDish for me TBH. Like any 3rd party repository, the magnitude of the mess is largely dependent on what one installs and the sensibility of one's pinning.

Set up package priorities properly (i.e. everything but the specific packages you want pinned to -1) and there's no harm in installing a few things from deb-multimedia... As long as you avoid core media library replacements, they will most certainly make a mess.
Nothing a little apt-foo can't fix mind, but unless you really need, say, ffmpeg compiled with all the codecs possible, it's a situation best avoided.

Alternatively, simply installing the individual binary packages works fine as well, since they don't depend on anything else that isn't in the debian/devuan repos.

The first track is the iso9660 filesystem, in this case containing the game data files (it's just empty in the "music only" image).
Most games from the late 90's that included music used these mixed-mode discs, where the first track is mode 1 (CD-ROM) and the rest of the tracks are mode 0 (CD-DA) audio tracks. That way the music can be played by the drive's audio playback hardware without the CPU load of decoding, say, MP3 files.
If you put such a disk in a CD player it will actually try to play track 1 as audio... With somewhat unpleasant results. Your ripping software is smarter and will ignore it.

It's the same on any OS, you learn what software you like by trying it out or by word-of-mouth. You find windows easier because you have more experience with it.

Well you did pick the hard way, compiling it by hand in your home directory. Installing from the deb-multimedia repos is pretty painless (that's how I install it), and using dpkg to build a .deb package from the source shouldn't be much worse.
It's common practice on linux to install applications system-wide using the package manager, so it's not surprising that going against the grain will make things difficult. Had you built and installed a .deb package, it should have set up the udev rules and all that for you.

Of course if debian actually shipped the damn thing in their repos, there would be no hassle whatsoever. I really don't get the complete lack of interest from the maintainers on this particular package TBH, especially as the cdemu devs have gone so far as to include all the needed files already.

Understanding of CD formats, experience, and a little guesswork. Also extrapolation from the bin/toc example in the cdemu manual, where it demonstrates giving cdemu only the .toc filename and it figuring out loading the matching .bin by itself.
.ccd, .cue, and .toc are all "table of contents" files that define how to read the matching .bin or .img, it's pretty logical that you'd need to load that first. Simply opening the .ccd as text should make it obvious what it is and why you might need it.
.sub is subchannel data, and IIRC it's optional unless the disk actually uses a subchannel. Subchannels are most commonly used for supplimental data such as CD-TEXT (track titles), pre-emphasis data... or for copy-protection bullshit.

You need to load the .ccd file, not the .img. The .ccd contains the session and track information needed to determine the disk layout, without it you will get only the first (data) track, if anything.
Same with bin/cue format, you load the .cue file not the .bin.

steve@perdition ~/Incoming/groundzero/full $ unrar x quake2-ground_zero.rar 

UNRAR 6.12 freeware      Copyright (c) 1993-2022 Alexander Roshal

Extracting from quake2-ground_zero.rar

Extracting  ground.zero.ccd                                           OK 
Extracting  ground.zero.img                                           OK 
Extracting  ground.zero.sub                                           OK 
All OK
steve@perdition ~/Incoming/groundzero/full $ cdemu load 0 ./ground.zero.ccd
steve@perdition ~/Incoming/groundzero/full $ cdemu status
Devices' status:
DEV   LOADED     FILENAME
0     True       /home/steve/Incoming/groundzero/full/ground.zero.ccd
steve@perdition ~/Incoming/groundzero/full $ cdemu device-mapping
Device mapping:
DEV   SCSI CD-ROM     SCSI generic   
0     /dev/sr1   
steve@perdition ~/Incoming/groundzero/full $ cdparanoia -Q -d /dev/sr1
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  2.    13234 [02:56.34]   124760 [27:43.35]    no   no  2
  3.    11662 [02:35.37]   137994 [30:39.69]    no   no  2
  4.    14547 [03:13.72]   149656 [33:15.31]    no   no  2
  5.    13307 [02:57.32]   164203 [36:29.28]    no   no  2
  6.    13487 [02:59.62]   177510 [39:26.60]    no   no  2
  7.    13418 [02:58.68]   190997 [42:26.47]    no   no  2
  8.    13054 [02:54.04]   204415 [45:25.40]    no   no  2
  9.    13878 [03:05.03]   217469 [48:19.44]    no   no  2
 10.    11145 [02:28.45]   231347 [51:24.47]    no   no  2
 11.    20568 [04:34.18]   242492 [53:53.17]    no   no  2
TOTAL  138300 [30:44.00]    (audio only)
steve@perdition ~/Incoming/groundzero/full $ cdemu unload 0

Looks fine to me. vOv

There are plenty of CD rippers. There are fewer drive emulators, because drive emulators are primarily used either for dealing with proprietary windows disk image formats or for piracy... Neither of which are a priority for free software.
CDemu works fine though, why do you need more than one virtual disk drive anyway?

I disagree. Finding the software needed to load those clonecd images was extremely easy, and I didn't even have to navigate the minefield of shitty websites, adware, crippleware, and malware I would have on windows.
The only "difficult" part is that debian doesn't package cdemu. That bit is plain ridiculous, it's been requested repeatedly over the years.

The above is for demonstration purposes only of course, and I absolutely did delete those pirated images when I was finished You should still buy the game on GOG.

Back in the day, devices had non-volatile memory to store firmware in. Then manufacturers found they could save a few cents.

For most things, yes.

The kernel and/or udev.
Generally speaking, the device driver requests firmware through the kernel API, and the kernel pulls it from disk. If the root filesystem is not yet mounted, this may be deferred and a udev trigger used to load it once it's available.

When the device driver is loaded, if possible. Where exactly this falls in the boot process depends on how the kernel and initrd were built - primarily whether the firmware files are in the initrd image or not.
(AKA, I could tell you how it works on gentoo, but I'm too lazy to dissect the devuan initrd to see if it's the same)
Obligatory kernel documentation link.

As for the refracta stuff, I have no idea. I dislike refracta intensely.

Indeed. The things that will kill li-ion cells the fastest are heat, repeated deep-discharges, and continuous trickle-charging... Two of which you will get in spades if you leave a machine plugged in with the EC set to maintain 100% charge.
If you intend to store a battery (functionally what an always-on-ac laptop is doing), you want it at 60-80% and as cool as possible. Often this means it's better to remove the battery entirely if the machine allows it.

This "battery care" behaviour is run by the embedded controller, it has it's own nvram and whatnot since it needs to handle charging when the machine is off etc.

Most laptops I have seen have manufacturer bloat software for tweaking charge behaviour, but without it windows will just go for maximum runtime. Consumers rate portables on runtime after all, and replacement batteries make money...

I've been using mc for ~20 years, and I've never heard of, needed, or wanted to scroll the filelist by "dragging" the mouse. The scrollwheel works fine.
TBH I primarily just use the keyboard though, that's what page up and page down keys are for, is it not?

Proof positive that age does not always beget wisdom then.

The problem is you insulting people who volunteered their free time to try to answer your questions.
If you want guaranteed professional responses, you go to a paid support channel. This is not that, this is best-effort when-we-feel-like-it by a community of volunteers. Answers are not guaranteed, correct answers even less so.

Innoextract works on the GOG windows installer, as I mentioned in the other thread.

I just extracted the GOG "Quake II Quad Damage" installer, and there are 19 tracks included as .ogg.
A cursory listen says that's the original soundtrack, though I'd have to dig out my CDs to see what's missing (MP1 & MP2 music?)

Also, it appears to come with the original AQ2 as part of "Netpack 1"

Should be as easy as 'innoextract setup_quake2_quad_damage_2.0.0.3.exe', grab the extracted "app" directory, drop in yamagi binaries and play.

Pretty much exactly the same way. '+set game<mod directory>' works for 95%, if a mod needs something else it'll be in the instructions.

Why on earth would you run Quake 2 (or any open-sourced id-tech engine for that matter) in wine?

HoaS suggested yamagi earlier, and I concur. It's very close to the original experience and highly compatible, with a little bit of modernisation and graphical updates where it matters.
Yamagi is what the quake2 debian/devuan package will install.

I don't game on devuan specifically (gentoo desktop and all that), but from what I gather getting Q2 up and running should be as simple as 'apt install quake2', then following instructions WRT game-data-packager.

If you want to play with shiny new stuff (and don't mind compiling the engine yourself), there's VKQuake2 and Q2RTX too, for vulkan support and raytracing respectively.

It's not a real LAN party unless it involves Doom and a bunch of null-modem serial cables.

Aside, and on the topic of old id-tech games, I think I may have a small doom wad hoarding problem...

du -sh Doom/Mods
6.8G    Doom/Mods

Not bad for a game that shipped at ~30MB

AFAIK it never went away, and is still on sourceforge same as it ever was.
Steam blah blah hype steam... yawn.

Gotta love all the noise about it being "FREE on Steam!"... "For FREE!". When it was a free mod to begin with and the Q2 engine open-sourced decades ago.