As proposed here the next book of the Nixer's Book Club is gonna be «The UNIX-HATERS Handbook».



Quoting from wikipedia:

Quote:The UNIX-HATERS Handbook is a semi-humorous edited compilation of messages to the UNIX-HATERS mailing list. The book was edited by Simson Garfinkel, Daniel Weise and Steven Strassmann and published in 1994.

The book is online for free here (just follow the links).

The book has short chapters, so I think we can do 2 to 3 chapters per week.

• The first session of this season of the book club will be January 30, when we'll discuss about the first 3 chapters (I'll bump this thread then).
  
• The second session will take place on February 6, we'll discuss chapters 4 to 6.
  
• The third session will take place on February 13, we'll discuss chapters 7 to 9.
  

Very nice, count me in! I've always wanted to discuss this book in more depth.

Excellent, I'm looking forward to the discussion!

Whoop, let’s get this started! :)

Hello, I wanted to chime in that I joined so could participate in this book club. Sounds fun!

(27-01-2021, 02:47 PM)ylambda Wrote: Hello, I wanted to chime in that I joined so could participate in this book club. Sounds fun!

Welcome to nixers!

(27-01-2021, 02:47 PM)ylambda Wrote: Hello, I wanted to chime in that I joined so could participate in this book club. Sounds fun!

Fantastic! Glad to have you on board.

(27-01-2021, 02:47 PM)ylambda Wrote: Hello, I wanted to chime in that I joined so could participate in this book club. Sounds fun!

Hi, ylambda! welcome to nixers and to the book club!

It's time to bump this thread.
How was your week? Have you had a good reading?

UNIX: The World's First Computer Virus

This chapter has four topics:

• UNIX as an evolutionarily successful virus.
  
• UNIX as an economically successful drug.
  
• Standardization.
  
• UNIX myths.
  

The chapter begins by comparing UNIX with an evolutionarily successful virus. It explains that the reason for its success was not because UNIX was technically superior, but because, like a virus, it was evolutionarily superior.

Both virus and UNIX share the following characteristics: they are small (minimal, don't have too much in it), portable (can (invade) be ported to different types of hosts), requires attention of the host to be succeed, and are able to mutate very quickly.

The chapter than tells the story of the UNIX, praising how MULTICS was designed to be good while UNIX was not. It also explains how, like a virus accumulates random genetic material, UNIX accumulated random bloat software.

IIRC from TUPE, # and @ were used as line editing commands in old terminals. The chapter also cites it as one of UNIX accumulated genetic material.

The chapter now goes to another metaphor: UNIX as a drug. Now, another reason for UNIX success was, again, not because it was technically superior, but because, like drugs, it was economically superior.

On the topic of standardization, the chapter says that users want a Standard UNIX, but vendors don't want it. They want to stick the user with their own version of UNIX, in order to avoid competition.

Quote:I think UNIX and snowflakes are the only two classes of objects in the Universe in which no two instances ever match exactly.

The result of the lack of uniformity among UNIXes is the effect of throwing #ifdefs at the code.

Quote:I don't know if there's a moral to this story, other than one should never trust anything related to UNIX to be compatible with any other thing related to UNIX.

It cites the standards: POSIX, X/Open, CORBA(?) and even OpenStep.

The chapter closes talking about the UNIX myths. As drug users lie to themselves (“pot won't make me stupid”, “I can stop anytime I want to”, etc), UNIX users lie to themselves too. UNIX has its own collection of myths:

• It's standard (now it is, kinda).
  
• It's fast and efficient (yes, it is).
  
• It's the right OS for all purposes (well, there are not other options...).
  
• It's small, simple, and elegant (I believe the UNIX I'm using is indeed).
  
• Shell scripts and pipelines are great way to structure complex problems and systems (I agree it's not the greatest or most elegant way, it's more like a glue).
  
• It's documented online (when it is documented...).
  
• It's documented (except when it isn't).
  
• It's written in a high-level language (I cannot opine on that as C is the only language I know well).
  
• X and Motif make UNIX as user-friendly and simple as the Macintosh (now we have Qt and Gtk!)
  
• Processes are cheap (now they are (but I still have to replace some fork(2)s with a bloated single process some times)).
  
