I still use pkgs.org pretty frequently when I need to find versions of packages and their dependencies across different distros and versions of distros. I had to use that to sneakernet something to fix a system just this past week.

Yes, and encryption had nothing to do with it (though I suppose it would have prevented it in this case).

A properly configured modem would ignore this coming from the Internet side, or escape the characters so that they didn’t form that string.

It was always fun saying +++ATH in IRC to see who hadn’t configured their escapes properly

All installation media is a bootable image. Whether it supports booting on the virtual hardware is another question.

Why not just install an old version in a VM and find out?

But remember, no search engines for troubleshooting, forums and printed matter only. (And mailing lists and IRC, but they’d probably tell you to Google it, which is off limits for this exercise.)

What computer/what hardware? What media?

There’s still microcode and other firmware blobs. Coreboot is just BIOS.

Seriously? It’s the default file manager for KDE since version 4, way back in 2006. If you’ve KDE at all since then, you’ve probably used it.

You assume the shell isn’t compromised.

Yes, but the last times it was just one city, this time it’s a state.

For basic functionality, yes.

It’s called physical-to-virtual, or p2v. Proxmox uses qemu under the hood, so you should be able to start from their docs to create the VM: https://pve.proxmox.com/wiki/Advanced_Migration_Techniques_to_Proxmox_VE

I would just download them. Already ripped, encoded, and compressed.

What laptop? BIOS option?

I don’t think static linking is that difficult. But for sure it’s discouraged, because I can’t easily replace a statically-linked library, in case of vulnerabilities, for example.

You can always bundle the dynamic libs in your package and put the whole thing under /opt, if you don’t play well with others.

What are the crazy historical reasons? As far as I know, running six ttys and one graphical session, in that order, has been standard.

The really crazy historical way to test for crashes is num/scroll/caps lock. That’s handled by a very low-level kernel driver. If those are responsive, it’s probably just your display (gpu, X, wayland, or something) that’s locked up. If they’re unresponsive, your kernel is locked up. (If you’re lucky, it’s just gotten real busy and might catch up in a minute, but I’ve only seen that happen once.)

Anything that might interfere with sleep. Literally any attached device might have a buggy driver.

I don’t see a list of hardware in your edit.

Yes. And these posts should be sent there. I don’t come to the Linux community for shitposting.

It’s for work? Keep using Windows. VM or separate PC or whatever. Maybe WINE.