| This seems like an oddly specific take on this topic. You can get a conflicting resource in a shell by typing 'npm start' twice in two different shells, and it'll fail with 'port in use'. My point is that you can do not conflicting IPC, but by default IPC is conflicting because it is intended to be. You cannot bind the same port, semaphore, whatever if someone else is using it. That's the definition of having addressable IPC. I don't think arguing otherwise is defensible or reasonable. Having a concern that a network service might bind the same port as an other copy of the same network service deployed on the same target by another host is an entirely reasonable concern. I think we're getting off into the woods here with an arbitrary 'die on this hill' point about semantics which I really don't care about. TLDR: If you ship an IPC binary, you have to pay attention to these concerns. Pretending otherwise means you're not doing it properly. It's not an idle concern; it's a real concern that real actual application developers have to worry about, in real world situations. I've had to worry about it. I think it's not unfair to think it's going to be more problematic than the current, very easy, embedded story, and it is a concern that simply does not exist when you embed a library instead of communicating using IPC. |