GUI libraries for C (not C++)

S

Synic

Hi guys.

It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.

Any suggestions?
 
S

Stephen L.

Synic said:
Hi guys.

It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.

Any suggestions?


http://www.libsdl.org/index.php

might be one possibility...


Stephen
 
E

Emmanuel Delahaye

In 'comp.lang.c' said:
It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.

It's off topic here. Hints:

SDL
OpenGL
gtk+/Gnome

Don't ask here for details.
 
S

Synic

Emmanuel Delahaye said:
It's off topic here. Hints:

SDL
OpenGL

Neither's really a X11/MS Windows GUI library though; more 3D graphics
libraries.
gtk+/Gnome

I was under the impression GTK's C++. I'll check on that.
Don't ask here for details.

C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?
 
R

Randy Howard

C library questions seem to be common here, along with demands for them
to stop. I'm surprised nobody's gotten around to creating a
comp.lang.c.libs group to give people an alternative for these sort of
queries. What's been the barrier?

The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link:
http://www.eskimo.com/~scs/C-faq/top.html
 
O

Ori Bernstein

Hi guys.

It's been a while since I've done programming in C. What I'm after is a
multi-platform library (X11 and MS Windows at a minimum) which is not
C++ that will let me program GUI apps. Something simple and straight
forward to work with; ideally, open source.

Any suggestions?

Gtk+ 2.x
www.gtk.org for downloads/tutorials.
 
S

Synic

Randy Howard said:
The main barrier seems to be people not willing to read the FAQ, which
is common practice for those with knowledge of Usenet and its practices.
Since you seem to be unaware of its location, try this link:
http://www.eskimo.com/~scs/C-faq/top.html

Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.

Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal. I've created two other groups (in the aus.* heirarchy)
with a similar formalised creation procedure to comp.*.

An early draft version of the charter is here:

2. Charter

This newsgroup is for discussion of issues relating to C libraries,
toolkits and other add-ons to the C language which may not be
considered "on-topic" for the pure C language group.

Examples of on-topic discussion includes:

* Which C library to choose for tasks,
* Changes to C structure which might affect libraries,
* Costs and benefits of different libraries on a technical basis,
* How to use common libraries,
* Porting of useful features and functions from other languages
to be used with C in libraries.
* Any other issue which is C related but unwelcome in
comp.lang.c.

Examples of off-topic discussion include:

* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.

Some caveats for online behaviour exist:

* comp.lang.c.libs is a text-only discussion group. If what you
have to say absolutely requires HTML, text encoding or
binaries, posters should direct their potential readers to a
URL which contains these things.
* Advertising is not allowed in the body of messages to this
newsgroup. A standard four line .signature has more than enough
room to alert readers to your company and its services.
* Be aware that some participants will consider comp.lang.c.libs
more "real world" than others. The onus is on comp.lang.c.libs
users to recognize that libel laws exist. Ad hominem attacks
are discouraged.
* Cross-posting to flame-filled newsgroups is also discouraged.

comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3. Info on how the BI is calculated is in the
"Breidbart Index (BI) Definition" document currently at http://
www.stopspam.org/usenet/mmf/breidbart.html

It's been largely boiler-plated from the charter of aus.business. If
there are (useful) comments, suggestions or objections, now's the
best time to put them.

If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.
 
R

Richard Bos

Synic said:
Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.

Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal. I've created two other groups (in the aus.* heirarchy)
with a similar formalised creation procedure to comp.*.

An early draft version of the charter is here:

2. Charter

This newsgroup is for discussion of issues relating to C libraries,
toolkits and other add-ons to the C language which may not be
considered "on-topic" for the pure C language group.

Examples of on-topic discussion includes:

* Which C library to choose for tasks,
* Changes to C structure which might affect libraries,
* Costs and benefits of different libraries on a technical basis,
* How to use common libraries,
* Porting of useful features and functions from other languages
to be used with C in libraries.
* Any other issue which is C related but unwelcome in
comp.lang.c.

I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.
Examples of off-topic discussion include:

* Which C++ library to choose for tasks.
* Which modules would be great to use with Perl, PHP or Python.

I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:

* How to code something using POSIX, or using the MS Windows API.
Some caveats for online behaviour exist:

* comp.lang.c.libs is a text-only discussion group. If what you
have to say absolutely requires HTML, text encoding or
binaries, posters should direct their potential readers to a
URL which contains these things.
* Advertising is not allowed in the body of messages to this
newsgroup. A standard four line .signature has more than enough
room to alert readers to your company and its services.
* Be aware that some participants will consider comp.lang.c.libs
more "real world" than others. The onus is on comp.lang.c.libs
users to recognize that libel laws exist. Ad hominem attacks
are discouraged.
* Cross-posting to flame-filled newsgroups is also discouraged.

comp.lang.c.libs explicitly welcomes the use of binary message
cancelers and anti-spam cancelers which apply a Breidbart Index
threshold of 3.

I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).
If there are good reasons why comp.lang.c.libs should not be created,
now's also the best time to put them.

On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.

Richard
 
S

Synic

Richard Bos said:
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.

M$VC++-specific questions would be out because they're C++ anyway :).

POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.

In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
A very different character to complement comp.lang.c rather than
ape it.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:

A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.

That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.
* How to code something using POSIX, or using the MS Windows API.

The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).

In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.

Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.

There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.

Thanks for the vote of confidence :).

I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.
 
R

Rob Thorpe

Synic said:
Richard Bos said:
I'd advise against this last point; you'll be inundated with POSIX- and
M$VC++-specific questions.

M$VC++-specific questions would be out because they're C++ anyway :).

POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.

In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.
A very different character to complement comp.lang.c rather than
ape it.
I'd add strictly system-specific discussions, as well, since they're
better held on system-dedicated newsgroups. E.g.:

A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.

That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.
* How to code something using POSIX, or using the MS Windows API.

The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language.
I'm not sure that this is a good idea, either; third-party canceling is
a hairy issue which should not and need not be fought on a newsgroup
level, but by the owners of news servers (for whom it is easier to
simply dump binary posts to non-binary groups anyway, as the last three
I've used all do already - I presume the same thing is true for multi-
and cross-posts).

In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.

Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.

There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.
On the contrary. Unlike earlier suggestions of this ilk, this one
actually seems a good idea to me, with the few exceptions I've noted.

Thanks for the vote of confidence :).

I've put up the RFD draft at http://clcl.autons.net/. It'll no doubt see
some modification as comments are made here.

Sounds like a good idea to me.

A possible way to stop POSIX and MS Win32 related traffic is to have
specific rules saying for example "Questions about POSIX libraries
should be directed to ...".
 
A

August Derleth

M$VC++-specific questions would be out because they're C++ anyway :).

You'd be surprised how few people can tell the difference.
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.

Why would you want to cover POSIX when comp.unix.programmer does such a
good job of that already?

Besides, not all POSIX stuff will be on-topic. POSIX defines the standard
command line syntax and some of the standard file locations, among other
things not related to C at all. comp.unix.programmer knows about this
stuff; will you? Will anyone in your group?
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.

General chat devolves into pure noise, and knowledgeable people tend to
dislike pure noise. The comp.* hierarchy is usually held to a higher
standard than alt.* or soc.*.
A very different character to complement comp.lang.c rather than
ape it.

I think comp.lang.c is is the way it is for a reason, and you should
understand it before you try to make your own newsgroup.
A good point, but, there's still the argument that system specific stuff
is just another library or incompatibility ripe for discussion.

Again, most people who know about a specific system's stuff will most
likely be in newsgroups devoted to that system, not in comp.lang.c.libs.
Getting knowledgeable people to devote time to a new group will be hard.
That said, I agree that it's a good idea for something like "It is
recommended that system-specific discussions are better held on
system-dedicated newsgroups. E.g.: [...]" to be added to the Caveats
section. More a sound suggestion than a dictate.

On Usenet, you have two tools: Sound suggestions and killfiles. Until
someone writes a client that recognizes X-Kill-Reader: [method], that's
all we've got.
The MS Windows API is really just a set of libraries. If/where there
are C functions (rather than C++ ones), discussion of these would be
fine, with recommendations that other groups will have more detailed
info which is not limited to the C language.

All APIs are just libraries, at least as far as the userland program is
concerned. This is one reason I think clc.libs will fail: It will attract
a host of system-specific questions but not necessarily any
system-specific expertise.
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist. It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.

Third-party canceling is, in my view, Bad and Wrong. It opens the
floodgates for abuse on a simply unprecedented level. I don't want to
subscribe to servers that honor such beasts, and I certainly don't want to
read groups where it's explicitly welcomed.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.

There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.

The BI is well and good for spam-control, but I think it should be up to
server admins to do it, not vigilantes with explicit liberty to cancel
posts at random. The server admins feel the financial pain from spam,
since they own the machines spam pollutes most heavily, and they should
be given the reigns when it comes to controlling it.
Thanks for the vote of confidence :).

I'd think it would be a good idea if I wasn't convinced of its failure.
Not exactly a vote of confidence, but you'll hear worse if this isn't
completely ignored.
 
S

Synic

August Derleth said:
Why would you want to cover POSIX when comp.unix.programmer does such a
good job of that already?

However, there may be useful discussion involving libraries which
provide POSIX compatibilities to otherwise non-compliant OSes. I'm not
convinced there's a reason to explicitly recommend against discussing
these sorts of libraries because of their functionality.
Besides, not all POSIX stuff will be on-topic. POSIX defines the standard
command line syntax and some of the standard file locations, among other
things not related to C at all. comp.unix.programmer knows about this
stuff; will you? Will anyone in your group?

Thus the recommendation that system-specific queries go to system
specific groups is the good way to go. If posters follow that, great.
If they don't, they reap the reward of someone telling them they'd be
better off asking in whichever is more appropriate.
General chat devolves into pure noise, and knowledgeable people tend to
dislike pure noise. The comp.* hierarchy is usually held to a higher
standard than alt.* or soc.*.

Wasn't quite meaning alt.* or soc.* type "general chat" there.
I think comp.lang.c is is the way it is for a reason, and you should
understand it before you try to make your own newsgroup.

What works with one group does not work for all. Ideally, the plan is
for the clc purists to keep clc. People who use libraries and want to
discuss getting things to work in wierd and wacky environments and
across disparate platforms, use clcl and perhaps move off to system
specific groups if discussion goes that way.

Some on clc would never be seen on clcl. I'm also of the opinion that
there may be some on clc who will welcome the chance to jump ship to a
group where every fourth article isn't someone saying "not strictly on
topic, go away" in response to questions relating to C programming :).
Again, most people who know about a specific system's stuff will most
likely be in newsgroups devoted to that system, not in comp.lang.c.libs.
Getting knowledgeable people to devote time to a new group will be hard.

By all means, people can be refered to other groups if their discussion
will be better served there.
All APIs are just libraries, at least as far as the userland program is
concerned. This is one reason I think clc.libs will fail: It will attract
a host of system-specific questions but not necessarily any
system-specific expertise.

System specific expertise isn't required. It's not a strictly system
specific group. Want to talk about GTK? clcl. Programming with ncurses?
clcl. Which is a good cross-platform GUI library? clcl.
Third-party canceling is, in my view, Bad and Wrong. It opens the
floodgates for abuse on a simply unprecedented level. I don't want to
subscribe to servers that honor such beasts, and I certainly don't want to
read groups where it's explicitly welcomed.

The BI is strictly about repetitive postings (spam) and overly large
crossposts (spam and pests). That's pretty much it.
The BI is well and good for spam-control, but I think it should be up to
server admins to do it, not vigilantes with explicit liberty to cancel
posts at random.

Not at random.

Q: How does the Breidbart Index (BI) work?

A: The BI is defined as the sum of the square roots of n (where n is
the number of newsgroups each copy was posted to, over a 45 day
period). The standard BI threshold in protected groups on Usenet is
20. The people in the Netherlands nl.* hierarchy have apparently gone
with 8.

Example: If two copies of a posting are made, one to 9 groups,
and one to 16, the BI index is sqrt(9)+sqrt(16) = 3+4 = 7.

Example: If three copies of a posting are made, two to one group
each and the third to 3 groups, the BI index is sqrt(1)+sqrt(1)
+sqrt(3) = 1+1+1.73 = 3.73.

Example: One posting is cross-posted to 9 groups, the BI index is
sqrt(9) = 3 = 3.

Many news servers will have already culled articles cross-posted to 8
or more newsgroups just on principle :). Recommending a BI threshold
of 3 is a very aggressive anti-spam posture. The calculation of BI
levels is discussed in more detail at http://www.stopspam.org/usenet/
mmf/breidbart.html

Genuine postings are never going to be hit by the Breidbart Index at 3.

Now clcl could easily adopt a less aggressive anti-spam posture to
aus.business if people really want. It'd be embarrassing, but hey. I'm
ready to be convinced by the hoards :).
The server admins feel the financial pain from spam,
since they own the machines spam pollutes most heavily, and they should
be given the reigns when it comes to controlling it.

There's nothing stopping them from keeping the reigns. With most news
server software, you can happily ignore cancels and even block reposts.
Can't say any of that's been relevant or needed for aus.business up to
this point or for the Netherlands nl.* hierarchy, to my knowledge.
I'd think it would be a good idea if I wasn't convinced of its failure.
Not exactly a vote of confidence, but you'll hear worse if this isn't
completely ignored.

Thanks for the feedback.
 
R

Richard Bos

Synic said:
M$VC++-specific questions would be out because they're C++ anyway :).

M$VC++ can be used to compile C as well, AFAIAA. Even so, you'll get
your share of VC++ questions as much as c.l.c does.
POSIX- related questions would probably be on topic. If it's not
strictly C, then it'll likely be a library somewhere.

If it _is_ strictly C, it's also likely to be in a library somewhere:
libc, glibc, libmath, whateverVCcallsit.lib, and so forth.
In this sense, I'd rather see comp.lang.c.libs be a much more
inclusive group than comp.lang.c and more open to general chat.

In that case, your group will succumb under the weight of the POSIX-only
and M$VC-only rubble, which would be better answered on POSIX and M$
newsgroups in the first place.
The MS Windows API is really just a set of libraries.

That's no argument. The same thing is true of _all_ functions a C
implementation provides, whether they are Standard or not.
In practice, third-party canceling hasn't been done yet on aus.business.
However, it's been a great morale booster there for the recommendation
to exist.

Not to me, it isn't. Third-party canceling is infinitely abusable, and I
wouldn't post anywhere where I ran a serious risk of having my posts
canceled by anyone but me. Luckily, AFAIK news.individual.net does not
honour third-party cancels, and that is as it should be.
It also ensures that spammers can be duly larted since the
anti-spam stance is so clear in the charter.

If you think Usenet works like that, think again.
Also, in practice, the kill/resurrect pattern you see where these wars
hot up also generally see crosspostings retained. So crossposted
kills/resurrects still won't be seen if you limit crossposts with your
own server software.

Huh? Sorry, but that just doesn't seem to relate to anything.
There's a fair bit more info on the Breidbart Index in the RFD draft for
anyone curious.

Discussions of one person's opinions on spam canceling do not belong in
an RFD - _certainly_ not when that one person takes a stance as extreme
as yours. BI of _three_? Good grief.

Richard
 
R

Randy Howard

Nup. Nothing in that FAQ points me to other groups to ask C library
questions in. Perhaps that's why your group's continually beseiged by
these questions.

It does, but not by name. (See section 19 for the most applicable ones).
You'll note that newsgroup names change over time. Also, most respondents
when asked a question like "Where can I find out how to program using
multiple threads in C?" will get a brief answer such as:
"comp.programming.threads" would be a very good choice."
from one of the regulars here. I don't see a problem with that.

Problems about libraries are usually answered in a similar fashion, but
not discussed at length in this group. www.sf.net is the canonical place
to find such information anyway.
Since there's been no barrier to the creation of a group, I'm writing up
an RFD proposal.

Congratulations.
 
S

Synic

Rob Thorpe said:
Sounds like a good idea to me.

:)
A possible way to stop POSIX and MS Win32 related traffic is to have
specific rules saying for example "Questions about POSIX libraries
should be directed to ...".

I'd rather leave that to a clcl "Welcome and Newsgroup FAQ", posted on
the 1st and the 15th of each month, rather than the charter per se. It's
much easier to update a regular Welcome posting with changes as needed.
 
