I found this review to be lacking in content. It doesn't discuss the content of the book to any extent; This is how I review things. I didn't want to write a summary of the whole book, because that is not how I feel reviews should be done. To each his own
instead it talks about how it got him a job promotion to UNIX Engineer. How did it do this? What did you learn from the book that gave you such an additional skillset to be promoted to UNIX Engineer? What are the differences between the UNIX Administrator and the UNIX Engineer you are referring to? I believe you are misreading. I was interviewing other people. My definition for admin = someone who does day to day unix operations. An engineer is someone who designs software and systems for unix.
I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms.
I've not found any books that are mostly printed man pages. Nor have I found any circumstances where the man pages don't cover things I need to know. In any case, what parts of UNIX does it explain? Is it explaining Linux or UNIX? What OS "paradigms" are you referring to? You are going by this definition aren't you? I have a handful of Solaris books that pretty much are manfiles. I was just referring to books that tell you what commands meant, nothing more.
What importance did you realize this book serving after you had read it? Are you sure this gave you applicable knowledge to separate "UNIX Administrators" from "UNIX Engineers"? What is the difference here?
Why? If it's discussing that you need to know an RFC to understand why something works the way it does (you've stated that this book talks more about the why than how), how does it make it "not-so-good"? My "went too far" comment was about the bad puns. Not the non-technical nature.
Do the few puns in the book really take that much of the quality away? No, it doesn't, I just pointed it out because some people do not like this type of humor ....
Finally, please excuse my harshness. I just feel you could have done a better, much more descriptive job. Don't take it personally I dont;-)
Yeah, same for big telco... I'm sure I signed something like that too, but I was not in a bargaining position, being unemployed for a few months will do that. I still work on my projects, I just don't take as much credit:-)
Slashdot Mirror
I found this review to be lacking in content. It doesn't discuss the content of the book to any extent;
....
Finally, please excuse my harshness. I just feel you could have done a better, much more descriptive job. Don't take it personally ;-)
This is how I review things. I didn't want to write a summary of the whole book, because that is not how I feel reviews should be done. To each his own
instead it talks about how it got him a job promotion to UNIX Engineer. How did it do this? What did you learn from the book that gave you such an additional skillset to be promoted to UNIX Engineer? What are the differences between the UNIX Administrator and the UNIX Engineer you are referring to?
I believe you are misreading. I was interviewing other people. My definition for admin = someone who does day to day unix operations. An engineer is someone who designs software and systems for unix.
I am constantly amazed at Unix books that are mostly printed man files, and things that can easily be googled. This book explains with great precision why Unix is the way it is, and what separates it from other OS paradigms. I've not found any books that are mostly printed man pages. Nor have I found any circumstances where the man pages don't cover things I need to know. In any case, what parts of UNIX does it explain? Is it explaining Linux or UNIX? What OS "paradigms" are you referring to? You are going by this definition aren't you?
I have a handful of Solaris books that pretty much are manfiles. I was just referring to books that tell you what commands meant, nothing more.
What importance did you realize this book serving after you had read it? Are you sure this gave you applicable knowledge to separate "UNIX Administrators" from "UNIX Engineers"? What is the difference here?
Why? If it's discussing that you need to know an RFC to understand why something works the way it does (you've stated that this book talks more about the why than how), how does it make it "not-so-good"?
My "went too far" comment was about the bad puns. Not the non-technical nature.
Do the few puns in the book really take that much of the quality away?
No, it doesn't, I just pointed it out because some people do not like this type of humor
I dont
Yeah, same for big telco... :-)
I'm sure I signed something like that too, but I was not in a bargaining position, being unemployed for a few months will do that. I still work on my projects, I just don't take as much credit
My Zaurus runs linux and Java, but I hear there are licensing problems with the Personal Java they are using....
UNIX admin 5 years, BA Philosophy with a minor in Psychology...
Silly me thought I would never get a job playing with computers....