zfs discuss - Nov 2007 - pls discontinue troll bait was: Yager on ZFS and ZFS + DB + "fragments"

I''ve been observing two threads on zfs-discuss with the following 
Subject lines:

Yager on ZFS
ZFS + DB + "fragments"

and have reached the rather obvious conclusion that the author "can 
you guess?" is a professional spinmeister, who gave up a promising 
career in political speech writing, to hassle the technical list 
membership on zfs-discuss.  To illustrate my viewpoint, I offer the 
following excerpts (reformatted from an obvious WinDoze Luser Mail 
client):

Excerpt 1:  Is this premium technical BullShit (BS) or what?

------------- BS 301 ''grad level technical BS'' -----------

Still, it does drive up snapshot overhead, and if you start trying to 
use snapshots to simulate ''continuous data protection'' rather
than
more sparingly the problem becomes more significant (because each 
snapshot will catch any background defragmentation activity at a 
different point, such that common parent blocks may appear in more 
than one snapshot even if no child data has actually been updated). 
Once you introduce CDP into the process (and it''s tempting to, since 
the file system is in a better position to handle it efficiently than 
some add-on product), rethinking how one approaches snapshots (and COW 
in general) starts to make more sense.

------------- end of BS 301 ''grad level technical BS''
-----------

Comment: Amazing: so many words, so little meaningful technical 
content!

Excerpt 2: Even better than Excerpt 1 - truely exceptional BullShit:

------------- BS 401 ''PhD level technical BS''
------------------

No, but I described how to use a transaction log to do so and later on 
in the post how ZFS could implement a different solution more 
consistent with its current behavior.  In the case of the transaction 
log, the key is to use the log not only to protect the RAID update but 
to protect the associated higher-level file operation as well, such 
that a single log force satisfies both (otherwise, logging the RAID 
update separately would indeed slow things down - unless you had NVRAM 
to use for it, in which case you''ve effectively just reimplemented a 
low-end RAID controller - which is probably why no one has implemented 
that kind of solution in a stand-alone software RAID product).

...
------------- end of BS 401 ''PhD level technical BS''
------------------

Go ahead and lookup the full context of these exceptional BS excerpts 
and see if the full context brings any further enlightment.  I think 
you''ll quickly realize that, after reading the full context, this is 
nothing more than a complete waste of time and that there is nothing 
of technical value to learned from this text.  In fact, there is very, 
very little to be learned from any posts on this list where the 
Subject line is either:

Yager on ZFS
ZFS + DB + "fragments"

and the author is: "can you guess? <billtodd at metrocast.net>"

I''m not, for a moment, suggesting that one can''t learn
*something*
from the posts of the author "can you guess? 
<billtodd at metrocast.net>"... indeed there are significant 
spinmeistering skills to be learned from these posts; including how to 
combine portions of cited published technical studies (Google Study, 
CERN study) with a line of total semi-technical bullshit worthy of any 
political spinmeister working withing the DC "Beltway Bandit" area. 
In fact, if I''m trying to conn^H^H^H^H talk someone out of several 
million dollars to fund a totally BS research project, I''ll pay any 
reasonable fees that "can you guess?" would demand.  Because
I''m
convinced, that with his premium spinmeistering/BS skills - nothing is 
impossible: pigs can fly, NetApp == ZFS, the world is flat .... and 
ZFS is a totally deficient technical design because they did''nt 
solicit his totally invaluable technical input.

And.. one note of caution for Jeff Bonwick and Team ZFS - lookout ... 
for this guy - because his new ZFS competitor filesystem, called, 
appropriately, GOMFS (Guess-O-Matic-File-System) is about to be 
released and it''ll basically, if I understand "can you
guess?"''s email
fully, solve all the current ZFS design deficiencies, and totally 
dominate all *nix based filesystems for the next 400 years.

Regards,

Al Hopper  Logical Approach Inc, Plano, TX.  al at logical-approach.com
            Voice: 972.379.2133 Fax: 972.379.2134  Timezone: US CDT
OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/
Graduate from "sugar-coating school"?  Sorry - I never attended! :)

> 
> I''ve been observing two threads on zfs-discuss with
> the following 
> Subject lines:
> 
> Yager on ZFS
> ZFS + DB + "fragments"
> 
> and have reached the rather obvious conclusion that
> the author "can 
> you guess?" is a professional spinmeister,
Ah - I see we have another incompetent psychic chiming in - and judging by his
drivel below a technical incompetent as well.  While I really can''t
help him with the former area, I can at least try to educate him in the latter.

...
> Excerpt 1:  Is this premium technical BullShit (BS)
> or what?
Since you asked:  no, it''s just clearly beyond your grade level, so
I''ll try to dumb it down enough for you to follow.
> 
> ------------- BS 301 ''grad level technical BS''
> -----------
> 
> Still, it does drive up snapshot overhead, and if you
> start trying to 
> use snapshots to simulate ''continuous data
> protection'' rather than 
> more sparingly the problem becomes more significant
> (because each 
> snapshot will catch any background defragmentation
> activity at a 
> different point, such that common parent blocks may
> appear in more 
> than one snapshot even if no child data has actually
> been updated). 
> Once you introduce CDP into the process (and it''s
> tempting to, since 
> the file system is in a better position to handle it
> efficiently than 
> some add-on product), rethinking how one approaches
> snapshots (and COW 
> in general) starts to make more sense.
Do you by any chance not even know what ''continuous data
protection'' is?  It''s considered a fairly desirable item these
days and was the basis for several hot start-ups (some since gobbled up by
bigger fish that apparently agreed that they were onto something significant),
since it allows you to roll back the state of individual files or the system as
a whole to *any* historical point you might want to (unlike snapshots, which
require that you anticipate points you might want to roll back to and capture
them explicitly - or take such frequent snapshots that you''ll probably
be able to get at least somewhere near any point you might want to, a
second-class simulation of CDP which some vendors offer because it''s
the best they can do and is precisely the activity which I outlined above,
expecting that anyone sufficiently familiar with file systems to be able to
follow the discussion would be familiar with it).

But given your obvious limitations I guess I should spell it out in words of
even fewer syllables:

1.  Simulating CDP without actually implementing it means taking very frequent
snapshots.

2.  Taking very frequent snapshots means that you''re likely to
interrupt background defragmentation activity such that one child of a parent is
moved *before* the snapshot is taken while another is moved *after* the snapshot
is taken, resulting in the need to capture a before-image of the parent (because
at least one of its pointers is about to change) *and all ancestors of the
parent* (because the pointer change will propagate through all the ancestral
checksums - and pointers, with COW) in every snapshot that occurs immediately
prior to moving *any* of its children rather than just having to capture a
single before-image of the parent and all its ancestors after which all its
child pointers will likely get changed before the next snapshot is taken.

So that''s what any competent reader should have been able to glean from
the comments that stymied you.  The paragraph''s concluding comments
were considerably more general in nature and thus legitimately harder to follow:
had you asked for clarification rather than just assumed that they were BS
simply because you couldn''t understand them you would not have looked
like such an idiot, but since you did call them into question I''ll now
put a bit more flesh on them for those who may be able to follow a discussion at
that level of detail:

3.  The file system is in a better position to handle CDP than some external
mechanism because

a) the file system knows (right down to the byte level if it wants to) exactly
what any individual update is changing,

b) the file system knows which updates are significant (e.g., there''s
probably no intrinsic need to capture rollback information for lazy writes
because the application didn''t care whether they were made persistent
at that time, but for any explicitly-forced writes or syncs a rollback point
should be established), and

c) the file system is already performing log forces (where a log is involved) or
batch disk updates (a la ZFS) to honor such application-requested persistence,
and can piggyback the required CDP before-image persistence on them rather than
requiring separate synchronous log or disk accesses to do so.

4.  If you''ve got full-fledged CDP, it''s questionable whether
you need snapshots as well (unless you have really, really inflexible
requirements for virtually instantaneous rollback and/or for high-performance
writable-clone access) - and if CDP turns out to be this decade''s
important new file system feature just as snapshots were last decade''s
it will be well worth having optimized for.

5.  Block-level COW technology just doesn''t cut it for full-fledged CDP
unless you can assume truly unlimited storage space:  not only does it encounter
even worse instances of the defrag-related parent-block issues described above
(which I brought up in a different context) but, far worse, it requires that
every generation of every block in the system live forever (or at least for the
entire time-span within which rollback is contemplated).

