TL;DR: If you're a Linux user, you probably don't want to pay for Proton VPN (yet).
If you search this subreddit, you'll find a lot of people saying that. However, I thought I'd go into a little more detail. I hope it helps some folks!
First off, let me say: I love Proton, I love their mission, and I'm a (mostly) happy user of Proton Mail, Calendar, and even Drive. I also had a very good experience with Proton VPN on Android. In short, I'm not a Proton-hater (if such a thing is even possible).
I'm writing this because I wish I had read something like it before plunking down my cash for Proton Unlimited. (I upgraded from "Mail Plus" solely for the addition of the VPN. And because I was happy for an excuse to give Proton more of my money, frankly.)
First, a message to the Proton team
I'll just quote my own message from a relevant Github issue:
Sounds like y'all are pretty understaffed and I'm sure it's not your decision directly, but I will say: leaving a clearly half-finished client as the only option for (paying) customers while a new client is in the works -- and scrolling up, this thread has been open for over a year now -- well, I think y'all will start to burn through good will pretty quickly.
My honest suggestion would be: take a pause from the new client development for a month. Squash some bugs. Plug some memory leaks. Make the current client stable and unbroken. (Not talking new features even, just... not broken.) Put it in a decent spot, then leave it to focus on the new client. (And even then, if bugs come up in the old client, I think you have a responsibility to fix them.)
Also, seeing something happen on the current client will make your (paying!) customers feel less abandoned. (Take me for example: as I said, I love the Proton mission, but even I feel like this is a bit of a bait-and-switch.)
And as an addendum: if you're not going to implement actual fixes, please put an asterisk on the Proton VPN marketing copy, be clear about your (lack of) Linux support. Call it a "beta" client, explicitly say which features are not supported. Something, anything.
State of the Linux VPN client: A summary
It's Pretty Bad.
GUI client
No wireguard
No split-tunneling
No port-forwarding
No profiles
Broken search functionality
Slow, unresponsive UI
Lacking basic usability features (e.g. "connect to fastest server that supports P2P", "connect to last server", etc.)
Changing VPN connection state breaks many other applications (including Dropbox, Steam, etc.), requiring a restart
Horrible memory leaks
I've put the memory leaks in bold because it's essentially a blocker. If you leave the GUI client open, it will slowly devour your memory. For me, this usually resulted in a client crash.
Summary: Don't use the GUI client. Like, period.
Command-line client
No wireguard
No split-tunneling
No port-forwarding
No profiles
Changing VPN connection state breaks many other applications (including Dropbox, Steam, etc.), requiring a restart
Takes minutes to establish initial connection
The CLI client is a big improvement over the GUI client. It (mostly) works! You can (e.g.) connect to a P2P- or Tor-enabled server easily, or the fastest server in a given country. Also, it does not hemorrhage memory.
However, its initial connection takes minutes. I can't imagine why. I didn't have this issue with the GUI client. (It's slow, but not that slow.) Note that if you have the kill switch enabled (which you should!), you have no network at all during this time. (By the way: after that initial connection, e.g. if you disconnect and reconnect, it's not nearly as bad.)
Also note that after you're finally connected, many apps that will have started during that time will silently have lost their network connection. (Possibly a kill switch bug?) Dropbox and Steam were two obvious and consistent examples of this for me. This also happens when resuming from suspend, or any time the VPN connection status changes for any reason, manual or otherwise. This is also consistent for me -- happens every time. I do not experience this with any other Linux VPN client.
Summary: The command-line client is way better than the GUI client, but still worse than many other (non-Proton) Linux VPN clients.
Using the provided wireguard profiles
This is a decent possible alternative, but it's a very manual process.
You login to your VPN account on the web, use the provided interface to download a wireguard configuration for a single server, and then you can use Network Manager or whatever you want to connect to that server.
There's no bulk-download option, no way to dynamically connect to servers in different regions based on capabilities or load. This is a downgrade from just about any other VPN client out there. The only upsides are: you avoid having to use Proton's own client and you get support for wireguard (and port-forwarding!).
I considered building some tooling to automate the process of finding the fastest server with a given set of capabilities, pulling down the wg config, and connecting to it. Then I realized: what am I even paying for, at that point? Easier just to use a different provider.
Final note
I'm not writing this (just) to complain -- more for visibility. Both for the Proton team as well as potential users. If I had read something like this before paying for the service, I simply would have continued using my existing VPN and kept my eye out for the arrival of the "new" Proton Linux client at some point in the future.
But finding all this out after-the-fact -- after reading various glowing reviews, marketing copy, and after paying for a subscription -- is enough to leave a sour taste in any user's mouth.
There are two main aspects to coreboot in my opinion that differentiate it from other firmware ecosystems:
The first is a strong push towards having a single code base for lots of boards (and, these days, architectures). Historically, most firmware is build in a model I like to call "copy&adapt": The producer of a device picks the closest reference code (probably a board support package), adapts it to work with their device, builds the binary and puts it on the device, then moves to the next device.
Maintenance is hard in such a setup: If you find a bug in common code you'll have to backport the fix to all these copies of the source code, hope it doesn't break anything else, and build all these different trees. Building a 5 year old coreboot tree on a modern OS is quite the exercise, but many firmware projects are near impossible to build under such circumstances.
With coreboot, we encourage developers to push their changes to the common tree. We maintain it there, but we also expect the device owner (either the original developer or some interested user) in helping with that, at least with testing but more ideally with code contributions to keep it up to current standards of the surrounding code. A somewhat maintained board is typically brought up to latest standards in less than a day if a new build is required, and that means that everybody has an easy time to do a new build when necessary.
The second aspect is our separation of responsibilities: Where BIOS mandates the OS-facing APIs and not much else (with lots of deviation in how that standard is implemented), UEFI (and other projects like u-boot) tends to go the other extreme: with UEFI you buy into everything from build system, boot drivers, OS APIs and user interface. If you need something that only provides 10% of UEFI you'll be having a hard time.
With coreboot we split responsibilities between 2 parts: coreboot does the hardware initialization (and comes with its build system for the coreboot part, and drivers, but barely any OS APIs and no user interface). The payload is responsible for providing interfaces to the OS and user (and we can use Tianocore to provide a UEFI experience on top of coreboot's initialization, or seabios, grub2, u-boot, Linux, or any program you build for the purpose of running as payload).
The interface between coreboot and the payload is pretty minimal: the payload's entry point is well-defined, and there's a data table in memory that describes certain system properties. In particular the interface defines no code to call into (including: no drivers), which we found complicates things and paints the firmware architecture into a corner.
To help payload developers, coreboot also provides libpayload, a set of minimal libraries implementing libc, ncurses and various other things we found useful, plus standard drivers. It's up to each coreboot user/vendor if they want to use that or rather go for whatever else they want.
credit: [deleted] user on Reddit.