The Unix philosophy has proven inadequate to meet the needs of real-world software integration
I'm assuming that's why it's so trendy to talk about "microservices" these days.
What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.
The Unix philosophy doesn't say anything against implementing service discovery mechanisms.
...if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.
My God, "pathologically neckbearded". That's just rich. Let's shit on everyone who shows us different ways of building systems that allow for greater composability and emergent features.
The Unix philosophy doesn't say anything against implementing service discovery mechanisms.
It's less about service discovery mechanisms per se. It's more about using objects communicating via APIs as units of composition, rather than processes communicating via data (usually text) streams. The object-based approach hews closely to how programmers actually think, makes protocol specification as easy as declaring a method (and checked by the compiler!), and enables much more sophisticated interaction between components. See Miguel de Icaza's essay "Let's Make Unix Not Suck" for an in-depth look at how the COM model improves on Unix philosophy for software integration: http://baizid.org/literature/bongo-bong.html
What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.
There is a real tension between RPC-orientated systems and protocol-orientated systems. The RPC and distributed object model (COM,DCOM,CORBA) produces tightly coupled systems that provide more functionality if all parts are from the same vendor/team. The protocol-orientated style gives us the RFC protocols with a much wider diversity of implementations.
The question is which application developers do you make happy. The Windows/GNOME style is a single system with lots of moving parts that can't be individually replaced. One of the attractions of UNIX has been its hetrogeneity.
> Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel.
Which application developers? A hell of a lot of developers are really really happy with "muh unix". Why should a bunch of hipsters with half baked ideas get to rob those developers of that happiness because pushing through half baked ideas makes them happy?
It seems to me that more and more of this comes up as people are moving onto Linux for "cloud services", bringing with them mental models honed on Windows (and to some degree, OSX).
The Unix workstations were by and large simply a great deal more expensive, and there weren't any compelling options on x86 other than Windows, DOS, maybe OS/2, and a few other clones.
It was pretty much pure business--the technical merits don't enter into it. That said, Microsoft took on a heroic burden to attempt backwards-compatibility.
If you want a vindication of the Unix philosophy, look at the server space.
