News for hackers. Stuff that matters.
Re:The cpio trailer problem (2018) by qalmakka on Sunday July 19, 2020 @04:36AM (#23887932)
I never really understood why tar "won" and cpio "lost" the archive wars. Both do pretty much the same thing, thus I think it was just a matter of personal preference?

I started using *NIX around ~2006 and nobody was using cpio already then, I only had the chance of learning of its existence when I first had to extract an RPM.

Re:The cpio trailer problem (2018) by raverbashing on Sunday July 19, 2020 @05:26AM (#23888103)
Because the cpio utility has awful usability

(it might capture more info than tar maybe? but it's not worth the effort)

Re:The cpio trailer problem (2018) by theamk on Sunday July 19, 2020 @01:13PM (#23890757)
Second that. I had the time when I was working with initrd images, so I had to use cpio a lot. I could never get used to its syntax.

And the fact that it’s manpage was missing, only saying “use info instead” did not help its usability at all.

Re:The cpio trailer problem (2018) by JdeBP on Sunday July 19, 2020 @01:50PM (#23891013)
That was a GNU documentation problem, never applicable to non-GNU versions of cpio, and not even applicable to the current GNU manual page, which has no mention of info and definitely exists. It also post-dates by years the period where tar and cpio were in competition, which was (roughly) the early 1980s. (The POSIX standard pax aimed at resolving the conflict was in the 1003.1b draft in 1991.) It thus is an entirely fallacious explanation for what happened in the "archiver wars".

* https://news.ycombinator.com/item?id=18978064

* https://netbsd.gw.com/cgi-bin/man-cgi?cpio

* http://osr507doc.sco.com/man/html.C/cpio.C.html

* https://manpages.debian.org/sid/cpio/cpio.1.en.html

Re:The cpio trailer problem (2018) by tyingq on Sunday July 19, 2020 @10:03AM (#23889432)
Cpio did have some advantages. It was more space efficient, and would read past errors. See https://www.gnu.org/software/tar/manual/html_section/tar_71....
Re:The cpio trailer problem (2018) by fit2rule on Sunday July 19, 2020 @05:31PM (#23892599)
I think it was because of tape-drive manufacturers. Tar was often used to move big data off the platters and onto magnetic tape - cpio didn't have that killer application. In the bad old days of metal, tape was how you saved things, while the disks were for processing ..
Re:The cpio trailer problem (2018) by gpvos on Sunday July 19, 2020 @07:46AM (#23888672)
I guess that once ftp sites and Usenet binary groups had de facto standardized on tar files (first compressed, later gzipped; uuencoded for Usenet), it was a foregone conclusion. Why they did, I don't know; it may have been random. Originally, lots of source was distributed as a shar file (also possibly compressed and uuencoded); maybe the name similarity with tar helped?
Re:The cpio trailer problem (2018) by nix23 on Sunday July 19, 2020 @08:05AM (#23888764)
Maybe skip cpio and go directly to dar?

https://en.wikipedia.org/wiki/Dar_(disk_archiver)

Re:The cpio trailer problem (2018) by icedchai on Sunday July 19, 2020 @11:18AM (#23889908)
I started using Linux in 1993 and cpio was barely used then.
Re:The cpio trailer problem (2018) by jan6 on Sunday July 19, 2020 @04:48AM (#23887976)
maybe it was preference at first, some people finding it annoying to deal with cpio's file list, and it built up to the modern stuff like builtin integration with compressors (probably coinciding with tar.gz becoming the de facto *nix archive)? I personally find xz and cpio both cool, despite both being barely used ;)
Re:The cpio trailer problem (2018) by jhoechtl on Sunday July 19, 2020 @09:31AM (#23889219)
XZ used to be the compression format for many Linux packages in many distros (at least Arch based) and has only lately been replaced by ZStd. How do you come to the conclusion that xz is barely used?
Re:The cpio trailer problem (2018) by ComputerGuru on Sunday July 19, 2020 @11:30AM (#23889995)
I definitely would not say zstd has replaced xz, but it is on its way too. I'm not sure it is even the best replacement because the needs of packages differ from the strengths of zstd. Zstd is designed to optimize for both compression and decompression (i.e. It does neither spectacularly but has very good/pareto trade offs) while packages are very much written once and read many times. If xz weren't so memory intensive to decompress it would be a good choice (ie it's not a good choice), but I feel like there is still a better option out there that approaches the problem from a "optimize for size at the expense of heavy compression costs" and zstd is not it
Re:The cpio trailer problem (2018) by chungy on Sunday July 19, 2020 @04:42AM (#23887950)
tar is far easier to use, I think.