I agree with the author’s sentiment about FIPS 140. I find NIST to be incredibly slow. I understand there must be some stability, but they are too slow. For example, I think it's horrible that they are still recommending PBKDF2 in 2025.
A big part of the problem I have with it is that it's a "ceiling" on security. Things like electrical code or building code are a "floor" on quality, you have to be at least as good as the code requirements, but can freely be better. FIPS-140 bounds you both ways. If you could more easily do better it'd be much less of a problem that NIST are slow.
I don't love FIPS either, but cryptosystems don't work the same way as buildings and electrical codes. It's very easy to have "secure cryptosystem A" and "secure cryptosystem B", and then have massive security holes in "cryptosystem A + B". This happens all the time, and is one of the main reasons for the classic "don't roll your own crypto" admonition. The FIPS "whole system" mandate is meant to forestall this failure mode.
Even in building and electrical, just because B is better than A does not mean it’s allowed.
IIRC the first wago parts (221) were UL-listed in 2017, the 221 were released in 2014, and the original push-lever splices (the 222) were released in 2004.
In fairness, it's one thing for an implementation like a building to be as over-enginereed as possible in its own right, but it's another when a standard has to ensure that multiple implementations can interoperate. I'm not saying FIPS-140 has only that kind of limitation (far from it), just that this isn't the best analogy.
Yeah, there's a ton of correctness testing involved. That's mostly at the algorithm, rather than the module level, so it'll fall under CAVP/ACVP rather than CMVP.
That's not for interop, that's for "are you actually doing the crypto you said you'd do". It's designed to prevent broken crypto, not to ensure coordination between parties.
An old but not widely known fact – particularly problematic in machines with hardcoded OEM keys like most laptops, as the app history will still be visible to new owners purchasing the machine even after reinstalling Windows.
I've had a good experience with JavaFX and I even managed to AOT compile two faily complex applications of mine. My advice would just be to stay away from FXML. Also use jlink to build a stripped down JRE for your application and package it with jpackage.
> It is designed by academicians who thought clever looking choice is better.
That's just not true. That's the typelevel ecosystem. The official Scala toolkit mostly includes haoyi libraries which is pretty much Python like Scala.
It's the main reason I never liked .NET and I feel like a lot of .NET proponents suffer from Stockholm syndrome.
The argument that having few options would actually be a good thing is so absurd.
The only reasonable explanation I have is that he got flagged by Snapchat automatically who reported him to the authorities immediately. Even without E2E encryption, how would they intercept the message as the app is most likely communicating with the server via HTTPS or SSL?
I've tried it and didn't like it at all. It's a memory hog, start-up times are horrendous, I've had lots of glitches on MacOS and I detest XAML. Overall it really feels like yet another alpha state product.
Besides, I'm not really keen on using Microsoft products. Right now I have big hopes for Iced on Rust.
MS Teams devs obviously feel the same as they didn't bother using any of this stuff (Maui, Avalonia, Xamarin). I get the sense the Microsoft groups developing these technologies are suffering from MIC (Manager is Customer) syndrome.
It's super fast if you use Native AOT. My entire application starts up in 0.3 seconds, that includes Avalonia and all my code too. It does use more memory than I'd like though, about 200 MB.
>We use Avalonia for our Product and honestly couldn’t be happier.
What do you mean "couldn't be happier"? Start-up times and memory consumption are objectively bad. Also something someone else already mentioned in here: font rendering just feels really off.
>On desktop (Apple M2) it pretty much feels instant to me.
Why are you lying? It's not quick, let alone "pretty much instant". Neither on my M3 nor on my gaming machine. Actually I think Avalonia's start-up time is the worst out of all GUI frameworks I've used so far, including Electron.
