Is Linux Unix?
What's really needed to settle this is a definition of Unix. Unfortunately, there's no obvious definition against which we might compare Linux. The systems we all accept as unambiguously Unix -- that is, BSD, HP-UX, Solaris and Tru64 -- have more functional differences than, say, Linux and Unixware.
My Web logs show that somebody asked Google an interesting question sometime just before 08:03:41 Eastern on January 24th and then again sometime before 04:54:29 Eastern on January 26th. As entered the first time, the search was for "linux to unix relationship," although that became "relationship of linux to unix" a few minutes later and "what is the relation of Linux to Unix" two days after that.
Since my personal site isn't the first one that comes up when you do these searches, I decided the person must have been very interested in pursuing the question. So I set out to answer that question in this column. Aside from legal considerations associated with trademarks and copyrights, I know, of course, that the answer is obvious: Linux is Unix. Duh. Even Scott McNealy has said so.
On the other hand, experience suggests that about half of everything I know is wrong, and IDC, in its work for Red Hat, certainly claims that Linux isn't Unix. Red Hat's Mark de Visser recently said the path to Redmond is through Mountain View, which means the company is focusing on Unix now to displace Microsoft on the desktop in the future.
So, is this just a marketeer's attempt to differentiate his x86 Unix from Sun's x86 and Sparc-based Solaris, or is there a significant difference that isn't accounted for by relative scale and maturity?
Starting with History
History may give us a place to start. Everybody knows Unix started at what was then AT&T Bell Labs and went through two enormous growth phases, the first at Berkeley in the early 1980s and the second at Sun 10 years later, but surprisingly few people know where Linux came from.
Before looking at that, however, it's important to be clear that Linux is actually a composite. The Linux platform includes the Linux kernel, the same GNU utilities found in virtually all versions of Unix, the same GUIs and applications available for most Unix variants, and hundreds of device drivers either custom-developed for Linux and (mostly since) ported to Unix variants like Solaris for x86 or ported from Unix variants such as OpenBSD and SCO Open Server.
The current kernel is fundamentally the work of Linus Torvalds and people he recruited into the kernel development and maintenance process, but the kernel he started with -- Andrew S. Tanenbaum's Minix -- was unambiguously described by its author as "an open source Unix clone."
Stacking the Case
That's actually important for another reason too: Tanenbaum's 1987 book, Operating Systems: Design and Implementation, was one of the first to include both the source and an absolutely clear open-source license agreement along the lines laid out by Richard Stallman's Free Software Foundation.
Both history and composition therefore stack the case toward believing that Linux is indeed Unix. Unfortunately, history isn't enough; after all, the same argument would support the belief that Yorkshire Terriers are Alaskan Malamutes on the grounds of genetic heritage and a shared interest in chasing mice.
What's really needed to settle this is a definition of Unix. Unfortunately, there's no obvious definition against which we might compare Linux. The systems we all accept as unambiguously Unix -- that is, BSD, HP-UX, Solaris and Tru64 -- have more functional differences than, say, Linux and Unixware. Old standbys like the System 5.3 compatibility test risk having to certify zOS and Windows 2003XP with Services for Unix as Unix -- and we know that's wrong.
A better idea, therefore, may be to look at what the product is intended to do, rather than how it does it, to see whether Linux meets Unix expectations.
From the Mouths of Developers
For this, consider what Dennis Ritchie, one of the original Unix developers, had to say in a paper on "The Evolution of the Unix Time-sharing System":
From the point of view of the group that was to be most involved in the beginnings of Unix (K. Thompson, Ritchie, M.D. McIlroy, J.F. Ossanna), the decline and fall of Multics had a directly felt effect. We were among the last Bell Laboratories holdouts actually working on Multics, so we still felt some sort of stake in its success.
More important, the convenient interactive computing service that Multics had promised to the entire community was in fact available to our limited group, at first under the CTSS system used to develop Multics, and later under Multics itself. Even though Multics could not then support many users, it could support us, albeit at exorbitant cost. We didn't want to lose the pleasant niche we occupied, because no similar ones were available; even the time-sharing service that would later be offered under GE's operating system did not exist.
What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.
What he means here isn't just time-sharing on a single machine, but a collaborative environment in which the system is used to provide communications among people and thus enable them to share goals and ideas while contributing to each other's work.
So does that sound like a description not so much of Linux but of the fellowship that's sprung into being around it? Of course it does, and combining that usage with the origin in Minix, the shared GNU and open-source heritage, and obvious functional compatibility with Unix settles the question: Linux is Unix, and no ifs, buts or maybes about it.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.