pete@octopus.UUCP (Pete Holzmann) (04/25/88)
In previous articles, ray@micomvax.UUCP (Ray Dunn), swan.ulowell.edu and creps@silver (Steve Creps) write: >>> >>> [various arguments about comp.sys.ibm.pc.this-is-getting-ridiculous!] >>> This is the beginning of a DISCUSSION. This is NOT a call for votes. Please do NOT vote on this! Let's discuss it, hopefully in news.groups. See you there! This is the BEGINNING of a discussion. The more I work this over, the more I realize how hard it is to cover all the angles when dealing with generalities. I look forward to seeing improvements on my thoughts. If what I say here gets completely thrown out by the time we've come up with a solution, all the better: the solution won't be blamed on me then! :-) Getting straight to the point: We need to fix the comp namespace so that the most-discussed operating environments are handled in an organized way. Let's make comp.binaries.msdos PC/MS-DOS executable programs comp.sources.msdos PC/MS-DOS-specific source code comp.msdos.apps Discussions of PC/MS-DOS programs comp.msdos.hlevprog Discussions of High Level programming on PC/MS-DOS. Language compilers, windowing environments, multitaskers, etc. comp.msdos.llevprog Discussions of Low Level programming on PC/MS-DOS. Interrupts, BIOS calls, writing device drivers, etc. comp.os2.misc Discussions about OS/2 apps & programming. comp.sys.ibm.ps2 Discussions about IBM PS/2 computers (and compatibles). And keep comp.sys.ibm.pc Discussions about hardware on PC's and compatibles. The Unix side of things could probably use similar cleaning up: comp.unix.apps Discussions of Unix programs: grep, compress, shells of all flavors, dd, fsck, etc. comp.unix.hlevprog Discussions of High Level programming on Unix. Library routines, termcap, awk, perl, etc. [C questions go elsewhere] comp.unix.llevprog Discussions of Low Level programming on Unix. Kernel hacks, Device drivers, etc. If the Mac folks can handle it, they might want: comp.sys.mac Discussions about mac hardware (kept) comp.mac Discussions about the mac environment comp.mac.hypercard Discussions about hypercard programming comp.mac.programmer Discussions about mac programming The amiga and maybe atari groups also need similar organization. I'm not the one to suggest specifics here. What gets deleted? comp.binaries.ibm.pc comp.sources.ibm.pc comp.unix.questions comp.unix.wizards WHY bother? What is broken? 1) The question/ans traffic in the sys.ibm.pc and unix.quest/wiz groups is rather unmanageable. We need a way to split up the discussions along lines that make it reasonably easy to: o avoid tremendous cross-posting o allow readers to scan for topics at their level of use and experience o keep similar topics together 2) 'unix' refers to an O/S. 'mac' ostensibly refers to a machine that could run lots of different kinds of software, but basically it runs what we might call 'mac' software for want of a better term :-). 'ibm.pc' supposedly is mostly hardware-related too... We need SOFTWARE-oriented groups that deal with the operating environments most-discussed on the net today. Clearly, unix, msdos, the mac environment, and the amiga environment are the most-discussed. The atari discussion is 1/2 the size of the amiga discussion, yet is still pretty big. (Numbers of articles in our active file; relates to discussion volume since the Great Renaming): comp.sys.atari.st 2926 comp.sys.mac 5680 (+ 1064 in mac.xx) comp.sys.amiga 6420 (+ 621 in ...tech) max(comp.unix.questions,comp.unix.wizards) 8415 sum(...unix.questions,unix.wizards) 15880 comp.sys.ibm.pc 17322 [In responding, please stay with the topic. I want to get the whole thing organized; I don't care if my numbers here are right, or even within 50% of right.] It is clear that the comp.xxx architecture relegates specific hardware manufacturers to lower levels of the heirarchy; software topics go near the top. Well... msdos, amiga, mac and even atari are rather important operating environments to people on the net now. They may be more or less hardware dependant, but I don't see that that matters. 3) (A nit, but I think it is important anyway) o The 'ibm.pc' groups rarely refer to the *IBM* pc. That world has grown far beyond IBM's own systems. My identifier for that world is 'msdos'. Choose your own better one if you like. Don't get other folks mad by choosing 'dos'. o 'sys.ibm.pc' is three directory levels deep. 'msdos' is one. On at least SOME systems, that's a reasonable amount of extra overhead. 'sys.mac' => 'mac' and 'sys.amiga' => 'amiga' will also save some overhead. WHAT IS GOOD ABOUT THE NAMES I'VE CHOSEN? Well, it seems to me that the names we've chosen in the past when splitting up 'unix' just haven't provided the desired separation. Anytime you make one group for beginners and another for wizards/ techies/gurus... well, everybody naturally wants to get advice from the experts. This is not what we want or need! Thus, I've split up the appropriate groups into: xxx.apps xxx.hlevprog xxx.llevprog 'high level' and 'low level' do NOT refer to languages. They refer to 'level' within the operating environment. Clearly, there is still potential for cross-posting. I can't think of *any* set of names that will completely eliminate this. But the separations I've described are reasonably clear, and work better to eliminate the problem than anything else I can think of. As far as the MAC groups go, my guess is that 'mac.programmer' can probably be left as-is. I don't know a lot about mac programming; (so now I'll stick foot-in-mouth :-) and say...) perhaps they don't need such a separation at this point. What do y'all think? Let the flame games commence! -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746