• It invented the hierarchical file system, electronic mail, networking and the Internet protocols, remote file access, security/passwords/file protection, finger, uniform treatment of I/O devices (if it hadn't invented them, it at least popularize them).
  
• It has a productive programming environment (yeah, it hasn't, the environment is left for the user to set it).
  
• It's a modern operating system.
  
• It's what people are asking for (it's what I asked for).
  
• The source code is available (now it is, and for free as in freedom!), understandable (except if you use GNU stuff). And what you buy from your manufacturer actually matches what you are running (not applicable).
  

Welcome New User: Like Russian Roulette with Six Bullets Loaded

This chapter goes on how UNIX is not newbie-friendly. It has six points that defends that:

• Cryptic command names.
  
• rm(1) accidents (it has long texts for this topic).
  
• Inconsistency (yeah, I admit, it still annoys me).
  
• Documentation (the next chapter deals more about it).
  
• Error messages.
  
• The UNIX (philosophy) attitude.
  

Unlike the LISP world of verbose-command-names, UNIX way of naming things is quite cryptic (two letter commands). It cites as a footnote one situation in which Ken Thompson was asked what he would have changed about UNIX if he had it all to do over again (He would spell “creat(2)” with an “e”). I remember this story from TUPE (page 204).

The chapter then goes on a long text full of examples on how rm(1) can be destructive, irreparable and irreversible.

Quote:UNIX abuses our trust by steadfastly refusing to protect its clients from dangerous commands. In particular, there is rm(1), that most dangerous of commands.

It reckons some reasons why files die more often under UNIX than under any other operating system:

• The UNIX file system lacks version numbers (solved on plan9).
  
• Unix programmers have a criminally lax attitude toward error reporting and checking (I must admit, I do that).
  
• The UNIX shell, not its clients, expands “*”.
  
• File deletion is forever.
  

I have a trash(1) command that moves files into a XDG-compliant trash directory and an untrash(1) command that move files back. But I must admit that I always forgot to use them, and keep deleting important stuff. If you are interested in those scripts, here they are.

There is a mail that this chapter quotes that occurred EXACTLY to me:
In my keyboard the greater-than (>) character is the shifted period (.) and to type an asterisk (*) I have to keep shift pressed. So I miscalculated the timing and kept shift pressed from the asterisk when I was typing a period, so instead of rm *.o, I typed rm *>o. Curiously, the “o” file isn't deleted.

The book then says how permanently and irreversibly deleting important data with rm(1) is considered by comp.unix.questions' FAQ as a rite of passage in the UNIX environment. Hehe.

Now the book goes to the inconsistencies in UNIX, that, I must admit, annoys me.

Quote:Predictable commands share option names [not on UNIX. -v is verbose or version? -h is human-readable or help?], take arguments in roughly the same order [have you used find(1) today?], and, where possible, produce similar output [Let's not talk about ps(1) output].

Indeed, Macintosh had a user-interface standard (for its graphical interface), as did NeXT, but the command line interface is the wild west. There is no common standard other than the oral tradition.

Quote:No such body has ever existed for UNIX utilities. As a result, some utilities take their options preceded by a dash, some don't. Some read standard input, some don't. Some write standard output, some don't. Some create files world writable, some don't. Some report errors, some don't. Some put a space between an option and a filename, some don't.

Quote:The highest achievement of the UNIX-aesthetic is to have a command that does precisely one function, and does it well. Purists object that, after freshman programmers at Berkeley got through with it, the program “cat” which concatenates multiple files to its output now has OPTION

And thus the cat-v movement was born.

The chapter reckons some flaws of UNIX way of handling arguments:

• (1) The * wildcard is expanded by the shell, not by a library by the program.
  
• (2) Options (switches) and other arguments should be separate entities, as they are in DOS.
  
• (3) UNIX filenames are permissible (tabulation, dash, and EVEN NEWLINES are tolerated).
  

[opinion]
Although I understand the simplicity of giving programs their post-processed calling command, we cannot deny that it is inconsistent how programs parse their argument. Not all of them use getopt(3). Some cannot use it.
I think that rather than passing argc and argv, passing an actual structure with pre-parsed options would avoid the need to call getopt(3) and would keep things more regular.
[/opinion]

The chapter discuss a little more about possible and impossible filenames, and tells the story that some “UNIX victims” turn the filename-as-switch bug into a “feature” by keeping a file named “-i” in their directories:

Quote:Type “rm *” and the shell will expand this to “rm -i filenamelist”
which will, presumably, ask for confirmation before deleting each
file. Not a bad solution, that, as long as you don't mind putting a
file named “-i” in every directory.

I have never heard about this. Sounds terrible.

Some commands use dashes to indicate “please ignore all following dashes”. This is a bad solution, in my opinion.

Online documentation.
More on the next chapter.

The chapter then goes to the topic of error messages, and how UNIX refuses to give them. This section ends with a set of error jokes, most of them not applicable in modern systems.

It then summarizes the chapter:

Quote:We've painted a rather bleak picture: cryptic command names, inconsistent and unpredictable behavior, no protection from dangerous commands, barely acceptable online documentation, and a lax approach to error checking and robustness.

And of course, the chapter shills on the UNIX philosophy.

Documentation: What Documentation?

This chapter's topic is the UNIX documentation, the man pages, which, second the author, are “nothing more than a collection of reminders for people who already know what they are doing”, and that use “a set of text formatting macros used for nothing else on the planet”.

One of the first complaints about man pages is the lack of hyperlinking.

Quote:Today's hypertext systems let you jump from article to article in a large database at the click of a mouse button; man pages, by contrast merely print a section called “SEE ALSO” at the bottom of each page and invite the user to type “man something else” on the command line following the prompt.

There was an alternative to man pages that uses hyperlinking: GNU info pages. But nobody likes GNU info pages. I think that a SEE ALSO section with only related man pages is better than the hyperlink hell other documentation systems may have.

The chapter then talks about SystemV man page directory system (/usr/man/c_man). I had no idea of the existence of such a thing. Thank goodness I have never found it in any system I have used.

It then shows a mail about the quest of a user to find the location of a man page.

Then, the chapter talks about the lack of man pages to shell built-in commands. I think that the number sectioning system is bad. Named sections would be more helpful. For example, “man bin/awk” for binaries, “man lib/printf” for system and library calls. This setting could be even expanded with “man bin/awk/printf” to get the manual of a builtin command of a shell (or of awk).

The chapter then goes on internal usage notices some programs have. Some of them have a “-h” option to show usage, or show the usage when no argument is given. But again, this is inconsistent.

Then, the chapter reveals that the actual documentation is the source code, as man pages generally reveals nothing useful. It talks about NeXT file system hierarchy structure, with /NextDeveloper/Headers as a path for included headers. Damn, the file system structure was a wild west back in the days. Binaries in /lib, headers in different directories scattered all over the place...

The books is hilarious from the get go, halfway between serious rants and poetic prose.
It shows that you aren't alone in your pain with a unix system.

Quote:To Ken and Dennis, without whom this book would not have been possible.

Quote:Why would you spend so much time and effort writing about what you hate if you didn't secretly love it.

Quote:No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog.

So far Ritchie is right, all metaphors, jealousy, emotions, nagging, and not many solutions.

The tone of the first 3 chapter is more or less similar, namely "It's horrible, but there's really nothing better for now", "The best of the worst".

Quote:Unix survives only because everyone else has done so badly.

There's a definite emphasis and contrast on one side with a rosy retrospection, how the past was perfect and solid.
While on the other side, there's also a feeling that Unix is stuck in time and doesn't move on, isn't made for machines of the future.

Quote:Why didn't we learn the lesson from it and move forward?

There are lot of mini-stories about bugs or issues happening to random users. Some of them are relevant today, some aren't.

Sun machines seemed to have been missing a good debugger. ELF was probably not there at the time.
There's a nostalgia about LISP machines and how they don't require thinking about memory management.

I really like one of the author's other book "The Design of Everyday Things", Donald Norman, which has a focus on how instinctive and intuitive interfaces are.

Chapter 1 tries to compare Unix with computer viruses. I don't find that metaphor really powerful when you have a bit of knowledge in the field of evolutionary biology — this applies to any living entity or even ideas (memes anyone).

I love how the author describe Unix as having been written on a whim to be able to play Space Travel.

There are a lot of complaints that aren't really valid today:
- Reliability
- Memory mapped files
- Better command line with completion
- Debuggers
- Standardization (more or less)

And funny remembrance of the Unix war and name battle:

• AIX is Unix from IBM
  
• A/UX is Unix from Apple.
  
• They’re both AT&T System V with gratuitous changes.
  
• Then there’s HP-UX which is HP’s version of System V with gratuitous changes.
  
• DEC calls its system ULTRIX.
  
• DGUX is Data General’s.
  
• And don’t forget Xenix—that’s from SCO.
  
• Initially everyone wanted to call themselves Unix but it got trademarked by AT&T.
  

It's true that there's a myth of Unix being a standard systems.

Quote:This notion of standards breaks down when applied to software systems. What sort of specification does a version of Unix satisfy? POSIX? X/Open? CORBA? There is so much wiggle room in these standards as to make the idea that a company might have liability for not following them ludicrous to ponder. Indeed, everybody follows these self-designed standards, yet none of the product s are compatible.

You always have to mention CORBA when you mention bad stuff >_<

Chapter 2 is about first impressions, the interface to the system and how archaic it is. Obviously, everyone knows that part.
The naming conventions are cryptic and they stay the same way for backward compatibility. Which leads to lack of consistency and confusion from users. There's also no way to directly distinguish between shell built-in and commands.
And you're left wondering if shell built-in should have their own documentation or not.

There's a lot of complaints about `rm` and glob being dangerous.
Basically the whole system choosing to put the responsibility on the user. Be it for the worse or the best.

There's a good section about special characters in filename and how they get intermixed with arguments.


The authors pose a really good point about documentation having an out of date format and not being enough for today. It's true that, also according to them, the best way to learn is through oral stories and anecdotes. Or even by having source code as documentation (that you might even have to steal for that)

Hey maybe nixers could be a provider of unix gurus!

Quote:- Obtaining & maintaining a personal UNIX guru
- feeding your guru
- keeping your guru happy
- the importance of full news feeds
- why your guru needs the fastest machine available
- free Coke: the elixir of your guru’s
- life maintaining your guru’s health
- when DO they sleep?

The concept of Unix not having evolve and stayed in the past come up again all the time:

Quote:The Unix documentation was so concise that you could read it all in an afternoon.

Overall, the first few chapters set the tone: Unix is stuck in the past, we're stuck in the past of the past, and we'd like to jump to a future we don't know but we'll point out all the faults of the present.

Thank you for the warm welcome!

Excellent write up venam and phil! I found your reviews helpful to recollect my thoughts. I wrote much less, here's what I prepared beforehand.

Ch. 1

I believe the 'accumulation of random genetic material' piece is spot on. Unix has collected many historical remnants and refuses to let go, taking decades to give it up. The saga of init systems comes to mind, or the slow march towards wayland. I think this is a result of how diverse the atmosphere is.


Ch 2

I had never come across the filename as flag example before. Had to give it a try and of course it worked as described. I'm not sure I believe that's an ideal scenario for unix, but here we are.

Ch 3

Sums up my experience nicely. I find man pages mostly useless except for something I already know is there, or searching for an obscure feature for fun. Thankfully the internet has been able to answer my queries for 'how to x'. I'm not sure I'd make it in a early 90's computer world.


Overall I find the book's complaints thus far about unix to be similar to problems I've directly experienced. I think the issues have improved over time, but still exist and are inescapable for anyone to avoid. Reading this is both infuriating and fun. Sorta like hate-watching a bad movie.

Can we set three chapters again for the next Saturday?

(31-01-2021, 11:32 AM)phillbush Wrote: Can we set three chapters again for the next Saturday?

As far as I'm concerned the book is light enough that it's feasible for me.

Ch 4.
This chapter describes the various ways in which sendmail is a faulty program. I have little experience using sendmail directly. I end up using it via libraries in whichever language I'm working with. It's always worked great for me. I haven't done much with handling delivery of emails on a system either.

Quote:STEP 1: Figure out what is address and what is body

A story is told about sendmail parsing the body of an email incorrectly, using each word as a cc address. As a joke, I will email a friend with the whole message sent this way. Interesting quirk of email I've never thought about.

Quote:Unix believes so strongly in standards, it has (at least) three separation
characters: “!”, “@”, and “%”. The at-sign (@) is for routing on the Inter-
net, the exclamation point (!) (which for some reason Unix weenies insist
on calling “bang”) is for routing on UUCP, and percent (%) is just for good
measure (for compatibility with early ARPANET mailers).

Here's more examples of old email addresses formats:
Sample business card with bang paths
I'm happy where email landed, using DNS and a single separator. I can't imagine using bang path format. Seems so easily broken.

Also UUCP was new to me. After some research into this old-tech, I found it's still being used today. There's a project aiming to develop communication tools for remote areas (e.g. Central America) that have little money to afford the costs of satellites. Instead they're using High-Frequency radio to build out a GSM network. Wikipedia mentions this project near the end of the article.

https://www.rhizomatica.org/hermes/

Ch 5. Usenet

Quote:Newsgroups with large amounts of noise rarely keep those subscribers who
can constructively add to the value of the newsgroup. The result is a
polarization of newsgroups: those with low traffic and high content, and
those with high traffic and low content. The polarization is sometimes a
creeping force, bringing all discussion down to the lowest common
denominator. As the quality newsgroups get noticed, more people join—
first as readers, then as posters.

This little bit resonates with me, I often find the smaller communities I participate in more rewarding long-term. I'm slowly trying to increase my time spent on the internet being part of smaller, or niche communities, spending more time reading from websites that focus on specific content, and trying to carefully craft my own portion of internet. This happens naturally for anyone using the internet, finding sites to visit frequently isn't hard at all. What's different for me is trying to stay away from large catch-all websites like Reddit and find my own communities. I'm about a year into the process, and constantly trying to change my own habits.

How does a website or community become part of your daily/weekly routine?
Any of them you want to mention?

Quote:rn commands are a single letter, which is a fundamental problem. Since
there are many commands some of the assignments make no sense.

Any of the arguments made here about how this news reader works feel irrelevant today. Usenet is much less popular, and this no longer is how most people get their fill of daily discussion. Also, use a different program then. This chapter did not make any argument against unix specifically, and instead harped on the failings of usenet and a newsreader. Beyond users of unix being (historically) highly active on usenet, I don't see the connection here.

Ch 6.

I would love a better terminal, something that can draw properly. No curses, or ascii. No DEC Sixel type graphics. Would love to be able to "cat an image" file on a remote server. I want vim to feel like a graphical IDE. Let me mouseover and see typing information, when I debug code I want to be able to inspect the state of every variable. Yes using a mouse with vim, sacrilegious, and yes vim CAN show this information, but it does so within the limited blocks of a terminal.

Re: Escape codes
I guess using escape codes is a badge of honor, but not one I'm proud to wear. I think we can do better. I don't ever see that changing, however.

Chapter 4 is about mail on UNIX and UUCP.

Just like ylambda, I have done a small research about UUCP, as it is something new to me.

Chapter 5 is about the Usenet.

This chapter deals more with the behavior of Usenets users and its social aspects than with the technical aspects and implementation of the Usenet. Most of the chapter still applies to the WWW.

Quote:Newsgroups with large amounts of noise rarely keep those subscribers who can constructively add to the value of the newsgroup. The result is a polarization of newsgroups: those with low traffic and high content, and those with high traffic and low content

This is still valid in the Web and its forums.

Chapter 6 is about the terminal and TUI.

It begins explaining that the way UNIX was designed for teletypes is the Original Sin of the system, as much has evolved since those days.

The chapter describes three ways different operating systems handled different terminal manipulation procedures. UNIX chose to use a library that must be linked with every TUI program. This library just hides the fact that the UNIX kernel still thinks to be communicating with a teletype.

(06-02-2021, 10:19 AM)ylambda Wrote: I would love a better terminal, something that can draw properly. No curses, or ascii. No DEC Sixel type graphics. Would love to be able to "cat an image" file on a remote server. I want vim to feel like a graphical IDE. Let me mouseover and see typing information, when I debug code I want to be able to inspect the state of every variable. Yes using a mouse with vim, sacrilegious, and yes vim CAN show this information, but it does so within the limited blocks of a terminal.

That's exactly what I think. But its the consequence of the original sin the book talks about.

This chapter talks a little bit about the X windowing system and how it was supposed to make UNIX work on bitmap displays. More on that on the next chapter.

Three chapters that go into emails, the internet, and terminals. The idea that backward compatibility gets in the way is still inherently present.

That first chapter focuses a lot on sendmail and its drawbacks. The mail systems today on Unix aren't any better either. I've had my share of hell setting up postfix, dovecot, and anything in between.

The unicode standard wasn't that strong back then, fortunately we don't have as much problems with that today.

The metaphorical more or less non-sense rants go a long way about sendmail, that just shows how much there was frustration.

Based on an IRC convo with josuah there are some more alternatives today that are probably simpler. Like qmail, notqmail, and OpenSMTPD.

In the chapter after that we dive into something not so Unixy: the internet of the time. The rant is much like today's web rant, and they admit it's "not about tech but about sociology".

(06-02-2021, 10:58 AM)phillbush Wrote: This is still valid in the Web and its forums.

"news", "netnews", "Usenet", software that brought the advent blogging and the web. Which is all "Based on name-calling, harassment, and letter-bombs", "mob rule and public lynchings", "Free speech!", "insightful, obnoxious postings", "polarization of newsgroups", "smarty pants that want to reply to see their name in the light"... Yep! It isn't any better today. I guess people are just not nice in general. newsgroup are the ancestor of Reddit, and the "netizens" weren't any better either.

(06-02-2021, 10:19 AM)ylambda Wrote: How does a website or community become part of your daily/weekly routine?
Any of them you want to mention?

I've been limiting any community that is a "bubble" or driven by whatever I mentioned above such as the polarization and emotional rollercoaster. I have enough in my daily life then to go online and feel like everyone is shouting all the time 😂.

The chapter about terminals is the one that resonates the most with the backward compatibility issue theme.
Different terminals have different standards and libraries (termcap, curses, terminfo) are created to try to avoid the problem and use a less-efficient common denominator. Yet, we haven't moved from this legacy system and aren't able to use smarter terminal features. We're stuck on text-stream terminals even though we could have so much more. Terminals now equate with green-on-black text consoles in most people's mind even though that's not what it actually stands for. It was supposed to denote the controlling end of something connected to a machine.
I agree with both ylambda on that, we missed on new features.

Overall, the sentiment of the book is still present in these chapters: a resentment for not moving on but also feeling like somehow it was better before and the timeline could've gone another way. Seeing the rant about the internet of the time... Maybe the timeline doesn't change after all, and it's just wishful thinking.

I have a little catching up to do, but I have to say, this is a very strange book.

The authors really hate Unix. Yeah. So much that I have a little bit of trouble understanding what they’re talking about. It’s rant after rant, so many metaphors. It reminds me a lot of a certain toxic german subculture, where people just complain for the fun of it (how … how is that fun?). Honestly, this makes it a little hard for me to read. :)

They hardly pinpoint exactly what’s wrong. Most of it is just vague rambling. Or I’m simply too blind or too biased to understand.

It’s also, obviously, really dated. Most of the stuff doesn’t really resonate with me – except for this one:

Quote:[John Rose’s e-mail:] Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. … If there’s a window involved, it closes right up. … This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, just restart …

Modern software takes this to the extreme. Crashing app on a smartphone? Not even intended to be debuggable. Normal users don’t want that. Just kill it, the user can restart it.

Lots of desktop software isn’t better, either.

It’s funny how my “base line” is programs that write log lines. This is what I usually consider good software, because thanks to the log lines you have a rough idea why it crashed. It didn’t even cross my mind that something like putting the user in a debugger, where you can inspect the program’s internal state, might be a better idea. Oof. Then again, we have long lost that battle – what would I do in a debugger for, say, a PDF viewer? Vim? My VTE-based terminal? Way too complex.

(09-02-2021, 12:14 PM)vain Wrote: (how … how is that fun?)

I guess this is the sort of thing you either get or don't. But in the case of UHH, I think it's safe to say that they are complaining because they have lost environments that they used to prefer to Unix, which we arguably haven't managed to reconquer. As such, it seems legitimate.

The X-Windows Disaster

This chapter rants about how the X basic programs don't deal with basic graphical user interface.

Quote:X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.)

