Easier said than done in this case. Actually effective crosschecks preventing this issue from occurring would entail rather massive I/O and CPU amplification in common operations.
we could have run with https://www.postgresql.org/docs/current/app-pgchecksums.html turned on, but it slows things down a bunch - and turning it on in retrospect would have taken days. Also not clear that it would have caught whatever the underlying corruption was here…
Suprised no one has mentioned RFC 8914 Extended DNS Errors, specifically section 4.17[1]:
> 4.17. Extended DNS Error Code 16 - Censored
> The server is unable to respond to the request because the domain is on a blocklist due to an external requirement imposed by an entity other than the operator of the server resolving or forwarding the query. Note that how the imposed policy is applied is irrelevant (in-band DNS filtering, court order, etc.).
Which would be relevant for Google DNS's "Query refused" at least. Although I guess it's possible maybe they do support it but Windows/Chromium don't...
Binary compatibility is necessarily at odds with the “recompile the world” philosophy. This global view has some advantages, eg. performance can be improved system wide LTO, calling conventions changes, security with hardening options, etc.
The local view, where a program with no knowledge of its runtime environment could appear at any time to a runtime environment that similarly knows nothing about a program, loses all those advantages and costs added constraints but gains.. the ability to run those programs.
The article argues that the balance should be shifted, to their (eventual) benefit, sure. I wonder how long until that would take.
I wonder if there’s more “pay for play” path. I guess that’s containers. Or maybe what they argue for but bundled software could stay the way it is now. Further bifurcation seems bad, adding more code paths to test etc.
Presumably there's some reason Go can't just use an embedded manifest[1] like everyone else?
Ahh, I'm inferring (from [2]) even with the manifest entry, a system wide registry key is also required to get long paths working:
> I'm working with the Windows security team to find a way to enable long path support without having to modify the registry, just by using the embedded manifest, but the chances of this happening soon are quite low.
I guess "hibernating" (writing VRAM to swap) works better than expecting userspace to gracefully handle device resets. One linear read vs. a thundering herd of processes re-initialising, decompressing, etc. should be more predictable/reliable at least.
I do wonder however how much VRAM is "volatile" - ie. framebuffers - and could just be thrown away. And web browsers seem to handle GPU resets just fine, so maybe they could opt-in?
I didn't mention in the article but the Nvidia drivers at one point would drop VRAM rather than preserving it, leading to corrupted RGB noise textures in window managers and browsers (and potential crashes though I don't think I encountered them). I suggested doing this on the AMD bug tracker (https://gitlab.freedesktop.org/drm/amd/-/issues/2362#note_20...), but the amdgpu developers weren't interested.
As I understand, KWin does call glGetGraphicsResetStatusARB(), and on Nvidia GPUs, sleep-wake (or opening apps if it crashed the GPU) would cause KDE to detect a graphics reset and print "Desktop effects were restarted due to a graphics reset" (https://github.com/KDE/kwin/blob/10c04995c1f9f82ddbd6610e5e0...). I haven't used Nvidia GPUs in years and don't know if this is still an issue. I think many apps don't check for graphics resets?
I'm not sure if residency is relevant here; the Microsoft link indicates that eviction makes memory inaccessible from the GPU to make room for other memory, which explains why Linux uses the same name for "backing up" VRAM before sleep (through the same underlying mechanism).
Wonder how this compares with the Consumer Data Right in Australia. The standards and discussions around them are right there on GitHub [1] - pretty surreal seeing accounts for the big banks. Of course it's mostly completely useless for anything DIY as semi-understandably access to any real data is gated behind certification requirements.
