The UNIX-HATERS Handbook

Over the last few days I’ve been reading the excellent UNIX-HATERS Handbook. In case you haven’t had the pleasure to read it yet or worse, haven’t heard of it before, it is a collection of stories, rants, design flaw analysis and newsgroup posts about UNIX. It is also writing in a highly cynical and amusing way that will definitely bring you hours of amusement if this geeky type of humor is your thing. It certainly did for me. Don’t take it too lightly though as it has been one of the few books I’ve had to put down for some time in between my reading sessions and not rushed through. Of course that might be caused by the fact that beneath its cynical site it is nonetheless very technical reading material.

Now before you can run away screaming that you can’t be bothered to read or moreover buy such a nerdy book let me tell you that it is distributed for free as a .PDF file. After we have established that you can obtain this work legally without payment I’ll transition over to it’s content. During this post I’ll quote several times from the book. This will be accompanied by footnotes. ¹

At least after one last historical bit. You see, the book was released during the nineties, which makes it ancient in terms of relatedness concerning computer science. Now while I’ll be the first to admit that I probably didn’t understand everything I can tell for certain that I am able to relate to some of the mentioned issues having come across them myself during either my time spent with Ubuntu Linux or during some… let’s call them “terminal experiments” on my Mac.

Why would they ever want to do that?

One of the favorite things to worry about of application developers, be it the designers or the coders, seems to be the users reason to create special use cases. Let’s start this section with a nice historic example which sounds pretty ridiculous in our modern days.

Why would you ever need to point to something that you’ve drawn in 3D? ²

In my opinion there is a lesson to be learned from that. You cannot try to anticipate every possible usage scenario that the users can and will come up with. To minimalize the damage however one can try to do extensive user testing during development and not fret to listen to the users, or community as they are mostly called nowadays after your product has been deployed. Look at yourself. How often have you had to bend a misbehaving piece of software to your will in order to get your desired output?
The answer is probably quite often. However, you being a person with reasonable computer skills will be able to do that. Average users won’t be able to do that and moreover they are not willing to do that. Either your software can achieve the user’s goal or it cannot. If not it will be replaced.

Having fun with sed

Some people, when confronted with a Unix problem, think ‘I know, I’ll use sed.’ Now they have two problems. ⁴

sed is a difficult topic, I’ll give you that. All the while being pretty helpful when trimming, changing, extending and otherwise transforming text it is a useful command. Of course it’s not the engineer’s fault it can also be overly complicated, especially if you need to perform multiple commands so that you better outsource them to a file or else… Or when you either have to change the symbol which is used to signal the separator between its command sequences. Or when when trying to hack around limitations which are system dependent like sed not understanding /n on OS X.

Y2K38

The ultimate example of careless Unix programming will probably occur at 10:14:07 p.m. on January 18, 2038, when Unix’s 32-bit timeeval field overflows… ⁵

Wikipedia tells me that the problem of using a 32bit integer to store system time and date is nowadays mitigated by using 64bit integers. Maybe the person who first thought of the old implementation was convinced that mankind would never see the year 2038. Well, to be fair he was pretty darn right that he’d never see that year given our life expectancy. Wikipedia also tells me that the newer implementation limits the year to 2,147,485,547. I wonder if - theoretically speaking - there might be people around cursing that stuff no longer works at 2,147,485,548. I think I’d consider this design flaw repeating itself quite funny.

Security

Beware of the sysadmin claiming to be improving security when editing these files; he is referring to his job, not your system. ⁶

I can remember only four times when I had to modify these files without a GUI. Two times during installs of Archlinux while heavily relying on their great wiki. The other two times I wrecked my system.

Design principles

One of my favorite quotes, being a Mac convert since December 2010 is the following one about what the target audience of various operating systems looks like:

The fundamental difference between UNIX and the Macintosh operating system is that UNIX was designed to please programmers, whereas the Mac was designed to please users. (Windows, on the other hand, was designed to please accountants, but that’s another story.) ³

For additional laughs do not skip the chapter The rise of worse-is-better which is in the epilogue and itself an excerpt from another article.