The chapter explains how the lack of user interface by the X protocol resulted in different user interface standards.

Quote:X gave programmers a way to display windows and pixels, but it didn't speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards.

The chapter criticizes the X design of implementing “mechanism, not policy” and separating the window management from the window server. That resulted in various different and inconsistent ways of user interaction, compared with the single consistent user interface of Macintosh (the author cites Macintosh a lot in this chapter).
All of it resulted in the creation of ICCCM, which, I agree, is a dense and difficult standard. Compare it with the modern and simpler EWMH.

Quote:In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, [...]

The chapter then goes on the myths widespread by X:

• X Demonstrates the Power of Client/Server computing: The chapter explains how the division of labor between the client and the server must only be decided on an application-by-application basis.
  
• X Makes Unix “Easy to Use”: So little of Unix is designed for the desktop metaphor (such as “drag-and-drop”) that it's “just one kludge on top of another”. And then something I didn't know: xauth(1) has an interactive mode.
  
• X is “Customizable”: The chapter explains how the X Resource system is broken.
  
• X is “Portable”.
  
• X is Device Independent: “X is extremely device dependent because all X graphics are specified in pixel coordinates.”
  

The chapter exalt the NeWS Window System a lot of times during the chapter. It also exalts the NeXT's window server.

csh, pipes, and find: Power Tools for Power Fools.

