Beginning motto (inspired by „Fiddler on the roof”):

• Most free Unixes are computer geeks’ kids, so obviously they’re not for the mortal people. Nowadays developers make an effort to patch those systems to simplify usage of them for the masses. And, despite the efforts of ‘bazaar’ developers, it goes rather slowly or maybe that’s why… - said Guru. Tewie remained quiet.
• I know… - Keyto didn’t like the idea.
• Eh, Keyto. Firstly, the Linux society, to accelerate working, hire salaried programmers… Secondly, where do Unixes come from?… Third of all, they weren’t desktop systems from the beginning! And finally - KDE and GNOME are patches, or subsystems, if you don’t like the word ‘patch’, attached to the completed system. Like back then Windows 3.xx was a plugin for DOS. How long are you going to pretend that it’s not true? I’m comparing the idea, not functionality. Windows was user-friendly from the beginning.
• You’re right - admired Tewie.
• But Tewie! UNIX, Linux no matter how it’s called has totally different constructional philosophy. Saying that KDE is a patch is misunderstanding! - Keyto looked a bit annoyed and expressed his arguments for a longer while.
• You’re right - admired Tewie.

At that point michuk couldn’t stand it anymore:

• But, Tewie, if they are both right… They cannot be right at the same time!

Tewie looked at him and said:

• You’re absolutely right.

And now in order I’ll express my own arguments to prove I’m right.

Chapter 1: UNIX

This story begins – as usual – long long time ago, far far away, behind the Ocean, in United States of America, in Bell Laboratories building. In that firm a computer stood. Nothing special about it, but in 1969, when those events started, computer wasn’t commonplace at all. There were no Personal Computers, no Microsoft, IBM or Apple. None flame wars… Romantic time. Apropos – the computer processing time was priceless at that time. And there was a problem: a certain machine, narrowly DEC, model PDP-7, was doing nothing, standing uselessly in its room (yes, computers had their special rooms). So it’s not surprise that one of the biggest computing gurus — Ken Thompson — was asked to take care of it. Such a great machine couldn’t be wasted in any way. Thompson called for other gurus, including the man who worked with systems programming before – Dennis Richie and they together created an early version of a first UNIX system. They were developing it for some time without any special publicity using other machines at the later stage (e.g. PDP-11/20). To code UNIX more efficiently, they developed a new programming language called “C”. And then… Life started to be very, very complicated.

Chapter 2: The Rules

For those, who don’t know: computer programs aren’t made the way that “somebody sits in front of computer and writes a program”. That’s a myth, distributed by people living in a place called Hollywood. Programs come into being in their creators’ minds, written down on paper (yes - regular paper), quite often modeled on UML diagrams and eventually at the very end of that entire process they are implemented. Implementing basically means to give a program particular shape, i.e. translate programmer’s ideas into code in selected programming language. It’s important to adopt rules. Breaking them is not acceptable. Order has got to exists especially in science, particularly in maths and programming. Otherwise the program won’t work correctly, even worse — modifications can be impossible in the future. As any other system, UNIX bases on some foundations. Which is the most important of them?

Chapter 3: The KISS rule

In reality creators of the systems like Linux, BSD, Mac OS X and others are inspired by the idea of the KISS rule. Every other rule is only its consequence. Apples never fall far from the tree, similarly the rules came from the mother to children. This rule is used in the distributions like Slackware, Arch or Crux. Success has many fathers, that’s why computer scientists claim that they made that phrase (particularly hackers from MIT), as well as economists, mathematicians, biologists… We can count many of them. Someone interested in philosophy, knows that similar rule was coined by William Ockham (a.k.a. Ockham’s Razor), who lived in 1285-1349. For sure he didn’t have a computer and he wasn’t an economist (but who knows). Personally I think that KISS rule is as old as Mother Earth… But, but, maybe I should finally tell you what that rule says. KISS is an acronym from “Keep It Simple, Stupid”. If some of you think that’s a bit too offensive, well — that’s the point. Currently it’s also known in its more gentle form like “Keep it Simple and Stupid”, “Keep It Short and Simple”, or “Keep It Small and Simple”. Back to what Ockham said (beware! a pinch of Latin): Entia non sunt multiplicanda praeter necessitatem which can be translated as: entities should not be multiplied beyond necessity. And I like that phrase the most.

As we know, in programming we can reach out goal in many different ways. Are all of them equal? NO! The easier are better!

Just because they are:

• Easier to write,
• Easier to maintain,
• Easier to change (if needed),
• Easier to share with other people,
• Easier to port to other platforms,
• More immune to bugs and…
• Often simply faster

Anyway if you don’t program - ask some experienced programmer. Small chance that he won’t agree with that.

The first consequence of the KISS rule is:

Chapter 4: the DRY Rule

Don’t Repeat Yourself

When you write a program you can go with one of these strategies: write code line after line, and when you realize that what you’re going to write has been already done, you use the best computer scientist’s friend that is the “copy-paste” sequence. That’s not the best solution. Instead of that — functions (procedures) were created to simplify it. Function with repeated code are writing once, and then called in many places. But that’s still nothing. To make it more useful, elastic and simple, you have to follow another rule:

One sentence - one procedure.

