> On Fri, Jun 25, 1999 at 10:28:21PM -0400, Arvind Sankar wrote:
> > On Fri, Jun 25, 1999 at 10:55:07AM -0400, Lou Grinzo wrote:
> > > You can get the performance today by using directories, but that
> > > destroys usability. Documents need to appear as files to the user,
> >
> > Why must they appear as files to the user? I don't see quite what is very wrong
> > with having a complex document as a directory.
>
> Not only is there nothing wrong with this approach, but for people who
> use LaTeX for largish documents this is the way it *has* been done for
> a number of years.
>
> Typically you create a "document" as a directory.
[ followed by a description how you deal in a sane matter with a big
LaTeX document ]
....
> And in all honesty, what is stopping an application from keeping their
> document format as tar, and unpacking into /tmp when you start work on
> a document, then retarring at the end. All the speed, very simple.
>
Although I agree with what Nathan wrote in the longish part of his
description I think that the last quoted paragraph is misguided. The
speed of taring and untaring IS NOT an issue even on a slow machine.
When you work on a complex document hours at the time and days, or
even weeks or longer, total these few extra seconds here and there are
really irrelevant.
Myself I use for a work on (La)TeX documents emacs with auc-tex macros
(and I definitely DO NOT want LyX started when I click on a document
icon :-) and this supports notion "the whole directory as one
document" even to a greater degree. It knows, for example, what my
"master document" is and if I start dvi creation process on any of
.tex source files it will begin transparently with a master document
anyway. There are also simple ways to control what is included or
excluded on a particular run, but I digress.
The point is that I emphatically **do not** want to hunt for a
temporary directory de-jour where things were unpacked if I wish to
have a look at a particular component. I also want to be able,
without an extra hassle, to substitute temporarily my pictures with
stubs, filter some parts of my document through a Perl script,
generate other parts automatically from a report generator of a
database and some other from a gnuplot output driven by a Fortran
program and thousand of other things which I even cannot think of
today.
If you think that you can provide a packaged abstraction which can
support all my conceivable and not-yet-invented needs than this is
great but I have to see it before I will believe in that. But I think
that this is a waste of time as such abstraction already exists and it
is called a file system and you better spent your energy on thinking
how to improve and possibly generalize it instead of subverting it.
If you feel that this is important you may program a GUI user space
utility which will pack the whole bundle into a "net-transportable"
form and unpack it transparently. No muss, no fuss but keep a format
standard across various OSes and platforms.
For those who think that archiving does not matter and is just a form
of ensuring that all components are kept together think for a second
how much wailing and flamage such trivial packaging format like RPM
caused on this, definitely "computer-savvy", forum. If you are one of
those who still cannot recover from an "RPM shock" here is yet another
rpm unbundler:
#!/usr/bin/perl -w
use strict;
my ($buffer, $pos, $gzmagic);
$gzmagic = "\037\213";
open OUT, "| gunzip" or die "cannot find gunzip; $!\n";
while(1) {
exit 1 unless defined($pos = read STDIN, $buffer, 8192) and $pos > 0;
next unless ($pos = index $buffer, $gzmagic) >= 0;
print OUT substr $buffer, $pos;
last;
}
print OUT <STDIN>;
exit;
There! It takes an rpm archive on stdin and writes cpio stream on
stdout. If you think that this is a good idea extend OUT pipe with
'| cpio -imd' and you will get a set of files instead. And all this
teeth gnashing and strong words over those few lines of code...
Michal
michal@harddata.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/