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.
this post was submitted on 12 Sep 2024
155 points (99.4% liked)
Proton
5240 readers
135 users here now
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.
founded 1 year ago
MODERATORS
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.
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.
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
That would be my dream.
Maybe build something off of FUSE?
Fuse is what runs appimages right? Does it run other things too?
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.
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.
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"
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?
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.