marke@richs118.cpg.trs.reuter.com (Mark Ellis) (04/18/91)
I've seen several discussions regarding uploading of Coherent source &/or uuencoded binaries here. Is the policy set (if so by whom) & if so, what is the policy regarding this? Personally, I would like to see Coherent specific stuff posted here rather than sorting through comp.os.minix group for it. I'm not trying to start a war, just wonder if the demarkation zone has been set already? Thanks, Mark Ellis Reuters Oak Brook, IL
rmk@rmkhome.UUCP (Rick Kelly) (04/21/91)
In article <1655@richsun.cpg.trs.reuter.com> richsun!marke writes: > >I've seen several discussions regarding uploading of Coherent source &/or >uuencoded binaries here. Is the policy set (if so by whom) & if so, what is >the policy regarding this? > >Personally, I would like to see Coherent specific stuff posted here rather >than sorting through comp.os.minix group for it. I'm not trying to start a >war, just wonder if the demarkation zone has been set already? My belief is that we need to set up a Coherent sources group and forget the arguments. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP
rt2@cunixb.cc.columbia.edu (Rens Troost) (04/22/91)
I've been watching the discussion flail along for a while, and I'm of the opinion that this hunger for a c.o.coh tree is a little premature. The bandwidth on this group is not what you would call large, and much of it has been devoted to the sources question. When I cast my vote for this group, I expected a c.o.minix - like group to emerge - the mixture of sources and discussion on the minix group has been great, and despite some periodic suggestions for subgroups, the structure has remained for a long while. Refer to your comp.os.minix archive for the details. I'll throw my two cents in- 1> sources are useful. 2> too many subgroups make archivers lives hard. 3> the bandwidth on this group is not high enough to choke any mailer. 4> you don't waste an inode on another directory :). IFF sources become a problem on this group, then decide to fork another group. But I'd sure be happy to see some sources come this way...especially if they're easily portable to MINIX. :) -Rens rt2@cunixb.cc.columbia.edu rens@gnu.ai.mit.edu
wjb@cogsci.cog.jhu.edu (04/23/91)
Rens Troost writes: >I've been watching the discussion flail along for a while, and I'm of the >opinion that this hunger for a c.o.coh tree is a little premature. >... >I'll throw my two cents in- >1> sources are useful. >2> too many subgroups make archivers lives hard. >3> the bandwidth on this group is not high enough to choke any mailer. >4> you don't waste an inode on another directory :). Now, for an alternative point of view. I think that having separate discussion and source groups makes it easier to archive the "important" stuff. It requires less work for archivers who actually care about the quality of their archives as opposed to the number of megabytes and makes it easier for users of the archives to actually find things. That is why I'm supporting the current proposal to split comp.os.minix. I suspect that Rens and I are on the opposite sides of that discussion in comp.os.minix as well. >IFF sources become a problem on this group, then decide to fork another >group. But I'd sure be happy to see some sources come this way...especially >if they're easily portable to MINIX. :) Do it the right way now. Don't wait till later and have to deal with the lethargy of the net and confusing your readers. Also, if your programs are portable to Minix and you have a separate source newsgroup, I'll only have to read that one. :-) Bill Bogstad
rad@railnet.nshore.ncoast.ORG (Rick DeMattia) (04/23/91)
rt2@cunixb.cc.columbia.edu (Rens Troost) writes: > > I'll throw my two cents in- > 1> sources are useful. > 2> too many subgroups make archivers lives hard. > 3> the bandwidth on this group is not high enough to choke any mailer. > 4> you don't waste an inode on another directory :). > Hear hear. Also, I think we should wait 6 months or so and see how the traffic in this newsgroup develops, before going through the procedure to request an additional group for sources. It's easy to get a new group when we need it. It is difficult to remove redundant groups effectively if they turn out to be unnecessary. -- UUCP: {uunet|backbone}!nshore!railnet!rad rad@railnet.nshore.ncoast.org CompuServe: 72517.666@compuserve.COM
marke@richs118.cpg.trs.reuter.com (Mark Ellis) (04/23/91)
I agree entirely with Rens (rt2@cunixb.cc.columbia.e). IFF sources become a problem here, THEN split into another group for just sources.
lark@greylock.tivoli.com (Lar Kaufman) (04/23/91)
I've taken the liberty of picking up this thread and cross-posting it to comp.os.minix and comp.os.xinu since it seems germane to these groups as well - especially as my comments are inserted. In article <22.Apr.91.174055.49@cogsci.cog.jhu.edu>, wjb@cogsci.cog.jhu.edu writes: Rens Troost writes: >I've been watching the discussion flail along for a while, and I'm of the >opinion that this hunger for a c.o.coh tree is a little premature. >... >I'll throw my two cents in- >1> sources are useful. >2> too many subgroups make archivers lives hard. >3> the bandwidth on this group is not high enough to choke any mailer. >4> you don't waste an inode on another directory :). I'll accept this view, but read on... Now, for an alternative point of view. I think that having separate discussion and source groups makes it easier to archive the "important" stuff. It requires less work for archivers who actually care about the quality of their archives as opposed to the number of megabytes and makes it easier for users of the archives to actually find things. That is why I'm supporting the current proposal to split comp.os.minix. I suspect that Rens and I are on the opposite sides of that discussion in comp.os.minix as well. This argument may well be applicable to comp.os.minix, but it doesn't hold up for comp.os.coherent. comp.os.coherent is too new to offer much in the way of choices between what is "important" stuff and what is not. Also, as Coherent is a solid implementation in itself, most additional offerings for it are either much wanted or small (trivial?) sources. >IFF sources become a problem on this group, then decide to fork another >group. But I'd sure be happy to see some sources come this way...especially >if they're easily portable to MINIX. :) Now we approach an interesting point: portability. Do it the right way now. Don't wait till later and have to deal with the lethargy of the net and confusing your readers. Also, if your programs are portable to Minix and you have a separate source newsgroup, I'll only have to read that one. :-) Bill Bogstad The lethargy of the net is a myth. Let's talk about YOUR lethargy. (You the reader, not Bill Bogstad in particular.) I did propose comp.os.coherent myself, after studying several Requests for Discussions and Calls for Votes and studying the guidelines for establishing newsgroups (reprinted frequently on news.groups). It was more work than expected, but only because the vote was much heavier than I expected - gratifyingly so, I might add. Which is to say, if you want it and think it is right, Go Ahead. Now, I am on record as preferring a common sources group for small unixoid OSes - especially Version 7-flavored OSes. This greatly enlarges the pool of developers of useful applications, and also provides a place for people who don't even have their own support group to post. For example, users of QNX, and people who are adding Unix flavored extensions to MS DOS. For those who don't want to paw through sources that might not be useful to them, one can simply list the OSes the source can be compiled for on the Subject line, as is done to provide separation of interests in some other groups where cross-pollination of ideas is wanted by most, but not all, readers. Since I've just done the newgroup formation process, I'm not ready to re-enter the fray just now. On the other hand, I'll lend whatever advice and help I can to someone who would carry this proposal forward. Failing that, I encourage anyone who has Good Stuff for Coherent to go ahead and put the sources in comp.os.coherent (assuming it is already tested for Coherent). This is in the tradition of Usenet. New groups are generally formed on the basis of either need or compelling interest. Neither of those have yet been demonstrated for comp.os.coherent.sources or comp.unix.sources.coherent or whatever you would call it. -lar Lar Kaufman I would feel more optimistic about a bright future (voice) 512-794-9070 for man if he spent less time proving that he can (fax) 512-794-0623 outwit Nature and more time tasting her sweetness lark@tivoli.com and respecting her seniority. - E.B. White
wjb@cogsci.cog.jhu.edu (04/24/91)
In article <694@tivoli.UUCP> lark@tivoli.com (Lar Kaufman) writes: > [included stuff from my and others previous posts about a seperate > source group] > [Lar's suggestion that a v7ish source group be created] With Minix starting to move towards POSIX, I'm not sure that a combined group would work out, but I wouldn't be against it. >Failing that, I encourage anyone who has Good Stuff for Coherent to go ahead >and put the sources in comp.os.coherent (assuming it is already tested for >Coherent). This is in the tradition of Usenet. New groups are generally >formed on the basis of either need or compelling interest. Neither of those >have yet been demonstrated for comp.os.coherent.sources or >comp.unix.sources.coherent or whatever you would call it. First an admission. I have never seen Coherent and probably never will. I'm interested in a system for which I can obtain full source code. I do read comp.os.coherent and did so when the digest was being sent to comp.os.misc. I voted for comp.os.coherent since I thought it was a good idea. I never said that sources shouldn't be posted to comp.os.coherent or to comp.os.minix for that matter. I said that I thought that a seperate sources group would be helpful. As to compelling interest, that is usually determined by discussion and a vote. That seems to be what is taking place right now. Certainly some traffic has already started and I others are asking permission to continue. If no one else is in favor then the discussion will die. Bill Bogstad P.S. I will not respond publically on this further nor vote on the matter. As a non-user of Coherent, I don't think my wishes should matter. I also rarely vote on rec.* and soc.* newsgroups.
wjb@cogsci.cog.jhu.edu (04/24/91)
In article <694@tivoli.UUCP> lark@tivoli.com (Lar Kaufman) writes: > [actually reposts something I said in comp.os.coherent] > > ... I think that having separate > discussion and source groups makes it easier to archive the "important" > stuff. It requires less work for archivers who actually care about the > quality of their archives as opposed to the number of megabytes and makes > it easier for users of the archives to actually find things. ... The above was not a comment about a specific archiver of Coherent/ Minix/Unix/or any other systems software or discussions. I access many archives via ftp on a regular basis and they are all appreciated. If any maintainer of an archive site was offended by the statements above, please accept this public apology. I'll slow down in the future and pay more attention to what I'm typing... Bill Bogstad wjb@cogsci.cog.jhu.edu
cavrak@kira.UUCP (Steve Cavrak) (04/24/91)
In article <1655@richsun.cpg.trs.reuter.com> richsun!marke writes:
I've seen several discussions regarding uploading of Coherent
source &/or uuencoded binaries here. Is the policy set (if so
by whom) & if so, what is the policy regarding this?
From article <9104201711.45@rmkhome.UUCP>, by rmk@rmkhome.UUCP (Rick Kelly):
My belief is that we need to set up a Coherent sources group
and forget the arguments.
The usual rule for creating a "new" group is for the "need" to arise
because a new thread of postings overwhelms the old charter of the
group. In which case, I would argue, post away and when there are
enough postings to make life confusing here, spin off a different
group -- maybe comp.os.coherent.sources and comp.os.coherent.binaries.
(Right, there is nothing sacred about the old hierarchies either.)
Steve