[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.



Written by The Wanderer
> Well, if all you want is to be able to have more "newbie-friendly"
> descriptive names of the directories, it might be possible to achieve
> something like that by the simple addition of a collection of symlinks;
> just symlink e.g. "/Configuration" to '/etc', '/Programs' to '/bin',
> "/System Programs" to '/sbin', '/User Files' to '/home', et cetera.
>
> That wouldn't get rid of the existing names, but it would be simple to
> implement as a single nearly-empty package.
>
> I imagine one could also set up a custom configuration of some file
> browser such that it would hide displaying the "real" names, and then
> ship a sort of micro-distro (installer task, maybe?) which installs the
> symlinking package and that file browser as part of its standard UI
> setup. It wouldn't be perfect, but it might meet the described want.

I was thinking about that, but something could go wrong with that:

Written by me.
> >> I was wondering what would happen if some program used filesystem paths
> >> as its input data for some processing task.  He he, yes, changing status quo
> >> is not easy

Written by Stefan Monnier
> > Here's one source of breakage I encountered a few times because of this
> > /usr merge (which I generally welcome, BTW):
> >
> >     dpkg -S =foo
> >
> > this (using the Zsh shell) should give me the name of the Debian package
> > which provides the command `foo`.  It works well for most commands, but
> > it fails for `ifconfig` because `ifconfig` was actually installed in
> > /sbin/ifconfig (but the /usr merge makes this same /sbin directory
> > available under the name /usr/sbin so Zsh thinks that `ifconfig` comes
> > from `/usr/sbin/ifconfig` whereas `dpkg` doesn't have any record of
> > installing a `/usr/sbin/ifconfig` file).

Written by me
> Yes, before every possible bug derived from that change is corrected,
> you could use some sort path translation program
> that takes paths from the caller program and translates it
> to some path the called program can understand.
> Just thinking.

It could happen again.


Reply to: