@josephcox fast rewind 25-ish years back, and there were lots of discussions what to do with .af domains as Taliban was going to disconnect Afghanistan from the Internet.
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.
Proton and Tuta has similar challenges most others don't care about (including FastMail) - End to End Encryption. That itself is a pretty hard nut to crack. FastMail and similar services don't need to think about that, which makes their services simpler.
I would also not claim that Tuta has a quicker development cycle. They had a round recently where more features were highlighted. But that's an exception. I've had a Tuta account for years as well, to test it out, and both the webmail and Android app is still not that feature rich.
And Proton delivers new features and updated apps quite regularly now compared to just a few years ago. Can it be better? Yes, of course. But still, they are doing alot than just 2-3 years ago. And 2-3 years was even better than the years before that.
Also consider that Proton delivers on a broad range of products and services. Mail, Calendar, Drive, Pass and VPN. Tuta basically has Mail and Calendar, where both of these Tuta services being fairly reduced in features still.
My experience (mostly using Mail and a little bit Drive these days) is that Protons releaes are also pretty solid. It's extremely seldom I'm hit by bugs these days. To have that kind of quality requires quite some QA efforts. I'm not claiming the other services are equally good, but Mail and Drive is now very stable - and Mail is especially crucial for my 15-20+ users abd myself.
Finally, Proton serves more than 100 million users by now. Tuta has reached a bit over 10 million, IIRC. That requires Proton to have more staff on support and operations tasks. So even if Proton has more than 400 employees, that's not 400 developers.
I've been in touch with both. I've let Tuta behind. The Proton support was superb. It was delightful to actually be in touch with support personnel actually understanding how e-mail and the delivery mechanisms work. Solved my issues pretty quickly.
But was on Proton business and Visionary plans when I reached out, so the support level expectations are quite higher there.
I dunno. I more often feel people who complain loudest about poor support comes from people who want a specific outcome but gets angry when they don't get what they want and expect. And then let their steam out in social media angling it in a way that they are the victims.
And this trend isn't specific to Proton, but more as a general impression.
The best way to check the support level is to actually reach out to them with an issue and then see how they respond to you.
Give both a shot. Both are the only ones (I know of) having zero storage access as the only option; meaning #e2ee is enforced. You may have mailbox.org as a third one (E2EE must be enabled manually there).
I ended up with Proton as I experienced it far more feature rich, flexible and mature. And the Bridge is a must for my use case. In addition, it builds on PGP which can be used to have E2EE communication with people outside of Proton. (yes, I've tried Mailvelope with Tuta; that does not work at all. And doing it manually with copy/paste and PGP in an ordinary text esitor is a waste of time and also turned out error prone one the receiving end; Tuta mails gets mangled on the way).
But if you're a very lightweight mail user, Tuta might fit your need. I generally think of Tuta more like a messenger service with SMTP transport support.
Also beware, importing mails to Tuta is still not possible (unless that has changed the last months). And exporting mails are also a mess. I have migrated one user from Tuta to Proton, and I had to manually fix mail headers to get them imported. The mail export was quite poor, tbh. It took me longer than importing a handful of users from a Zimbra server to Proton - using the same Proton Mail Import/Export tool.
Finally, I just want to mention that Tuta is a company with less than 20-30 employees, serving something like 10 million users. Proton is probably closer to 500 employees these days, serving more than 100 million users. So these organisations are quite different. Which also means they have quite different approaches for developing services further and capabilities to handle sudden challenges.
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?
I can be pragmatic in many cases, use stuff which works - prefer FOSS when there are real alternatives.
But nvidia ... They deliberately try to get a free pass in #foss with their proprietary driver. The "open source" Linux kernel driver you get from them is essentially just a firmware loader ... Which tries to circumvent the limitations internal GPL export restricted functions have, inside that binary blob.
And that, dear friends, is one of the reasons this driver can make your system end up in crashes ... When it tries to access restricted functions using an expected interface, where an internal kernel interface may have changed sufficiently with a kernel update to break unexpected users of it.
Drivers doing the right thing, typically don't end up in this mess ... Because they use properly public exposed APIs which has a different guarantee to stability. So if that driver is a proper GPL licenced driver, it has access to all the GPL tagged functions in the kernel directly and doesn't need to do this wonky stuff.
And that's why #nvidia deserves to be completely ignored by #Linux users. They deliberately try to access kernel functionality in particularly restricted from their driver - because it's not a proper GPL driver.
#amdgpu's might not be equally good compared to what nvidia can do. But at least, there are real open sourced, GPL based drivers for them.
Thanks to your initial feedback, these include improvements like:
🗓️ Easier access to Proton Calendar
⏩ Easy migration from #Gmail
🚨 Notification badges
🔠 Improved accessibility and font support
First, thanks a lot for your responsiveness. It feels great to keep in touch with my favourite service providers 😁
I'm a Mail Plus user, considering Unlimited, to use VPN. Given the "conflict" with DNS settings when switching on a VPN, how do you see your ad-blockkbg capabilities versus, for example, #nextdns ?
I believe #nextdns might be more configurable, but overall protection level is probably equal to the one of #protonVPN ?
> The curl security team will work on getting this CVE rejected.
Good luck on that. At best, it will be labelled as "disputed".
I would recommend you to become a CNA yourself for curl. The general CVE policy is that any reporter need to first reach out to the appropriate CNA to get a CVE for an issue. A reporter can go to a root CNA too, but only after the project CNA has been reached. And there are some conflict resolution policy if the CNA and reporter disagrees.
It's a bit of "paperwork" and administrative steps to get approved as a CNA. You need to document security policies and processes and show you understand how CVE's are worded and registered. But I would expect curl to be in a good position to get approved.
We did that a while back in OpenVPN. And the tooling (in particular cvelib) makes it pretty easy to register and publish CVEs.