Re: bsdcpio and bsdtar installed by default

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 5-Jun-08, at 12:39 PM, Christos Zoulas wrote:
> By whom? Are you volunteering? Seriously it is not like our pax has  
> the
> cleanest code. I have spent many hours debugging various problems in  
> it
> and I don't want to keep doing it. FreeBSD uses libarchive too, and it
> is actively and well maintained. Plus you get the advantage of being
> able to use the archiving API from other programs instead of needing  
> to
> invoke tar!


I'm all for good clean code that's actively and well maintained.

I'm also in full agreement that the current pax implementation is  
buggy and ugly and could have been replaced with any of many better  
implementations long ago.  I too have poked around in it more often  
than I ever wanted to.

However I'm not so sure it's a good idea to use libarchive from  
programs that want to unpack things instead of invoking dedicated  
archive programs as separate processes, just as I'm not so sure it's a  
good idea to use compression and decompression APIs directly instead  
of starting separate processes running dedicated compression and  
decompression programs.  Use of separate processes is even more  
important as multi-processor platforms become more common.  Using LWP  
threads and library APIs for these purposes is possible I suppose, but  
I strongly object to using threads when they're not absolutely 110%  
necessary beyond any doubt.  Vfork() and execv() are not the expensive  
operations here.  We already have to maintain separate programs for  
such features anyway.  We already need to have high-performance pipes  
too.  The problems with threads are many and widely documented, even  
just within NetBSD's PR database alone.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>