UNIX Haters’ Handbook Review

UNIX Haters’ Handbook Review By Myself

The UNIX Haters’ Handbook [ PDF ] is an amazing book. In general technical books, most of the reasons for writing are that the author particularly likes a certain technology, and happily takes it out and shares it with the readers.

And several authors of this book are all because they hate UNIX to the point of “people grow and hate water grows east”, so they set up a mail group to collect all kinds of anger, and finally based on the various posts posted in the mail group. Complaining, compiled into a book such as the Haters’ Handbook, to vent anger against UNIX, is also unprecedented. </p>

Although this book has a unique perspective, from the current point of view, only 50% of the author’s complaints belong to the inherent problems of UNIX. Unique. The other 50% is quite historical, and you can see how “original” the UNIX system was. Especially compared with the current Linux, it can be seen that Linux, as the successor of UNIX, has made great progress in the file system, security, stability, and so on.

Criticism of Unix

Apart from some criticism of specific bugs in UNIX, behind this book is actually a confrontation between three design philosophies, which I call the MIT philosophy, the UNIX philosophy, and the GUI systems philosophy. The term “MIT philosophy” is borrowed from the famous Worse is the better article. The representative of the MIT philosophy is the LISP machine, that is, the machine that provides a LISP environment.

This machine provides users with an elegant programming environment, such as unified memory management, unified functional interface, good documentation, etc. Everything programmers need is ready. But the system was not successful either as a personal computer or as a workstation.

History of UNIX

The GUI system philosophy started with Xerox’s Alto and was quite popular before Windows 95 appeared in the mid-1990s, especially in the field of personal computers, where almost all personal computer manufacturers are providing their own graphical interface operating systems.

The philosophy of the GUI system is a friendly user interface and a consistent user experience. As for the specific function, it is delegated to the specific application to realize.

The UNIX philosophy is like a philosophy of an open system: it does not emphasize system consistency except for providing unified system calls and standard tools (POSIX). UNIX is like a system with a pile of loose building blocks. Under the premise of complying with the POSIX standard (in fact, it is a very loose standard), each manufacturer can choose the building blocks to build the system.

UNIX’s openness, allowing free building blocks, is incompatible with those who believe in the MIT philosophy. These users complained about the inconsistency of UNIX because of openness. For example, a well-criticized shortcoming of UNIX is that its command line parameters are not uniform. Under the command line, some commands add -h to display help, some to display hidden files, and some commands do not accept the -h parameter at all.

Bugs & Issues of Unix

Such problems reflect the lack of a unified plan for UNIX’s evolution. This is unthinkable on other operating systems with a single evolutionary path. For another example, the computing model of UNIX is very simple. It uses C language and shell to make a glue package for system calls, does not provide memory management and does not provide exception handling, and the file system is also very low-level.

It does not support file recovery or file metadata. Information storage. The computing model and storage system of MIT’s LISP machine look more advanced, unified functional interface, automatic memory management, and so on.

People who have used LISP machines are naturally not accustomed to such a “low-level” operating system as UNIX. As a result, in addition to complaining about UNIX, users who have used LISP Machine can only seek to build a new layer on top of UNIX to make up for UNIX’s shortcomings. One result of this is the creation of the monster Emacs.

In the end, almost everything that can be done in UNIX can be done in Emacs. In this way, Emacs completely replaces the UNIX environment with the exception of the operating system kernel. Emacs is so powerful that everyone agrees that Emacs is an all-purpose software, while vi users joke that Emacs is an operating system that lacks a good editor. Everyone knows that the author of Emacs is Richard Stallman from MIT.

About Author of UNIX

The authors of The Haters’ Handbook are also technologists who have worked for many years in MIT’s AI lab. To explain UNIX’s success, he borrows the phrase Worse is better (Gabriel asserts that C and UNIX are the ultimate computer virus) and classifies UNIX as the world’s first computer virus.

The book mentions that the common features of UNIX and viruses are: 
small size, infecting a variety of hosts (portable), rapid mutation, and so on.
The book says that the popularity of UNIX is not because it is technically 
superior to other operating systems, but because it is portable, contagious, and mutated quickly,
 and it occupies a large share of users.