This chapter is the first of a series of ranting about how UNIX is a programmer-oriented system.

Yet another example of feature creep:

Quote:Unix power tools don't fit this mold. Unlike the modest goals of its designers to have tools that were simple and single-purposed, today's Unix tools are over-featured, over-designed, and over-engineered.

There are three main topics on this chapter:

• The Shell (especially csh) and the inconsistencies between them, and the problem of quoting metacharacters;
  
• Pipes, and how they are a simplistic IPC mechanism.
  
• Find, and how arcane its syntax is
  

Programming: Hold Still, This Won't Hurt a Bit

Unfortunately, I had no time to read this chapter, my week was too busy (first week of this semester of the uni), I'm gonna read it in this afternoon, after doing my chores.

Chapter 7 was a rant about X11.
It's interesting how the nagging about X11 memory usage is similar to today's nagging about Electron-apps and web-browsers.

Quote:Even today, the X server still turns fast computers into dumb terminals. You need a fairly hefty computer to make X run fast — something that hardware vendors love.

We know today that the idea of running graphic programs over the network is lacking as it can't use graphic acceleration. So many X extensions have been made to bypass its initial design and use direct graphic rendering.

On that note, I had never in my life ran `xauth` in its interactive mode, I had no clue it even existed. That whole section reminds me of the thread we had about all the ways to start an X11 server.

