[B]StuffIt formats aside, when one considers that the BSD subsystem of OS X includes programs for zip (.zip), gzip (.gz), bzip2 (.bz2 and .bz), tar (.tar), and the disused compress (.Z), I think that Apple should provide Finder support for, at the very least, decompression of these formats, without the need to open either Terminal or a third-party program
They should go even further and implement live-browsing of those archives in a normal finder window (possibly with an additional column like "compression" which indicates how heavy the file got compressed in percents). Given the fact that most Linux distribution already got this feature it is a shame that Apple hasn't come up with this yet...
StuffIt formats aside, when one considers that the BSD subsystem of OS X includes programs for zip (.zip), gzip (.gz), bzip2 (.bz2 and .bz), tar (.tar) ... I think that Apple should provide Finder support for, at the very least, decompression of these formats...
Nitpicking, but a .tar file by itself does not utilize compression, right?
It may not utilize compression, but what it achieves is compression. Explaination below.
Simple archiving of files (eg tarring) DOES compress them. Due to the way disks work, instead of allocating a set of bits or bytes to a file, the file system allocates "blocks" (but I'm sure you know that).
On my hard drive, they are 4KB each. You will therefore have roughly 2KB of wasted space per file. Now times that by 100,000 files (average file system), and you get 200MB of wasted space.
This particular instance of wasted space is eliminated when you archive with tar. What you achieve is essentially compression.
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
This is probably why tar is used for light-weight compression on *nix systems. Tar works well for numerous files that are smaller than the (minimum) block-size.
Live browsing of archives, while convenient, has interesting implications with regards to user interfaces. There are issues with user awareness of the distinctions between files and archives. Many or perhaps even most users are incapable of grasping the difference let alone capable of discerning which they are working with.
With that said, I hope apple implements an extensible compression API with an easily accessible front end via the finder. They could also set up a server for distributing certified modules such that users would be prompted to download the correct, missing module when trying to decompress a file. (ala quicktime)
Live browsing of archives, while convenient, has interesting implications with regards to user interfaces. There are issues with user awareness of the distinctions between files and archives. Many or perhaps even most users are incapable of grasping the difference let alone capable of discerning which they are working with.
If done correctly, the user need never know that the file is in a compressed archive. Besides, users understand disks, what's so different about archives?
This is why disc images are so good. Because users understand disks. Any user can figure out, "Ok, I've got files on this disk, so I'll drag them to the disk I want" (or double click the installer).
Now, archives are more complex. They are a folder, which has morphed into a single file. You need to extract the folder from that file before it is a folder again. Now you've extracted it, you have a folder and the original file.
This is simple to you or I. However, Joe C. Illiterate will go straight into *DUH* mode when you tell him an archive is a folder compressed into a single file that you need to expand for your files to appear.
-------------
The other solution is to have archives behave like folders (ala XP). Except users get pissed off when the performance of their computer halves due to decompression overhead.
If done correctly, the user need never know that the file is in a compressed archive. Besides, users understand disks, what's so different about archives?
I'm definitely knit-picking here but bear with me. The distinction isn't a huge problem but Apple has a history of limiting their interfaces to account for rare but confusing/dangerous scenarios.
If a user is unaware that they are working with an archive and then try to share a portion of the archive contents with another user, problems can arise. File sizes will start shifting or the files might be emailed elsewhere without the user realizing that the recipient must have special utilities and knowledge to view the files.
If clueless user has a CD's worth of mp3s in a compressed archive and then tries to burn them for a PC user... what happens? Either not all of the files will fit, or the PC user must be know how to extract the files. This is a simple scenario for most of us to understand Unfortunately, we can't expect the vast majority of users to fully understand what is going on behind the scenes and to then conceive a work around.
All but a couple of the 40-60 year old office workers at my workplace would be completely lost. Similarly, the education majors and young teachers I know would be confused. "What? This is a special folder which must be treated differently?" The designer in the office next to me would certainly run into problems exchanging quark files (and their ingredients) with sister companies and publishers. Frequently, it is necessary to re-explain the options for embedding graphics and fonts. There are all kinds of implications for what types of applications the recipient of such a file must have. Also, it causes the file sizes to change in a manner contrary to the designers intuition.
Hiding the distinction between folders and archives will confuse users. Users must treat the folders and archives differently or they will eventually run into task ending failures in their workflow.
It may not utilize compression, but what it achieves is compression. Explaination below.
Simple archiving of files (eg tarring) DOES compress them. Due to the way disks work, instead of allocating a set of bits or bytes to a file, the file system allocates "blocks" (but I'm sure you know that).
On my hard drive, they are 4KB each. You will therefore have roughly 2KB of wasted space per file. Now times that by 100,000 files (average file system), and you get 200MB of wasted space.
This particular instance of wasted space is eliminated when you archive with tar. What you achieve is essentially compression.
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
***NITPICKER 2000 BOT DEACTIVATED***
Barto
Nitpick? You are still not correct, technically or not. TAR, while often used with compression software, has nothing to do with compression.
Sure, you are possibly reducing size-on-disk, which is variable from machine to machine, but not the actual size of the files. The reduction of size-on-disk is really cluster size dependent, not as a function of TAR.
Heck, does moving your 100k files to a drive with smaller cluster size count as compression? Or move those files to a large cluster HD count as decompression?
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
From a user's perspective, turning something into an archive and saving 200MB of space is compression, algorithmic or not.
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
From a user's perspective, turning something into an archive and saving 200MB of space is compression, algorithmic or not.
Barto
<ultra nitpicking>
Hrmph. With a standard block size of 1k, that means a max of 1023 wasted bytes per file. This means it'd take a tar archive of 205,000 files to save 200MB, and that's the low end. :-)
Given an average wastage of 512 bytes/file, it'd take a tar archive with 2048 files to even recover 1MB of disk space. I doubt the user would even notice any space savings of under 1MB. 2048 is still a rather large archive.
Personally, I wouldn't extraction from a tar file "decompression" at all, I'd call it "unpacking". :-)
Hrmph. With a standard block size of 1k, that means a max of 1023 wasted bytes per file. This means it'd take a tar archive of 205,000 files to save 200MB, and that's the low end. :-)
Given an average wastage of 512 bytes/file, it'd take a tar archive with 2048 files to even recover 1MB of disk space. I doubt the user would even notice any space savings of under 1MB. 2048 is still a rather large archive.
Personally, I wouldn't extraction from a tar file "decompression" at all, I'd call it "unpacking". :-)
</ultra nitpicking>
Last time I checked, 90% of hard drives have 4KB block sizes. It would only take about 100,000 files. The example I used was tarring an average hard drive, presumably to backup on tape.
Now, I wouldn't call it decompression. But what I did say (and keep saying) is from an average user's perspective, in fact any user's perspective, untarring achieves the same as decompression. Untarring is effectively decompression at the user side.
You would need to be moving a lot of files, and the process is not the same as associated with a compressed file like ZIP or SIT (double-clicking an archive to create a folder).
Someone else want to jump in with a reason why I *shouldn't* close this thread?
Because I want to add that this appears to be a user interface problem, and it would appear to me that displaying a compressed archive as a disk image with a tight belt, or a zipper, or some other indication that it wasn't just a disk image, would solve the "is it many or is it one" question elegantly enough.
OK, now you can close the thread. Before anyone has time to shoot down my idea.
Comments
Originally posted by andrewm
[B]StuffIt formats aside, when one considers that the BSD subsystem of OS X includes programs for zip (.zip), gzip (.gz), bzip2 (.bz2 and .bz), tar (.tar), and the disused compress (.Z), I think that Apple should provide Finder support for, at the very least, decompression of these formats, without the need to open either Terminal or a third-party program
They should go even further and implement live-browsing of those archives in a normal finder window (possibly with an additional column like "compression" which indicates how heavy the file got compressed in percents). Given the fact that most Linux distribution already got this feature it is a shame that Apple hasn't come up with this yet...
Originally posted by andrewm
StuffIt formats aside, when one considers that the BSD subsystem of OS X includes programs for zip (.zip), gzip (.gz), bzip2 (.bz2 and .bz), tar (.tar) ... I think that Apple should provide Finder support for, at the very least, decompression of these formats...
Nitpicking, but a .tar file by itself does not utilize compression, right?
Simple archiving of files (eg tarring) DOES compress them. Due to the way disks work, instead of allocating a set of bits or bytes to a file, the file system allocates "blocks" (but I'm sure you know that).
On my hard drive, they are 4KB each. You will therefore have roughly 2KB of wasted space per file. Now times that by 100,000 files (average file system), and you get 200MB of wasted space.
This particular instance of wasted space is eliminated when you archive with tar. What you achieve is essentially compression.
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
***NITPICKER 2000 BOT DEACTIVATED***
Barto
Live browsing of archives, while convenient, has interesting implications with regards to user interfaces. There are issues with user awareness of the distinctions between files and archives. Many or perhaps even most users are incapable of grasping the difference let alone capable of discerning which they are working with.
With that said, I hope apple implements an extensible compression API with an easily accessible front end via the finder. They could also set up a server for distributing certified modules such that users would be prompted to download the correct, missing module when trying to decompress a file. (ala quicktime)
Originally posted by iBrowse
As far as I know, WinZip can open .sit files just fine.
I just tried and can't get it to do it
Live browsing of archives, while convenient, has interesting implications with regards to user interfaces. There are issues with user awareness of the distinctions between files and archives. Many or perhaps even most users are incapable of grasping the difference let alone capable of discerning which they are working with.
If done correctly, the user need never know that the file is in a compressed archive. Besides, users understand disks, what's so different about archives?
Now, archives are more complex. They are a folder, which has morphed into a single file. You need to extract the folder from that file before it is a folder again. Now you've extracted it, you have a folder and the original file.
This is simple to you or I. However, Joe C. Illiterate will go straight into *DUH* mode when you tell him an archive is a folder compressed into a single file that you need to expand for your files to appear.
-------------
The other solution is to have archives behave like folders (ala XP). Except users get pissed off when the performance of their computer halves due to decompression overhead.
Barto
Originally posted by 1337_5L4Xx0R
If done correctly, the user need never know that the file is in a compressed archive. Besides, users understand disks, what's so different about archives?
I'm definitely knit-picking here but bear with me. The distinction isn't a huge problem but Apple has a history of limiting their interfaces to account for rare but confusing/dangerous scenarios.
If a user is unaware that they are working with an archive and then try to share a portion of the archive contents with another user, problems can arise. File sizes will start shifting or the files might be emailed elsewhere without the user realizing that the recipient must have special utilities and knowledge to view the files.
If clueless user has a CD's worth of mp3s in a compressed archive and then tries to burn them for a PC user... what happens? Either not all of the files will fit, or the PC user must be know how to extract the files. This is a simple scenario for most of us to understand Unfortunately, we can't expect the vast majority of users to fully understand what is going on behind the scenes and to then conceive a work around.
All but a couple of the 40-60 year old office workers at my workplace would be completely lost. Similarly, the education majors and young teachers I know would be confused. "What? This is a special folder which must be treated differently?" The designer in the office next to me would certainly run into problems exchanging quark files (and their ingredients) with sister companies and publishers. Frequently, it is necessary to re-explain the options for embedding graphics and fonts. There are all kinds of implications for what types of applications the recipient of such a file must have. Also, it causes the file sizes to change in a manner contrary to the designers intuition.
Hiding the distinction between folders and archives will confuse users. Users must treat the folders and archives differently or they will eventually run into task ending failures in their workflow.
Whenever there is a problem with Quark, it's Quark's problem, not Apple's. No exceptions.
Barto
What would be really useful is a command line way of keeping the files resource fork when transfering the file over the internet.
Dobby.
Originally posted by Barto
It may not utilize compression, but what it achieves is compression. Explaination below.
Simple archiving of files (eg tarring) DOES compress them. Due to the way disks work, instead of allocating a set of bits or bytes to a file, the file system allocates "blocks" (but I'm sure you know that).
On my hard drive, they are 4KB each. You will therefore have roughly 2KB of wasted space per file. Now times that by 100,000 files (average file system), and you get 200MB of wasted space.
This particular instance of wasted space is eliminated when you archive with tar. What you achieve is essentially compression.
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
***NITPICKER 2000 BOT DEACTIVATED***
Barto
Nitpick?
Sure, you are possibly reducing size-on-disk, which is variable from machine to machine, but not the actual size of the files. The reduction of size-on-disk is really cluster size dependent, not as a function of TAR.
Heck, does moving your 100k files to a drive with smaller cluster size count as compression? Or move those files to a large cluster HD count as decompression?
Po-tay-to, po-tah-to
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
From a user's perspective, turning something into an archive and saving 200MB of space is compression, algorithmic or not.
Barto
Originally posted by Barto
I didn't say TAR is compression. I said this:
I think it is quite reasonable to call the extraction of a tar archive "decompression" from the user's perspective, if not the developer's perspective.
From a user's perspective, turning something into an archive and saving 200MB of space is compression, algorithmic or not.
Barto
<ultra nitpicking>
Hrmph. With a standard block size of 1k, that means a max of 1023 wasted bytes per file. This means it'd take a tar archive of 205,000 files to save 200MB, and that's the low end. :-)
Given an average wastage of 512 bytes/file, it'd take a tar archive with 2048 files to even recover 1MB of disk space. I doubt the user would even notice any space savings of under 1MB. 2048 is still a rather large archive.
Personally, I wouldn't extraction from a tar file "decompression" at all, I'd call it "unpacking". :-)
</ultra nitpicking>
Originally posted by John Whitney
Personally, I wouldn't extraction from a tar file "decompression" at all, I'd call it "unpacking". :-)
i usually call it untar'ing.
Originally posted by John Whitney
<ultra nitpicking>
Hrmph. With a standard block size of 1k, that means a max of 1023 wasted bytes per file. This means it'd take a tar archive of 205,000 files to save 200MB, and that's the low end. :-)
Given an average wastage of 512 bytes/file, it'd take a tar archive with 2048 files to even recover 1MB of disk space. I doubt the user would even notice any space savings of under 1MB. 2048 is still a rather large archive.
Personally, I wouldn't extraction from a tar file "decompression" at all, I'd call it "unpacking". :-)
</ultra nitpicking>
Last time I checked, 90% of hard drives have 4KB block sizes. It would only take about 100,000 files. The example I used was tarring an average hard drive, presumably to backup on tape.
Now, I wouldn't call it decompression. But what I did say (and keep saying) is from an average user's perspective, in fact any user's perspective, untarring achieves the same as decompression. Untarring is effectively decompression at the user side.
Barto
Can we all just agree that this semantic equine has been well and truly sadonecrobestialized and move on, or let this thread die?
Barto
Someone else want to jump in with a reason why I *shouldn't* close this thread?
Originally posted by Kickaha
Someone else want to jump in with a reason why I *shouldn't* close this thread?
Because I want to add that this appears to be a user interface problem, and it would appear to me that displaying a compressed archive as a disk image with a tight belt, or a zipper, or some other indication that it wasn't just a disk image, would solve the "is it many or is it one" question elegantly enough.
OK, now you can close the thread. Before anyone has time to shoot down my idea.