Recommended Reading: ``The Art of UNIX Programming'' and ``The UNIX-HATERS Handbook'' The books being recommended are ``The Art of UNIX Programming'' by Eric Raymond and ``The UNIX-HATERS Handbook'' by various. They may be found at the following URLs, respectively: http://catb.org/~esr/writings/taoup/ http://web.mit.edu/~simsong/www/ugh.pdf Also, have a look at this: http://www.art.net/~hopkins/Don/unix-haters/login.html Two of most famous products of Berkeley are LSD and Unix. I don't think that is a coincidence. --Anonymous This recommendation is different from the others, as it recommends two works this time. The former, TAOUP, isn't being recommended for its merit, but, instead, as a work to be glanced over and reviewed while reading the latter, TUHH, which is the main subject this iteration. The UNIX-HATERS mailing list is such a USENET list for rants concerning UNIX and its various deficiencies. TUHH can largely be considered a commentary on UNIX interspersed with many such rants. It is well-written, flows nicely, and can be read in a matter of hours, especially if the reader has already used UNIX for some time. This work is often dismissed as old and thus invalid, but perhaps the strongest point is how many of the complaints are still valid today. Arcane syntax and rituals, preventable failures, a lack of fundamental features, an unforgiving nature, and the emulation of hardware from the 1960s (and more!) is still very much alive in the UNIX tradition as seen today. Much of this is contrasted with other systems of the time that avoided most or all of these issues. The fourteen chapters detail, with highlights: the birth of UNIX UNIX is remarkably similar to a virus and it spread like one, collecting useless traits as it went. People are often mistaken about things originating from UNIX. how it treats its newest users All or most command names, including that of the help system, are cryptic. Tools don't forgive mistakes. the documentation issues, when documentation exists The help system is inconsistent. mail frustrations This is among the first of many incorrectly-implemented standards. the ``joys'' of using USENET the terminal and all of its quirks on top of quirks Every program is forced to embed its own terminal-controlling code. X-Windows or ``This is not the ultimate window system, but I believe it is a good starting point for experimentation.''^1 A research project on a teletype operating system is the GUI you must use. the ``tools'' UNIX provides for programming Why have real communication or standards when you have pipes? programming in the UNIX environment The bugs are the interface. C++ system administration as system babysitting There are dozens of formats for dozens of tools. a lack of security A single mistake is all it takes. the unstable filesystems The file-based operating system has a lowly notion of files. NFS Looking at this list, some annoyances have largely disappeared, some have only been exacerbated, and others have been abstracted under other programs that usually work, but not always. A great deal of the fun is finding exactly what these are. To its credit, the GNU project has eliminated many implementation frustrations in UNIX life, but what wasn't caused by implementation was caused by design, which GNU has been less hostile towards. TAOUP is recommended reading as an example of the ``UNIX weenie'' archetype. The entire work should be read with a heavy skepticism, as disadvantages and ills of UNIX are understated, ignored, or played as positives while the advantages are grossly exaggerated. At times, there are lies concerning the origin of concepts, such as ``Open Source Software'' or the concept of the pipe^2 being UNIX or simply heavy-handed implications of such. Many things considered good are said to have been ``implicit'' in the ``UNIX tradition'' and many things considered bad are said to have been part of the reason other systems have failed. The author of this review is of the opinion that UNIX is a brand-name simplicity that fails at being simple; try reading TAOUP with this in mind. The two works share topics in parts and the difference in perspective is interesting, to write the least. I recommend reading all of what the two works have to say about sendmail. For good reason, TAOUP largely sidesteps discussing actually programming in UNIX. The twentieth chapter of TAOUP does explain some issues with UNIX design, but often handwaves them away. With regards to a UNIX file being an ordered collection of bytes: On the other hand, supporting file attributes raises awkward questions about which file operations should preserve them. It's clear that a copy of a named file to another name should copy the source file's attributes as well as its data - but suppose we cat(1) the file, redirecting the output of cat(1) to a new name? Vomiting a file is a very interesting operation, which usually requires reset be used to fix the terminal or stty sane when reset fails, which occurs often enough to require knowing this. The tradeoffs between supporting file metadata and how this affects vomiting files is an ongoing discussion to this very day. If you find yourself skeptical of my recommendation, observe this:^3 FCNTL(2) Linux Programmer's Manual FCNTL(2) ... Mandatory locking By default, both traditional (process-associated) and open file description record locks are advisory. Advisory locks are not enforced and are useful only between cooperating processes. Both lock types can also be mandatory. Mandatory locks are enforced for all processes. If a process tries to perform an incompatible access (e.g., read(2) or write(2)) on a file region that has an incompatible mandatory lock, then the result depends upon whether the O_NONBLOCK flag is enabled for its open file description. If the O_NONBLOCK flag is not enabled, then the system call is blocked until the lock is removed or converted to a mode that is compatible with the access. If the O_NONBLOCK flag is enabled, then the system call fails with the error EAGAIN. ... BUGS ... Mandatory locking The Linux implementation of mandatory locking is subject to race conditions which render it unreliable: a write(2) call that overlaps with a lock may modify data after the mandatory lock is acquired; a read(2) call that overlaps with a lock may detect changes to data that were made only after a write lock was acquired. Similar races exist between mandatory locks and mmap(2). It is therefore inadvisable to rely on mandatory locking. UNIX is ``the file-based operating system'', yet supports useless advisory locks and the implementation of real locks are nonstandard and broken. In closing, and to put some more of myself in this recommendation than is usual: Hello there. I've had many discussions about data formats and, being one of the popular systems, UNIX-likes come up often. I prefer numerical data formats, also known as binary formats; these tend to be smaller, easier to manipulate and verify, easier to parse, among other advantages. A disadvantage of these is the need of specialized tooling for creation, manipulation, and display with regards to human use. I've been of the belief that UNIX favors textual formats primarily because these enable ostensibly generic tooling to be used and not for any other particular reason. That is, you can create them with ed, display them with more or less, and so on. It is my belief this was due to sloth more than anything, considering the various textual formats common have different syntaxes and other qualities that I'd think preclude an overarching design consideration. Would you be able to give any information or perspective on this view? I appreciate your taking the time to read this email. That is what I asked Doug McIllroy, but after a tad of back-and-forth, he has decided to not answer. Footnotes: 1 The X11 email announcement can be found here: http://www.talisman.org/x-debut.shtml 2 Observe a concatenative language for an example of easily passing output of one procedure as input of another. The UNIX ``pipe'' is nothing innovative and is considerably less advanced and useful than other, similar systems. 3 Issuing man fcntl on a GNU/Linux system should display roughly this man page, probably. .