You also don’t need the dash for the short options.
Also, if you’re compressing with bzip2 and have archives bigger than a few megabytes I’ll like you a lot more if you do it with --use-compress-prog=pbzip2
Technically the notation with dashes is the non-standard one - the dash form is a GNU addition. A traditional tar on something like Solaris or HP-UX will throw an error if you try the dash notation.
(It works great with beef, too. Bonus points for the raw yolk over it. If not homemade though there’s literally one bar that I trust with this, salmonella is not fun.)
There’s nothing technically wrong with using xjf rather than xzf, but it’ll bite you if you ever use a non-linux platform as it’s a GNU extension. I’m not even sure busybox tar supports it.
Yes, but I’m asking you to use pbzip. bzip at best utilizes one core, both for packing and unpacking. pbzip uses as many cores as IO bandwith allows - with standard SATA SSDs that’s typically around 30.
pbzip can only utilize multiple cores if the archive was created with it as well.
I’ve searched for it and xz also doesn’t use multithreading by default, you can change the program tar uses to compress by passing the -I option. For xz using all possible CPU threads:
tar -cv -I 'xz -6 -T0' -f archive.tar.xz [list of directories]
The number indicates the compression ratio, the higher the number, the more compressed the archive will be but it will cost more in terms of memory and processing time
You also don’t need the dash for the short options.
Also, if you’re compressing with bzip2 and have archives bigger than a few megabytes I’ll like you a lot more if you do it with --use-compress-prog=pbzip2
True, but I refuse to entertain such a non-standard option format. It’s already enough to tolerate
find’s.Technically the notation with dashes is the non-standard one - the dash form is a GNU addition. A traditional tar on something like Solaris or HP-UX will throw an error if you try the dash notation.
It’s also traditional to eat raw meat, but we discovered fire at some point.
Don’t try to take my raw ground pork away from me.
Who are you, the Mett demon?
\
(It works great with beef, too. Bonus points for the raw yolk over it. If not homemade though there’s literally one bar that I trust with this, salmonella is not fun.)
Not enough onions. Your average mettigel has better mett/onion ratio.
I got toxoplasmosis that way
That’s an audible “yuck” from me, man. Well done!
Can’t be well done if it’s raw.
Looks like you Mett your match.
I like the dashes, they make the options look like options to me.
You know when you meet someone and you’re just like “oh boy, yeah, they’re evil. No humanity at all”
ps aux says hi!
I think the
-jalso compresses with bzip2 but I’m not sure if this is defined behavior or just a shortcutThere’s nothing technically wrong with using xjf rather than xzf, but it’ll bite you if you ever use a non-linux platform as it’s a GNU extension. I’m not even sure busybox tar supports it.
Yes, but I’m asking you to use pbzip. bzip at best utilizes one core, both for packing and unpacking. pbzip uses as many cores as IO bandwith allows - with standard SATA SSDs that’s typically around 30.
pbzip can only utilize multiple cores if the archive was created with it as well.
Does something similar happen using
xz?I’ve searched for it and xz also doesn’t use multithreading by default, you can change the program tar uses to compress by passing the
-Ioption. For xz using all possible CPU threads:tar -cv -I 'xz -6 -T0' -f archive.tar.xz [list of directories]The number indicates the compression ratio, the higher the number, the more compressed the archive will be but it will cost more in terms of memory and processing time
Thanks for answering your own question, this is useful information.