eggert@twinsun.com (Paul Eggert) (03/02/91)
I also have been troubled by the overbroad mandate and poorly chosen name of comp.sources.reviewed. We used to have newsgroups with poorly chosen names containing `moderated' or `mod', but I had thought we learned our lesson that newsgroup names should reflect their contents, not their editorial methods. But karsten@tfl.dk writes: >Many of the bested public domain packages have been ported from UNIX >to other operating systems, and some the other way. In the future, we >can expect people will comply with the posix standards, which will >supported on many operating systems. So in the future packages will >not be for one operating system. This suggests that for sanity's sake, the newsgroup will stick to Posix (or at least Posix-like) applications. It also suggests that competent reviewers will check for Posix conformance. This will indeed be a service to the computing community. If so, I suggest that the name of the proposed newsgroup be changed to `comp.sources.posix', because it will reflect the newsgroup's contents far more accurately.
wht (Warren Tucker) (03/03/91)
In article <1991Mar1.163137.293@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >This suggests that for sanity's sake, the newsgroup will stick to Posix >(or at least Posix-like) applications. It also suggests that competent >reviewers will check for Posix conformance. This will indeed be a >service to the computing community. My 2e-02 cents worth on c.s.u/c.s.m and the article subject. C.S.M/C.S.U/C.S.R BABBLE, ER, DISCUSSION ---------------------------------------- I love how somebody recently said "[I enter into this discussion carefully]." I appreciate the mammoth job of moderating c.s.u and understand how long periods of time can pass with no activity. I suspect Mr. $alz of having to commit paid commerce so he has shekels for gas to and from work. This obviously takes him away from net.demands. I pass no judgment upon him and have no opinion on "what we should do about c.s.u." c.s.m is a very good alternative for distribution. Brandon was and Kent is very helpful in getting releases organized and sane. Both have saved me from extremely red faces (not that it hasn't been Pink a few times anyway :-)). But there is where it stops. This has been fine for me. Between (c.s.u) heavy testing with delays and (c.s.m) administrative help only with blindingly fast transmission some perceive a void. comp.sources.reviewed seems to me a viable middle ground. Let me use my ECU as a straw dog for comparing the various groups. I sent a thoroughly nauseating posting, 2.70, my first large one, through alt.sources and got my first healthy taste of flames and good suggestions. Only a few people came forward, but enough to get OS version differences and other issues settled. Alt.sources gave me the chance for a smoke test and resulted in a sounder offering. I submitted ECU 2.74 to comp.source.unix a couple of years ago. It was delayed (I might offer that it was about the time the Smithsonian astronomical package and other large stuff was going through). I o got tired of waiting o upraded the program to 2.8 during that time. While nothing came out on the net, the ultimate offering did benefit from the delay. For me, at least, I often find that no matter how hard I work on a business letter, I usually find improvements I could have soon after I mail it. So, c.s.u was a plus. I submitted 2.8 to the net via c.s.m. It was then that my great Q.A. friend, Tom Betz (tbetz@upaya) came forward with all manner of bugs, suggestions, and best of all, encouragement. He put the program through more hoops and advanced use than I very likely ever will. When it came time for ECU 3, I had added new features that I and Tom could test, but also "experimental" features neither of us could test well or at all: various terminals for non-ANSI support, the ISC port attempt and the GCC environment. As a result, after 6 patches future downloaders will have to know about and hunt for (thanks for the patchlog, Kent!), ECU 3 is stable. Had c.s.reviewed been around, a ready mechanism would have been in place that perhaps would have eliminated *all* those patches. While the net would have had to wait for ECU 3 a while longer (breathlessly, no doubt :-)), many would also have been spared seeing a rash of patches, including one that Broke the published version and had to have a patch to a patch. Now, you may say, "Warren, c.s.r may have kept you from making several knee jerk postings, but some of us are more mature and careful in our submissions." I agree in part. There are many wonderful offerings in all the groups which have never required a single patch. I wish I were that good ;->, but I am not alone in trying to code for environments I don't have. Patches are inevitable in those cases. C.S.M/C.S.U/C.S.R BOTTOM LINE ----------------------------- c.s.r would o provide a more reliable and organized way to find motivated tester-critics o increase the number of cases and environments for testing o improve the end product and reduce patch frequency o more than compensate for delays in net.delivery. o should be a comp.sources."new-and-augmenting" not a comp.sources. "all-is-made-new" or comp.sources."death-to-$alz". C.S.POSIX COMMENT ----------------- UNIX C and shell scripts, VMS C and shell scripts, Perl scripts, awk scripts, MSDOS C, assembler and Pascal, X11 bitmaps, FORTRAN, Amiga C, standalone man pages and a host of other kinds of "source" have shown up there. o Many/most of these have no POSIX applicability; let's not exclude 90% of reality from the comp.sources."new-thang" o POSIX is better defined than the ANSI C pseudo-standard debacle and both have laudable goals; yet, both doomed us to not one extra environment to support, but a rash of mutltivariate interpretations of what different providers thought these standards meant; just say "no, FALSE, 0, EOF, NIL, NULL, NUL, "(null)", NAK, NAK, NAK, CAN, EOT, ...-.-" (but I diverse). ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me -- ---------------------------------------------------------------------------- Warren Tucker, Tridom Corporation, gatech!n4hgf!wht, wht@n4hgf.Mt-Park.GA.US When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. -Edmund Burke
eggert@twinsun.com (Paul Eggert) (03/03/91)
wht (Warren Tucker) writes:
UNIX C and shell scripts, VMS C and shell scripts, Perl
scripts, awk scripts, MSDOS C, assembler and Pascal, X11
bitmaps, FORTRAN, Amiga C, standalone man pages ... Many/most
of these have no POSIX applicability; let's not exclude 90% of
reality from the comp.sources."new-thang"
Posix excludes little of what you mention; it's a broad umbrella, or
soon will be. As for the rest, surely X applications should be posted
in comp.sources.x? And surely Amiga-specific stuff should be posted in
comp.sources.amiga, and similarly for other vendor-specific stuff like
assembler?
Will comp.sources.reviewed publish programs that don't conform to Posix
but could easily be made to? I hope not -- it'd mean the reviewers
weren't doing their job.laird@chinet.chi.il.us (Laird J. Heal) (03/03/91)
In article <1991Mar2.194702.18667@tridom.uucp> wht@n4hgf.Mt-Park.GA.US writes: >Let me use my ECU as a straw dog for comparing the various groups. >Had c.s.reviewed been around, a ready mechanism would have been >in place that perhaps would have eliminated *all* those patches. >While the net would have had to wait for ECU 3 a while longer >(breathlessly, no doubt :-)), many would also have been spared >seeing a rash of patches, including one that Broke the published version >and had to have a patch to a patch. Addressing only POSIX-compliant software is very good, but why not restate the newsgroup as specifically for software going through a beta or gamma test phase? That is, put it out so people can bang on it, apply patches, and then post the final result to groups which get archived. For things like "compress" implemented in COBOL, there are always either alt.sources or comp.sources.misc. -- Laird J. Heal The Usenet is dead! Here: laird@chinet.chi.il.us Long live the Usenet!
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/04/91)
In article <1991Mar3.051242.5879@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >wht (Warren Tucker) writes: >> UNIX C and shell scripts, VMS C and shell scripts, Perl >> scripts, awk scripts, MSDOS C, assembler and Pascal, X11... >Posix excludes little of what you mention; it's a broad umbrella, or >soon will be. Talk to me when it survives the test of time (i.e., its proponents have finished meeting, proposing, coffee drinking, and ArkB-ing and have actually implemented something). In the early 80's, some swore wemalltalk hackers by now. That umbrella is still rather leaky. >Will comp.sources.reviewed publish programs that don't conform to Posix >but could easily be made to? I hope not -- it'd mean the reviewers >weren't doing their job. POSIX is certainly not part of the agenda of most of my work, nor is it likely to be for a long time. If we write a program that can be POSIX-compatible, we should. But I won't use tcsendbreak() instead of ioctl(fd,{TCSBRK,TIOCSBRK},0) when most of real cyberspace (dev sys, headers, libraries) hasn't heard of the Newspeak yet. Now, if somebody wants to claim a source is POSIX compliant: Hi Ho. But to say reviewers must or should enforce POSIX is no more sensible than requiring compliance with the Chicago Manual of Style. Both of these specifications are good ideas -- in their places. No, too much useful stuff would be excluded. I did read your phrase 'easily be made to' and agree. But the response I made was to a proposal to name the new group 'comp.sources.posix' in lieu of 'comp.sources.reviewed'. Ever read _Life on the Mississippi_? Compare 'POSIX' with 'association men'. They will eventually rule simply because they stick together, but the River we swim (innovate) in will become more like molasses. (However, I assert that POSIX Perl will remain forever an oxymoron. If it ever comes to exist, the world will suddenly disappear in a poof of code inspection reviews. ;-> ). ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/04/91)
Pardon me if this is a duplicate. I had news errors and I *think* I cancelled the bad one. In article <1991Mar3.051242.5879@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >wht (Warren Tucker) writes: >> UNIX C and shell scripts, VMS C and shell scripts, Perl >> scripts, awk scripts, MSDOS C, assembler and Pascal, X11... >Posix excludes little of what you mention; it's a broad umbrella, or >soon will be. Talk to me when it survives the test of time (i.e., its proponents have finished meeting, proposing, coffee drinking, and ArkB-ing and have actually implemented something). In the early 80's, some swore we'd all be smalltalk hackers by now. That umbrella is still rather leaky. >Will comp.sources.reviewed publish programs that don't conform to Posix >but could easily be made to? I hope not -- it'd mean the reviewers >weren't doing their job. POSIX is certainly not part of the agenda of most of my work, nor is it likely to be for a long time. If we write a program that can be POSIX-compatible, we should. But I won't use tcsendbreak() instead of ioctl(fd,{TCSBRK,TIOCSBRK},0) when most of real cyberspace (dev sys, headers, libraries) hasn't heard of the Newspeak yet. Now, if somebody wants to claim a source is POSIX compliant: Hi Ho. But to say reviewers must or should enforce POSIX is no more sensible than requiring compliance with the Chicago Manual of Style. Both of these specifications are good ideas -- in their places. No, too much useful stuff would be excluded. I did read your phrase 'easily be made to' and agree. But the response I made was to a proposal to name the new group 'comp.sources.posix' in lieu of 'comp.sources.reviewed'. Ever read _Life on the Mississippi_? Compare 'POSIX' with 'association men'. They will eventually rule simply because they stick together, but the River we swim (innovate) in will become more like molasses. (However, I assert that POSIX Perl will remain forever an oxymoron. If it ever comes to exist, the world will suddenly disappear in a poof of code inspection reviews. ;-> ). ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/06/91)
Pardon me if this is a duplicate. I have news errors and I *think* I cancelled the bad one. In article <1991Mar3.051242.5879@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >wht (Warren Tucker) writes: >> UNIX C and shell scripts, VMS C and shell scripts, Perl >> scripts, awk scripts, MSDOS C, assembler and Pascal, X11... >Posix excludes little of what you mention; it's a broad umbrella, or >soon will be. Talk to me when it survives the test of time (i.e., its proponents have finished meeting, proposing, coffee drinking, and ArkB-ing and have actually implemented something). In the early 80's, some swore we'd all be smalltalk hackers by now. That umbrella is still rather leaky. >Will comp.sources.reviewed publish programs that don't conform to Posix >but could easily be made to? I hope not -- it'd mean the reviewers >weren't doing their job. POSIX is certainly not part of the agenda of most of my work, nor is it likely to be for a long time. If we write a program that can be POSIX-compatible, we should. But I won't use tcsendbreak() instead of ioctl(fd,{TCSBRK,TIOCSBRK},0) when most of real cyberspace (dev sys, headers, libraries) hasn't heard of the Newspeak yet. Now, if somebody wants to claim a source is POSIX compliant: Hi Ho. But to say reviewers must or should enforce POSIX is no more sensible than requiring compliance with the Chicago Manual of Style. Both of these specifications are good ideas -- in their places. No, too much useful stuff would be excluded. I did read your phrase 'easily be made to' and agree. But the response I made was to a proposal to name the new group 'comp.sources.posix' in lieu of 'comp.sources.reviewed'. Ever read _Life on the Mississippi_? Compare 'POSIX' with 'association men'. They will eventually rule simply because they stick together, but the River we swim (innovate) in will become more like molasses. (However, I assert that POSIX Perl will remain forever an oxymoron. If it ever comes to exist, the world will suddenly disappear in a poof of code inspection reviews. ;-> ). ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
sef@kithrup.COM (Sean Eric Fagan) (03/06/91)
In article <1991Mar5.172845.14713@tridom.uucp> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >Pardon me if this is a duplicate. I have news errors and I *think* >I cancelled the bad one. I have now seen it 6 times. It wasn't really worth reading the first time. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
kgallagh@digi.lonestar.org (Kevin Gallagher) (03/07/91)
In article <1991Mar06.084340.7662@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Mar5.172845.14713@tridom.uucp> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >>Pardon me if this is a duplicate. I have news errors and I *think* >>I cancelled the bad one. > >I have now seen it 6 times. It wasn't really worth reading the first time. I really don't see why you feel it necessary to insult people sometimes when you reply to a posting. A day or so ago, in another posting, you responded to to someone by saying, "You must be stupid." And this time you just had to throw in the comment: "It wasn't really worth reading the first time." You may think that such attacks strengthen your argument, but the very opposite is true. If you continue along this line, I am sure you will find that more and more people will ignore what you have to say by intentionally skipping all postings with your name attached. You will find fewer and fewer people responding to your contributions to the discussion, as if you didn't exist. If you desire to have others listen to your arguments and, perhaps, be persuaded by your point of view, they must be assured that you will treat their opinions with the same amount of respect you want others to give to yours. This means, no matter how absurd, no matter how silly, and no matter how stupid you feel their position or argument to be, you must not attack them personally nor berate the words they speak. Take my advice and back off. You will be a better person for it and, in time, you may gain the respect of others that you no doubt desire. -- ---------------------------------------------------------------------------- Kevin Gallagher kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh DSC Communications Corporation Addr: MS 152, 1000 Coit Rd, Plano, TX 75075 ----------------------------------------------------------------------------
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/09/91)
In article <1991Mar03.152123.17801@chinet.chi.il.us> laird@chinet.chi.il.us (Laird J. Heal) writes: >In article <1991Mar2.194702.18667@tridom.uucp> wht@n4hgf.Mt-Park.GA.US writes: >>Had c.s.reviewed been around, a ready mechanism would have been >>in place that perhaps would have eliminated *all* those patches. >Addressing only POSIX-compliant software is very good, but why not restate >the newsgroup as specifically for software going through a beta or gamma >test phase? That is, put it out so people can bang on it, apply patches, >and then post the final result to groups which get archived. I think you've got something there. Maybe what we need is a *mailing list* with a moderator (list manager) and a group of reviewers who work together to produce "better" versions of code that then get submitted to one of the established groups. ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me