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.
We've been using SSH keys by default for all of our new users for years, removes a ton of confusion and starts them with one of the better authentication methods out of the gate.
(We also set most up with code signing because why not? They think it's cool because we have green checkboxes everywhere, and they get to learn a bit of cryptography too)
Yeah, but that would honestly be an argument for any large company with leverage getting too much leverage, and this would apply to things like Google, Amazon, Apple, etc. and them using their leverage to control markets in similarly unethical ways.
It feels tiring that any time Microsoft does something good, EEE comes up, but times where Amazon or Google are doing massive damage to our industry or standards for their own benefits it's crickets.
Two different perspectives: on the search engine end being a consumer... that's a pretty easy-going experience, Google filters out the large amount of noise because it's a good search engine, you get your answer, you're on your way.
The other end of things, the users sitting on SO, weeding through the influx of questions, looking to grab bounties, etc. that is where working with SO is really rough. That is where we deal with a huge amount of garbage coming in.
Also as someone that has written answers for esoteric questions before, it can be hugely frustrating when the moderation-by-community ends up causing you grief because they don't understand the subject material enough to do anything other than to rule-lawyer your post to death (I started ripping my answers off the site and posting them to my own instead, which yay, I guess nice traffic boost?).
I stopped answering questions long ago unless it was referenced in a Github issue.
---
On the more esoteric side of things, the duplicates can be really rough, if you have an error that is caused by something non-trivial but the same error can be caused by a trivial mistake you'll be fishing through hundreds of posts trying to find alternative answers and underlying causes, this is pretty much the only time that you find the trash heap bubbling up on the consumer side of things.
It's trying to protect people that want to hire bottom-dollar work, but not get bottom-dollar quality.
If you're not happy with the rate at which I'm getting things done, you don't need screenshots of my desktop, feel free to hire someone else and let me know how that goes.
You're selling the wrong product if you're just looking to sell on the bottom dollar.
I meet clients in-person and focus on quality and consistency. Yeah sure you can save a few thousand by having someone do it on a site like this, but you'll lose many more times that much the first time a deploy gets botched, the site goes down, they can't help you get what you need as opposed to what you asked for, etc.
I stopped trying to beat on price long ago, wasn't worth it, just meant I had to put out lower quality code and slap stuff together sloppily to compete and I didn't like doing that.
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.