>It's a pity that they don't get to the crux of distributed systems because it's very well defined and described for ~40 years now.
Really?
I'm incidentally in the midst of a lit-review on the subject and it seems quite apparent that no standard definitions have emerged.
>The two fundamental ways in which distributed computing differs from single-server/machine computing are.
>1. No shared memory. 2. No shared clock.
The typical multiprocessor is, in fact, a distributed system under the hood. Most of the time the programmer is unaware of this thanks to cache coherence algorithms, which in turn benefit from a reliable communication layer between individual cores.
And yet, we can still observe consistency failures when we operate the chip outside of the parameters for which it guarantees a single-system image (namely: when using something like OS threads).
I think the problem is that we're using the wrong kind of definition. Your definitions -- an indeed most definitions encountered in literature, with some exceptions -- appeal to design. They are teleological definitions, and as such they can't define "distributed" in the sense of "distributed programming" or "distributed computation". A more useful kind of definition is intentional [0]. It is constructed at a higher level of analysis that assumes the design serves the purpose of representing the world, among others. Thus, you get a definition like this:
Distributed computing is a computational paradigm in which local action taken by processes on the basis of locally-available information has the potential to alter some global state.
Returning to multiprocessor initial example, the more useful question is often not
whether computation is distributed, but
when it makes sense to regard it as such. There are three typical cases in which an engineer is engaged in the practice of distributed computing:
1. He is designing or developing a distributed computing system.
2. The system is operating outside of specified parameters, such that design invariants no longer hold.
3. The system is malfunctioning, which is to say it violates its specification despite operating within specified parameters.
The second case is the most relevant to our prototypical multiprocessor. The use of OS threads, for example, can be understood as operating outside of the range of parameters for which the SSI can fulfill its guarantees. It is important to note that the system can still be made to function correctly (contrary to case #3), provided the programmer shoulders the burden of distributed control.
It's definitely possible -- and I would argue, correct -- to reframe "no shared memory" and "no shared clock" in intentional terms, but as we've seen with the multiprocessor example, those two conditions alone do not define "distributed system" in general; they are not fundamental properties. I will however grant that they are the most common manifestations of distribution in practice.
To summarize: the literature has not -- to my knowledge -- arrived at a good definition ~40 years ago. If I've missed something, please point it out, though. I'd hate to publish something incorrect. :)
[0] https://en.wikipedia.org/wiki/Intentional_stance#Dennett's_t...