I have just read the Unix Haters Guide which I found quite by accident whilst looking for a way to turn off an annoying feature in TOAD (an expensive tool for Oracle developers). It was a most enlightening book. I had no idea that Unix was so shonky. In short it is a pretty damning indictment of Unix.
I came to Unix from MS-DOS in the early 1990’s. I discovered, for example, that the toy operating system I’d been using had file and record locking capabilities whereas the real one didn’t. Even worse every program is apparently expected to implement it's own file locking routines; great until some other program (such as "remove files") just blithly does it stuff to your file because it is ignorant of your program.
Unix is written in C which may be ok for operating systems but is a not a great language to program in when it comes to applications. Needless to say just about every application program for Unix is written in C which lacks just about everything a good programming language is supposed to have such as array bounds checking. Fortunately I haven't ever had to do anything in C++ which is a lot worse to use apparently. Before I started using Unix I’d been using Turbo Pascal, a brilliant low cost development tool with a debugger that was years ahead of anything that was available on Unix.
Some bugs (or poor design features) in Unix persist for decades. The book accuses developers of being reluctant to fix a problem, consequently users work around the problem and now it is impossible to fix the problem because the users work arounds will break. I recently read about a bug in a Unix type system that had finally been fixed after 33 years (yes that's 33 years). Take the utility "make" for example. This utility reads a "makefile" which contains instructions on how to build a computer program without rebuilding the bits that haven't changed. The build instructions must be prefixed with a "tab" character. Not obvious if you view a "makefile" in a standard text editor, this requirement isn't obvious. If you don't know about it you could end up prefixing your instructions with 8 spaces and wondering why the make utility doesn't work and spits out some unintelligible error message. I struck this problem when I first tried to use make.
Ever tried to configure Unix? It has a multitude of configuration files in inconsistent formats, scattered around the /etc directory and its sub directories, it can also be difficult to find out what needs to be changed when you wish to configure something in particular. I don't know how people managed before Google.
Just out of curiosity I had a look at the sendmail manual. I decided it wasn’t worth it after reading about 1 page of the manual. It seems you need to write a configuration file and run this through some sort of generator to get a sendmail configuration file! WTF?
I've tried of some of the simple methods detailed in the book for crashing Unix, in the safety of a Virtual Machine, and they work well.
The authors of the book cite an announcement that Unix and C are a hoax. This apparently is an April fools joke.
Having said all that I've recently installed a Linux on my PC and will gradually be shifting my stuff off the Windows treadmill over in the next few months. The version of Linux (PCLinuxOS) I use is easy to configure, fortunately, and the user is shielded from having to mess about text files.
I'll probably be a bit more skeptical about Unix being an "advanced operating system" in future.
You can obtain this book in pdf form via this link http://www.simson.net/ref/ugh.pdf
I came to Unix from MS-DOS in the early 1990’s. I discovered, for example, that the toy operating system I’d been using had file and record locking capabilities whereas the real one didn’t. Even worse every program is apparently expected to implement it's own file locking routines; great until some other program (such as "remove files") just blithly does it stuff to your file because it is ignorant of your program.
Unix is written in C which may be ok for operating systems but is a not a great language to program in when it comes to applications. Needless to say just about every application program for Unix is written in C which lacks just about everything a good programming language is supposed to have such as array bounds checking. Fortunately I haven't ever had to do anything in C++ which is a lot worse to use apparently. Before I started using Unix I’d been using Turbo Pascal, a brilliant low cost development tool with a debugger that was years ahead of anything that was available on Unix.
Some bugs (or poor design features) in Unix persist for decades. The book accuses developers of being reluctant to fix a problem, consequently users work around the problem and now it is impossible to fix the problem because the users work arounds will break. I recently read about a bug in a Unix type system that had finally been fixed after 33 years (yes that's 33 years). Take the utility "make" for example. This utility reads a "makefile" which contains instructions on how to build a computer program without rebuilding the bits that haven't changed. The build instructions must be prefixed with a "tab" character. Not obvious if you view a "makefile" in a standard text editor, this requirement isn't obvious. If you don't know about it you could end up prefixing your instructions with 8 spaces and wondering why the make utility doesn't work and spits out some unintelligible error message. I struck this problem when I first tried to use make.
Ever tried to configure Unix? It has a multitude of configuration files in inconsistent formats, scattered around the /etc directory and its sub directories, it can also be difficult to find out what needs to be changed when you wish to configure something in particular. I don't know how people managed before Google.
Just out of curiosity I had a look at the sendmail manual. I decided it wasn’t worth it after reading about 1 page of the manual. It seems you need to write a configuration file and run this through some sort of generator to get a sendmail configuration file! WTF?
I've tried of some of the simple methods detailed in the book for crashing Unix, in the safety of a Virtual Machine, and they work well.
The authors of the book cite an announcement that Unix and C are a hoax. This apparently is an April fools joke.
Having said all that I've recently installed a Linux on my PC and will gradually be shifting my stuff off the Windows treadmill over in the next few months. The version of Linux (PCLinuxOS) I use is easy to configure, fortunately, and the user is shielded from having to mess about text files.
I'll probably be a bit more skeptical about Unix being an "advanced operating system" in future.
You can obtain this book in pdf form via this link http://www.simson.net/ref/ugh.pdf
No comments:
Post a Comment