summaryrefslogtreecommitdiff
path: root/docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml
diff options
context:
space:
mode:
authorGerald W. Carter <jerry@samba.org>2008-04-22 10:09:40 -0500
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:47:48 -0500
commit8f8a9f01909ba29e2b781310baeeaaddc3f15f0d (patch)
tree90c6b720ad3a7bc815245c0ef28820424f89d658 /docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml
parent197238246389c40edc60c6630d18d6913086e630 (diff)
downloadsamba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.tar.gz
samba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.tar.bz2
samba-8f8a9f01909ba29e2b781310baeeaaddc3f15f0d.zip
Moving docs tree to docs-xml to make room for generated docs in the release tarball.
(This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14)
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml')
-rw-r--r--docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml79
1 files changed, 79 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml b/docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml
new file mode 100644
index 0000000000..6331d2fd4e
--- /dev/null
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-foreword-cargill.xml
@@ -0,0 +1,79 @@
+<?xml version='1.0'?>
+<!DOCTYPE preface PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<preface>
+<title>Foreword</title>
+
+<para>
+When John first asked me to write an introductory piece for his latest book, I was somewhat mystified as to
+why he chose me. A conversation with John provided some of the rationale, and he left it to me to fill in the
+<emphasis>rest</emphasis> of the story. So, if you are willing to endure a little bit of background, I will
+provide the part of the story that John wouldn't provide.
+</para>
+
+<para>
+I am the Director of Corporate Standards at Sun Microsystems, and manage Sun's standards portfolio. Before
+that, I was the Director of Standards at Netscape, which was when I met John. Before Sun, there was Digital
+Equipment Corporation, also standards. I've written several books on standards, and tend to observe (and
+occasionally help) the technical and business trends that drive standardization as a discipline. I tend to see
+standardization as a management tool, not as a technical discipline and this is part of the rationale that
+John provided.
+</para>
+
+<para>
+The book that you have before you focuses on a particular standardized way of doing something hence, it is a
+book about a standard. The most important thing to keep in mind about a standard is the rationale for its
+creation. Standards are created not for technical reasons, not for business reasons, but for a deeper and much
+more compelling reason. Standards are created and used to allow people to communicate in a meaningful way.
+Every standard, if it is a true standard, has as its entire (and only) goal set the increasing of relevant
+communication between people.
+</para>
+
+<para>
+This primary goal cannot be met however, unless the standard is documented. I have been involved in too many
+standardization efforts when it became apparent that <emphasis>everybody knows</emphasis> was the dominant
+emotion of those providing documentation. <emphasis>They</emphasis> of the ever present <emphasis>they
+say</emphasis> and <emphasis>they know</emphasis> are the bane of good standards. If <emphasis>they
+know</emphasis>, why are you doing a standard?
+</para>
+
+<para>
+A <emphasis>good standard</emphasis> survives because people know how to use it. People know how to use a
+standard when it is so transparent, so obvious, and so easy that it become invisible. And a standard becomes
+invisible only when the documentation describing how to deploy it is clear, unambiguous, and correct. These
+three elements must be present for a standard to be useful, allowing communication and interaction between two
+separate and distinct entities to occur without obvious effort. As you read this book, look for the evidence
+of these three characteristics and notice how they are seamlessly woven into John's text. Clarity and
+unambiguity without <emphasis>correctness</emphasis> provide a technical nightmare. Correctness and clarity
+with ambiguity create <emphasis>maybe bits,</emphasis> and correctness and unambiguity without clarity provide
+a <emphasis>muddle through</emphasis> scenario.
+</para>
+
+<para>
+And this is <emphasis>the rest of the story</emphasis> that John couldn't (or wouldn't) bring himself to
+state. This book provides a clear, concise, unambiguous, and technically valid presentation of Samba to make
+it useful to a user to someone who wants to use the standard to increase communication and the capability
+for communication between two or more entities whether person-machine, machine-machine, or person-person.
+The intent of this book is not to convince anyone of any agenda political, technical, or social. The intent
+is to provide documentation for users who need to know about Samba, how to use it, and how to get on with
+their primary responsibilities. While there is pride on John's part because of the tremendous success of
+the Samba documentation, he writes for the person who needs a tool to accomplish a particular job, and who has
+selected Samba to be that tool.
+</para>
+
+<para>
+The book is a monument to John's perseverance and dedication to Samba and in my opinion to the goal of
+standardization. By writing this book, John has provided the users of Samba those that want to deploy it to
+make things better a clear, easy, and ultimately valuable resource. Additionally, he has increased the
+understanding and utility of a highly useful standard, and for this, as much as for the documentation, he is
+owed a debt of gratitude by those of us who rely on standards to make our lives more manageable.
+</para>
+
+<para>
+<simplelist>
+ <member>Carl Cargill, Senior Director</member>
+ <member>Corporate Standardization, The Office of the CTO</member>
+ <member>Sun Microsystems</member>
+</simplelist>
+</para>
+
+</preface>