Re: The argument for fs assistance in handling archives

From: Spam
Date: Fri Sep 03 2004 - 16:51:49 EST





> On Fri, Sep 03, 2004 at 09:30:38PM +0200, Spam wrote:
>>
>>
>>
>> > Helge Hafting <helge.hafting@xxxxxxx> said:
>>
>> > [...]
>>
>> >> The only new thing needed is the ability for something to be both
>> >> file and directory at the same time.
>>
>> > Then why have files and directories in the first place?
>>
>> Good point, we don't need them :) Directories are just a visible
>> grouping of files to make it easier for the user to manage. But some
>> things aren't really that intuitive with todays layout - especially
>> for non-unix users.
>>
>> Just an example where the user needs to edit config file for some
>> program. Where should he look?
>> /etc/app.conf ?
>> /etc/app/app.conf ?
>> /etc/conf.d/app.conf ?
>> /var/lib/app/app.conf ?
>> and so on....
>>
>> Using file-as-dir isn't really that much of a change. It isn't those
>> that will confuse people anyway.
>>

> If the non-computer literate user is expected to edit the config file,
> a pretty interface that hides the internals from the user should be provided.
> For the sake of power users, users that believe themselves to be power users,
> and configuration changes on multiple systems.
> 1) Track the location of the config file with the native package management
> system.
> 2) Keep a human readable/editable format.
> 3) Provide APIs or schema so that the files may be parsed for correctness,
> or edited or created programatically.
> 4) Provide a tool that not only checks for a parseable file, but does
> sanity checks such as (Does file exist).

> I'm at a loss as to how any of this has anything to do with filesystems.
> The closest I see is one implementation of the above (gconf2) happens to
> use the filesystem for it's default hierarchical database backend.

The relevance was as to the presentation of meta-data, streams and
such and their implication on users.

I just used the example of config files because there are not so
much of a standard among them. Administrators still need to learn
and remember where and what to backup. This wouldn't be so much of a
change if they decide to introduce some usage for meta-data or named
streams.

Remember, even if the functionality exist you do not have to use
everything of it.

> As for developers that are too stupid/lazy to provide the GUI and meet
> the other criteria... I suggest extensive use of cattle prods on
> them as they attend an automata class.

Lets all start with the bash(ing) ;).

But really. What you say is true. The users do not care so much
about what is going on below the curtains. Here is where the clash
between different groups of Linux users and developers appear most
vivid.

Sure KDE and Gnome are on their way, but their efforts still have a
long way to go. They still don't talk to eachother to strive for a
comon goal - but competes instead (which may even be a good thing).

~S


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