It is documented in libapt-pkg-doc (/usr/share/doc/libapt-pkg-doc/method.html/index.html).

If I'd decide to implement something like this, I'd consider two options: local repo with file:// scheme or custom apt-transport. HTTP server is needless here. (But I'll never do this because I prefer to rebuild packages myself if there's no repo for my distro.)

Bank clients. Taxi aggregator clients.

Why though?

The filesystem is organized to store data by its type, not by the physical storage. In DOS/Windows you stick to separate "disks", but not in Unix-like OSes. This approach is inconvenient in case of removable media, that's why /media exists. And /mnt is not suited for any particular purpose, just for the case when you need to manually mount some filesystem to perform occasional actions, that normally never happens.

Just media files, downloads, images , music kinda stuff.

That's what usually goes to /home/<username>. Maybe mount that device directly to /home? Or, if you want to extend your existent /home partition, use LVM or btrfs to join partitions from various drives. Or mount the partition to some subdirectory of /home/<username>, or even split it and mount its parts to /home/<username>/Downloads, /home/<username>/Movies etc. So you keep the logic of filesystem layout and don't need to remember where you saved some file (in /home/<username>/Downloads or in /whatever-mountpoint-you-use/downloads).

Mount them where you need. Not /mnt and not /media. Maybe /var or its subdirectory, or /srv, or /opt depending on what kind of data you want to store on that partition.

And not only did everything “just work” flawlessly, but it’s so much faster and more polished than I ever knew Linux to be!

Congrats, you are very lucky. But try to survive couple of version upgrades before recommending it to noobs.

Be careful if you buy a Samsung 8x0 SSD. They have long standing bugs that may cause data loss. They are worked around in the kernel, however you have to ensure that the workaround for your particular model exists in the kernel version you use.

It is not steganography. It's just cat original.png trojan > malicious.png.

I don't know, however this is impossible to understand what's wrong with your fonts.

What kind of changes? Package installation, removal and configuration? Use apt-mark showmanual to save list of manually installed packages, dpkg --get-selections | grep 'deinstall$' to save list of removed packages, debconf --get-selections to save debconf package settings, backup files that you edited in /etc. This should be enough for restoration, wouldn't take a long time for backup and avoid risk of filesystem inconsistency.

The standard answer: don't backup the system, automate its deployment instead. Backup only data.

The biggest problem that I see on this screenshot is that it is a compressed JPEG.

And also show ls -l /etc/fonts/conf.d

It's the same across all POSIX compliant shells. zsh is not POSIX compliant.

touch a b c 'd e f' 'g h i'
for f in *; do ls -la "$f"; done

fxd

Try to avoid using any file manager (uninstall them all if it is difficult to avoid running them). So you will practice in using file manipulation commands.

Is it still alive? I switched to LibreTube and happy with it.

What is this? Looks like a website filled with info about projects unrelated to it and gathering donations for unknown purpose.

Why not use Privacy Badger to prevent usage of tracking cookies?

I recommend to throw away this drive because blocks that are readable and writeable now, may fail soon. But if you want to use it anyway, it is possible to collect a list of unaccessible blocks usong badblocks and pass it to mkfs to create a filesystem that ignores that blocks. IIRC this is described in man badblocks.