boneill@swan.ulowell.edu (Brian O'Neill) (09/10/88)
Well, here's the final results:
ARC 27
PK 45
ZOO 112
BTOA-SHAR 1
TAR-COMPRESS 1
SHAR-COMPRESS 1
EARTHPIG 1 *
* Being developed
It seems ZOO has won an overwhelming victory. However, PKWare has yet to
develop the new software, and recent news could change the vote. Interpret
these results however you wish - they were simply a look into the sentiments
of the net.
Here is what most people said about each of the top three:
ARC - Standard among most services
PK - Fast
ZOO - Supports multiple operating systems without problem
- Directory structure (could improve with creating non-existent
directories
After the dust settles, and PKWare comes out with their "public-domain"
format, maybe a recount would be in order.
============================================================================
Brian O'Neill, MS-DOS Software Exchange - UUServe E-Mail Archive Server
ArpaNet: boneill@swan.ulowell.edu
UUCP : {(backbones),harvard,mit-eddie,et. al.}!ulowell!boneilltneff@dasys1.UUCP (Tom Neff) (09/14/88)
There must have been some confusion in the way the compression standard
vote was conducted. The answers as tabulated seem like nonsense. The
only existing "PK" compression [actually packaging - bundling is involved
as well as compression] standard is the ARC format. There is no such
thing as a "fast" format or a "slow" format, only fast and slow utilities
to manipulate the format. Hence the first two entries ("ARC" and "PK")
in the vote tabulation really refer to the same thing. If combined, they
still don't outpoll ZOO, so the outcome would not be affected, but I
would feel better about the poll if the results looked more sensible.
It looks awfully as though the responding users confused the choice of
extracting utility with the choice of underlying format. Only the second
issue is of importance to this debate; presumably the individual user is
welcome to use whatever he or she wants to build or extract the chosen
format.
I would further question why we even need to settle on exactly one
packaging format, either for ftp/uucp archives or binary news
distribution. The following points suggest themselves:
1. There are only a few formats in general use, each of them good.
Choosing between them has become an issue of personal preference,
and most sites already have the means to extract all of them.
Those that don't can probably get what they need from colleagues or
from us.
2. The specific choice of packaging format in which a product is
distributed is usually made by the author, and it's not unusual
these days to see clauses in the READ.ME saying that distribution
is free but must be "as is." Forcibly tearing down a ZOO to
make an ARC (or vice versa) would violate any such instructions;
the restriction is a reasonable one and should not disqualify a
product from Usenet distribution as long as the format is one of
the "majors."
3. The one exception I would make to point 2 above is with self
extractors. Self-extraction sounds great on paper and some authors
go for it, but it is nonetheless a Bad Thing, because it usually
restricts the flexibility a downloading user has to inspect or
manipulate his own copy before extracting or running it; and most
importantly because it leaves the user vulnerable to system damage
from transmission errors or trojan mischief. Shell archives are
of course a species of self-extraction, but they lay their operation
bare to user inspection and rely on tools you are responsible for
providing yourself, so are inherently safer.
4. Far more important than selecting one archive format is settling
on a consistent pattern of ( chop + uuencode + shar ) etc. for
posting in news articles. Regardless of the file you end up
with when you're done, the mechanism for creating the file should
be foolproof, consistent and robust. We need to put a little more
thought into this, I think.
--
Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff
"None of your toys CIS: 76556,2536 MCI: TNEFF
will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)doug@isishq.math.waterloo.edu (Doug Thompson) (09/20/88)
TN>From: tneff@dasys1.UUCP (Tom Neff)
TN>Date: 13 Sep 88 18:50:54 GMT
TN>There must have been some confusion in the way the compression standard
TN>vote was conducted. The answers as tabulated seem like nonsense. The
TN>only existing "PK" compression [actually packaging - bundling is involved
TN>as well as compression] standard is the ARC format. There is no such
TN>thing as a "fast" format or a "slow" format, only fast and slow utilities
TN>to manipulate the format. Hence the first two entries ("ARC" and "PK")
TN>in the vote tabulation really refer to the same thing.
Actually, not really. PKARC can create files which ARC cannot unpack.
While most of the time the two really are compatible, this is not always
true. ARC E is not guaranteed to unarc an archive made with pkarc,
unless pkarc is invoked with the arguement "-oc".
--
Doug Thompson - via FidoNet node 1:221/162
UUCP: ...!watmath!isishq!doug
Internet: doug@isishq.math.waterloo.edudave@sun.soe (Dave Goldblatt) (09/22/88)
From article <67.23356BC2@isishq.math.waterloo.edu>, by doug@isishq.math.waterloo.edu (Doug Thompson): > > Actually, not really. PKARC can create files which ARC cannot unpack. > While most of the time the two really are compatible, this is not always > true. ARC E is not guaranteed to unarc an archive made with pkarc, > unless pkarc is invoked with the arguement "-oc". > If 13-bit LZ is used (aka "squashing"), standard SEA ARC will not be able to extract the files. However, the latest versions (since April, I think) of ARCE also will extract "squashed" files. As an aside, I've heard that SEA signed an agreement with Vernon Buerg in which he is allowed to distribute ARCE, ARCA, etc., as shareware.. -dg- -- Internet: dave@sun.soe.clarkson.edu or: dave@clutx.clarkson.edu BITNET: dave@CLUTX.Bitnet uucp: {rpics, gould}!clutx!dave Matrix: Dave Goldblatt @ 1:260/360 ICBM: Why do you want to know? :-)
tneff@dasys1.UUCP (Tom Neff) (09/23/88)
In article <67.23356BC2@isishq.math.waterloo.edu> doug@isishq.math.waterloo.edu (Doug Thompson) writes: > TN> ... Hence the first two entries ("ARC" and "PK") > TN>in the vote tabulation really refer to the same thing. > >Actually, not really. PKARC can create files which ARC cannot unpack. >While most of the time the two really are compatible, this is not always >true. ARC E is not guaranteed to unarc an archive made with pkarc, >unless pkarc is invoked with the arguement "-oc". Actually, not really. The most recent versions of ARC.EXE and ARCE.COM (i.e., within the past six months) handle squashing just fine. There is supposedly even a Unix port that does, although I haven't seen it. (If there isn't, it would be folly to select anything with squashing for Usenet anyway.) -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
linhart@topaz.rutgers.edu (Mike Threepoint) (09/28/88)
Dave Goldblatt elaborates on Doug Thompson: -=> > Actually, not really. PKARC can create files which ARC cannot unpack. -=> > While most of the time the two really are compatible, this is not always -=> > true. ARC E is not guaranteed to unarc an archive made with pkarc, -=> > unless pkarc is invoked with the arguement "-oc". -=> If 13-bit LZ is used (aka "squashing"), standard SEA ARC will not be able -=> to extract the files. However, the latest versions (since April, I think) -=> of ARCE also will extract "squashed" files. So will the latest version of ARC (tm), grudgingly. ARC 5.22 will extract squashed files, but lists the compression method as "Deviant". The last two versions of ARCE support it, too. So does NARC, a point-and-shoot full-screen unarcer. The UNIX ARC I've seen can squash. So, actually, squashing is now a standard compression method. The message "You need a later version" is accurate for all the MS-DOS unarcers I know of. You can get ARC 5.22 off of SIMTEL, if for some strange reason you wanted it (or the documentation).
Ralf.Brown@B.GP.CS.CMU.EDU (09/28/88)
In article <Sep.27.18.41.33.1988.27012@topaz.rutgers.edu>, linhart@topaz.rutgers.edu (Mike Threepoint) writes: }Dave Goldblatt elaborates on Doug Thompson: }-=> If 13-bit LZ is used (aka "squashing"), standard SEA ARC will not be able }-=> to extract the files. However, the latest versions (since April, I think) }-=> of ARCE also will extract "squashed" files. } }[...] So does NARC, a }point-and-shoot full-screen unarcer. Not surprising, since NARC is merely a shell for PK***. }You can get ARC 5.22 off of SIMTEL, if for some strange reason you }wanted it (or the documentation). Not anymore! All SEA programs have been removed from the MSDOS archives. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
malpass@vlsi.ll.mit.edu (Don Malpass) (09/29/88)
In article <Sep.27.18.41.33.1988.27012@topaz.rutgers.edu> linhart@topaz.rutgers.edu.UUCP (Mike Threepoint) writes: >ARC 5.22 will extract squashed files, but lists the compression >method as "Deviant". INSPIRED NOMENCLATURE! Without them all of us would not have spent a man-month of each of our lives ranting and raving about this towering inferno. -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] My opinions are seldom shared by MIT Lincoln Lab, my actual employer RCA (known recently as GE), or my wife.
malpass@vlsi.ll.mit.edu (Don Malpass) (09/29/88)
In article <2340c5cd@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: >In article <Sep.27.18.41.33.1988.27012@topaz.rutgers.edu>, linhart@topaz.rutgers.edu (Mike Threepoint) writes: >}You can get ARC 5.22 off of SIMTEL, if for some strange reason you >}wanted it (or the documentation). > >Not anymore! All SEA programs have been removed from the MSDOS archives. > Seriously, what is the right thing to use in UNIX to unarc ANY .arc file? I hope there's an answer to this, or I think Simtel has done a lot of people a disservice, although it's your football. Alternately, where CAN those of us who don't share your viewpoint get 5.22? -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] My opinions are seldom shared by MIT Lincoln Lab, my actual employer RCA (known recently as GE), or my wife.
doug@sis.UUCP (Doug Berry) (10/01/88)
In article <179@vlsi.ll.mit.edu> malpass@ll-vlsi.arpa.UUCP (Don Malpass) writes: [...] >Seriously, what is the right thing to use in UNIX to unarc ANY .arc >file? I hope there's an answer to this, or I think Simtel has done a lot >of people a disservice, although it's your football. Alternately, where >CAN those of us who don't share your viewpoint get 5.22? i have been using the UN*X port of ARC 5.21 that was posted to the net in the past few months. |ARC - Archive utility, Version 5.21, created on 04/22/87 at 15:05:21 |Adapted from MSDOS by Howard Chu. It has performed flawlessly since i made it on our Ultr*x 2.2 microV*x. doug -- ...utzoo\ phone: +1 416 845 9430 x446 uucp: ...uunet!mnetor!yunexus!sis!doug