XelNika

In cases where the data itself doesn't carry the unit (or TZ in this case), I usually ask that the unit-less columns at least include the unit in the name. A TZ-less column is not that bad if it is suffixed "UTC", e.g. `ExecutionTimeUtc`.

There are probably real world cases where dropping the TZ/offset provides meaningful performance/storage savings, but it hasn't been the typical case in my current sector.

I think people who monitor their usage like this are probably running $20-30 subscriptions or PAYG API pricing.

$100 a month on an LLM subscription for hobby usage is an absurd amount of money IMO.

As I understand it, this second complaint is not against the original company, but against the government authority that handled his case.

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++.

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.

Intel Alder Lake delivered around a 15% improvement to single-core performance gen-on-gen so it's just you.

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.

Yes, it's not good.

> 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.

Yes, it says so in footnote 1 in the article. It's also not the benchmarked code so it doesn't really matter.