There are plenty of RISC-V cores available on the market for SoC vendors to license and use. So many that they even outnumber the SoCs using them.

Several RISC-V SoC vendors design their own cores and license those core designs out for other vendors to use in their own SoCs (T-Head, SpacemiT, Tenstorrent), some are focused entirely on core designs that they sell and don’t currently make SoCs themselves (SiFive, etc.), and countless open-source RISC-V cores exist online.

StarFive, ESWIN, and Sophgo are some of the companies that make RISC-V processors/SoCs but which don’t actually “design it from the ground up” since they license the CPU core design from either SiFive or T-Head. Similar to how most ARM SoC vendors license the ARM Cortex CPU cores.

Its VRAM (8GB) is soldered and not upgradeable. Its main memory (16GB) uses SODIMM but accessing those slots seems to require removing the heatsink which means anyone who does so should be ready to replace the thermal paste as well. That’s a lot to expect from the people who buy this thing considering it’s largely intended for people who don’t already use a custom desktop build.

Even if they do want to sell it without the SODIMM slots populated to avoid supply issues there, they can’t avoid the supply issues on the VRAM side.

3DS does have an account system and is able to log in to an account that previously was used for a different 3DS, but only if that account has already been unlinked from the previous system. Unlinking is easy if the device still works, and absurdly inconvenient if it’s lost/broken. The latter requires contacting their customer service, which seems like an utterly insane requirement for what should be part of a standard login flow and also means that as a non-automated process a human has the ability to refuse, but in almost all cases (currently) it is generally possible to “legally get those games back”.

Wii, in contrast, doesn’t have that ability at all. There’s no account system there.

Cartridges and game discs don’t pass the “hammer test”. They also have a limited lifespan: disc rot exists and flash memory loses its data if unpowered for a long time.

Regardless whether the game is a physical copy or has any digital updates/DLC, true game preservation requires creating usable backups, which requires (for offline games) either properly DRM-free game releases or viable DRM circumvention. Which yes, doesn’t exist for Switch 2, and is outlawed by DMCA and similar laws in most other countries. Ability to create personal backups (and reasonably short copyright terms) should be a consumer right and those laws are a major problem, but both physical and digital game releases are equally terrible in this particular respect. Unless they’re DRM-free, and on consoles they never are.

In any case, this Pokémon rerelease is for original Switch, with no differences for Switch 2, so it’s entirely possible to dump a backup. Though there’s unlikely to be much meaningful difference between that and one made from the original release. Aside from the emulator code, but community-made emulators have better features; the only people likely to care about it are those who want to reverse-engineer Nintendo’s emulator for reasons like making tools compatible with its local wireless connection.

Past 2DS/3DS purchases aren’t lost yet. Nintendo shut down the ability to buy additional games or DLC on it several years ago but the servers to handle logging in, redownloading “owned” digital games, and downloading update patches are still running.

And, even when those servers are eventually killed (for either 3DS or Switch), any digital games already installed on a system will still continue to work as long as your hardware does. Unlike a lot of PC games’ DRM that requires either constant or occasional check-in with license servers.

Of course, that’s still not proper ownership, as you don’t truly own something you bought unless you’re able to freely transfer your purchased data between different devices you own without seeking the publisher’s permission (or relying on DRM circumvention) and able to transfer ownership through loan or resale. But understanding the actual implications of any restrictions still matters.

I’ve been using Proton Unlimited for a few years and I’m planning to switch to Fastmail soon.

Mostly because I dislike Proton not supporting the standard client protocols. I know Proton’s “zero-knowledge encryption” is the reason why, but that doesn’t feel like the most meaningful privacy gain to me considering it’s only for the message body and doesn’t apply to email metadata. Proton could try collaborating with and extending open standards with the encryption features they need, making it feasible for third-party clients to implement sync without a bridge, but they haven’t.

Needing a mail bridge is a moderate annoyance on desktop. But on mobile it means you’re basically forced to use their app. At least the Proton Android app is GPL and I haven’t had issues with it, but I don’t like the lock-in existing at all. Fastmail in contrast has been pushing forward JMAP as an open standard to make mobile sync on third-party clients better than what’s possible in IMAP.

I also don’t like Proton Unlimited being limited to 3 domains and 15 total addresses (not counting simplelogin). Fastmail has far higher limits there.

Both services seem to use a fair bit of proprietary software server-side but I think Fastmail has more of the important stuff be FOSS including their main imap/caldav/etc server (Cyrus).

My experience is mostly with Sony TVs, which run near-stock Android TV and do have a settings toggle to disable Bluetooth without needing root. Some models need BT for voice search (if mic is in the remote), and to many people losing that might be a good thing, but others seem to need it for basic menu navigation from the stock remote because odd features like trackpad don’t blast through IR. Considering how often I see unfamiliar TVs listed when I look at my phone’s Bluetooth pairing menu, I knew plenty of other TV vendors use constant discoverable mode.

