From owner-freebsd-doc Tue Sep 23 10:29:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22551 for doc-outgoing; Tue, 23 Sep 1997 10:29:16 -0700 (PDT) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22541 for ; Tue, 23 Sep 1997 10:29:01 -0700 (PDT) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.7/8.8.7) with SMTP id MAA20421; Tue, 23 Sep 1997 12:28:07 -0500 (EST) Date: Tue, 23 Sep 1997 12:28:07 -0500 (EST) From: John Fieber To: nik@iii.co.uk cc: doc@freebsd.org Subject: Doc projects In-Reply-To: <19970915111420.01135@strand.iii.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-doc@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 15 Sep 1997 nik@iii.co.uk wrote: > my own machine at home. At which point I'd like to get more involved with > the documentation project. What tasks are up for grabs at the moment? What REALLY needs to happen is for someone to do a cover-to-cover reading of the handbook and flag things that are out of date, flat out wrong, or generally incomprehensible. I've stumbled into things in all categories, and I know there are more. Some things are trivial to fix, otherwise just compile notes like "sect 8.3.2: yada yada yada is correct for 2.1, but the procedure was changed for 2.2. Note the change." THEN, we will no what needs to be done. :) Although it would be easy to divide up the reading among a number of people, having one person do it has the distinct advantage of being better able to spot larger scale structural glitches, however at ~300 pages printed, that is no tiny task. (I recently finished tech editing a ~370 page book...but I got paid for it :) As far as new docs, I think we could really use a "FreeBSD performance tuning" guide. This should cover (a) what performance information exists, (b) how to get it, (c) how to interpret it, and (d) what to do about it. Why is this an important document? Because the applications that separate FreeBSD from the alternatives (read: Linux) are server applications where small performance tweaks can have a big effect. (c) in particular can be quite complex as I discovered when I started drafting a little blub about looking at memory usage...what *exactly* do things like vss and rss reveal? Things like this have been at the root of a number of Linux/BSD debates when, in fact, the numbers being compared between the systems were not really comparable because of differences in reporting. A lot of the answers are diffused in the archives of the hackers mailing lists, and can be picked from the brains of core team members. -john