I have not once ever seen anyone shorten the name of a Debian release like that and I’ve been following/using Debian things for two decades.

Squeeze, Wheezy, Jessie, Stretch, Buster, Bullseye, Bookworm, and Trixie aren’t “ds”, “dw”, “dj”, “ds” again, “db”, “db” again, “db” for a third time in a row, or “dt”. Both stable and sid are “s” too.

For what it’s worth, the “Download & transfer via USB” feature was applying DRM locked to the key of the specific Kindle device you select, giving you a file that’s incompatible with other devices even if they’re kindles linked to the same Amazon account. For many publishers it also gives files with drastically lower image quality than the Kindle app: about one-fourth to one-third the file size. For a couple examples, a 368MB KFX manga volume has a 125MB AZW3 file and an 8.0MB KFX light novel has a 2.2MB AZW3 file. Those smaller AZW3 files are also similar in size to DRMed EPUB files of the same books from other markets like Kobo and Google Play, so I expect it’s a deliberate choice to limit the quality of formats that are more trivial to strip DRM from.

The best way I’ve found to make personal backups of owned Kindle content is to use a rooted Android device to download everything through the Kindle app, copy the KFX files to a computer, extract the key in a root shell, and then use DeDRM tools on those files with that key.

A quick and dirty shell command I’ve used for that purpose is egrep -ao 'dsn[0-9a-f]{32}' /data/data/com.amazon.kindle/databases/map_data_storage.db. The key is 32 hex characters.

Having a rooted Android device in the first place is the biggest hurdle for being able to do that. This new jailbreak should make it possible to do something similar with e-ink kindles instead.

Don’t assume Qualcomm’s general hostility to user control and freedom is representative of all non-x86 systems.

This system isn’t like that at all. It’s usable with mainline Linux and mainline U-Boot and has no proprietary driver blobs. Granted, RISC-V has some more progress to make in terms of boot image standardization, and this board in particular uses an old SoC from three years ago (JH7110) which predates a lot of improvements that have been happening to various intercompatibility-focused RISC-V standards.

For some of the most recent ARM systems (notably excluding Qualcomm junk), I can write a single installation image for a Linux distro of my choice to a USB drive and then boot that single USB drive through UEFI on several completely different systems by completely different vendors. Ampere, Nvidia, and more. ARM’s SystemReady spec results in exactly the same user-friendly process you’re used to on x86.

The RISC-V ecosystem isn’t there yet though its very recent RISC-V BRS (Boot and Runtime Services) spec promises to bring that for near-future hardware. But this DeepComputing board doesn’t have that and doesn’t have some other features (vector instructions, RVA22/23, etc) that are very likely to become the minimum requirements for several RISC-V Linux distros in the not too distant future.