> "...not having the calculator take 10sec to start due to telemetry..."
Calculator fires up in 2 seconds even on my elderly Intel m3-6y30 machine.
Not to pick on the parent poster, since I've seen far too many on HN say the same thing, but if the person who started this topic wants a prime addition to "unpopular opinions here that should not be", it's that those who aren't skilled enough to use Windows properly are also pretty much guaranteed not to be skilled enough to use other operating systems which expose much more complexity to the user, like Linux, properly either.
Not a CPU issue, but a network timeout one. Disconnect from ethernet/wifi, try again, report back. Circa 2016, it took 5-10 sec before it would give up on phoning-home & finally open. I put wireshark on it & timed it myself. No idea what it does now.
With Windows, who can tell? And that's the real issue. Is it a bug? Is it Micrsoft telemetry? Is it Microsoft being underhanded (which happens!)?
I've noticed that Windows programmers are very quick to work around what they perceive as bugs in underlying library code, and opaqueness in both code and motives is why.
Aside from that, amen. "Get a byte, get a byte, get a byte byte byte" is a breath of fresh air compared to MS documentation. The situation has improved--if only because we can go to StackOverflow and ask Jon Skeet for the answer--but in the bad old days (where you might as well be on a desert island with your MSDN DVDs) it was pure pain.
Calculator fires up in 2 seconds even on my elderly Intel m3-6y30 machine.
Not to pick on the parent poster, since I've seen far too many on HN say the same thing, but if the person who started this topic wants a prime addition to "unpopular opinions here that should not be", it's that those who aren't skilled enough to use Windows properly are also pretty much guaranteed not to be skilled enough to use other operating systems which expose much more complexity to the user, like Linux, properly either.