Editing Plan 9 from Bell Labs (section)

=== Comparison to contemporary operating systems ===
In 1991, Plan 9's designers compared their system to other early nineties operating systems in terms of size, showing that the source code for a minimal ("working, albeit not very useful") version was less than one-fifth the size of a [[Mach (kernel)|Mach]] [[microkernel]] without any device drivers (5899 or 4622 [[lines of code]] for Plan 9, depending on metric, vs. 25530 lines). The complete kernel comprised 18000 lines of code.{{r|distributed-system}} (According to a 2006 count, the kernel was then some 150,000 lines, but this was compared against more than 4.8&nbsp;million in [[Linux]].{{r|unix-spirit-set-free}})

Within the operating systems research community, as well as the commercial Unix world, other attempts at achieving distributed computing and remote filesystem access were made concurrently with the Plan 9 design effort. These included the [[Network File System]] and the associated [[vnode]] architecture developed at [[Sun Microsystems]], and more radical departures from the Unix model such as the [[Sprite (operating system)|Sprite]] OS from [[University of California, Berkeley|UC Berkeley]]. Sprite developer Brent Welch points out that the SunOS vnode architecture is limited compared to Plan 9's capabilities in that it does not support remote device access and remote inter-process communication cleanly, even though it could have, had the preexisting [[UNIX domain sockets]] (which "can essentially be used to name user-level servers") been integrated with the vnode architecture.{{r|welch}}

One critique of the "everything is a file", communication-by-textual-message design of Plan 9 pointed out limitations of this paradigm compared to the [[static typing|typed]] interfaces of Sun's [[object-oriented operating system]], [[Spring (operating system)|Spring]]:

{{Blockquote|Plan 9 constrains everything to look like a file. In most cases the real interface type comprises the protocol of messages that must be written to, and read from, a file descriptor. This is difficult to specify and document, and prohibits any automatic [[type checking]] at all, except for file errors at run time. (...)

[A] path name relative to a process' implicit root context is the ''only'' way to name a service. Binding a name to an object can only be done by giving an existing name for the object, in the same context as the new name. As such, interface references simply ''cannot'' be passed between processes, much less across networks. Instead, communication has to rely on conventions, which are prone to error and do not scale.|Roscoe; emphasis in the original.{{r|roscoe}}}}

A later retrospective comparison of Plan 9, Sprite and a third contemporary distributed research operating system, [[Amoeba (operating system)|Amoeba]], found that

{{Blockquote|the environments they [Amoeba and Sprite] build are tightly coupled within the OS, making communication with external services difficult. Such systems suffer from the radical departure from the UNIX model, which also discourages portability of already existing software to the platform (...). The lack of developers, the very small range of supported hardware and the small, even compared to Plan 9, user base have also significantly slowed the adoption of those systems (...). In retrospect, Plan 9 was the only research distributed OS from that time which managed to attract developers and be used in commercial projects long enough to warrant its survival to this day.|Mirtchovski, Simmonds and Minnich{{r|integrated}}}}