The rant definitely comes from a while back, a time where fonts where still hosted in the X11 server. These were ugly and couldn't even use anti-aliasing because of patents.

There's a point to be made about the fact that there aren't any standard GUI toolkit. The author calls it "user interface Tower of Babel". We do have the ICCCM "standard" but even today it is hard to respect and comply with, along with EWMH as a subset.

Looking back at it, in my opinion, that's an issue about the lack of overarching power-structure that would dictate who can do what and what is standard and what isn't. There aren't authorities enforcing and deciding for others, there are rough standards because it's mainly driven by open source and free contribution, at least today.
We can clearly see how people react today when someone tries to enforce their vision on others with projects from RedHat... Not everyone likes this.

On the other side, this can give rise to the "cognitive black holes" that the author talks about, because of the ever-increasing complexity and fracture. "Feature creep".

The resource location section killed me. It's definitely true, a resource could be in a million places for X11. At least now there are libraries that will search all the places for it. But the reverse would mean having a central registry, so back to the previous point.

And don't worry about all the "XFillRectangle" and "XDrawRectangle" issues, now we have Wayland and you'll deal with OpenGL constructs instead.

Chapter 8 about csh, pipes, and find.

Again with the theme of "it was good in the past but what it is today doesn't fit the case". Also, in relation with feature-creep.

