mende@aim.rutgers.edu (04/10/86)
From: "Bob Mende [NB]" <mende@aim.rutgers.edu>
In responce to the idea that sources should be sent in encoded form,
I make a plea that this should *not* be so. I am using a VAX running
VMS 4.3 *not* Unix. I dont those people who are not on unix machines
dont have the standard encode.decode routines. Also, when you post to
net. micro.amiga it is also cross posted to the arpanet info-amiga.
So even though you post to the usenet news it goes to many non-usenet
sites. I make a plea that no one starts a trend of posting encoded or
compiled versions of programs. Also, I dont know if this has been done,
but some type of standard binary encoder should be accepted so IFF type
binarys can be posted and used by everyone.
Bob Mende
Snail: BPO 20187 ARPA : MENDE@AIM.RUTGERS.EDU
Piscataway NJ UUCP : seismo!topaz!aim!mende
08854 Phone: (201) 878-0602
CMS : microlab!mende
_____________________________________________________________________________
[ I hereby disclaim that I exist and therefore proclam by default that the ]
[ proceding drivel is no more than a figment of your imagination ]
-----------------------------------------------------------------------------
------kim@mips.UUCP (Kim DeVaughn) (04/12/86)
> In responce to the idea that sources should be sent in encoded form, > I make a plea that this should *not* be so. > ..... > Bob Mende This is a "me too" vote in favor of NOT encoding sources (or posting binaries) to net.micro.amiga. Thus far, only human readable sources have been posted here, which have been of benifit to many people (both Amiga and non-Amiga owners). I feel it would be most unfortunate if this were to change, and this news.group were to end up like net/mod.mac... or net.atari16 where all you see is BinHex or uuencoded stuff posted. I'm sure there is alot of good stuff posted in these groups, but it is of no value (to me) since I don't have the time to "decode" it all and see what it is. /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 408-720-1700 x231 USPS: MIPS Computer Systems Inc, 930 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
rb@ccird2.UUCP (Rex Ballard) (04/15/86)
There have been several public domain versions of uuencode and uudecode posted to net.micro, net.micro.atari and (I believe) net.sources. This is the preferred format for exchanging atari binaries because they can be converted on the unix host or on the micro itself. Now that landon dyer has been so kind as to submit an atari->amiga translator, there are a number of atari binaries already available that could be used on the amiga. All you need is the above mentioned uudecode.
david@ukma.UUCP (David Herron, NPR Lover) (04/16/86)
Oh come on! Don't whine about not having a uu{en,de}code gadget
or something similar! Public domain versions of all those programs
are easily available and can be made available again!
If nobody else has those thingies I have copies here and can post
them or whatever given enough demand.
--
David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@uky.csnetkeithe@tekgvs.UUCP (04/17/86)
In article <436@mips.UUCP> kim@mips.UUCP (Kim DeVaughn) writes: >> In responce to the idea that sources should be sent in encoded form, >> I make a plea that this should *not* be so. >> ..... > >This is a "me too" vote in favor of NOT encoding sources (or posting >binaries) to net.micro.amiga. > ... >I'm sure there is alot of good stuff posted in these groups, but it is >of no value (to me) since I don't have the time to "decode" it all >and see what it is. > >/kim Well, excuuuuuuuuuse ME! So, since you don't have the time to decode the stuff and look at it the rest of us should be deprived of having some potentially neat stuff to play with on our Amigas. Well, who died and left YOU king, anyway?!?! Folks, if you've written some good stuff and want to post the uuencoded binary to it, do so by all means! My guess is that for evey one of the people who don't want it there are lots of us who *do* want it, and we'll be happy with the binary form if that's all you want to divulge. (Note: of course I'd rather have the source, but with the Amiga and the various incompatible C compilers, the source may not be of much use anyway! :-) ) keith Keith Ericson at TekLabs (resident factious factotum) Tektronix, PO 500, MS 58-383 Beaverton OR 97077 (503)627-6042 uucp: [ucbvax|decvax|ihnp4|hplabs|(and_many_others)]!tektronix!tekgvs!keithe CSnet: keithe%tekgvs@tektronix ARPAnet: keithe%tekgvs%tektronix@csnet-relay
mykes@3comvax.UUCP (Mike Schwartz) (04/18/86)
In article <760@ccird2.UUCP> rb@ccird2.UUCP (Rex Ballard) writes: >There have been several public domain versions of uuencode and >uudecode posted to net.micro, net.micro.atari and (I believe) >net.sources. This is the preferred format for exchanging >atari binaries because they can be converted on the unix host >or on the micro itself. > >Now that landon dyer has been so kind as to submit an atari->amiga >translator, there are a number of atari binaries already available >that could be used on the amiga. All you need is the above mentioned >uudecode. I realize that both the ST and the Amiga use 68000 processoros, but I find it hard to believe that ST binaries will run on the Amiga. The operating systems are real different, and the Amiga hardware does things in a much different way than the ST. Landon Dyer's atari->amiga translator is great if you are writing code for the ST, using the Amiga to edit and compile. I saved away the Atari-Amiga translator, but have not unpacked it yet. I figure it might be a uuencoded program to erase my floppies or something (read net.sources.d for more related topics).
dyer@atari.UUcp (Landon Dyer) (04/20/86)
> >Now that landon dyer has been so kind as to submit an atari->amiga > >translator, there are a number of atari binaries already available > >that could be used on the amiga. All you need is the above mentioned > >uudecode. > > I saved away the Atari-Amiga translator, but have not unpacked it yet. I > figure it might be a uuencoded program to erase my floppies or something > (read net.sources.d for more related topics). HOLD ON! STOP! The translator I posted to net.micro.amiga translates AMIGA binary files to the ST binary file format. Amiga-->ST. Got it? In addition, the translator is meant only for developers who specifically have written code for the ST. You cannot translate any random binary file you have sitting around on one of your Amiga disks. You have to make ST VDI calls, and so on. The purpose of the translator was to give Amiga developers the opportunity to write programs for the ST, using the Lattice C enviroment on the IBM-PC version of the Amiga development system. (The source for the translator was recently posted. And the uuencoded executable translator -- which runs ONLY under MSDOS -- is certainly NOT a floppy disk or hard disk formatter program, but I appreciate your caution!) Hope this cleared up the confusion. -- -Landon "If Business is War, then I'm a Prisoner of Business!" ... {hoptoad, lll-crg!vecpyr}!atari!dyer "Quantity is Quality"
local-info-amiga-request@ics.UCI.EDU (04/22/86)
From: "David Herron, NPR Lover" <ukma!david@caip.rutgers.edu>
Oh come on! Don't whine about not having a uu{en,de}code gadget
or something similar! Public domain versions of all those programs
are easily available and can be made available again!
If nobody else has those thingies I have copies here and can post
them or whatever given enough demand.
--
David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@uky.csnetlocal-info-amiga-request@ics.UCI.EDU (04/22/86)
From: Mike Schwartz <3comvax!mykes@caip.rutgers.edu> In article <760@ccird2.UUCP> rb@ccird2.UUCP (Rex Ballard) writes: >There have been several public domain versions of uuencode and >uudecode posted to net.micro, net.micro.atari and (I believe) >net.sources. This is the preferred format for exchanging >atari binaries because they can be converted on the unix host >or on the micro itself. > >Now that landon dyer has been so kind as to submit an atari->amiga >translator, there are a number of atari binaries already available >that could be used on the amiga. All you need is the above mentioned >uudecode. I realize that both the ST and the Amiga use 68000 processoros, but I find it hard to believe that ST binaries will run on the Amiga. The operating systems are real different, and the Amiga hardware does things in a much different way than the ST. Landon Dyer's atari->amiga translator is great if you are writing code for the ST, using the Amiga to edit and compile. I saved away the Atari-Amiga translator, but have not unpacked it yet. I figure it might be a uuencoded program to erase my floppies or something (read net.sources.d for more related topics).
rb@ccird2.UUCP (Rex Ballard) (04/23/86)
Generally, encoding is done on the other groups net.micro.{mac,atari16}
for good reasons.
Encoded source is usually compressed and encrypted in order to save
space and modem time of sending text across the net. This can be
a serious problem when extra large files come across the net and
have do be distributed to hundreds of sites.
Encoded binaries are usually used for things such as compilers and
languages, where the source is useless without the binary. A good
example is the various forths that have binary "kernals". These
are often followed by "forth in forth" files that allow the reciever
to modify and learn from the sources written for that binary.
Often, a binary is sent along with instructions on where to get the
"FTP sources" from. This is useful when there are hundreds of small
files, include files, and utilities that comprise the "source". Many
public domain projects and GNU (Copyrighted, but freely available)
projects involve as many as 4 megabytes.
When projects are "trivial", one or two messages worth of source, there
is little problem with distributing sources directly on the net. When
a project is more substantial, 17 parts each about 64K, net
adminestrators tend to get a bit upset about the cost of sending these
all over the country. The cost to the network is about $2/K. There
are a few PD projects that can run 4 to 6 parts of uuencoded binary.
This would translate to about 4 meg of source. The cost of sending
that much source to all of the net sites would be around $8,000. An
ftp might only cost $20, less if the site is in the same phone area.
Other less valid reasons include posting of "shareware", "beta-copies",
and "preview copies" of products which will be eventually marketed
as commercial products. Examples of this include Apple's "Switcher",
Finder upgrades, and various upgrades that might otherwise be available
"over the counter", but are "given" to the net by the copyright owner
with the understanding that the owner shouldn't be expected to give
the usual support.
Another semi-valid reason is when someone uses a non-standard or
very expensive compiler to generate the code. In this case, if the
language used is strange, or the compiler supports certain
"non-standard" features such as in-line assembly code, passing of
structures by value, et. al., it is often preferred to send the
binary rather than the "funny source". For example, source written
in lex/yacc or Objective C would be useless if all that was available
was Lattice C.
The worst reason is to distribute "worms", or "pirated copies" of
software. Unfortunately, this sometimes happens, and there is
little that can be done about it. If someone does this, flame them
via mail and via follow-up. In some cases, these "hackers" are using
someone elses account, but at least somebody will know.
Now, assuming that the distribution of binaries is justified for these
"special cases", what are the requirements for encoding?
First, the character set must be limited to the "graphic" characters
of the ASCII character set. This is because modems, link protocols,
and communication media across the net are very "fussy" about recieving
certain control characters, many of which will be "dropped" or goof
up the link. Also, some links drop the "8th bit", so seven bits
is all thats safe.
Second, the encryption should pack as much information as possible
into available character set. This is because more wasteful protocols
such as intel hex format tend to require more space. These protocols
also have error detection which is already included in the net
protocol. Remember, encoded binaries are intended to save space.
Third, the encryption should be simple to implement, and should be
machine independent. The code to encode/decode should be runnable
on either the environment used to read the news, or on the micro
on which the binary will be used. This way, the binary can be
decoded and the binary transferred via XMODEM or KERMIT, or any
other "file transfer service" available on the News feeder, but
if not available, the encoded file can be simply "captured" and
decoded on the micro.
As was mentioned before, public domain versions of uuencode and
uudecode have been posted to net.micro net.micro.atari and net.sources.
This protocol meets all three of the above requirements. In addition,
the uuencode/uudecode supplied with UNIX work equally well on these
files.
One variation on this protocol which is a little dubious is using
the "compress" function to further reduce the size of the file.
Although this reduces the size of the files, a good "standard" hasn't
been adopted yet.
The mac group adopted binhex and apearantly use it quite effectively.
I don't know that much about this service other than that it works
for them.mjg@ecsvax.UUCP (Michael Gingell) (04/23/86)
Why does everyone persist in talking about encoded SOURCE files???? I thought they were meant to be read. If all that is available is the object code then by all means encode it for posting however I think it would be nice to post both a) to give those that want to learn the chance to do so by example and b) to run the object code if they don't have the means or the ability to compile it themselves. Mike Gingell ...decvax!mcnc!ecsvax!mjg
savage%topaz@topaz.UUCP (04/27/86)
In article <45100037@infoswx>, bees@infoswx.UUCP writes: ... > > I agree with Keith. There are many reasons for posting binaries. Yes, > I'd rather have the source, but given the choice between binary or nothing, > I'd rather have the binary! For instance, if I am working on something > that I want y'all to try out, I might want to post the binary because: > a) It will be in Manx Aztec C and you not only may not have this, > but you may not have my bug fixes to some of the libraries. > b) I may still be working on it, and don't want anyone to muck > with it until I'm done. > c) I might want to sell it someday, and/or I might want to keep > my software techniques private. > ... > > Discussion? (not too much I hope, we could banter about forever). > > Ray Davis > Teknekron Infoswitch, Richardson, TX > infoswx!bees, (214)644-0570 Alright, I second that!!! Let's allow encoded binaries for the above reasons. Like he said, having something (binary, no source) is better than having nothing at all (no binary, no source). Also, uuencode/uudecode & btoa/atob sounds like a pretty good combination to me for transferring the binaries... Come on, let's allow it now, or we'll still be here a year from now fighting over what is right! If you don't want to "see" uuencoded binaries than just don't read them... Ed Savage