Hence the rethinking that I mentioned.  COW techniques are attractive from an
ease-of-implementation standpoint for moderately infrequent snapshots, but as
one approaches CDP-like support they become increasingly infeasible.  Whereas
transaction-log-protected approaches can handle CDP very efficiently (in a
manner analogous to a database before-image rollback log), as well as being able
to offer everything else that ZFS does with better run-time efficiency (e.g., no
longer must the entire ancestral path be updated on disk whenever a leaf node
is), plus update-in-place facilities to support good sequential-streaming
performance where that makes sense - but at the cost not only of increased
implementation complexity but of the need for something resembling innovation
(at least in the file system context).  And for the occasional installation that
really requires high-performance snapshot rollback/writable clone facilities,
you can still implement them effectively at the block level *underneath* all
this file-level stuff and then get rid of their overhead when the requirement
has expired.

That''s as dumbed-down as I''m going to get:  if you still
can''t understand it, please seek help from a colleague.
> 
> ------------- end of BS 301 ''grad level technical BS''
> -----------
> 
> Comment: Amazing: so many words, so little meaningful
> technical 
> content!
Oh, dear:  you seem to have answered the question that you posed above with the
same abject cluelessness which you''re bringing to the rest of your
post.  Oh, well:  there''s something to be said for consistency, I
guess.
> 
> Excerpt 2: Even better than Excerpt 1 - truely
> exceptional BullShit:
No - just truly exceptional arrogance on your part:  you really ought to develop
at least minimal understanding of a subject before deciding to tackle someone
who already has a great deal more than that.
> 
> ------------- BS 401 ''PhD level technical BS''
> ------------------
> 
> No, but I described how to use a transaction log to
> do so and later on 
> in the post how ZFS could implement a different
> solution more 
> consistent with its current behavior.  In the case of
> the transaction 
> log, the key is to use the log not only to protect
> the RAID update but 
> to protect the associated higher-level file operation
> as well, such 
> that a single log force satisfies both (otherwise,
> logging the RAID 
> update separately would indeed slow things down -
> unless you had NVRAM 
> to use for it, in which case you''ve effectively just
> reimplemented a 
> low-end RAID controller - which is probably why no
> one has implemented 
> that kind of solution in a stand-alone software RAID
> product).
That one was already clear enough that I''m just going to let you find a
helpful colleague to explain it to you, as suggested above.  Someone who knows
something about write-ahead logging and how it''s usable not only to
protect operations but to enhance their performance by capturing the amount of
information required to replay one or more serial updates to the same or
associated data in the log or in supplements to it while deferring final
batch-propagation of those updates back to the main database might be a good
bet.

Making due allowances for your being in Texas and thus being intimately
acquainted with BS on a very personal level, I''ll suggest that you
refrain from further solidifying that state''s stereotypes in the
Internet group-mind until you''ve cleared your insights with someone who
actually has some acquaintance with technologies such as file systems, and
transaction managers, and log implementations - all of which I have both studied
in depth and been well-paid to write from scratch.  You might also consider
posting your babble from a personal rather than a professional location, unless
your profession is completely unrelated to technology in particular and to
competence in general.

- bill
 
 
This message posted from opensolaris.org

On Sat, 17 Nov 2007, can you guess? wrote:
> Ah - I see we have another incompetent psychic chiming in - and
> judging by his drivel below a technical incompetent as well.  While I
> really can''t help him with the former area, I can at least try to
> educate him in the latter.
I should know better than to reply to a troll, but I can''t let this
personal attack stand.  I know Al, and I can tell you for a fact that
he is *far* from "technically incompentent".

Judging from the length of your diatribe (which I didn''t bother
reading),
you seem to subscribe to the "if you can''t blind ''em with
science,
baffle them with bullshit" school of thought.  I''d take the word
of
any number of people on this list over yours, anyday.

HAND,

-- 
Rich Teer, SCSA, SCNA, SCSECA, OGB member

CEO,
My Online Home Inventory

URLs: http://www.rite-group.com/rich
      http://www.linkedin.com/in/richteer
      http://www.myonlinehomeinventory.com

<troll bait>

Rich Teer wrote:
> I should know better than to reply to a troll, but I can''t let
this
> personal attack stand.  I know Al, and I can tell you for a fact that
> he is *far* from "technically incompentent".
>
> Judging from the length of your diatribe (which I didn''t bother
reading),
> you seem to subscribe to the "if you can''t blind ''em
with science,
> baffle them with bullshit" school of thought.  I''d take the
word of
> any number of people on this list over yours, anyday.
>
> HAND,
>   
I''m sure this troll will reply to you as he did to me. I just
can''t help
laughing at his responses anymore. I do find it odd that someone has so 
much time on their hands to just post such remarks. It''s as if they 
think they are doing themself or the world a flavor.


