I hate to bitch but bitch I must
smithi at nimnet.asn.au
Sun Oct 18 09:06:02 UTC 2009
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).
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:
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 :)
> > 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.
More information about the freebsd-questions