You are puzzling me a bit. What exactly do you consider to be the
overhead? Code size? Memory consumption? CPU time?
When it comes to compression, the combination of compressed data and
decompression code should be larger than uncompressed data, everything
else is secondary. The secondary stuff might still affect some users,
but it is not a general problem.
> So... even in 2003, I really don't know of many (any?) tasks which
> would benefit from bzip2, considering the additional memory and
> cpu overhead.
That overhead will become less important with time. And if we will
merge bzlib anyway, we may as well do it today.
But I do agree with you that some choices made by the maintainer were
rather stupid. And one of them is the reason for this thread and
appears to be the whole point behind your argument.
-- The cost of changing business rules is much more expensive for software than for a secretaty. -- unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/