Martin Sckopke <X913%DMAFHT1.BITNET@cunyvm.cuny.edu> (05/02/91)
Hi netters,
I hate to bring up the subject again, but I read about it in connection
to the distribution of MINI-X. What would be so difficult about distri-
buting Minix sources as uuencoded, 13bit-compressed tar files ? I think
every version of the OS has the mentioned tools supplied and even the
people on BITnet (like me) could use them. Ok, I still got problems
with uuencoded files (a gateway changes some characters), but it's
quite easy to write a little filter for this problem. So where's the
advantage in using shar ? Sometimes unshar doesn't work, sometimes
the shell crashes while trying to unpack the sources, u can't send any
binaries and so on. So if I missed something, please inform me.
! f u cn rd ths,
Martin Sckopke (X913@DMAFHT1) ! u cn gt a gd jb
! n cmptr prgrmn.wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (05/03/91)
[Martin Sckoptke asks why some people distribute source code in "shar" as opposed to uuencode, compressed, tar files.] Well, the "default" format for distributing Unix sources on USENET has always been "shar" format. This is because ANY Unix system has a copy of a complete Bourne shell. In addition, USENET has historically been sent over ASCII only links so there were no problems with character code translations or for that matter with padding. Minix on the other hand has a somewhat less complete shell and has always had a mailing list that had to deal with code translations on BITNET. That is why Minix has had to invent a way to deal with such problems. By the way, NOT all Unix systems have uuencode or compress and I think some older versions of System V didn't even have tar. (Yes, I know the sources for uuencode and compress are freely available and versions of tar are also available. The idea is to assumme the least about the receiving system. "Shar" files can even be taken apart with a text editor if that is all you have.) USENET people used to complain about compressed archives because most UUCP based USENET links automatically compress the data before it is transferred and uncompress it for storage on disk. When a large posting which has been compressed and then expanded through uuencode is run through a second compression it usually ends up being larger then if the "raw" file had just been compressed. Minix traffic on USENET is a fraction of total traffic and you might expect those complaints to continue. With the advent of binary program groups such as comp.binaries.* and sexually explicit pictures in alt.sex.pictures, such complaints have for the most part disappeared. People moving from UNIX to Minix though might still have a tendency to use "shar" format files from force of habit. Bill Bogstad > ! f u cn rd ths, > Martin Sckopke (X913@DMAFHT1) ! u cn gt a gd jb > ! n cmptr prgrmn. Your algorithm above seems to be: 1. If a word consists of only vowels replace it with a single vowel. 2. For all other words, remove all vowels and replace all doubled consonants with a single consonant. I have a problem with the last line though. Shouldn't it be... n cmptr prgrmng i.e. in computer programming
klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/03/91)
(About distributing sources uud'ed && compressed)
The major advantage of using shar is that the sources (and documentation!)
can be read before unpacking all. This proofreading can be done in your
news reader (when you are on USENET), while for unpacking you need to
go to a shell and think. (OK, just a littlebit, but even that is very
much compared to just paging through a file -- I am very flexible in
skipping the leading X ).
But i (and i hope everybody) will send all its sources at least in uud'ed
from.
Question: small sources do i send double. Any objections/advantages seen
by any netters?
Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer