6

As I understand it, part of the Unix identity is that it has a microkernel delegating work to highly modular file processes. So why is Linux still considered "Unix-Like" if it strays from this approach with a monolithic kernel?

  • 6
    "part of the Unix identity is that it has a microkernel" Just out of curiosity, where did you read that? The wikipedia page on the Unix kernel, for example, mentions nothing about microkernels and the wikipedia page on microkernels notes that early unix kernels were monolithic. – John1024 Jan 24 '15 at 5:18
  • @John1024 I suppose I wrongly assumed high modularity and a monolithic kernel could not coexist. – Steve Jan 24 '15 at 17:42
  • 1
    @John1024 In the wikipedia on Unix philosophy the term "monolithic" is used multiple times to contrast with a UNIX system. For instance, "The Unix philosophy favors composability as opposed to monolithic design" and "using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems". While it never specifically says the kernel is monolithic, it contrasts monolithic design with Unix and its modularity. This is why I thought they couldn't coexist. – Steve Jan 24 '15 at 20:57
  • 1
    You have a good point: Unix philosophy does favors modularity. I suspect that the explanation is that, historically, Unix kernels were monolithic because (a) Unix preceded microkernels and (b) the microkernel concept has been slow to mature. – John1024 Jan 24 '15 at 21:23
  • The "composability as opposed to monolithic design" refers more to user space than kernel space. For example, the unix way is to do grep pattern file | wc -l; however GNU been a bit more pragmatic and now you can do grep -c pattern file. – wurtel Jan 26 '15 at 12:04
5

I believe the answer lies in how you define "Unix-like". As per the wikipedia entry for "Unix-like", there doesn't seem to be a standard definition.1

A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification.

There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system is "Unix-like".

The term can include free and open-source operating systems inspired by Bell Labs' Unix or designed to emulate its features, commercial and proprietary work-alikes, and even versions based on the licensed UNIX source code (which may be sufficiently "Unix-like" to pass certification and bear the "UNIX" trademark).

Probably the most obvious reason is that UNIX and MINIX are antecedent of Linux, having inspired its creation.2

Torvalds began the development of the Linux kernel on MINIX and applications written for MINIX were also used on Linux. Later, Linux matured and further Linux kernel development took place on Linux systems.

Linus Torvalds had wanted to call his invention Freax, a portmanteau of "free", "freak", and "x" (as an allusion to Unix).

Whether a system is monolithic or microkernel does not seem to be considered when calling an operating system "Unix-like". At least, not nearly as often as whether the system is POSIX-compliant or mostly POSIX-compliant.

1

The "UNIX way" really refers to experience of the user. A small set of utilities can be combined to build an effective operating system command line. Related to this, operating systems utilities are in no way "special" or have power beyond programs which you can write yourself.

This is a difficult point to make these days, since UNIX was so successful in this aspect that it has become the way operating systems are expected to present their command line interfaces. The point is best illustrated by a counter-example: here's how to do cp a.txt b.txt on a IBM mainframe:

//COPY     JOB ,CLASS=E,MSGCLASS=X,NOTIFY=&SYSUID
//cp       EXEC PGM=IEBGENER
//SYSIN    DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSNAME=a.txt,DISP=SHR
//SYSUT2   DD DSNAME=b.txt,DISP=(NEW,CATLG),UNIT=SYSDA

This won't even copy every type of file.

UNIX made a number of assumptions which simplify usability at the cost of performance. File channels 1 (stdin), 2 (stdout) and 3 (stderr) go to and from the terminal, removing a lot of the boilerplate from the JCL above. The filesystem supports one type of data -- bytes -- and one access mode -- sequential (although the pointer where the sequential data can be read or written can be moved to implement a sort of "random access"). This means that system utilities only need deal with one type of file and one type of data to cover all files and datatypes. The filesystem does not require pre-allocation. Adding files to the directory (aka "disk catalog" on IBM mainframes) happens automatically if the filename is known to the operating system.

These assumptions were so successful that these days we don't even give them a second thought. Whereas at the time they would have appeared profligate -- imagine the sheer overhead of a filesystem which wasn't told in advance the maximum size of a file.

But UNIX didn't stop there. It promoted a "toolbox" approach to system utilities. The mainframe's IEBGENER can print files, rearrange fields within records, drop records, create blank records. In contrast, in UNIX cp copies files, cat lists file contents, cut handles fields. There's a neat syntax for stringing the stdout of a command to the stdin of the next file, all on one terminal line. Using this "pipe" syntax and those small commands we can do everything which IEBGENER can do. And things which the authors of IEBGENER never dreamed of.

Kernighan and Plauger wrote an influential book in 1976 about this approach -- Software tools -- and that's really the first exposition of the "UNIX way". Kernighan and Pike restated this approach in their 1984 book The UNIX programming environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.