[gobolinux-users] Minor hierarchy design overhaul - Occam's razor

[Michael Homer]

On 3/20/07, Nick Matteo <kundor at kundor.org> wrote:
> On 3/19/07, molfar <molfar.ua at gmail.com> wrote:
> > On 3/17/07, Nick Matteo <kundor at kundor.org> wrote:
> > > [/Depot] addresses a deficiency in the standard file system hierarchy.
> > > There are places for distro-provided programs and packages; and there
> > > are places for individual user's files; but there isn't a place for
> > > files shared by users but not provided by the distro or a package.  A
> > > filesystem hierarchy standard ought to address all the filing needs of
> > > the system, and so Gobo provides one.  I think this is a really good
> > > idea.
> > And what if I personally want to have such folder named /Store? And if I
> > don't need such folder at all? This is much more probable situation, since
> > I, personally, and I am sure most people are using Gobo as a single-user
> > desktop. Thus it is more logical to create needed directory ad hoc in
> > multiuser environment than have it deleted manually every time I install or
> > upgrade the distro.
> > And I disagree that FSH standard should provide for such a folder. We have
> > lived without it and I see no really solid reason why things should change
> > in this case.
>
> I have a single-user desktop and /Depot is my largest folder.  It
> holds all my music, movies, videos, downloads, ISOs.  This is because
> I run multiple operating systems, and I want to get to my media from
> all of them, so it's a separate partition; sometimes I run different
> users to have different desktops, home setup, etc, but still want
> access to all my documents.
> Having a standard name is important because it allows it to be found
> by standard tools.  Download dialogs, for example, which commonly show
> the home directory and Desktop as default options, could show Depot as
> well if it were standard.  Recent Document menus would know to track
> it as well as the home directory.  Media jukeboxes would know to
> search there as well as under $home.  The list goes on ;-)
> That sort of thing is why we have a filesystem hierarchy standard in
> the first place.  The FHS fails to address files which are provided by
> users which should be available to other users, leaving us with a
> dearth of tools and options to deal with such situations.
That's exactly my experience as well, on my old system. This one's too
new to have things set up like that yet.
> > > > [4]. What use is for /System/Links/Manuals and Shared folders? Why index
> > > > them?
> > > So that "man whatever" works.  The man program needs to know where to
> > > find manual files.  Same for "apropos" and "info."
> > I've already replied to Michael Homer about that - it seems that it is
> > possible to provide for such a PATH in "man.conf" itself. Haven't tried it
> > myself)) but it possibly could prove useful.
>
> Huh?  No matter what you do in man.conf, you still need a path to give
> it.  Do you propose listing every program directory in there?  Not
> only would that give abysmal performance, it would mean man.conf would
> have to be edited whenever a program was installed or removed -- which
> would break the Gobo philosophy of package management using file
> system tools.  (IE, rm -rf /Programs/Foo wouldn't be sufficient.)
Just having a look at it, it's not even Gobo-ified. It just looks in
/usr/man, and then several others that all symlink to the same place.
There's pretty much no reason to edit it ever. I think the recipe
should patch it to look in /S/L/M though. Now it makes four
unnecessary searches when it doesn't find something the first time.
> > > "Shared" are files shared between programs.  They have to all be
> > > accessible in one place for various programs to know where to find
> > > them -- each program has no way of knowing what other program may or
> > > may not have provided relevant files.
> > > Yes, it's prettier for users to look under the program's individual
> > > directory.  That's why these links are under System, where you're not
> > > supposed to look ;-)
> > That's a good reason :). However it's smth that can be regarded to classical
> > nix FSH as a whole. You are not supposed to look at anything but files in
> > your own ~/user folder. But this way there wouldn't be Gobo in the first
> > place. We talk about design principles here - to make system more logical an
> > less cluttered, not about having to look somewhere or not))
>
> Pretty layout is nice, but some things are necessary for the operation
> of the system.  That's why it's called /System -- it's where we can
> shove the necessary parts so that they don't interfere with the pretty
> layout which users can use to navigate anywhere they need.
>
> If it were up to me, I'd move /Settings up to the root dir, since
> users do need to deal with it, and gobohide /System.
I wouldn't, just because I think "System settings" throws up a red
flag for people that they should be careful. But I could go either way
really.
> They obviously don't belong in /Depot, /Users, or /Mount.  Since
> they're not provided by a Program, they can't be kept in /Programs.
> End users want to see them and manipulate them, so they shouldn't be
> in /System.  They're not Links; they're not Variable; they're not
> Settings; they're not from the Kernel; and they aren't used by the
> System, but by Programs. There's not really a better place for them to
> live.
Excellently put.

I also endorse what Jonas, Lucas, and Hisham wrote, pretty much in the
entirety. /Files could benefit from some rethinking, I think, and
/S/K/B has been shown to be necessary for several reasons. Molfar,
you've obviously put a lot of thought into this subject, so I'm
interested in what other ideas you have for /Files particularly.
-Michael