I think this explanation is quite accurate. Relative to other operating systems, UNIX was written in C, which was portable and early free distribution, and even if it was not technically good enough, it still spread like the flu. One pass ten, ten pass one hundred, quickly attack the city and conquer the land.

The popularity of UNIX at that time can be proved from several aspects. In the early 1980s, many new UNIX companies sprang up like mushrooms. Sun and SGI are typical examples of growing up with UNIX. They got to Nasdaq in just a few years with the UNIX workstation business. Microsoft and Apple started out in the personal computer business. They each have their own operating systems, but they also went to the UNIX world to bet. Both have launched their own UNIX distributions (called Xenix and A/UX respectively ). UNIX, the “virus”, has a very strong parasitic ability on workstations and servers.

It was not until the emergence of “virus” Linux, which had stronger evolution and transmission ability, and a major shuffle when the.COM bubble burst. Market share fell. Linux completely inherits all the “virus” characteristics, except for the original small size and portability, by opening the kernel source code, it has created the status quo that is now ubiquitous from supercomputer servers to embedded systems. In terms of the total number of devices, there has never been an operating system in the world as successful as Linux.

It’s a pity that the MIT Philosophy itself has no successful operating system products for comparison (except Emacs, a program that runs on UNIX), so it lacks a point in criticizing UNIX. In order to write a thick hater’s manual to hit UNIX, it takes anger from the other side, the users who believe in the GUI philosophy.

The anger of these users is largely centered on ease of use. The emergence of the graphical interface operating system is essential to solve the usability problem of the computer. Before the advent of graphical interface systems, mastering the use of computers required reading thick manuals.

After the graphical interface appears, it only takes a few minutes of demonstration, and ordinary users can operate the computer to complete some simple tasks. This essential increase in efficiency is what revolutionized Xerox’s Alto and Apple’s Macintosh. What UNIX had was a bunch of two-letter commands, inconsistent command-line arguments, and an X graphics system that wasn’t really designed for GUI systems. Commands are hard to remember, and X is bloated. Even with these, it still does not form a unified desktop system (so KDE and Gnome came later), so it is no wonder that users complain.

Complaint & Criticism

One of the complaints from GUI users that I didn’t expect was a UNIX pipe complaint. The main point of criticism is that the pipeline itself is not powerful enough as an IPC mechanism, including that the pipeline does not support bidirectional data flow (there are very few use cases for bidirectional pipelines), and can only use data as a byte stream instead of parsing structured data, and pointers, etc. Wait. From the point of view of traditional UNIX users, these accusations are unfair.

The role of the pipeline is to concatenate the input and output of the program and string the small tools into a powerful toolchain. But pipes are not the only IPC mechanism on UNIX, UNIX has other IPC mechanisms to support functions beyond pipes. From another point of view, requiring the pipeline to support bidirectional communication, structured communication, etc., is a criticism of the pipeline from the GUI philosophy. In the GUI world, there are two new ways of inter-process communication: 1.

Integrate all small programs into a large multi-threaded window program for inter-thread communication; 2. Copy and paste objects between different programs. From these two perspectives, it is natural to require UNIX pipes to be as bidirectional as inter-thread communication and to support structured objects rather than pure byte streams.

GUI programs

This new set of inter-process communication mechanisms for GUI programs has changed the software architecture of the platform. The software architecture of UNIX is based on the concept of software tools (Software Tools), which boils down to the philosophy that each tool does one thing and does it best. Because of the complexity of the GUI program itself, it has become a common practice to put various functions into a large program and let each module communicate with each other directly in the process space.

For example, formula calculation in spreadsheet software does not need to be delegated to an external calculator such as bc and is directly completed by the built-in module. Under the guidance of this philosophy, in order to provide a comprehensive solution, various commercial programs pursue large and comprehensive, built-in functions that may be used, so the volume is also increasing.

It is not surprising that commercial software is several hundred megabytes in size. The UNIX hater’s handbook advocates this method of program construction that can only be regarded as a local optimum, and in turn complains that the pipeline, another local optimum, is not good enough, in my opinion, there are historical limitations.

https://wpgroupurl.com/how-to-read-someone-elses-programming-code/

Conclusion

Overall, this book represents a sharp critique of UNIX by two other philosophies other than UNIX philosophy and is worth reading as part of the history of UNIX development.