chuq@apple.com (Chuq Von Rospach) (02/20/90)
This is an official call for discussions on reorganizing the
comp.sys.mac hierarchy. After much preliminary discussion about ways to
deal with the overloading of comp.sys.mac, we've decided that we need
to do something more than just create a new group, but instead try to
reorganize the structure in a more radical way that won't require
further tuning in two or three months.
NOTE: The proposal, as written, does not fully conform to current
guidelines for newsgroup creation. This was done after great thought
because it was felt that what needed to be done to c.s.m simply
couldn't be done successfully by staying within the guidelines in a
timely manner. Gene Spafford, Greg Woods and I all feel the variations
are appropriate for the situation, but I also feel that this exceptions
should also have the general approval of the net, so I'm calling for a
survey on whether the proposal is acceptable.
PLEASE READ THE ENTIRE CALL FOR DISCUSSION AND THE PRELIMINARY
PROPOSAL. If you feel the proposed voting scheme for the reorganization
is appropriate or inappropriate, send mail to 'chuq@apple.com' with
either a 'yes' or a 'no' to the proposal structure. If the majority of
people responding to this survey vote 'yes' then the official call for
votes will have the structure proposed here. If the majority of
responses are negative, the proposal will be structured to match
current guidelines as a series of call for votes, although that is
expected to stretch the implementation time significantly. Either way,
if you have an opinion about the acceptability of the proposal, please
send it to me for inclusion in the survey. The results of the survey
will be binding on the form of the final proposal and call for votes.
This proposal is written as a series of suggested group changes or
creations. They are being sent out as a single proposal, but each group will
be voted on separately. This will allow the user community to choose which
sections of the proposal they want implemented, rather than forcing an all
or nothing situation.
Additionally, I am proposing that, during the Call For Discussion phase we
are now entering, a secondary survey for additional changes be held. If
there is a group or change that you feel should be made to comp.sys.mac that
isn't in this preliminary proposal, you can e-mail that suggestion to me. If
I get 100 requests for a group, I will add it to the voting of the final
proposal. If I get fewer than 100 requests, I'll post it in a list when the
voting is finished as groups proposed for future additions, but they will
not be part of the official vote. (in other words, if there is a group you
want added to the final vote, you should send me e-mail requesting it AND
discuss it in news.groups to convince others to do so as well.).
If the survey on the guidelines variations fails, this proposal will be
restructures as a series of independent votes on one issue of the
proposal at a time. The effective change is that it will take a lot
longer to implement and require everyone to send in multiple votes, one
for each issue, rather than a single piece of e-mail with votes
covering all issues -- a lot more work over a longer time to get the
same thing done.
One final note: I'm specifically ignoring comp.sources.mac and
comp.binaries.mac in these proposals and focusing only on
comp.sys.mac. There have been some discussions of splitting or
reorganizing c.b.m recently, but (1) I think it would be premature to
place any changes to a vote at this time, and (2) I think fixing c.s.m
is complex enough issue to deal with as it is without adding in the
complexities of the other hierarchies. I also believe that changes to
moderated groups should be organized by the moderator, so I leave these
hierarchies to someone else to work with.
Please send your survey comments about the structure of this proposal
(positive or negative) and requests for additional groups in this
proposal to me at "chuq@apple.com". Because of the complexity of this
proposal and some personal scheduling requirements I'm running a
somewhat extended discussion period: discussion of this proposal and
vote counting for the surveys will run until March 17, 1990 with the
call for votes being issued the week of March 19. Please route all
discussion to news.groups and keep it out of c.s.m -- it's noisy enough
as it is (which is the whole point of the proposal).
Now, to the reorganization proposals themselves. Remember, in the call for
votes each proposal will be voted upon separately, and depending on the
results of the survey there might be additional groups to be voted upon:
Proposal 1: rename comp.sys.mac to comp.sys.mac.misc. This will be in
multiple stages: the creation of comp.sys.mac.misc, followed a few
weeks later by the rmgroup of comp.sys.mac and the addition of a usenet
alias to the new group to forward misdirected messages. This will bring
c.s.m into the same standardized naming as other hierarchies, and it
should also discourage some of the cross-posting between c.s.m and
sub-groups that happens when people think they should put it in the
parent group just in case.
Proposal 2: Creation of comp.sys.mac.os. This will be for discussion of
Macintosh system software -- the system, finder, multifinder, CDEVs, INITs
and other Apple and third party Operating System software and its
extensions.
Proposal 3: Creation of comp.sys.mac.appl. This will be for discussion of
Macintosh applications. The naming of this group has created a fair amount
of discussion, ranging between app and applications. I've chosen appl for a
couple of reasons: (1) for people with a knowledge of Macintosh this term
won't be ambiguous, since it is the signature byte of applications (it
should also be obvious enough in context to not be ambiguous to complete
novices); and (2) I see this as the root of a sub-hierarchy, and the thought
of typing comp.sys.mac.applications.wordprocessing is painful and I think it
would be unacceptable to many users -- the shorter name will encourage
future expansions rather than discourage them.
Proposal 4: renaming comp.sys.mac.hypercard to comp.sys.mac.appl.hypercard.
To standardize naming in the new scheme. Technically, since Apple computer
considers Hypercard system software it should be c.s.m.os.hypercard, but I
don't believe most users agree with that thinking.
Proposal 5: creation of comp.sys.mac.wanted. A place for the "I'm missing
part five of..." or "I need a program that does..." or "Where can I get a
good price on..." messages. There was some discussion of creating a sister
group c.s.m.forsale, but for sale messages really should be encouraged to go
into a regional group and not a net-wide group.
Welcome to comp.sys.mac document: In parallel with this proposal, Geoff
Allen <pmafire!geoff@uunet.UU.NET> is writing an "introduction to the
comp.sys.mac hierarchy document. This document will be posted on a regular
basis (and updated when needed) and will document the different groups in
the hierarchy and what type of messages should be posted where. It or a
sister posting will also include answers to common questions. This posting
should also help reduce cross-posting, confusion and the constant
re-introduction of certain topics.
Rejected proposals: This is a short list of proposals considered that I've
rejected and why:
o c.s.m.fonts: discussion should be in comp.fonts
o c.s.m.desktop: desktop publishing discussion should be in comp.text.desktop
o c.s.m.d (or c.s.m.futures): I wasn't convinced it was a viable long-term
discussion. With the proper splitting of the other topics, it should
fit appropriately in c.s.m.misc. talk.politics.apple was also
considered.
o c.s.m.viruses: discussion should be in comp.virus
o c.s.m.reviews: there isn't enough traffic to justify, and it would
have to be moderated to prevent lots of noise.
o c.s.m.{db,comm,spreadsheet,wordprocessing,et al}: these should be
considered as sub-groups of the c.s.m.appl hierarchy and we should
wait and see how traffic in that area works out before considering
splitting it further.
That's it. Five proposals, two renamed groups and three creations (two of
which should be considered roots for sub-hierarchies that can be created as
needed). Again, please respond to the survey about the format of this
proposal, and if you have groups you feel ought to be added to the
proposal. All discussion should take place in news.groups, not in the c.s.m
group.
thanks to: Cory Kempf, D. K. Smith, Dan Veditz, Dave Smith, Gail
Zacharias, Geoff Allen, John Macdonald, John R. Delaney, Larry E.
Kollar, Mark M Mehl, Piper Keairnes, Randy Futor, capmkt!bandy,
fleming@cup.portal.com, sklein@cdp.UUCP, among others, for their feedback,
suggestions and advice on building this proposal.
chuq
--
Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking]
Rumour has it that Larry Wall, author of RN, is a finalist in the race for
the Nobel Peace Prize for his invention of the kill file.chuq@apple.com (Chuq Von Rospach) (02/20/90)
[This is a repost of an earlier article do to a problem on apple.com.
-eliot]
This is an official call for discussions on reorganizing the
comp.sys.mac hierarchy. After much preliminary discussion about ways to
deal with the overloading of comp.sys.mac, we've decided that we need
to do something more than just create a new group, but instead try to
reorganize the structure in a more radical way that won't require
further tuning in two or three months.
NOTE: The proposal, as written, does not fully conform to current
guidelines for newsgroup creation. This was done after great thought
because it was felt that what needed to be done to c.s.m simply
couldn't be done successfully by staying within the guidelines in a
timely manner. Gene Spafford, Greg Woods and I all feel the variations
are appropriate for the situation, but I also feel that this exceptions
should also have the general approval of the net, so I'm calling for a
survey on whether the proposal is acceptable.
PLEASE READ THE ENTIRE CALL FOR DISCUSSION AND THE PRELIMINARY
PROPOSAL. If you feel the proposed voting scheme for the reorganization
is appropriate or inappropriate, send mail to 'chuq@apple.com' with
either a 'yes' or a 'no' to the proposal structure. If the majority of
people responding to this survey vote 'yes' then the official call for
votes will have the structure proposed here. If the majority of
responses are negative, the proposal will be structured to match
current guidelines as a series of call for votes, although that is
expected to stretch the implementation time significantly. Either way,
if you have an opinion about the acceptability of the proposal, please
send it to me for inclusion in the survey. The results of the survey
will be binding on the form of the final proposal and call for votes.
This proposal is written as a series of suggested group changes or
creations. They are being sent out as a single proposal, but each group will
be voted on separately. This will allow the user community to choose which
sections of the proposal they want implemented, rather than forcing an all
or nothing situation.
Additionally, I am proposing that, during the Call For Discussion phase we
are now entering, a secondary survey for additional changes be held. If
there is a group or change that you feel should be made to comp.sys.mac that
isn't in this preliminary proposal, you can e-mail that suggestion to me. If
I get 100 requests for a group, I will add it to the voting of the final
proposal. If I get fewer than 100 requests, I'll post it in a list when the
voting is finished as groups proposed for future additions, but they will
not be part of the official vote. (in other words, if there is a group you
want added to the final vote, you should send me e-mail requesting it AND
discuss it in news.groups to convince others to do so as well.).
If the survey on the guidelines variations fails, this proposal will be
restructures as a series of independent votes on one issue of the
proposal at a time. The effective change is that it will take a lot
longer to implement and require everyone to send in multiple votes, one
for each issue, rather than a single piece of e-mail with votes
covering all issues -- a lot more work over a longer time to get the
same thing done.
One final note: I'm specifically ignoring comp.sources.mac and
comp.binaries.mac in these proposals and focusing only on
comp.sys.mac. There have been some discussions of splitting or
reorganizating c.b.m recently, but (1) I think it would be premature to
place any changes to a vote at this time, and (2) I think fixing c.s.m
is complex enough issue to deal with as it is without adding in the
complexities of the other hierarchies. I also believe that changes to
moderated groups should be organized by the moderator, so I leave these
hierarchies to someone else to work with.
Please send your survey comments about the structure of this proposal
(positive or negative) and requests for additional groups in this
proposal to me at "chuq@apple.com". Because of the complexity of this
proposal and some personal scheduling requirements I'm running a
somewhat extended discussion period: discussion of this proposal and
vote counting for the surveys will run until March 17, 1990 with the
call for votes being issued the week of March 19. Please route all
discussion to news.groups and keep it out of c.s.m -- it's noisy enough
as it is (which is the whole point of the proposal).
Now, to the reorganization proposals themselves. Remember, in the call for
votes each proposal will be voted upon separately, and depending on the
results of the survey there might be additional groups to be voted upon:
Proposal 1: rename comp.sys.mac to comp.sys.mac.misc. This will be in
multiple stages: the creation of comp.sys.mac.misc, followed a few
weeks later by the rmgroup of comp.sys.mac and the addition of a usenet
alias to the new group to forward misdirected messages. This will bring
c.s.m into the same standardized naming as other hierarchies, and it
should also discourage some of the cross-posting between c.s.m and
sub-groups that happens when people think they should put it in the
parent group just in case.
Proposal 2: Creation of comp.sys.mac.os. This will be for discussion of
Macintosh system software -- the system, finder, multifinder, CDEVs, INITs
and other Apple and third party Operating System software and its
extensions.
Proposal 3: Creation of comp.sys.mac.appl. This will be for discussion of
Macintosh applications. The naming of this group has created a fair amount
of discussion, ranging between app and applications. I've chosen appl for a
couple of reasons: (1) for people with a knowledge of Macintosh this term
won't be ambiguous, since it is the signature byte of applications (it
should also be obvious enough in context to not be ambiguous to complete
novices); and (2) I see this as the root of a sub-hierarchy, and the thought
of typing comp.sys.mac.applications.wordprocessing is painful and I think it
would be unacceptable to many users -- the shorter name will encourage
future expansions rather than discourage them.
Proposal 4: renaming comp.sys.mac.hypercard to comp.sys.mac.appl.hypercard.
To standardize naming in the new scheme. Technically, since Apple computer
considers Hypercard system software it should be c.s.m.os.hypercard, but I
don't believe most users agree with that thinking.
Proposal 5: creation of comp.sys.mac.wanted. A place for the "I'm missing
part five of..." or "I need a program that does..." or "Where can I get a
good price on..." messages. There was some discussion of creating a sister
group c.s.m.forsale, but for sale messages really should be encouraged to go
into a regional group and not a net-wide group.
Welcome to comp.sys.mac document: In parallel with this proposal, Geoff
Allen <pmafire!geoff@uunet.UU.NET> is writing an "introduction to the
comp.sys.mac hierarchy document. This document will be posted on a regular
basis (and updated when needed) and will document the different groups in
the hierarchy and what type of messages should be posted where. It or a
sister posting will also include answers to common questions. This posting
should also help reduce cross-posting, confusion and the constant
re-introduction of certain topics.
Rejected proposals: This is a short list of proposals considered that I've
rejected and why:
o c.s.m.fonts: discussion should be in comp.fonts
o c.s.m.desktop: desktop publishing discussion should be in comp.text.desktop
o c.s.m.d (or c.s.m.futures): I wasn't convinced it was a viable long-term
discussion. With the proper splitting of the other topics, it should
fit appropriately in c.s.m.misc. talk.politics.apple was also
considered.
o c.s.m.viruses: discussion should be in comp.virus
o c.s.m.reviews: there isn't enough traffic to justify, and it would
have to be moderated to prevent lots of noise.
o c.s.m.{db,comm,spreadsheet,wordprocessing,et al}: these should be
considered as sub-groups of the c.s.m.appl hierarchy and we should
wait and see how traffic in that area works out before considering
splitting it further.
That's it. Five proposals, two renamed groups and three creations (two of
which should be considered roots for sub-hierarchies that can be created as
needed). Again, please respond to the survey about the format of this
proposal, and if you have groups you feel ought to be added to the
proposal. All discussion should take place in news.groups, not in the c.s.m
group.
thanks to: Cory Kempf, D. K. Smith, Dan Veditz, Dave Smith, Gail
Zacharias, Geoff Allen, John Macdonald, John R. Delaney, Larry E.
Kollar, Mark M Mehl, Piper Keairnes, Randy Futor, capmkt!bandy,
fleming@cup.portal.com, sklein@cdp.UUCP, among others, for their feedback,
suggestions and advice on building this proposal.
chuq
--
Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking]
Rumour has it that Larry Wall, author of RN, is a finalist in the race for
the Nobel Peace Prize for his invention of the kill file.6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (02/20/90)
I could quote a ton from the proposal, but I think that would only waste bandwidth. Instead, I will summarize: Chuq proposed a way to split comp.sys.mac. Pretty quick summary, eh? I don't have any problems with the proposal as it stands except for the fact that comp.sys.mac.programmer isn't mentioned at all. This isn't necessarily bad, since it could mean that Chuq's proposal wants to leave it alone. On the other hand, I've always thought that comp.sys.mac.hypercard belonged comp.sys.mac.programmer.hypercard. I know it's a long name, but it has an intuitive feel to it for me. I'm not ready to call HyperCard hackers computer scientists (and they probably aren't, either), but I don't think HC fits anywhere else. Ideas? Objections? Accolades? ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
chuq@Apple.COM (Chuq Von Rospach) (02/20/90)
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) writes: >I don't have any problems with the proposal as it stands except for the fact >that comp.sys.mac.programmer isn't mentioned at all. This isn't necessarily >bad, since it could mean that Chuq's proposal wants to leave it alone. On >the other hand, I've always thought that comp.sys.mac.hypercard belonged >comp.sys.mac.programmer.hypercard. I currently plan on leaving c.s.m.programmer alone because I really don't think it needs to be fixed. c.s.m.hypercard's an interesting thing. HyperCard tends to defy explanation. I generally describe it to people as "the Basic of the 90's" but that's not really a fair description, either. it was suggested to me as c.s.m.appl.hypercard, c.s.m.appl.db.hypercard, c.s.m.p.hypercard -- there are just lots of places where it almost fits. I decided against putting it in programmer because there's a lot of functionality and utility that has nothing to do with programming hypercard. There are a lot of users out there that never do any scripting and just use stacks other people write. A c compiler, on the other hand, is something you wouldn't use unless you were compiling something. So I put it under appl. I could be convinced to change that, but I think that while programming HC is an important aspect, it's not the only important aspect, and it's better to put it in with the applications. As to c.s.m.p itself, I considered setting it up as a hierarchy, but I think it might be overkill right now. I also considered setting it up with the amiga naming standards (c.s.m.tech), which is easier to type and probably a better name for a hierarchy (programmer is better for a single group, though). Try: c.s.m.tech.c c.s.m.tech.macapp c.s.m.tech.misc c.s.m.tech.mpw c.s.m.tech.pascal Considering the volumn in c.s.m.p right now, do we really buy anything with this? I tend to think it's too-much-too-soon, but maybe we ought to get it all out of the way now. that's why we're in the discussion phase: to hack this out. I can be convinced either way. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Rumour has it that Larry Wall, author of RN, is a finalist in the race for the Nobel Peace Prize for his invention of the kill file.
chuq@Apple.COM (Chuq Von Rospach) (02/20/90)
Just to keep people up to date, I've already made a few changes to the
proposal as posted that I'd like to send out for comments. From my change
log. I plan on including these changes in the official call for votes unless
someone convinces me they're wrong (in the case of an 'add group', this
isn't so bad, since you can always vote the specific group down. In some
ways I'd rather have too many 'add groups' in the proposal and have some
rejected than too few and not get the right groups created.)
---===---===---===---===---===
changes from call for discussion proposal:
---===---===---===---===---===
(a) change group name comp.sys.mac.appl to comp.sys.mac.appl.misc. This is
a sub-hierarchy, and we need to avoid what we're trying to fix with the
c.s.m -> c.s.m.misc rename.
(b) add group c.s.m.appl.games for discussion of macintosh games.
(c) add group c.s.m.appl.comm for discussion of communication issues:
terminal emulators (white night, microphone, etc), bbs software (red
ryder host) and communication/networking (appleshare, tops, etc).
---===---===---===---===---===
--
Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking]
Rumour has it that Larry Wall, author of RN, is a finalist in the race for
the Nobel Peace Prize for his invention of the kill file.6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (02/20/90)
From article <38783@apple.Apple.COM>, by chuq@Apple.COM (Chuq Von Rospach): > There are a lot of users out there that never do any scripting and just use > stacks other people write. > I think that while programming HC is an important aspect, it's not the > only important aspect, and it's better to put it in with the applications. Well, I suppose my main concern is that I want to read HyperTalk/XCMD stuff but not stack stuff. I generally give c.s.m.programmer much more scrutiny than c.s.m itself, because for me c.s.m.programmer has higher signal-to-noise. My first reaction, then, is to then suggest comp.sys.mac.app.hypercard AND comp.sys.mac.programmer.hypercard... but that's a bit too much depth too hastily, methinks. As you go on to point out with... > As to c.s.m.p itself, I considered setting it up as a hierarchy, but I think > it might be overkill right now. Exactly. But 'might' is the key word there. I would be interested to see what others have to say, which is why this will be my last post on the subject for a little while. The way I see it, newsgroup over-propogation will only encourage cross-posting, and comp.sys.mac.programmer can always be messed with later. But I still have misgivings about HyperCard's placement, even if only for my own personal concerns, though those concerns are not likely unique. (How many qualifying clauses can you count in the last sentence?) ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
werner@zephyr.sw.mcc.com (Werner Uhrig) (02/20/90)
re: where does Hypercard belong in the hierarchy ...
I think Hypercard should not be "buried" under c.s.m.appl or
c.s.m.prog but should stand by itself, with the potential for
a later split into sub-groups such as
tech, users, programmers, etc...
at which point I'd (once again, and for brevity=sanity sake)
would argue for
comp.sys.mac.hc.tech
^^.appl
.prog
.user et. ...
but that is a bridge (proposal) that the Hyperflunkies have
to build ....
I'm so glad that *something* is finally getting split again
in comp.sys.mac ..... I'll vote for whatever the majority votes
for !! :-)
--
--------------------------> please send REPLIES to <------------------------
INTERNET: werner@cs.utexas.edu
or: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1)
UUCP: ...<well-connected-site>!cs.utexas.edu!wernerrussotto@eng.umd.edu (Matthew T. Russotto) (02/20/90)
In article <38783@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >I currently plan on leaving c.s.m.programmer alone because I really don't >think it needs to be fixed. Agreed. >c.s.m.hypercard's an interesting thing. HyperCard tends to defy explanation. >I generally describe it to people as "the Basic of the 90's" but that's not >really a fair description, either. it was suggested to me as >c.s.m.appl.hypercard, c.s.m.appl.db.hypercard, c.s.m.p.hypercard -- there >are just lots of places where it almost fits. Why not just leave it c.s.m.hypercard-- it really isn't an 'app' (i.e. a 'Desktop' Application, as described by the Human Interface Guidelines) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?
chuq@Apple.COM (Chuq Von Rospach) (02/20/90)
russotto@eng.umd.edu (Matthew T. Russotto) writes: >Why not just leave it c.s.m.hypercard-- it really isn't an 'app' (i.e. >a 'Desktop' Application, as described by the Human Interface Guidelines) The rationalization was that it was more of an application than a part of the os (Apple's bundling as system software notwithstanding) and I'm trying to avoid putting stuff at the top level that doesn't need to be. On the other hand, a couple of people have brought up not renaming it, so I'm watching the discussion. I will probably leave it on the proposal as stands and see whether it gets approved or not during the vote (since what you're proposing is 'do nothing', rather than 'modify the proposal'). chuq -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Rumour has it that Larry Wall, author of RN, is a finalist in the race for the Nobel Peace Prize for his invention of the kill file.
usenet@cps3xx.UUCP (Usenet file owner) (02/20/90)
In article <38768@apple.Apple.COM> chuq@apple.com (Chuq Von Rospach) posted an official call for discussion regarding reorganizing the comp.sys.mac hierarchy. I'm not going to quote from it at length. Overall, the proposals he presents are well-reasoned and would go a a long way toward improving the current mess in comp.sys.mac. However, I have some quibbles and, IMHO, some improvements to offer. >Proposal 1: rename comp.sys.mac to comp.sys.mac.misc. >Proposal 2: Creation of comp.sys.mac.os. >Proposal 3: Creation of comp.sys.mac.appl. These three proposals all make a lot of sense to me. My quibble here is VERY minor. Chuq says finding a mame for the applications group >created a fair amount of discussion, ranging between app and applications and then states his reasons for settling on `appl'. I would prefer `apps': most of the reasons Chuq gave for `appl' apply equally to it, and in this context, when my brain sees `appl' it wants to put an `e' on the end and launch itself into an infinite loop. :-) There's just something about `appl' that bugs me . . . it itches someplace I can't scratch. >Proposal 4: renaming comp.sys.mac.hypercard to comp.sys.mac.appl.hypercard. Whoa! Hold it right there. Chuq's reasoning on this: >To standardize naming in the new scheme. Technically, since Apple computer >considers Hypercard system software it should be c.s.m.os.hypercard, but I >don't believe most users agree with that thinking. I don't think most users view HyperCard as just an app, either. In article <3996@hub.UUCP> 6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) takes a substantially different view: >I've always thought that comp.sys.mac.hypercard [should be] >comp.sys.mac.programmer.hypercard. I know it's a long name, but it >has an intuitive feel to it for me. I'm not ready to call HyperCard >hackers computer scientists . . . but I don't think HC fits >anywhere else. In article <38783@apple.Apple.COM>, Chuq responds to this: >c.s.m.hypercard's an interesting thing. HyperCard tends to defy >explanation. I generally describe it to people as "the Basic of >the 90's" but that's not really a fair description, either. it was >suggested to me as c.s.m.appl.hypercard, c.s.m.appl.db.hypercard, >c.s.m.p.hypercard -- there are just lots of places where it almost fits. Chuq then gives his reasons for not having HyperCard under c.s.m.p: >there's a lot of functionality and utility [in HyperCard] that has >nothing to do with programming . . . . a lot of users out there . . . >never do any scripting and just use stacks other people write. So, he settled on comp.sys.mac.appl.hypercard. >I could be convinced to change that . . . . Chuq is absolutely right: Hypercard does defy explanation. It also defies categorization. It is neither an application, a language, nor really part of the system. Yet it is coming to be viewed by a sizable proportion of Mac users as integral to the Mac--and if there's any substance at all behind all the `future role of HyperCard and HyperTalk' vapor that's been rolling off the pages of MacWeek, then HyperCard is only going to become more important to the typical Mac user. It simply doesn't make any sense to try to shove HyperCard into an arbitrary category merely for the purpose of `standardizing naming in the new scheme.' My radical proposal: comp.sys.mac.hypercard It works. It works just fine. Leave well enough alone. >Proposal 5: creation of comp.sys.mac.wanted. This is an excellent idea. The reduction in cross-postings which it should engender is much to be desired. For similar reasons, I would like to add another proposal: Proposal 6: creation of comp.sys.mac.conflicts (no, I'm not really attached to that name; I'm sure someone out there in netland can come up with a better one) This would be a place for all those postings about how a particular app and a version of the System don't want to work together, INIT or FONT conflicts, and all that. IMHO, if there's not a special place for these, they'll wind up being cross-posted all over: to c.s.m.os and c.s.m.apps (oops . . . I meant c.s.m.appl :-)), maybe c.s.m.misc. and possibly even c.s.m.programmers. If you agree with me on this one, let Chuq know when you vote on the proposals. In his original posting, he said that he'd like to see 100 votes to put any additional proposals up for the final balloting. If you think I'm off the wall, post reasoned arguments to news.groups; send flames direct. (I love getting mail! :-)) >comp.sys.mac document . . . introduction to the comp.sys.mac hierarchy. Also good thinking. I agree almost entirely with Chuq's reasoning in his list of rejected proposals. I had only one tentative qualm: c.s.m.comm. That was alleviated when I found this: In article <38784@apple.Apple.COM>, Chuq makes these additions to the proposals: >(a) change group name comp.sys.mac.appl to comp.sys.mac.appl.misc. This is > a sub-hierarchy, and we need to avoid what we're trying to fix with the > c.s.m -> c.s.m.misc rename. >(b) add group c.s.m.appl.games for discussion of macintosh games. >(c) add group c.s.m.appl.comm for discussion of communication issues: All of which sound good to me. +-----===-----===-----===-----===-----===-----===-----===-----===-----+ | carl jeffrey otto | Macintosh: the first personal computer | | otto@frith.egr.msu.edu | good enough to criticize. -- Alan Kay | | - - - - - - - - - - - - - - - - - | | My opinions are my own. Feel free to borrow any that you like; | | but if you do something silly with it, that's your problem. | +-----===-----===-----===-----===-----===-----===-----===-----===-----+
peter@ficc.uu.net (Peter da Silva) (02/20/90)
I think comp.sys.mac.apps is a better name than c.s.m.appl, from an
aesthetic standpoint and a practical one. The latter sounds like it
should be comp.sys.mac.apple (or is that comp.sys.apple.mac?), perhaps
a group for discussing the apple records lawsuit. Besides, Mac
hacks are always using "app" or "apps" as an abbreviation. I've never
seen "appl" used. Common, non-confusing abbreviations are better than
exotic and confusing ones...
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'leipold@eplrx7.uucp (Walt Leipold) (02/20/90)
In article <38783@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >I currently plan on leaving c.s.m.programmer alone because I really don't >think it needs to be fixed. > >As to c.s.m.p itself, I considered setting it up as a hierarchy, but I think >it might be overkill right now. I also considered setting it up with the >amiga naming standards (c.s.m.tech), which is easier to type and probably a >better name for a hierarchy (programmer is better for a single group, >though). Try: > >c.s.m.tech.c >c.s.m.tech.macapp >c.s.m.tech.misc >c.s.m.tech.mpw >c.s.m.tech.pascal Then of course you'll need "c.s.m.tech.hardware" instead of the current "c.s.m.hardware", right? The original posting didn't mention c.s.m.hardware at all... Oh, BTW, I'm in all favor of the reorganization; the S/N ratio on c.s.m has been particularly low lately. >Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) -- -- The UUCP Mailer
gz@cambridge.apple.com (Gail Zacharias) (02/21/90)
In article <38768@apple.Apple.COM> chuq@apple.com (Chuq Von Rospach) writes: >Proposal 2: Creation of comp.sys.mac.os. This will be for discussion of >Macintosh system software -- the system, finder, multifinder, CDEVs, INITs >and other Apple and third party Operating System software and its >extensions. >Proposal 3: Creation of comp.sys.mac.appl. This will be for discussion of >Macintosh applications. I do not believe this split will work. Once all the discussions die down and people are just going by the names of the newsgroups, I don't think c.s.m.os will end up with much of anything except mac vs. ms-dos wars. Do you really believe people will post comments about Public Folder or SuperClock or any other useful init/cdev to a group named c.s.m.os instead of c.s.m.app{s,l}? -- gz@cambridge.apple.com
randy@polecat.llnl.gov (Randy Futor) (02/21/90)
chuq@Apple.COM (Chuq Von Rospach) writes: >russotto@eng.umd.edu (Matthew T. Russotto) writes: >>Why not just leave it c.s.m.hypercard . . . >The rationalization was that it was more of an application than a part of >the os (Apple's bundling as system software notwithstanding) . . . Before I was done with the thread, another poster used the phrase that came first to my mind when thinking about what to do with the HC group(s), to wit, leave well alone. HC is sorta OS, sorta application -- leave it between the 2 in the namespace to reflect that. It's not an attempt to be clever & it does mean doing one less thing at this stage -- as a consequence, I like it! ;-} -- randy@polecat.llnl.gov futor@ocfmail.ocf.llnl.gov ps: As someone else pointed out ( I apologize for dropping your article in my haste! ), the OS stuff should be routed to comp.os.mac which *will* mean changes outside the c.s.m realm; this shouldn't be a major deal though, since a) it *is* an operating system, opinions to the contrary notwithstanding ( or should that be "not *worth* standing"?? ;-) & b) there does seem to be sufficient traffic to justify its creation. -- just a couple of thoughts -- R
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (02/21/90)
In article <164@brazil.cambridge.apple.com>, gz@cambridge.apple.com (Gail Zacharias) writes that it is unlikely that people will post questions about INITs, cdevs, and the like, in a group called comp.sys.mac.os, and I think Gail's right. Speaking not of the net, I often hear people wonder what the Mac OS is called. They want to call it the Desktop (no, that's the metaphor), HFS (no, that's a type of file system), the Finder (no, that's the shell). Now, *I* call it the Mac OS, because I'm a Mac geek and I hafta be right about these things or kill myself. But my point is that lots of people don't KNOW the Mac has an OS. Or what an OS is. And that in some large part is what the Mac is -- a machine usable by people who don't know what an OS is. Some alternatives I've thought of just now for comp.sys.mac.os might be... comp.sys.mac.system-folder /* my fave so far */ comp.sys.mac.system /* hmmm. redundant? */ comp.sys.mac.inits-das /* a little abitrarily specific */ This is a pretty tough thing to figure out. Nobody should panic, though, because we still have comp.sys.mac.os to fall back on. I just want to see something else used if someone can think of it. randy@polecat.llnl.gov (Randy Futor), in another article in my ZTerm scrollback buffer that has no reference number :-), says this: > the OS stuff should be routed to comp.os.mac Ugh. I think it will be lost there. It is my understanding that the comp.os hierarchy is for discussion of multi-platform operating systems in a relatively "scientific" or "academic" way. Until we have Mac clones, there will only be one machine running the Mac OS, and that's the Mac. There are lots of Macs, but I don't think that's a relevant distinction. ------------------------------------------------------------------------------ Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
jpb@umbio.miami.edu (Joe Block) (02/21/90)
I think splitting comp.sys.mac is a great idea. The traffic is just too high to keep up with, especially for people who aren't interested in all the areas. I do think that there should be a comp.sys.mac.virus though, because virus information is machine specific, and most of us who only use Macs probably don't want to wade through postings about DOS and UNIX viruses to find out about the viruses that do concern us (I know I don't). -- Joe Block jpb@umbio.miami.edu There was a young poet named Dan, whose poetry would never scan, when told this was so, He said, Yes I know, It's because I try to fit every possible sylable into the last line that I can.
tim@hoptoad.uucp (Tim Maroney) (02/21/90)
This is a highly silly idea. People on the network are not fastidious; they are, in fact, downright sloppy. The divisions between the newsgroups would not be respected, since people simply blather on about whatever suits their fancy in any newsgroup which seems marginally related to the subject. If this division were instituted, one could not be sure from reading group X that one would be reading most of the posted messages about subject X, nor that one would even be reading mostly messages on subject X. This situation would create a great deal of frustration, and would lead to all the new groups having a large number of metadiscussions about how article 49717523@foo.edu does not belong in newsgroup comp.sys.mac.wombat, it belongs in newsgroup comp.sys.mac.platypus. Between inappropriately posted messages and flames about inappropriately posted messages, we would be replacing one unreadable newsgroup with some ten unreadable newsgroups. The proposal shows a naivete about network sociology which would be surprising in a person with a decade's experience on the net; but it is not surprising, considering that it comes from an alienated mega-nerd with absolutely no perception of social reality. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
werner@zephyr.sw.mcc.com (Werner Uhrig) (02/21/90)
> re: csm.appl vs. csm.apps I like csm.appl better. first because it is the "natural" abbreviation for "application" (you alway put stop when a vowel would be next, right?) and "apps" does not seem intuitive to me at all .... > re: what about hypercard? given its "tri-sexualness" (or is it more?) of OS-software, programming platform, application (and "environment" and DB-system and ...) I think the "obvious" solution out is to leave it at the level where it is. But I always disliked the length of that name, and given that it is quite likely to spawn "daughters", my prefered name would be csm.hyca (or csm.hype, maybe :-) and, yes, I considered csm.hyca.misc, but I'd like to wait for that until csm.hyca.xcmd and csm.hyca.user gets created. (another argument against csm.hype is that it would then result in csm.hype.misc, csm.hype.user and csm.hype.prog - and what kind of ideas would that give to people !! :-) hmmm, csm.hype.2pt0... anyway, thanks for starting this thread, Chuq .... -- --------------------------> please send REPLIES to <------------------------ INTERNET: werner@cs.utexas.edu or: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1) UUCP: ...<well-connected-site>!cs.utexas.edu!werner
werner@zephyr.sw.mcc.com (Werner Uhrig) (02/21/90)
> Do you really believe people will post comments about Public Folder
or SuperClock or any other useful init/cdev to a group named c.s.m.os
instead of c.s.m.app{s,l}?
YES, especially if one posts a little (maybe more than once, or
bimonthly) note explaining that this is the group to post articles
which address any files that you might stick into your System
Folder ... (a little hand-holding never hurts :-)
--
--------------------------> please send REPLIES to <------------------------
INTERNET: werner@cs.utexas.edu
or: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1)
UUCP: ...<well-connected-site>!cs.utexas.edu!wernerwerner@zephyr.sw.mcc.com (Werner Uhrig) (02/21/90)
In article <10377@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >This is a highly silly idea. People on the network are not fastidious; >they are, in fact, downright sloppy. The divisions between the >newsgroups would not be respected, since people simply blather on about >whatever suits their fancy in any newsgroup which seems marginally related ...etc.etc... the first part of Tim's article might be construed as a contribution to the discussion, even though a rather "silly" one if one thinks through that he implies that "less groups are better because then people do not complain about articles posted to the wrong group" (so why do we have the many groups we have in the first place?!!) in a way this an insult to most everyone on the net which get classified as stupid fools all out to make Tim's life miserable .. ...but then Tim gets personal and insults Chuq directly (and I actually had thought you had grown up some over the last 5 years, Tim, and would have expected better from you) >The proposal shows a naivete about network sociology which would be >surprising in a person with a decade's experience on the net; but it is >not surprising, considering that it comes from an alienated mega-nerd >with absolutely no perception of social reality. >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com I would have ignored the article and let it stand (and sink) on its own foolishness, but I simply don't think one should let this kind of public attack (on anyone) go by without some kind of protest - do your insulting in private email, Tim, it would do both your image and the quality of your articles a whale of good. -- --------------------------> please send REPLIES to <------------------------ INTERNET: werner@cs.utexas.edu or: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1) UUCP: ...<well-connected-site>!cs.utexas.edu!werner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/21/90)
In article <38768@apple.Apple.COM> chuq@apple.com (Chuq Von Rospach) writes: >[4 things with which I entirely agree omitted] >Proposal 5: creation of comp.sys.mac.wanted. A place for the "I'm missing >part five of..." or "I need a program that does..." or "Where can I get a >good price on..." messages. I can see why people would want to post to this group (because they want/need part of a posting, a package, etc.). What I don't see is why anyone would READ the group to answer the postings. I'd be inclined to treat it as a "just noise" group and ignore it; perhaps I'm just not as altruistic as some others, or perhaps I don't really understand the intended content of the group. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/21/90)
In article <4003@hub.UUCP> 6600pete@ucsbuxa.ucsb.edu writes: >Some alternatives I've thought of just now for comp.sys.mac.os might be... > > comp.sys.mac.system-folder /* my fave so far */ Too long. > comp.sys.mac.system /* hmmm. redundant? */ Not redundant in the macintosh context. I think this would be an improvement over comp.sys.mac.os; "os" is indeed a fuzzy concept on the macintosh, now that you mention it. > comp.sys.mac.inits-das /* a little abitrarily specific */ A little too *something*; blech. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/21/90)
In article <3480@zephyr.sw.mcc.com> werner@zephyr.sw.mcc.com (Werner Uhrig) writes: >> re: what about hypercard? > > given its "tri-sexualness" (or is it more?) of OS-software, > programming platform, application HyperCard is an application, and it is also a programming platform. It is NOT operating system software. The "system software" talk is just a fiction used to allow Apple to spin off "all" their "applications", but keep HyperCard. It's doublethink. Personally, I think comp.sys.mac.apps.hypercard is probably the right way to go, in spite of the length of the name. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
roy@phri.nyu.edu (Roy Smith) (02/22/90)
Chuq Von Rospach <chuq@apple.com> writes: >Proposal 3: Creation of comp.sys.mac.appl. I hate to pick nits with what is basicly a very well thought out and logical proposal, but my first thought when I saw c.s.m.appl was that "appl" stood for "Apple" not "Application". This leads to, of course, c.s.m.clone, should the need ever arise. Personally I prefer "app" because it seems more logical, and because it's 1 character shorter. That said, I voted yes for the whole proposal, and urge others to do likewise. It's basicly pretty good and the need for reorganization is obvious. I think everybody should consider just putting up with whatever little part of the proposal irks them rather than insisting on slugging it out with more proposals, counter-proposals, votes, etc. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy "My karma ran over my dogma"
emv@math.lsa.umich.edu (Edward Vielmetti) (02/22/90)
I dunno about the mac reshuffling more I think about it -- I start to get cognitive overload thinking about all these new groups, what they might be named, and how deep these hierarchies are getting. I need an argument that it's better to go down two levels more in the tree rather than just broadening out the existing level. For point of comparison here's other similar breakdowns: mac: digest hardware hypercard programmer binaries appletalk amiga: hardware tech sun: hardware software source sunos windows miscellaneous networks (*) ibmpc: digest net programmer tcp-ip binaries binaries.d sun is the moderated "comp.sys.sun", there's also an "alt.sys.sun". the breakdowns are by the Keywords: on the postings. The categorization is very good, though there have been latency problems. the tcp-ip group is "comp.protocols.tcp-ip.ibmpc", a rotten name for the PCIP mailing list. There's no traffic to speak of on ibm.pc.net. the ibmpc binaries group is bad of late having lost a moderator. The good news is the traffic on comp.binaries.ibm.pc.d; it has postings from the top archivists in the pc world (Keith Peterson, Timo Salmi, Russ Nelson) and no shortage of good traffic. I would suggest that a comp.binaries.mac.d would get reasonable traffic quickly and the signal/noise probably wouldn't be bad at all, especially if the sumex folks were to join in. note that the "source" part of comp.sys.sun is really announcements of availability of sources, not the things themselves. In this way it functions much like comp.archives. as far as spinning off "games", note that the current rec.games hierarchy has several different kinds of things in it, e.g. - specific games: bridge chess empire go hack moria rogue - specific game-playing machines: vectrex - general game-playing machines: video - general game types: board frp pbm rpg* - general game-writing people: programmer - a sort of on-line game: trivia - everything else: misc a comp.sys.mac.games (or comp.sys.mac.apps.games, ick) would fit in rec.games.mac via the "vectrex rule" though that's kind of weak at this point. In summary. I suggest discussion of comp.binaries.mac.d, a group along the lines of comp.binaries.ibm.pc.d. By all my estimates it's the right next thing to do, it should clear a vote real easily (I think the mercy rule could kick in on this one), and it's independent of the existing comp.sys.mac reorganization question. --Ed
moriarty@tc.fluke.COM (Jeff Meyer) (02/23/90)
Taken from my letter to chuq, and offered up for discussion on the renaming conventions: ----- I'd vote No on the current slate of proposals, but you're pretty close to a set of new newsgroups that I'd vote Yes for. Brief analysis: >Proposal 1: rename comp.sys.mac to comp.sys.mac.misc. No problems at all with this. >Proposal 2: Creation of comp.sys.mac.os. This will be for discussion of >Macintosh system software -- the system, finder, multifinder, CDEVs, INITs >and other Apple and third party Operating System software and its >extensions. Two problems with this, one major, one minor. The inclusion of 3rd party CDEVs and INITs makes for a fuzzy line between this and comp.sys.mac.appl; the types of discussions I'd associate as being clearly disassociated from the other comp.sys.mac groups, i.e. questions, complaints, suggestions about Apple system software, begin to get mixed with reviews, questions, comments about 3rd party utilities -- something I'd associate more with comp.sys.mac.appl. Stick to strictly Apple-produced system software. My minor problem with this group would be how much volume it would produce, but once 7.0 comes out, there should be plenty of room there for it. Scratch that... >Proposal 3: Creation of comp.sys.mac.appl. Go for it. Include third party utilities from Proposal two, though. >Proposal 4: renaming comp.sys.mac.hypercard to comp.sys.mac.appl.hypercard. I'd hesitate about this structure for two reasons: one, HyperCard compatibles like SuperCard and Plus are often discussed in this group; I guess I've come to think of HyperCard less as an application, and more as a "interface/language for the Mac." More importantly, it sounds as if much of HyperCard is going to be incorporated into the System Software in 7.0 and afterwards. I think HyperCard is unique enough to keep it's current designation. However, this isn't a major item; I wouldn't vote down the entire scheme just for this. >Proposal 5: creation of comp.sys.mac.wanted. Is there a precendent for this, i.e. a comp.sys.pc.wanted? This is the kind of group I could see that is heavily cross-posted to comp.sys.mac.appl or comp.sys.mac.misc, from the standpoint that the people the posters want to reach often do not read this type of group; it's success depends on the number of good Samaritans you have who page through, looking to help. I agree that it would be nice to get out the "I'm missing part 5 of XXX on comp.binaries.mac", but I don't think this group will solve that situation. As to recommendations for applications, etc., I'd rather have that in comp.sys.mac.appl, as it spurs discussions of merits and defeciencies of various applications. ---- In summary, I'd say that if Item 2 were changed to specifications, I'd vote Yes on this as a format. I don't really care for comp.sys.mac.wanted, but I can vote No on that when the individual group vote is taken. I'm quibbling with Proposal 4; it's not that important to me one way or another. "You're right, of course. I'm extraordinarily selfish. But it has served me so well in the past." --- Moriarty, aka Jeff Meyer INTERNET: moriarty@tc.fluke.COM Manual UUCP: {uw-beaver, sun, microsoft, hplsla, uiucuxc}!fluke!moriarty CREDO: You gotta be Cruel to be Kind... <*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>
ggw@wolves.uucp (Gregory G. Woodbury) (02/24/90)
In article <38768@apple.Apple.COM> chuq@apple.com (Chuq Von Rospach) writes: > >This is an official call for discussions on reorganizing the >comp.sys.mac hierarchy. > [at the end of the whole thing, Chuq writes] >That's it. Five proposals, two renamed groups and three creations (two of >which should be considered roots for sub-hierarchies that can be created as >needed). >Proposal 1: rename comp.sys.mac to comp.sys.mac.misc.... > This will bring c.s.m into the same standardized naming... Hmmm.... what standardized naming scheme? Not that I disagree with c.s.m.misc, but what other groups really adhere to any sort of standard? >Proposal 2: Creation of comp.sys.mac.os. > This will be for discussion of Macintosh system software > the system, finder, multifinder, CDEVs, INITs This is (I presume) one of the groups that can be further sub-divided as necessary to provide less density and finer control. It wasn't identified as such explicilty, but I feel that this should be clearer. >Proposal 3: Creation of comp.sys.mac.appl. Not a bad bit of creative naming. >Proposal 4: renaming comp.sys.mac.hypercard to comp.sys.mac.appl.hypercard. Here I have a problem. HyperCard is only technically an application. It really more like an alternative to most of the mac os stuff. It doesn't belong in the os area, but then again, it really is too much to be lumped in just one area. I'd rather see it remain in its own area where it can be sub-split if it gets really hairy. Besides, it should be comp.sys.mac.hc.* ;-) >Proposal 5: creation of comp.sys.mac.wanted. No problem. Another presumption: comp.sys.mac.programmer remains in places, as do c.s.mac.hardware and c.s.m.digest? -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>
jln@accuvax.nwu.edu (John Norstad) (02/26/90)
I understand that there's a proposal to create a new UseNet newsgroup devoted to Macintosh viruses. I missed the original proposal on the nets, but a friend told me about it, and recommended that I post my comments on news.groups. I'd like to register a "NO" vote on any such new group. I have several reasons for voting "NO": 1) There is a already a group comp.virus (= VIRUS-L) which is very active and contains lots of Mac-related postings. It's a moderated group, which helps a bit. 2) I and other anti-viral tool authors would undoubtably continue to post announcements of new viruses and upgrades of our tools to comp.sys.mac anyway, to reach the widest possible audience. 3) The most important reason of all is that I'm afraid such a group would only encourage speculation about how viruses work and how new viruses could be created. It is the unfortunate truth that such speculation in public does indeed lead to the creation of new viruses - it's happened several times in the Mac world already, and numerous times in the PC world. Those of us who are active in the fight against viruses have come to the sad conclusion that it is very dangerous to talk about our work except among ourselves. I know that this is elitist and may even be hopeless in the long run, but that's the way it is. 4) Amateurs who post uninformed conjecture about viruses simply confuse the public - witness the really bad mess on comp.sys.mac (or perhaps it was comp.sys.mac.programmer, I've forgotten) shortly after the discovery of WDEF. I think that the creation of a new group devoted solely to viruses would only encourage this kind of thing. 5) The people who are actively doing research on Mac viruses and who are developing the major anti-viral tools already have their own private discussion group. John Norstad (author of Disinfectant) Northwestern University jln@acns.nwu.edu
mehl@cs.iastate.edu (Mark M Mehl) (02/27/90)
jpb@umbio.miami.edu (Joe Block) writes: >I . . . think that there should be a comp.sys.mac.virus though, >because virus information is machine specific, and most of us who only use ^^^^^^^ ^^^^^^^^ You mean operating system specific. This is true. >Macs probably don't want to wade through postings about DOS and UNIX viruses >to find out about the viruses that do concern us (I know I don't). Right again. The virus discussions should be posted to comp.sys.mac.os (or comp.os.mac, which ever gets created) (with possible cross postings to comp.virus) because they are OS specific. Now many people realize this already because virual-ware is a kind of cDEV or INIT program that "is" to be discussed in comp.sys.mac.os; however, many people do not. Just saying that comp.sys.mac.os includes discussions on cDEV and INITs isn't enough; the charter for this OS group should spell out the word V.I.R.U.S. because many non-computer people don't appreciate that virual issues are really OS issues of a special kind. There is nothing wrong with having a comp.virus group on Usenet; however, people should really cross post to the corresponding OS group in the comp.os.* hierarchy because that's really where the virus discussions belong. In fact, comp.virus should really be renamed to comp.os.virus because viruses are always OS issues just as they are OS specific. Perhaps, someday, we will have to create a comp.os.mac.virus group on Usenet, but let's hope not. -- /\ Mark M Mehl, alias Superticker (Supertickler to some) <><> Internet: mehl@atanasoff.cs.IAstate.edu \/ UUCP: {{mailrus,umix}!sharkey,hplabs!hp-lsd,uunet}!atanasoff!mehl Disclaimer: You got to be kidding; who would want to claim anything I said?