The abstractions aren't just for simplicity. In many cases, ensuring that the distributed nature is unknown or unobserved means the system can make different decisions without affecting the program. This leaves room for flexibility in the system design.
Maybe? Alternatively by bringing the distributed nature up front-and-center you can have more flexible designs. If I could timeout my drawing routine when the screen has already refreshed (or context has been stolen from the OS) then I have a lot more flexibility in how to recover instead of pretending to do my best and ending up with a lot of screen tearing when I miss my frame budget.
I'm trying to wrap my head around where this would happen in a way that made sense. Derailing the GPU pipeline from the OS probably doesn't make much sense. If we're talking about the OS halting the CPU side of the render I guess that would maybe be useful? Even on a single core machine it would be equally useful so I don't know if its a case of distribution per se...
But in the abstract, sure. It's a give and take. It's useful to know things and use that knowledge. It's also useful to know a detail is hidden and changeable without consequence.
Yeah I'm thinking the OS halts the CPU side of the render and, say, stuffs an errno into a register after the routine so the CPU can see what happened and recover. If I were writing a program that required a minimum frame rate and I missed multiple frames, it would probably be nicer for the user if I displayed a message that I was just unable to write a frame at the required speed and quit rather than screen tear and frustrate the user.
A similar situation happens if my NIC/kernel buffers are to overloaded to send the packets I need out. Instead I can try in vain to push packets out and have almost no understanding how many packets the OS is dropping just to keep up. Media standards like RTCP were designed around scenarios like these, but that itself is complexity we wouldn't need if the OS could notify the application when their packet writes failed.
This kind of flexibility right now is really difficult because most OSs try to pretend as hard as possible that everything happens sequentially. This is just about opening up more complete abstractions to the programmer.
Distributed problems that are largely timing are easy to see in this nature. In large, the whole synchronize on a clock idea is invisible to programmers.
That said, there are times when it isn't hidden, but only taken out of your control. I guess the question is mainly in how to move them to first class objects to reason about?
The distributed nature can never be unobserved, by definition. What a well-designed distributed system can do is offer facilities to enable useful constraints on its operation, that might then be used as necessary via a programming language.
