Proton CEO comments about proton drive client for linux
Proton CEO comments about proton drive client for linux
One redditor asked about it on the most recent AMA:
Hi, is there a plan to release protondrive for linux?
Proton CEO's answer:
We're currently looking at options for how to fund this. It's an expensive development because Linux has so many different flavors and we need deep integration with the filesystem, and it is not yet clear if there are enough Linux users that would allow us to offset the cost of this development. Like many things Linux, it may eventually just have to subsidized from Proton's reserve budget. That doesn't mean it won't get done, it will just take longer since we are also subsidizing several other efforts at this time, such as the Proton VPN free servers for elections campaign: https://protonvpn.com/blog/free-servers-before-elections
-Andy
Source: https://www.reddit.com/r/ProtonMail/comments/1ff211y/comment/lmrdepr
It's unclear that they need to handle a specific flavor when they could release a Flatpak. I think the community wouldn't have any problem tweaking the dependencies for particular distros.
It wouldn't be the distribution method that is challenging, it's the complicated task of monitoring your filesystem for changes, and working with a dozen or so different file systems to do it (the way it's accomplished on an ext4 partition might not work on btrfs, for example).
I agree, the reasoning seems rather outdated. Flatpaks are pretty good.
Flatpak is not the answer here. For example, flatpak version of codium doesn't recognise terminal settings out of the box. Since such trivial thing is a problem, image how difficult it would be to use it with various file systems, sync options, etc.
I always see people asking for it, but I guess we’re actually the vocal minority in this situation.
lemmy usually asks more in proportion to it's userbase, but I saw a lot of people asking for Standard Notes on reddit during the AMA.
Permanently Deleted
Would it help them to just pick a single distribution, open source the client, and have the community figure out how to build for other distributions?
Edit: also, part of the reason there aren't many Linux users is because there's missing clients Edit2: they wrote this in the AMA: On your first question, we are in touch with the rclone dev working on Proton Drive integration and they have our API specs and documentation, and we're available to answer any questions that they might have
Yeah I agree, package it once and let the community do the remaining work. I believe that's how steam was introduced to Linux, I don't now where we are currently.
ProtonDrive bridge (like they have for Mail), that handles the encryption, that exposes a localhost webdav endpoint that can be mounted.
This would be a pretty reasonable comprise in my opinion. Works like mail bridge (maybe calendar could get some love too?) And everyone is happy.
It's not fancy like an automatic folder sync thing, but at least I could mount a Protondrive directory and do my own syncing myself (I'm a Linux nerd afterall). There is no need for "deep filesystem integration" as he claims.
The same thing could be used for Calendar with Caldav feed as well. A single "Bridge" app could me made to handle Mail, Drive, Calendar
Maybe build something off of FUSE?
Fuse is what runs appimages right? Does it run other things too?
FUSE is a way to present a filesystem to the operating system without writing kernel level code.
I really don't blame them, security and privacy minded folk are more likely to use niche configs. Feels like for Linux stuff companies may be better served making APIs and letting the community handle it. Rclone for example implements a bunch, and last I knew had an unstable Proton plugin.
I wish they'd at least start by creating an API. Then at least we can use rclone without all the reverse engineering.
Huh, as a Linux user who puts up with Proton's unwillingness to support Linux, to me this seems to he saying "Stop paying for Proton until they make Linux clients"
6 months ago he said: "We want to, but we can't find Linux developers."
Well maybe they found them and they told him what he’s saying now?
Seems like they would first look if there is enough money and enough users to make it worthwhile, and then go looking for developers.
Don't get me wrong, i have been a paying client for many years and really love the products and the company, but everything they say about linux... I don't know, this just sounds like an excuse to continue to prioritize other things and get the linux users off their backs for a while longer.
Ship an appimage or something, use basic fs abstraction to create an encrypted blob, do whatever you want within said blob.
Look at virtualbox or something for inspiration.
Look at xdg desktop portals for transfering files.
Could they just integrate with rclone? That would at least handle some of the layers.
Or even avoid all of this discussion and just make it in FUSE?
@abobla Thanks for telling us why the delay for a Proton Drive client!
no problem :)
I kinda struggle to believe it's that difficult. I mean, Tresorit has a pretty good and functional Linux client. What have they done which makes it sustainable for them?
Filen.io also has a pure sync-client, which is distributed as an AppImage. This also works, but the FUSE integration Tresorit provides is quite awesome and performing quite decently.
I would actually recommend Proton to start the development on an older Linux distro. Like RHEL/Alma/Rocky 9 or Debian 11 (which is EOL, though) and make it run there. Moving from that distro to newer distros will then go smother and you'll get other distros supported quicker.
The mistake too many Linux efforts does is to take the "latest and greatest" distro version - often coupled with what a single Linux developer considers the "most used distro" and then hits lots of challenging when needing to support older distros. That's going to be painful.
@protonprivacy Please take note and forward to Andy and other managers.
Synology also has a functional Linux client.
The problem isn't possible dependency conflicts, it is file mamager integration. GNOME and KDE use different systems for integrating online systems with their file managers and obviously both need to be supported. FUSE could work but telling from my experience with NTFS3 it would be unbearably slow.
That's a shame. I was actually holding off on getting unlimited until there was a native client. I was just last week testing Celeste from flathub and it works but is kind of limited and I would very much prefer an official client.