Hi: I tried with gzip and bzip2 but they gave errors.

Use the 'xz' tool. It's been in Slackware since version 13.0 and will already be installed since it's used to unpack the Slackware packages.

To use it:

xz -d <file.xz>

1 members found this post helpful.

Thanks for your answer, but wasn't gzip enough complication for the user to make it greater? Gzip manual: slightly over a hundred lines. xz: over a thousand.

If the files are tar.xz, then just use tar.

How about ark? Its man is 104 lines. Not that I personally consider it a strength: a longer manual is probably longer because it's more thorough.

Given that I gave the answer - xz -d to decompress, and another poster gives an answer to uncompress tar archives compressed with xz, I don't know what your reply is supposed to mean.

1 members found this post helpful.

Usually tools are validated by its intended use, not by the length of the manual. xz offers much greater compression, that is why it is used, not because the man-page may be longer or shorter.

Do you not see the world is ever more and more complex? Somebody says: let's study physics! I'd like to understand the place were I live. How illusory a statement. In his entire life he won't be able to understand but a tiny chapter of physics. Do you like that? I don't.

Why the need for more compression? Because software grows larger by the minute. What's the need? Software grows more complex by the minute. What's the need? More complex particle collision simulation. Oh, no! A new multimedia format.

Well, nothing is keeping you from going back to an 8086 and run DOS or CP/M on it, reduces complexity. But then, I guess you like to browse the web with pictures (better picture compression -> faster browsing, but more complexity), ... .
Ranting about increasing complexity in software is useless, it will happen anyways. Having said that, I never needed to even look at the man-page for xz, it behaves exactly like gzip and bzip2 from a user point of view. If you can handle one, you can handle the others

A concomitant of complexity can be choice. In this case, xz is usually a better choice for compressing data since it achieves better compression - faster download time, lower storage costs etc. The downside is that for machines which are not as highly powered (ARM for example, which is why the packages are still gzipped) and do not have as much RAM, xz can present problems.
As long as you learn the limitations and benefits of each, you can make well informed choices. Should you become overwhelmed by choice, you just move upwards and think about what it is you want to achieve and what are you prepared to lose or not profit from by not paying attention to certain details. e.g. for some things I just don't care about the fine details, so I might lose out on a few monetary savings from time to time but at the expense of not having to spend time doing something I don't want to.

I personally like to have a multitude of choices for certain situations/topics because it allows me fine control over my experience. For example, I find Windows almost untenable now because it's so much effort to turn off the defaults which are (IMO) intended for less experienced users: I want to be able to make fine adjustments. However, for other things such as making my window manager or X server work, I don't care about fine tuning - it's not relevant to me and I just want 'on and work'. The great thing about Linux distributions (Slackware especially) is that you can always go and change any setting you want without restriction, as the options are open.

Choice is a good thing. Too much choice simply means you need to find ways to deal with it :-)

I use an utility called "unp". On your terminal you just have to type "unp file" and it unpacks it. It has support to a lot of filetypes and I believe xz is included.

1 members found this post helpful.

Yes, I see the three of them admit the same -dv option I always use. I have connected an 8086 with one of its pins connected to Vcc to set it in minimum mode, demultiplexed address/data and buffered all the lines, built a dynamic memory controller from scratch, no LSI chip, based on the memory data sheet specifications and used a Motorola 6845 CRT controller to build the video section around it. All 16 bits! How many wires! The predecesors used 8-bit data buses, easy to wire. Then I began to write an editor, then an assembler which was really a set of macros when, well, I had an IBM PC for some days and from then on my little machine was more and more relegated until I forgot it. The IBM ran an 8088, 8-bit only external data bus at 3.58 MHz. Mine ran at 8 MHz! What a fool! I should have stuck to my 8086.

If you want to compress a file/folder:

tar cfpJ the archivename.tar.xz filename

to decompress do as dugan said above

2 members found this post helpful.

Well, maybe that was an overkill already just this one would have been enough. Or even that one, but I'm not sure that you can still find one on Ebay

Don't worry, i have just built a Z80 system to get out of the supercomplexity thing. For all things outside the system it is unable to communicate with them. Too slow, even running at 20MHz. Who cares. Have computers to work interactively? Certainly not.

EDIT: your knowledge of history amazes me! IBM has an original of Pascal's machine. The 8080 once was present in nine of ten desktops and physically larger machines. I worked with some of them. This one started the whole thing.