Normal document-centric office apps can create such horrors.
This is by design.
> All I am saying is that for some kinds of data (such as a single,
> large growing component and any number of small maybe growing
> components), storing it in a special file is fine. It's been done and
> it works well. I have already said that this case does not apply in
> general.
Why is it fine just this once? You wanted to manipulate individual
components with normal tools, but clearly you can't. You need special
tools to insert and extract data. If anything, this is _worse_ than
a multi-forked file. You will need a separate tool for each app.
>>> I advocate putting albods/data forks/streams/what-have-you into
>>> separate files in a directory, and making no changes to the kernel or
>>> libc. That means the default behaviour of the kernel, libc and system
>>> utilities is that a directory-based albod is just another directory.
>>
>> In other words, scratch this whole idea.
>
> Yes.
>
>> Suffer your choice of inefficiency or user-hostility.
>
> No, I didn't suggest that. Again, I favour optional extensions to new
> and existing tools, so that you can view albods as either atomic or as
> conventional directories. Make the default behaviour configurable on a
> per-user basis (~/.resource-file) and allow that default to be
> overridden on a per-execution basis.
Existing tools need a file view. (please don't use "atomic")
BTW, existing tools are already compiled and linked.
Ugh. I don't think /bin/mv should be reading config files in
your home directory.
>>> Other (optional) behaviour can be added on top of this.
>>
>> This can not be. If you really think that random user-space software
>> developers will agree on a way to use directories as documents...
>
> That doesn't matter. If GUI developers can't agree to use a common
> library, it does not follow that the functionality should be pushed
> into the kernel/libc.
Hey, maybe Microsoft is right about us...
I said the above mostly because I think your "userspace" argument
is really a disguised "go away and die" argument. I believe you are
fully aware that a userspace implementation can not happen, and you
are counting on that fact.
If you don't like multi-forked files, just say so.
>> It isn't enough to have a few GUI apps. Users will be confused by
>> the inconsistent treatment.
>
> No they won't. Each user can edit ~/.albodrc. Generic luser has:
Hmmm, anybody that doesn't want to screw with tar is a luser?
You have too much time to waste.
> The point is everybody can be catered to with this scheme. Hacking the
> kernel/libc *prevents* a *legitimate* mode of operation. That is
> simply unacceptable.
That is simply not true.
BTW, devfs *prevents* a *legitimate* mode of operation. Once people
start to use it, developers will require it, and then nobody will
be able to have a stable /dev with reliable security. :-/
What is your real concern?
>>>>> Command-line users who want to see albods as atomic can use some
>>>>> special tools, or perhaps switches to existing tools.
>>
>> Command-line users who want to see the parts can use special tools.
>> $ albod -x 80A8C452 ~/foo.doc > a.png
>
> NO! I want *all* my existing tools to be unaffected. I don't want the
> semantics changed. But I'm quite happy for another user on the machine
> to use cooked mode.
By opposing this, you get the alternative:
$ doc-fmt -x 80A8C452 ~/foo.doc > a.png
$ id-fmt -x 80A8C452 ~/foo.id > b.png
$ kde-fmt -x 80A8C452 ~/foo.kde > c.png
$ xml-fmt -x 80A8C452 ~/foo.xml > d.png
...
See? You will be even less able to use your command-line tools.
>> I'd say you are afraid of change. When the topic isn't devfs... :-/
>
> I'm afraid of having different semantics shoved down my throat.
Many are afraid that devfs will become a required feature.
While devfs is currently an option, you might shove it down
people's throats at some point. (maybe a driver will need it)
> The difference between devfs and kernel space albods is that with
> devfs I provide choice. There are a range of operating modes that
> users are free to use (and I note that some devfs detractors are
> effectively trying to prevent me (i.e. any user who just wants to
> download a kernel from Linus and not patch it) from having the full
> range of choice).
>
> With kernel space albods, I don't get the choice of having all my
> tools work in raw mode. This is why I'm fundamentally opposed to
> them. The key point is that I support the availability of new
> semantics but I oppose the restriction of existing ones.
No, this is totally backwards. If you don't want to use multi-forked
files, then just don't use them. You are "effectively trying to prevent
me [...] from having the full range of choice".
>>> If you stuff around with the kernel/libc, you make it hard/impossible
>>> for people to see the raw components (real files in real directories).
>>> I can't stress enough how wrong that would be.
>>
>> What use are the raw components? They won't be in any file format
>> that you would normally use. They may be headerless raw image data,
>> binary markup language, binary data structures, etc.
>
> That's not true. They may have gif files, for example. And the headers
> are somewhere in the albod directory.
Oh, you wish. Office apps tend to have their own internal formats.
>> Since you need a special tool to create plain text anyway, you
>> might as well have that tool use the sub-file extraction API.
>
> I have a range of tools I can use to create text. The simplest is
> <cat>. I don't need a special API to write text.
If "text" is anything like ASCII, you will need a special tool
to create it from the representation used by a word processor.
You can expect odd control characters including '\0', use of
line lengths instead of newline characters, Unicode, embedded
style information, and perhaps even binary data structures.
Since your existing tools alone are already useless, I don't see
any reason to object to using special extraction tools.
> ??? I'm talking about system utilities, ls, sed, awk, perl, tr plus a
> whole bunch of my own custom utilities.
Few people use "sed" on raw binary data.
-
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/