From owner-freebsd-questions@FreeBSD.ORG Sun Oct 18 09:06:02 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8223D106566B for ; Sun, 18 Oct 2009 09:06:02 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id DDDCB8FC08 for ; Sun, 18 Oct 2009 09:06:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n9I95xrZ017727; Sun, 18 Oct 2009 20:05:59 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 18 Oct 2009 20:05:59 +1100 (EST) From: Ian Smith To: PJ In-Reply-To: <20091017223504.AB7DB1065716@hub.freebsd.org> Message-ID: <20091018173037.K70724@sola.nimnet.asn.au> References: <20091017223504.AB7DB1065716@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org Subject: Re: I hate to bitch but bitch I must X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 09:06:02 -0000 PJ, having (in this case at least) the luxury of reading freebsd-questions as a digest, I'm going to quote a few of your extracts from several messages, largely without surounding context, as it's all incredibly repetitive, masively overquoted and mostly just "grasping for ambiguity" as Warren Block so eloquently put it. > To be as precise as possible, it means normally it should work so go > ahead; then the question is - what do you mean by normally. > In our case above, the instructions were to do the operation with the > disk not in use and the os in SUM. That's very clear. Now, I f they > wanted to point out a bug, the bug means that there is an anomaly under > certain circumstances - and in this case there really is no bug as it is > very clear as to how the instructions should be used. If they consider > the operation under a live files system a bug, then they should just > make a warning and say something along the lines of "do not use on live > system as that may destroy data" or something to that effect. I think you're only being so obtuse about this because you haven't had much experience reading man pages, and seem to expect them to conform to some sort of English Literary standards that are entirely inapplicable. > Just a note: I find it strange that nobody looked into the problem of > the confusion... I thought I had pointed out where the co;nfusion > arises... and no one seems to have either understood the inconsistencies > or bothere to read the explanation... oh well... let's keep on > blundering away... ;-) Must we? The confusion, and the seems-like-a-hundred messages it's now spawned, is all yours. Many have tried relentlessly and unsuccessfully to explain to you what just about everyone else has had no difficulty in understanding, because they don't try applying linguistic contortions to a simple statement by its (entirely English-speaking) authors. M. McKusick, W. Joy, S. Leffler, and R. Fabry, "A Fast File System for UNIX", ACM Transactions on Computer Systems 2, 3, pp 181-197, August 1984, (reprinted in the BSD System Manager's Manual, SMM:5). BUGS This utility should work on active file systems. You can tune a file system, but you can't tune a fish. If you want to see the _fascinating_ history of the tunefs(8) man page: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/tunefs/tunefs.8 First go right down the bottom, Rev 1.1, and choose 'annotated' view .. you'll see the original text committed by Rodney Grimes. If you don't know who Marshall McKusick, Bill Joy, Sam Leffler and Robert Fabry are, do some googling, or start at http://www.mckusick.com/articles.html Rev 1.4 adds an interesting warning .. perhaps some pedant had suggested that a little humour was inappropriate :) At some later point, mckusick corrected the spelling of 'Daemon', and later ru@ changed "can't" to "cannot" (FFS!). This is a very carefully considered BUGS section, with over 15 years' of history. Mess with it at your peril :) > What in the world is RFC 2119? (that's a rhetorical question....) I > prefer to stick to orinary dictionaries, like Oxford, Collins, Webster... > then again, my college university studies were in English lit... but I'm > afraid I have have neglected that and have been somewhat dragged down to > the level of the "plebes" in the hope they may catch some of my > meanings... :-D You need to use the right terms in the appropriate context, and it's best to try avoiding condescension when dealing with people who may not have attained your literary qualifications, but who clearly know a hell of a lot more about this subject than you do. If you don't know about RFCs you'll get lost with lots of UNIX (and other computer system) references. Google is your (and our!) friend. > > I understand that I'm confused :) Ok. > > Actually, what's happening here is dropping part of a sentence. It's > > common in English to shorten > > Yea, it should work, but it doesn't. > > > Absolutely not! There is nothing to suggest either statement above. If > one says it should work, it can mean (of course, it changes within > different contexts) that all is ok and normal conditions (whatever they > may be) will allow things to function correctly. There is certainly no > implication about confidence... where do you get that? It can mean ver > confident just as well. And dropping a sentence is a very presumptuous > assumption. "but is doesn't" is a specific condition... and there can me > innumerable conditions. Semantic obfuscation and failure to understand usage of 'BUGS' sections. Try reading a whole lot more manpages to get their drift, eg what would you make of "BUGS: bound to be some" without knowing the wisdom therein? > In the end, it's up to the author to clarify... I don't understand what > he's trying to do as on my stem his instructions/example just do not > work anyway. :-( You really cannot go on blaming others for your lack of comprehension, and it's best to stick to technical facts if you want good help here, though all praise to the extraordinary patience of some folks here. Ian