None of this even attempts to address the problem of Google Play (the primary android app marketplace) being filled with malware. Every single app that’s being distributed through Google Play today already has a “verified” developer by the same criteria they’re applying system-wide. That malware can continue working as it already does without any changes.

This is exclusively about Google imposing control on all apps distributed through channels that otherwise used to be outside Google’s control.

Google’s claimed reasoning is that this control is a good thing and makes them be able to block apps made by malware developers in the same way they already do in Google Play, even for users who install apps from other sources. Critics disagree because Google forcibly taking personal information and money from all software developers and wielding the ability to remotely kill any app they don’t like for any reason have far wider consequences than protecting users from malware, and the proliferation of malware on Google Play shows how (in)effective Google’s measures against it are. Neither side believes or claims this can or will make Google Play any safer.

RISC-V is more like 1-3 years away from CPUs existing that have competitive performance in datacenter workloads. Not decades.

But they won’t be manufactured in Europe. Getting fabs up and running is indeed something that takes a very long time.

Encrypted email in the way that Proton and Tuta do it has a lot of drawbacks. Because I almost never use my personal/non-work email to communicate with another human, and automated mails tend to have the message body be no more sensitive than the subject line and metadata, zero-knowledge encryption at rest for just the mail body has a negligible privacy impact for me.

It helps to consider your actual needs and privacy goals, using the services or software that fits them best rather than just following what others say has the best privacy.

I used Proton for two years and, similarly, just recently migrated off of it last month. Since I use custom domains for email through it, and I never cared to use their other services outside of Mail (and occasionally VPN), it was a quick and painless migration. Unlike the painful migration of changing my email address everywhere to be non-gmail (which I still haven’t 100% finished after two years), this time I only needed to update DNS records and copy mailbox data. After migrating, having actual IMAP/JMAP access without a bridge is nice.

Note that you don’t necessarily need to import your entire mailbox when migrating. I never imported my email archive from gmail to proton; an offline archive of all old received emails on my NAS is enough for me if I ever need to search through it. I can even view that archive in Thunderbird.

My thoughts on a few of the other Proton services:

• Proton VPN is really nice. One of the few good ones with port forwarding. But some other options have better pricing than VPN Plus alone outside of the Proton Unlimited bundle.
• SimpleLogin (or Proton Pass masks) is nice, though using anonymous email masks is a trade-off in dependence. I prefer disposable addresses under my custom domain for anything associated with my identity regardless (like services that use my billing or shipping info), and shared domain masks for anything else. My existing shared-domain email masks in Proton still work even after my subscription ended. Addy and Firefox Relay are fine alternatives, and some other mail services like Fastmail have their own equivalent included.
• I’d rather self-host CalDAV/CardDAV than rely on online services for calendar, contacts, etc.
• I had already been using a local KeePassXC database and a NAS for many years so I had no reason to use Proton Drive and Pass, except for the latter’s email masks.

It seems they actually changed its official romanization to “Bracky” about 3 years ago, probably to avoid that problem. I listed them from memory and hadn’t realized it changed. Still, that old name was used on Japanese merch and marketing for decades, but not in any main series games since those only use the katakana “ブラッキー”.

Eevee’s name sounds close enough to being the same in Japanese and English that they even used the same voice clips for both in some anime episodes and Let’s Go Eevee. The official romanization just has a strange spelling.

Only the French version uses those names. English has Eevee, Vaporeon, Jolteon, Flareon, Espeon, Umbreon, Leafeon, Glaceon, and Sylveon. Japanese can be considered the original names, which are (when written in latin letters) Eievui, Showers, Thunders, Booster, Eifie, Blacky, Leafia, Glacia, and Nymphia.

German, Korean, and Chinese each have different names for them and most other Pokémon too. Other languages like Spanish, Italian, and Portuguese use the same names as English.

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.

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.

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.

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.

The parent comment mentions working on security for a paid OS, so looking at the perspective of something like the users of RHEL and SUSE: supply chain “paranoia” absolutely does matter a lot to enterprise users, many of which are bound by contract to specific security standards (especially when governments are involved). I noted that concerns at that level are rather meaningless to home users.

On a personal system, people generally do whatever they need to in order to get the software they want. Those things I listed are very common options for installing software outside of your distro’s repos, and all of them offer less inherent vetting than Flathub while also tampering with your system more substantially. Though most of them at least use system libraries.

they added “bash scripts you find online”, which are only a problem if you don’t look them over or cannot understand them

I would honestly expect that the vast majority of people who see installation steps including curl [...] | sh (so common that even reputable projects like cargo/rust recommend it) simply run the command as-is without checking the downloaded script, and likewise do the same even if it’s sudo sh. That can still be more or less fine if you trust the vendor/host, its SSL certificate, and your ability to type/copy the domain without error. Even if you look at the script, that might not get you far if it happens to be a self-extracting one unless you also check its payload.

A few reasons security people can have to hesitate on Flatpak:

• In comparison to sticking with strictly vetted repos from the big distros like Debian, RHEL, etc., using Flathub and other sources means normalizing installing software that isn’t so strongly vetted. Flathub does at least have a review process but it’s by necessity fairly lax.
• Bundling libraries with an application means you can still be vulnerable to an exploit in some library, even if your OS vendor has already rolled out the fix, because of using Flatpak software that still loads the vulnerable version. The freedesktop runtimes at least help limit the scope of this issue but don’t eliminate it.
• The sandboxing isn’t as secure as many users might expect, which can further encourage installing untrusted software.

By a typical home user’s perspective this probably seems like nothing; in terms of security you’re still usually better off with Flatpak than installing random AUR packages, adding random PPA repos, using AppImage programs, installing a bunch of Steam games, blindly building an unfamiliar project you cloned from github, or running bash scripts you find online. But in many contexts none of that is acceptable.

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.

“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.

With one of these Altra CPUs (Q64-22), I can compile the Linux kernel (defconfig aarch64 with modules on GCC 15.1) in 3m8s with -j64. Really great for compiling, and much lower power draw than any x86 system with a comparable core count. Idles at 68W full system power, pulls 130W when all cores are under full load. Pulling out some of my 4 RAM sticks can drive that down a lot more than you’d expect for just RAM. lm_sensors claims the “CPU Power” is 16W and 56W in those two situations.

Should be awful for gaming. It’s possible to run x86 things with emulation, sure, but performance (especially single-thread) suffers a lot. I run a few containers where the performance hit really doesn’t matter through qemu.

Ampere has a weird PCIe bug that results in either outright incompatibility or a video output filled with strange artifacts/distortion for the vast majority of GPUs, with the known good selection that aren’t bugged being only a few select Nvidia ones. I don’t happen to have any of those Nvidia cards but this workstation includes one. Other non-GPU PCIe things like NICs, NVMe, and SAS storage controllers work great, with tons of PCIe lanes.

Depends on what you consider self-hosted. Web applications I use over LAN include Home Assistant, NextRSS, Syncthing, cockpit-machines (VM host), and media stuff (Jellyfin, Kavita, etc). Without web UI, I also run servers for NFS, SMB, and Joplin sync. Nothing but a Wireguard VPN is public-facing; I generally only use it for SSH and file transfer but can access anything else through it.

I’ve had NextCloud running for a year or two but honestly don’t see much point and will probably uninstall it.

I’ve been planning to someday also try out Immich (photo sync), Radicale (calendar), ntfy.sh, paperless-ngx, ArchiveBox (web archive), Tube Archivist (YouTube archive), and Frigate NVR.