gnu@sun.uucp (John Gilmore) (08/08/84)
Recently there's been a rash of uuencoded object code in net.sources. I think this is a despicable practice, because source is not provided. One of the great things about this network is that there's a large (LARGE) variety of machines on it. Something posted in object is useful on exactly one class of machines. Furthermore, recipients can't fix bugs or make enhancements -- let alone consider porting the software to a different environment. While free object code w/o source is sometimes better than no code at all, I don't think net.sources is the right place for it. I think that posting object code without source should be discouraged, in Emily Post and by replies to people who do it. Is this the "sense of the net" or am I off in a corner? Followups to net.news only, please.
ken@turtlevax.UUCP (Ken Turkowski) (08/08/84)
Yes, let's keep this object code out of net.sources. In addition,
USENET is a connection of UNIX sites, and few sites would be interested
in CPM object code.
--
Ken Turkowski @ CADLINC, Palo Alto, CA
UUCP: {amd,decwrl,dual,flairvax,nsc}!turtlevax!ken
ARPA: decwrl!turtlevax!ken@BERKELEYbet@ecsvax.UUCP (08/09/84)
Wait, wait, wait. USENET is a network of sites running UNIX so we
aren't interested in CP/M (or MS-DOS, as has been the case) object
code? So why does net.micro.* exist? For the matter of that, if
material must relate to UNIX to be appropriate to USENET, why have
*any* of the non-technical groups? Now it may be the case that
net.sources should be named net.unix.sources, but I haven't ever heard
this claim presented before. If people are really down on distributing
uuencoded binaries through net.sources, then let's make up another
group for these things, sharing the feature of net.sources of being set
up for large files. The description I have heard for net.sources is
something like "large files, such as source code", and I have seen
other things besides source code (in particular large documents) posted
to this group.
I can't understand all the squawking. Do people have broken 'n' keys?
Or is it a new experience to find something not if interest to
*everybody* in net.sources?
Bennett Todd
...{decvax,ihnp4,akgua}!mcnc!ecsvax!betsdyer@bbncca.ARPA (Steve Dyer) (08/09/84)
>Yes, let's keep this object code out of net.sources. In >addition, USENET is a connection of UNIX sites, and few sites >would be interested in CPM object code. I really can't figure this one out, people. Small personal computers such as the IBM-PC and the Mac are becoming more and more pervasive, and although I do not own either of them (yet), if I did, I would only be too happy to receive useful programs, even if they are distributed only in binary form. My site may be a UNIX machine, but it's likely that there are many PCs where I work, and many people may also have them in their homes. The kind of argument used here could be used against people who post C-language versions of code with heavy OS-dependencies: "Hey, keep your BDS C forth interpreter out of net.sources; we UNIX types can't run it." or "Where do you get off posting that 4.2BSD-dependent program: my PDP-11 running V7 barfs when I try to compile it." But we don't say this, because we reason that the greater good of the net is served, even if an individual aite has no use for it. In any event, I would hate to think that uuencoded binaries would ever replace source-code postings where appropriate, but there are also many benefits. The typical PC environment is simply not the same as your usual UNIX system: one has a superabundance of software tools and languages, the other is as likely to run 123, a modem program and nothing else. If someone posts a source program written in what-have-you, I may not be able to use it, because I haven't shelled out $500 for the compiler. Standardized environments like the PC (or MSDOS machines) and the Mac actually make binary distribution practical and preferable, and not only a way to maintain a greedy programmer's trade secrets. -- /Steve Dyer {decvax,linus,ima}!bbncca!sdyer sdyer@bbncca.ARPA
hansen@pegasus.UUCP (Tony L. Hansen) (08/09/84)
Some time ago it was suggested that net.sources.pc be formed for the express purpose of posting sources for micro systems. It was decided at that time that doing this should be postponed until a clear need for it arised, in other words, a substantial amount of traffic began in that type of stuff in comparison with the other type of stuff that belongs in net.sources. I think that the time has come. What does everyone else think? Tony Hansen pegasus!hansen
john@genrad.UUCP (John Nelson) (08/09/84)
Nevertheless, net.sources is for SOURCES. If source is posted, it can be used on any system with an appropriate compiler, with perhaps a little diddling. I, for instance, have a TRS80 model I. (no flames please!) With source code posted in C, I can compile an appropriate program for MY system, or I can adapt a program with a good concept to my configuration. Even assembly language can be adapted (but is much harder if the base processor is different). Object code is useless for anyone who does not have the specific machine type. There are many bulletin board systems around that supply compiled versions of public domain programs for micros. Use THEM! They are a much more efficient way to distribute object code programs, because users can dial up systems that only deal in objects for THEIR system type! Posting object code to this forum subjects all of us to pass around large files that we cannot use in any way! Of course some source files are machine specific also (example: a C program to manipulate an MS-DOS directory), but sometimes such things are adaptable to other environments.
mark@cbosgd.UUCP (Mark Horton) (08/10/84)
I agree completely with Steve Dyer: just because something is in binary form is no reason not to post it. Of course, we'd prefer you post source if that's possible. Placing a binary into the public domain is kind of silly because the users are dependent upon the author for support, and the author isn't going to appreciate lots of requests for support. But if the binary is all you have, and the author doesn't mind, or the compiler is hard to come by, there's nothing wrong with posting the binary. I do caution you that only things that are of overall benefit to the net should be posted. If it's pretty obscure but very small, no problem. But I'd hate to see someone post the entire list of bets placed in last week's Ohio Lotto, which is both huge and of limited use. Mark Horton
phil@amd.UUCP (Phil Ngai) (08/10/84)
I much prefer source to binary but the program posted is one that
got a lot of interest from my users. People who use PCs don't mind
binary. It made my users happy and that's the bottom line at this
site (and hopefully at yours too).
--
amd70 is dead, tell a friend
Phil Ngai (408) 982-6554
UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!phil
ARPAnet: amd!phil@decwrl.ARPApmg@aplvax.UUCP (08/10/84)
Since object code is not of general interest it should probable be posted to a more specific group (ie. net.micro.pc ). Transfer of object code is useful when the source is unavailable, but it should only be brought to the attention of the users that can actually use it. The program in question was useful for me, and I read net.micro.pc to obtain information for my PC! Mike -- P. Michael Guba ...decvax!harpo!seismo!umcp-cs!aplvax!pmg ...rlgvax!cvl!umcp-cs!aplvax!pmg
bsa@ncoast.UUCP (The WITNESS) (08/13/84)
We already post non-Unix SOURCE code to net.sources (witness (:-) the Red
editor, Mac FILE, and others); why not object as well? I am not directly
involved in any of this (TRS-80 mod I, no RS-232) but see nothing wrong with
it. If you want to squawk, try to convince the net that net.sources should
have subgroups (good luck!).
--
Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw: R0176@CSUOHIO.BITNET
6504 Chestnut Road, Independence, OH 44131 <> (216) 524-1416
"The more they overthink the plumbin', the easier 'tis tae stop up the drain."pmg@aplvax.UUCP (08/16/84)
Net.sources.pc, an idea whose time has come! -- P. Michael Guba ...decvax!harpo!seismo!umcp-cs!aplvax!pmg ...rlgvax!cvl!umcp-cs!aplvax!pmg