[comp.os.os2] Stop Wasting Bandwidth On Binaries

artk@congrunt.uunet.uu.net (Art Kreitman @ Congruent) (12/28/89)

     There seems to be a rash of binary postings from one spot with an
overactive C compiler.	  Their not needed, they don't add to the discussion,
they all will have to be redone to accomidate Extended Attributes and Long
File Names that are part of OS/2 1.2.	If you can't shut down you compiler,
start a vote for a comp.sources.os2 or comp.binaries.os2, stop flooding
two continents worth of news.
Art Kreitman					uunet!congrunt!artk
Congruent Corp. 				congrunt!artk@uunet.uu.net
110 Greene Street
New  York, NY 10012				212-431-5100

slh@fred.cs.washington.edu (Scott Heyano) (12/28/89)

Don't be an asshole and learn how to spell.

tholen@uhccux.uhcc.hawaii.edu (David Tholen) (12/29/89)

In a recent posting, the view was expressed regarding OS/2 binaries that:

> "Their [sic] not needed..."

Maybe not needed (is anything necessary?), but wanted and appreciated.

> "...they all will have to be redone to accomidate [sic] ... OS/2 1.2."

I have downloaded several utilities that make absolutely no use of filenames
and in fact work just fine under version 1.2.  Those that DO use filenames
still work; it's just that they don't support the long filenames now
permitted, thus they don't "have to" be redone (1.2 is downward compatible
with the short filenames used by the FAT method) but should be if they want
to support long filenames.

Incidentally, the "bandwidth" used is the same whether the destination is
comp.os.os2 or comp.binaries.os2.  The only difference is whether you see
them in comp.os.os2 or not.  If you'd rather not see them, just skip them
when scanning new postings.

Just wanted to let our person "with the overactive C compiler" know that not
everyone shares the view represented above.  Keep up the good work.

root@dialog.UUCP (Christian Motz) (12/29/89)

In article <5.UUL1.3#5085@congrunt.uunet.uu.net> artk@congrunt.uunet.uu.net (Art Kreitman @ Congruent) writes:
>
>     There seems to be a rash of binary postings from one spot with an
>overactive C compiler.	  Their not needed, they don't add to the discussion,
>they all will have to be redone to accomidate Extended Attributes and Long
>File Names that are part of OS/2 1.2.	If you can't shut down you compiler,
>start a vote for a comp.sources.os2 or comp.binaries.os2, stop flooding
>two continents worth of news.

With the lack of utilities that exists for OS/2, I (and I am sure that
I am not the only one) support the posting of binaries fully, although
I would like to see more sources. But posting the binaries definitely
is worth more than most "discussions" in this newsgroup.

..FLAME ON
Learn how to spell before you drivel about wasting net bandwidth!!!
..FLAME OFF

Followups to junk, flames to /dev/null, NUL: or NIL:, depending on your OS.

--
Christian Motz           uucp: ...!uunet!mcsun!unido!nadia!dialog!root
"Trust me, I know what I'm doing!" -- Sledge Hammer         Bix: cmotz

peter@ficc.uu.net (Peter da Silva) (12/31/89)

In article <5845@uhccux.uhcc.hawaii.edu> tholen@uhccux.uhcc.hawaii.edu (David Tholen) writes:
> Incidentally, the "bandwidth" used is the same whether the destination is
> comp.os.os2 or comp.binaries.os2.  The only difference is whether you see
> them in comp.os.os2 or not.  If you'd rather not see them, just skip them
> when scanning new postings.

Not to this site, or many another site with a UUNET feed. We get comp.os.os2,
but we don't get general binaries groups and wouldn't get comp.binaries.os2.
In fact, if binaries start being a problem, we won't get comp.os.os2 either.

The only binary group we get is comp.binaries.ibm.pc, because of certain daft
decisions made by the likes of IBM and Microsoft nearly 10 years ago. One hopes
that they don't do the same again...
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com

wayne@dsndata.uucp (Wayne Schlitt) (01/02/90)

as i see it, there are three advantages to getting rid of binaries
(and/or sources) from a discussion group:

1) for those who dont want to use the bandwidth, it is much easier to
   just not get comp.binaries.*

2) for those with tight disk space, you can expire the binary/source
   groups quicker

3) archive sites can be set up for the binary/source groups so that
   those who missed the goodies the first time can get them later..


as kind of a separate questions, many of the binaries that i have seen
float through comp.os.os2 have been "standard" unix programs.  (which
is fine...)  were these simply compile and run type of ports to os2,
or did you have to make a lot of changes to the sources?

if they are simple compiles, i guess i do object to the binaries being
posted.  for those who want them, it would be a lot less bandwidth to
just mail them.

if they are not simple ports, then wouldnt it be better to post the
sources and/or diffs?  that way people can fix bugs and make
improvements to the ports.  

the binary postings _have_ raised the size/article ratio for
comp.os.os2 quite a bit and has also raised the cost per reader to
number 5 in Brian Reid's lists.  comp.os.minix is also high, but most
of the large postings there are source.


-wayne

peter@hpkslx.HP.COM (Peter Huang 1-691-3417) (01/03/90)

>/ hpkslx:comp.os.os2 / wayne@dsndata.uucp (Wayne Schlitt) / 10:47 am  Jan  1, 1990 /
>
>
>as i see it, there are three advantages to getting rid of binaries
>(and/or sources) from a discussion group:
>
>1) for those who dont want to use the bandwidth, it is much easier to
>   just not get comp.binaries.*
>
>2) for those with tight disk space, you can expire the binary/source
>   groups quicker
>
>3) archive sites can be set up for the binary/source groups so that
>   those who missed the goodies the first time can get them later..
>
First, I support the posting of binary/sources in this group.
Because, 1) I just start using os/2 and I don't have anything to start
with. Having these binares helps a lot.
2) this group is so tiny compare to comp.binary.ibm.pc, however, if
this group get as big as comp.binary.ibm.pc then I think there will
be a lot of cry for separation. By then, we can take a vote right :-)

I appreciated the person doing the work and posting the result,
I also see the points in saving load time and disc space.  Let's wait
a little bit and see how this group will go.


	============================================
	Peter Huang / HP Response Center Lab
	Mail: peter@hpkslx.HP.COM 
	============================================

darcy@druid.uucp (D'Arcy J.M. Cain) (01/05/90)

In article <12760001@hpkslx.HP.COM> peter@hpkslx.HP.COM (Peter Huang 1-691-3417) writes:
>First, I support the posting of binary/sources in this group.
>Because, 1) I just start using os/2 and I don't have anything to start
>with. Having these binares helps a lot.

But having the binaries in a separate newsgroup wouldn't stop you from
having access to the binaries.

One of the things I like about the newsgroup method is that it allows me, as
an administrator, to decide what I am going to receive.  As I am basically
a leaf node, I can download the stuff that I want/need and shut off the rest
before it is sent to me by my feeder site.  I only have one 2400 baud modem
and it is needed for other things besides news so I cut down on the total
amount of bandwidth by not receiving all groups including the binary groups.
This is easy when they are subsumed under one heading.  If individual groups
are going to sneak this extra bandwidth in to me by posting binaries to
non-binary groups then I may have to cut out more news to keep my modem free
for business.  Let's not undercut the scheme that has been worked out after
much trial and error.  At least not without much wider discussion.

Followups directed to news.groups

-- 
D'Arcy J.M. Cain (darcy@druid)     |   Thank goodness we don't get all 
D'Arcy Cain Consulting             |   the government we pay for.
West Hill, Ontario, Canada         |
No disclaimers.  I agree with me   |

rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (01/09/90)

I would vote for creating separate news groups for OS/2 sources and
binaries. Of course many of the programs posted here in the last time
were ports of well-known Unix programs (although they are not STANDARD
unix programs, they are PD, or did you ever hear of a Unix coming with
MicroEMACS or GNU awk included ?). But some ports were not as easy as
someone could expect (MicroEMACS :-) and many OS/2 users may not have
access even to the Unix sources.

How could creation of these new newsgroups be initiated ? If someone
could do it (perhaps somone sitting in Amerika and not in old Europe)
I think he should do so.

Kai Uwe Rommel
Munich
rommel@lan.informatik.tu-muenchen.dbp.de

kluge@lan.informatik.tu-muenchen.dbp.de (Oliver Kluge) (01/10/90)

In article <1034@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes:
>I would vote for creating separate news groups for OS/2 sources and
>binaries. [...]
>Kai Uwe Rommel
>rommel@lan.informatik.tu-muenchen.dbp.de

Hello !

Yes, I would also appreciate doing this. comp.binaries.os2 was
mentioned by some users. We don'/t get such a newgroup
so I want to ask wether such a newsgroup does really exist?
If not, please create one!

So long ... Oliver Kluge

--
                                         / relay.cs.net (CS-NET, ARPA)
kluge%lan.informatik.tu-muenchen.dbp.de@ - unido.uucp   (UUCP)
					 \ unido.bitnet (BITNET)
TTTTTTUU  MUMMMMMMMM              Technical University Munich
TTTTTTUU  UMMMMMMMMM  Department of Mathematics and Computer Sciences SAB
  TT  UU  MU  MM  MM           Laboratory for Parallel Computing
  TT  UU  UM  MM  MM                    Arcisstrasse 21
  TT  UU  MU  MM  MM                     8000-Munich 2
  TT  UUUUUM  MM  MM              Federal Republic of Germany
  TT  UUUUMU  MM  MM        Vc +49 89 2105-2028, Fax +49 89 2800529
"Why stop now just when I'm hating it?" Marvin, the paranoid android
                                         / relay.cs.net (CS-NET, ARPA)
kluge%lan.informatik.tu-muenchen.dbp.de@ - unido.uucp   (UUCP)
					 \ unido.bitnet (BITNET)
TTTTTTUU  MUMMMMMMMM              Technical University Munich