similar to: [Bug 2888] New: Consider adding other compression schemes (lz4, zstd)

zstd is accessible within R using the archive package [1]. I use it all the time when saving large objects, using code I adapted from [2]. Is your suggestion to import the libraries/source code into base? [1] https://CRAN.R-project.org/package=archive [2] https://coolbutuseless.github.io/2018/10/02/using-lz4-and-zstandard-to-compress-files-with-saverds/ On Fri, Jan 10, 2025 at 6:17?PM Jeroen

On 2020-09-07 11:21:13 [+1000], Darren Tucker wrote: > The zstd part would be a larger discussion because we would need to > either carry it as a Portable patch or have zstd added to OpenBSD > base, and I don't know if that would be accepted. Do you have any > performance numbers for zstd in this application? A key stroke is here 10 bytes of raw data which zstd compresses usually

https://bugzilla.samba.org/show_bug.cgi?id=14338 Bug ID: 14338 Summary: ZSTD support Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayne at opencoder.net Reporter: Rsync at ml.breakpoint.cc

Many distros and browsers these days use zstd as the preferred compression method. For example if you unpack a .deb or .rpm file on Debian or Fedora there is zstd archive inside. It is claimed that zstd offers improved compression over gzip, but (unlike lzma) it has comparable decompression speed. Maybe it is interesting to get an estimate of how much R packages would benefit from zstd. Testing

I think the first step would have to be to add zstd support to R. zstd is a bit controversial (as shown by the community blowback of the changes you mentioned) and their build system (calling it that is being very generous) is mess so it would require a bit of testing, but it is doable. That said, assuming the above is solved, we have been debating the change of compression at CRAN in general for

With the changes to add zstd support yesterday, the build of R-devel is failing when zstd is not present, even though the docs say that zstd is optional. The error comes in building the datasets package, see e.g. https://github.com/r-devel/r-svn/actions/runs/12760693086/job/35566530112. Best wishes, Heather On Mon, Jan 13, 2025, at 1:26 AM, Simon Urbanek wrote: > I think the first step

https://bugzilla.mindrot.org/show_bug.cgi?id=2972 Bug ID: 2972 Summary: Add build-time option to use OpenSSL for ChaCha20-Poly1305 Product: Portable OpenSSH Version: 7.9p1 Hardware: ARM OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

Can't speak for Jeroen, but it sounds like it's worth adding support for tar.zstd package files, just like how tar.gz, tar.xz, and tar.bzip2 are currently supported. I'd also argue for support zstd compression throughout R, including adding zstdfile(), support for saveRDS(..., compress = "zstd"), and so on. Then it could be discussed later what the default(s) should be.

On 2020-08-06 08:45, J Martin Rushton via CentOS wrote: > You'll need to upgrade to CentOS8. > > C7 is at rsync 3.1.2-10, and will not go above 3.1.2 ever. > > C8.2 is at 3.1.3-7, C8 will always be on 3.1.3 > > Martin Another option is to build rsync from source, which is what I did to try out the zstd compression. centos7$ rsync --version rsync? version 3.2.2? protocol

https://bugzilla.samba.org/show_bug.cgi?id=14390 Bug ID: 14390 Summary: Feature request: don't fail if using "-z" transferring to rsync complied with --with-included-zlib=no Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: enhancement

ok, I did install zstd (zstd command line interface 64-bits v1.4.4, by Yann Collet) reconfigured & compiled dovecot 2.3.10.1 again with option : with-zstd changed the configuration file to : zlib_save = zstd and restarted dovecot - now I have following log file errors : Aug 28 16:17:39 lxc-imap dovecot: imap(rnowotny)<237930><H1kft/CtENRUclcc>: Error: zlib_save: Unknown

Hello, When I look at email files on my server (mdbox format), they contain random LZ4 stuff. I have now changed the compression to gzip and new mails look cleaner. But older ones have problems. A mail file looks like this: 2 M1e C5655b6a8 ^A^BN 00000000000006F4 Dovecot-LZ4^M*<9B><C5>^@^A^@^@^@^@^F<DD><FF><83>Return-path: <nobody at

Hi All, Any inputs on this issue? -- Shedi On Wed, Feb 21, 2024 at 5:12?PM Shreenidhi Shedi < shreenidhi.shedi at broadcom.com> wrote: > Hi All, > > Copying the content from the GH issue as is. > Need your inputs on the same. > FWIW, the coredump files generated in linux have xattr values which are > > 32 bytes. > > https://github.com/WayneD/rsync/issues/569

I am running XEN on CentOS Linux release 7.8.2003 I have a Debian 7, and two Gentoo DomU Guests running fine. I am trying to get an Ubuntu 20.04 DomU Guest running but I get this error when trying to run the netboot kernel image xc_dom_probe_bzimage_kernel unable to LZ4 decompress kernel I understand that CentOS Xen does not support LZ4 decompression. Is there a workaround for this?

I'm a long time user of openssh and I was wondering if there is any work towards supporting alternative compression methods in openssh like LZ4? Regards, Mark -- Mark E. Lee <mark at markelee.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message

Compression has some problematic interactions with encryption that OpenSSH seems to have handled far before anyone else (by having it off by default). On Thursday, October 24, 2013, Darren Tucker wrote: > On Thu, Oct 24, 2013 at 07:30:38PM -0400, Mark E. Lee wrote: > > I'm a long time user of openssh and I was wondering if there is any work > > towards supporting alternative