>> But for something which is in concept merely a "document", this is
>> pretty inconvenient. I can pass a Word file around easily -- passing
>> around our free-software documents ought to be just as convenient.
>
> Thank you for your vote for a user library implementation of compound
> files. This is the traditional Unix answer to such things, that's
> more-or-less how Windows and NT deals with such files.
Eh, no.
He said nothing about internal representation. Don't claim that he
supports either userspace or kernel code. He only said that he did
not want to deal with something directories, which you chopped.
>> In practice, to keep with convenience the "office" apps will all
>> implement a flat file format.
>>
>> And because of that we won't get the efficiency of directories.
>
> There's no reason why a user library implementation would have to be
> stupid. For example, you could re-invent a simple filesystem in a flat
> file. The minus is that you have to re-invent some code which is
"no reason why a user library ... be stupid"
Adding a second layer of filesystem-like structure is stupid.
Writing code for this in every app is stupid.
slow + buggy is not good
> almost the right stuff in the kernel. The plus is that it's easy to
> pass around, and you didn't change the kernel. Another minus is that
> existing commands such as "cat" aren't going to do anything nice on
> these documents.
No, commands such as "cat" work fine. That isn't the problem.
-
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/