About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve

It's a Way of Thinking

And it can't be summed up easily.

Unix isn't an operating system - it's a way of thinking.
 - Ancient Unix proverb

Get It

Try It

It's hard to know if they're serious or not - the people at the CLIX Exchange are notoriously cheeky. But of late there's been a discussion - suspiciously tongue in cheek - about the best 'Unix' editor.

Is it ed? Is it vi? Or is it nano or pico? [Gratefully e-RMS-macs was never mentioned.]

It's none of those.

Presuming for one fallacious instant that some people have in fact got it wrong, it can be pointed out that yes indeed the graphical user interface offers things the command line - the text mode console - can never offer. Bleeding obviously.

But if the command line is not an alternative to the GUI for most operations: what good is the underbody of Unix anyway?

Good question. And if it could be summed up easily there wouldn't be any need to simply reply 'it's Unix'. But 'Unix' cannot be summed up easily - and yet it truly is a 'way of thinking'. Rather than an operating system per se.

The Doug Eminence

Perhaps more than even 'dmr' and 'ken' Doug McIlroy is the father of this 'way of thinking'. Doug McIlroy was the head of the Bell Labs CSRC back when Unix was born and his precepts for its design and development have stuck with Unix all through the years, permeating the way 'dmr', 'ken', and that ultimate pedagogue Brian W Kernighan ('bwk'') have thought and taught.

'Make each program do one thing and do it well', Doug wrote in a memo to 'dmr' and 'ken'. 'And instead of adding on bells and whistles at a later date you make a new program instead', he added.

Doug was also the one who insisted on plain good old ASCII as a way for programs to communicate with each other. Think for a moment where the Internet would be today if people hadn't adhered to that advice: almost every protocol in use today is dependent on ASCII communication.

Simply pointing your browser to a website is ASCII. You're sending a plain text ASCII message to the remote server.


Where '<RRL>' is the relative resource locator - the page you want relative to the website itself. Asking for the home page of rixstep.com is essentially a GET with '/index.shtml' as the RRL.

Sending and receiving mail is the same thing - it's all ASCII. FTP is ASCII. Almost all of the protocols are ASCII.

If we didn't have ASCII for these protocols - if people hadn't listened to their Doug Eminence way back - then we wouldn't have the Internet today as we know it.

Doug's also the one who came up with the idea of 'pipes'. When he first presented it to 'dmr' and 'ken' they couldn't see what it would be good for. 'Just put it in', said Doug. They did - and the rest is history.

The technologically immediate precursor to Unix was Multics - and Multics used a model very similar to the mess Microsoft are using today: resident modules that continually broadcast their presence to the system and a coordinator. Messy.

Pipes changed all that - and if OS X users today think their systems are eminently more 'maintainable' then pipes are one of the reasons why.

Doug's suggestion for the pipe token was the 'hat' ('^'). This was later changed to 'bitwise OR' ('|'). All programs were written to accept input from the keyboard and output to the screen. In addition the 'screen' was defined as one of two things depending on the circumstances: it could either be the standard output or it could be a special 'error' output (for displaying error messages.)

Once all programs accepted this model it was easy peasy to connect apps together in pipes. The following automatically removes duplicate lines in 'myfile.txt'.

cat myfile.txt | sort | uniq

And so forth.

Abstract Assembler

Ken Thompson began work on Unix in a language he himself developed - as much of what happened at Bell Labs almost by accident. Intent on playing a computer game, he decided to write a Fortran-H compiler for his PDPs but got sidetracked and came out weeks later with a truncation of the Multics language BCPL. Always cryptic, Ken decided to merely truncate the name as well.


BCPL had a lot of resource heavy constructs such as the 'valueof' token which could take a block of code of up to 4 KB. The PDPs had perhaps only 16 KB to run programs in, so 'valueof' was out of the question. And so forth.

Ken made B an 'interpretive' language. Instructions were left in plain text form until runtime; then one by one they'd be transformed into 'machine code', one of the two languages a processor must understand. As this transformation itself takes time and as a lot of computer processing is iterating through loops, interpretive languages aren't particularly fast.

After the first abortive attempt to show off the new operating system (at which time heckler Kernighan came up with the name) Ken and Dennis decided they needed a better language. That language turned out to be C and it was written by Dennis.

'C is a language that does what the machine does and does it well', explained Brian to one of the contributors to this website. And that just about sums it up. C is a 'von Neumann' model language. John von Neumann essentially defined the way computer systems have to work - as long as they're 'instruction oriented' as most are.

The essential 'processor gymnastics' can be readily defined. Processors need to be able to fetch and store things in memory; they need to be able to shift the contents of their registers to multiply and divide; and so forth.

C is specifically constructed to be able to accommodate all possible von Neumann operations - and to leave things emphatically at that point. Some CPUs have been capable of rotating register contents - but not all, and rotation is not necessary for a von Neumann machine. Rotation is therefore not a part of C as it wouldn't be universally supported; 'macros' can easily effect a rotation if it's needed.

Once Steve Johnson showed Dennis Ritchie that his language was indeed portable (Johnson estimated the portability at 94%) then Unix itself became portable. And once Unix was portable the world had a viable standard. And it's because the C language can handle things in such an efficient manner - essentially as an 'abstract assembler' - and can therefore be used for systems development that there can be a universality in computer systems today.

Research Model

Ken's grant for PDPs was motivated by a need at Bell Labs for a word processing system for patent applications. To Ken - and to Dennis and Brian and the rest - the Unix system was otherwise just a 'cool thing'. And yet they knew they were going to be working in an environment where everyone would share the same hard drive space. They were also aware their work had to be protected.

Unix didn't start as an attempt to create a super secure operating system but the pieces were already in place. 'This is mine, that is yours. I can let you in if I want to but you won't get in if I don't want you to.' Privacy. Safety. And above all: the same principles apply to the operating system itself: no one can touch it.

Ideas like these are simply unknown in the personal computer 'home brew' market where it's enough of an achievement to get 40 column output on a television screen.

Unix was born in the era of 'server' operating systems and that's one of the main reasons it serves the Internet so well today.

Cryptic Ken

If I had to do it all over again I'd spell it 'create()'.
 - Ken Thompson

Many have wondered about - or marveled at - the thoroughly cryptic nature of Unix. It's not called 'copy' - it's called 'cp'; it's not called 'move' but 'mv'; and so forth. There's been speculation if this was actually a character trait or if it was because of the 'primitive' conditions under which the team worked (with paper telex output and so forth).

But anyone who's had to stop over in the Microsoft world of MS-DOS appreciates what they the Unix team have done. 'You mean I have to type 'COPY' all the time?' Just a couple of extra keystrokes - multiplied by the thousands of invocations and millions of users - and it's obvious what's been saved.

But Ken is more than cryptic. 'Keep your hands off the drivers' is one of his most famous maxims - this as a followup of the guidelines of Doug McIlroy. And it's of course a wonder to see how many other software houses didn't listen - and got royally screwed up as a result.

In Ken's world you don't muck about putting functionality for one thing inside the casing of another. A 'command interpreter' is supposed to interpret commands - not tell you the time of day or brew your coffee.

Layers of code is an important concept as well. It's just not nice for user land code to dig into drivers - and of course it should be prohibited: look what idiots like Unsanity and their users are doing today.

Everything has a proper place in the world of Ken Thompson and the world at large can only benefit by it.

Summing Up

The Doug Eminence, the C language, the security model, the compartmentalisation: they all play a part in explaining what Unix is and why it's so superior; but even taken together they don't come close to describing the big picture.

At the end of the day Unix is instead a 'way of thinking' - and a way that can't be put into words: you have to use the system to understand it. Dennis Ritchie said it like this.

'Unix is basically a simple operating system - but you have to be a genius to understand the simplicity.'

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.