</troll bait>

...
> I should know better than to reply to a troll,
So which is it, Rich?  Do you ''know better'' but lack even
minimal self-control, or do you, however dimly, recognize that there''s
actually a difference between ''trolling'' and legitimate
criticism (and are you so scared of the latter that you''ll attempt to
deflect it using - if that were possible - even less technical basis than Al
had)?

 but I can''t let this
> personal attack stand.
Let me be sure that I''ve got this right:  it''s no problem for
Crazy Al to call me a "professional spinmeister", to call what
I''ve said "premium technical BullShit" and a bunch of other
repetitive things throughout his post and to opine that it is a "complete
waste of time and that there is nothing of technical value to learned from this
text" (which may well have been true for Al given his obvious personal
limitations, but he over-extended himself - itself probably not very difficult -
when he presumed to extend that assessment to others). and generally to babble
on in that vein without saying any more worth specific mention, but when I
respond to him in technical detail (and, yes, comment upon the stultifying
incompetence of his criticism) that constitutes an intolerable
''personal attack''?

(By the way, I think you meant above that you couldn''t let it stand
*without attempting to rebut it*, since it''s actually still
''standing'' just fine, right where I originally stood it.)

  I know Al, and I can tell you for a fact that
> he is *far* from "technically incompentent".
Even in the event (unlikely as it may appear) that this assertion might actually
be defensible in some sufficiently-limited context (I certainly won''t
try to guess where), you''re hardly getting off to a good start at
convincing me that I should value your opinion of what constitutes
''fact'' any more than I value Al''s drivel.  But in the
context that he chose to blunder around in here?  Nah, no chance at all: 
he''s a complete and utter bozo, as anyone who had any real clue about
the subject would have no difficulty whatsoever discerning.
> 
> Judging from the length of your diatribe (which I didn''t bother
reading),
Amazing:  yet *another* psychic!  *Naturally* there was no need to read it when
your mind (or what passes for it) was already made up about what it must have
said - not to mention that discussing its technical merit (should you actually
be qualified to do so) could be dangerous to your biases.

It''s beginning to look like incompetence may be somewhat endemic around
here, though it''s nice to see that at least some participants have
apparently resisted infection.  But given that Al seems to have spent a couple
of years on the "OpenSolaris Governing Board" (whatever that may be -
I''ll just take his word for it), one really has to wonder.

Of course, if one gives Sun the benefit of the doubt perhaps they just find that
among that board''s other more significant functions it''s also
a useful place where clueless blowhards can be parked to keep them occupied and
out of trouble:  I''d be reluctant to venture into such speculation on
the basis of a *single* example, but since you also appear to fit that
description and to be associated with the same body...

In any event, one thing of which I can be fairly certain is that Plano is not
the infamous village in Texas that is missing its idiot, nor is whatever village
happens to be your own home.  It''s beginning to look as if there may
really be no one here capable of discussing these issues technically, which
would go a long way toward explaining the knee-jerk castigation of anyone who
presumes to suggest that your chosen baby is anything less than adorable.

- bill
 
 
This message posted from opensolaris.org

You''ve been trolling from the get-go and continue to do so.  First
it''s "I have the magical fix", which wasn''t a fix at
all.  You claim to want to better the project, then claim you can''t be
bothered because you don''t really care.

You rant and rave about how this is so much like wafl from a technical
perspective, but then claim to not work for netapp or even KNOW anyone from
netapp.  Yet a quick search of the net has you claiming to have worked with
netapp hardware for years.  You must be the ONLY person on this planet to have
used a vendors wares for YEARS, have an intimate technical knowledge of the
wares, but not know a SINGLE person who works for the company selling or
supporting such wares.

Just shut it already.  Your four page rants are convincing no one of anything
but the fact you''re an arrogant ass, as previously stated, and as your
continued rants validate.  No, I don''t care what rambling response
you''ll have, nor does anyone else.  Really, get yourself a blog.



^^did you see that paragraph, it was a list of names of all the people on this
list who care what you have to say.  Just go away already.
 
 
This message posted from opensolaris.org

> You''ve been trolling from the get-go and continue to
> do so.
Y''know, cookie, before letting the drool onto your keyboard you really
ought to learn to research it.

