lphillips@lpami.van-bc.UUCP (Larry Phillips) (12/06/87)
From: >While I am posting, I would like to request some feedback on the Amiga >version of Zoo. What features would people like to see? Much as I like the idea of being able to use full pathnames and filenames in an archiving utility, I wish zoo wasn't available. Please don't take this as a flame, because it isn't. As a sysop on the Amigaforum on CIS, I get enough questions about using ARC, and don't look forward to learning yet another archiver just to answer questions about it. The only advantage I see to zoo is in the path/filename area. ARC generally does a better job of compression. I suggest that it would be better to modify ARC in such a way as to retain compatibility across machines that have ARC available, yet provide the benefits of long filenames and directory preservation. -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
phillip@cbmvax.UUCP (Phillip Lindsay GUEST) (12/08/87)
in article <1600@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) says: > > >While I am posting, I would like to request some feedback on the Amiga > >version of Zoo. What features would people like to see? > > Much as I like the idea of being able to use full pathnames and > filenames in an archiving utility, I wish zoo wasn't available. Please > don't take this as a flame, because it isn't. As a sysop on the Amigaforum > on CIS, I get enough questions about using ARC, and don't look forward to > learning yet another archiver just to answer questions about it. ZOO was written with portability in mind... One thing we do need is a standard way of passing compressed archives around. I want to be able to create the archive once and simply drop it on any machine and open it up with no hassles (and I want a SUN4 for Christmas:-}). Right now we have Arc, Zoo, atob+shar, and pdTAR+compress. (others?) Atleast ZOO appears to be going in the right direction. -phil ============================================================================== Phillip (Flip) Lindsay - Wake up and watch CNN at: Heather Ridge Apts. #G-115 UUCP: {ihnp4|seismo|caip}!cbmvax!phillip Mantua, NJ 08051 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making.
dca@toylnd.UUCP (David C. Albrecht) (12/09/87)
> Much as I like the idea of being able to use full pathnames and > filenames in an archiving utility, I wish zoo wasn't available. Please > don't take this as a flame, because it isn't. As a sysop on the Amigaforum > on CIS, I get enough questions about using ARC, and don't look forward to > learning yet another archiver just to answer questions about it. > > The only advantage I see to zoo is in the path/filename area. ARC > generally does a better job of compression. I suggest that it would be > better to modify ARC in such a way as to retain compatibility across > machines that have ARC available, yet provide the benefits of long > filenames and directory preservation. > You're leaving out one large advantage. Zoo is FREEWARE. Not shareware. Doesn't ask for donations. Doesn't insist commercial enterprises pay $35 for a product which cost them absolutely nothing to advertise and distribute. Like 'arc' zoo is available on unix and micros often including source making it widely available for shipping files between the machines. zoo does a more than adequate compression job, handles long file names, directory preservation, and isn't shareware that makes it a superior product in my book. Why should I want to modify arc to do the same things? Of course, CIS has a problem. Unless it has changed, the copyright file for zoo specifically prohibits posting the zoo program to commercial services that charge more than $7.00 an hour for 1200 baud. That kinda leaves CIS out in the cold. Just an observation mind you, I have nothing against CIS. David Albrecht
richard@gryphon.CTS.COM (Richard Sexton) (12/12/87)
In article <190@toylnd.UUCP> dca@toylnd.UUCP (David C. Albrecht) writes: > >> Much as I like the idea of being able to use full pathnames and >> filenames in an archiving utility, I wish zoo wasn't available. Please >> don't take this as a flame, because it isn't. As a sysop on the Amigaforum >> on CIS, I get enough questions about using ARC, and don't look forward to >> learning yet another archiver just to answer questions about it. For the price you weasels charge, you can't answer a few questions ? >Of course, CIS has a problem. Unless it has changed, the copyright file for >zoo specifically prohibits posting the zoo program to commercial services >that charge more than $7.00 an hour for 1200 baud. That kinda leaves >CIS out in the cold. Just an observation mind you, I have nothing against >CIS. I wasn't aware of this. How amusing. What a sense of humor. What a sense of what is "right". Way to go, RD. -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."
bilbo@pnet02.cts.com (Bill Daggett) (12/13/87)
ARC is free too. At least the latest version I have is. It DOES state that
if you use ARC commercially the licensing fee is $35.00. And it DOES state
that a donation would be nice. The term Shareware is not used. Don't get me
wrong, I think ARC deserves a donation.
I would rather stick with ARC enhanced to accept any file name length then
ZOO.
There is a third program recently released called PAK. PAK's neat advantage
is that you don't need it to unpack a program. You simply run <filename>.PAK
and it unpacks itself - but like ZOO the compressing is not as great as ARC.
PAK does accept any normal file length name like ZOO.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Bill Daggett, a.k.a. *Bilbo Baggins* Recombinant Hobbit and Sysop of
* Sometimes The Dragon Wins! * Bilbo's Hideaway = 213-640-6104
INTERNET: bilbo@pnet02.CTS.COM
UUCP: {hplabs!hp-sdd!crash, ihnp4!scgvaxd }!gryphon!pnet02!bilbojlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) (12/14/87)
Our local PaNorAmA Amiga User's Club has a bulletin board project
underway wherein we want to make the latest Club and Fred Fish disks more
available for members. Each disk is archived by directory before going on
the board to make it faster and simpler to download, and to save storage
space on the board's hard drive.
I have found Zoo to be invaluable for this use. I particularly like
the way Zoo retains the directory structures, and the long file names.
The size of Zoo's archive seems to be comparable with those produced by
Arc as well. Sometimes Arc produces smaller files than Arc, sometimes
they are larger - but not by much. I do have a couple of enhancements
that I would like to see though.
o Would it be possible to extend Zoo to automatically pick up
sub-directories as well. IE. if I want to zoo a directory that
has a structure like:-
A
... some files ...
B
... some files in A/B
C
... some files in A/C
Can I have zoo pic up both A/B/* and A/C/* as well as A/*
without without having to specify the sub-directories A/B and
A/C on the command line.
o Personally, I would like Zoo's default to recreate the directory
structure when the archive is unpacked. By default, Zoo now
places the files in the current directory, unless you specify
the more complicated expert mode unpacking option,
"zoo e.// Archive.zoo".
o Zoo has a bug that should be fixed. When you unpack the archive
with the command "zoo e.// Archive.zoo", Zoo leaves a lock on
the first directory it creates.
o Can we have the source code? The docs suggest that they should
have been part of the package. If we make any changes, I would
be glad to mail you a diff file. It is always better for one
person to be the "keeper of the source" so to speak and to be
the one who releases the latest version.
--
// Jeff Lydiatt UUCP: uunet!van-bc!jlami!jlydiatt
\X/ or : {ihnp4!alberta!ubc-vision,uunet}!van-bc!jlami!jlydiattlphillips@lpami.van-bc.UUCP (Larry Phillips) (12/16/87)
>You're leaving out one large advantage. Zoo is FREEWARE. Not shareware. You are right, of course. This is a significant advantage, at least to some. >Of course, CIS has a problem. Unless it has changed, the copyright file for >zoo specifically prohibits posting the zoo program to commercial services >that charge more than $7.00 an hour for 1200 baud. That kinda leaves >CIS out in the cold. Just an observation mind you, I have nothing against >CIS. No, CIS does not have a problem. Apparently the author has a problem with CIS, whether it be with CIS in particular or networks that charge more than $9.00/1200 baud (I think) in general. It is up to him, and we do respect that restriction. He is missing a very large audience, the majority of which have no access to Usenet, but I presume he is aware of this fact. Since virtually all of the files available on CIS are in ARCed format, we are hardly 'left out in the cold', and in fact we convert all Zoo'ed files to ARC format before posting them. Who does this hurt? CIS? Not hardly. Just an observation mind you, I have nothing against the author of Zoo. >David Albrecht Larry Phillips Disclaimer: I do not represent CIS. I am just a hacker who loves to help out where I can. I do not get paid for what I do on the forum, other than having the satisfaction of being able to help a LOT of Amiga users. -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
peter@sugar.UUCP (Peter da Silva) (12/16/87)
It doesn't seem *significantly* better than ARC. About all it's got going for it is the long file names. As a side bonus, I get to take up another hunk of space in my not-so-well-endowed c: directory for a chunky little utility. I could go for replacing LU with ARC... it was a significant improvement over LU and SQ. ZOO won't replace ARC, it'll just be a parallel standard. Look at the IBM-PC to see how much fun you can have with that. Personally, I'd prefer an IFF-based archive format. Now THAT would be a win. Totally expandable, too. And every Amiga hack should be able to diddle IFF by now. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
keithd@cadovax.UUCP (Keith Doyle) (12/21/87)
Not to too much further heat up the ARC/ZOO debate, but...
There are a couple of things I sure wish ARC did that it dosen't do, and
I was wondering if ZOO addresses these problems:
1. Truncation of file names. (unix to Amiga? come on, they both have 14+
character names!)
2. Work with subdirectories. I should be able to say:
arc -r -a arcfilename directoryname
and have it go through all subdirectories and get all the files, and
on the uncompress, do a mkdir to create the directories if they don't
already exist.
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170dmose@agora.UUCP (Dan Mosedale) (12/21/87)
In article <1624@van-bc.UUCP> jlydiatt@jlami.van-bc.UUCP (Jeff Lydiatt) writes: > o Would it be possible to extend Zoo to automatically pick up > sub-directories as well. IE. if I want to zoo a directory that > has a structure like:- > > A > ... some files ... > B > ... some files in A/B > C > ... some files in A/C > > Can I have zoo pic up both A/B/* and A/C/* as well as A/* > without without having to specify the sub-directories A/B and > A/C on the command line. I agree 100%! This would make it many times easier to ZOO an entire disk! > o Personally, I would like Zoo's default to recreate the directory > structure when the archive is unpacked. By default, Zoo now > places the files in the current directory, unless you specify > the more complicated expert mode unpacking option, > "zoo e.// Archive.zoo". Make sure it recreates the old directory structure in the current directory though. If I'm cd'ed to DH0:Downloads/NewProg, I want all subdirectories to be created there. >-- > // Jeff Lydiatt UUCP: uunet!van-bc!jlami!jlydiatt >\X/ or : {ihnp4!alberta!ubc-vision,uunet}!van-bc!jlami!jlydiatt One other thing: locally, some folks have been saying that large HAM/LACE pictures actually increase when Zoo'ed by zoo aP ram:pica.zoo df0:pica See if the compression algorythms are at fault! Could be a user error, though, as I haven't tried it. -- \\ "These opinions may in some way represent those of my employer... // \\ but I seriously doubt it." // \\ // Dan Mosedale dmose@agora \\ // \\/ ...tektronix!reed!percival!agora!dmose \//
jdow@gryphon.CTS.COM (Joanne Dow) (12/22/87)
In article <1631@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > > >You're leaving out one large advantage. Zoo is FREEWARE. Not shareware. > > You are right, of course. This is a significant advantage, at least to >some. > > >Of course, CIS has a problem. Unless it has changed, the copyright file for > >zoo specifically prohibits posting the zoo program to commercial services > >that charge more than $7.00 an hour for 1200 baud. That kinda leaves > >CIS out in the cold. Just an observation mind you, I have nothing against > >CIS. > > No, CIS does not have a problem. Apparently the author has a problem >with CIS, whether it be with CIS in particular or networks that charge >more than $9.00/1200 baud (I think) in general. Alas this includes BIX and SOURCE as well. I wonder what this gentleman has against the higher cost services where his program might be of more value. Meanwhile ARC is the main distribution medium and zoo is rather languishing. Ah well - that's his prerogative. It'd be nice if he could post somewhere his reasons for this. -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.
john13@garfield.UUCP (John Russell) (12/23/87)
In article <1929@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >1. Truncation of file names. (unix to Amiga? come on, they both have 14+ > character names!) This really really really bugs me. One #define somewhere is screwing up all the long file names. >2. Work with subdirectories. The Unix arc I can't even get to create an archive in a different directory (eg arc a ../foo *) or unarc from a different one. Also Unix arc will gladly remove your files when you use the "m" option even if it can't create the archive (because you don't have write permission on the directory) or can't read the file (a problem sometimes when uudecoded files create binaries with odd protections and you don't notice). John -- "...and intuition, in a case such as this, is of crucial importance." -- William Gibson, _Count_Zero_
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/30/87)
In article <2677@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >Alas this includes BIX and SOURCE as well. I wonder what this gentleman has >against the higher cost services where his program might be of more value. Actually the copyright notice says at that bottom that "the above restrictions may be relaxed by special agreement; please contact me for details." Also, imagine how things would suddenly be if every author of every free program insisted that the program be distributed at low cost. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
peter@sugar.UUCP (Peter da Silva) (01/03/88)
In article <1749@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > Also, imagine how things would suddenly be if every author of every > free program insisted that the program be distributed at low cost. Yeh, a lot of people would find their distribution channels for free and low cost software drying up. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
richard@gryphon.CTS.COM (Richard Sexton) (01/04/88)
In article <1339@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <1749@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >> Also, imagine how things would suddenly be if every author of every >> free program insisted that the program be distributed at low cost. > >Yeh, a lot of people would find their distribution channels for free and >low cost software drying up. ... while the lower cost distribution channels would no doubt pick up the slack. -- It's too far from Santa Fe to my ignition, or something like that. richard@gryphon.CTS.COM {ihnp4!scgvaxd!cadovax, philabs!cadovax, codas!ddsw1} gryphon!richard
peter@sugar.UUCP (Peter da Silva) (01/06/88)
In article ... richard@gryphon.CTS.COM (Richard Sexton) writes: > In article ... peter@sugar.UUCP (Peter da Silva) writes: > >In article ... dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >> Also, imagine how things would suddenly be if every author of every > >> free program insisted that the program be distributed at low cost. > >Yeh, a lot of people would find their distribution channels for free and > >low cost software drying up. > ... while the lower cost distribution channels would no doubt pick > up the slack. Not for the people I was talking about for whome Compuserve and its cohorts are the only distribution channel for much of this software. The U.S. is an interesting place. You might not have noticed this, being so close to the situation, but I have. An incredibly large portion of the population lives in large towns that are pretty much isolated by long distances from the big cities. Towns too small to support an active BBS and user group community. Few of these places, though, are quite so isolated they don't have at least moderately inexpensive access to Compuserve. The lower cost distribution channels can't afford to take up the slack. Consider the U.S. Mail. You and I know that it's more expensive to send (x) via the mails than by (say) UPS... at least not if you want equivalent prompt service. This cost helps subsidise postal offices in places where it wouldn't be economical to provide ANY mail service otherwise. #pragma mysticism(ON) It's interesting and refreshing that the Invisible Hand is quite capable of supporting the equivalent arrangement in the Other Plane. #pragma mysticism(OFF) Basically... if CI$ isn't worth it to you, just don't use it. Don't flame it for costing so much... ESPECIALLY when you have access to so many other channels. If everyone had the access to systems like this, CI$ would be out of business. If all these software authors suddenly became Stallmanist anarchists all that would happen is that less high quality software would get to Truth or Consequences or Lower Podunk. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
cjp@antique.UUCP (Charles Poirier) (01/08/88)
PeopleLink is a low-cost alternative that many people don't seem to be aware of. Non-prime-time 1200 Baud service is $4.95/hr, well below the $7/hr figure that started this furor. Lower rates are available for heavier users. The Amiga Zone on PLink is great. (Hi Harv - you show great restraint in not speaking up here!) The point is, that $7/hr limitation is a stab, not at *all* commercial services, just at the overpriced ones. Charles Poirier -- Charles Poirier (decvax,ihnp4,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."
hrlaser@pnet02.cts.com (Harv Laser) (01/10/88)
cjp@antique.UUCP (Charles Poirier) writes: >PeopleLink is a low-cost alternative that many people don't seem to be >aware of. Non-prime-time 1200 Baud service is $4.95/hr, well below the >$7/hr figure that started this furor. Lower rates are available for >heavier users. The Amiga Zone on PLink is great. (Hi Harv - you show >great restraint in not speaking up here!) The point is, that $7/hr >limitation is a stab, not at *all* commercial services, just at the >overpriced ones. > > Charles Poirier >-- > Charles Poirier (decvax,ihnp4,attmail)!vax135!cjp > > "Docking complete... Docking complete... Docking complete..." Yah, restraint is but one of my virtues... comes on the list right after humble :) And thanks for the plug, by the way. Word-of-mouth can be just as good a method of advertising as glossy full page full color $4000 ads if the right words come out of the right mouths aimed at the right ears. [my artsy fartsy .signature got swept away in the Great Gryphon Crash of Xmas Day, 1987, so in the meantime I'm just...vvvvvv] UUCP: {ihnp4!scgvaxd!cadovax, rutgers!marque}!gryphon!pnet02!hrlaser INET: hrlaser@pnet02.cts.com
blgardne@esunix.UUCP (Blaine Gardner) (01/21/88)
in article <2562@gryphon.CTS.COM>, bilbo@pnet02.cts.com (Bill Daggett) says: > > There is a third program recently released called PAK. PAK's neat advantage > is that you don't need it to unpack a program. You simply run <filename>.PAK > and it unpacks itself - but like ZOO the compressing is not as great as ARC. > PAK does accept any normal file length name like ZOO. Yes, PAK is a godsend for getting ARC or ZOO or FixObj into the hands of new users. I've got a ZOO.PAK and ARC.PAK available on the BBS that I run the Amiga section on. There is some confusion though, since there is also a program called PackIt. To the best of my knowledge, PackIt does no compression, it just cats files together, it may handle subdirectories though. PackIt is a completely different beast from PAK. (PAK is distributed in a file called PAK.PAK, it contains PAK and the docs, and unPAKs itself.) I have to disagree with the statements that ZOO doesn't do as well on compression as ARC. ZOO will do very little (if any) compression on picture files or sampled sound files (I would guess that IFF and ZOO use the same compression technique), but on any other type of file (source, executable, text) ZOO generally does a better job of compression than ARC. As I remember ZOO archives were usually 5-20% smaller than ARC archives. When you add ZOO's faster compression, and the ability to handle long filenames, I much prefer ZOO over ARC. -- Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 UUCP Addresses: {ihnp4,ucbvax,allegra,decvax}!decwrl!esunix!blgardne ihnp4!utah-cs!esunix!blgardne usna!esunix!blgardne "I don't see no points on your ears boy, but you sound like a Vulcan!"
devilbis@csd4.milw.wisc.edu (Vilbiss Warren C De) (01/24/88)
Just a note in regards to the differences between ARC and ZOO compression, as well as the new PKAX ARC extractor for the Amiga... First of all, the reason that ZOO does better on some files, while it does MUCH poorer on others (i.e., no compression at all!) is because ZOO only uses Ziv-Lempel 13-bit compression, while the ARC programs will dynamically choose between 8 different compression algorythms. Well, I should be fair, ZOO *does* have two alternatives; 13 bit "crunch", or nothing at all! For some reason, IFF pictures & sound files seem to ARC more efficiently if they're Squeezed (Huffman compression), which is why ARC wins this one over ZOO. But, the real answer to the question lies in the newly-released PKAX ARC extractor for the Amiga, offered by none other than Phil Katz hisself, of IBM PC fame (and, if I may add, a close personal friend of mine...). Anyways, the PKAX program is the extract-only part of the package, analogous to PKXARC for the PC; he is currently preparing to port the other half of his PC offering to the Amiga, depending on the fate of PKAX as regards to "shareware" receipts (actually, in his case, it's more like User Supported Software than "shareware", since he had to pay someone to complete the Amiga port, and wants to recoup his investment like any other businessperson). Anyways again, besides being another ARC extraction utility, this program is FAST!, which, of course, is one of Phil's trademarks in the PC arena. Also, the program is relatively small in size, 18652 bytes long, AND (the finale I've been leading up to for the last dozen lines or so), it supports Squashing, which is the ARC extension that Phil implemented for PKXARC/PC, which is the same Ziv-Lempel varient that ZOO uses to get better compression. Except, in PKARC/PKXARC/PKAX's case, it's even better, because those programs are able to more intelligently determine which varient to use on compression to save more space. As an example, for a PC, PKARC will make files smaller than ARC will, even when Crunching or Squeezing is being used, because the algorithm is more intelligent. And, the files can still be unARC'ed by either program (except for Squashing, which is PK-exclusive for now.) Well, that's enough for now from me. - Mike Shawaluk
jw@sics.se (Johan Widen) (01/25/88)
zoo version 1.42b is for som reason unable to handle more than 97 files.
I think this is unreasonable. Please don't keep this limitation just for
backwards compatibility.
--
Johan Widen
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
Internet: jw@sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw