On Tue, Sep 23, 2014 at 11:30 AM, Ralph Eastwood <tcmreastwood_AT_gmail.com> wrote:
>
> Some time ago, there was some discussion about sbase's tar with
> compression. I was wondering if this compression tool would
> necessarily have to be a standard gzip/bzip2/xz implementation.
>
For sbase I think it should be, because gzip and bzip2 are the norm.
Not everything that is the norm is sane or even nice ofcourse, but for
sbase I'd want a minimal stable set of unix tools that work well.
> As Gzip,Bzip2 and XZ rely on rather complicated code bases, I propose
> that a different algorithm (probably based off ROLZ), be used
> instead, with a focus on a suckless implementation as opposed to
> speed/compression ratio. Having said that, most ROLZ implementations
> do tend to have greater speed and higher compression ratio than Gzip.
>
> I know I could easily create a suckless implementation, but would it
> be of interest to be included in sbase or is it beyond the scope of
> the collection of utilities?
>
It is beyond the scope imho.
FWIW I think this should not be in sbase. A tar and gzip
implementation though would be nice to have. The tricky part for tar
might be to have it's behaviour to be mostly compatible with existing
implementations[0].
Maybe it's an idea to polish the "flate"[1] code instead?
The SLOC of libarchive is high because it supports alot of formats
(the ones that are not needed can be disabled). From what I've seen
the API code is quite clean. pkgtools from morpheus works quite well
with it too![2]
[0]
http://www.linuxquestions.org/questions/slackware-14/why-pkgtools-still-using-tar-1-13-a-721813/
[1]
http://git.suckless.org/flate/
[2]
http://git.2f30.org/pkgtools/
Received on Wed Sep 24 2014 - 13:02:10 CEST