Ark sucks. Arch is good as a distro but uses the most lame archive manager.
But the Arch installer only gives you a basic terminal based environment. Arch doesn't have a default archive manager, or a default desktop environment! After the initial installation - the graphical environment and all of the other software selections are completely up to the user to configure and install.
However, some of the Arch-derived distros, which provide a fully configured Arch desktop system might supply Ark by default. Usually only the ones that install KDE/Plasma as the default desktop. Any that install a Gnome based system will typically use file-roller. But in my experience, both archive managers integrate well with the file managers in their respective Desktop Environments. I've never had a problem with either of them. Both can handle all of the most common compression formats - as long as you have the appropriate tools installed for each file-type.
That said, I'm a bit of a terminal junkie. I tend to use the terminal for most things. I find it a lot more convenient to issue a quick one-liner, use a bash alias, or fire off a script (I write scripts for everything), than to clumsily fire up some GUI program, wait for it to load, point and click through a bunch of options, before starting whatever task I want to get done.
Just switch to a terminal (I always have at least one running), two seconds of typing and BAM! Job done! Or at the very least, job running in the background whilst I get on with other things! XD
the 7-zip for Windows runs perfectly with Wine - 7zFM.exe and you compress whatever you want at whatever level you want and wherever you want.
Why are you running the Windows version through Wine? If you are running Arch - there should be a native Linux version of 7zFM available - if not in the repos - then in the AUR..... At least there always used to be - I haven't used Arch in a good number of years though, so perhaps this situation has changed. It always used to be part of the p7zip package.
Going back to
@blackneos940 's post - if you are compressing large disk images of virtual machines - it's going to take a long time and potentially use up a lot of system resources to do so. And from what I recall, your PC was fairly low-spec.
The amount of time taken to compress/decompress will depend on things like: the algorithm used, the compression ratio, the available system resources of the computer performing the compression/decompression (memory, processor speed, the number of processor cores, number of other processes running etc)
The other thing to bear in mind is that the amount of compression that is applied to an archive also depends on the type of files that you are compressing.
If you have a lot of files that are already in a compressed format (e.g. certain video/audio files, data files, or other archive files) it may be impossible to compress those files much further. So no matter what compression algorithm you're using - the archive size may not be much smaller than the original files it contains.
Re:
@rado84 's recommendation of 7zip:
Avoid using .7z on it's own for compressing backups on Linux. The .7z format does NOT preserve file-permissions (the owner and group permissions) for files.
It says so right there in the man-page for 7z:
Backup and limitations
DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :
- 7-zip does not store the owner/group of the file.
On Linux/Unix, in order to backup directories you must use tar :
- to backup a directory : tar c - directory | 7za a -si directory.tar.7z
- to restore your backup : 7za x -so directory.tar.7z | tar xf -
7z is a great format and can provide compact archives, but I only use 7z on its own if I don't care about preserving file-permissions. For example, if I'm compressing a folder containing some files to send to somebody, then I might use .7z.
I don't use .tar.7z (as per the quote from the 7z man-page) because decompression/extraction becomes a 2-stage operation in the GUI. It's a two stage operation in the terminal too. But at least in the terminal you can chain the two commands together into one operation - as per the example quoted from the man-page.
Personally, I often use tar.xz for backups, or .tar.gz if I want it done quickly and when file-size is not an issue. With .tar.xz and .tar.gz - it's still technically a two stage operation to extract, but unlike .tar.7z - both steps can be performed in a single operation/command in the GUI (and in the terminal using one tar command).
Also, the .xz and .7z compression algorithms are very comparable in terms of speed and file-size. Both provide nice, compact archives (smaller file-sizes), but they do use a little more time and memory to compress and decompress files than gzip, which is by far the fastest algorithm.
With xz, depending on the compression ratio and the types of files being compressed, you can typically get the archives file-size down to between 8%-18% of the original size. Which again - is comparable to .7z.
If you wanted the smallest possible file-sizes, and the memory usage and time taken are not an issue - you could use xz with the -e option (extreme) and the compression ratio set to -9 - which tries to get the file-size as small as possible. But that will take much, much longer to compress and decompress.
You can do the same with 7z too.
By contrast - with gzip, you're typically looking at the archive being approximately 12%-26% of its original size. And depending on the type of data being compressed/decompressed and the compression ratio - it is typically 3 to 6 times faster than 7z, or xz.
So if you want fast compression, and file-size is not so much of an issue - gzip is your best bet. gzip is the fastest algorithm for compression and decompression and uses less memory/system resources, but yields slightly larger files. In that scenario - I'd recommend .tar.gz.
If you want the smallest files - at the cost of longer compression/decompression times I'd go with .tar.xz
Or if you want something slightly faster than xz or 7z, but with better compression than gzip, another good option is bz2 (bzip2) (using the .tar.bz2 extension).
Wrapping things up - personally - I tend to use .tar.xz or .tar.gz for backups, or whenever it's important to preserve permissions.
For quick and dirty archives to send to other people, I'll use .7z when preservation of permissions is not a priority, or just use plain old zip!
Just to back up everything I've said, here's a quick experiment:
I have a folder which contains 45Mb of c++ source code. All UTF-8 text files with .h or .cpp file extensions and some other random text files containing notes and things. There may also be some git repo data in there too.
Code:
$ du -sh JasProjects
45M JasProjects
Creating a few archives - using the default compression ratios on each and using the time command to time each operation:
Code:
$ time tar czf JasProjects.tar.gz JasProjects
real 0m1.310s
user 0m1.075s
sys 0m0.576s
$ time tar cJf JasProjects.tar.xz JasProjects
real 0m3.104s
user 0m2.775s
sys 0m0.560s
$ time ( tar c - JasProjects | 7za a -si JasProjects.tar.7z )
# Verbose output from 7za snipped..
real 0m8.424s
user 0m11.231s
sys 0m1.416s
That created a .tar.gz, a .tar.xz and a .tar.7z and we can see how long each operation took.
Now listing the files, so we can see their sizes:
Code:
$ ls -lh JasProjects.tar.*
-rw-r--r-- 1 jason jason 4.3M Apr 8 16:29 JasProjects.tar.7z
-rw-r--r-- 1 jason jason 6.1M Apr 8 16:29 JasProjects.tar.gz
-rw-r--r-- 1 jason jason 4.3M Apr 8 16:29 JasProjects.tar.xz
3
So looking at the output above - I get the following results:
From fastest to slowest, with the final size and the percentage of the original directory size:
.tar.gz in 1.3 seconds => 6.1Mb => 13.5% of the original size
.tar.xz in 3.1 seconds => 4.3Mb => 9.5% of the original size
.tar.7z in 8.4 seconds => 4.3Mb => 9.5% of the original size
So in this case - the results were fairly close for all three methods in terms of file-size. gzip was by far the fastest algorithm - almost 3 times faster than xz and just over 6 times faster than 7z, which was a big surprise. But gz yielded the largest file.
xz and 7z yielded identical sized files, but xz was more than twice as fast as 7z. Which is interesting, because even I thought 7z would be a bit faster than that!
Interesting!
I think I'll go back to playing Need For Speed, while compressing my *BSD and TAILS VMs..... 
..... :3
