Google doesn’t even have a motive to try evading this. Legally mandating that they collect user IDs means that they get to collect more personal data under the guise of compliance, and can also market the increased privacy invasion as a “child safety” feature.

ChromiumOS doesn’t need to comply, according to the current bill, but Google has no reason to ship it preinstalled on any consumer devices.

Mir is a pretty notable example. In 2013, around the same time development on Wayland sessions was picking up for the other desktops, Canonical decided to try doing their own incompatible thing and designed their own display server system to replace X for the then-upcoming version of their Unity desktop.

Ubuntu switched from Unity 7 to Gnome 3 before Unity 8 and Mir were ready, leaving both projects abandoned by Canonical and handed off to the community. Long after it had already lost what little relevance it had, Mir eventually was converted into a Wayland compositor.

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.

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.

RISC-V is designed to be an extensible instruction set, where the base is very minimal and reduced but a plethora of extensions exist. The ISA can be small for academic and microcontroller uses, large (more than a hundred extensions) for server uses, or anything in between.

Despite the name, a powerful RISC-V server can arguably not be considered “RISC”, though that term doesn’t have a single agreed-upon meaning and some design characteristics strongly associated with RISC still apply such as limiting memory access to dedicated load/store instructions only rather than allowing computation instructions to operate on memory.

Also, not everything is CPU instructions. Acceleration for media codecs, for example, normally means off-loading those tasks to the GPU rather than the CPU. Even if the CPU and GPU are both part of the same SoC, that doesn’t touch the CPU instruction set.

In the first place, consider why you even want to switch to RISC-V. If it’s because of an enthusiasm for open-source and hearing the ISA described as open, know that any performant hardware you’ll get likely won’t be as open as you expect. The SoC won’t be open-source, the CPU cores in it won’t be open-source, the firmware and bootloader might be an open-source u-boot fork but there’s a good chance it’s proprietary. Even the actual implemented ISA won’t be open since major core designers add custom instructions that aren’t part of the RISC-V spec.

Distros like Ubuntu and Fedora seem slated to treat RISC-V as a main architecture that has close to the same number of packages and the same update schedule as x86/ARM by the end of next year, if not sooner. Just like is also the case for ARM, proprietary software like games can run with a nontrivial performance overhead, and other binary software distributed through other channels outside the distro repos (like docker containers, third-party apt/yum repos, or appimage) is often only distributed for x86 even for things that are open-source and can be compiled for other arches without issue.

The software situation can be either a major annoyance or completely seamless depending on how closely you stick to just the distro repos.

Hardware vendors will probably have stuff comparable enough to recent Intel/AMD for desktop in about a year from now. Likely not better, but within the same realm at least. Within another couple years after that you’ll almost definitely see more than one of the established major SoC vendors (like Qualcomm, Nvidia, AMD, or Samsung) release something RISC-V in the desktop, server, or mobile space, which is sure to be competitive with x86 and ARM hardware in that space.

Laptops might not see anything good. An alternate ISA can be viable on servers and mobile (both being Linux-first ecosystems), and desktop can easily inherit from stuff made for server, but laptop has unique hardware needs and the market isn’t there for vendors to bother investing too much R&D on laptop chips that can’t run Windows nor Mac. RISC-V laptops do exist but they’re basically taking chips designed for SBC/edge and throwing them in a laptop shell, with the result naturally being awful at power draw since it was never meant to be a good laptop chip, and the iGPU situation is a mess too. That’s unlikely to change in the next few years.

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