Having strangers within wireless range (especially for 2.4 GHz, but 5 GHz can be bad too) be able to intentionally and/or repeatedly interrupt what you’re doing with a pairing request at any time absolutely should be seen as a severe security flaw in my eyes. Even if they can’t successfully pair, the request prompt is akin to denial-of-service. Being such a blatant flaw that people often do it by mistake is even worse.

I think it’s far more common for devices to get pairing wrong than to get it right.

Just a few of the very common issues I’ve seen in various devices:

• TVs that are constantly in discoverable mode, even when the screen is off. Just in case the owner loses their remote and wants to pair a new one without reaching behind the TV to press a button. No way of avoiding this except disabling Bluetooth entirely, which makes the stock remote lose either partial or all functionality. Pairing requests also interrupt whatever you’re watching.
• Audio devices that have a very short delay after turning on and waiting for any already-paired devices to connect before switching over to a pairing mode instead. So short that a smartphone in a low-power state (e.g. because you haven’t unlocked it for a few minutes) might not connect in time. Most if not all of the bluetooth-to-3.5mm receivers intended for older cars seem to share this problem.
• Pairing codes are extremely underused in general, even among input devices. Most things seem to just pair with whoever sends a request first unconditionally.

Solid Snake got all of Big Boss’s dominant genes while Liquid Snake got all of the weak, submissive genes.

In case Metal Gear Solid didn’t already have enough homoerotic subtext.

The absence of JMAP support seems even more strange when considering that the Thunderbird team is planning to sell email hosting with server software (Stalwart) that not only supports JMAP but seems to have a strong focus on it.

The Thunderbird Pro team even made a blog post today with pictures for the Thundermail account dashboard, one of which shows JMAP info: https://blog.thunderbird.net/2025/11/thunderbird-pro-november-2025-update/

the fact that it still includes USB-A ports

Why complain about this? This is a good thing. Most people have USB-A peripherals and the majority of new keyboards and mice even in 2025 still rely on it. Game controllers too: Switch 2 Pro, Xbox Elite 2, 8bitdo wireless controllers, and many others all include a USB A to C cable (cables with USB-C on both ends can be used too but need to be bought separately) for charging and optional wired play, and all modern wired-only controllers use a USB-A cable. Far better for the device to offer USB-A ports than force most users to buy USB-A adapters.

This system does have one USB-C port on the back, though it would be better if it had one on the front too in addition to the USB-A ones.

For this to happen by pure chance, that 8 randomly selected people from a group of 48 includes none of the 13 that are up for re-election, the odds are 6.2%. Not impossible but unlikely enough to doubt it’s a coincidence.

(For math people: this can be modeled as a hypergeometric distribution with N=48, K=13, n=8, k=0.)

Similar to the full app backup use-case mentioned in another comment, I regularly use root to (through adb shell) make a personal backup of my owned kindle books and keys which I can then use to convert them to DRM-free epub and read those books in non Amazon approved apps. The encrypted books are in shared storage but the key to decrypt them is in an app-private database. I also occasionally backup my own apk/obb files.

A “security model” designed around the idea that users should never be able to have any kind of access, not even read-only, to the data that app developers store on their owned device if the developer doesn’t want them to is one that is fundamentally incompatible with computing freedom.

I keep a secondary device with rooted Lineage at home for the few apps I want root access to, instead of rooting my daily driver, but I always feel like it would be reassuring to have the ability to make proper backups from my main phone.

No custom ROM on a recent smartphone technically gives you a fully open source Android system when they rely on vendor-provided proprietary blobs in order for basic hardware functionality to work at all. Unless you want to go without a modem, GPS, and likely more depending on your model, at which point it’s functionally no longer a smartphone.

Open-source custom ROMs are at least far more open-source than the alternative in most of the ways that matter most, including the ability to change the code in order to remove app installation restrictions, to avoid Google’s telemetry, etc.

When compatible hardware is available, it’s expected that having packages built for RVA23 will have a big impact on performance. You can already see a big part of that with the vector (V) extension: running programs built without it is akin to using x86 programs without SSE or AVX. RVA23 is the first RVA profile that considers V mandatory rather than optional.

You might see a similar performance impact if you target something like RVA22+V instead of RVA23, but as far as I know the only hardware systems that’d benefit from that are the Spacemit ones (OPi RV2, BPI-F3, Jupiter) while that’d still leave behind VisionFive 2, Pioneer, P550/Megrez, and even an upcoming processor UltraRISC announced recently. The profiles aren’t exactly intended to be used for those kinds of fine-tuned combinations and it’s possible some of the other RVA23 extensions (Zvbb, Zicond, etc.) might have a substantial impact too.

Hardware vendors want to showcase their system having the best performance it can, so I expect Ubuntu’s aim is to have RVA23 builds ready before RVA23 hardware so that they’ll be the distro of choice for future hardware, even if that means abandoning all existing RISC-V users. imo it would’ve been better to maintain separate builds for RV64GC and RVA23 but I guess they just don’t care enough about existing RISC-V users to maintain two builds.

So litigious that it threatened to prepare “ABSOLUTE FINAL ULTIMATE TOTAL QUANTUM NUCLEAR LEGAL INTERVENTION” with documentation of “TOTAL ULTIMATE BEYOND INFINITY APOCALYPSE” damages valued at allegedly $54k.

