I bought a Milk-V Mars (4GB version) last year. Pi-like form factor and price seemed like an easy pick for dipping my toes into RISC-V development, and I paid US$49 plus shipping at the time. There’s an 8GB version too but that was out of stock when I ordered.

If I wanted to spend more I’d personally prefer to put that budget toward a higher core system (for faster compile times) before any laptop parts, as either HDMI+USB or VNC would be plenty sufficient even if I did need to work on GUI things.

Other RISC-V laptops already are cheaper and with higher performance than this would be with Framework’s shell+screen+battery, so I’m not sure what need this fills. If you intend to use the board in an alternate case without laptop parts you might as well buy an SBC instead.

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.

I’m not completely sure but I think they removed it at some point after the public backlash (which was 3 years ago now). For the Windows version at least, there apparently used to be an option during the installation wizard for setting whether telemetry is enabled or not. Most Linux distros never had the telemetry at all. I don’t know about Mac.

It is open source, but had some controversy. Most prominently the addition of telemetry a few years ago, which was never included in the builds managed by Debian or most other distro maintainers. They also added a Contributor License Agreement which lets the Audacity project change its own license (even to a non-foss one, though they promise they won’t) without needing to have the change approved by any individual developers.

Even their earliest “uncarrier” features weren’t without issue. Making certain services (spotify, apple music, youtube, netflix, etc.) not count against subscribers’ data caps, while continuing to enforce data caps for other uses, goes against the spirit of net neutrality. This also includes throttling video streams by default to force lower quality (with opt-out on their site).

Promos like a free pizza on Tuesdays seems like a neat optional perk on the surface but their existence fundamentally mean subscription expenses on cellular network service are partially going towards things that have not even the slightest tangential connection to the service.

It is a Linux machine. Runs a Debian derivative, and it’s not like Windows or anything else that isn’t Linux/BSD can run on a RISC-V laptop.

This isn’t the first RISC-V laptop, but the significance of a RISC-V laptop existing is primarily for developers who work on software targeting RISC-V systems. The ability to run RV64 programs without emulation and to natively compile RV64 software without cross-compilers is valuable to some people. Also, China in particular sees value in having computing products that aren’t affected by sanctions; the processor in this is designed and manufactured by a Chinese company without licensing any intellectual property from US or UK.

I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don’t use “zero access” encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn’t help them avoid lock-in impressions either.

I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.

In transit, yes, but not end-to-end.

One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton’s servers never have access to the message contents for even a moment. When incoming mail hits Proton’s SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient’s public key and storing it. That undermines Proton’s promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won’t bother doing that key exchange and almost no automated mailers would.

Some standard way of automatically asking a mail server “Does user@proton.me have a PGP public key?” would help on this front as long as the server doesn’t reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn’t give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.

They say the reason for needing their bridge is the encryption at rest, but I feel like the better way to handle wanting to push email privacy forward would be to publish (or better yet coordinate with other groups on drafting) a public standard that both clients and competing email servers could adopt for an email syncing protocol for that sort of zero-access encryption that requires users give their client a key file. A bridge would be easier to swallow as a fallback option until there’s wider client support rather than as the only way.

A similar standard for server-to-server communication, like for automatic pgp key negotiation, would be nice too.

Still, Proton has a easy to access data export that doesn’t require a bridge client or subscription or anything. I think that’s required by GDPR. It’s manual enough to not be an effective way to keep up-to-date backups in case you ever abruptly lose access but it’s good enough to handle wanting to migrate to another provider.

Compared to simplelogin (or proton pass aliases, addy, firefox relay, etc), one other downside of a catchall is in associations across accounts. Registering with a @passmail.net address implies that I use Proton; registering with random-string@mydomain.org implies I have access to that domain. If 10 data breach leaks have exactly one account matching the latter pattern then that’s a strong sign the domain isn’t shared. If one breached site has my mailing address, my real identity can be tied to all the others.

The problem with those TV apps is DRM. All the major streaming services require that you either use a locked down platform (probably checking SafetyNet and more on Android TV) or settle for their browser UI which lacks dpad support and gets quality throttled to 1080p or lower.

Circumventing that DRM is possible, but no project at the scale of a platform like those would dare the both legal risk and support headache of making those circumventions (which are very liable to break) a core part of the OS.

Kodi (and distros using it like LibreELEC) exist for people who want a FOSS platform for using non DRM encumbered media with a TV remote interface.

Likely reversing a major anti-consumer decision is nice, even if it took seven years.

Knowing that consumer protections repeatedly flip back and forth every time the executive branch switches political party, and even then only if we’re lucky, is not so reassuring. What’s stopping it from being repealed again in a few years?

Every single other browser is Chromium.

One exception I’m aware of: GNOME Web (aka epiphany-browser) uses WebKitGTK, which is based on Apple’s WebKit rather than Google’s Chromium/Blink. But it’s Linux desktops first and foremost. Not on mobile platforms, not exactly intended for Windows (might be usable with Cygwin/WSL) or macOS (seems to be on MacPorts) either, and even on non-GNOME desktops like KDE it might seem a bit out of place.

I daily drive Firefox but Epiphany is my first choice fallback on the rare occasion I encounter a site that’s broken on Firefox.

The passive adapters that connect to DP++ ports probably still rely on this HDMI specific driver/firmware support for these features.

If you’re planning to subscribe to Proton Unlimited or Proton Family regardless, you might as well try Proton Drive. They try to be fairly privacy focused similar to Proton’s other products.

Mega has a similar privacy-oriented design. Such that the server side shouldn’t have direct access to your unencrypted file data or its decryption keys.

Still, any web-based service necessitates trusting the JavaScript you receive not to leak out your password or keys. Both Proton and Mega have a good track record so far in that regard, but the best practice for privacy with raw data storage is to encrypt your own data with local tools and treat any remote server as untrusted.

I would not count on all major distros maintaining support for processors as old as Core 2 forever.

RHEL 9 in particular (and by extension CentOS Steam, Alma, Rocky) already dropped support for all of the processors affected by this breakage since 2022.

Linux systems often group these CPU feature set generations into levels, where “x86-64-v2” requires SSE4 and POPCNT (Nehalem/2008 and newer) and “x86-64-v3” requires AVX2 (Haswell/2013 and newer).

Ubuntu and Fedora are already evaluating optimized package builds for both v2 and v3 but haven’t announced any plans to drop baseline x86-64 yet; I wouldn’t be surprised to see it happen within the next two years. Debian is a relatively safer bet for old hardware.