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
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.
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.
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”
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.
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.
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.
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
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).
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.
Not sure what’s the chicken and what’s the egg here but maybe they didn’t know how much work would have to be done and thus how much money it would cost.
But it’s all just speculation and neither am I trying to defend them nor do I have a use case for this particular feature. I just wanted to interject a different possible scenario.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !protonprivacy@lemmy.world
Empowering you to choose a better internet where privacy is the default. Protect yourself online with
Proton Mail, Proton VPN, Proton Calendar, Proton Drive. Proton Pass and SimpleLogin.
Proton Mail is the world’s largest secure email provider. Swiss, end-to-end encrypted, private, and free.
Proton VPN is the world’s only open-source, publicly audited, unlimited and free VPN. Swiss-based, no-ads, and no-logs.
Proton Calendar is the world’s first end-to-end encrypted calendar that allows you to keep your life private.
Proton Drive is a free end-to-end encrypted cloud storage that allows you to securely backup and share your files. It’s open source, publicly audited, and Swiss-based.
Proton Pass Proton Pass is a free and open-source password manager which brings a higher level of security with rigorous end-to-end encryption of all data (including usernames, URLs, notes, and more) and email alias support.
SimpleLogin lets you send and receive emails anonymously via easily-generated unique email aliases.
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.
@abobla
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.
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”
I wish they’d at least start by creating an API. Then at least we can use rclone without all the reverse engineering.
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.
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.
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 :)
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.
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.
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.
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
That would be my dream.
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.
deleted by creator
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’m not skilled enough to be able to speak to that.
Maybe I’m in the minority, but all I need is a fuse plugin. I don’t need specific syncing like a OneDrive/Google Drive app.
Why not use rclone? It can mount proton drive.
I agree, the reasoning seems rather outdated. Flatpaks are pretty good.
I always see people asking for it, but I guess we’re actually the vocal minority in this situation.
So few that they’re going to spend more money on it than they will make.
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.
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.
Not sure what’s the chicken and what’s the egg here but maybe they didn’t know how much work would have to be done and thus how much money it would cost.
But it’s all just speculation and neither am I trying to defend them nor do I have a use case for this particular feature. I just wanted to interject a different possible scenario.