So the question for squashfs (most likely livecd/usb) users and/or kernel users. What compression method do you use?

Same question for kernel/busybox.

Most popular is lzma (xz) and deflate (gzip) but I know some were using lz4 or lzo but the latter in special applications (embedded, or requiring speed or low memory overhead)

I have an "ulterior motive" in this question - there is relatively new compression (zstandard) I mean that some claim is popular. Well from my experience with compression and compressors it's not, not to mention the compressor itself is overbloated - one and half megabyte for single compressor is, I don;t know how to call it other than bloatware. And the compressor is not that fantastic either.
But I'm trying to establish the facts. So what is it for you?

PS. I also encourage everyone to vote in poll, that's what it's for.

So why don't you just ask that question instead?

AFAIU, Arch Linux uses zstandard for its packages now. That is good enough for me.

Linux live systems include the tools needed to decompress the squashfs into RAM, so once that is done the compression is passé and irrelevant.
I find the question what they use of minor interest; even if I planned to create sth like that myself: Surely it depends on the size of the image and the projected space available (meaning: does it have to fit on a CD or some such). With those two figures, just use what fits best.
Generally speaking, the higher the compression the slower it is to unpack. Might also be a factor.

I want to establish whether it's popular not strictly who uses it. For example if 5 people use it, what does it tell? And if 5 out of 10, or 5 out of 10000 use it what does it tell? There is a difference is it?

but you will hardly get enough votes here.

I don't make live CDs or squash kernels, but I do use zstd when backing up my filesystem with fsarchiver

Is it better than lzma (xz/lzip/7z)?

What is your kernel/busybox compressor, do you know?

zstd seems to be faster than xz compression for my situation, backing up a single-partition Linux install. Howver, there's a point of diminishing returns. Backing up my current Fedora installation:
It wasn't worth the extra time!

The question is - pointless.
There's various requirements, and different compression algorithms fulfil them differently:

• compression rate
• speed of compression/decompression
• availability on other systems
• size of executable (as you pointed out)
• ...possibly more...

The question is: what is the best for your particular situation?

zstd has good compression - currently the highest possible AFAIU - but I doubt it's very fast.
One can also adjust compression ratio (not only zstd has that feature). As you can see in the previous post, higher rates result in much higher compression times. But that is not necessarily true for the decompression.

You haven't yet told us your specific use case - beyond your vague opening statement.

Sorry, I wasn't around for long time. Independent, external conditions...


Maybe for you. If you read my question post you would know it's to establish actual state of things and popularity not requirements. If I asked what is the browser or distro you use, would you tell me "There's various requirements..."?

And zstd does not have highest compression ratio, lzma has. Zstd is faster though. But the question was about something else.

I don't mind your or anyone elses reasons to use it, I want to know how popular are different codecs to establish facts against claims.

Which is very different from asking "is compression A better than compression B".
That's pretty close to exactly what I would answer, yes. I definitely wouldn't say "it's the best because I use it".

Yeah, I understand... specially I never asked that (which compression is better...)

I understand that too. I would answer: firefox or dolphin or opera, but it's just me, I'm far too ordinary, that's true.

I beg to differ:

In my topic question?
Yeah, right.
If you have something to say about topic question, I'm all ears. Otherwise, let others to answer. You're off topic.