I said a good deal of what I''ve said recently well over a year ago here
(and in fact had forgotten how much detail I went into back then, else I might
just have given a pointer to it).

  First it''s "I have the magical fix",
which
> wasn''t a fix at all.
Just because you can''t understanding something doesn''t mean it
isn''t feasible, dearie.

  You claim to want to better the
> project,
I''ll have to see a reference for that, I''m afraid:  while I
have some interest in ZFS from a technical standpoint, I''ve never had
any kind of commitment to it.

 ...
 
> You rant and rave about how this is so much like wafl
> from a technical perspective, but then claim to not
> work for netapp or even KNOW anyone from netapp.  Yet
> a quick search of the net has you claiming to have
> worked with netapp hardware for years.
Another reference required, I''m afraid:  I''ve never touched a
NetApp box, nor to the best of my knowledge used one (of course, when
you''re interacting with the Internet, you don''t know what
hardware may be on the other end).

  You must be
> the ONLY person on this planet to have used a vendors
> wares for YEARS, have an intimate technical knowledge
> of the wares, but not know a SINGLE person who works
> for the company selling or supporting such wares.
No, cookie:  you''re just as incompetent a researcher as you are
technically.

...
> ^^did you see that paragraph, it was a list of names
> of all the people on this list who care what you have
> to say.
Ah - I see that you responded to this post before responding to the poster who
just proved you wrong (yet again).

- bill
 
 
This message posted from opensolaris.org

The only sad part is it''s clear one or two people were fooled into
believe there''s any merit to your trolling.

Grow up.
 
 
This message posted from opensolaris.org

Ah - no references to back up your drivel, I see.

No surprise there, of course - but thanks for playing.

- bill
 
 
This message posted from opensolaris.org

Big talk from someone who seems so intent on hiding their credentials.
 
 
This message posted from opensolaris.org

> Big talk from someone who seems so intent on hiding
> their credentials.
Say, what?  Not that credentials mean much to me since I evaluate people on
their actual merit, but I''ve not been shy about who I am (when I
responded ''can you guess?'' in registering after giving
billtodd as my member name I was being facetious).

If you''re still referring to your incompetent alleged research,
I''m still waiting for something I can look at:  I do happen to know
that another Bill Todd has long been associated with Interbase/Firebird (which
is kind of ironic since Jim Starkey is an old friend of mine from my eleven
years at DEC, though it''s been a few years since we managed to get
together), but aside from the possibility that you confused him with me I can
only suspect that you pulled your ''discovery'' right out of the
same orifice from which you''ve pulled the rest of your crap.

- bill
 
 
This message posted from opensolaris.org

On Sun, Nov 18, 2007 at 12:15:25 -0800, can you guess? wrote:
: > Big talk from someone who seems so intent on hiding
: > their credentials.

: Say, what?  Not that credentials mean much to me since I evaluate people
: on their actual merit, but I''ve not been shy about who I am (when I
: responded ''can you guess?'' in registering after giving
billtodd as my
: member name I was being facetious).

You''re using a web-based interface to a mailing list and the
''billtodd''
bit doesn''t appear to any users (such as me) subscribed via that
mechanism.  So yes, ''can you guess?'' is unhelpful and makes
you look as if
you''re being deliberately unhelpful.

OK, it''s in your email address, but various broken MUAs (Outlook and
derivatives for one) fail to show that.

: If you''re still referring to your incompetent alleged research, [...]
: [...] right out of the
: same orifice from which you''ve pulled the rest of your crap.

It''s language like that that is causing the problem.  IMHO
you''re being a
tad rude.  This doesn''t help anybody.

-- 
Dickon Hood

Due to digital rights management, my .sig is temporarily unavailable.
Normal service will be resumed as soon as possible.  We apologise for the
inconvenience in the meantime.

No virus was found in this outgoing message as I didn''t bother looking.

On 18-Nov-07, at 7:30 PM, Dickon Hood wrote:
> ...
> : If you''re still referring to your incompetent alleged research,
> [...]
> : [...] right out of the
> : same orifice from which you''ve pulled the rest of your crap.
>
> It''s language like that that is causing the problem.  IMHO
you''re
> being a
> tad rude.  This doesn''t help anybody.
+1.

To those of us raised civilly it''s a flag to ignore what follows.