We receive many single functions, saying more visually: “toy bricks”, each of them gives us particular functionality. When one of those bricks needs to be fixed, no problem — we fix it, or rewrite it. The rest of the code won’t even “know” about that, as long as that brick is giving the same functionality using the same interface. That rule operates also in operating systems, and for sure, in UNIX family. Following the brick analogy, UNIX is a kernel (engine) forming the interface (don’t mistake it with the graphical interface…) and a whole lot of small programs — “the bricks”, each of them being a solution for some problem.. When we have a complex problem to resolve, from the available “bricks” we build a more complex solution.

Chapter 5: Simplicity of construction vs user-friendliness

I emphasize that once again: simplicity of a UNIX family system concerns their construction. It’s not related with simplicity of using the system directly. Although… let’s look at this stupid example:

srv@srv # ps aux | grep kowalski | \\
grep service_program | tee log.txt

Let’s assume that Mr. Kowalski doesn’t know what do commands like ps, grep and tee mean, as well as that strange sign which looks like a vertical line. He doesn’t know how to put it together to make it work. Let then our administrator make a script for him and the problem is resolved.

Maybe another more convincing example: a commonly known and admired by many multimedia program: MPlayer. It is — just a reminder — a rather hard to use console app. Even though I use it myself, I just can’t remember all of its commands, because… there is a graphical interface for it, which gives me the functionality I want. One problem - one procedure. Separate program plays the movie, another one gives us the interface. MPlayer is a great program by itself. If you don’t like its GUI, write your own! You can’t program? Find another one already made. There is plenty of them. One functionality (excellent) to just display a movie, another one to simplify its usage. Analogically like in another UNIX system — Mac OS X. The Darwin System – makes it work. The Aqua interface on top of it — is a hero everyone adores.

Chapter 6: Other Rules

The KISS rule implies other consequences. For example - everything is a file. Cynical people add: “even when it’s not a file”. So what? Experienced programmers know that some fundamental rules have to be followed with consequence. Otherwise the goal won’t be achieved — we’ll never finish the project and we’re going to look like the mythical Sisif: when it’s almost over we realize that there is a bug that we have to fix, so we start all over again. It can seem weird for regular user but it’s not that weird from the system construction’s point of view. It works already for a few dozen years!
And every command is a single process. Command interpreter is basically a user process. These fundamental rules were accepted, and they just work. And they work in our favor.

Chapter 7: More on those toy bricks

One of the advantages of a UNIX system is the possibility to replace any part of the system with another provided that it has the same interface/functionality. You don’t like BASH? Use tcsh. You don’t like KDE? There is GNOME, Xfce.

These are those basic rules on which UNIX is based that made this system so flexible. From, desktops, servers, mainframes to supercomputers and back to small mobile devices like smartphones or MIDs…
But, can we really say that the system in a router is actually a complete system? Because…

Chapter 8: What’s mean complete system?

I once wrote an article about the kernel and operating systems in majority. Let me quote myself:

there are two definitions of operating systems. Usually we’re saying that operating system is a program which runs from the moment that we start the PC until we turn it off (or reboot). Any other programs are the user programs. Following that definition, the term operating system is the same as the kernel. Using other words, we can put the equality sign between those two terms. We can also say that the kernel provides some environment for other programs.

But generally when we say “operating system” we’re thinking about all programs that are provided by some producer as response to some requirement for a working environment. That’s why we tend to use “Linux” as the name of the whole system when in reality it’s only name for of the kernel.

End of quote.

So what does it mean “adding functionality” or for instance “patching system by adding graphical interface by force” (go back to the motto from the beginning of this article)?

If we use the first definition, kernel (Linux) is the complete operating system and everything else is only a group of user programs (bash interpreter, X window system, KDE, etc). In such case we cannot talk about “adding functionality” because it’s the very way the system was built. Or maybe we actually can do it, but then every case is equal, whether it’s bash, X server, the GIMP, vim or KDE, they all add some functionality to the system. What’s interesting, the same applies to Windows or OS/2. They also have kernels and user programs. Can we say that the Aero (Vista’s interface) is a patch to the Windows kernel? In that case we can (but does it change anything?)

But if we accept the second definition… Then there is no such a thing as “complete system”. Debian GNU/Linux is a complete system. Period. Same thing with the GoboLinux, MS Windows XP, or whichever version of OS/2 Warp. And same with the operating system built into the router or the firewall, correct?

Epilogue

In the article above I only touched one topic. We can write thick books about the UNIX philosophy – that system came into being around 40 years ago. But I wanted to stress that something that is a disadvantage for some individuals can be priceless advantage for others. Mostly I wanted to emphasize that we cannot mistake the fundamental philosophy of a project which gives it almost endless opportunities with the (dubious) fact that it’s unsuitable for normal users. Because why would average Joe care about what’s under the hood of his favorite user interface? What some people call “patching” I call “adding new functionalities” and it’s not merely a word game. The main feature (and advantage) of UNIX is that developers can add new “bricks” onto it. Even the ones that no one was dreaming about when it was originally designed.

P.S. Next episode will be less philosophical, because I’m going to talk about the procedure of booting up UNIX the system and how it actually works. Stay tuned!