Some years ago, I evaluated Protonmail as a replacement for my personal gmail account.
When came the steps "can I easily move from this service?", I realized you have to _pay_ to export all your emails from the service. They make it super easy for you to open an account and receive emails, and then makes you pay if you want to get a copy of your own data.
I contacted the support to tell them it is likely illegal under European Data Privacy laws. They replied I can still export email for free one by one if I wanted to... (which is obviously not a valid answer when you have 5000 emails)
Then I looked in Swiss laws for a similar clause, and found that Swiss laws doesn't give users of online services the right to easily and freely get a copy of their data. It was a law proposal at the time of my research.
So yeah... Your data is so secure in Switzerland that you don't even own your data !
I see it as a way of getting paid for the development of services. People willing to pay for an offering are more likely to provide quality feedback. Once it is stable there and dev time has been recouped, you can offer it to the free tier.
I actually don't have an issue with that. Once it is available to free tier users, it frees up the devs to go to the next item on the list once again only available to the paid users. Lather, rinse, repeat. Sounds like a fairly sound bizplan.
> I see it as a way of getting paid for the development of services.
The obvious reason is that a company has an incentive to make it easy to onboard and no incentive to help you migrate off or even an incentive to make it difficult or costly to leave. I don't see how making import/export something only a payed tier has is specifically or especially for funding development. It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
Do you not agree that the types of support requests or other feedback from the masses in the free tier tends to be of a much lower quality than you might get from a paid user? The expense of supporting those requests are not insignificant. By ensuring that the product is in a much more stable state before reaching the free tier can help keep those support costs lower.
>It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
Yet here we are on a dev centric forum talking about it being a "bad" decision. From a dev perspective, the decision of starting something in a paid tier then (if ever) releasing to the free tier is not offensive to me. A company offers a free thing that has fewer features than a paid tier, "news at 11" type of story it is not. Doing poor research into the limitations of the free tier and complaining publicly about not having access to the paid features on the free tier is also not news worthy. Again, yet, here we are.
Hey Dylan I saw your comment on USPS api. I am very much unguided on how to use it. Can you please email me? I don't know how to use it and I even called them, no luck! Please email me.
--impetus1 a t protonmail(dot)com.>
Good. If you want to pay with your personal data, use gmail. If you want to keep your personal data, then pay the people who run the service with actual money.
Briefly looking at the files and code it's hard to tell whether that is still the case, but it's fair to assume Import-Export would reuse most of the machinery behind Bridge.
bridge exposes imap making it easy to download all your data using Thunderbird or another client. I don't know about "export" because imap does what I want and is supported by most providers in the same format.
For those who care about OSS and moving to Protonmail from bigcorps email, this _might_ matter, although I think that for the majority of Protonmail users (which doesn't care much about open source), it doesn't matter.
Try harder. You can run their bridge to expose imap and use any client to export your emails. Also, your info from "years" ago is out of date as they are a small company that has been working on product/features all those years.
Their point was about having to pay to export your data. Afaik Bridge is still to this day only available to paying users. Still, their statement is no longer true since exporting in bulk is permitted for free with the Import-Export app.
It's artificial scarcity, which to me is immoral, but it is what it is.
In your example, you have the choice not to buy the license. In the case of Protonmail, they already have your emails, and are already serving them to you, so holding your correspondence hostage if you want to export it all in one go is a bit of a dick move.
that's obviously a strawman. What's being critized is the heroin-dealer model of doing business, i.e. "the first dose is free" but you'll be locked in, which seems increasingly popular among a lot of services that try to compete with the big players.
no because the comparison is in the mechanism of luring in customers, not the substance or the price. We can go with any commodity you feel comfortable with if that improves the analogy for you
These things suck, though. The way they protrude from the USB port makes the phone awkward to carry around, and they prevent charging the device while using a headset.
You can buy adapters that pass through power and also have a 3.5mm jack - I have one of those and find it even flakier.
Same, I have been using snap to run Firefox and Chromium for about more than a year (personal usage, not professional), and rarely had issues. I had one issue regarding a feature like WebGL or a file picker, but it was solved after 5 minutes of googling, and it was about running a single command line to give more permissions to the snap package. This way of distribution works quite well for big applications with many dependencies that you want to be automatically updated without fear of breaking some shared libraries.
I also feels more confident trying new applications with snap. I know I can easily install different versions and uninstall them without breaking the system.
Question regarding Fedora : I tried it in a docker environment. During some googling to troubleshoot issues, several results were found on the Red Hat commercial support website (so, not accessible). I'm afraid that a good part of advanced/niche documentations and knowledge base for troubleshooting is behind Red Hat commercial support. Is that the case in practice?
Fedora has official docs (https://docs.fedoraproject.org/en-US/docs/), and in practice I've never had a need for the commercial RHEL support. Honestly, I've been using Fedora for 3 years now and can't even remember the last time I had to dig into the docs to troubleshoot something.
I'm a power user and have been using Fedora for over 10 years. I'd highly recommend it, and I don't recall ever getting the feeling that the support/info I needed was gated behind commercial RHEL.
I faced the same problems with some of RH's other software. It felt like they make software needlessly complicated and then hide the troubleshooting information behind paywalls in the hopes of landing support contracts.
"The amendments to this article will make it sound as follows: The Republic of Belarus excludes military aggression from its territory against other states."
Either Lukashenko will tell Putin to remove Russian troops from Belarus, or Lukashenko is breaking the new constitution of his own country.
SIMD instructions as we know them today do not make a consensus among the actors and architectures. See : https://www.phoronix.com/scan.php?page=news_item&px=Linus-To...
That makes them harder to implement in compilers and in turns to democratize SIMD.
Extract : "[...] the addition of SIMD instructions has led to an explosion in the number of instructions, especially for x86. And of course not every x86 processor will support all these instructions. Only the newer ones will support AVX-512.
The beauty of SVE is that the same code will work for both the super-computer and the cheap phone. That is not possible with the x86 SIMD instructions."
It's indeed nice that SVE2 binaries can run on differing HW, and fragmentation will be less because it's required in ARMv9.
> the same code will work for both the super-computer and the cheap phone. That is not possible with the x86 SIMD instructions
Actually, when the code is expressed using "portable intrinsics" (https://github.com/google/highway), the source code looks the same but compiles to SSE4/AVX2/AVX-512 and NEON,SVE,SVE2 and RISC-V V instructions.
It's a solved problem there, have profiles : "Low", "Medium", "High", "Ultra High".
They allow for a quick start, then as the user is more aware of the feature, the user can tune the predefined profiles themselves.
You can have independent profiles for each independent feature : input profiles (keyboard/gamepads), graphics profiles, audio profiles, etc
For example, on a Google account, that would be a single drop down list with those options: "Private and no personalized experience" (everything turned off), "Private with personalized experience", "Public"
Good reading ! It would be interesting to have other similar challenges, such as Euler, solved in idiomatic Tensorflow and Pytorch. Also some examples of more complicated state-of-the-art algorithms, such as sorting/graph/trees algorithms reimplemented in these frameworks.
It would be a great introduction to these frameworks for people who never touched anything ML-related, leaving the neural network content to later in the learning process.
Learning how to create differentiable algorithms and neural networks would be easier once the way those frameworks work is understood (ingesting data, iterating dataset, running, debugging, profiling, etc).
If you are starting with neural networks or differentiable programming, learning both the maths and the frameworks at the same time can be quite overwhelming
HN's Point of View doesn't represent the PoV of the 1 billion active iPhone owners.
Most people won't have any idea about the meaning of "hashes" and "databases". Not everyone is trying to actively fight the system and shit on everything, most people just want to live happily with their friends and family, they won't care that Apple scans their devices.
> "Either there will be heads rolling at management, or Apple takes a permanent hit to consumer trust."
Oh god ! How wasn't all of this obvious to the top Apple management, but so obvious to epistasis! Damn, thanks man for correcting and leading Apple to the right track !
