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.

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.

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.

The common issues with RISC-V laptops, or rather any laptops made with SoCs that weren’t designed to be laptop-first, include things like sleep not putting the system in a low enough power state (battery will run out if you leave it folded without turning it off), underwhelming GPU, higher power draw when idle, and lower peak performance for intermittent load. If none of those are a dealbreaker, the newest DeepComputing Framework board (on K3) can arguably be considered a viable daily driver RISC-V laptop option, though I wouldn’t want to use it as one.

Nvidia, AMD, and Intel are the big names for GPUs and they all have products that integrate a GPU into the same SoC as the CPU, but none of them would be likely to license out their GPU IP to other SoC vendors in modern times. Same goes for the in-house GPU designs for Apple/Qualcomm/Samsung. ARM does license out its Mali GPU IP, and that’s often the go-to option for SoC vendors that don’t have their own in-house GPU, but RISC-V systems can’t use that. So RISC-V systems’ GPU options effectively amount to either:

1. Use separate processors for your CPU and GPU. Desktop/server can just slot in a video card. Laptops in the 15-inch or larger space often solder a GeForce or Radeon chip to the board. Smaller 13-inch laptops normally don’t do this because of cooling and battery life concerns.
2. License the integrated GPU from Imagination. That seems to be the only notable GPU offering available to license on non-ARM. Users don’t seem very fond of Imagination GPUs but they’re better than nothing.
3. Pray that one of the companies with an established GPU portfolio decides to not only enter the RISC-V space but also makes a RISC-V processor that can be used in laptops. I think that’s unlikely and they’ll probably focus on server only.

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.

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.

This board has the StarFive JH7110 SoC. That processor has previously been in very low power single board computers like StarFive VisionFive 2 (2022) and Milk-V Mars (2023), a Raspberry Pi clone that can be bought for as low as $40. Its storage limitations (SD/eMMC rather than NVMe) show how much this isn’t meant for laptop use.

Very underpowered for a laptop too, even when considering this is intended for developers and doesn’t need to be remotely performance competitive. Consider that this has just 4 RV64GC cores, the cheapest Intel board options Framework offers are 12 cores (4P+8E), and any modern RISC-V core is far simpler with less area than even an Intel E core. These cores also lack the RISC-V vector instructions extension.