t901590@mp.cs.niu.edu (T.J. McNamee ) (03/02/91)
I've seen a couple of replys to the splitup proposition saying they don't think its a good idea because of the porability across platforms of most minix postings...I agree, but that wasn't the intent of the original message, it suggested a split along info/sources lines. comp.os.minix and comp.sources.minix I am assuming. After digging through the archives at vm1.nodak.edu I tend to agree. I have looked at the comp.sources.unix archive and found exactly what I wanted quickly, but having to look through megabytes of info questions to get the one source file is a pain...having a newsgroup for JUST sources would make it easier to find the files people want.
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (03/02/91)
In article <1991Mar1.213647.13550@mp.cs.niu.edu> t901590@mp.cs.niu.edu (T.J. McNamee ) writes: >original message, it suggested a split along info/sources lines. >comp.os.minix and comp.sources.minix I am assuming. This is a very good idea, and also a very good name. I like comp.sources.minix for a name. Lets start the voting proceedure, and get this newsgroup going! -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
ast@cs.vu.nl (Andy Tanenbaum) (03/03/91)
In article <30737@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >This is a very good idea, and also a very good name. I like >comp.sources.minix for a name. Lets start the voting proceedure, I think that splitting along CPU lines is not a good idea. I am convinced that people with an X CPU will post general information to comp.os.minix.X just because all they ever think about is X. Thus everyone will have to read everything to avoid missing anything. No win. As to a sources group, it is a possibility, but I'd be surprised if there were many people who would read one but not the other. If there are such people, please post messages explaining why. The main advantage of splitting is to make the administration easier, i.e., the archive of the source group would have all the sources. On the other hand, the people running the archives could store the sources in the archives separately, even with one group. If we do split, I have a small preference for comp.os.minix.sources rather than comp.sources.minix, i.e., it is "our" group. I think the sources group should be unmoderated. There is no reason a priori to think that people will post discussions to the sources group. If someone does, I propose a way to make the point that this is a protocol violation: will all 44,000 readers send that person a polite message asking not to do it again. That will break his mail system and give him negative feedback from his postmaster. Before starting on a voting procedure, which should follow the normal net news rules, I think we should have a discussion here to see what we think. My own feeling is that with only 20-30 messages a day, a split is not really necessary, but if there is an overwhelming feeling for a separate sources group, ok. Andy Tanenbaum (ast@cs.vu.nl)
overby@plains.NoDak.edu (Glen Overby) (03/03/91)
In article <9146@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >The main advantage >of splitting is to make the administration easier, i.e., the archive of >the source group would have all the sources. On the other hand, the >people running the archives could store the sources in the archives >separately, even with one group. ... >I think the sources group should be unmoderated. That is the way it currently works, and it shows. There are few places to go to pick up past postings, and they all maintain things differently and inconsistantly. I can only see a moderated sources group improving things; an unmoderated sources group would not change my stance as a passive moderator (aka archive site maintainer) as I would still have to sift thru just as much data in the same way as I have been doing. Only a blind "everything that came across" archive could be easily set up with a separate group. I must also quickly point out the reality that people WILL continue to post sources, bug fixes, etc. to comp.os.minix. An archive that only archives .sources would miss all that. The one thing I can see a sources group helping is communications TO the Braindead IBM Territory NETwork (BITNET). Everything passing thru the news to mail gateway could be encapsulated in an armor 'uuencode' (or 'atob') shield for it's journey thru RSCS. In short, I don't see a sources group improving much. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet)
wfkonij@cs.vu.nl (Konijnenberg WF) (03/04/91)
In article <9146@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <30737@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >>This is a very good idea, and also a very good name. I like >>comp.sources.minix for a name. >I think that splitting along CPU lines is not a good idea. Agreed. There are already too many people unaware of the existence of any other type of computer than theirs. (cf. the vile heresy of "all the world's a VAX". :-) >As to a sources group, it is a possibility, but I'd be surprised if >there were many people who would read one but not the other. If there >are such people, please post messages explaining why. I would. Reason: I tend to skip all source that I see coming by. When I see it, I usually don't need it. When I need it, I can dig it up from an archive. A periodical overview of newly (and properly) arrived sources on the comp.os.minix group might be useful though. >... If we do split, I have a small >preference for comp.os.minix.sources rather than comp.sources.minix, >i.e., it is "our" group. Let's follow the general newsgroup structure and call it comp.sources.minix. >I think the sources group should be unmoderated. >Before starting on a voting procedure, which should follow the normal >net news rules, I think we should have a discussion here to see what >we think. -- -- Willy Konijnenberg <wfkonij@cs.vu.nl> Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
vickde@vicstoy.UUCP (Vick De Giorgio) (03/04/91)
In article <9146@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >Before starting on a voting procedure, which should follow the normal >net news rules, I think we should have a discussion here to see what >we think. My own feeling is that with only 20-30 messages a day, a >split is not really necessary, but if there is an overwhelming feeling >for a separate sources group, ok. > I'm in favor of the split discussion/sources. While I agree with you that most will take both (I certainly will), it will make finding the sources in my archives much easier. As it is, I have to pull them out manually or dig through pages of indexed Subject: lines to find a source. =V= -- Vick De Giorgio - vickde@vicstoy.UUCP -- I'd fly 10,000 miles to smoke a camel. UUCP - uunet!tarpit!bilver!vicstoy!vickde - The Philosopher's Stone Unix BBS, Orlando FL - (407) 299-3661 1200/2400 24 hours 8N1
klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) (03/06/91)
(About a splitup to comp.os.minix & comp.os.minix.sources)
This proposed splitup leaves me with a question:
Where should fixes and patches go?
Both alternatives are appealing. The advantage of posting fixes to the
sources group is that by archiving the sources group one can come up to
the most recent version. The advantage of the posting fixes to the non-sources
group is that the usual combination of a bug report + fix is seen by
everybody.
And what to do with the the big bug reports with tiny fixes?
Or, otherwise, with updates from the author to a program?
And a remark to Andy:
Yes, i will enjoy a splitup as proposed. This means i can at last make an
entry in my kill file which deletes non-interesting PC, Mac and Amiga
questions in the non-source group (Provided that bug reports and fixes
go to the source group).
(Speaking for many on usenet (rather than comp.os.minix by mail) i am not
worried about my incoming bandwidth. I am rather worried about the
possibility to shift incoming news quickly).
Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamerast@cs.vu.nl (Andy Tanenbaum) (03/07/91)
In article <klamer.668248951@mi.eltn.utwente.nl> klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) writes: >(About a splitup to comp.os.minix & comp.os.minix.sources) > >This proposed splitup leaves me with a question: > >Where should fixes and patches go? I would assume that anything containing code would go to the sources group. Even if it is a large explanation and 1 line of cdiff. A disadvantage of calling the group comp.sources.minix is that probably the vast majority of the postings will be discussion + a cdiff. People who currently read comp.sources.unix will subscribe to comp.sources.minix and begin flaming everybody for not posting whole files. This will require endless explanations. Calling it comp.minix.sources will make clear that this is not a regular source group, but a subset of the MINIX discussion. Andy Tanenbaum (ast@cs.vu.nl)
mitchell@MDI.COM (Bill Mitchell) (03/07/91)
In article <klamer.668248951@mi.eltn.utwente.nl> klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) writes: >(About a splitup to comp.os.minix & comp.os.minix.sources) > >This proposed splitup leaves me with a question: > >Where should fixes and patches go? > >........... > >And what to do with the the big bug reports with tiny fixes? >Or, otherwise, with updates from the author to a program? and patches submitted by others than the original author? and patches which are incompatable with previous patches? still, I think that confusion is less confusing than the current confusion. Should make finding and obtaining sources and patches from archives easier than at present. Not that I've ever had much success with the archives. I'm still trying to get a copy of origami part 5. -- mitchell@mdi.com (Bill Mitchell)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/07/91)
The discussion of splitting up the group bores me... I remember that this discussion comes up once a year.... I suspect that the number of people that will NOT subscribe to both lists will be rather small --- thus there will be little effect. Since I am connected via a BITNET relay, it will be necessary that both subgroups have a list server. C.v.W.
Paul.Northover@dundee.ncr.com (03/08/91)
In an article Andy Tanenbaum <ast%CS.VU.NL@vm1.nodak.EDU> writes: >In article <klamer.668248951@mi.eltn.utwente.nl> klamer@mi.eltn.utwente.nl > (Klamer Schutte -- Universiteit Twente) writes: >>(About a splitup to comp.os.minix & comp.os.minix.sources) >> >>This proposed splitup leaves me with a question: >> >>Where should fixes and patches go? >I would assume that anything containing code would go to the sources >group. Even if it is a large explanation and 1 line of cdiff. Agreed, that way automatic archivers would pick it up. However a message would also have to be sent to the discussion group as well so that those not subscribing to the sources group would know about the posting. Chances are that this would be done by posting the entire article to both groups, which would mean 2 copies of it for those of us that subscribed to both groups via the e-mail relay :-( It could be worse, the author could send the posting less the 1 line cdiff to the discussion group, then every site would get 2 copies. :-{ Paul Northover <Paul.Northover@Dundee.NCR.COM> NCR Self Service Systems Dundee Scotland
HIGGINS@ge-dab.ge.com (Sean C. Higgins 8*259-2073) (03/08/91)
>From: Christoph van Wuellen <mcnc!VM1.NoDak.EDU!HBO043%DJUKFA11.BITNET%CUNYVM.CUNY.EDU> > >The discussion of splitting up the group bores me... >I remember that this discussion comes up once a year.... > >I suspect that the number of people that will NOT subscribe to both lists >will be rather small --- thus there will be little effect. > >Since I am connected via a BITNET relay, it will be necessary that >both subgroups have a list server. > >C.v.W. I agree! Let's move on... Sean
leisner.wbst139@xerox.com (03/08/91)
Duplicate some information. Post anything over several line to comp.os.minix.sources with a readme. Post a readme with clarifying text (if it makes sense to comp.os.minix). That way, informed readers can find out what's happening in comp.os.minix.sources without having to read each posting (kinda like cross-posting). marty (Knowledge is useful in the Information Age) (Software is mindstuff. It is the hardest activity created by man) ARPA: leisner.wbst139@xerox.com NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
ast@cs.vu.nl (Andy Tanenbaum) (03/08/91)
In article <46876@nigel.ee.udel.edu> Paul.Northover@dundee.ncr.com writes: >Agreed, that way automatic archivers would pick it up. However a message would >also have to be sent to the discussion group as well so that those not >subscribing to the sources group would know about the posting. No. I would presume that there would NOT be an announcement in the discussion group. That would INCREASE the number of messages for people who read both groups, which I suspect will be a large fraction of the total. If the net result of the split is to make life more complicated for most people, I think it is a bad idea. Andy Tanenbaum (ast@cs.vu.nl)
peter@ficc.ferranti.com (Peter da Silva) (03/13/91)
In article <9222@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > I would assume that anything containing code would go to the sources > group. Even if it is a large explanation and 1 line of cdiff. This is perfectly acceptable. Patches are a substantial fraction of the traffic in existing sources groups. > Calling it comp.minix.sources will make clear that this is not a regular > source group, but a subset of the MINIX discussion. I assume you mean comp.os.minix.sources. That sounds like a good idea, if the idea of a moderator is abhorrent. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (03/13/91)
OK, I've offered to run a vote. Several people have sent me mail supporting this. Any dissenters? First order of business is the name of the group. Two have been proposed, comp.sources.minix and comp.[os?].minix.sources. There are good points for both of them: comp.sources.minix: Pro: It's the traditional name for a sources group. It will help keep people who don't want sources from blowing out their sys files. It will help people running automatic archivers. Con: It will probably be necessary to moderate it to get it passed. comp.os.minix.sources: Pro: It is more likely to pass without a moderator. Con: It's going to force people to complicate their sys files to avoid it. It's not traditional. This might hurt its chances. The next point is... does it want to be a moderated group? A moderator does put some delays in the process, but it also cleans up the flow in the group and may help get some organization in the chaos of contradictory patches that are seen in comp.os.minix. A really good moderator would even be able to merge some of the patches or determine that they're not actually fixing the problem at hand... just covering it up. The ideal moderator would be Andy Tannenbaum, but I suspect he's a bit busy. :-> So, if I'm acceptable as a vote-taker (I'll probably run the vote from home) I'll post a CFD in a few days. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
ast@cs.vu.nl (Andy Tanenbaum) (03/14/91)
In article <5M.9Z65@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >OK, I've offered to run a vote. Several people have sent me mail supporting >this. Any dissenters? I'm happy to have you run the vote. I definitely don't like the idea of a moderated group. I'm not even sure I'd contribute to it. Anarchy has worked pretty well so far. If we align with the formal structure of USENET, other people may insist that comp.sources.minix contains full programs, not just 2-line cdiffs and the like, since that is the way the other groups work. For copyright reasons that is not always acceptable, depending on the source of the material. In short, comp.sources.minix is quite different than comp.sources.xyz for all xyz. For this reason I don't think it belongs there in the hierarchy. Personally, I don't think a split is necessary, but if everyone else does, I could live with an unmoderated comp.os.minix.sources or maybe comp.os.minix.code or comp.os.minix.patches just to emphasize that the group is not intended for the exclusive posting of public domain sources. I would prefer to keep comp.os.minix, but if for technical reasons groups with the syntactic structure a.b.c.d and a.b.c are not allowed, then comp.os.minix could become comp.os.minix.d or comp.os.minix.disc. I think any voting proposal should at least have several possibilities. My own preferences from best (1) to worse (5) are: 1. Keep it as it is now Best 2. comp.os.minix and comp.os.minix.code (unmoderated) | 3. comp.os.minix and comp.sources.minix (unmoderated) | 4. comp.os.minix and comp.os.minix.code (moderated) V 5. comp.os.minix and comp.sources.minix (moderated) Worst Andy Tanenbaum (ast@cs.vu.nl)
jpc@fct.unl.pt (Jose Pina Coelho) (03/15/91)
In article <9302@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > > [...] > > Anarchy has worked pretty well so far. Amen. :-) > [...] > > I could live with an unmoderated comp.os.minix.sources or maybe > comp.os.minix.code or comp.os.minix.patches just to emphasize that the group > is not intended for the exclusive posting of public domain sources. Better be code because sources would atract lot's of flak, and patches is only part of the traffic. > I would prefer to keep comp.os.minix, but if for technical reasons groups > with the syntactic structure a.b.c.d and a.b.c are not allowed, then > comp.os.minix could become comp.os.minix.d or comp.os.minix.disc. It's allowed, look at comp.binaries.ibm.pc & comp.binaries.ibm.pc.d > I think any voting proposal should at least have several possibilities. > My own preferences from best (1) to worse (5) are: > > [...] > > 2. comp.os.minix and comp.os.minix.code (unmoderated) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It's the only way to fly ! -- Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fct.unl.pt Rua Jau N 1, 2 Dto | UUCP: ...!mcsun!unl!jpc 1300 Lisboa, PORTUGAL | Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/17/91)
Just to add my 5p worth (that's inflation for you) - I'm quite happy with things as they are. Surely the amount of traffic isn't really causing anyone real problems ? Leave it as it is, please. Andy Michael -- Andy Michael "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton - `House of Cards' Middlesex email: eesrajm@brunel.ac.uk UB7 9PA or Andrew.Michael@brunel.ac.uk
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/17/91)
In article <2042@Terra.cc.brunel.ac.uk>, eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: > > > Just to add my 5p worth (that's inflation for you) - > > I'm quite happy with things as they are. Surely the amount of traffic isn't > really causing anyone real problems ? > > Leave it as it is, please. > > > Andy Michael > Whoops - really a few too many reals there, I really think ..... More seriously, though ... It seems that the idea to split the group into CPU types has died a death, thankfully. On the grounds of compatability this is a good thing, IMHO. We already have people re-inventing the wheel because the PC people don't know that the ST people have already done it, and vice versa. (Two examples of this are format and virtual screens, in case anyone is wondering). I'd like to see MINIX reach the same state as most Unixes where the underlying hardware is pretty well irrelevant. MINIX 1.5 was a good move in this direction - let's keep it that way and not move apart again, please. This leaves the question of splitting the newsgroup on source and non-source lines. As I see it, the proposal to split the group is because some people don't like seeing all the "Where can I buy MINIX" articles. I agree that they can be a pain sometimes, but what happens if all the 'serious' MINIX people only look at the sources group ? Will all the enquirers just be ignored ? I'm sorry, but I don't see that the traffic is anywhere high enough to justify a split at present. Andy Michael -- Andy Michael "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton - `House of Cards' Middlesex email: eesrajm@brunel.ac.uk UB7 9PA or Andrew.Michael@brunel.ac.uk
peter@ficc.ferranti.com (Peter da Silva) (03/19/91)
If Andy won't post to a moderated group, that pretty much shoots that whole idea down. :-< In article <9302@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > I could live with an unmoderated comp.os.minix.sources or maybe > comp.os.minix.code or comp.os.minix.patches just to emphasize that the group > is not intended for the exclusive posting of public domain sources. I don't see any difference between ".code" and ".sources", but if the name is important then I can go either way. In fact, I'll happily put whatever anyone wants in the CFD, including arguments against it. It is, after all, a Call for Discussion. Now that you've brought the idea up, how do people feel about a ".sources" and a ".patches" group, both? > I would prefer to keep comp.os.minix, but if for technical reasons groups > with the syntactic structure a.b.c.d and a.b.c are not allowed, then > comp.os.minix could become comp.os.minix.d or comp.os.minix.disc. This is not in general a problem, though there are people who have strong feelings in favor of a separate .misc group there's no rule or real technical problem with doing things this way. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
ast@cs.vu.nl (Andy Tanenbaum) (03/20/91)
In article <3+2AN33@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I don't see any difference between ".code" and ".sources", but if the name >is important then I can go either way. The argument against comp.sources.minix is simply that lots of people who know nothing about MINIX will read it expecting complete C programs. When they see an endless stream of cdiffs, they will go into flame mode. Calling it comp.os.minix.code clearly indicates that it is not analogous to comp.*.sources.* In fact, I'll happily put whatever >anyone wants in the CFD, including arguments against it. It is, after all, >a Call for Discussion. >Now that you've brought the idea up, how do people feel about a ".sources" >and a ".patches" group, both? No. There's so little point in having a bunch of tiny groups. >> I would prefer to keep comp.os.minix, but if for technical reasons groups >> with the syntactic structure a.b.c.d and a.b.c are not allowed, then >> comp.os.minix could become comp.os.minix.d or comp.os.minix.disc. > >This is not in general a problem, though there are people who have strong >feelings in favor of a separate .misc group there's no rule or real technical >problem with doing things this way. The disadvantage of .misc is that it suggests that the odds and ends go there that didn't fit in elsewhere, as in comp.os.misc. It is my expectation that "comp.os.minix.misc" would be the main group. Andy Tanenbaum (ast@cs.vu.nl)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (03/20/91)
In article <3+2AN33@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >If Andy won't post to a moderated group, that pretty much shoots that >whole idea down. :-< How about a moderated group for official new releases of Minix? And officially approved bug fixes? >Now that you've brought the idea up, how do people feel about a ".sources" >and a ".patches" group, both? I would like to see a group .patches, for officially sanctioned upgrades and bug fixes. This group should be moderated. If not moderated, great pressure must be put on all of us not to post until we get approval from official sources (the testing group?) to do so. The .sources group would be for anything. This includes non-approved bug fixes, and whole programs (like sc, c68, c386, etc.), and everything in between. I think it would be good to have a moderated group for officially sanctioned stuff, and it is obviously necessary to have a non-moderated group for the masses to dump into. For me, it is sometimes hard to determine just what is officially approved, and what isn't. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
wjb@cogsci.cog.jhu.edu (03/20/91)
Andrew Micheal wrote: >Whoops - really a few too many reals there, I really think ..... >More seriously, though ... > > [Discussion of not splitting by CPU types] I agree. >This leaves the question of splitting the newsgroup on source and non-source >lines. As I see it, the proposal to split the group is because some people >don't like seeing all the "Where can I buy MINIX" articles. I agree >that they can be a pain sometimes, but what happens if all the 'serious' MINIX >people only look at the sources group ? Will all the enquirers just be >ignored ? Any 'serious" MINIX person is going to "read" (skim?) both groups anyway. The "discussion" group for discussion of problems/solutions/ideas, etc. and the "code" group for large (or small) contributions to the MINIX environment. I will admit there is going to be an overlap between the two. i.e. Where do you post a two line change to a file which solves somebody's problem? I would send it to both. If we are talking about newsgroups here, a crossposting to more then one group doesn't affect the amount of traffic at all. If we are talking about more then one mailing list, there might be some additional traffic, but not much. If it seems appropriate and the people who currently manage the mailing list are willing to do so, the list could be "cloned" and people would be given the opportunity to subscribe to one or both of them. Or the single merged mailing list could continue with two submission addresses. This would allow people who get access via e-mail to still specify which of the two newsgroups is more appropriate for their message. Many people would probably? only read the "discussion" group and depend on archive sites when they need sources. That brings up the big advantage that I see. It would make it MUCH easier for archivers to automatically save "code" postings. Many people can't afford the space or time to store every piece of code that comes down the chute. Or just weren't around when it was posted. (Re: request for "fastkey" recently.) Automatic archiving of such "code" and generation of indices could be done. Contributers could be encouraged to include "Description:" lines in their "code" postings in order provide the necessary information. If no "Description:" line was provided the "Subject:" line might do as a rough substitute. I think comp.os.minix.code would be an appropriate name and it should be unmoderated. Bill Bogstad P.S. Some people might say I talk about Minix alot, but don't get much done. They are probably right.
peter@ficc.ferranti.com (Peter da Silva) (03/21/91)
In article <9369@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > The argument against comp.sources.minix is simply that lots of people who > know nothing about MINIX will read it expecting complete C programs. When > they see an endless stream of cdiffs, they will go into flame mode. Calling > it comp.os.minix.code clearly indicates that it is not analogous to > comp.*.sources.* Makes sense, I guess. Past experience with alt.source-code and other innovatively named groups tends to make me a bit skeptical of new adventures in group naming. In any case, I'll include that in the CFD. > The disadvantage of .misc is that it suggests that the odds and ends go > there that didn't fit in elsewhere, as in comp.os.misc. It is my > expectation that "comp.os.minix.misc" would be the main group. Like comp.sys.amiga.misc? I don't see any reason to move comp.os.minix itself around... but I'll include this in the CFD. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
"Cornelius Caesar" <cae@sdfvm1.vnet.ibm.com> (03/21/91)
It might also be interesting to discuss the creation of something like comp.os.minix.binaries. Possibly some people would like to get (or post :-) ) them, and there wouldn't be an appropriate place to do so if the sources were separated from the main group. Cornelius
ast@cs.vu.nl (Andy Tanenbaum) (03/21/91)
In article <31178@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >I think it would be good to have a moderated group for officially >sanctioned stuff, and it is obviously necessary to have a non-moderated >group for the masses to dump into. For me, it is sometimes hard to >determine just what is officially approved, and what isn't. Who would do the official approving? Certainly not me. The stuff that I take and use appears in the periodic new releases, like the 1.6.15 one I just sent to the beta list. I don't want to set up a continuous process of reviewing everything that comes in and approving/rejecting on the fly. There is a MINIX referees mailing list that might do such approving, but it hasn't worked terribly well (i.e, nobody ever sends anything to it). Hence I don't think an official newsgroup is a good idea. You can see what I post by looking at the header to see the origin. Andy Tanenbaum (ast@cs.vu.nl)
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (03/22/91)
ast@cs.vu.nl (Andy Tanenbaum) wrote: > In article <5M.9Z65@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>OK, I've offered to run a vote. Several people have sent me mail supporting >>this. Any dissenters? > > I'm happy to have you run the vote. I definitely don't like the idea of Ditto. > Personally, I don't think a split is necessary, but if everyone else does, Humm... I agree with this. > 1. Keep it as it is now Best One vote here. > 2. comp.os.minix and comp.os.minix.code (unmoderated) | If (1) fails, one vote. Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (03/22/91)
eesrajm@cc.brunel.ac.uk (Andrew J Michael) wrote: > It seems that the idea to split the group into CPU types has died a > death, thankfully. On the grounds of compatability this is a good Yes, :-) > thing, IMHO. We already have people re-inventing the wheel because > the PC people don't know that the ST people have already done it, and > vice versa. (Two examples of this are format and virtual screens, in > case anyone is wondering). I'd like to see MINIX reach the same state > as most Unixes where the underlying hardware is pretty well irrelevant. > MINIX 1.5 was a good move in this direction - let's keep it that way and > not move apart again, please. That's what we call the Unification Project here; we are doing this with Advanced MINIX right now. The next Advanced MINIX will be unified completely. > This leaves the question of splitting the newsgroup on source and non-source > lines. As I see it, the proposal to split the group is because some people > don't like seeing all the "Where can I buy MINIX" articles. I agree > that they can be a pain sometimes, but what happens if all the 'serious' MINIX > people only look at the sources group ? Will all the enquirers just be > ignored ? > > I'm sorry, but I don't see that the traffic is anywhere high enough to justify a > split at present. I am in complete agreement, despite my previous message. I am an archiver myself, so it sometimes is a bother to find the sources between the lines of junk discussions. However, this news group is not _that_ heavy anymore (in terms of traffic), so it does not really cause me any problems.. Also, and that is more important to me, I want to keep up with ALL develop- ments in the MINIX field. A splitup would definitely cause many wheels to be re-invented, as Andy said above. Ergo: (1) A _system_ based splitup is unwanted. (2) A _sources_ based splitup is (yet) unneeded. However, it is a free world (not quite, but we're working on it :-), so IF there is going to be any splitup at all, I vote for a sources-and- patches based one, with a name of comp.os.minix.code or ~software. Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands > > > Andy Michael > > > > -- > Andy Michael "You might think that. I > 85 Hawthorne Crescent couldn't possibly comment." > West Drayton - `House of Cards' > Middlesex email: eesrajm@brunel.ac.uk > UB7 9PA or Andrew.Michael@brunel.ac.uk > >
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (03/22/91)
peter@ficc.ferranti.com (Peter da Silva) wrote: > If Andy won't post to a moderated group, that pretty much shoots that > whole idea down. :-< Right. His Master's Voice, eh? > I don't see any difference between ".code" and ".sources", but if the name > is important then I can go either way. In fact, I'll happily put whatever > anyone wants in the CFD, including arguments against it. It is, after all, > a Call for Discussion. This has to do with "foo.sys.sources", and the "foo.sys.sources.d" convention, I believe. But what keeps us from using "comp.os.minix.software"? Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands
ast@cs.vu.nl (Andy Tanenbaum) (03/22/91)
In article <9103220852.AA04339@grape.ecs.clarkson.edu> cae@sdfvm1.vnet.ibm.com (Cornelius Caesar) writes: >It might also be interesting to discuss the creation of something like >comp.os.minix.binaries. I think that is a bad idea. The spirit of MINIX says one should distribute sources. Only under rare circumstances (legal or technical, e.g. program too big for asld) should binaries be posted. This does not require a new group. I don't understand the desire to have so many little groups. I suppose people like that like to have 50 windows on their screen, one for every possible activity (e.g., one for reading each newsgroup, one for sending domestic mail to men, one for sending domestic mail to women, one for sending foreign mail to men, one for sending foreign mail to women, one for editing large texts without mathematics, one for editing small texts without mathematics, one for editing large texts with mathematics, one for editing small texts with mathematics, one for running programs that are known to work, one for running new programs that are being debugged, one for troff, one for an analog clock, one for a digital clock, etc. Andy Tanenbaum (ast@cs.vu.nl)
bert@arrakis.nl.mugnet.org (Bert Laverman) (03/22/91)
Kenneth J. Hendrickson wrote: > Peter da Silva wrote: >>If Andy won't post to a moderated group, that pretty much shoots that >>whole idea down. :-< > > How about a moderated group for official new releases of Minix? > And officially approved bug fixes? Yikes! Why would you want that??? Official releases are recognized by their senders, and the Subject line giving a new Minix version number. Besides, official releases don't occur that often. Beta-prereleases however.... ;-) >>Now that you've brought the idea up, how do people feel about a ".sources" >>and a ".patches" group, both? > > I would like to see a group .patches, for officially sanctioned upgrades > and bug fixes. This group should be moderated. If not moderated, great > pressure must be put on all of us not to post until we get approval from > official sources (the testing group?) to do so. Again, here you're creating a group with very sparse traffic. What's the use of moderating a group that should only be used by the original writers of programs? Again the real "officially sancioned" upgrades are easily recognized by subject line and sender. > The .sources group would be for anything. This includes non-approved > bug fixes, and whole programs (like sc, c68, c386, etc.), and everything > in between. Hey, you want official patches in an moderated group, but the programs those patches are for in an unmoderated group???? > I think it would be good to have a moderated group for officially > sanctioned stuff, and it is obviously necessary to have a non-moderated > group for the masses to dump into. For me, it is sometimes hard to > determine just what is officially approved, and what isn't. EVERYTHING THAT'S OFFICIALLY SANCIONED, IS THEREFORE ALREADY MODERATED! Simple: Official patches are announced as "Patchlevel #" or "Patch nr. #", and always by the original poster of the program, or else by someone who mentions in the posting that he doing so _for_ the original poster. I suppose we can trust each other not to pretend, eh? And when in doubt, find the sender of the original posting, and _ask_him/her_! As for my own opinion, I don't think a splitup is absolutely necessary... yet. It _would_ make it easyer, however, to separate "save-worthy" postings from "read-only" postings. It's sometimes a bit annoying to have to pick up the pieces of a source posting from between discussions on the differences between 386sx and 386dx processors, or even about "where to get the best buy on minix"! (That was a really dumb one if you ask me. Just post one message breathing the words "public domain" and "minix" in the same paragraph, and you'll get gobs of replies ranging from "no it isn't" to "hey, is it pd? where?") So, count this one as in favor of an _unmoderated_ group with both code, and patches. I suppose man pages would be ok also, but what about "Ten easy steps to xxxx happyness"? ;-) Greetings, Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org Molukkenstraat 148 work: laverman@cs.rug.nl 9715 NZ Groningen The Netherlands tel.: +31 50 - 733587 From "How to catch a lion in the desert": The Dirac method: We assert that wild lions can ipso facto not be observed in the Sahara desert. Therefore, _if_ there are any lions at all in the desert, they are tame. We leave catching a tame lion as an exercise to the reader. =====================================================================
paul@ukpoit.co.uk (Paul Wood) (03/22/91)
In article <31178@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >How about a moderated group for official new releases of Minix? >And officially approved bug fixes? In the past I have been caught out by multitudes of fixes, and not knowing which ones are "official" and which ones are "unofficial". Fixes which have been fully beta-tested need some kind of flag to indicate this fact. Fixes which are untested also need to be flagged. Perhaps separate groups is the answer, unless there is an alternative. Should there be separate groups for standard and advanced Minix? The opportunities for confusion in this area will be extremely high. A releated issue is: Perhaps there is a need for a "Road Map" document, like Unix International have for System V. I know that there is work going on for Posix-ification of Minix. TCP/IP is also being done. In the short term there is UUCP, mail, news, advanced Minix, etc, etc. A good indication of the need for a "Road Map" is that I don't know everything that is going on in Minix. Who does? Is it secret? Does everyone agree what the "Road Map" is or will be? paul@ukpoit.co.uk Paul Wood, 31 Buttermere Drive, Dronfield Woodhouse, ----------- Sheffield, England, S18 5PX. ----------- -- Paul Wood [ e-mail: paul@ukpoit.co.uk or ...!ukc!ukpoit!paul ] [ address: iT, Barker Lane, Chesterfield, England S40 1DY ] [ phone: +44 246 214256, postline: 5403 4256, fax: +44 246 214353 ]
peter@ficc.ferranti.com (Peter da Silva) (03/23/91)
OK, the CFD has been sent to the news.announce.newgroups moderator. I have deliberately not put any dates on it as yet, because I suspect it will be a slightly controversial proposal. A second CFD with dates will come out in a week or so if things seem settled enough to predict dates. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
archer@frmug.fr.mugnet.org (Vincent Archer) (03/24/91)
In a comp.os.minix article, kjh@pollux.usc.edu ("Kenneth J. Hendrickson") writes: > I think it would be good to have a moderated group for officially > sanctioned stuff, and it is obviously necessary to have a non-moderated > group for the masses to dump into. For me, it is sometimes hard to > determine just what is officially approved, and what isn't. It now seems to be pretty well accepted that there's going to be a split into a "discussion" group (the old comp.os.minix), and a "source" group. The idea sounds reasonable for administrative purposes (having a separate source group is fine, when it comes to archives). Having a separate group for upgrades and official (i.e. fixes or new software that is going to actually appear in P-H released Minix) sounds like a good idea too. Of course, I agree with kjh that such a group would have to be moderated by the official Minix authors (i.e. andy, frans and all the others) to prevent anarchy. Such a group would have no traffic at all for months, then get a whole burst of postings (no doubt the much awaited 1.6 "transition" version :-) and a small residual activity (1.6.356, 357, and so on :-) but would make life easier for all of us. But, whatever the decision is, don't forget the mailing-list world of Minix fans. I, for example, still get The Newsgroup using a complex path (thru bitnet, internet, X25 and modems, with four or five different different versions of news-style software) for communication costs purposes. The List is still an important part of the minix life, and don't rush to add one (or two) newsgroups on the Usenet without having consulted with Glen Overby about the setup of the new list. Btw, please note that I'm no longer reachable thru my old mail address, but using the new address below: -- Vincent Archer Internet: archer@frmug.fr.mugnet.org Bang: uunet!minixug!frmug!archer
webber@csd.uwo.ca (Robert E. Webber) (03/25/91)
In article <9410@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
....
.I don't understand the desire to have so many little groups.
Actually it is fairly simple. Most people find less than 10% of the
messages posted to the group actually worth reading. Thus, if we
split comp.os.minix into:
comp.os.minix.interesting
and
comp.os.minix.uninteresting
then we would be done with the Great Name Debates and could settle
down to the more advanced debate over which messages were posted to
the wrong group.
Of the groups actually proposed, comp.os.minix.binaries is the only
one that really shows promise. Of all the programs that came with
MacMinix, the ones that came as binary-only have been the most trouble
(specifically elle which seems to loose track of the keymap in weird
and wonderful ways and cc/ld which seems to from time to time not be
able to open files that all other programs have no trouble with). So,
as long as people don't post compressed source archives, uuencoded
binary data files, etc., to the binaries group, I could actually see
being able to safely unsubscribe from that group and thus reduce the
total number of message I read per year by 10 or so.
The notion of a sources group seems to have run into the problem that
people who want sources also want patches (by author and/or by others)
and any significant discussion about installation, bugs, ports, etc.,
which starts to sound like the comp.os.minix.interesting again. Over
the past couple of weeks, the most interesting sources related posting
I have seen was the comment that by modifying a couple of include files
and doing a one-shot pass over the file system, minix could be made to
work with longer than 14 character file names. This comment did not show
which files needed to be change, what the change actually was, and was
in defense of the usefulness of sources rather than any discussion about
file name lengths in minix. It would clearly never have appeared in
any comp.os.minix.sources group under any reasonable notion of what
a sources posting is and yet it was an interesting and important comment
about the minix sources (independent of its significance in the discussion
of the merits of having sources). As Euclid used to tell Ptolemy, there
is no royal road to minix - you got to read everything.
--- BOB (webber@csd.uwo.ca)klamer@mi.eltn.utwente.nl (Klamer Schutte) (03/25/91)
In <9103211932@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >ast@cs.vu.nl (Andy Tanenbaum) wrote: >> In article <5M.9Z65@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>>OK, I've offered to run a vote. Several people have sent me mail supporting >>>this. Any dissenters? >> >> I'm happy to have you run the vote. I definitely don't like the idea of >Ditto. >> Personally, I don't think a split is necessary, but if everyone else does, >Humm... I agree with this. >> 1. Keep it as it is now Best >One vote here. >> 2. comp.os.minix and comp.os.minix.code (unmoderated) | >If (1) fails, one vote. I agree. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
peter@ficc.ferranti.com (Peter da Silva) (03/25/91)
In article <9103212058@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: > peter@ficc.ferranti.com (Peter da Silva) wrote: > > If Andy won't post to a moderated group, that pretty much shoots that > > whole idea down. :-< > Right. His Master's Voice, eh? No, recognising that Andy's stuff, consisting as it does of updates from one rev of Minix to the next, is probably the single most important source posting that comes through in here. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
nall@cs.utk.edu (John Nall) (03/26/91)
In article <5Y8ATR8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <9103212058@uwalt.nl.mugnet.org> waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >> peter@ficc.ferranti.com (Peter da Silva) wrote: >> > If Andy won't post to a moderated group, that pretty much shoots that >> > whole idea down. :-< >> Right. His Master's Voice, eh? > >No, recognising that Andy's stuff, consisting as it does of updates from >one rev of Minix to the next, is probably the single most important source >posting that comes through in here. >-- Exactly. In all this furor over whether or not to have one or two or umpteen-zillion groups, the central issue of Minix development seems to have gotten lost. There are really only two people (perhaps groups, I don't know) who seem to be doing true Minix development AND SHARING IT WITH OTHERS. Andy is one, and Bruce Evans is the other. I for one do not want this to stop. My definition of "true Minix development" by the way, is the O/S itself - the kernel, MM and FS. There are a lot of other very good people doing a lot of very good stuff in other areas, of course. So if Andy does not want to play, I see the potential for Minix not going further than it already has. Which is not near so far as it needs to go. If it stops now, and the only updates we ever get are what comes out through P-H, Minix will become an interesting piece of history. John Nall
peter@ficc.ferranti.com (Peter da Silva) (03/26/91)
Two points: (1) The comp.os.minix splitup RFD is a Request for Discussion. Not a vote. Please don't send me votes until I call for them, which will likely be in 3-4 weeks. (2) I will include any discussion in comp.os.minix in what I include in my CFV, and echo any significant points to comp.os.minix, but if you can it would probably be worthwhile to subscribe to news.groups. You know my bias and while I think I can be impartial I'd feel better having someone on the other side monitoring things in there. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
ralf@ptavv.ka.sub.org (Ralf Wenk) (03/27/91)
I does not see why a splitup is necessary. The current load is low and even in the good old days of upgrading to 1.5.?? there were no problems by having patches and "normal" articles in one group. The splitup will possibly make life easier for some archive administrators but more complicated for the most of us because we have to read both groups to be up to date. -- -- Ralf Wenk -- ralf@ptavv.ka.sub.org
wjb@cogsci.cog.jhu.edu (03/29/91)
Ralf Wenk wrote: >I does not see why a splitup is necessary. The current load is low >and even in the good old days of upgrading to 1.5.?? there were no >problems by having patches and "normal" articles in one group. Well, it would have been easier for me to deal with it. Automatically saving source postings for later perusal while being able to quickly see and respond to requests for information... (Actually, back then I didn't know enough about Minix to respond, now I just think that I do. :-) >The splitup will possibly make life easier for some archive administrators I think so as well and have said so in the past. Still it hasn't been completely clear to me that the archive administrators agree with me. If they really don't think it will make a difference, maybe we shouldn't bother. I think it would help me, but I'm more concerned about making it easier for true archive administrators. (I just save stuff for my own use.) >but more complicated for the most of us because we have to read >both groups to be up to date. [sarcasm on] Huh? You have to read a WHOLE 'nuther group. This generally requires hitting "y" or maybe the return key when your news reading program presents you with the name of the "other" group. You might also have to edit your .newsrc file once in order to put the two group names next to each other so you are sure to read both of them at the same time. This is obviously more complicated then typical users of Minix are capable of managing. [sarcasm off] And nothing else to say. Bill Bogstad
al@escom.com (Al Donaldson) (03/29/91)
Bill Bogstad brackets the following in [sarcasm]: > Huh? You have to read a WHOLE 'nuther group. This generally > requires hitting "y" or maybe the return key when your news reading program > presents you with the name of the "other" group. You might also have to > edit your .newsrc file once in order to put the two group names next to each > other so you are sure to read both of them at the same time. This is > obviously more complicated then typical users of Minix are capable of > managing. My main objection to a split, any split, is that it requires posters to make a decision: which group do I post to? The answer is often "both." And, all too often, instead of cross-posting, the user separately posts the message, once to group A and a second time to group B. Two distinct messages with the same content. The result is (a) that the net carries the message twice to all sites and (b) we have to read the message twice. Someone has to pay for (a), and each of us pays for (b). If anyone [in the US??] wants an example, check out the misc.forsale, misc.forsale.computers, and misc.wanted kludge. Sometimes I see the same message *three* times over there. Maybe we can handle this -- maybe we're a lot smarter than those folks over there.. :-) It's not a problem with the additional group. I'll edit my .newsrc so I can read both of them together, as I suspect everyone else will. The problem is that I have to read through probably a time and a half the traffic to get the same content. Al
ast@cs.vu.nl (Andy Tanenbaum) (03/31/91)
In article <1991Mar29.143439.2027@escom.com> al@escom.com (Al Donaldson) writes: >And, all too often, instead of cross-posting, the user separately posts >the message, once to group A and a second time to group B. Two distinct >messages with the same content. The result is (a) that the net carries >the message twice to all sites and (b) we have to read the message twice. It's a lot worse than that. Sometimes when you actually crosspost, the message hits some node that is running old software and the crosspost is exploded into separate messages. Once this happens, they don't get put back together again (ask Humpty Dumpty). Andy Tanenbaum (ast@cs.vu.nl)
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/02/91)
Al Donaldson writes: > >>[I (Bill Bogstad) get sarcastic about the difficulty in dealing with two >>minix newsgroups.] > >My main objection to a split, any split, is that it requires posters >to make a decision: which group do I post to? The answer is often "both." >And, all too often, instead of cross-posting, the user separately posts >the message, once to group A and a second time to group B. Two distinct >messages with the same content. The result is (a) that the net carries >the message twice to all sites and (b) we have to read the message twice. >Someone has to pay for (a), and each of us pays for (b). > >If anyone [in the US??] wants an example, check out the misc.forsale, >misc.forsale.computers, and misc.wanted kludge. Sometimes I see the >same message *three* times over there. Maybe we can handle this -- >maybe we're a lot smarter than those folks over there.. :-) > >It's not a problem with the additional group. I'll edit my .newsrc >so I can read both of them together, as I suspect everyone else will. >The problem is that I have to read through probably a time and a half >the traffic to get the same content. Sorry about the tone of my last message. With your explanation, I now understand your fears. I assume you are concerned about people who post seperate messages to each group. (Most recent news software can avoid showing you the same message twice if it is crossposted.) Your example of misc.forsale.* is certainly a situation that we would want to avoid. My personal problem with those groups is the number of people who post computers to misc.forsale instead of/or without a posting/crossposting to misc.forsale.computers. I don't think that other groups have the these problems to the same extent. The comp.unix.* groups seem to handle it o.k. (With the possible exception of people/questions which fit most appropriately in comp.unix.questions.) Education of readers and posters can help solve this problem. The misc.forsale groups are often used by people who are not familiar with them or news in general. They probably never read the groups themselves nor will they ever post there again. The readers and posters of the Minix newsgroups have a much larger stake in making it an efficient forum for communication. As a result, I think it can work. However, this does bring up a concern that I have mentioned in passing twice now. How will the two newsgroups interface with the currently single mailing list? Many people have no access to news and depend on the mailing list for both discussion and sources. The quick solution (leave things as they are) results in mailing list people never seeing many source codes. They also end up sending their source codes to the discussion newsgroup. Sending everything from both groups to the mailing list means they see everything. But again what about their mailings. Do they always go into the discussion group/source group/both (crossposted of course)? The way I see it any solution which only has one address to which mail can be sent doesn't even ALLOW people to correctly send their messages, let alone encouraging them to do so. Whether two seperate lists of recipients should be maintained or just two different submission addresses would depend on what the administator of the list wanted to do. Does anybody know who the current administrator of the mailing list at UDEL.EDU is? I guess I'll have to send a note to the request addresss... Bill Bogstad
snowboots@cix.compulink.co.uk (Andrew Bray) (04/03/91)
There seems to be a lot of discussion on this subject, and ast for
one seems to be totally against it. However, I would argue that there
is one overriding argument in favour of some kind of split up:
Assistance for archive sites. The way that comp.os.minix runs at the
moment must create a lot of work for maintainers of archive sites -
unless they have the disk space to store everything, and if they
store everything the users of the archive sites then have the job of
sorting out the chaff, often from only the subject line (unless they
fetch everything). As archive sites are effectively a service to us
all, any help we can give must surely be welcome.
So there should either be two groups, one for general chitchat and
cries for help, and one of material suitable for archiving, or we
should place an Archive-as line or some such in any posting we think
should be archived, and any non conformant message doesn't get
archived.
All this IMHO,
Andy.
snowboots@cix.compulink.co.ukbert@arrakis.nl.mugnet.org (Bert Laverman) (04/03/91)
Al Donaldson wrote: > My main objection to a split, any split, is that it requires posters > to make a decision: which group do I post to? The answer is often "both." I should hope not in this case. Besides, as already _many_ people pointed out, the object is clearly _not_ a splitup on subject, but rather a splitup on _contents_. Even more people already drew the obvious conclusion that everybody is going to read both groups anyway - I suppose mailing lists would simply merge the two back into one to save setting up two separate administrations - so there is no conceivable reason that I can think of for anyone to make a crossposting. One group will be probably-save-all, and the other read-first-decide-later. I thought the proposed names made this clear enough... > [ explanation about simpleminded reasoning for double posting deleted ] Again, this might have been the risk if we decided for a processor-based split, but luckily we avoided that trap. > If anyone [in the US??] wants an example, check out the misc.forsale, > misc.forsale.computers, and misc.wanted kludge. Sometimes I see the > same message *three* times over there. Maybe we can handle this -- > maybe we're a lot smarter than those folks over there.. :-) Or misc.misc. You don't need to be in the US to get that crap. :-) > It's not a problem with the additional group. I'll edit my .newsrc > so I can read both of them together, as I suspect everyone else will. Unless you have a VSNR (Very Simple News Reader) you'll probably be prompted for it anyway; Look Momma, no hands! ;-) > The problem is that I have to read through probably a time and a half > the traffic to get the same content. I doubt that. Greetings, Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org Molukkenstraat 148 work: laverman@cs.rug.nl 9715 NZ Groningen The Netherlands tel.: +31 50 - 733587 From "How to catch a lion in the desert": The Peano method: In the usual way construct a curve containing every point in the desert. It has been proven that such a curve can be traversed in arbitrarily short time. Now we traverse the curve, carrying a spear, in a time less than what it takes the lion to move a distance equal to it's own length. =====================================================================
nall@cs.utk.edu (John Nall) (04/05/91)
In article <1991Apr02.040413PM.8984@demon.co.uk> snowboots@cix.compulink.co.uk (Andrew Bray) writes: >There seems to be a lot of discussion on this subject, and ast for >one seems to be totally against it. However, I would argue that there >is one overriding argument in favour of some kind of split up: > >Assistance for archive sites. [ discussion material deleted] The trouble with this argument is that it is not being made by the people who maintain the archive sites. If they, as a group, say it needs to be done, and should be done, then I for one would be all for it. But it seems to me, if I recall correctly, that some of the best arguments against it have come FROM archive site guys! John Nall
jds@cs.umd.edu (James da Silva) (04/06/91)
nall@cs.utk.edu (John Nall) writes: >snowboots@cix.compulink.co.uk (Andrew Bray) writes: >>There seems to be a lot of discussion on this subject, and ast for >>one seems to be totally against it. However, I would argue that there >>is one overriding argument in favour of some kind of split up: >> >>Assistance for archive sites. > [ discussion material deleted] > > The trouble with this argument is that it is not being made by the > people who maintain the archive sites. If they, as a group, say > it needs to be done, and should be done, then I for one would be > all for it. But it seems to me, if I recall correctly, that some > of the best arguments against it have come FROM archive site guys! As an archive site maintainer (The Mars Hotel BBS archive @ 1-301-277-9408) and grizzled old Minix 1.1 veteran, I guess this is my cue to put in my two cents worth: I'm going to join the other old-timers who've already spoken out against a split. I'm voting NO. My main reason is that the split would NOT separate the wheat from the chaff. I find that some of the discussions are as useful as the code, so I archive good discussions along with code. Cruft WILL be posted to the code group, and pearls WILL appear in the discussion group. The split would actually make my job as archive maintainer slightly harder, since I will have to track both groups. A split is mainly of help to those who are not interested in investing the time that Minix still demands. I predict that we will see an increase in repeated questions from people who have pulled sources from the code group but didn't see the discussion that thrashed out how to get the code actually working. "Help! I don't normally read the discussion group, but ..." People who post to the code group are not going to get any more organized that they are now, so the need to follow everything that is going on will still be there. In particular, our fearless leader AST is not always obsessed with release management: "Well, that program worked on the version of Minix that existed on my hard disk on the day I posted it." :-) Then there is the Meta-Discussion-Flame-Factor. When inappropriate postings appear in the wrong group they will get flamed, and the flamers will get flamed, etc. We've all seen this before in other groups. I concede that this might not result in any more traffic than the current oft-recurring meta-discussion on splitting the group. It'll be even less pleasant, however. Even though I don't think a split is desirable, I would like to heartily thank Peter da Silva (no relation, BTW) for running the vote so as to settle the matter once and for all (which on Usenet means: for another few months :-). Of course, if the split happens, I WILL archive both groups. Cheers, Jaime ........................................................................... : domain: jds@cs.umd.edu James da Silva : path: uunet!mimsy!jds Systems Design & Analysis Group
overby@plains.NoDak.edu (Glen Overby) (04/06/91)
In article <32506@mimsy.umd.edu> jds@cs.umd.edu (James da Silva) writes: ^^ See this article again for a Few Good Reasons against a .code group >nall@cs.utk.edu (John Nall) writes: >>snowboots@cix.compulink.co.uk (Andrew Bray) writes: [1 good argument for a sources group] >>>Assistance for archive sites. As (Yet Another) archive site maintainer (plains.nodak.edu), the ONLY way I can see a sources group helping the archive maintainers is if it is moderated, in which case the moderator essentially runs the archive (about the only thing I'd do is uudecode postings so they'd suck up less disk space). That's the reason I volunteered as moderator: I do most of the moderation already (just on a somewhat less timely basis). Oh, yeah, there is one other possibility: everything could be encapulated in a nice suit of uuencode armor before it's shiped thru the IBM world. I don't expect that to happen, though (you loose again, Bitnet; you get to hear Bitnet people whine, Internet). I won't put out a campaign add telling everyone which way to go, because I haven't quite decided myself yet :-) As for archiving an unmoderated sources group, I've already got that one figured out: I start the filenames with 1 and go until I catch hell for sucking up all our disk space :-) (at which point I delete old stuff and keep on going). -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet)
jpc@fct.unl.pt (Jose Pina Coelho) (04/09/91)
In article <9449@plains.NoDak.edu> overby@plains.NoDak.edu (Glen Overby) writes: Oh, yeah, there is one other possibility: everything could be encapulated in a nice suit of uuencode armor before it's shiped thru the IBM world. I don't expect that to happen, though (you loose again, Bitnet; you get to hear Bitnet people whine, Internet). And don't forget to add an 'M' at the end of each line or the trailing spaces will be chewed. -- Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fct.unl.pt Rua Jau N 1, 2 Dto | UUCP: ...!mcsun!unl!jpc 1300 Lisboa, PORTUGAL | Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?
broman@schroeder.nosc.mil (Vincent Broman) (04/09/91)
As another archive maintainer, my comment is similar: splitting up the group would not make my job any easier, particularly because there is no mechanism for enforcing posting to the "right" group, also because I archive discussions as well as packages of code. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (04/10/91)
about adding a trailing 'M' to each lineof uuencoded data: a trailing 'M' is pure junk, a trailing 'running' letter gives a sequence check which helps you if there were some lines lost -- this may occur if several parts are put together. missing trailing blanks are no problem with the new MINIX uud program. C.v.W>
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/11/91)
Vincent Broman wrote: >As another archive maintainer, my comment is similar: >splitting up the group would not make my job any easier, >particularly because there is no mechanism for enforcing >posting to the "right" group, also because I archive >discussions as well as packages of code. Well, AST has said that he won't post to a moderated source code so you're right. There won't be any mechanism to force people to do the right thing. (other then peer pressure.) I am of the opinion that in the Minix community that will be a strong force, but only time would tell. As someone who has used the Minix archive sites in the past, just having that one extra bit of information ("code related") would have made it much easier to determine if some program was available and where to find it. Some of the sites archive sources in separate directories. This is usually done by the person who runs the archive site. In some (many?) cases, those files never even came through the mailing list. (I believe Bruce Evan's bcc compilers would be an example.) They usually don't have every piece of code that came through the mailing list because this would require the archive administrator to manually do the segregation. Other sites store every article from the mailing list. This means that messages about why you can't do something are mixed in with messages about how to do it and speculations about why somebody would want to do it. By having a "code" newsgroup, I hope in some sense to turn the latter type of archive site into the former type, WITH LITTLE OR NO ADDITIONAL WORK FOR THE ADMINISTRATOR OF THAT SITE. I'm basing this hope on the goodwill of the posters to correctly identify their postings and the willingness of the administrators of the current list archive sites to make the necessary changes to the way that they run their site. I can't prove that the former exists. All I can look at is the willingness of the Minix community in the past to help one another. As to the administrators, so far they seem to feel there is little benefit to segregating code or that it won't work. I don't understand the first reason. The only thing I can think of is that those administrators have never really had to USE their archives? They are already very familiar with Minix and what is available. The second is possible. It would result from either people being unwilling to post to the appropriate group or from new subscribers who are not yet aware of the difference. New subscribers are more likely to post to "comp.os.minix" then "comp.os.minix.sources" and their postings will usually belong in that group anyway. If there are posters out there who are going to deliberately make the newsgroup split not work, please step forward now so we can avoid all of this hassle. Bill Bogstad P.S. This could almost be accomplished by having everyone who posts code put a "CODE" keyword in the subject line of their messages. If it really looks like splitting the group/list is too much trouble can we at least try to do this? My problem with this is that there is no protection from a new subscriber who blindly replies/followsup to a "CODE" message and uses the same subject line. Sending to a separate group or mail address takes a little more thought/knowledge.
ast@cs.vu.nl (Andy Tanenbaum) (04/11/91)
In article <50356@nigel.ee.udel.edu@ wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes:
@
@P.S. This could almost be accomplished by having everyone who posts code
@put a "CODE" keyword in the subject line of their messages. If it really
@looks like splitting the group/list is too much trouble can we at least try
@to do this? My problem with this is that there is no protection from a new
@subscriber who blindly replies/followsup to a "CODE" message and uses the
@same subject line. Sending to a separate group or mail address takes a
@little more thought/knowledge.
That brings up another issue. If we have a comp.os.minix.code group
and people reply to it, the replies will go to the wrong group. Of
course if all posters consistently set the Followup-To field, that can
be avoided, but I doubt that will happen.
Andy Tanenbaum (ast@cs.vu.nl)peter@ficc.ferranti.com (Peter da Silva) (04/13/91)
Status of vote: start of vote still blocked on mailing-list questions. Alternate suggestion: crossposting all sources to alt.sources. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (04/13/91)
In article <9636@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > course if all posters consistently set the Followup-To field, that can > be avoided, but I doubt that will happen. Well, a certain amount of that can be handled simply by making the gateway put in the appropriate header line. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
anderson@dogie.macc.wisc.edu (Jess Anderson) (04/13/91)
In article <KDOAQHC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Status of vote: start of vote still blocked on mailing-list questions. >Alternate suggestion: crossposting all sources to alt.sources. Not so good, I think; alt* distribution is considerably less reliable in many places around the net. I'm basically not for the split in the first place, but I'd rather all things related to Minix continued to appear in the comp.os* hierarchy. -- Jess Anderson <> Madison Academic Computing Center <> University of Wisconsin Internet: anderson@macc.wisc.edu <-best, UUCP:{}!uwvax!macc.wisc.edu!anderson NeXTmail w/attachments: anderson@yak.macc.wisc.edu Bitnet: anderson@wiscmacc Room 3130 <> 1210 West Dayton Street / Madison WI 53706 <> Phone 608/262-5888
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/14/91)
Jess Anderson: >>Peter da Silva wrote: >>Alternate suggestion: crossposting all sources to alt.sources. > >Not so good, I think; alt* distribution is considerably less >reliable in many places around the net. I'm basically not for >the split in the first place, but I'd rather all things related >to Minix continued to appear in the comp.os* hierarchy. I have my own problems with this, but that isn't one of them. When an article is crossposted to two different groups, it will be sent to any machine which receives either one of the groups. The result is that a crossposted article to comp.os.minix and alt.sources will show up in both groups on a machine that has directories for both groups and in only comp.os.minix if it only has that directory. Many sites are set up with all of the group directories (even the ones that they don't receive) and in that case, the minix articles would be the only articles in alt.sources that people at those sites would ever see. Crossposting is implemented as multiple links to the same file and takes up essentially no more disk space then an article posted to one group. The result of this would be that MInix alt.sources postings would be "piggybacking" on the distribution of comp.os.minix. Bill Bogstad
bert@arrakis.nl.mugnet.org (Bert Laverman) (04/15/91)
peter@ficc.ferranti.com (Peter da Silva) wrote:
> Alternate suggestion: crossposting all sources to alt.sources.
NEVER!
My harddisk is of such meaningless size, and telephone rates vs
2400bps are so high, that I will never even consider getting
alt.sources!
Besides, this crossposting looks more like offering our sources to
others, than getting those sources split from text. I don't know if
regular alt.sources readers will appreciate the advantage of seeing
Minix software go past. Usually these are packages which do less than
the full-blown things they use on their BSD and System V machines...
Bert
=====================================================================
Bert Laverman email: bert@arrakis.nl.mugnet.org
Molukkenstraat 148 work: laverman@cs.rug.nl
9715 NZ Groningen
The Netherlands tel.: +31 50 - 733587
From "How to catch a lion in the desert":
The thermodynamics method:
We construct a semi-permeable membrane which lets everything
but Lions pass through. This we drag across the desert...
=====================================================================peter@ficc.ferranti.com (Peter da Silva) (04/16/91)
In article <1991Apr13.011133.1919@macc.wisc.edu> anderson@dogie.macc.wisc.edu (Jess Anderson) writes: > In article <KDOAQHC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >Status of vote: start of vote still blocked on mailing-list questions. > >Alternate suggestion: crossposting all sources to alt.sources. > Not so good, I think; alt* distribution is considerably less > reliable in many places around the net. True, but not relevent. They would still show up in comp.os.minix, but would also show up in alt.sources for general consumption and comment. Check out crossposting in the regular news.announce.newusers articles. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
lunnon@qut.edu.au (04/16/91)
In article <1991Mar29.143439.2027@escom.com>, al@escom.com (Al Donaldson) writes: > Bill Bogstad brackets the following in [sarcasm]: >> Huh? You have to read a WHOLE 'nuther group. This generally >> requires hitting "y" or maybe the return key when your news reading program >> presents you with the name of the "other" group. You might also have to >> edit your .newsrc file once in order to put the two group names next to each >> other so you are sure to read both of them at the same time. This is >> obviously more complicated then typical users of Minix are capable of >> managing. > > My main objection to a split, any split, is that it requires posters > to make a decision: which group do I post to? The answer is often "both." > And, all too often, instead of cross-posting, the user separately posts > the message, once to group A and a second time to group B. Two distinct > messages with the same content. The result is (a) that the net carries > the message twice to all sites and (b) we have to read the message twice. > Someone has to pay for (a), and each of us pays for (b). I think we are worrying too much, from what I understand cross-posting results in a few extra bytes tacked on to a message header, I don't think this level of extra traffic would cost too much, remove your subscription to alt.warm.fuzzies instead :-) < Stuff removed > > It's not a problem with the additional group. I'll edit my .newsrc > so I can read both of them together, as I suspect everyone else will. > The problem is that I have to read through probably a time and a half > the traffic to get the same content. > > Al I don't know about you but when I look at comp.sources.atari.st and comp.binaries... _I_ only read the message headers to determine which Items are of interest. The rest flow past and are captured by some archive or other. This way I have some inkling of what has flowed past and what has not with a clear impression that it was probably a source or fix and not someone (like me) complaining about the lack of multi-threading. What this means is that this split would save _ME_ time as I would not have to read the start of the message find out it was a source, think about whether I should archive it. Decide I will get it from an archive (maybe - if the archiver didn't miss it by accident in amongst the discussion on PDP-8 memory management) type 'next' ( We use VMS ) and wait for our overloaded vax to give me the next message. Personally then I can say from this _end users_ point of view this would save me a fair bit of reading and simplify the memory work required. In fact in the old days, I used to capture news in batches, download it at 2400 baud to my ST then read it and split it up, just the downloading took 2 hours each week (our VMS site has not heard about kermit with big packets :-) then it was a really nasty job to sort out the good bits (sources) and archive them. All this was needed because the VMS news program had a nasty bug to do with the extract command and that as a student _I__HAD_NO_ACCESS_TO_FTP_ (ouch) and even mailing off campus required extra privs. Thus there was no way to get patches and sources other than carve up this newsgroup and archive. In my estimation there are probably thousands in this boat, that would benefit from the fact that sources are lumped together and can be archived conveniently ( indicate your presence by sending a yes vote - oh you can't do that - ???? no external mail access ?? well ask your postmaster to send it to /dev/null for you so you don't feel too bad ) #undef sarcasm In defense of those not (quite) with us BOB R.Lunnon@qut.edu.au
peter@ficc.ferranti.com (Peter da Silva) (04/17/91)
In article <9104152746@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: > peter@ficc.ferranti.com (Peter da Silva) wrote: > > Alternate suggestion: crossposting all sources to alt.sources. > NEVER! (wot never? no never. not ever? well, hardly ever.) > My harddisk is of such meaningless size, and telephone rates vs > 2400bps are so high, that I will never even consider getting > alt.sources! You don't have to. > Besides, this crossposting looks more like offering our sources to > others, than getting those sources split from text. More it's marking those sources as something to archive. > I don't know if > regular alt.sources readers will appreciate the advantage of seeing > Minix software go past. Usually these are packages which do less than > the full-blown things they use on their BSD and System V machines... Some of us have less than BSD and System V machines available. The Minix stuff works just fine on Xenix-286 and PCs. The big-name packages are often far too big. If I didn't see this stuff as being useful beyond minix, I wouldn't have offered to help by running a vote on the split. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"