grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) (01/03/90)
Gee, I certainly hope that LHARC doesn't take over. Why? Three reasons.
1: It doesn't exist on many machines.
2: It isn't that good.
3: It's as slow as molasses.
I did a benchmark on my AT clone at work, using a variety of filesets and
all the compression programs I had around. If there is interest I will
post the actual numbers. The summary is that PKZIP wins hands down in
most of the areas of interest to me - it is fast, and it compresses trees.
The problem with PKZIP (and PKARC as well) is lack of source.
ZOO source is available in the PD, and ZOO has already been ported to
most machines (right?). ZOO is comparable in speed and compression to ARC,
and slower than PKARC or PKZIP. However, it does do trees, and thus has
a real advantage over ARC.
LHARC was abysmally slow. Compression was better than ARC or ZOO, but no
better than PKZIP. It takes sooooo looooong to do simple operations that it
is simply not usable (IMHO). Does trees, tho.
The nice thing about ARC is that it exists on all machines, and everyone
has ported it in such a way that it stays compatible. If you read the
comments with LHARC for the ST (which I have run a number of times, by
the way), there is mention of incompatibility. I believe the latest
version supports some of the additional encoding methods, but there were
still some arbitrary differences.
The only real advantage I can see to using one of the newer compression
programs is the ability to compress trees. For a new compression program
to be successful it must be fast, readily available for any operating
system, and totally compatible across all operating systems. ARC is
even usable on a MAC! For LHARC or ZOO to be successful, it needs to be
ported to all of the common machines out there, from the Atari 800XL
to the IBM 3090. ARC is there...
Well, I haven't been in a good flame war for a while. Have fun, if
you must. I personally think that LHARC is not the way to go, and I
am sure that all of you who disagree will let me know.
_john
--
John T. Grieggs (Telos @ Jet Propulsion Laboratory)
4800 Oak Grove Drive, Pasadena, Ca. 91109 M/S 301-260A (818) 354-1453
Uucp: {cit-vax,elroy,chas2}!jpl-devvax!grieggs
Arpa: ...jpl-devvax!grieggs@cit-vax.ARPAkoreth@panarthea.ebay.sun.com (Steven Grimm) (01/03/90)
In article <6716@jpl-devvax.JPL.NASA.GOV> grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) writes: > 1: It doesn't exist on many machines. I should note again that I won't accept any comp.binaries.atari.st (or, for that matter, comp.sources.atari.st) submissions in lharc format until source code for lharc becomes available. This is partly for my convenience; I like to look at documentation and test archive integrity on panarthea before downloading the software to test it on the ST. But it's mostly for the convenience of all the other netters who've told me that they like to do more or less the same thing. Once source code becomes available, I'll leave it up to individual submitters to decide whether to use it instead of arc or zoo. --- " !" - Marcel Marceau Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ebay.sun.com ...!sun!ebay!koreth
klute@trillian (01/03/90)
Path: trillian !klute And another reason to use ZOO or ARC: There is ARCGSH available, a program that lets you work with ZOO, ARC and other programs from a GEM environment. Check the archives at panarthea or terminator and get version 2.1! (Older versions do not support ZOO.) Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
andyc@hplsla.HP.COM (Andy Cassino) (01/04/90)
grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) writes: | Gee, I certainly hope that LHARC doesn't take over. Why? Three reasons. | | 1: It doesn't exist on many machines. | 2: It isn't that good. | 3: It's as slow as molasses. | | I did a benchmark on my AT clone at work, using a variety of filesets and | all the compression programs I had around. . . (text omitted) . | LHARC was abysmally slow. Compression was better than ARC or ZOO, but no | better than PKZIP. It takes sooooo looooong to do simple operations that it | is simply not usable (IMHO). Does trees, tho. Gee, I'd venture the opinion that LHARC runs lots better on the ST than it does on an AT clone! I ran some tests on my ST this weekend. LHARC .51 was slower than ARC 5.21 but it was neither abysmal nor unusable. It took maybe 30% longer to compress; un-LHARCing seemed comparable to un-ARCing. LHARC did a much better job of compression - up to 25% better in my tests! I concluded that any extra execution time was compensated many times over by the decrease in download times (and costs) due to the superior compression. Therefore, I don't mind using LHARC for GEnie uploads/downloads or other BBS downloads at low baud rates. As for Usenet binaries, Steven Grimm has stated that LHARC source must be available before LHARC'd binaries are acceptable. When/if that happens, I would think that conservation of net bandwidth should make LHARC the preferred program. (Then again, I hear ARC 6.0 is out and it is supposed to be better than LHARC....) Disclaimer: The opinions expressed herein are those solely of the author, who has no pecuniary interest in the companies, products, or publications mentioned above. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Andy Cassino % % uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com % % Hewlett-Packard Lake Stevens Instrument Division % % 8600 Soper Hill Road Everett, WA 98205-1298 % % (206) 335-2211 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
cr1@beach.cis.ufl.edu (Christopher Roth) (01/04/90)
Just thought I'd say a few things:
First of all, can anybody please mail me arcgsh version 2.1? All
attempts to get this program from wuarchive.wustl.edu have been a
complete and total failure. I'd appreciate it.
As for the ZOO -VS- LHARC discussion, I use ZOO quite a bit.
Currently, I am converting the Atari ST files on an 8 line BBS in
Florida over to ZOO. The things I like about ZOO are:
1) It compresses, ussually, better then ARC does. We've saved
quite a bit of disk space.
2) There are some nice features. It is USEFUL to have the
ability to add a comment into that archive, many has been the
time I have downloaded a file and forgot what it was. I also
like the fact it saves the complete pathname of the file. None
of this archives-within-archives stuff to preserve pathnames.
LHARC might compress a bit better, but it it not as widely used as
LHARC and as available on other machines.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Christoper Roth * "Machines have no
* InterNet : cr1@beach.cis.ufl.edu * Conscience..."
=-=-=-=-=-=-=-=-=-=-=-=-=-Post No Bills-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) (01/04/90)
In article <5440094@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: >Gee, I'd venture the opinion that LHARC runs lots better on the ST than >it does on an AT clone! I thought about this after I posted - the speed of LHARC will depend in part on the port and the machine it is running on. It runs quite a bit faster on the AT, incidentally. When I get something in LHARC form, I normally undo it on the AT and tranfer it over via 3.5 inch floppy (if it fits) or 19,200 baud cable (if larger than 720K). It seems faster to un-LHARC on the AT and transfer serially, than to un-LHARC on the ST, but I have not benchmarked that one... _john -- John T. Grieggs (Telos @ Jet Propulsion Laboratory) 4800 Oak Grove Drive, Pasadena, Ca. 91109 M/S 301-260A (818) 354-1453 Uucp: {cit-vax,elroy,chas2}!jpl-devvax!grieggs Arpa: ...jpl-devvax!grieggs@cit-vax.ARPA
klute@trillian (01/04/90)
Path: trillian !klute In article <1363@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander) writes: >Arcgsh is the best reason I have ever had to install a shell (gulam, >msh, any keyboard oriented line-at-a-time shell at all). Yes, I was >using 2.1 and IMHO it's at least 5 times as much work to use as the >raw commands themselves. Faugh! Depends on what you like and what you do not like. Surely Arcgsh is nothing for people who like command line shells and are able to remember all the options a program has, and especially Zoo has *many* of them. Arcgsh was designed for people who 1) like GEM or 2) do not want to remember all commands and options of Zoo, Arc etc. in order to keep their heads free for more important things. If you like to use Arcgsh in general but do not like details of user guiding please mail me you suggestions! Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) (01/05/90)
In article <5440094@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: > >As for Usenet binaries, Steven Grimm has stated that LHARC source must >be available before LHARC'd binaries are acceptable. When/if that happens, >I would think that conservation of net bandwidth should make LHARC the >preferred program. > well, at terminator.cc.umich.edu in atari/new directory, there is a file called LHARCSRC.arc which looks like something worthwhile to look at... -- S. Alan Ezust depeche@calvin.cs.mcgill.ca McGill University Department of Computer Science - Montreal, Quebec, Canada
econadm5@watserv1.waterloo.edu (BENTLEY BH - ECONOMICS) (01/10/90)
Source is already available in C language but Im new to Unix and am using my professors account somehow Ill figure a way to place it on Unix so others can get to work on switching over to Lzh. Dave Tomesch Super BBS (519) 749-1206 24hrs. Brain Bentley Kwest Editor