on 11/14/02 9:17 AM, Peter Palmreuther <[EMAIL PROTECTED]> wrote: [snip] > Have you _ever_ understood what qmail uses /var/qmail/users/* for? > No? Than you lied and you haven't read qmail documentation. [snip]
The information in the rest of your email is very helpful. Incredibly so for me, and I thank you for it. However, do you realize how full of assumptions most explanations (e.g. helpful explanations from people who know things) and documentation are? Full of assumed knowledge and assumed points of view. So often this makes even extensive documentation almost useless for asimilating even the basics - unless you have lots of time on your hands and can study and study and study until the obvious hidden information finally dawns on you. I find that in particular information about the internet and about server software is more buried right in front of us all than any other area I have ever studied. So the bottom line is no one really needs to prove anything about how hard someone else has studied the documentation. Some of us have studied until it hurt. Others reach their threshold of pain much sooner. But let's face it, learning from documentation is often a pain. A little dialog with someone can help almost effortlessly to bring forward the implicit points of view and create seeds for the process of assimilation, so that returning to the doc can then be fruitful. Documentation writers can learn from this. And learn and learn and learn - I believe without limit. Documentation can be much better. It is hard to be without attitude, and to rid oneself of all the hidden assumptions of being involved in a particularly community of discourse. Documentation is ideally written for everybody. That is an impossible task, but it can be approached. I appreciate this list and the help it provides to supplement the inevitable limitations of documentation (limitations that are experienced very differently by different people needing to learn and get work done). I am just lobbying for the cause of relieving us all from any need to even so much as clarify what someone has failed to do in using the documentation. This would leave our helpful information totally uncolored by anything besides help, which I think would be a good step. After all there is no need to defend the documentation. Like everything it was hard work to write it, and tries to meet an impossible goal. It is good to be aware of both all the time. The "best" of us (and who is that anyway?) will miss the obvious often enough whether writing or reading. Thanks, Kurt Bigler