The author argues that leaving flexibility in the hand of the users slowly but surely will lead to failure. I'm not sure about that. Imagine the opposite scenario, where we are handed the whole pristinely designed OS from above and are not left with any room for improvement, nor allow any other devs than those from a certain group to touch it. Is that good, back to the previous point? I'm not sure, but I think the author would be fan of the centralization movements happening today.

Quote:When was the last time your Unix workstation was as useful as a Macintosh?

These days I have no idea...
Mac was indeed made to please non-techie users while Unix was targeted at developers. I'm not sure of that either.

I love the argument that the shell is mostly unused. This just opens up opportunities for ways in which it could be upgraded. But that also doesn't mean we should remove it.

Chapter 9 on Programming

I think the author likes lisp a lot.

Ch 7.

Hey look we still have x and all it's baggage. I appreciate the work put into wayland, not easy to replace something as prolific as x.

Ch 8.

Quote:As soon as a feature was added to a shell, someone wrote a shell script that depended on that feature, thereby ensuring its survival. Bad ideas and features don’t die out.

Agree, wish it wasn't this way so often.

Another quote that grabbed me.

Quote:...you spend all your time learning to do complex and peculiar things that are, in the end, not really all that impressive.

The chapter ends with an email from Jamie Zawinski which caught my eye, I remember reading his interview in the book Coders at Work. Not surprised he was determined enough to find the file using the shell.

