3,942 karma · joined April 20, 2010
[ my public key: https://keybase.io/gauntletwizard; my proof: https://keybase.io/gauntletwizard/sigs/WLBbW433_lqvZr3EFcUj8sCaut00PcbdQ5dKfxC0TV4 ]
Does this test actually spot modern fakes? My understanding was that they typically used simple modulo addressing such that any write was immediately readable, and even large continuous chunks operated perfectly fine, it just also "overwrote" that address every 4GB or whatever.
What I'm saying is that the two probabilities are independent, possibly correlated, but not dependent. You need some number of nines in your control plane for scaling operations. You need some number of nines in your control plane for updates. These are very few, and they don't overly affect the serving plane, so long as the serving plane is itself resilient to the errors that happen even when a control plane is running, like sudden node failure.
Proper modeling of these failure conditions is not as simple as multiplying probabilities. The chance of failures in your serving path goes up as the time between control plane readiness goes up. You calculate (Really, only ever guesstimate, but you can get some good information for those guesses) the probability of a failure in the serving plane (incl. increases in traffic to the point of overload) before the control plane has had a chance to take actions again, and you worry about MTTF and MTBR of the control plane more than the "Reliability" - You can have a control plane with 75% or less "uptime" by action failure rate but that still takes actions on a regular cadence and never notice.
You can build reliable infrastructure out of unreliable components. The control plane itself is an unreliable component, and you can serve traffic at massive scale with control planes faulty or down completely - Without affecting serving traffic. You don't need more nines in your control plane than your serving cluster - That is the only point I am addressing/contesting. You can have many, many less and still be doing right fine.
In real practice, it's so cheap to keep your operator running redundantly, that it's probably going to have more nines than your workloads, but it doesn't need to be
The problem is that these two concepts are treated as one.
Safety needs might be possible to solve. Totalitarian states with ubiquitous panopticons can leave you "safe" in a crime sense, and AI gaslighting and happy pills will make you "feel" safe.
Love and belonging we have "Plenty" of already - If you're looking for your people, you can find them. Plenty aren't willing to look.
But once you get up to Esteem, it all falls apart. Reputation and Respect are not scalable. There will always be a limited quantity of being "The Best" at anything, and many are not willing to be "The Best" within tight constraints; There's always competition. You can plausibly say that this category is inherently competitive. There's no respect without disrespect. There's no best if there's no second best, and second best is first loser. So long as humans interact with each other - So long as we're not each locked in our own private shards of reality - There will be competition, and there will be those that fall short.
Self Actualization is almost irrelevant at this point. It falls into exactly the same as the above. You can simulate a reality where someone is always the best at whatever they decide to so, but I think it will inherently feel hollow. Agent Smith said it best: https://youtu.be/9Qs3GlNZMhY?t=23
All that said - There's still a ton of room for NFS to be the backing store, but more importantly there's room for distributed filesystems with intelligent caching to displace all of this.
Google used to have ethicists ethicists and a culture of don't be evil. They were fired by the AI ethicists, who for the most part were among that latter group - Rationalists who were supremely good at rationalizing their choices rather than making good ones.
I don't think that any of the current efforts at regulation are going to work. The latter culture has taken over the institutions, and that's why you see so many baying for the institutions to be taken down.
At some level, they are attempting to avoid bad press, but their methods go far beyond "Washing our hands of it, not my problem" and into "Trying to obfuscate and cover up crimes so that we can't be tied to them".
Source: Worked at Uber for about six months and quit in disgust.
None of this is to exonerate the NYT for their biased reporting, because the crime rates in conventional taxes are almost as bad, and closure rates are worse. It's an ugly industry that Uber could have cleaned up but decided the pragmatic approach was to spin doctor.
It does seem to have waxed and waned; going in and out of popularity to the point of being a lost art multiple times. Wikipedia doesn't go so far as to divide it into eras, but given the time gaps, it's possible that there were multiple "inventions" of perspective in the sense of formalized techniques and pedagogy. https://en.m.wikipedia.org/wiki/Perspective_(graphical)
I am a Site Reliability Engineer (SRE), Google Style, with experience at both large and small organizations. I can help you build a Platform Engineering practice from the very beginning. I'm looking to help small dev teams increase their velocity by implementing best-practices of Devops: CI/CD, Kubernetes Deployments, and effective Monitoring frameworks.
My resume: https://resume.gauntletwizard.net/ThomasHahnResume.pdf
My LinkedIn: https://www.linkedin.com/in/thomas-hahn-3344ba3/
My Github: https://github.com/GauntletWizard
The next step up is building a "metadata" device, which stores the filesystem metadata but not data. This is dangerous in the way the ext4 journal is; lose the metadata, and you lose everything.
Both are massive speedups. When doing big writes, a bunch of spinning rust can't achieve full throughput without a SSD ZIL. My 8+2 array can write nearly two gigabits, but it's abysmal (roughly the speed of a single drive) without a ZIL.
Likewise, a metadata device can make the whole filesystem feel as snappy as SSD, but it's unnecessary if you have enough cache space; ZFS prefers it, so if your metadata fits into your cache SSD, most of it will stay loaded
I don't consider this a vulnerability, per se. This is the the usual level of uncertainty when dealing with physical objects.