By FORMAT

“The Art of UNIX Programming” by Eric Raymond is available here: https://catb.org/~esr/writings/taoup/

“The UNIX-HATERS Handbook” by various writers is available here: https://web.mit.edu/~simsong/www/ugh.pdf
Also see this: http://www.art.net/~hopkins/Don/unix-haters/login.html

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.

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, 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:

• the birth of UNIX
• how it treats its newest users
• the documentation issues, when documentation exists
• mail frustrations
• the “joys” of using USENET
• the terminal and all of its quirks on top of quirks
• X-Windows or “This is not the ultimate window system, but I believe it is a good starting point for experimentation.” ¹
• the “tools” UNIX provides for programming
• programming in the UNIX environment
• C++
• system administration as system babysitting
• a lack of security
• the unstable filesystems
• 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.²

The two works share topics in parts and the difference in perspective is interesting, to say 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:³

FCNTL(2)

Linux Programmer’s Manual

FCNTL(2)

…

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

…
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.}

“Two of the most famous products of Berkeley are LSD and Unix I don’t think that is a coincidence”