Ch 9.

Quote:Experienced C programmers know to ignore all but the first parse error from a compiler.

I don't think this is unique to C or the unix environment.

It's time to bump this thread.

Chapter 10. C++

Quote:Like Unix, C++ was never designed, it mutated as one goofy mistake after another became obvious. It is just one big mess of afterthoughts.

The chapter rants about C++, much of the chapter is about the complexity of the language and the fact that much of C++ users actually use a subset of the language, which is more sane to do than using the language as a whole.

Quote:Every C++ programmer can create their own dialect, which can be a complete obscurity to every other C++ programmer

The chapter compares C++ with an Object-Oriented Assembly, because of its lack of elegance, abstraction and power.

The chapter inconsistently change the subject from C++ to C a lot of times:

Quote:C weenies will tell you that one of the best features of C is the preprocessor. Actually, it is probably the worst.

Chapter 11. System Administration: Unix's Hidden Cost

This chapter begins the last part of the book: The Sysadmin's Nightmare.

The chapter compares administrating a Unix system to babysitting it.

Quote:According to one estimate,every 10-25 Unix workstation shipped create at least one full-time system administration job, making system administration a career with a future;

The chapter rants about the difficulty of tuning and running a Unix system, the garbage it lets behind, and the number and inconsistency of system configuration files.

Chapter 12. Security: Oh I'm Sorry, Sir, Go Ahead, I Didn't Realize You Were Root

The chapter is about the the design flaws of Unix that prevent it from being secure.

• The superuser with absolute powers.
  
