Linux Books

Short review of Open Systems Standardization, A Business Approach, Carl F. Cargill, Prentice Hall, 1997.

Mr. Cargill is a long time information technology standards participant who writes with a considerable depth of experience on standard development organizations and corporate standards departments. This book builds on his previous book, Information Technology Standardization: Theory, Process and Organizations. It appears targeted towards those active in the standards professions as it quickly jumps into the language of the field without benefit of a glossary or definitions section.

The over 300 page book is divided into three sections. The first section of the book explores the basis for standardization and discusses the need for open systems and the concomitant need for open standards and open organizations. Chapter 5 explains two dimensions of standards: practice/conceptual standards and process/product standards and then develops a four state model of standards. Chapter 6 identifies and develops two different views of standards: user and provider, which is expanded in the following chapters into a useful standardization planning model consisting of five elements: reference model, industry standards, functional profile, systems profile and applications implementation. The extensive discussion of company organizational structures in Chapters 6, 7 and 8, while interesting and related to the idea of open organizations, seemed a bit off-topic.

In section two, The Application of Standardization, the author's considerable background in standards development shows. He provides an insider's view of the operation of a company standards department, a detailed explanation of how a standardization development organization (SDO) operates, and explains the operation of different SDOs with a focus on the American National Standards Institute procedures. This section also offers a business-oriented view of standards discussing standards as "infratechnologies," the effect of standards on the product life cycle, and business expenditures on standardization.

In section three, The Organizations, again the author's depth is evident as he describes the operation of the major international SDOs (ISO, IEC and ITU), consortia (not formal SDOs: Open Software Foundation [OSF], X/Open Company, Limited, Unix International, Object Management Group and others), Regional Standards Bodies (ECMA, CEN, CENELEC and ETSI), along with IETF, ANSI, IEEE and US governmental standards bodies. This reviewer finds this the most detailed and accurate tour of the information technology and telecommunications standards world (US-centric) available in a single volume. The only formal US organization left out was the Telecommunications Industry Association.

In summary, Carl Cargill is a "Standards Man", steeped in the legends, language and lore of his field. If standards are your chosen field, this work is worth reading.

This quick reference guide to Perl 5.000 was always close at hand when I was learing Perl. It provided just enough detail to remind me of the sticky points of syntax and usage while being lean enough to find items fast. It is a truly useful companion to both the Camel book (Programming Perl, 2nd edition) and the Llama book (Learning Perl).

These days I don't use it as much, mainly because my knowledge of Perl has grown to the point where I have fewer questions of usage, but also because I have the CD-Rom edition of O'reilly's "Webmaster in a Nutshell" which contains a full text version of "Programming Perl". I can now look things up electronically in about the same time I could on paper.

Perl's quirky syntax and the attitude built into the language of there's always more than one way to do it, makes having multiple reference sources a requirement, if only to find the Perl guru who thinks like you do. Vromans uses a clean, straightforward style which is a refreshing change from the sometimes too humorous style of Larry Wall and Randal Schwartz.

"Perl Debugger Pocket Reference" is a relativly short introduction into the command line Perl Debugger (perl -d option). You will find the following main chapters in this book:

- Introductory chapters (partly meta chapters not about the debugger but about good programming)
- Debugger Commands
- Debugger Variables
- Debugging Options
- Debugger Internals, Quick reference, rest

When I bought this book I had hoped for a "...Pocket Guide" and not a "...Pocket Reference" (deeper coverage). I consider this not an extreme "...Pocket Reference" (like e.g. "Perl Pocket Reference") because this book contains examples for each of the commands and options that it describes. For me examples are the most important part in technical books.

The language, the printing and the index (there is an alphabetic index) are of the usual high O'Reilly standard).

I think that "Perl Debugger Pocket Reference" might be a bit heavy if you never used a command line debugger like gdb or xdb before. This book assumes that you already know what and why you want to do with the debugger, you will be explained WHO to do this with the debugger. PDPR is missing the process model when using a debugger. Personally I would have wished for even more examples and a bit more about when to use a certain feature of the debugger.

