#.PAK files.
77 messages in this thread
While ARC is the most common and widely used archiving program on the Amiga,
there are a few others available. Each has its strong and weak points.
We have just had our first upload of a file using a program called PAK, and
it's in DL 15, called PLAY.PAK. The program itself is a Sonix music player,
documantation for it, and a small utiliy that allows switching out the LED,
which disables the low pass audio filters on the A500 and A2000. The author,
who is also the author of the PAK program has stated that it may be distributed
only in its PAKed form. Because this is a program that many members have been
looking for, and because we will not go against the athors distribution
requests, we have left it in PAKed form.
We would like to hear feedback from the members as to whether we should
provide PAKed files (as opposed to ARCed files) in the Data Libraries.
PAKed files are simpler than ARCed files. To decompose a PAKed file into its
parts, simply download and run the program. In this particular case, you would
type PLAY.PAK, and the file will unPAK itself. On the down side, PAKed files
tend to be larger than ARCed files by anywhere from 10% to 50% larger.
If you have any feelings one way or the other, please respond to this with
your opinions. We will try to get a feeling for the consensus and either
severely limit the PAKed files or just leave them as uploaded. If the feeling
is that PAKed files are OK, we will also provide the PAK program itself.
This is your forum. Please feel free to help guide its future.
Regards, Larry.
I think that PAK files should be allowed, and that some pressure should be put
on Mark to improve his compression routines. The big advantage of PAK is its
simplicity for new users, who always try to execute .ARC files their first time
out.
Another advantage is the removal of file name length restrictions,
which is ANOTHER added complication of arc. On the downside, it appears that
PAK likes to unpack in the directory that it resides in (at least by default),
and that will lead to a lot of disk "thrashing" when unpacking large files.
There's probably room for both, but I'd start to change my answer if
Amigaforum became the "compression program of the month" forum. There is at
least one other contender that I'm aware of (Zoo), and it could get to be quite
a mess.
Ariel
There's also PKARC, which supports a form of compression which ARC does not.
Wish all these people would get together at least to the point of supporting
each other's formats.
Rick
I don't agree that executing a PAK file is the intuitive first thing that a new
user does. I think providing a better education to a new user, IE, suggesting a
D/L of an unarced introductory text file after his/her first logon is a
bettermethod. The text file could explain about ARC, ZOO, PAK, etc.
Terry:
Not only is it a good method to include help files within the forum,
but it is an already implemented method! I believe help files for new users
are available in DL0.
I said that it's intuitive for new users to attempt to run arc files
because I've heard the same questions a thousand times in messages here. There
ARE quite a few users who migrated from other computers who instinctively know
that .ARC does not equal a .COM or .BIN file. However, for users who have
bought their first computer, it is typical for them to attempt to run or
"execute" the .ARC file.
Ariel
Larry, the only program which I think _needs_ to be PAKd is Arc, which would
get us through the bootstrapin problem nicely. But it's not a religious issue,
y'know? It's not like I'll need to find room for another utility on my C:
diskette, since the PAKd file requires no utility; nor doI use up space on my
disk with a bunch of redundant PAK code sitting in each PAK file, since I can
unPAK everything, the PAK code vanishes, and then re-ARC if that's how I like
to store things. I don't need to change Diskman, since I can just RUN
PAK files rather than do the UnArc procedure first.
The only drawback to PAK is higher communications costs. What happens to the
grodyguts like ElGato.ARC? Do they take two hours to download when PAKd?
Larry,
In my humble opinion, file compression schemes in telecom services should
strive to do one thing. That one thing is to reduce file size maximally
without degrading the file structure. For the majority of CIS users, and , a
prime consideration is the cost of communications. Downloading is a choice I
make based on price/performance factors. As I am remote from a toll-free CIS
node and have to pay Long Distance rates + connect time, speed of data transfer
is a mighty important factor for me.
Count my vote for ARC or its improved successor. While ARC required some
understanding to perform, in either direction, it isn't beyond the ken of
anyone older than 10 years old ( I think).
Michael
I would be very hesitant to dl a .pak file without a way like arc's v option to
check needed disk space and prevent filename conflicts. I would also worry
about potential trojan horses being upload with an innocent looking .pak
extension. One of the beauties of arc is that I know I'm not going to trash a
disk by just un-arcing the files. I can then write-protect my disks before I
run an unknown commodity.
Mike,
You have brought up a very good point, and one that will have to be taken
into account. The sysops here will have to be extremely vigilant to prevent any
innocent looking but dangerous programs from being made public.
I have a similar feeling toward Zoo, as it has not been proven to my
satisfaction that it will restrict its activities to the directory I have it
in.
Thanks for the input.
Regards, Larry.
Larry,
If you use 'zoo x filename' instead of 'zoo x// filename' it will
extract the files to the current directory, ignoring filenames.
ZOO also seems to be twice as fast as ARC in compressing files and
since it supports full path/names it doesn't require Execute.Me files; thus
making it simplier to use. One little side benifit is that it also seems to
compress files smaller than ARC. (From my experience with over 23meg of
downloads on my bbs.)
One other note is that you can also instruct it to not store the paths
when creating a ZOO file.
Scott
Scott,
It would seem that your experience is oppositte mine. I find that though some
Zoo'd files are smaller then the same files ARCed, Most times ARC does a better
job. I can't see much difference in time taken to acrhive or extract. There is
also the problem of having to explain more than one archiving system. At least
.PAK files are easy to explain.
Regards, Larry.
Larry,
Try ZOO'ing ARC023 and also ARC'ing it…which is smaller?
Though I know that this is a limited example, it is not all I
base my statements on. Besides picture files, I find that in 8 out of 10
cases ZOO'd file are usually at least 10% smaller. As far as the time required
to archive files, remember that ZOO has no 'analyzing,' stage…since as
far as I know it employs only one method of compression.
Snipit to the rescue:
ZOO'D.zoo 33429 rwed 11-Oct-87 20:13:28
ARC'D.ARC 40164 rwed 11-Oct-87 20:13:28
If you'd like additional stats, I'd be more than glad to provide
you with them by the megabyte…<grin>
Scott
Scott,
You mention picture files… would you care to hazard a guess as to which
Data Libraries are the largest here in the Amigaforum?
Though the testing I did was limited, perhaps 15 or 20 different sets of
files, I found that ARC was the winner for size in more cases than was Zoo. I
used what I felt were typical cases, where groups of files containing
executable and source or text were put together.
Regards, Larry.
Larry,
I'm not in favor of any ONE archive program having exclusive rights
here on CIS. I do however agree that ARC is much better for picture files.
If ARC only supported full pathnames, it would also be the easiest to
use…Ray keeps saying that he MIGHT add this, but it's doubtfull that we'll
see it for quite a while.
I am also aware that ZOO poses a special problem for CI$, since it's
author forbids it from being uploaded to commercial networks that charge over
$9/hr 1200baud (not sure of that figure, but I know that it's below the rate
here). If this is your problem with ZOO I could certainly understand that…
Scott
[Hiding his copy of ZOO before the natives get restless…]
Scott,
I AM in favor of ONE archive program. I only need ONE program to process
the downloads from CIS. It is even the same program I use to compress files I
upload. Sounds like an ideal solution to me.
Scott,
IBM Forum did some testing on ZOO'ed files when ZOO first came out, it
found that while on occasion, ZOO did beat ARC on filesize, that on average ZOO
was 10 to 15% (or so) larger and there were a few other troubles with it.
I forget all the reasons, but their tests shows ZOO was not the way to
go.
Don
Larry (and others)…a couple of points here:
1) PAK does provide a way to see what's "in" a .PAK archive before
unravelling it. You need the PAK utility itself to do this. It's
a whopping 5K long, so it shouldn't put any terrible contraints
on anyone to get it and keep it around. Type PAK PAKNAME.PAK to
see the files inside the archive, with their full names, their
original filesize, and their PAK'd filesize.
So much for that argument.
.
2) Mark Riley is dilligently working on new compression schemes
for an upgrade to PAK. From discussions with him he indicated he
can get PAK to compress down to equal or BETTER what ARC0.23
can deliver. If that's the case, then PAK could easily
become ARC's replacement, since it's faster, smaller,
its archives unPAK themselves, can use full Amiga style filenames,
etc. etc.
.
3) lastly, and perhaps most importantly, Mark is extremely soured
by what he perceives to be rampant piracy amongst Amigans.
The more shareware contributions he receives for PAK, the more
likely he is to finish and distribute an improved version.
Harv,
While you can indeed see what's in a .PAK file by using the PAK utility, it
does not solve the two major problems inherent in a .PAK file. The first is
that one of the beneifits of PAK is that you don't need, and indeed may not
have PAK itself. The second is that even with PAK, one is still not sure that
the .PAK file contains what it is said to contain. This is a dangerous
situation for a file that you run, without benefit being able to look at it
first. With ARC, the file you are unARCing does not execute, and no harm can
occur during that process. Lest you think that this is overly paranoid, I
assure you that if you have been once bitten by a destructive program, you will
hesitate to take any program on faith alone. As I say, we do check every file
here in the DLs, so it is less of an issue than it otherwise would be.
As far as Mark's perception of piracy and the Amiga is concerned, he is in
the same boat as authors of software everywhere, and on every machine. If he
expects people to send him shareware contributions, he will definitely need to
improve the product a LOT. It has a big hurdle to overcome in the area of
compatibility with other systems, in which area ARC already shines. It's a
'Catch 22' situation. He doesn't want to put the time in if people aren't
contributing, and they won't unless he puts the time in.
Regards, Larry.
I think we have a misunderstanding here. Are you saying that "running"
a PAK file to dissolve it is dangerous? Or are you saying that
downloading a file which has a .PAK extension under the surmise
that it actually IS a PAK file is dangerous, since one doesn't
really know what the file is just because it has a PAK extension.
Here, on Plink, and elsewhere, where files are downloaded and
checked by sysops, this doesn't present a problem. Elsewhere
it might, if that's what you meant.
Secondly, I don't know that Mark has any intention to make PAK
compatible with any other systems. PAK is the first utility written
strictly for the Amiga. All others (ARC, ZOO, LAR, Squeeze, etc)
were portovers from other operating systems. If people keep their
wits about them, and sysops everywhere provide correctly named
files, there shouldn't be any problems. It's nice to go into an
IBM area with my Amiga and download @ 2400 baud, unARC *their* ARC
files then move it to an MS Dos disk with Dos2Dos and run it under
the Transformer, rather than sleeping thru a download done under
MS Dos/Transformer itself. I'm not Anti-ARC.
Outside of text files, though, I don't know a lot of IBM folks who
come to Amiga sigs to download files, though, since the last time
I looked, there was no Amiga emulator for them. 🙂
Larry,
Regarding your comment about ZOO, you have to "throw a switch" in order
to have ZOO split itself into subdirectories – even if the ZOO was created with
all the subdirectories. So if you don't use the switch, which happens to be
"//", then ZOO won't split itself into the subdirectories. What you would end
up with is only what was in the "root" of the ZOO. You would have to manually
extract each subdirectory.
So, if you don't use the // switch, you are as as safe as with ARC.
Even with the switch, the subdirectories are only created on the destination
drive (if specified – or your Current Directory).
It's a shame that ZOO isn't allowed here. It's use of LONG FILNAMES,
it's ability to archive the files in their proper subdirectories – and then to
extract those files AND subdirectories, make it much more useful than ARC. ZOO
usually creates smaller "archives" and works faster too.
It's a moot point anyway. ZOO's author(s) have restrictions that
preclude it's inclusion/use on Compu$erve.
As to PAK, I like the concept AS A "USER". It is easy to use. It is
MUCH harder to create a PAK file with many items. Each file must be MANUALLY
ADDED to the PAK file – no wildcards allowed. And as a DOWNLOADER, especially
one paying $12.50/Hr., I want the SMALLEST ARCHIVES POSSIBLE! PAK files are
MUCH too large!
Lloyd
Lloyd,
Thanks for the clarifications about Zoo. I admit I do like the idea of being
able to specify full filenames, as well as the ability to unZoo to full paths
(provided it can't go "up a dirextory level"). One thing that I keep hearing
about is that Zoo compresses more that ARC. In my testing, I have found that
ARC wins in the compression race more often than Zoo does.
All in all, for my own use, I prefer ARC, even though it sometimes requires a
little more work to do the same things as Zoo.
Regards, Larry.
Larry,
ARC beats ZOO in compressing animations, and sometimes IFF pictures.
ZOO compresses text and programs more efficiently. On the whole, ZOO is more
efficient on the majority of files (in my testing).
And don't forget, there are no "EXECUTE.ME" files to create and use!
Lloyd
Larry,
I enjoy the PAK common sense approach to unpacking itself and have
downloaded the program as well. It's major fault is of course the compression
routine. It does not compress nearly well enough in some cases to warrant its
use for saving download time. It does well enough with document files and may
have use for beginner situations. All in all, if the uploader believes the PAK
is good enough, it should not be a problem for the downloader.
I missed the story on Zoo vs Arc. Is there a significant savings with
Zoo to warrant its use?
Thanks,
Jer
Jerry,
Zoo is a little less efficient at compression than ARC. It's main claim is
that it supports full pathnames and long file names. Unfortunately it is
incompatible with archivibg utilities on any other machines.
Regards, Larry.
Larry,
J0RGEN's ARCEXE very nicely handles the problems os long filenames and
directories. You can also see where everyting is going before it goes there,
too.
Vic,
Good point. I keep meaning to get hold of the author of ARC to talk about a
way to have ARC do those sorts of things automatically, yet remain compatible
with other ARCs. I still think compatibility is, if not _the_ most important
feature of ARC, at least high on the list.
Regards, Larry.
There IS a way for ARC to extract files without having to use ARC. The IBM
version of ARC as it's normally distributed works like PAK does — you just
type ARC.ARC and it deARCs itself.
Steve,
I was speaking more about a way of allowing ARC to remain compatible, yet
still have the ability to use long filenames and perhaps even directory specs.
Regards, Larry.
Larry:
Seems to me that there is a utilitie that handles the long file name
problem for the Ami. As I recall it creates a file containing the 'real names'
and then changes the filename so that they are compatable with 'the others,'
and then envokes ARC on the whole mess. Was that vapor or does it exist?
73, bill
Bill,
it does indeed exist. It's called (I think ARCX, by J0RGEN Tomsen).
Regards, Larry.
You're probably thinking of J0RGEN Thompson's ARCEXE.ARC in DL 4.
Larry,
I agree, compatibility is paramount.
Larry:
Compatability in archives/archivers is important to me. I usually dl
with an IBM PC and since it is not good for anything else, I normally let it do
the de-arcing if 1) the files are not too large and 2) not too many to do. In
the second case, for instance, I actually dl'd a bunch of IBM files and
de-arced them on the Ami (there were just too many to spend the time fiddling
around with the PC). 73, bill
Larry, like it or not – ARC is a standard and a fairly reasonable one. I
would not tend to use another packing format unless it was more efficent than
ARC.
I don't believe that we should refuse any PAKed files, just that we should
encourage the use of ARC. If someone wants to use PAK, thats fine too.
Geo
Larry,
I object to converting everything to PAK format. Since ARC is both
smaller and more standard, I think that it should be used for everything except
possibly the new user type files. Please remember that most of us are paying
for CIS time, so dont make us all pay extra in order to help out some of the
new users.
IMHO
Jim
PS. When will we get Zmodem for downloads?
Jim,
If you read Larry's message to mean that we are proposing to convert
everything to PAK format, Larry either phrased it ambigiously, or you misread
it, or both.
PAK is a nice format in that no external utility (like ARC) is needed
to extract files. That's it's good point. The downside is that PAK files are
normally 10%-50% larger than the same files compressed with ARC.
The question is, since PAK compression is less efficient than ARC
compression with the obvious side effect of increasing download times, should
we (sysops) allow PAK files in the DLs or convert them to ARC files and
reupload (except where specifically forbidden, as in the case of PLAY.PAK) ?
Does the convenience of PAK's extraction overcome it's lack in
compression?
Personally, I'd rather limit PAK files and stay with ARC until and if
something else comes along that is more effecient than ARC (and hopefully
upward compatible with it). But, this is _your_ forum, what do _you_ want the
policy to be?
Steve,
One of the options you suggested makes a lot of sense to me – how about putting
it to a straight YES/NO vote before this thread wanders off into a general
discussion of ZOO, ZMODEM or whatever?
It seems that most of us are more interested in shorter download times than in
long filenames, fast unpacking, etc., and .ARC meets our needs better than any
of the present options. We don't have the disk space in the DLs to store the
same file as .ARC for some of us and .PAK for others. So let's make .ARC the
standard here until a more efficient (i.e., smaller files) archive program
comes along. The only exception that really makes any sense is UNARC.PAK for
new members.
If we agree, the Sysops would (as you suggest) convert files uploaded in other
formats to .ARC before putting them in the DLs (with suitable incantations
against "Trojan Horses" with .PAK suffixes!). Yes? No?
Vince
Vince,
As this thread is already running about 10-1 against we're gonna do
exactly as you suggested! Just thought we should have an open discussion about
it before hand. Thanks for your input.
Steve,
I'm sorry I misunderstood Larry's message. My vote, then is that the
Pak files should be kept to a minimum for all but the beginner files.
Thanks,
Jim
PS. Thanks to all the sysops for doing such a fine job here!
I believe that the Forum should allow files in ANY format; provided
that they are not copywritted, of course.
This of course means that I would support PAK files, but that it would
be nice if there were also ARC and/or ZOO versions of the file for those of us
who like saving a little $$$ by shortening our download time.
In the spirit of speeding downloads, I'd also like to suggest that CIS
impliment transfer protocols that are better suited for packet-switched
networks than the current ones…Wxmodem or maybe even Zmodem (!!!) would be a
welcome addition!
Scott – The ARCHIVES (203)938-9163 24hrs/day 2400baud 40meg!
Scott,
I'm afraid we really can't provide files in too many formats at one time. The
problem is one of storage and confusion.
Quick B protocol is meant for packet network transfers.
Regards, Larry.
The new "quick" version of CIS-B transfer protocol supports high-efficiency
network downloads. You need the protocol upgraded on both your terminal and in
CIS.
I've used TapCIS to download a long file at an effective baud rate of 2360 BPS
over TYMNET from Canada. Is that what you're looking for?
../greg
Sounds like just what I'm looking for! Where would I find this
'TapCIS' term program?
Scott
TapCIS is an MS-DOS program. I was posting that to show the capabilities in
"quick" B protocol. I assume that a bunch of the PD term programs will be
rewritten and will re-appear with QB sometime around new years.
TapCIS is an automated handler dedicated to running CompuServe for you. There
are a bunch of programs in this class. (MMM (Maug Message Manager)(Mac); Mac
Navigator; ATO (Automatic Terminal Operator)(MSDOS); TapCIS (formerly
ZapCIS)(MS DOS)). There are rumours of a comparable Amiga program due out
"real soon now" (mid January??), but I know nothing about it.
../greg
I'm rather concerned about the download time issue as well. Given my
druthers, I'd like to see most of the files in the DLs remain ARC files,
and only PAK the new-user things (like ARC!). The fact that you can
selectively pick things out of an ARC file gives me a much more secure
feeling. If the only way you can find out what's in a PAK file is to
run it–well, I just don't know that I'd like to give up the control I
have over my files.
I guess I'd rather not see a proliferation of files packed in a format
that has few benefits to offer over an existing well-established standard.
Regards,
Lee
Larry,
Since disk space must be limited on CIS, I can see little advantage in
allowing files to occupy more space than we know is necessary. While I'm all
for freedom of expression, wasting space in the DL area hurts us all. One
thing I would absolutely forbid is the existance of the same program in 2
different 'packed' forms. I have never used PAK, so I don't know how
convenient it is, but I certainly have reservations about not being able to see
what is in the file before executing it.
PAK files are used on a local bulletin board in my area. The reason it
seems to be popular is because you don't need the PAK program in order to unPAK
the file. Some people feel threatened by ARC, or maybe I should have said
afraid. Personally, I don't have anything against PAKed files, although I think
that because the file-size reduction of ARC vs. PAK, the files should be
provided in both formats. That could tend to effectively double the size of the
data libraries. If it came down to a choice between the two, I would have to
pick the ARC program. The health of my wallet is of concern here. The connect
rates can really add up. For bulletin boards it is fine, but for a commercial
($) service, you have to go with the least expensive choice.
-> Mike <-
Mike,
We have limited space here so we will not carry files in both PAK and
ARC'ed format.
Don
Larry,
I don't know if the problem is peculiar to Montreal, but I've lost the phone
line during a download more than once in the past, and expect that to happen
again in the future. Obviously, the bigger the file, the less chance I have of
a successful download.
The .PAK format is great for new users, but what the rest of us want is an
archive program that compresses *more* efficiently than .ARC. With Sculpt 3D,
etc., we're starting the see .arc files up to about 500K in the DLs, and I
don't dare try to download those!
Count me as a vote AGAINST archive programs that produce bigger files than .ARC
(including .PAK) and FOR any new archive program that gives us *smaller* files.
Regards, Vince
I don't feel, that ARC is so difficult to use, that another program should be
justified. ARC is a defacto standard and should remain so, also because it is
rather efficient.
J0RGEN
I am satsified with, and in this case, I am not in favor of changing over, but
if the compression can be improved, I feel that the change should be made. The
inconvenience of changing to a new standard should be small compared to the
gain. Remember, the defacto standard personal computer is the IBM PC (ugh!).
Jeff
Larry,
Since ARC is the standard now, and since it provides smaller files, I would
prefer to stay with it. If something came along that produced much smaller
files, I would say go with that.
By the way, it would be nice to see listed in the DL descriptions, the file
length soze one knowz what one's getting into before he starts. I'm sorry I
didn't do this when I uploaded some files earlier, but they're short.
Thanx,
Jerry.
Jerry,
The file size is listed in every file's title line. Here's an example:
BLANK.ARC/binary 23-Jul-87 7615 13
The title and file type come first, followed by the date of the upload, the
size of the file, and the number of downloads.
Regards, Larry.
Larry,
After I sent the stupid message, I realized what that number was. I sent a
later message saying essentially that I figured that out.
Thanks a lot for the response!!!
Jerry.
Jerry,
I saw that after I left the message, but figured I'd leave the answer anyway
because there are probably a few members who don't relaize it. We get a few
questions about file sizes every month, so it never hurts to point it out.
Regards, Larry.
Larry,
Disregard that last comment about file sizes – just got my head screwed on!
Eyeballs in sockets too. Boy, do I feel stupid!
Regards,
Jerry.
It's expensive enough to download at 1200 baud. The learning curve to unarc a
file is not so steep that it's worth incurring more expensive connect charges.
I have nothing against respecting the distribution wishes of the author,
however I do have reservations about ENCOURAGING the use of this new PAC
program.
One of the most attractive aspects of the Amiga is STANDARDIZATION. It is the
only computer with anything like IFF, and it is the only computer with a single
disk format (pretty much). These features of the Amiga are minor, yet very
important.
I have just moved into the world of Amiga, selling my IBM AT. I bought the
Amiga because of the wonderfull graphics and sound. I was also impressed with
the software available for it.
Now that I am developing software on the Amiga I have found a hidden feature
that I like, and that is deeper and deeper levels of standardization and
consistancy.
I strongly suggest that ARC be our STANDARD compression scheme, it is
efficient, commonly available, and full featured.
Adding a new type of compression only gives Amiga users one more thing to worry
about, one more crinkle in our alreadly complicated lives.
Thank You,
Sam Palahnuk
Larry,
I don't like the idea of somebody forcing a new program, no matter mow good it
might be, on the Amiga community. The stipulation that this program may only be
distributed in it's PAK'ed form I find totally unacceptable. If PAK is a good
program, then let it stand on it's own. I'd rather not have the program than be
forced into it.
If the SYSOP's agree that PAK format is a good one, then let it co-exist and
build up it's own following. If I were in your position, I'd send a polite but
firm message to the author that his forcing of a new protocol is unwelcome and
say thanks, but no thanks to the program in it's restricted form.
Is the PAK format PD or shareware?
I also, for one, would _NOT_ like a format that gives the program distributor
the full access to my computer before I've had a chance to view his files.
Remember the virus problem. This type of "execute me and see what I do"
distribution would make it that much easier for juvenile programmers to wreak
havoc on others.
David
Larry,
As I thought about my answer, I thought that it might be ambiguous so I wanted
to clarify one point:
I see no problem in an author making a request to have the program he offered
kept in the format that he also offered, if the format is a good one. I have a
problem with the "demand" that it be kept in that format or not distributed.
It is the "demand" that causes me to suggest the thanks, but no thanks
response.
David
The one file that has the 'demand' in it is PLAY.PAK. In this case, the demand
is understandable as the author of the Sonix player is also the author of PAK.
Steve,
I would find a "request" from an author attempting to see how people liked his
PAK format acceptable and understandable. A take it or leave it type of demand
is a subtle way of asserti the attitude that I find objectionable. I would
liken it to the used car salesman who says that you can have the car for deal
discussed IF you buy it RIGHT NOW. I say thanks, but no thanks to those deals
too.
David
P.S. Please don't take this the wrong way. I am not trying to cast aspersions
at the author, just criticizing his method of getting his work accepted.
PAK sounds like the SFX version of IBM's PKARC. If PLAY *must* be in PAK
format, then it is capable of unpacking itself. PAK also sounds like a useful
utility for people to use on their own, so it should be uploaded, too.
However, other than the PAK program itself, and any programs that have legal
restrictions limiting them to PAK, ARC should remain the standard archiver.
Follow standards except where legal or technical reasons force an exception.
If there are too many exceptions, THEN look at changing the standard.
ARC is easy enough to use. I support it's continued use for all non-limited
(by legalistic reasons) files.
../greg
I prefer ARC or ZOO to PAK. PAK is an impressive and interesting concept, but
on CIS, we pay for our time, and I prefer not to D/L more bytes than I have to.
On BBSs, the same is true, although it's not money that we are cost, it is time
and connect time limits.
Larry,
1. PAK files should be limited to new-user files. They are simple to
use, and do not tend to confuse the user. A note in the newuser bulletin
pointing out the specific files necessary for the new member (e.g. ARC) should
be in .PAK form.
2. ARC should in all other respects be treated as the standard for the
forum. It is a multi-system standard, and allows flexible treatment of files
for personal use, as well as saving DL time.
I have been Archiving most of my files, and enjoy being able to add files
to the Archive without unpacking the whole thing, as well as seeing what
is in there before deARCing.
3. Recently, a friend of mine handed me a disk with a PAK file on it.
I contained a rather interesting program that would eat disks. He did warn
me about it, but I shudder to think what would've happened to me if I had not
been warned. I like to be able to SEE what I'm getting.
Doug
Doug,
Is this guy still a 'friend'…handing you a program that will eat
disks doesn't sound like a very friendly thing to do.
Don
Don,
He DID warn me. However, I did warn everybody I knew about his little package.
Doug
Doug,
Although I agree *100%* with everything you've said, I'd like to make an
observation:
The PAK program has no bearing on Trojan Horses.
Consider: your PAKed program eats disks, you aren't told, you run it, it eats
your disk, you complain that PAK was the culprit since you couldn't see it
first. Okay, so you get an ARChive with a bunch of files in it. You deARC it,
and there's a file that's supposed to do something interesting. If you run it,
it eats your disk. What's the difference?
UNLESS YOU'RE WILLING TO DISASSEMBLE THE PROGRAM BEFORE RUNNING, OR RUN A
SPECIAL CHECKER PROGRAM AGAINST IT, THERE IS NO WAY TO VERIFY THE PROGRAM SAVE
RUNNING IT. PAKed or ARCed makes no difference.
YOU, sir, are doing a service to the Amiga community by spreading the news
about that dangerous file. And THAT is what it takes. The sysops here (heck,
the sysops on any reputable system) perform a deARC and cursory test run on
EVERY file submitted before it is merged — this is why the delay before they
appear sometimes. We'd do the same thing for PAKed files. It takes human
intervention to prevent the spread of Trojans… the library method used is
inconsequential.
Rick
Rick,
I stand by a statement I made in an earlier message. ARC is a 'proven'
program, and is known to be safe. Files that are deARCed can be checked fairly
quickly in a variety of ways, and those same files are files that will be used
often, or at least more often than the ARCed file itself, which is generally
referenced once, when you extract the files from it. Note that the ARCed file
is not executed.
In the case of PAKed files, each and every one is a new factor, and must be run
'on faith'. Consider… if I run 'strings' on a PAKed file, it tells me
nothing, as ordinary PAKed files have compressed data. The running of a PAKed
file could do something far different than you bagained for. I won;t go into
all the possibilities (why give the idiots any ideas?), but let's just say that
if something is amiss, it does not have to show up right then. After running
it, you may end up with a bomb awaiting its time, striking long after the PAKed
file is gone, leaving you no clues as to how it got there. I very much distrust
a program I can't dig at a bit, and far prefer an archive that decomposes into
the files that will be kept and used.
Regards, Larry.
I think that it would probably be a good idea to use PAK. It would make no
sense to stifle progress, adn ARC is, after all, getting old. PAK might take
advantage of some of the Amiga's strong points (as opposed to ARC, which is
available for most machines and probably has to compromise).
Erik,
I am the last one to stifle progress, provided that it is true progress. In
the case of PAK, the only advantage I can see is the ease of use. I can see a
lot of disadvantages with it, and so do not consider it progress. I don't think
the age of a program is necessarily indicative of its usefulness. ARC still
does the best all around job.
Regards, Larry.
I feel that .arc is not all that difficult to use, once you get the hang
of it. Better documentation would help that a lot. The one thing that I feel
that makes .arc more desirable is that it does condense the files more. This is
of concerned to me, because I upload and download files to Compuserve, and time
is money. If a file is 50% smaller then it will require 50% less time to
download, and that can make a big difference since Compuserve is so slow at
doing xmodem, and Amiga files are generally very large. As long as .arc files
are available from uploaded .pak files then it doesn't make any difference to
me, but if a .pak file is not duplicated into an .arc file then I feel that
download times would be greatly increased and
pak files should not be allowed in the forum. In fact I think that all binary
files that are uploaded without being .arc should be .arc by the sysops. I
realize that this increases the amount of work for the sysops, but it sure is
nice having a 200 block file condensed down to 100 blocks. Most of the files I
have delt with have been condensed pretty close to 50% because most programs
come with documentation and the documentation is condensed the most, so it
averages out to be nearly 50% in most cases.
Ed
I vote to keep ARC as the primary format untill something more efficient comes
along. For me, phone charges and connect charges combine to make downloads
nearly as expensive as commercial software. I don't want to see anything
expand the size of uploaded files more than it has to be. I'd like to see
faster protocalls, too.
KJ
Larry, having read 12 or so replies of 23 listed, I'm against it. Mike Shulte
(msg #97541) had a very telling point. The only thing wrong with ARC is it's so
darn BIG!
D.
Don,
Your point about ARC being large is a good one. You may be pleased to know
that we have a file in DL 4 called UNARC.PAK, which contains a small unARCing
utility and a short text file about using it. It is hoped that this will allow
a quick way for members to get a program to extract files. ARC is still
available for those that need the other functions.
Regards, Larry.
regarding UNARC, saw it. Using DISKMAN so needs full ARC program to work
properly. ARC is hardwired into it as a submenu. Wouldn't mind a
replacement,anyway.
Thanks, Don