File: pr03.html

package info (click to toggle)
samba 2:3.6.6-6+deb7u7
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 160,976 kB
  • sloc: ansic: 1,764,536; xml: 114,867; python: 78,119; perl: 27,633; sh: 13,802; makefile: 4,704; asm: 3,281; cpp: 2,281; yacc: 1,949; exp: 1,784; ada: 1,681; pascal: 1,089; cs: 879; awk: 756; lex: 566; csh: 58; sed: 45; php: 6
file content (54 lines) | stat: -rw-r--r-- 6,409 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Foreword</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="up" href="index.html" title="The Official Samba 3.5.x HOWTO and Reference Guide"><link rel="prev" href="pr02.html" title="Attribution"><link rel="next" href="TOSHpreface.html" title="Preface"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Foreword</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pr02.html">Prev</a>�</td><th width="60%" align="center">�</th><td width="20%" align="right">�<a accesskey="n" href="TOSHpreface.html">Next</a></td></tr></table><hr></div><div class="preface" title="Foreword"><div class="titlepage"><div><div><h2 class="title"><a name="id323466"></a>Foreword</h2></div></div></div><p>
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
<span class="emphasis"><em>rest</em></span> 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.
</p><p>
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.
</p><p>
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.
</p><p>
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 <span class="emphasis"><em>everybody knows</em></span> was the dominant
emotion of those providing documentation. <span class="emphasis"><em>They</em></span> of the ever present <span class="emphasis"><em>they
say</em></span> and <span class="emphasis"><em>they know</em></span> are the bane of good standards. If <span class="emphasis"><em>they
know</em></span>, why are you doing a standard?
</p><p>
A <span class="emphasis"><em>good standard</em></span> 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 becomes 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 <span class="emphasis"><em>correctness</em></span> provide a technical nightmare. Correctness and clarity
with ambiguity create <span class="emphasis"><em>maybe bits,</em></span> and correctness and unambiguity without clarity provide
a <span class="emphasis"><em>muddle through</em></span> scenario.
</p><p>
And this is <span class="emphasis"><em>the rest of the story</em></span> 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.
</p><p>
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.
</p><p>
</p><table border="0" summary="Simple list" class="simplelist"><tr><td>Carl Cargill, Senior Director</td></tr><tr><td>Corporate Standardization, The Office of the CTO</td></tr><tr><td>Sun Microsystems</td></tr></table><p>
</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pr02.html">Prev</a>�</td><td width="20%" align="center">�</td><td width="40%" align="right">�<a accesskey="n" href="TOSHpreface.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Attribution�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Preface</td></tr></table></div></body></html>