I think it is a problem on QSSL side, because even posts into
comp.os.qnx via google won’t show up in nntp://inn.qnx.com/comp.os.qnx
but they show up in my ISP’s news server.
On the other side, we will have our own search engine real soon now. openqnx.com currently has the browse/posts web interface to inn.qnx.com
for all qdn.* groups and comp.os.qnx. The search capability will be
added in the near future.
Asking google to add more qdn.* groups should probably come from QSSL,
if it works at all. There may require some $$, but that is definitely
worthwhile from QSSL’s point of view.
Asking google to add more qdn.* groups should probably come from QSSL,
if it works at all. There may require some $$, but that is definitely
worthwhile from QSSL’s point of view.
instead of spending $$, QSSL may choose to do it themselves.
Bill Bull took qdn a few months ago, I am sure he is busy working
on a solution, since his appearance on the qnx irc is far less
frequent lately
I think it is a problem on QSSL side, because even posts into
comp.os.qnx via google won’t show up in nntp://inn.qnx.com/comp.os.qnx
but they show up in my ISP’s news server.
Dropping comp.os.qnx is QSSL’s feed problem, but
seeing qdn.* outside of qnx.com (ex.Google) may be an another problem.
As I said in the first article, someone maybe just
suck/nntpget/etc-ing inn.qnx.com for article into local NNTP server
If anybody can get the Path: header from non-*.qnx.com NNTP servers
probably you can get where it is leaking out from.
And if above facts were true, thus qdn.* is not distributing outside but
merly just leaking out, it isn’t healthy and there’s no point to
request adds to Google whoever the requester is
(including QSSL; stopping the leak or
authorizing proper NNTP exchange should be first)
On the other side, we will have our own search engine real soon now. openqnx.com currently has the browse/posts web interface to inn.qnx.com
for all qdn.* groups and comp.os.qnx. The search capability will be
added in the near future.
