gnu@hoptoad.uucp (John Gilmore) (07/27/87)
Just ask your news feed(s) to stop forwarding them. Remove them from
your active file. rm -rf /usr/spool/news/comp/binaries. I did it and
it worked (almost). Occasionally I have to flame somebody who posts
a binary to some other newsgroup (comp.text.desktop was the most recent)
but for the most part people put things where they belong.
In the jobs world it's called "voting with your feet". The nice part
is that, even if the rest of the Usenet continues to have problems with
binaries, YOU won't...and if enough people agree with you, the whole
problem will go away. E.g. the people who want binaries will pay for
moving them, and the ones who don't, will opt out.
This is sort of an inverse "alt" guerilla effort. In "alt" the point was
to be able to carry groups that the backbone wouldn't carry. Here the
point is to NOT carry groups that they do carry. Who runs your machine anyway,
you or them, answer yes or no... :-))
John
PS: Webber's offer sounds magnificent to me. The guys who are complaining
that it doesn't have libraries, ANSI, etc...why don't YOU contribute something
to the effort?
--
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@postgres.berkeley.edu
Alt.all: the alternative radio of the Usenet.sns@genghis.UUCP (Sam Southard) (07/27/87)
In article <2524@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > PS: Webber's offer sounds magnificent to me. The guys who are complaining > that it doesn't have libraries, ANSI, etc...why don't YOU contribute something > to the effort? Because they are satisfied with the C compiler they have. It's not their project, so why should they work on it? Webber said he would write it as some sort of solution to the problem of posting binaries (I would rather have all postings be source, also, but let's be realistic). Since he's bothered with the situation, let him fix it. As long as I'm here, I might as well put my two cents in. I do most, if not all, of my work on a PC/AT. A lot of the sources that are put out make some assumptions about sizeof(int) among other things. They won't work on the AT with the Lattice C or Microsoft C under DOS or the Xenix C compiler (I have all three). It's not the fault of the compiler, but the assumptions of the author (to avoid flames, I'd like to be able to make such assumptions, and they are not unreasonable. Unfortunately, the are also not valid for the AT). Unless you can regulate the source of all the postings, a PD compiler won't help much. Unless, of course, Webber's compiler will support all the assumptions made by a lot of the programs (BSD, sizeof(int), etc.) at least one binary group will have to stay, comp.binaries.ibm.pc. -- Sam Southard, Jr. {sns@genghis.caltech.edu|sns@genghis.uucp|{backbone}!cit-vax!genghis!sns}
michael@stb.UUCP (Michael) (07/29/87)
In article <174@genghis.UUCP> sns@genghis.UUCP (Sam Southard) writes: >As long as I'm here, I might as well put my two cents in. I do most, if not >all, of my work on a PC/AT. A lot of the sources that are put out make some >assumptions about sizeof(int) among other things. They won't work on the AT >with the Lattice C or Microsoft C under DOS or the Xenix C compiler (I have >all three). It's not the fault of the compiler, but the assumptions of the >author (to avoid flames, I'd like to be able to make such assumptions, and >they are not unreasonable. Unfortunately, the are also not valid for the AT). Here's an excellent solution to this problem (and one I wish the IBM compilers had as an option, at least): Make sizeof int == sizeof long == sizeof char* == sizeof void*. In other words, if you need 32 bits for a long, then ints will also be 32 bits. Pointers need (if I understand correctly how the segmemting works) 48 bits (32 offset, 16 for seqment reg). So, make all ints/longs reserve 48 bits of data and only use 32. PRESTO! You can assign ints/longs/char *'s interchangibly. You can forget to force that NULL to a (char *)NULL and it will still work. Realize: C is NOT ASSEMBLY (except on the pdp-11 :-). It is a language. Whether that implementation is super-optimized or is portable is a decision made by the compiler author. Commercial ones go for the efficiency. PD ones can go for portability. (in case you're curious: I have a C compiler for a 68000 that has a flag for 16 bit, efficient ints vs. 32 bit, compatible ints. Since the O/S was written with a different compiler (32 bit ints), the option was the only way to go). -- : Michael Gersten seismo!scgvaxd!stb!michael : Copy protection? Just say Pirate! (if its worth pirating)