lkml.org 
[lkml]   [2004]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: The argument for fs assistance in handling archives
    From
    Date
    On Thu, 2004-09-02 at 19:25, David Masover wrote:
    > Dave Kleikamp wrote:
    > [...]
    > | Please don't tell me that we have expectations to run make from within a
    > | tar file. This is getting silly. tar does a pretty good job of
    > | extracting files into real directories, and putting them back into an
    > | archive. I don't see a need to teach the kernel how to deal with
    > | compound files when user space can do it very easily.
    >
    > Suppose I've got a tar file with an index attached. Suppose it's
    > something like /usr/src/linux. Am I expected to extract all code for
    > all architectures, with all drivers, all docs, etc? Now, yes -- or I
    > have to figure out exactly which ones I need before I extract them
    > manually, one by one.

    I don't think it's unreasonable to expect someone to either extract the
    whole tar file, or identify what files they want from it. If you think
    there is too much in the tar file, roll your own with only the files you
    need.

    > But with tar support for make (and so on), files can be extracted on
    > demand. It's possible to do this in userspace, with named pipes, but
    > that's much slower and insanely clumsy.

    This doesn't justify bloating the kernel. untar the darn thing and user
    space does fine.

    > This has further implications -- imagine a desktop, binary distro
    > shipped with all files except the very most basic stuff as package
    > archives. They can all be extracted, on demand -- the first time I run
    > OpenOffice.org, it's installed. If there needs to be post-installation,
    > that's handled by the .deb plugin (or whatever).

    Are you saying install it on demand the first time it's run? This
    doesn't take any new kernel function.

    Or are you saying that the files are never installed on the filesystem,
    but always accessed from the package archives? In this case, why not
    ship each package as a compressed iso, and have the system mount the iso
    to run the app. I really don't see the point though, in that disk space
    is very cheap these days.

    > I don't know offhand how big OOo is. I think it's something like this:
    > ~ The installer is at most half (and maybe only a third) of the full
    > installation. That's a HUGE optimization!

    Optimization? How much performance are you willing to give up to save a
    little bit of disk space?

    --
    David Kleikamp
    IBM Linux Technology Center

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:4.047 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site