Tag: command line

Why no alternate compression algorithms in rsync?

I was thinking the other day, gzip is all fine and good, but why doesn’t rsync support other compression methods? There are a few use cases where using LZO (a very low latency compression algorithm) would be a better choice. One such case would be when operating with a relatively slow CPU, such as on

rsync –skip-compress=LIST option

On Ubuntu 12.04, rsync has the --skip-compress=LIST option, which is fricken’ rad since it defaults to skipping files with the extensions 7z, avi, bz2, deb, gz, iso, jpeg, jpg, mov, mp3, mp4 ogg, rpm, tbz, tgz, z and zip. So before, when we used to agonize over whether to use the -z option if the

zRam Has A Posse

How have I not known about this? Inconceivable! Here’s a WebUpd8 article on zRam. This zRam software looks like the bees’ knees for low-memory systems, of which I have a few. Crazily, all one needs is a sudo apt-get install zram-config to get it going.

Cool Shell One-Liner of the Day

awk -F, '{print $1}' CSV | sort | uniq -c | grep -vw 1 | tee /dev/tty | wc -l UPDATE: I went back and saw this post and thought to myself, “Self, why didn’t you annotate this garbage, you cheeky bastard?” OK, so the first part is pretty clear: get the first (or whichever)

gzip by default

In my lastĀ post on gzip, I discovered that gzip can compress data in a more sync-friendly way. This totally unrelatedĀ blog entry from nginx discusses a new gunzip filter that decompresses compressed data for clients that don’t support gzip. I was thinking about this the other day. Why not store all your content compressed, then you

Gzip and Rsync

Gzip and Rsync were sitting in a tree, k-i-s- Ok, I’ll stop. I just wanted to mention that I came across this little nugget in the gzip manpage the other night: [crayon-5c8caa0b7008b041391230/] That, I think, is pretty cool.