> all applications should be doing I/O in a giant pool of state I'm somewhat infamous as one of the last people to have given up on distributed filesystems, bu

> all applications should be doing I/O in a giant pool of state I'm somewhat infamous as one of the last people to have given up on distributed filesystems, but even I have always believed the "giant pool of state" approach is a better model for applications. Storage should be designed for applications, not the other way around. Hide the tiers and locality and layouts behind an abstraction layer as much as possible, let 90% of the code "think" in objects or rows or arrays or whatever makes sense for it. Yes, the abstraction will leak. You'll have to deal with it when performance tuning, and probably add some other user-visible concept of consistency/durability points, but all of that should be minimized. In addition to lessening the cognitive load for most programmers, having such a layer makes it easier to adapt to new technologies in a rapidly changing landscape. > The idea of this was called SSI before, but it can actually become reality This is where we diverge a bit. SSI vs. explicit distribution is really orthogonal to storage models and abstractions. Most SSI attempts failed because the coordination/coherency cost even for compute/memory stuff was too high. Also the semantics around things like signals, file descriptors, process termination and so on were always a mess. POSIX contains too many things that only really work in a single system, barely a shared-memory multiprocessor let alone a more loosely coupled type of system, but that goes well beyond the storage parts. (Yes, young 'uns, there's more to POSIX than the filesystem part.) Tanenbaum's and Deutsch's critiques of RPC mostly apply to any kind of SSI, especially with respect to handling partial failure. While abstracting away the storage part makes sense, I don't think abstracting away a system's distributed nature is a good idea (or even possible) for most domains.