
Proton has taken another step toward offering a command-line version for Linux-based distributions. This was announced in early November. They released packages for Debian and Fedora. de ProtonVPN CLIAnd now it's also available on Arch-based distributions (the header image is from Ubuntu, to take advantage of it). With this move, most of the demand would be covered, since Arch is widely used in derivatives like Manjaro, EndeavourOS, and others.
Regarding new features, none are mentioned, but what's coming is: P2P, TOR, and Secure Core for connections, as well as the ability to see all the cities and countries available on our plan. However, in my personal opinion, it still... without it seeming to me the best option, and I explain my reasons.
ProtonVPN CLI is a small package, but it requires many dependencies.
ProtonVPN CLI is a very small package, but it can't work on its own. It requires about 30 more packages when you try to install it on Manjaro, my everyday operating system. At this point, you have to consider whether it's worth having so many extra packages or not. I see three possibilities, including the one offered by ProtonVPN CLI:
- Native system optionI usually opt to use ProtonVPN directly in the KDE network settings, also available in GNOME and desktops that draw from the two previous ones. You can download a profile, install it, and activate the VPN from the system tray. The problem you might encounter here is that reconnections aren't very reliable, but it usually works for me.
- ProtonVPN GUI in flatpak packageThere is a ProtonVPN Flatpak package with an interface, but It is not officialThis interface is based on GTK and works perfectly. There are no connection problems because it's a community version created from the Official versionThe downside of the Flatpak package is that it also installs a few platform dependencies. This isn't a problem if you already use several Flatpak apps, because those dependencies are likely already installed.
- ProtonVPN CLIThe third option is to use the command-line version. Once all features are implemented, this is likely to be the best option, and if we need something truly reliable that consumes few resources, the dependency costs shouldn't be too high.
Everyone should know what suits them best. For now, I'm sticking with the first option, but it's good to see how developers are taking care of us not only with software for us, but also for those of us who prefer to use the terminal.