For all those poor souls like me that still have to use Perl 5.5, you will not like this book because it explains the cool new features of the Perl 5.8 debugger (differences to Perl 5.6 covered as well) that are missing in Perl 5.5. I hope that I can convince my customer to upgrade to Perl 5.8 to be able to use cool new debugger (especially the w watchpoints will be great).

I will keep this booklet next to my keyboard when I am Perl programming from now on to be able to lookup the Debugger functions that I will need. If you are a Perl programmer like me that does not produce flawless code, I really recommend this book. I will use it again right after finishing this review. Perl debugging will be more fun (for me) from now on.

Describes general computer requirements for time-critical applications and related requirements for real-time operating systems. Major weaknesses of the standard UNIX System V for real-time applications are discussed, and various approaches in designing real-time UNIX operating systems are presented. The REAL/IX operating system, a fully preemptive real-time UNIX operating system, is described in detail. Two detailed case studies of designing real-time systems are included. Annotation copyright Book News, Inc. Portland, Or

This is a great 872 page book for computer professionals with some experience using UNIX/Linux or a different distribution package of Linux like SuSE. It is not a good text book for teaching new students without Linux background and limited networking experience.

Many concepts are described using "Linux terms" not understood by a beginner, and there is no glossary from which to look up the definition of these words. There are no review questions at the end of the chapters to gauge one's understanding of the material presented, and few pictures accompanying the information presented.

If you have a Linux background and want a good reference or need to learn about the Red Hat distribution of Linux - this is a very good book for you. If you are a Linux beginner, let me recommend a book called "Teach Yourself Linux Red Hat". It is a highly visual, easily understood, excellent beginning Red Hat Linux text.

Trish Millis

Clearly stated and well written book. Good potential textbook.

Whitehead's book is well suited for a new linux sysadmin, who wants an easy introduction to her main tasks on the machine. The text is straightforward and accompanied by well chosen illustrations. The book centres on using KDE as the desktop UI, instead of Gnome. Perhaps it could also have given more equal coverage to the latter?

If you are perhaps coming from a Microsoft computer background, then the types of tasks should be familiar. Like setting up the machine with an IP address on a network. Or getting the linux OpenOffice running. {It's the analog of the Microsoft Office suite.)

However, experienced linux sysadmins should avoid this book. For you, it will be redundant.

I haven't used UNIX to any extent for nearly 20 years. I was forced to administer our UNIX based internet/intranet site when our UNIX geek/guru quit. I used to HATE UNIX. Hansen's book was very helpful in getting up and running again in a UNIX environment. This book helped me to, almost, like UNIX again. I'd highly recommend it to novice UNIX users or users who need to update their skills. Mr. Pat Vitone

I was very impressed with RedHat's complete and understandable approach to the installation and configuation of their Linux distribution.

Some of us remember using HP Open Mail in the early 90s. Very stable, and with the ability to scale up to many users. The book describes its strange journey, and how it morphed into something called Scalix. Perhaps you might agree with Feilner's characterisation of HP's marketing of Open Mail as being defined by a too-close relationship with Microsoft, and a reluctance by HP to position Open Mail as a direct competitor to Exchange. His account of Open Mail's travails is backed up by excerpts from contemporaneous accounts in the technical press.

Anyway, here we are today with Scalix. How does it look? The book describes a sophisticated GUI that lets the sysadmin easily handling managing a large email server. One immediate advantage is that the GUI lets you avoid direct editing of what Feilner calls the "horrible" sendmail syntax of the sendmail configuration files. Good. I was once a sysadmin of unix boxes, and sendmail had the well deserved reputation of being the most complicated package to manage. Its syntax is indeed dreadful, and if you know nothing of this because you use Scalix, you are fortunate.

Another very useful advantage of Scalix over a default sendmail is a more efficient holding of messages. Sendmail sends copies of a message to each recipient's mail file. As far as I know, there is no way with sendmail to avoid this. But Scalix uses a totally different storage approach, that avoids this replication. It lets Scalix scale up to handle more users and messages than sendmail.