spaf@gatech.CSNET (Gene Spafford) (10/29/85)
Postings suggesting and/or discussing the replacement of net.sources.mac
by mod.sources.macintosh (my suggestion for the name) should go on in
net.news.group. I have added that group to the "Newsgroups" line of
this article, and followups will also go there.
I have set the "Followups" line so that discussion *only* goes on in
net.news and net.news.group. Anyone reading net.sources.mac who has
an opinion on this matter should subscribe to net.news.group.
--
Gene "sometime in 1986" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spafbytebug@felix.UUCP (Roger L. Long) (10/30/85)
In article <1754@gatech.CSNET> spaf@gatech.UUCP (Gene Spafford) writes: >Postings suggesting and/or discussing the replacement of net.sources.mac >by mod.sources.macintosh (my suggestion for the name) should go on in >net.news.group. I have added that group to the "Newsgroups" line of >this article, and followups will also go there. Net.sources.anything seems ideal to moderate, just so we can clear out the noise of discussion and requests for reposting part x of y when the less-than-perfect net distribution system eats an article. I mentioned in an earlier posting that I was willing to moderate a mod.sources.macintosh group. I've so far received one vote - a yes. If you have an opinion on having such a group, MAIL your vote to me. -- roger long filenet corp trwrb!felix!bytebug
gus@Shasta.ARPA (10/31/85)
> Postings suggesting and/or discussing the replacement of net.sources.mac > by mod.sources.macintosh (my suggestion for the name) should go on in > net.news.group. I have added that group to the "Newsgroups" line of > this article, and followups will also go there. > > I have set the "Followups" line so that discussion *only* goes on in > net.news and net.news.group. Anyone reading net.sources.mac who has > an opinion on this matter should subscribe to net.news.group. KEEP NET.SOURCES.MAC!!!!!!!!!!! N.S.M is a goldmine of software for the Macintosh and I don't want to see anything to lessen its usefulness.
maddog@tolerant.UUCP (Bill Arnett) (11/01/85)
In article <1482@Shasta.ARPA> gus@Shasta.ARPA writes: > >KEEP NET.SOURCES.MAC!!!!!!!!!!! > >N.S.M is a goldmine of software for the Macintosh and I don't want to see >anything to lessen its usefulness. RIGHT ON! -- Bill Arnett {ucbvax,nsc}!tolerant!maddog Tolerant Systems, Inc. San Jose 408/946-5667
somner@lasspvax.UUCP (David Somner) (11/05/85)
In article <195@tolerant.UUCP> maddog@handel.UUCP (Bill Arnett) writes: >In article <1482@Shasta.ARPA> gus@Shasta.ARPA writes: >> >>KEEP NET.SOURCES.MAC!!!!!!!!!!! >> >>N.S.M is a goldmine of software for the Macintosh and I don't want to see >>anything to lessen its usefulness. > >RIGHT ON! Hear hear! Let's keep this group going!!!!! On this end of the world, (Cornell) everyone uses Macs highly. I believe that about a good 70% of all people on campus use one, and about 60% have Macs themselves after using it for about a month or so. This is a VERY active site for Mac stuff.
hogan@rosevax.UUCP (Andy Hogan) (11/07/85)
> Postings suggesting and/or discussing the replacement of net.sources.mac > by mod.sources.macintosh (my suggestion for the name) should go on in > net.news.group. I would like to register one vote (if there can be such a thing in an anarchic net :-) ) for keeping net.sources.mac. My reasons: 1. There is a resonable amount of software useful to me and others at work. I also use some at home, but that does not negate my usage at work. 2. I don't think making the group a moderated one would decrease the volume all that much. The volume is high both because of interest and because of the type of posting-- usually text files which can be decrypted to produce a Mac-executable application. These tend to be large. Making the group moderated won't affect interest Unless the moderator is willing to do an enormous amount of work, announcements that something is available will not tell me enough about the software to know whether I want it or not. So I'll ask for it, and so will others. The moderator will see a lot of requests and post it. No net decrease in postings. Of course, there is the objection that such posts are not source code. While there has been source code posted to the group (and it is instructive if not actually useful), transportability and frequent lack of the actual source make an encoded executable the most practicle thing to post in many cases. Keep in mind this group is for a one-lung micro, not a good-sized mini. 3. I don't buy the shareware concern. I've never seen a posting or a shareware program that said, in effect, "If I don't make money from this I'll never make something shareware again!". I don't think shareware is intended to make money for the author, but is intended to (a) defray part of the cost involved and/or (b) guage acceptance of the program by counting how many people pay for it. And, as has been pointed out, many (if not most) of the posts to sources.mac are items gotten from CompuServe or some other network/bulletin board, and passed on to USENET readers in the true spirit of free- or share-ware (unlimited distribution to potential users). These posters have nothing at all to gain by passing these items on to the rest of us, and to deny all of us this method of sharing would be a great loss. Well, for what it's worth, I said my two bits. If it must be, I could live with a mod group (heck, since I'm freeloading, I can LIVE with anything). However, if someone (backbone admins?) makes this change, I suggest they and the moderator of the group closely watch the before-and-after-moderation traffic, and consider switching back to an unmoderated group if there is not a significant decrease in traffic. -- Andy Hogan Rosemount, Inc. Mpls MN path: ...ihnp4!stolaf!umn-cs!mmm!rosevax!hogan Working is not a synonym for Quality.
dww@stl.UUCP (David Wright) (11/09/85)
You might like to know that a particular (and to most people obscure) posting in net.sources.mac was so useful in one of our projects that I've been using it ever since as a justification to my management for our connection to the news net - and what's more they accept the argument. So I don't mind if you change names but please don't rm the group!
peter@graffiti.UUCP (Peter da Silva) (11/11/85)
> objection that such posts are not source code. While there has been source > code posted to the group (and it is instructive if not actually useful), > transportability and frequent lack of the actual source make an encoded > executable the most practicle thing to post in many cases. Keep in mind > this group is for a one-lung micro, not a good-sized mini. I don't buy this. The IBM-PC is certainly no more of a computer (less of a micro) than the Mac, and there have been plenty of excellent sources in Turbo Pascal, 'C', and even Basic posted for it. There have also been a few binaries (ced.com.uu springs to mind), but at least the binaries have been uuencoded and uuencode source for UNIX has been posted to net.sources. If the IBM-PC can do it, why *NOT* the Mac? -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
jimb@amdcad.UUCP (Jim Budler) (11/12/85)
In article <434@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: > >I don't buy this. The IBM-PC is certainly no more of a computer (less of a >micro) than the Mac, and there have been plenty of excellent sources in >Turbo Pascal, 'C', and even Basic posted for it. There have also been a >few binaries (ced.com.uu springs to mind), but at least the binaries have >been uuencoded and uuencode source for UNIX has been posted to net.sources. >If the IBM-PC can do it, why *NOT* the Mac? I don't understand this. What is the importance of uuencode in the discussion. Binhex is used for the mac, and an excellent decoder of binhex was posted to the net. (xbin). In source. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 Bogus newsgroup: net.news: Move to end of .newsrc[yn^L]? Don't be dictators, use thought.
peter@graffiti.UUCP (Peter da Silva) (11/16/85)
> >I don't buy this. The IBM-PC is certainly no more of a computer (less of a > >micro) than the Mac, and there have been plenty of excellent sources in > >... > >If the IBM-PC can do it, why *NOT* the Mac? > > I don't understand this. What is the importance of uuencode in the discussion. > Binhex is used for the mac, and an excellent decoder of binhex was posted > to the net. (xbin). In source. It's not very important... but it *is* supposed to be the standard binary transfer program for mail and news. It's not that big a deal, though I would prefer to be able to do *something* with this code. The important point is that if you can post IBM-PC sources to the net, why can't you do the same for Macintosh sources? -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
tdn@spice.cs.cmu.edu (Thomas Newton) (11/20/85)
>> I don't understand this. What is the importance of uuencode in the >> discussion. Binhex is used for the mac, and an excellent decoder of >> binhex was posted to the net. (xbin). In source. > It's not very important... but it *is* supposed to be the standard binary > transfer program for mail and news. It's not that big a deal, though I would > prefer to be able to do *something* with this code. Macintosh files are slightly different from files on most other machines . . . they may contain both a data fork and a resource fork. Sending an arbitrary Mac file using uuencode would require posting *two* binaries, and would have the disadvantages that: (a) there might be more requests for reposts (if the two forks were sent in separate messages) (b) downloading programs from the net would require the ability to do 8-bit binary transfers (currently, BinHexed files can be converted back to a set of binary files on a Unix machine for downloading using MacTerminal, etc. OR can be downloaded to a Mac as a text file and decoded there using BinHex) I don't see why you should have any more problems decoding a BinHex file on your Unix machine than you would have decoding a uuencode file. In case you missed the point of the original message, xbin is a program *that runs under Unix* and that can decode BinHex files into their separate binary forks. > The important point is > that if you can post IBM-PC sources to the net, why can't you do the same for > Macintosh sources? Some Macintosh sources have been posted. But the enormous number of different Macintosh development systems coupled with the fact that there's no "official" native development system for anything other than assembly language means that unless a program's binaries are posted, many of the readers of net.sources.mac will be unable to use it. I think that with a few exceptions, the most useful way to make programs, etc. available on net.sources.mac is to post both source and binary form. Two exceptions: 1) Fonts and other resources which are usually created in binary form 2) Macintosh versions of large programs for which source has been made available at some previous date. In this case, it's appropriate to post the binary version of the program and perhaps the Mac-specific sources. The example which I'm thinking of is Kermit; if there was a Macintosh version of hack, it would also fall under this category. Note also that MacWrite documents are often sent in BinHex form to preserve formatting information; this *is* "source" as far as Mac users are concerned although it is the equivalent of "binaries" for everyone else. -- Thomas Newton Thomas.Newton@spice.cs.cmu.edu ..!seismo!spice.cs.cmu.edu!tdn
wls@astrovax.UUCP (William L. Sebok) (11/22/85)
>> I don't understand this. What is the importance of uuencode in the >> discussion. Binhex is used for the mac, and an excellent decoder of >> binhex was posted to the net. (xbin). In source. > > It's not very important... but it *is* supposed to be the standard binary > transfer program for mail and news. It's not that big a deal, though I would > prefer to be able to do *something* with this code. The utilities btoa / atob recently distributed in mod.sources with compress 4.0 produce more efficient encoding than uuencode / uudecode, using 85 of the printable characters rather than 64. I hope that these programs begin to displace uuencode/uudecode and begin to be more universally available at sites to which I might want to send things. And, of course, the combination of compress and btoa is hard to beat for sending text (and often even for binaries). -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls
peter@graffiti.UUCP (Peter da Silva) (11/23/85)
> I don't see why you should have any more problems decoding a BinHex file on > your Unix machine than you would have decoding a uuencode file. In case you > missed the point of the original message, xbin is a program *that runs under > Unix* and that can decode BinHex files into their separate binary forks. Except that I never bothered to get xbin because I never expected to want to use it. Oh, forget it. Like I said before, it's a *minor point*. The major point follows: > > The important point is > > that if you can post IBM-PC sources to the net, why can't you do the same for > > Macintosh sources? > > Some Macintosh sources have been posted. But the enormous number of different > Macintosh development systems coupled with the fact that there's no "official" > native development system for anything other than assembly language means that You mean there is an official native development system for the IBM-PC for anything other than assembly language? I've seen programs for the PC in various flavors of 'C', Turbo pascal, Xlisp, Forth, and even Basic. I have seen one uuencoded program that was only available in that form (ced), and one uuencoded program for which the source was avalable (shell). I have converted IBM-PC programs in several flavors of 'C' to run under UNIX. The only sources I've seen on the mac were both in 'C': one was a skeleton for doing various window stuff and the other was a window manager to let the Mac act like a Blit. Do Macintosh people ever write programs that do anything, or do they just play with their windows all day? -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
allbery@ncoast.UUCP (Brandon S. Allbery) (11/24/85)
> > I don't understand this. What is the importance of uuencode in the discussion. > > Binhex is used for the mac, and an excellent decoder of binhex was posted > > to the net. (xbin). In source. > > It's not very important... but it *is* supposed to be the standard binary > transfer program for mail and news. It's not that big a deal, though I would Wonderful. What good is a standard that's unavailable to half the net??? uu{en,de}code comes with 4.2 UUCP. Not System {III,V}. Not V[67]. Not [XV]enix. So it MUST be a standard. AAUGH! On the other hand, BinHex is posted every so often, IN SOURCE, to net.sources.mac, so it's always easy to find. If this IBM-PC mod group goes through I'll be glad to provide a binary-to-ASCII program in BASICA; I can't help Xenix PCers, unless they get MBasic in Xenix (if they get C I'm sure I can post a C version as well). --Brandon -- "This civilization, too, must be allowed to fall..." Brandon S. Allbery ncoast!allbery@Case.CSNet (ncoast!allbery%Case.CSNet@CSNet-Relay.ARPA) ..decvax!cwruecmp!ncoast!bsa -- maybe ..genrad!mit-eddie!futura!ncoast!allbery 6615 Center St., Mentor, OH 44060 (I moved) --Phone: +01 216 974 9210 CIS 74106,1032 -- MCI MAIL BALLBERY (WARNING: I am only a part-time denizen...) ncoast is dead, long live ncoast!
rec@mplvax.UUCP (Richard Currier) (11/26/85)
In article <463@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: > >Do Macintosh people ever write programs that do anything, or do they just play >with their windows all day? >-- >Name: Peter da Silva >Graphic: `-_-' >UUCP: ...!shell!{graffiti,baylor}!peter >IAEF: ...!kitty!baylor!peter > What is this venomous insulting posting doing in this group? There are Unix professionals out there making good use of the information passed in the Mac groups. If you don't understand what is going on, remove the groups from your site. Why is this group filling up with adolescent flameage? This is the one group where one should find intelligent, polite discussion about the makeup of the net. -- richard currier marine physical lab u.c. san diego {ihnp4|decvax|akgua|dcdwest|ucbvax} !sdcsvax!mplvax!rec
76645572@sdcc13.UUCP ({|lit}) (11/27/85)
There have been lots of postings saying that we should send only source code, since the name of the group is net.SOURCES.mac, or saying that we should post only binary files, since they are shorter. The unfortunate truth is that we need both source and binary files, since each serves a different purpose. This may sound strange, since source and object are two representations of the same thing, but most of us can't convert between them easily, like some of the UNIX-heads assume we can. Source code would suffice if we all had the same compiler. But there are 6 C compilers, soon to be 3 Pascal compilers, Forth, Lisp, Modula, and who knows what else. Obviously there is no standard language. This is not to say that source code is not useful, it is very useful. It provides good examples to many people, and can often be modified to work on their own compiler. But distributing source code is, for the most part, distributing examples of how to code. Most people will be unable to produce executable code from a source file. This is why we also need to send binary versions of the programs. Also, many times the source to a useful program is unavailable. Since we do have a problem with the amount of stuff being posted, we do need to set up some restrictions. Hopefully voluntary restrictions will be enough. Maybe something as simple as: Don't post stuff that really isn't useful. However, I have few qualms about most of the stuff that has been posted recently, I have found much of it useful. The answer my be in mod.sources.mac. But it is certainly not in arbitrarily prohibiting either binary files or source files. David Shayer, UCSD