...even so, without a disk failure, that probably wasn't the cause of this event.

* Data single obviously means losing a single drive will cause data loss, but no drive was actually lost, right?

* Metadata DUP (not sure if it's across 2 disks or all 3) should be expected to be robust, I'd expect?

* I certainly eye DM-SMR disks with suspicion in general, but it doesn't sound like they were responsible for the damage: "Both DUP copies of several metadata blocks were written with inconsistent parent and child generations."

I'd guess they have dozens of people across say a Linux kernel team, a Graviton hardware integration team, an EC2 team, and a Amazon RDS for PostgreSQL team who might at one point or another run a benchmark like this. They probably coordinate to an extent, but not so much that only one person would ever run this test. So yes it is duplicative. And they're likely intending to test the configurations they use in production, yes, but people just make mistakes.

It will be more interesting to talk about those applications if and when they are found. And I wouldn't assume the solutions are limited to reverting this change, starting to use the new spinlock time-slice extension mechanism, and enabling huge pages.

It sounds like using 4K pages with 100G of buffer cache was just the thing that made this spinlock's critical section become longer than PostgreSQL's developers had seen before. So when trying to apply the solution to some hypothetical other software that is suddenly benchmarking poorly, I'd generalize from "enable huge pages" to "look for other differences between your benchmark configuration and what the software's authors tested on".

[1] A discount that was less than the delta between consumer-class and business-class prices, when the latter doesn't seem to actually be providing better availability lately.

I don't think the author would have acted this way toward someone who said "sorry, I know it's a burden, I know it's stressful to be at risk of losing these benefits, and I've told that to everyone I can repeatedly." So how much danger is there really that the inconvenience of reloading the fax machine is pushing out someone who is trying to do good?

(For the sake of argument, I'm going with all the details of the story, including that this caused Karen any distress at all. I think it's more likely a real office like this has a setup for which getting a 500-page fax is no big deal at all. And if it really is a DoS on their processing, the consequence I'd be more worried about is causing acceptance to slow down enough that other disability claims are not processed before their deadline.)

Or semi-fiction? The author is actually blind and tagged it nonfiction, but I suspect some embellishment.

> but in reality, Karen is likely just as annoyed by this as the author.

When I'm frustrated talking with an agent of a big organization, I try to remember they probably didn't set the policy. But I also expect them to express some empathy for how I'm negatively affected by that policy. The author/protagonist, accurately or not, felt the opposite from "Karen from compliance". In their shoes, I wouldn't feel much empathy for Karen in return.

> The spam should go to the person in charge

I also expect the agent to have a closer relationship with "the person in charge" than I do (none whatsoever). If I mention the policy is absurd, they could at least make some effort to pass that along to their manager.

Also, sending the information to the agent is necessary compliance, even if the volume is malicious.

> not the person who is forced to deal with this every day

Maybe they feeling a bit of the pain themselves might make them more likely to speak up. If this becomes a miserable job that no one will stay in, that might provoke a change.

Yeah, I've done that. I find it much more honest than automatically closing it as stale or asking the reporter to repeatedly verify it even if I'm not going to work on it. The record still exists that the bug is there. Maybe some day the world will change and I'll have time to work on it.

I'm sure the leadership who set SLAs on medium-priority bugs anticipated a lot of bugs would become low-priority. They forced triage; that's the point.

> People even wrote automated rules to see if their bugs filed got downgraded to alert them.

This part though is a sign people are using the "don't notify" box inappropriately, denying reporters/watchers the opportunity to speak up if they disagree about the downgrade.

Is there an experiment you'd recommend to reliably show this behavior on such a SSD (or ideally to become confident a given SSD is unaffected)? Is it as simple as writing flat-out for say, 10 minutes, with O_DIRECT so you can easily measure latency of individual writes? do you need a certain level of concurrency? or a mixed read/write load? etc? repeated writes to a small region vs writes to a large region (or maybe given remapping that doesn't matter)? Is this like a one-liner with `fio`? does it depend on longer-term state such as how much of the SSD's capacity has been written and not TRIMed?

Also, what could one do in advance to know if they're about to purchase such an SSD? You mentioned one affected model. You mentioned DRAMless too, but do consumer SSD spec sheets generally say how much DRAM (if any) the devices have? maybe some known unaffected consumer models? it'd be a shame to jump to enterprise prices to avoid this if that's not necessary.

I have a few consumer SSDs around that I've never really pushed; it'd be interesting to see if they have this behavior.

> This was an oversimplification bordering on being misleading. It’s a lighter JS runtime that’s calling native code for rendering controls. The argument still has merit. Just because something in JS doesn’t make it slow or bloated. Interpreted languages will almost always be slower than their native compiled counterparts, but it’s negligble [sic] for these purposes.

Isn't it a full JS runtime? I think by "a lighter JS runtime that's calling native code" you mean it doesn't deal with HTML/CSS rendering, but that's not what JS runtime means. These are separate parts of the browser architecture.

I don't agree it's negligible for this purpose. Core OS functionality should run well on old/cheap machines, and throwing in unnecessary interpreters/JITs for trivial stuff is inconsistent with their recently announced commitment to "faster and more responsive Windows experiences" and "improved memory efficiency".

I don't have any inside information; I'm running with the hypothetical.

To some extent, yes. But if they choose React Native, something's probably wrong, because (despite what the article says) that requires throwing in a Javascript engine, significantly bloating a core Windows component. If they only use it for a small section ("that can be disabled", or in other words is on by default), it seems like an even poorer trade-off, as most users suffer the pain but the devs are making minimal advantage of whatever benefits it provides.

If the developers are correct that this is the best choice, that reflects poorly on the quality of Microsoft's core native development platforms, as madeofpalk said.

If the developers of a core Windows component are incorrect about the best choice, that reflects poorly on this team, and I might be inclined to say no, someone more senior should be making the choice.

Any idea what Firefox is waiting for? To me those lines I quoted seem entirely arbitrary, and a skim through bugzilla didn't help.

But WebCodecs is just really straightforward. It's hard to find anything to complain about.

If you have an IP camera sitting around, you can run a quick WebSocket+WebCodecs example I threw together: <https://github.com/scottlamb/retina> (try `cargo run --package client webcodecs ...`). For one of my cameras, it gives me <160ms glass-to-glass latency, [1] with most of that being the IP camera's encoder. Because WebCodecs doesn't supply a particular jitter buffer implementation, you can just not have one at all if you want to prioritize liveness, and that's what my example does. A welcome change from using MSE.

Skipping the jitter buffer also made me realize with one of my cameras, I had a weird pattern where up to six frames would pile up in the decode queue until a key frame and then start over, which without a jitter buffer is hard to miss at 10 fps. It turns out that even though this camera's H.264 encoder never reorders frames, they hadn't bothered to say that in their VUI bitstream restrictions, so the decoder had to introduce additional latency just in case. I added some logic to "fix" the VUI and now its live stream is more responsive too. So the problem I had wasn't MSE's fault exactly, but MSE made it hard to understand because all the buffering was a black box.

[1] https://pasteboard.co/Jfda3nqOQtyV.png

Probably never had to work with (live) video at all? I think using moq is the dream for anyone who does. The alternatives—DASH, HLS, MSE, WebRTC, SRT, etc.— are all ridiculously fussy and limiting in one way or another, where QUIC/WebTransport and WebCodecs just give you the primitives you want to use as you choose, and moq appears focused on using them in a reasonable, CDN-friendly way.

* Firefox support for WebCodecs is poor—none at all on Android [1], H.265 is behind a feature flag. [2]

* Mobile Safari doesn't support WebTransport. Or didn't...I just looked it up again and see it does in 26.4 TP. Progress! [3]

[1] https://searchfox.org/firefox-main/rev/da2bfb8bf7dc476186dfe...

[2] https://searchfox.org/firefox-main/rev/da2bfb8bf7dc476186dfe...

[3] https://caniuse.com/webtransport