CompCert VS mullvadvpn-app

A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.

Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.

But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.

[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"

Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".

However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.

From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.

[1]: https://compcert.org/

CompCert sends its regards

But that's fine, because we can do even better with things like the CompCert C compiler, which is formally proven to produce correct asm output for ISO C 2011 source. It's designed for high-reliability, safety-critical applications; it's used for things like Airbus A380 avionics software, or control software for emergency generators at nuclear power plants. Software that's probably not overly sophisticated and doesn't need to be highly optimized, but does need to work ~100% correctly, ~100% of the time.

For context, CompCert is a formally verified compiler. My former advisor helped with a fuzzer called CSmith which found plenty of bugs in GCC and LLVM but not in CompCert.

Does anybody know how does this compare to https://compcert.org/ ?

This is a common property for proof-oriented languages. Coq shares this property for instance, and you can write an optimizing C compiler in Coq: https://github.com/AbsInt/CompCert .

* Mozilla VPN: wrapper around https://mullvad.net/ (and had security issues: https://www.techradar.com/news/security-audit-finds-major-is...)

hey there, after doing some research it seems like the conclusion is your vpn. Nord VPN has a lack of port forwarding, while other vpns have port forwarding (proton, mullvad). that is most likely interrupting your speed. also, apparently nord does keep some sort of logs if your interested in that. i would recommend cancelling nord and getting something else like proton or mullvad (i would recommend proton more) if you really want to download movies/shows. another option for you (if you dont want to switch) is to find your movie on websites that don't require a vpn (aka not torrenting) but you can if you want to. you can use this for that, they have tons of movies and shows. or just use a streaming site off of the megathread.

The 500 MiB thing is because the frontend is an Electron app. That's sadly how it is with Electron. The UI can of course be re-written into a language/framework that produces way smaller programs, but it's not currently really worth the tradeoff. Most people are not that constrained in disk or internet speeds. https://github.com/mullvad/mullvadvpn-app/issues/1572

The downloads folder access thing is because Apple made it so. If you run an installer from the downloads folder it will need access to the downloads folder. This has nothing to do with Mullvad, but is a permission check macOS puts on all software. The Mullvad VPN app has no code for doing anything in the Downloads folder specifically.

Requiring an account for search is a deal breaker. They say they need it for payment, but mullvad[0] does just fine without an account as well.

[0]: https://mullvad.net/

From this post: https://github.com/mullvad/mullvadvpn-app/issues/1570

I don't understand why the .rpm package of Mullvad VPN still only officially supports Fedora. This issue on GitHub has been open for almost three years now and there is even someone else trying to help you making the necessary changes to support openSUSE in this PR. I kinda agree with cornfeedhobo's sentiment that the necessary changes to make it work on openSUSE are being gated. I'm a paying user for quite some years already and made the switch to openSUSE and I'd really like to continue using Mullvad VPN there without having to force install the .rpm package and thus living with a lot of uncertainty about how well it will run.

It's just a false-positive. If you're still wary, feel free to review the source code of the app and you can even build it yourself: https://github.com/mullvad/mullvadvpn-app/