Ralph Eastwood said:
> The introduction of bzip2 and xz always surprised me. Perhaps the
> authors of those formats were the only ones that approached GNU to
> have them included.
Actually GNU tar supports several compression tools:
* gzip
* xz
* bzip2
* lzip
* lzma
* lzop
* compress
Bzi
On 24 September 2014 16:41, Dmitrij D. Czarkoff wrote:
> People can shift, but archives can't. Most of tarballs that already
> available as .tgz or .tar.gz will remain in that format forever, and
> having to use GNU tar in order to use them is unacceptable.
Yeah, that does make sense. I've not
Ralph Eastwood said:
> OpenBSD even had 'gzip' aliased to? compress.
Had? From gzip(1) manual:
| HISTORY
| gzip compatibility was added to compress(1) in OpenBSD 3.4. The
| `g' in this version of gzip stands for ``gratis''.
$ ls -1i /usr/bin/{compress,gzip}
1455743 /usr/bin/compr
See [0] about implementations; OpenBSD even had 'gzip' aliased to?
compress. It appears that the lz77/deflate gzip is a GNUism.
Nothing bad about that - but I think although the current norm
dominates, it is only the current norm and people can shift.
[0] http://en.wikipedia.org/wiki/Gzip
--
Ta
On 24 September 2014 13:14, Dmitrij D. Czarkoff wrote:
> And there is. Check "-Z" option in the manual of you tar.
GNU tar has the option, but also searches for the 'compress' binary,
which isn't always installed by default.
--
Tai Chi Minh Ralph Eastwood
tcmreastw...@gmail.com
Ralph Eastwood said:
> Although the norm changes - if 'compress' wasn't patent encumbered, I guess
> there would be wide support for it still.
And there is. Check "-Z" option in the manual of you tar.
--
Dmitrij D. Czarkoff
On 24 September 2014 12:02, Hiltjo Posthuma wrote:
> 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.
Although the norm changes - if 'co
On Tue, Sep 23, 2014 at 11:30 AM, Ralph Eastwood 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 gzi
On a side note, I think you should write this as a few routines
in their own .c and place them under util/. It would be useful to
be able to grab the routines and embed them in another project.
Just create a .h to expose any functions/data structures required
and write the tool on top of that.
On Wed, Sep 24, 2014 at 05:42:45AM +0100, Ralph Eastwood wrote:
> I don't think the compression format is defined by POSIX; as far as I
> can see XZ is really recent but has gained traction in some
> distributions. In terms of actual usefulness, this compression scheme
> would be a nice addition f
On 24 September 2014 01:18, Wolfgang Corcoran-Mathe
wrote:
> Is there something wrong with sflate?
I had missed sflate, thanks! Although, having now looked, I'm
envisioning something smaller than sflate.
On 24 September 2014 01:29, Dmitrij D. Czarkoff wrote:
> IMO generating compressed tarball
Ralph Eastwood said:
> 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.
IMO generating compressed tarballs with rare compression scheme sucks.
Aren't tarb
Quoth FRIGN on Tue, Sep 23 2014 13:39 +0200:
I'd love to have a simple, suckless compression-algorithm and
see no problem in adding one to the suckless-universe.
Is there something wrong with sflate?
--
Wolfgang Corcoran-Mathe
On Tue, Sep 23, 2014 at 12:30:21PM +0100, Ralph Eastwood 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.
>
> As Gzip,Bzip2 and XZ rely on rather
On Tue, 23 Sep 2014 12:30:21 +0100
Ralph Eastwood wrote:
Hey Ralph,
> 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.
>
> As Gzip,Bzip2 and XZ rely on
Hi,
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.
As Gzip,Bzip2 and XZ rely on rather complicated code bases, I propose
that a different algorithm (proba
16 matches
Mail list logo