• The SUID (which I agree with, it's a hack).
  
• Process forking.
  
• Having "." in your $PATH
  
• Startup traps in rc files such as vi's .exrc
  
• Hidden files.
  
• Disk overload.
  

Chapter 10 — C++

I don't get the point of this particular chapter. I'll reiterate: The author does indeed like lisp a lot.
Regarding the last Hello World example, I've seen similar things with over-architecture today.

chapter 11- sys admins

Quote:sysadmins are highly paid baby sitters.

That's a funny quote. I think everyone liked it.

The filesystem at the time wasn't very solid. Most of today's filesystem have at least journaling and recovery mechanism.

Swapping is still a major problem, but at other scales.

The discussion related to centralized configuration files for all programs being bad is intriguing. In my opinion it's really not a bad thing, the other approach is to have each program containarized, à la nixOs, with their configuration along with them. If they aren't containarized it becomes a real mess.

On the last part of the chapter: Managing multiple machines is indeed hard. Today we have solutions like Puppet but I can imagine how much of a pain it could be. And, rdist doesn't seem to be solid software.

Chapter 12 - security

I'm don't buy the premise of the chapter. Many of the Unix pioneers were prominent security researchers. Ever heard of Robert Morris? (Obviously, because they mention the Morris worm)?

I also don't get what's wrong with "a few tricks in the operating system's kernel to enforce some sort of overall policy". Most OS do it that way. Still the metaphors are strong in this chapter!

Super user is a weakness, lack of encryption, and audit trails, etc.. I guess we moved a long way due to the constant arms race.

The classics (also mentioned by phillbush):

• SUID bit
  
• Having . in the PATH
  
• Using startup scripts as security holes...
  
• Fork bombs...
  

Chapter 13 and 14: The File System & NFS

The chapter begins with an explanation of what a filesystem is and what kind of filesystems there are on Unix.

Quote:Its most salient feature was its freewheeling conventions for filenames: it imposed no restrictions on the characters in a filename other than disallowing the slash character and the ASCII NUL. As a result, filenames could contain a multitude of unprintable (and untypable) characters, a “feature” often exploited for its applications to “security”.

I hate the lack of restrictions on the filename. ls(1) output cannot be parsed safely.

Quote:FFS introduced a variety of new and incompatible features. Foremost among these was symbolic links -- entries in the file system that could point to other files, directories, devices, or whatnot.

I agree with cat-v: symlinks were a bad idea.

Quote:In any event, fsch can take 5, 15, or 20 minutes to find out. During this time, Unix is literally holding your computer hostage.

I remember once I had a power failure and then 10 minutes of fsck.

The chapter then goes on things that the Unix filesystem lacked:

• Journaling.
  
• Records and record-based file locking.
  
• Additional metadata associated with a file (like filetype and access control list).
  

Creators Admit C, Unix Were Hoax

Quote:In any event, Brian, Dennis and I have been working exclusively in Lisp on the Apple Macintosh for the past few years

lol

The Rise of Worse Is Better

This is a classic by Richard P. Gabriel. It talks abut the “New Jersey Style”, that writing functionally simple programs is preferable.

Chapter 13 - The file system

This is a critic of UFS (UNIX File System) and derivatives, which are barely used today, apart from NFS. So it's not relevant but interesting, I've always been fascinated by the different take of file systems.

I like the idea that file systems should support both byte level operations and block/record level operations. The author mentions databases as an example, but DBs bypass the file system for other efficiency reason than accessing as record based.
I definitely agree that text files are less efficient when it comes to record based reading.

Storing the type within the file is also something that is discussed a lot. It has its advantages and disadvantages. Here.

The most important part in my opinion is the "exploiting features of modern hard disk". Which is about placing the files on disk in a way such that they will require as less arm movement as possible. This requires a buffering mechanism to be put in place for good disk scheduling to queue writes and reads in the best way. Algorithms like FCFS (First come first served), SSTF (shortest seek time first), SCAN, CSCAN, CLOOK, etc.. See here.

Quote:Will journaling become prevalent in the Unix world at large? Probably not. After all, it’s nonstandard.

Well, it is today.

Chapter 14 - NFS

The chapter is actually a good dive into NFS.
(Nope I didn't know that the initial patent for Ethernet was held by Xerox.)

It reminds me of cool FS I learned about in the OS dinosaur book: WAFL.

Et Cetera

I like that ending about the constant fight about entropy. It's the general repeating theme of the book.
It also describes the whole experience of working in our field, and maybe the human experience too, to constantly repair, maintain, patch. It's 90%, if not more, of all we do. A love for LISP isn't magically going to fix how the world works.
And it's definitely not limited to Unix either.

Overall, I think the book was a bit too negative for my taste and not constructive enough. I'll keep to what I said in my previous reviews because I think it summarizes my overview of the book.

Quote:There's a definite emphasis and contrast on one side with a rosy retrospection, how the past was perfect and solid.
While on the other side, there's also a feeling that Unix is stuck in time and doesn't move on, isn't made for machines of the future.
It's horrible, but there's really nothing better for now.
The best of the worst.
Unix is stuck in the past, we're stuck in the past of the past, and we'd like to jump to a future we don't know but we'll point out all the faults of the present.

Cheers!