S

Synic

Richard Bos said:
M$VC++ can be used to compile C as well, AFAIAA. Even so, you'll get
your share of VC++ questions as much as c.l.c does.

If they're compiling C, then great. Entirely on topic.

VC++ can be redirected elsewhere or ignored. Same as they would be in
any group.
If it _is_ strictly C, it's also likely to be in a library somewhere:
libc, glibc, libmath, whateverVCcallsit.lib, and so forth.
Yup.


In that case, your group will succumb under the weight of the POSIX-only
and M$VC-only rubble, which would be better answered on POSIX and M$
newsgroups in the first place.

You seem to have made up your mind on this. Personally, I don't see the
drama. clcl isn't meant to be a clone of clc and frankly I don't see the
world coming to a grinding halt if C libraries are discussed which might
be platform specific or not.

If it's a C library, it would be on topic for clcl (not clc). We're not
talking about changes to clc at all here. If anything, clcl should help
to reduce the load for clc by providing an alternative place that allows
discussions that clc doesn't want and the purists find offensive.
That's no argument. The same thing is true of _all_ functions a C
implementation provides, whether they are Standard or not.
Yup.

Not to me, it isn't. Third-party canceling is infinitely abusable, and I
wouldn't post anywhere where I ran a serious risk of having my posts
canceled by anyone but me. Luckily, AFAIK news.individual.net does not
honour third-party cancels, and that is as it should be.

If you're crossposting to nine groups at once or repeatedly posting the
same article, you should expect people to find this annoying. If you're
not, it's unlikely you'll be affected at all and this not at "serious
risk".
If you think Usenet works like that, think again.

Many ISPs out there like to have proof that advertising is "off-topic"
in a Usenet group before they'll act. An anti-spam charter demonstrates
that.

[...]
Discussions of one person's opinions on spam canceling do not belong in
an RFD - _certainly_ not when that one person takes a stance as extreme
as yours. BI of _three_? Good grief.

A charter is where general points are made about what is acceptable on a
newsgroup. This extends to whether the group accepts advertising,
HTML formatting, binary encoding, etc. A point on the policy by which
a group welcomes message cancelling fits in there.

This is from the Welcome draft not the RFD, btw:

Q: How does the Breidbart Index (BI) work?

A: The BI is defined as the sum of the square roots of n (where n
is the number of newsgroups each copy was posted to, over a 45 day
period). The standard BI threshold in protected groups on Usenet is
20. The people in the Netherlands nl.* hierarchy have apparently
gone with 8.

Example: If two copies of a posting are made, one to 9 groups,
and one to 16, the BI index is sqrt(9)+sqrt(16) = 3+4 = 7.

Example: If three copies of a posting are made, two to one
group each and the third to 3 groups, the BI index is sqrt(1)
+sqrt(1)+sqrt(3) = 1+1+1.73 = 3.73.

Example: One posting is cross-posted to 9 groups, the BI index
is sqrt(9) = 3 = 3.

Many news servers will have already culled articles cross-posted to
8 or more newsgroups just on principle :). Recommending a BI
threshold of 3 is a very aggressive anti-spam posture. The
calculation of BI levels is discussed in more detail at http://
www.stopspam.org/usenet/mmf/breidbart.html

If the BI issue is felt likely to trap too many posters who like to
crosspost excessively or repeatedly spam the new group, then I have no
particular objections to raising it to 8 or 20 or removing it entirely
to nullify it as an issue.

At this stage though, I can't see any technical way that a BI of 3
would inhibit someone who is posting in any normal way to a newsgroup.
If you can find any non-spam article in your current spool for clc
that matches the criteria of a BI of 3, I'll be mighty surprised.

(As always, the draft of the RFD is at http://clcl.autons.net/ for the
perusal of all interested parties. Comments and queries welcome.)
 
C

CBFalconer

Synic said:
.... snip ...

If you're crossposting to nine groups at once or repeatedly
posting the same article, you should expect people to find this
annoying. If you're not, it's unlikely you'll be affected at all
and this not at "serious risk".

If you are crossposting to three groups, and failing to set
followups to cut it back to one, you are a serious annoyance.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top