Do you think that the name of LZ5 should be changed?

[inikep]

I received a request to change the name of LZ5. More details are at https://github.com/inikep/lz5/issues/10
I am waiting for your opinion.

[nemequ]

The name may not be a problem for people on encode.su, but people on encode.su are definitely not typical users. Before answering, consider a random internet user who knows little to nothing about compression. Do you think they may be misled by the name into thinking:

* LZ5 is an improved version of LZ4 (compatible or not)?
* LZ5 is created and/or supported by the same people who wrote LZ4?

Even for a more technical user who can understand the difference between a new version and a fork, do you think they're likely to assume LZ5 is a friendly fork which makes some slightly different trade-offs, or are they likely to think the fork was undertaken to correct some issue, such as security, licensing, unresponsiveness, maintainership, etc.?

In short, I don't know why "the name shows LZ5 is related/a fork of LZ4 but it's not compatible with LZ4" is a "No" option not a "Yes" option. The whole problem with the name is that it shows LZ5 is related to LZ4; I don't think random people are going to understand the finer points of it being a fork, and even if they do the 5 implies that the fork is better, not just different. I get that you're trying to be up-front about the fact that LZ5 is derived from LZ4, and that's admirable, but I think in this case it causes a lot more problems than it solves, and that in the end it may be detrimental to both projects.

[inikep]

Do you think they may be misled by the name into thinking: LZ5 is an improved version of LZ4 (compatible or not)?

This makes a huge difference. If LZ5 would be compatible with LZ4 then the name can be LZ4-NG (we already have lz4x and smallz4).

I don't think random people are going to understand the finer points of it being a fork

I think that people able to download and compile LZ5 from GitHub will also read and understand a description of the project.

[Shelwien]

While we're at it, lets also rename LZ78.
And copyright all small numbers.

[jibz]

While we're at it, lets also rename LZ78.
And copyright all small numbers.

As I am sure you are aware, the number in this case is a year, and the authors of the two papers are the same, so it doesn't really work that well as an argument.

I think the question is if the '4' in LZ4 may be interpreted as a version. If it is, then LZ5 would indicate a successor of some sort. Like bzip2 was the successor to bzip. If that is the case then it could potentially be confusing, like say if you forked Python 2.7 and named your fork Python 2.8.

One thing the name accomplishes is that it sets itself apart enough to convey that it is not (directly) compatible.

I imagine one problem nemequ envisions is when the two are side-by-side in a library like squash. If you're an end user and looking through the list of available codecs and see LZ4 and LZ5, would you be likely to think they're two version of the same?

Of course, if you're the kind of end user who thinks they must both be really old versions of LZ78 then nothing will help you .

[inikep]

I think the question is if the '4' in LZ4 may be interpreted as a version.

But where are LZ1, LZ2, and LZ3? If I would see in lzbench/squash e.g. LZXX8 next to LZXX9 I would assume that LZXX9 is not replacement for LZXX8 because then LZXX8 should be removed.
My idea with the name of LZ5 was based on LZRW (https://en.wikipedia.org/wiki/LZRW) which gives numbers for different, not compatible algorithms.

[nemequ]

I think that people able to download and compile LZ5 from GitHub will also read and understand a description of the project.

Maybe, maybe not. People doing that aren't really who I'm concerned about, but being able to clone a project on GitHub and compile it isn't a very high bar… While a lot of people on GitHub do know what they're doing, there are also a lot of people out there who just go to a bootcamp or get some crappy certification, and really don't understand what they're doing.

I imagine one problem nemequ envisions is when the two are side-by-side in a library like squash. If you're an end user and looking through the list of available codecs and see LZ4 and LZ5, would you be likely to think they're two version of the same?

Exactly.

There are a lot of times when the string "LZ5" might be presented to someone who may not know the history, not just people checking the project out on GitHub. Choosing a codec in Squash is one example, but what about when it's presented in lzbench, the Squash Compression Benchmark, etc.? What happens if a filesystem decides to add it as an option for transparent compression? What about marketers including "LZ5 compression" in a list of features, maybe alongside a competitor who supports "LZ4 compression"?

But where are LZ1, LZ2, and LZ3? If I would see in lzbench/squash e.g. LZXX8 next to LZXX9 I would assume that LZXX9 is not replacement for LZXX8 because then LZXX8 should be removed.

LZ4 is, AFAIK, the first real product to use the LZ# scheme. "LZ77" and "LZ78" aren't presented to non-programmers, but the name of a codec using LZ77 or LZ78 *is*.

My idea with the name of LZ5 was based on LZRW (https://en.wikipedia.org/wiki/LZRW) which gives numbers for different, not compatible algorithms.

You're making my point here... people (correctly) assume that LZRW1, LZRW2, etc., are part of the same family/project, written and supported (or not) by the same author.

All I'm saying is that, without additional context, it's quite reasonable to assume that LZ4 and LZ5 are related in ways they aren't. You're not always going to be able to provide context. Given the choice, I think it's better to avoid a name that can so easily be misinterpreted.

[encode]

But where are LZ1, LZ2, and LZ3?

How about IBM's LZ1 and LZ2?
http://domino.research.ibm.com/tchjr...1!OpenDocument