Date: Tue, 23 Jun 1998 17:36:20 +0000 (GMT) From: "Jason C. Wells" <jcwells@u.washington.edu> To: "John D. Morrison" <jdm1intx@airmail.net> Cc: FreeBSD-questions <freebsd-questions@FreeBSD.ORG> Subject: Re: resolving security and permissions problems Message-ID: <Pine.BSF.3.96.980623171646.461A-100000@s8-37-26.student.washington.edu> In-Reply-To: <m0yoUCg-0007uGE@mail.airmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Jun 1998, John D. Morrison wrote: >> You _must_ read. If reading frustrates you then FreeBSD will frustrate > >Thanks for your help. Reading does _not_ frustrate me. What frustrates >me is not knowing _where_ to read. That is one thing I think that you >young unix turks forget. Like I said, I have the FreeBSD manual and We did not forget. Learning _what_ to read is something else you must learn. This is the case with any technical endeavour. You will notice that I gave you a list of things to read. This should help you in knowing "what" to read. >have read through it extensively, trying whatevery I could glean from it. >But you must understand that it's far more difficult and time consuming >to sit down and piece together enough information about what to do by >reading through gigabytes of man pages than it would be if someone would >just bother to write up a detailed, simplified procedure of how to set up >a typical FreeBSD installation for several different scenarios. "The Complete FreeBSD" by Greg Lehey. In general, online documentation is technical documentation. A good book is always in order. >I've read the FAQs. I've read all the readmes and installation texts. >They are all written in the briefest, tersest manner possible, as if to >say "here we'll give you a general direction to head in, but don't expect >anything else". This is a fitting description of what a FAQ should be. A FAQ is _not_ a technical document. It is a collection of "gotcha's" that we all share and contribute to. README's are also not full blown documentation. The man pages are technical documents. Being so, they are a chore to read. Here is one tip. Hit '/' and then type in a keyword to find pertinent info. Which brings me back to the book(s). They are invaluable at providing insight. They are also not technical documents. You see there is a conundrum. If you turn a technical document into an "insight" document it loses it's effectiveness as a technical document. If you turn a book (insight) into a technical document it will also become ineffective. You really do need both types of texts. >There is no document that gives a big-picture view of all the elements >necessary to set it up for say, a single developer who wants to do X >Windows stuff. The book makes a fair stab at it, but doesn't come close >enough. Yes well... X is not a FreeBSD, Inc product. There are several good books on X. "We" cannot do every single thing under the sun. There are 1,500 ports in the ports collection containing millions of lines of code and docs. >I applaud the efforts of all the volunteers involved in the FreeBSD >project and the excellent work they've all done in bringing it to the >world, but I think that they have yet to learn the lesson that Digital >Research and Microsoft both had to learn. Publishing terse, jargonesque >documentation and projecting a condescending attitude towards people who >request clarification will not earn them a lot of support in the world. I wasn't condescending you. I was telling you what you needed to know and what you asked me for. One of the things that you need to know is that FreeBSD requires a lot of reading, therefore that is what I told you. Catchya Later, | UW Mechanical Engineering Jason Wells | http://weber.u.washington.edu/~jcwells/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980623171646.461A-100000>