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
hi marc andré
as announced a few days ago, here is my write down about vis.
you probably won't agree with each point in there...
for many years now, i've been using vim as my main text editor. both for code
and for typing text.
while i consider myself a vim heavy user, when i browse through
On 22/09/2014, Evan Gates wrote:
> One thing I'm not clear on, in your opinion does suckless software use
> fixed or dynamic sized buffers/stacks? i.e. should it support
> arbitrarily long lines? depth of nested blocks? number of write files?
> I've seen some of both in software that seems suckles
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
On Tue, Sep 23, 2014 at 02:40:27AM +0200, FRIGN wrote:
> There's currently no plan to implement a regex-engine, because we don't
> suffer from NiH.
Really? :P