Helge Hafting <[email protected]> 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?
> Some tools will need
> a update - usually only because they blindly assume that a directory
> isn't a file too, or that a file can't be a directory too. Remove the
> mistaken assumption and things will work because the underlying system
> calls (chdir or open) _will_ work.
But with some weird restrictions: No moving stuff around between files, no
linking, some "files" can't be deleted (how would you handle removing the
principal stream of a file?). Some stuff you'd love to do (is, in fact, the
reason for this all) just can't be allowed (i.e., J. Random Luser setting
his own icon for system-wide emacs). So the tools/scripts/users/sysadmins
will have to be painfully aware that some of the files aren't, and some of
the directories aren't either. Major pain in the neck to use, if you look
closer. Add extra kernel complexity. For little (if any) gain.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
> Helge Hafting <[email protected]> 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.
>> Some tools will need
>> a update - usually only because they blindly assume that a directory
>> isn't a file too, or that a file can't be a directory too. Remove the
>> mistaken assumption and things will work because the underlying system
>> calls (chdir or open) _will_ work.
> But with some weird restrictions: No moving stuff around between files, no
> linking, some "files" can't be deleted (how would you handle removing the
> principal stream of a file?).
Well. there are read-only files. And if you remove the main stream
(which is the file, really) then it will all be gone =)
> Some stuff you'd love to do (is, in fact, the
> reason for this all) just can't be allowed (i.e., J. Random Luser setting
> his own icon for system-wide emacs).
Users do not normally have write permissions to system-wide
applications. Why would it be any different now?
> So the tools/scripts/users/sysadmins
> will have to be painfully aware that some of the files aren't, and some of
> the directories aren't either. Major pain in the neck to use, if you look
> closer. Add extra kernel complexity. For little (if any) gain.
Not sure what you mean "aren't". Things shouldn't be that much
different to administer. Normal permissions should still apply. Sure
extra complexity comes _if_ you want to use extended features that
are using meta-info. But there is where we need some patches to tar
and other backup tools.
One other way would be to enter a specific mode (chroot, a bash
flag --show-metas, etc) that would allow all streams and metas to be
seen as files in directories. Then tar and other tools would back it
all up. Restoring will be a little trickier as we don't know if
stuff was files or folders before. But I am sure that would be
solvable. Perhaps a tool to convert them back to normal files with
meta-data and streams.
~S
On Fri, Sep 03, 2004 at 09:30:38PM +0200, Spam wrote:
>
>
>
> > Helge Hafting <[email protected]> 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.
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.
--
Chris Dukes
Warning: Do not use the reflow toaster oven to prepare foods after
it has been used for solder paste reflow.
http://www.stencilsunlimited.com/stencil_article_page5.htm
> On Fri, Sep 03, 2004 at 09:30:38PM +0200, Spam wrote:
>>
>>
>>
>> > Helge Hafting <[email protected]> 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
Horst von Brand wrote:
>Helge Hafting <[email protected]> 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?
>
>
>
>> Some tools will need
>>a update - usually only because they blindly assume that a directory
>>isn't a file too, or that a file can't be a directory too. Remove the
>>mistaken assumption and things will work because the underlying system
>>calls (chdir or open) _will_ work.
>>
>>
>
>But with some weird restrictions: No moving stuff around between files, no
>
>
I see no need for such a weird restriction. If it is "weird", why have it?
If someone want to move stuff from one subdirectory to another, let them.
I see no need to stop that just because a file-as-directory was involved.
>linking, some "files" can't be deleted (how would you handle removing the
>
>
linking is a problem of course. We can't have hardlinks to directories,
so no hardlinks to file-as-dir either unless the general problems with
directory links are solved.
>principal stream of a file?).
>
A design decision. Removing the principal stream may delete
the entire tree. Or it may delete the principal stream only,
turning that file-as-dir back into a plain directory.
>Some stuff you'd love to do (is, in fact, the
>reason for this all) just can't be allowed (i.e., J. Random Luser setting
>his own icon for system-wide emacs). So the tools/scripts/users/sysadmins
>will have to be painfully aware that some of the files aren't, and some of
>the directories aren't either. Major pain in the neck to use, if you look
>closer. Add extra kernel complexity. For little (if any) gain.
>
>
The gain is indeed the interesting question here. It isn't something
I desperately need. But if file-as-directory _happens_, then I hope
it'll happen in a good way. No unnecessary complications or restrictions,
and allowing existing stuff to work as well as possible. There will
surely be some
tool problems - but we certainly don't need to break every existing
tool the way a new form of "open" will. . .
Helge Hafting