XelNika

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

> production 1.7GHz quad-core Intel Core i7-based 13-inch MacBook Pro systems with Intel Iris Plus Graphics 645, 16GB of RAM, and 2TB SSD

https://www.apple.com/macbook-pro/#footnote-4

So yes, that is compared to a very old 14 nm design, presumably the i7-8557U per Wikipedia.

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

https://en.wikipedia.org/wiki/Jumbo_frame#Bandwidth_efficien...

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.

I believe this is the reply in question:

https://twitter.com/colinmbrandt/status/1409577979731058699

See for example: https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless...

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.

A lot of ISP routers have the option to disable everything except the modem, often called "bridge mode". Avoids double NAT.

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.

But if you write defensively, like the post suggests, you won't be surprised by bad library writers.

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.

CGNAT is standard for all smaller ISPs in Denmark. I'm not sure if it's mainly to stay competitive or due to limited supply, but they offer public IPv4 addresses upon request, sometimes for free. It makes sense really; if you default to CGNAT, which is fine for 99% of users, there will be more public addresses for the people who need them which keeps costs down for both segments. It's not the ISP's fault the standard is outdated.

> My eyes don't react well to IPS, for some reason

In what way? If it's just discomfort using it for long periods of time, there's a 95% chance, you need to turn on the lights in your room or turn down your monitor brightness.

> Can you please recommend a VA panel that is good for text sharpness, too?

Some subpixel arrangements might require you to change the font smoothing (Windows ClearType), but any monitor with high pixel density will do, really. I'm not an expert on specific models so I won't recommend one.

Modern high refresh rate displays (100/120/144 Hz) come in VA and IPS flavors and good ones are factory calibrated to UltraSharp levels as well. 2560x1440 monitors are the sweet spot in terms of price to performance.

Your information is 2-3 years out of date.

> Call me a cynic, but the whole "think critically and figure it out for yourself" solution is inefficient at best, harmful at worst. Global warming skepticism is exactly the kind of thing that often occurs when people trust their own judgement more than that of subject matter experts.

I don't think that's true. Lots of global warming sceptics point to some subset of experts who are themselves sceptics. Even subject matter experts have biases. If we ignored those, we'd probably still be unlikely to find many global warming sceptics who had done their own in-depth research. It seems to me that most people in this category (whether it's global warming scepticism, anti-vax, 5G death rays or something else) merely seek to confirm already held beliefs and end up rejecting the opinions of actual experts in favour of misinformation from the kinds of people the blog post is talking about.

Beyond that there are also people with deeper issues than just a disregard for subject matter experts. If you look to extremes (e.g. flat Earth believers), some won't change their mind even when they do the experiments themselves and find proof to the contrary.

It is probably not a typo, they are aware of the difference. Just read their support page. [0]

> Unless otherwise stated, TUXEDO always uses ISO standard keyboards. Other standards, such as ANSI, are available depending on the model, but are also marked as such.

Browsing from the EU, I am not seeing an ANSI option on the linked 15" or either of the 14" models. It seems they're not capitalising on the enthusiast developer segment.

[0] https://www.tuxedocomputers.com/en/Infos/Help-Support/Freque...

> Trouble is, I had an ancient machine in the flock. It didn't seem like it at the time, but my main serving system was magpie, a RHEL 6 box from 2015.

I can't tell if this part is hyperbole. RHEL 7 isn't a resource hog and a server from 2015 is probably a blazing fast multicore Xeon. The machine itself is almost certainly capable.

> To get away from it, I'd have to migrate to another box. That meant picking out new hardware at the hosting company.

If a hosting company won't allow a customer to install a new OS on their dedicated server, it's a shitty hosting company, particularly when that OS first released the year before they started renting. From the list of things that had to happen, maybe this was about not having downtime, but firstly a single host is not enough for HA and secondly it would be easy to just get a VPS for a month to use as a temporary host while upgrading.

I think you are right that this is a person who insists on doing it the hard way. I wonder if maybe these blog posts are a way for the author to process events and vent frustrations, and not intended for HN readers to dissect, but I would expect her to use her custom diary software for that sort of thing instead.

Depends on your bank and the definition of a strong ad blocker. Danish banks use a common authentication solution that is generally (always?) inserted as a third party iframe. If you use the uBO enhanced Easy mode [0] or stronger, it'll be blocked.

[0] https://github.com/gorhill/uBlock/wiki/Blocking-mode

I like the init system (admittedly, I have not been using Linux long enough to remember a time before systemd), but components like networkd and resolved are a pain to work with in general. I've had the networkd DHCP client fail in situations that dhcpcd and dhclient handled with grace. It is not clear to me what benefit said systemd components provide over the more traditional solutions.

The Wiki instructions are outdated and WireGuard has since (March 2020) come to buster-backports.