The only hangup with the myth "debunking" is that the point is that the corruption doesn't happen to a per-disk buffer, but to the in-flight data before it's persisted to your stripe.
Which means all copies of the data will be corrupted. This can be anything from an irrecoverable file to complete filesystem corruption.
But generally, yeah, not any more dangerous than any other filesystem, and ECC used to be cheap so it was a no-brainer, you should have backups anyway TBH if we're being honest about storage resiliency.
What has been debunked is the "scrub of death" issue, on a scrub a bad bit flip would cause an error, which would be copied over with good data -- well it was technically good before. It would be statistically difficult to have a fault on a read, then a clean read, then a second bit flip destroying the data.
> The input latency might not be as good as you'd like.
Yeah input latency is annoyingly rough, not super bad but _just_ laggy enough to make it annoying to use.
Debating how much I want to change things, I can directly punch into my Linux machine but all my dev IDEs are on a VM for a long list of reasons, and I doubt Zed is going to run on my old ThinkPad if it struggles on software rendering, but we'll see.
I've literally programmed with VSCode for basically a decade this way without issues. Zed lags, it's disappointing and if I really like Zed I'll have to sort out another setup.
MSTSC is one of the rock-solid tools from Microsoft, and does better than almost everything else available on the market other than some PC over IP technologies specifically highly optimized for this use case. I've been programming with an ancient ThinkPad forever because I'm just remoting into a much more powerful machine.
We build a Shopify-leading platform on C# at a startup -- they got so much flak from colleagues about it being built on C# instead of Node or Python.
Absolutely no reason other than "C# icky" -- they ended up with a platform that is crazy fast (and fast scales way easier, it handles a dumb amount of traffic without a lot of crazy design)
Startup culture is toxic AF at times, bad engineering decisions for cargo cult stuff.
Long-time C# Dev here -- yeah I'm still jealous of being able to find more esoteric libraries in Node, Python or PHP -- or just having more options then someone's back-yard half-baked implementation sometimes.
On the other hand, I have nearly 20 languages under my belt and have been writing code professionally for 22 years -- I still use C# most of the time for a lot of other reasons, just this is one of the bigger pain points.
Which means all copies of the data will be corrupted. This can be anything from an irrecoverable file to complete filesystem corruption.
But generally, yeah, not any more dangerous than any other filesystem, and ECC used to be cheap so it was a no-brainer, you should have backups anyway TBH if we're being honest about storage resiliency.
What has been debunked is the "scrub of death" issue, on a scrub a bad bit flip would cause an error, which would be copied over with good data -- well it was technically good before. It would be statistically difficult to have a fault on a read, then a clean read, then a second bit flip destroying the data.