4 ms·
I don't disagree, but for the sake of having productive conversations, it's easiest to acknowledge that this is a matter of one's frame of reference. Are you te
by nrr 3y ago
I don't disagree, but for the sake of having productive conversations, it's easiest to acknowledge that this is a matter of one's frame of reference. Are you technically correct? Yes. How much does that matter at the end of the day? For most people, myself included, I'd argue not a lot.
As someone who straddles the system call boundary, I generally consider myself as not running in a distributed system if the layers of the stack below me will fall out from underneath me when some invariant of their abstraction around the distributed nature of my execution context fails to hold.
For PCIe-interconnected devices (except for HBAs and disk because that entire stack outright lies to you), the chances are pretty good that the kernel will bugcheck if it can't successfully remediate the problem.
For something connected over Bluetooth? Not so.
- vlovich123 3y agoYeah that’s a fair line and often how I like to think about things (ie are the failure domains coupled on error or not). The only nit is that it’s not uncommon for storage layers or really any HW to swallow errors and not even report it to the kernel. And that’s ignoring that silent memory errors happen a lot on most consumer HW.
- nrr 3y agoAgain, you aren't wrong, and it's actually a lament of mine that these peripheral processors aren't themselves under the purview of the kernel's scheduler for their tailor-made tasks or that the code that runs there isn't debuggable in much the same way as any other code. It is, nevertheless, good enough for most people that it more or less works 80% of the time. Pareto strikes again.