sending source code
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!udel!mmdf
From: BECKER%HUMBER.BIT...@wiscvm.wisc.edu (Bruce Becker)
Newsgroups: comp.os.minix
Subject: Re: sending source code
Message-ID: <631@louie.udel.EDU>
Date: Sun, 25-Oct-87 20:40:45 EST
Article-I.D.: louie.631
Posted: Sun Oct 25 20:40:45 1987
Date-Received: Tue, 27-Oct-87 05:42:21 EST
Sender: m...@udel.EDU
Lines: 27
1). current versions of uuencode substitute '`' (accent) for " " (space)
in order to deal with problems of blank-stripping - it should not actually
matter for "EOL" strippers, but multiple-blank-collapsers would cause
problems...
2). For every compression method you or I could come up with, there are always
a dozen "better" ones that we never heard of, or don't have a way to
implement, etc...
3). The problem decomposes into about 3 levels - a). archiving like "arc" or
"tar"; b). compression for efficiency; c). transmission media transparency.
So - use "tar" & "compress" to handle a). & b)., AND port "arc" to satisfy
the "BBS" world; c). is solved apprpriately to the transmission system -
x/y-modem, uuencode, etc. The problem with EBCDIC is not serious for
uuencoded files - a simple "ascii-to-Ebcdic" filter is required if not
already provided by the transmission services. Any translation
peculiarities are then resolved in the local version of uuencode/decode...
4). The "gist" of what i'm saying is - please try to build on the existing
universe of utilities as much as you can - that way the "UNix-ness" is
most fully accounted for... Some may say that MINIX now provides the chance
to redo that which Unix tried poorly at - perhaps what you propose falls
into such a category, but I'd like to see more analysis as to what needs
improvement/replacement, etc...
5). So this is an invitation for discussion about the "growth" & enhancement
of MINIX - are my concerns to "bureaucratic", or is such caution useful?
Ken's in the process of putting out something that's going to be a fair
amount of work - I hope he can get as much advice as possible up front...
Cheers, BBecker Humber College Etobicoke, Ont.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!unisoft!
hoptoad!gnu
From: g...@hoptoad.uucp (John Gilmore)
Newsgroups: comp.os.minix,comp.protocols.ibm
Subject: Re: sending source code
Message-ID: <3265@hoptoad.uucp>
Date: Mon, 26-Oct-87 23:33:36 EST
Article-I.D.: hoptoad.3265
Posted: Mon Oct 26 23:33:36 1987
Date-Received: Thu, 29-Oct-87 20:25:51 EST
References: <631@louie.udel.EDU>
Organization: Nebula Consultants in San Francisco
Lines: 32
There seems to be a fuss about sending Minix code around. The rest of
the newsgroups seem to be able to send code up down back and forth
without losing it, what's the problem here?
I hear that there are problems with bitnet screwing up messages. It seems
like comp.os.minix is NOT the place to solve these problems. If your site
is getting mangled netnews from a bitnet neighbor, why don't you arrange
with the neighbor to put in a real live transparent link, e.g. by uuencoding
each message or batch that traverses the link and de-encoding it on your end?
If uuencode is not enough to keep it transparent, write a bitnetencode or
something. Plenty of netnews sites that don't have uucp or tcp do this.
Various people have flamed the bitnetfolks for using IBM equipment; the
real problem is that they are using IBM software. They could get UTS
from Amdahl instead and have real Unix and real netnews (running under
VM if they still need to run the crud too). More to the point, they
could patch up the worst of the botches in the IBM software (e.g. write
an ascii-with-newlines file access method, and use it) rather than
trying to get the rest of the world to change. This is not a major
challenge; I know somebody who wrote an OS/MVT access method for
getting at APL file-system files, which are FAR more alien than ascii
text files!
As I understand bitnet it's all leased lines between prearranged hosts,
kind of like usenet is all dialup lines between prearranged hosts. If
you produced some simple software that made the links transparent to
arbitrary binary data, it seems like it would spread like wildfire to
the rest of bitnet, and much of the problem would be over.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvania
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!jade!ucbcad!
ames!ll-xn!mit-eddie!uw-beaver!ssc-vax!uvicctr!sbanner1
From: sbann...@uvicctr.UUCP (S. John Banner)
Newsgroups: comp.os.minix
Subject: Re: sending source code
Message-ID: <332@uvicctr.UUCP>
Date: Tue, 27-Oct-87 16:37:40 EST
Article-I.D.: uvicctr.332
Posted: Tue Oct 27 16:37:40 1987
Date-Received: Wed, 4-Nov-87 05:21:23 EST
References: <631@louie.udel.EDU>
Reply-To: sbann...@uvicctr.UUCP (S. John Banner)
Organization: University of Victoria, Victoria B.C. Canada
Lines: 37
In article <6...@louie.udel.EDU> BECKER%HUMBER.BIT...@wiscvm.wisc.edu
(Bruce Becker) writes:
>3). The problem decomposes into about 3 levels - a). archiving like "arc" or
> "tar"; b). compression for efficiency; c). transmission media transparency.
> So - use "tar" & "compress" to handle a). & b)., AND port "arc" to satisfy
> the "BBS" world; c). is solved apprpriately to the transmission system -
> x/y-modem, uuencode, etc. The problem with EBCDIC is not serious for
> uuencoded files - a simple "ascii-to-Ebcdic" filter is required if not
> already provided by the transmission services. Any translation
> peculiarities are then resolved in the local version of uuencode/decode...
>4). The "gist" of what i'm saying is - please try to build on the existing
> universe of utilities as much as you can - that way the "UNix-ness" is
>Cheers, BBecker Humber College Etobicoke, Ont.
I must agree with what you are saying, but might I suggest that instead
of using tar/compress/arc combinations, that we adopt the 'zoo' program
that was distributed on the net a few months ago. It gives the utility
of tar (ie, archiving directory structures, etc), with the data
compression of arc (actually, in my experiance it tends to be slightly
worse than arc, but only by about 2-5 percent, and given the added
functionality, I think that that is well worth it), PLUS there are
currently versions available for quite a varietly of machines, AND THEY
ALL HAVE THE SAME INTERFACE. I think that if we have to set some sort
of a standard for this (and I think that we will have do deal with this
problem sooner or later), the combination of zoo, and uuencode is
probably the way to go.
Well, so much for my two cents, if you don't like it, feel free to
propose other solutions (preferably with reasons :-), I am open to
whatever will get the job done in the best manner for the most people.
S. John Banner
...!uw-beaver!uvicctr!sol!sbanner1
...!ubc-vision!uvicctr!sol!sbanner1
ccsjb@uvvm
sbann...@sol.UVIC.CDN
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!
bellcore!faline!ulysses!mhuxt!ihnp4!occrsh!uokmax!rmtodd
From: rmt...@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.os.minix
Subject: Re: sending source code
Message-ID: <820@uokmax.UUCP>
Date: Mon, 2-Nov-87 14:16:13 EST
Article-I.D.: uokmax.820
Posted: Mon Nov 2 14:16:13 1987
Date-Received: Fri, 6-Nov-87 23:15:44 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP>
Reply-To: rmt...@uokmax.UUCP (Richard Michael Todd)
Organization: University of Oklahoma, Norman
Lines: 27
In article <3...@uvicctr.UUCP> sbann...@uvicctr.UUCP (S. John Banner) writes:
>I must agree with what you are saying, but might I suggest that instead
>of using tar/compress/arc combinations, that we adopt the 'zoo' program
>that was distributed on the net a few months ago. It gives the utility
>of tar (ie, archiving directory structures, etc), with the data
....
>ALL HAVE THE SAME INTERFACE. I think that if we have to set some sort
>of a standard for this (and I think that we will have do deal with this
>problem sooner or later), the combination of zoo, and uuencode is
>probably the way to go.
I agree with you about the usefulness of Zoo. I use it all the time to
transport files from this machine, an Encore Multimax, to my PC. The source
for Zoo compiled and ran first time on the Multimax, which is more than I can
say for many other programs from the net.
There is, however, a problem with using it on MINIX. Some time ago I
corresponded with Rahul Dhesi about porting Zoo to MINIX, and he told me
that it won't fit in 64Kcode-64Kdata systems. Considering that a full
13-bit LZW compression table takes around 50K, this isn't too surprising.
So, Zoo won't fit on MINIX. However, the 'booz' (I believe that's its
name) simplified extract-only program probably will work on MINIX; in fact, it
was designed to be portable to limited-memory systems. So, though you
won't be able to create Zoo archives on MINIX, it will be possible to
extract them on MINIX. Ain't great, but better than nothing.
--------------------------------------------------------------------------
Richard Todd "MSDOS: Just Say No"
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ur-tut!ur-cvsvax!srs!dan
From: d...@srs.UUCP (Dan Kegel)
Newsgroups: comp.sources.bugs,news.misc
Subject: Re: sending source code
Message-ID: <467@srs.UUCP>
Date: Thu, 5-Nov-87 09:06:14 EST
Article-I.D.: srs.467
Posted: Thu Nov 5 09:06:14 1987
Date-Received: Sun, 8-Nov-87 15:53:03 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP> <2566@umn-cs.UUCP>
Organization: S.R.Systems
Lines: 18
Roughly paraphrased:
> It is desireable to use a compressing archiver (like zoo or arc)
> to package groups of files for transmission.
> However, the resulting archives must be uuencoded (or btoa'd) before
> transmission on Usenet.
> Why not just make the compressing archiver output in a format
> suitable for direct transmission on Usenet?
Sounds like a good idea to me. I've always disliked having to go
thru three steps (paste, uudecode, unarchive) to decode these postings;
it's work I'd just as soon have a program do for me.
I think that more thought needs to be given to transmitting large
binary files over Usenet. People often distribute documentation and
source in this format, so the old objection "But executables don't belong
on Usenet" no longer applies.
- Dan Kegel
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!ut-sally!ut-ngp!auscso!48color!paddock
From: padd...@48color.UUCP (Steve Paddock)
Newsgroups: comp.sources.bugs,news.misc
Subject: Re: sending source code
Message-ID: <49@48color.UUCP>
Date: Sat, 7-Nov-87 11:23:06 EST
Article-I.D.: 48color.49
Posted: Sat Nov 7 11:23:06 1987
Date-Received: Tue, 10-Nov-87 04:21:31 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP> <2566@umn-cs.UUCP> <467@srs.UUCP>
Reply-To: padd...@48color.UUCP (pri=-0-Steve Paddock)
Organization: Best Printing Co., Austin, Tx.
Lines: 20
In article <4...@srs.UUCP> d...@srs.UUCP (Dan Kegel) writes:
>I think that more thought needs to be given to transmitting large
>binary files over Usenet. People often distribute documentation and
>source in this format, so the old objection "But executables don't belong
>on Usenet" no longer applies.
I've given it some thought. The thought is that every time I see one
I hit the n(ext) key.
Take a look at the news documentation. Most unix sites send compressed
news batches. This means that the savings I infer you want are
already transparently being achieved. In fact, a uuencoded binary
compresses very little compared to source.
Finally, I challenge, but will not debate, your logic regarding the
posting of binaries. See the archives for a full discussion.
--
Steve Paddock (ut-ngp!auscso!mybest!paddock) 512-477-9736
Best Printing Co, Austin, Texas 78767
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!woods
From: wo...@hao.UCAR.EDU (Greg Woods)
Newsgroups: comp.sources.bugs,news.misc
Subject: Re: sending source code
Message-ID: <939@hao.UCAR.EDU>
Date: Tue, 10-Nov-87 23:33:50 EST
Article-I.D.: hao.939
Posted: Tue Nov 10 23:33:50 1987
Date-Received: Fri, 13-Nov-87 05:17:51 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP> <2566@umn-cs.UUCP>
<467@srs.UUCP> <49@48color.UUCP>
Reply-To: wo...@hao.UUCP (Greg Woods)
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 30
Summary: DON'T DO IT, PLEASE!!
In article <4...@48color.UUCP> padd...@48color.UUCP (pri=-0-Steve Paddock) writes:
>In article <4...@srs.UUCP> d...@srs.UUCP (Dan Kegel) writes:
>
>>I think that more thought needs to be given to transmitting large
>>binary files over Usenet.
I think more thought needs to be given to the cost effectiveness of doing
this. Last night, our spool directory ran out of space because someone
was mailing over a megabyte of chess game sources and records of chess
games through us. Yes, we run that close to the edge. So do most other
major sites, I expect. We can't afford to let multi-megabytes of disk
space sit idle most of the time just to handle the occasional large mailing.
I suggest that it is more reliable and more cost efficient to send mag
tapes via traditional shipping methods. That way, those who benefit
from the transmission pay the cost of it instead of us.
In my view, there are two legitimate uses of the generosity of sites
like ours that transmit things freely for everyone: things that a large
number of people can benefit from (news articles), or SHORT private
messages that won't cause our phone bills to go through the roof or
our spool directories to overflow. Please THINK about what you are
doing (or thinking of doing). It is a BAD IDEA to encourage the mailing
of large sources. I wish uuencode had never been written.
PLEASE DON'T MAIL SOURCES OVER THE NET!!!
Thanks,
--Greg
--
UUCP: {husc6, gatech, oddjob, ames, noao, rutgers}!hao!woods
CSNET: wo...@ncar.csnet INTERNET: wo...@hao.ucar.edu
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nuchat!splut!jay
From: j...@splut.UUCP (Jay Maynard)
Newsgroups: comp.sources.d
Subject: Re: sending source code
Message-ID: <244@splut.UUCP>
Date: Sat, 14-Nov-87 13:31:34 EST
Article-I.D.: splut.244
Posted: Sat Nov 14 13:31:34 1987
Date-Received: Sun, 15-Nov-87 20:04:30 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP> <2566@umn-cs.UUCP>
<939@hao.UCAR.EDU>
Organization: Confederate Microsystems, League City, TX
Lines: 22
Summary: Only one problem, Greg...
In article <9...@hao.UCAR.EDU>, wo...@hao.UCAR.EDU (Greg Woods) writes:
> I suggest that it is more reliable and more cost efficient to send mag
> tapes via traditional shipping methods. That way, those who benefit
> from the transmission pay the cost of it instead of us.
There's only one problem with this, Greg: I can't stuff a DC2000, or a
9-track tape, into the 5-1/4 inch drive that represents the only removable
mass storage on my system. I'd be happy to pay for someone to send me a
stack of floppies, but there are precious few out there that can write
either 1.2 meg or 360K floppies in cpio format that my Microport system can
read that have the tape drives as well...
Don't get me wrong: I greatly appreciate the backbone's generosity. Until
wel can come up with a way to get stuff from the VAXen that some folks (not
necessarily you) think that all the world runs to the rest of the machines
in the real world, this will continue...
--
Jay Maynard, K5ZC (@WB5BBW)...>splut!< | uucp: uunet!nuchat!splut!jay
Never ascribe to malice that which can | or: academ!uhnix1!--^
adequately be explained by stupidity. | GEnie: JAYMAYNARD CI$: 71036,1603
The opinions herein are shared by none of my cats, much less anyone else.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!lll-lcc!unisoft!hoptoad!gnu
From: g...@hoptoad.uucp (John Gilmore)
Newsgroups: comp.sources.d
Subject: Re: sending source code
Message-ID: <3331@hoptoad.uucp>
Date: Mon, 16-Nov-87 01:35:54 EST
Article-I.D.: hoptoad.3331
Posted: Mon Nov 16 01:35:54 1987
Date-Received: Tue, 17-Nov-87 03:50:43 EST
References: <631@louie.udel.EDU> <332@uvicctr.UUCP> <2566@umn-cs.UUCP>
<244@splut.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 30
wo...@hao.UCAR.EDU (Greg Woods) wrote:
> I suggest that it is more reliable and more cost efficient to send mag
> tapes via traditional shipping methods. That way, those who benefit
> from the transmission pay the cost of it instead of us.
j...@splut.UUCP (Jay Maynard) wrote:
> There's only one problem with this, Greg: I can't stuff a DC2000, or a
> 9-track tape, into the 5-1/4 inch drive that represents the only removable
> mass storage on my system...
They both have valid problems. Greg has the problem that random people
are spending his modem time and disk space to get their work and play done.
Jay has the old familiar find-the-common-medium problem, exacerbated by
the IBM PC market's slowness to supply standard cartridge drives.
There is a fix for both of these problems. Jay clearly has a modem, or
he wouldn't likely be on the Usenet. The fix is for Jay to set up a
uucp link with whoever he wants to move large sources with. I do this
for people to pick up copies of the GNU C compiler occasionally, and
believe me, if somebody wants a 2 meg piece of software, they are
usually willing to go to the effort to set up a uucp link with you. If
they aren't willing, it's OK by me that they not get the software from
me; I guess they didn't want it enough..
I agree totally with Greg about sending large sources through other
peoples' machines. Set up a direct link and don't piss off the middleman!
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu g...@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvania