From: CityK <cityk@rogers.com>
To: Linux and Kernel Video <video4linux-list@redhat.com>
Subject: Another very basic question (the bozo with the WinTV-HVR-1800
Date: Sun, 16 Mar 2008 15:46:50 -0400 [thread overview]
Message-ID: <47DD792A.1060103@rogers.com> (raw)
>
> I greatly appreciate the answers and am sorry to have posted in a way that wasn't \
> kosher. Not that it's any excuse, but I've had trouble replying to the thread \
> because I get a batch mail with all the day's replies bundled into one, and I'm more \
> used to online forums than lists. I haven't figured out the best way to retain the \
> threading,
>
Just copy the thread title (as it is exactly written) into the subject line
> and I actually _have_ been reading the wikis. For weeks. :-)
excellent
> Posting \
> here is a last resort, and part of the frustration is that if one gets a small thing \
> wrong (in my case, one problem was that I was trying to use ATSC scanning when I \
> should have been using QAM...a simple error but for weeks it stumped me).
I understand
> The wikis are almost unintelligible in places
Yes, I would agree that in places that is indeed true.
The "Getting Started" series of articles are much better then what they
previously were like. I and others have spent a lot of time trying to
address these points in particular.
There are a lot of things that have been greatly improved upon, but I
still look at them and say "bah!"
But here are the points worth addressing:
- writing about this stuff (which is technical in nature) is not
necessarily easy...it takes a long time trying to express some of the
concepts clearly, concisely, and precisely.
- It is often troublesome trying to edit/amend something previously
written by someone else -- for the sake of (a) not offending them or (b)
discounting their effort and contribution. Often someone might have
approached something from a different angle which, while not being
wrong, makes it difficult to add upon without a complete rewrite ... the
same is true whether were talking about articles in the wiki or driver
code in the repo ... sometimes you just got to go with what's there
already rather then spending the time reinventing the wheel or doing
things your way.
- wikis rely upon user contributions ... should be obvious, but it
strikes me as if this point is lost on many individuals (I'm not saying
you; what I'm saying is that far too often I see posts/threads/enquiries
about "why doesn't the wiki say this", "why doesn't the wiki convey that
" , blah blah blah blah ... whine whine whine whine ... discount the
efforts of others ... act/suggest/convey/think things happen
automagically... give me give me give me...blah blah blah ... I like to
complain, but am short on contributions ... blah blah blah" ) ... now
although it seems that contributions are picking up, we're still not
seeing anything at the level of that which we should .... we have a
fairly large user base, but very few contributors ....
> The wikis ... assume a vast body of tv-related knowledge \
> that I just don't have (nor, frankly, would many people who just want to put in a tv \
> tuner card and watch tv).
That point I disagree upon -- the whole point of the wiki is to expand
upon and convey the knowledge...the whole point of having internal
article links within articles is to explain each point which might not
be clear ... there is a lot already explained in the wiki, but I just
don't know if users are exploring that fact....I tend to think they
aren't using it resourcefully.
> I'm posting here in this forum as a last resort for \
> questions that probably ARE answerable in the wikis, but I just didn't find them, \
> either by searching for terms that aren't right or by looking in the wrong places.
Fair enough. I will, however, note that on a number of pages in the
wiki there are also notes about searching the m/l lists first too before
posting. My point is that if everyone (new users) starts posting basic
questions to the lists, they are going to get flooded rather quickly
with items discussed previously or documented elsewhere.
I'll be blunt again -- there aren't many developers or others around to
answer questions as it is. Adding basic questions to the mix certainly
doesn't improve things.
Being someone who has observed the lists for a number of years (both
passively at first, and then later on as an active contributor over the
last three or four), I observe that the number of repetitive or basic
type questions is growing ... maybe its not -- maybe its just me ..but
I don't think my perception is wrong.....rather, I suspect that, as the
popularity of Linux increases, and as
TV_or_webcam_or_other_related_functions_falling_under_the_v4l/dvb/LinuxTV_umbrela
become less niche and more mainstream computing features, larger numbers
of novices to the field are dropping in.
The ramifications of this are that getting proper documentation in place
is important if we care to keep the SNR high. But, as mentioned above,
contributions towards such a goal have not been growing proportionately
The other point is that this increased level of
questions/demands/whinning (and oh yes, there have been plenty of
examples of such poor behaviour) is wearing on individuals. Case in
point: me. And I have no qualms about expressing that (that should be
obvious by now :P ). But believe me, others have expressed frustration
as well. Perhaps I've just been more vocal about it -- I have joked on
several occasions about having become the list ogre.
In any regard, it may be a losing battle - SNR is likely to drop no
matter what resources for the end user are in place and what efforts I
or others take.
> It's a chicken-and-egg thing: you can't understand the wikis until you know what the \
> terms are, and you can't understand the terms until you've learned the wikis.
>
mmmmmmm, disagree ... the wiki is meant to elucidate all terms ... and
hence its content should be comprehensible ... but if it isn't conveying
things properly, I will note that google will almost always provide a
source for an alternative definition or description ... as will
wikipedia, whose articles I observe show up more and more as one of the
first hits in a google search
> If anyone out there involved in documentation is interested in working on versions \
> that are more bozo-friendly, I'd be happy to help.
>
As I said, it takes a lot of time documenting things. If you can
document things clearer then they already are, and are up for the
challenge, then go nuts. Personally, I'm scaling back
> For example, one thing that seems \
> universally lacking in much Linux-related documentation (such as Man pages) is \
> examples. Even a distro-specific example, "in XYZ distro \
> /this/directory/this/command but yours may differ" is a huge help.
I'm diametrically opposed to such.
- First, it greatly misses the point that the features are supposed to
be distro-agnostic .... having a thousand nearly-non-differing-distros,
as the case is currently, is pretty retarded
- second, it would add bloat and reduce conciseness
- third, if distros want to screw something up so that it is no longer
done in an agnostic manner, then it is up to them up to document how
they do it ... as well as explaining or putting forth why their way is
so much better then everyone else's way, other then for the sake of just
being different
- fourth, the examples given will gravitate towards the popular distros
... invariably, this will currently mean most will become populated with
Ubuntu examples ... I personally don't care too much for Ubuntu, and
consequently don't want to continuously be reading examples geared
toward it .... ever see the Simpson's episode in which one of Marge's
sisters envisions herself having a family with Hans Moleman
(http://en.wikipedia.org/wiki/Hans_Moleman) ? Well, if you have, then
if you hold in mind the vision of all those kids running around bumping
into each other (cause they're blind as bats and about as athletically
gifted as a side of a barn is), then you'll now know how much I cringe
reading through Ubuntu related forums etc. ...
> The wiki about \
> DVB Search is one of the best I've seen thus far in this tv search, because it's \
> clear, concise, and includes examples.
>
DVB Search? Sorry, I don't know to what you refer.
> In any case, ... it sounds like at this point, I've done what I can and have the few unencrypted digital channels configured \
> properly.
Yep, I think so.
> In any case,I greatly appreciate the answers and suggestions; ... I'll sign off and if I have questions in the future I'll try to ask them \
> in the proper way. Thanks for the tips on how to do that. I'm sorry my posts got \
> people (understandably) perturbed.
No worries. In any regard, I'm glad you didn't take it personally --
others (when confronted by the list orge ... who also is known to post
rhetorical questions designed to make the original poster realise how
ridiculous their expectation/comment/question was ) often don't take the
comments as objective criticism (as they are intended), but rather as
subjective and, hence, respond angrily in kind.
Well, that just about wraps up my time on the list this week ... tune in
next week when I put it to the next person if they really, and truly,
meant to click on the send button.
Cheers.
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
reply other threads:[~2008-03-16 19:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47DD792A.1060103@rogers.com \
--to=cityk@rogers.com \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox