Plan 9 definitely has some interesting ideas but I think there are some hidden pitfalls in the "everything is a file" paradigm. The first is that it's not stri

Plan 9 definitely has some interesting ideas but I think there are some hidden pitfalls in the "everything is a file" paradigm. The first is that it's not strictly accurate - some things like network devices are actually collections of artificial files which need to be manipulated in strict ways. In my opinion it would be better to say that in Plan 9, "everything has a file-like protocol". Unfortunately most programmers aren't taught to think this way and are unable to extend this philosophy. They don't know how to apply the "everything has a file-like protocol" idea to their own projects and aren't given sufficient time to learn so they just go back to writing the same kinds of stuff they already know. Pretty quickly they tire of making simple protocol mistakes and start doing things like wrapping the protocols in frameworks of objects and using those to build their applications without realizing the additional complexity they've reintroduced since the paradigm effectively becomes "lower level things have file-like protocols, but other things are objects". The second problem is that the classic open/read/write/seek/tell/close interface isn't always the most obvious way to manipulate data. Editors would be much simpler with primitives like insert/delete, job processing is simpler with things like enqueue/dequeue, and so on. The plan 9 "systems" viewpoint is that developers should construct the appropriate protocols: editors should send insert/delete primitives to a document's "control" file, batch systems send enqueue/dequeue requests to queue control files, etc. But application developers generally don't want to think this way - they want paradigms which directly fit their model. This can become particularly challenging when the application wants to deal with more complex structures such as hierarchies or graphs. However I think Plan 9 did get a few things right here. The idea of per-process namespaces is very powerful, even when "everything is a file" doesn't hold true. More recent things like FUSE are still playing catch up. Protocols, API's and objects all have their problems. If I were ever to do this kind of research, I would try to come up with new ways to express and implement the essential state models of a system that would make retargeting software easier. Over the years it seems like I've had to write and rewrite several of the same basic state management schemes to suit the requirements of whatever platform or service is in fashion.