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
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
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.
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)
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 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-64cebc2cb7169541254924/] That, I think, is pretty cool.