--T
>
> -- 
> Dickon Hood
>
> Due to digital rights management, my .sig is temporarily unavailable.
> Normal service will be resumed as soon as possible.  We apologise  
> for the
> inconvenience in the meantime.
>
> No virus was found in this outgoing message as I didn''t bother  
> looking.
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Hint: Bill was already writing file system code when I was in elementary school.
;-)

Seriously...it''s rather sad to see serious and useful discussions
derailed by thin skins and zealotry. Bill''s kind enough to share some
of his real-world experience and observations in the old tradition of senior
engineers helping out those who are entering the field. I for one find his
contributions (here and on USENET) very useful and always thought-provoking,
whether I agree or disagree with a particular point. Thought-provoking often
means controversial, but that''s not a bad thing -- if you''ve
been involved in the software engineering process, you''ll know that
most engineers have spent many afternoons yelling at each other over opposing
points of view before going out for a drink together, and usually the end
product is better for it.  ;-)
 
 
This message posted from opensolaris.org

Anton B. Rang wrote:
> Hint: Bill was already writing file system code when I was in elementary
> school.  ;-)
> 
> Seriously...it''s rather sad to see serious and useful discussions
> derailed by thin skins and zealotry. Bill''s kind enough to share
some of
> his real-world experience and observations in the old tradition of
> senior engineers helping out those who are entering the field. I for one
> find his contributions (here and on USENET) very useful and always
> thought-provoking, whether I agree or disagree with a particular point.
> Thought-provoking often means controversial, but that''s not a bad
thing
> -- if you''ve been involved in the software engineering process,
you''ll
> know that most engineers have spent many afternoons yelling at each
> other over opposing points of view before going out for a drink
> together, and usually the end product is better for it.  ;-)
may be.

OTOH, when someone whom I don''t know comes across as a pushover, he
loses
credibility.
I''d expect a senior engineer to show not only technical expertise but
also
the ability to handle difficult situations, *not* adding to the 
difficulties by his comments.

(and remember: email is not the same as "yelling at one another" (in
the
hallway/at the conference table))

Michael
-- 
Michael Schuster	Sun Microsystems, Inc.
recursion, n: see ''recursion''

> OTOH, when someone whom I don''t know comes across as
> a pushover, he loses 
> credibility.
It may come as a shock to you, but some people couldn''t care less about
those who assess ''credibility'' on the basis of form rather
than on the basis of content - which means that you can either lose out on
potentially useful knowledge by ignoring them due to their form, or change your
own attitude.
> I''d expect a senior engineer to show not only
> technical expertise but also 
> the ability to handle difficult situations, *not*
> adding to the 
> difficulties by his comments.
Another surprise for you, I''m afraid:  some people just don''t
meet your expectations in this area.  In particular, I only ''show my
ability to handle difficult situations'' in the manner that you suggest
when I have some actual interest in the outcome - otherwise, I simply do what I
consider appropriate and let the chips fall where they may.

Deal with that in whatever manner you see fit (just as I do).

- bill
 
 
This message posted from opensolaris.org

> : > Big talk from someone who seems so intent on hiding
> : > their credentials.
> 
> : Say, what?  Not that credentials mean much to me since I evaluate people
> : on their actual merit, but I''ve not been shy about who I am
(when I
> : responded ''can you guess?'' in registering after giving
billtodd as my
> : member name I was being facetious).
> 
> You''re using a web-based interface to a mailing list and the
''billtodd''
> bit doesn''t appear to any users (such as me) subscribed via that
> mechanism.
Then perhaps Sun should make more of a point of this in their Web-based
registration procedure.

  So yes, ''can you guess?'' is unhelpful and makes you look as
if
> you''re being deliberately unhelpful.
Appearances can be deceiving, in large part because they''re so
subjective.  That''s why sensible people dig beneath them before forming
any significant impressions.

...
> : If you''re still referring to your incompetent alleged research,
[...]
> : [...] right out of the
> : same orifice from which you''ve pulled the rest of your crap.
> 
> It''s language like that that is causing the problem.
No, it''s ignorant loudmouths like cook and al who are causing the
problem:  I''m simply responding to them as I see fit.

  IMHO you''re being a
> tad rude.
I''m being rude as hell to people who truly earned it, and intend to
continue until they shape up or shut up.  So if you feel that there''s a
problem here that you''d like to help fix, I suggest that you try
tackling it at its source.

- bill
 
 
This message posted from opensolaris.org