Unfortunate typo: the article says "Having placed the fresnel lens, we're not able to get an usable image on the whole 40x30cm sensor." but I think the "not" should be "now". Having "not" reverse the meaning of the critical sentence!
HN user
brucedawson
Retired tech-nerd. Unicyclist, kiteboarder, juggler, hiker, plays tennis and pickleball, advocates for pedestrian/cyclist safety. Windows ETW expert. LGBTQ supporter. Vancouver, BC he/him
It's easy to make these 800V systems totally safe. You just have to combine this idea with the extremely sensible plan to put data centers in space and then there will be no worry about when "someone pulls out a rackmount unit" because there not be someone within hundreds of kilometers.
I think that is correct, but yes, a delay-slot instruction that is always executed is easy to reason about. Speculative execution that gets real? shudder
It did not help that the performance of the Xbox 360 CPU (and Cell) was terrible. In-order execution without the crazy-high frequencies the CPU was designed for was a failure.
Author here: This is not a common problem. I think I was told that Alpha had basically the same bug but it is a bug, for sure. Speculative execution causing problematic side effects is a deal killer.
Speculative execution, however, can cause less problematic side effects. For instance, a speculatively executed load or prefetch will usually actually prefetch which will pollute the cache, TLB, etc., and reveal side-band information, but that is a performance problem and perhaps a subtle security flaw, not a correctness bug like this was.
In 2021 I found an invisible memory leak in a tool (VS Code) that I have never used. This is the story of how.
I was surprised also when this happened, but pleased. The trust was nice. The fact that they needed to give me the symbols in order to understand the issue was surprising. Why couldn't they find the calls in their source? Or analyze the trace themselves? Curious.
Should it be my second law?
https://bsky.app/profile/randomascii.bsky.social/post/3lr24s...
Whoops! Good catch. That was supposed to be 12 furlongs. Apparently I have no intuitive sense of how long a furlong is so I didn't notice my typo
That is a problem they haven't tried to solve. Driving directions could be for tax/ride-share or a person in their own car. If Google Maps doesn't even ask you which it is then it can't possibly reliably give you correct directions. I'd love to see that fixed.
Right. I (the friend's cousin) did that. And two weeks after the changes were supposed to take effect the directions are still broken and the customers of this business are still inconvenienced.
So I wrote a blog post. It is yet to be determined if that will help or not.
Given that Google Maps understands the rules for street addresses in Vancouver it seems like the problem shouldn't have happened in the first place and should have been auto-corrected and the fix should have been quickly accepted. But none of that happened.
Most non-nerds don't know how to use the feedback tool. That is the reality.
It drives me crazy that Google Maps sometimes asks me where the entrance to a building is but it never seems to be clear about what it is asking. Where a pedestrian would enter? Where a car would enter?
Driving directions are a wonderful thing but they need to account for whether you are arriving in a ride-share vehicle (please drop me at the front entrance) or in a car you need to park (the front entrance may be worthless) - lots of work yet to be done.
And yet, as I mention in the blog post, Google Maps actually does understand how Vancouver's addresses work. It can find the location where a non-existent address would be if it existed. But for addresses like 138 W 6th Ave it chooses not to, instead trusting... well, I don't know what it's trusting. But whatever it is trusting is wrong, and is resistant to being corrected through the feedback tool.
Google Maps may not be able to understand every regional system but it _does_ understand the system in Vancouver. It then, apparently, makes it too easy for exceptions to this system to get encoded in their database and makes it too hard to fix those errors when they are noticed.
I believe that there is no accepted global system for "how street addresses work", but there has to be a better solution then a business owner reaching out to a friend's cousin to try to get a serious problem fixed.
If my fixes had been published in the promised 24 hours then this blog post would not have been written but after two weeks this is the best idea I could come up with.
I think it is practical for Google Maps to understand the systems used in most major cities and then use this knowledge to reduce the number of errors.
I also think it is possible for the feedback system to work better. It does work sometimes, but it is slow and opaque and unreliable. It's even worse for bike directions.
Interesting. I don't know what it means but if I delete the postal code from the 138 address in the map you link to then it goes back to displaying the bad location (with the postal code restored).
This smells like some weird caching, although I do most of my tests in an incognito window to minimize this.
Google Maps' database contains nonsensically placed addresses of non-existent buildings. Worse, however, is that it also contains entries for real buildings that are mapped blocks or kilometers away from their actual location, leading to real-life consequences.
After two weeks of failing to fix the most significant error that I found I decided to blog about the issue in hopes of getting the attention of the Google Maps team, and also to share what I found.
Some AMD drivers leak handles to every process created. On a build system that creates tens of thousands of process this leaks tens of thousands of process handles with each one creating a zombie process and wasting about 64 KB. This leak can consume all RAM on a powerful workstation in just a few days.
Author here:
Linux has made progress in this area, but I think that Windows is still better. Maybe I'm wrong (I haven't used Linux in a while) but I think when Linux developers say that they have excellent support for debug symbols this just means that they don't realize how good it is on Windows.
I can load a crash dump or ETW profiling trace that has come from a customer using any version of Windows and load it up on my machine and the debug symbols just appear. Windows 11? Windows 10? Windows 7? Some random patch level? It doesn't matter - they just show up. When I worked on Chrome I had that symbol server configured as well, so any combination of old Chrome version and Windows version would just work. It's really magical.
In addition, Chrome source code would automatically show up as I explored the crash dump. That's source indexing which is separate but related, and also magical.
If some Linux variants work this well, then that is great. Last time I tried I found there were many different steps and debug packages to install just to get all of the symbols for my local Linux install, and handling other Linux installs was more complicated.
This is all I do to make it work on Windows:
```set _NT_SYMBOL_PATH=srvc:\Symbolshttps://msdl.microsoft.com/download/symbols;SRV*c:\symbols*h...```
Author here: I find it quite strange that my kids have lost their mother, but I have not. I still have both my parents. That's so backwards.
Therefore I can't compare the grief of losing a parent to that of losing a spouse, and even when my parents do die (they are both in their eighties) it won't be the same because it will, to some extent, feel like the "right" time.
Losing a spouse is definitely disruptive as well and I have had to learn a lot of new skills, but they were probably overdue anyway. That part has been challenging, but quite manageable in comparison to the loss part.
Thanks. It's not really a consolation, but it does give me some happiness.
My employer (Google) gave me four weeks of grief leave. That plus four weeks of cobbled-together vacation and unpaid time off was invaluable for giving me the time to deal with logistics and bureaucracy and then have some healing time.
I am sure that it is difficult for smaller or less profitable companies to "do the right thing" even if they want to
"Die Broke" is similar. I read it ten years ago and it completely changed my attitude towards money. At least partially because of it I just gave my adult kids (28 and 30) as much money as I could as an early inheritance. It has way more value to them now than in 10, 20, or 30 years when I die. Plus I get to see them enjoy it, they get to thank me, they're not waiting for me to die, etc.
I am lucky to be able to do that, of course, but many would can give an early inheritance don't.
Which is to say, huge +1 to reading "Die With Zero" or "Die Broke"
Author here. I do recognize my immense privilege. I was even able to turn the dial a significant distance towards life before my wife died. I had dropped to 80% time (32 hours a week) and stopped managing and was working from home so that I could get almost 100% flexible hours.
But after my wife died even that was not enough. The few meetings I had left were blocking activities I wanted to do, and the job which I had previously loved no longer gave me joy. So, because I could, I retired.
If my wife hadn't died I might have retired at exactly the same time - a 10-year work anniversary is a nice milestone. I almost felt pressured to delay retirement because making major irreversible life-changing decisions after a traumatic life event can be very risky. But I think it is the right choice.
Blame the bible. God created the world in six days, and rested on the seventh, which was Saturday.
The real question is why the weekend was defined as straddling the last and first days of the week. Weird.
Yeah, I was a bit imprecise there. I didn't expect a difference of exactly 32, but I did expect something of that magnitude.
I blogged about that also:
https://randomascii.wordpress.com/2016/03/01/cars-in-canada-...
"To be fair..." (chorus of Letterkenny voices)
I appreciate the ASCII-only excuse, but I've corrected the omission anyway. Non-ASCII characters in randomascii - what will they think of next?
The foreground process will only get scheduled ahead of the background process if there is a shortage of CPU power. On today's many-core consumer machines it is much more likely that the background process will continue to make progress, with the only thing slowing it down being the repeated page faults.
Counting on CPU starvation to save memory seems like a very fragile solution.
I agree that commit peaks can affect foreground performance. I've filed bugs for an ephemeral 480 MiB bug in Chrome (caused by an errant product image), and I blogged about an errant 4 GiB allocation that wiped out the disk cache on my 8 GiB machine (https://randomascii.wordpress.com/2012/09/04/windows-slowdow...).
But treating working-set peaks as synonymous with commit peaks is problematic. I still believe that trimming of working sets will rarely save memory, and a working-set cap will virtually never be better than occasional trimming. The cap fails to address the higher-than-the-cap memory consumption in many cases, it just makes it more expensive.