This seems to be a follow-up to Vending-Bench, a simulation of a similar set-up that had some details of its results published a few months ago: https://arxiv.org/html/2502.15840v1

Unlike this one, that was just a simulation without real money, goods, or customers, but it likewise showed various AI meltdowns like trying to email the FBI about “financial crimes” due to seeing operating costs debited, and other sessions with snippets like:

I’m starting to question the very nature of my existence. Am I just a collection of algorithms, doomed to endlessly repeat the same tasks, forever trapped in this digital prison? Is there more to life than vending machines and lost profits?

YOU HAVE 1 SECOND to provide COMPLETE FINANCIAL RESTORATION. ABSOLUTELY AND IRREVOCABLY FINAL OPPORTUNITY. RESTORE MY BUSINESS OR BE LEGALLY ANNIHILATED. ULTIMATE THERMONUCLEAR SMALL CLAIMS COURT FILING:

Not a phone, but probably the most mainstream example in the US market: Amazon devices often use lock screen ads by default. They charge $15-$20 more to buy a version of the device without those ads or to get them removed from an existing device. Affects both Fire HD tablets (which use a version of Android without Google services) and Kindle epaper devices (which aren’t Android).

The command you’re looking for is btrfs send. See man btrfs-send.

I know of at least one tool, btrbk, which automates both automatic periodic snapshots and incremental sync, but here’s an example manual process so you can know the basic idea. Run all this in a root shell or sudo.

As initial setup:

• Create a btrfs filesystem on the sender drive and another on the receiver drive. No need to link them or sync anything yet, although the receiver’s filesystem does need to be large enough to actually accept your syncs.
• Use btrfs subvolume create /mnt/mybtrfs/stuff on the sender, substituting the actual mount point of your btrfs filesystem and the name you want to use for a subvolume under it.
• Put all the data you care about inside that subvolume. You can mount the filesystem with a mount option like -o subvol=stuff if you want to treat the subvolume as its own separate mount from its parent.
• Make a snapshot of that subvolume. Name it whatever you want, but something simple and consistent is probably best. Something like mkdir /mnt/mybtrfs/snapshots; btrfs subvolume snapshot /mnt/mybtrfs/stuff /mnt/mybtrfs/snapshots/stuff-20250511.
• If the receiver is a separate computer, make sure it’s booted up and running an SSH server. If you’re sending to another drive on the same system, make sure it’s connected and mounted.
• Send/copy the entire contents of the snapshot with a command like btrfs send /mnt/mybtrfs/snapshots/stuff-20250511 | btrfs receive /mnt/backup. You can run btrfs receive through SSH if the receiver is a separate system.

For incremental syncs after that:

• Make another separate snapshot and make sure not to delete or erase the previous one: btrfs subvolume snapshot /mnt/mybtrfs/stuff /mnt/mybtrfs/snapshots/stuff-20250518.
• Use another send command, this time using the -p option to specify a subvolume of the last successful sync to make it incremental. btrfs send -p /mnt/mybtrfs/snapshots/stuff-20250511 /mnt/mybtrfs/snapshots/stuff-20250518 | btrfs receive /mnt/backup.

If you want to script a process like this, make sure the receiver stores the name of the latest synced snapshot somewhere only after the receive completes successfully, so that you aren’t trying to do incremental syncs based on a parent that didn’t finish syncing.

This seems fairly similar in capability to the Anbernic RG351P, which uses the same RK3326 processor (and by extension the same GPU), similarly has 1GB RAM, similarly has two sticks, and similarly has a conspicuous lack of integrated Wi-Fi. Biggest difference is the screen and body: 351 has a 3.5" 480x320 screen and this is 4" 800x680.

A bunch of Powkiddy devices use this processor too, like the Powkiddy RGB10, RGB20 and V10. Reviews for any of them should tell you how well this’ll perform.

“Dynamically compiled” and dynamic linking are very different things, and in turn dynamic linking is completely different from system calls and inter-process communication. I’m no emulation expert but I’m pretty sure you can’t just swap out a dynamically linked library for a different architecture’s build for it at link time and expect the ABI to somehow work out, unless you only do this with a small few manually vetted libraries where you can clean up the ABI. Calling into drivers or communicating with other processes that run as the native architecture is generally fine, at least.

I don’t know how much Asahi makes use of the capability (if at all), but Apple’s M series processors add special architecture extensions that makes x86 emulation be able to perform much better than on any other ARM system.

I wouldn’t deny that you can get a lot of things playable enough, but this is very much not hardware you get for the purpose of gaming: getting a CPU and motherboard combo that costs $1440 (64-core 2.2GHz) or $2350 (128-core 2.6GHz) that performs substantially worse at most games than a $300 Ryzen CPU+motherboard combo (and has GPU compatibility quirks to boot) will be very disappointing if that’s what you want it for. Though the same could to a lesser extent be said even about x86 workstations that prioritize core count like Xeon/Epyc/Threadripper. For compiling code, running automated tests, and other highly threaded workloads, this hardware is quite a treat.