I have read about Unix philosophy after finding out its principles may coincide with pursue of mathematical simplicity. I found an awful book that was linked there because it includes an essay “Worse is better” by Richard P. Gabriel.
Unix begun as a research operating system that spred to industry along students who enjoyed using it so much they wanted to keep it.
The handbook is a collection of messages from unix-haters mailing list between years 1987-1993. Most of the complaints are about features that were added after 1983 AT&T commercialization. Most of it also is ether obsolete or useless now.
Book presents metaphors that have no other seeming purpose other than to slander creators, users, and the operating system. Here’s a “…
I have read about Unix philosophy after finding out its principles may coincide with pursue of mathematical simplicity. I found an awful book that was linked there because it includes an essay “Worse is better” by Richard P. Gabriel.
Unix begun as a research operating system that spred to industry along students who enjoyed using it so much they wanted to keep it.
The handbook is a collection of messages from unix-haters mailing list between years 1987-1993. Most of the complaints are about features that were added after 1983 AT&T commercialization. Most of it also is ether obsolete or useless now.
Book presents metaphors that have no other seeming purpose other than to slander creators, users, and the operating system. Here’s a “joke” from the book that amuses. Does it remind you of something current, not made by Ken but somebody else?
Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong.”
I picked out sections that have remained relevant to discuss about each:
- Cryptic commands
- Accidental deletion of files
- Pipes being difficult to use
- ‘rm’ -command hazards
- Bad documentation
Re: Cryptic commands
Unix commands remain short and “cryptic” and cherished. Frequently used abbreviations are memorized after experience with the system. It would be nice to know for certain why Unix commands and directory names are so short.
Short commands were likely great on a teletype. Each 5 characters away of a name took half a second away from typing it when you could write only 10 characters per second.
Practice got stuck after machines got faster. This means it was a deliberate choice. Multics, predecessor of Unix, had long command names with abbreviations. Eg. change_wdir (cwd).
The book suspects that the cause of short command names was the ASR-33 teletype keyboard’s long key travel and hand-bruising structure. Theres a problem in this explanation: Keyboard would have been replaced if it had been a problem. Videos about restored units in action would not seem to be harsh to fingers.
Re: Accidental file deletion
You can erase a file if you mix the input and output in any command. I didn’t get ‘gcc -o foo.c foo’ to overwrite the ‘foo.c’ but after searching a bit I found a compiler that still erases the outfile.
It’s possible to prevent damage by not opening the outfile before reading the start of the input. This would let a program to throw an error before writing any output. However it can complicate the program.
Re: Pipes difficult to use
It is acknowledged that pipes can be used to compose existing programs. The book complains that the feature is not perfect: Pipes do not provide bidirectional communication, cannot send pointers or file handles, or access permissions.
The writer proposes 1993 Machintosh does it better because it caters to users rather than programmers. Monolithic programs on that platform do not communicate together and files are specific to an application.
Unix users are programmers. Files are symbols. Shell is a programming environment, and should be treated as such.
Re: ‘rm’ that removes files
Unix has a particularly heinous command to remove files called ‘rm’. It actually removes the file instead of sending the file to trash or hiding it. It follows the conventions and shell treats it same as other commands.
This means you can destroy lots of important files with a single command. It is too effective for what it was created for and making it less effective is inconvenient.
Blame lands on the ‘rm’ command and some of that blame could be justified. But the real problem is elsewhere.
Re: Bad documentation
There’s a whole chapter for documentation. The situation has become worse than described in the book and the fragmentation has progressed, Now you find documentation everywhere and you have to guess where it is.
In worst case you don’t find any documentation, in another case you find 500 pages worth of text that disregards when, why and how it is being accessed.
Programmers do not get feedback respective to their documentation because people shy from contacting the author. Though contacting does not matter if the feedback is negative.
People are conditioned to expect service irrespective of how rude they are to a person providing service. On top of that they also either exploit or at least disregard the emotional connection authors have to their software. In our culture, professionals are not supposed to have these feelings.
Harsh feedback requires greater effort to be understood and therefore it is likely to be ignored. Note that the issues presented by the UNIX HATERS HANDBOOK were never fixed, the software simply became obsolete and new software piled over it.
However if Unix vendors, users and software authors had considered each others feelings, then most of the unix-haters handbook content would have never been even close to being written in the first place. Unix would not look like it does today but even if it had, people would have found out solutions instead of defaulting to bicker about the system’s apparent flaws.
Instead of being something worthwhile, open source can also be an exploitation of nice people. Do not be rude to people, and do not bother servicing if people are rude or uncaring at you. Taking responsibility over other people’s emotions is a requirement for having a meaningful interaction.
Commercialization
Here’s a guidebook that many software companies appear to follow.
- It benefits you if users know less about the system.
- It’s better if the program is incompatible if it is not expected to be compatible with anything else.
- Pride is raised about new features with disregard on how it affects the utility of existing features.
After you’ve successfully rounded the users into your ecosystem, they start behaving like cattle and mooing at you. Now you can start to treat them and programmers alike cattle and sparingly feed with shiny trinkets, transparent widgets and fashion trends.
Judgement & remarks
Unix haters handbook is a heritage of people whose culture arrived to Unix before them and spoiled it. They’re criticizing themselves: Predatory commercial interests with focus on exploitation. Motivation for work reduced to exchange of enough money to satisfy the lowest two steps on Maslow’s hierarchy of needs.
There is no need for anybody to free the developers, and it would not do good anyway. If an imprisoned is suddenly freed to nature without rehabitation she will perish. However if you know what’s going on, you can rehabit yourself.
Btw. On unrelated note there’s a reason or two for why BSD mascot has a fork. It’s for the gluteus maximus... of people who like to spawn nasty things.
Computer science would have progressed much further and faster if all of the time and effort that has been spent maintaining and nurturing Unix had been spent on a sounder operating system. We hope that one day Unix will be relingquished to the history books and museums of computer science as an interesting, albeit costly, footnote.
It’s always somebody elses fault and there’s a better solution that is new and just invented. Except that it features something that was in Multics or Scratchpad.
Dennis’ review
Dennis Ritchie’s anti-foreword in this book is cleverly written and mentions similar things I’ve written here. Though it matches the style of the book and has been written in analogues. The style is difficult to interpret so I provided a translation:
- Analogues or metaphors in unix-haters handbook, since they’ve been disconnected from their context and their authors, are empty of content.
- According to the authors Unix is an incoherent and flawed system, however the core concepts in Unix, the filesystem structure, files as interfaces, pipes, text based user interfaces, “cryptic command names”, process forking and execution, have outlived most other systems or become so common that vendors are forced to support them in their own systems to stay relevant.
- Authors have not educated themselves or studied history of their profession to judge whether the content they published is relevant or attempt to solve the right problems. Systems they propose as alternatives are nothing to be taken seriously. Dennis is joking at the blue user interfaces that are an eyesore, likening it to playing games and repeating frequently done things such that they become somebody’s job. However this is only an one interpretation of the analogy, he is perhaps also joking at the crash screens of modern systems that are ascii-art installations devoid of any meaningful information.
- The criticism in the book is not constructive or attempt to solve the problems. It is left as an exercise for the reader, or alternatively the proposed solutions are poorly conveiced on closer examination.
- Judgement: The book is as good as excrement.
However on a historical perspective it might be a significant study piece. This is a collection of coprolite from prehistorical cows.
Discarding of Unix
The culture took its toll, there is not much more to do than to discard what was spoiled by adding features to cater people who didn’t value it in the first place.
Indeed, as Unix is pushed to be more and more, it instead becomes less and less. Unix cannot be fixed from the inside. It must be discarded.
Definitely I know that anything Unix after System-V has not been viral. It is unable to spread on new platforms on its own. This makes it vulnerable, were the original virus ever rejuvenated. Meanwhile everybody is trapped into this fancy prison they made themselves.
Yet your prison without coherent design continues to imprison you. How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos; instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalists with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.
Hey maybe it’s Ritchie’s fault! In any case, Bon appetit!
2020-11-13 update: Changed the post a bit but spared the last draft. if you’re interested about writing then you may be interested to compare the old.index.md and index.md in this post. The worst problem there is that I fell to slander in the same way as the book when discussing documentation. I catched it on the last rewrite.