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.
Although swapfiles shouldn't be in snapshots (or otherwise Copy-On-Write), that doesn't mean you can't have them in btrfs. You can create a non-COW file in a separate btrfs subvolume that you don't enable automatic snapshots for and use that for swap. btrfs-progs even has a btrfs filesystem mkswapfile convenience command for allocating a NOCOW file suitable for swap use, though you still need to make sure to put it in a subvolume that you don't make snapshots for.
You probably don't want to put swap in an unencrypted partition if you're encrypting your root filesystem. Swap is liable to write sensitive data to disk, especially if you use hibernate.
I think the messaging is clear this time: Steam Deck is the defacto and flagship SteamOS device that represents the platform, and it has a strong established mindshare already, while other options are now available as well. It had a headstart of three years that gave it plenty of time to shine, and the handheld form-factor still stands out as something the competition (Windows) treats as an afterthought at best with poor UX.
The Steam Machines effort tried to position Alienware Alpha as its focus but the press coverage including all of the other options at the same time confused people. Steam Machines also had awful timing and pricing, with the Alienware being outdated hardware whose Windows version had already been out for a year for the same price or lower by the time the SteamOS version released, and the SteamOS version offering absolutely no advantage in pricing, power, features, or UX for most gamers. All of those factors are different this time. Plus game compatibility was much worse than it is now.
some games that looked old (like Animal Crossing)
There's a good reason for that one: the first animal crossing game was originally made for Nintendo 64, though that version was only released in Japan. GameCube got a port of it and that port (plus some extra features) is what released in English.
The detail that stands out the most about this is its screen resolution: 720x480 is both a perfect 3x integer scale of GBA's 240x160 and a good 1x fit (with small black bars) for NTSC video.
GBA games scale particularly poorly on most of their other devices' screens. On 640x480, the closest integer scale is 2x which makes the image fill only 50% of the screen area, otherwise you can use 2.667x scaling to fill the width (11% of height being letterboxing) at the expense of blurriness from non-integer scaling.
The last time Anbernic released a screen well-suited for GBA games was four years ago with RG351P/RG351M. Their 480x320 screens are a great 2x fit for GBA but an awful fit for every other system. 720x480 is a lot better for NTSC content while still being integer scale for GBA.
Unfortunately the lack of analog sticks ruins the compatibility improvements it'd otherwise have over RG351 thanks to the screen and newer CPU. Best to see this as like a GBA that can also play SNES games and not much else. I'd rather have a system that includes the inputs it needs than one that imitates a classic system's design.
Most of the "Is open source software safe?" section of this post seems to advocate for what's conventionally called Security Through Obscurity, which is widely considered very ineffective at preventing exploitation and at best a minor hurdle.
There are a lot of differences between Android and iOS in terms of security, attack surface, and exploitation, but attributing that to open vs closed-source completely misunderstands the entire subject. For just two of the countless reasons: Many of the worst vulnerabilities that affect Android devices are in closed-source proprietary Qualcomm firmware. A platform being open in the sense of allowing users to install any application they want to (like Windows and Android to a limited extent) or closed off to prevent installation of unapproved software (iOS, PlayStation, Toyota cars, TiVo, etc.) is completely separate from whether that platform is open-source or not. GPLv3 has license terms that try to tie the two concepts but I chose examples that don't use it at all. Also, iOS has public kernel source code.
Although by a different organization in a different continent, enshittification was also selected as word of the year for 2023 by the American Dialect Society.
There should have been a simple way to label them for usage that was baked into the standard.
There is. USB IF provides an assortment of logos and guidelines for ports and cables to clearly mark data speed (like "10Gbps"), power output (like "100W" or "5A"), whether the port is used for charging (battery icon), etc. But most manufacturers choose not to actually use them for ports.
Cables I've seen usually are a bit better about labeling. I have some from Anker and ugreen that say "SS”, "10Gbps", or "100W". If they don't label the power it's probably 3A and if they don't label the data speed it's usually USB 2.0, though I have seen a couple cables that support 3.0 and don't label it.
I've been using single-disk btrfs for my rootfs on every system for almost a decade. Great for snapshots while still being an in-tree driver. I also like being able to use subvolumes to treat / and /home (maybe others) similar to separate filesystems without actually being different partitions.
I had used it for my NAS array too, with btrfs raid1 (on top of luks), but migrated that over to ZFS a couple years ago because I wanted to get more usable storage space for the same money. btrfs raid5 is widely reported to be flawed and seemed to be in purgatory of never being fixed, so I moved to raidz1 instead.
One thing I miss is heterogenous arrays: with btrfs I can gradually upgrade my storage one disk at a time (without rewriting the filesystem) and it uses all of my space. For example, two 12TB drives, two 8TB drives, and one 4TB drive adds up to 44TB and raid1 cuts that in half to 22TB effective space. ZFS doesn't do that. Before I could migrate to ZFS I had to commit to buying a bunch of new drives (5x12TB not counting the backup array) so that every drive is the same size and I felt confident it would be enough space to last me a long time since growing it after the fact is a burden.
2026 is the 30th anniversary of the Pokémon series. They've always done new generations on the big anniversaries: Diamond/Pearl (gen4) for the 10th in 2006 (in Japan) and Sun/Moon (gen7) for the 20th in 2016. It would likewise be fitting to release the next generation in 2026 rather than this year.
I also believe we would have already seen a Z-A reveal trailer before the end of the 2024 if it was truly slated for a date as early as spring or early summer. Holding off on showing or saying absolutely anything since the teaser last February seemingly implies it's Game Freak's one big title for the year that'll be the main focus this time.