dazo
I need to look at that video (thx for the time marker). So my comment may miss his point.
If Linux is so hard, I wonder how Tresorit manages it quite nicely across multiple distros. They use fuse to mount the remote repository.
And the file attributes on files/dirs have a standardised API via libc and kernel syscalls. This is needed for the sync capabilities, to have data locally and in Drive. These APIs are identical across all distributions and are file system agnostic. Otherwise the tar command would have had a really hard challenge to be so widely useful for both file distribution as well as backups.
But I'll catch up on the video later.
I thought a bit more on these complaints since this post. And I realised these complaints can also be ignored by applying some basic mathematics and common sense.
Proton has more than 100 million users by now. So let's say 100 million in this example. How many public complaints would it need to be from these users to really "catch fire"? Meaning - how often do you read about complaints and from how many users? More than 100.000 users? Okay. Let's say there are 1 million dissatisfied users.
If half of that million users complained loudly on the Internet, I would say that would probably be quite noticeable. Media would most likely pick it up, and it would brew up to media storm right?
Have you noticed anything like that? Do you see that many users complaining?
And if yes, that would still only represent 0.5% of the whole user base of Proton. If you include the other half complaining "silently", it would represent 1% of the Proton users.
That still leaves 99% users which are at least to some degree satisfied with Proton.
Even if you pull it up to 20 million dissatisfied users, they would still be in the minority compared to users finding Proton's services being just fine. And 20 million dissatisfied users - that would definitely have caused some media traction, don't you think?
They could even have a Fedora Copr repo, where they push out the updated .spec file and get a proper package build for all Fedora, RHEL/CentOS and more distros. With proper RPM packaging and repository. Push a new build and all users gets an updated package at their next update cycle.
That's a reasonable path to get started with preparing packages to become part of the native yum/dnf repos at least. And that across a lot of distributions and releases in a single go.