They have price limits, but I think GP means volume alert limits. Someone unexpectedly bids a third of the Finnish production capacity, you call them and ask if they are sure.
There are many market participants, some of whom start trading on this information immediately. The Finnish grid is connected to the rest of Europe so a market participant could in principle flow this cheap energy from Finland all the way to Spain if the cables had capacity. I would guess it was too late the moment it happened.
You don't even need to worry about what someone can physically provide. All bids by market participants can (arguably should) be checked for extreme outliers. A bid of multiple GW from a participant that usually only trades hundreds of MW should immediately set off alarms. It only takes a phone call like "hey, are you sure about this?"
With Zig and Rust you have to explicitly opt-out with `ReleaseFast` and `unsafe` respectively, that makes a big difference. Rust has the added safety that you cannot (to my knowledge at least) gain performance by opting out with a flag at compile-time, it has to be done with optimized `unsafe` blocks directly in the code.
Lazy C++ is unsafe, lazy Zig is safe-ish, lazy Rust is safe. Given how lazy most programmers are, I consider that a strong argument against C++.
> Performance topped out at 111 MiB/s (931 Mbps), which is suspiciously close to 1 Gbps.
That's because of overhead in TCP over IPv4. You're testing the payload throughput, not the physical throughput. The theoretical maximum performance without jumbo frames is around 95%.
Moore's law is about transistor density, not single-core performance. Even if a new generation of chips obeys the "law", there is no requirement that the designers dedicate the improvement to single-core performance. Alternatives include multi-core performance and miniaturisation.
That is fair, I suppose, but why use a different DNS server than the default for your home network? I still think there's something fundamentally wrong with a DNS configuration that breaks Windows connectivity tests.
I do hope you're using something encrypted. Plain DNS can be redirected and manipulated quite trivially.
> That way any other people on his network wouldn’t have a problem, either.
Given that he's setting DNS servers statically on his own clients and has working DNS resolution on the DHCP-provided DNS server(s), that shouldn't really be an issue for other people.
While the project is super interesting, this seems like network horror to me. Not only is something "wrong" with the network (guessing dns.msftncsi.com is blackholed), the author is setting DNS servers statically on his clients instead of using DHCP. If I'm right that the domain is simply blocked, I think it counts as yet another horror that the author did not realise that before buying a replacement WiFi card. It pains me that the blog post never explains the root cause of the issue nor whether it was intentional.
File access should, by its very nature, be asynchronous. If you're only introducing asynchronicity to support Flatpak portals, the original code was flawed.
You could also argue the reverse: if synchronous file access was good enough before, there should be no real reason not to use Flatpak portals synchronously as well.
As a human-readable configuration language, YAML probably beats JSON and XML, but the implicit typing rules in the spec make it horrible to work with. I've written a lot of YAML for Ansible and it has some awful footguns.
That much is obvious. The blog post has an example of something that appears to be non-breaking (at least it would be in many other languages), but actually does break things. Both the library creator and user messed up in the example given, but if you're not intimately familiar with the language, both mistakes seem reasonable.
That is not a realistic scenario. Firstly, there's no waking up to find your server is unresponsive. It's part of the deal when you sign up. Secondly, public IPs are always an option. Thirdly, the ISPs I have used have always had relevant FAQ/help articles.
If any of those points do not apply to your ISP, that's not because of CGNAT, it's just a shit company. I've used four different ISPs in the past four years and getting rid of CGNAT has not been a problem once. IIRC only one of them used public addresses by default, two offered free dynamic IPs upon request and my current ISP offers paid static IPs for $3.
Tons of my friends and family have had CGNAT and never known. It's just not a big deal for most content consumers.