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

[Michael Homer]

On 3/17/07, molfar <molfar.ua at gmail.com> wrote:
> Hi, All!
> I've been meditating on ideas behind Gobo for almost a week now, reading
> Hisham's explanations and trying to perceive the inner logic of this distro.
> Eventually, several questions arose that didn't have suitable answers (at
> least for me). Either it is something that is beyond my knowledge on the
> issue or my understanding of Hisham's ideas. If I am wrong - please, correct
> me. But if those questions are reasonable - they might fall under the
> category of "improvement ideas".
> First of all, I strongly support the idea of having the whole FS tree
> rethought and done 'right' or at least logical. However, it seems, due to
> some complications, the design hasn't been completed - there are several
> inconsistencies that can/should be resolved.
> Let's begin:
>
> [1]. Why there is no symlink for "/System/Kernel/Boot/menu.lst" in
> /System/Settings folder? Or why not move it completely there? Wasn't it the
> idea in first place to have functionally separated folders that would
> contain all the relevant links and files, in this case for system tuning, so
> that users wouldn't have to search for them in other less obvious locations?
> There might be other missing links, however, I might not have stumbled upon
> them just yet.
The reason it's in /S/K/Boot, I imagine, is so you could have it on a
separate partition. A symlink would be nice I guess. In the
separate-partition case it would probably be a dead link, though,
since you wouldn't have Boot mounted once the system was up.
> [2]. What is "man.conf" symlink doing in /System/Links/Libraries? Isn't it a
> config file? Or maybe I don't get smth? No, I see that it originates from
> /Programs/Man/1.6d/lib but isn't it some kind of bug?
I don't think man.conf is intended to be edited, although I'll defer
to somebody who knows more about it.
> [3]. Personally, I fail to see any rationale behind having "/Depot" folder.
> I think it's redundant. Why force a special directory if a superuser could
> create any /pub, /Store etc. folder for the same purpose? Anyway, it's not
> for distro to decide whether I want my "pub" or not. Right?
`rmdir /Depot && problem=solved`. Having a standard name for it
probably has benefits, although I don't much use it myself (it's
mostly symlinks to areas of other filesystems).
> [4]. What use is for /System/Links/Manuals and Shared folders? Why index
> them? One thing if you index standardized files like .h or libs or execs -
> that way you can improve search procedures etc. But what good is it for say
> info/manuals or shared? There is such a mess in relevant folders that it is
> a lot easier to look up needed info in program's directory itself. If I am
> mistaken and these folders are needed for some peculiar functionality or
> improved compatibility with legacy three - then ok, but at least smth has to
> be done to unclutter them and make more useful. The state they are in now
> makes them pretty much rudimentary.
Shared needs to be combined so that everybody looks in the same place.
Otherwise it wouldn't be "shared", would it? Many applications want
files from other packages.

If you're looking something up from a specific program, you should
always go through its directory in /Programs. Working through the
symlinks is just a waste of effort then.
> [5]. Abstract folder like /Links (/System/Links) is unnecessary. Its
> subfolders should be moved one level up to reside directly under /System
> directory. This would eliminate the logical inconsistency for having normal
> files together with symlinks in one folder like, for example, in
> /System/Settings. Anyway, the idea of Gobo's symlink magic can be well
> written out in wiki, manifesto whatever. Why complicate folder tree?
I really have no view one way or another, but I really don't see the
point in optimising for a case that never occurs - when are you ever
going to access /S/L/* directly? They exist only to collect everything
in one place to be used in the various PATH variables and such.

I'm not sure I understood the part about eliminating the logical
inconsistency; could you go into that a little more?
> [6]. The /Files folder seems to be misplaced as well (IMHO). Orphaned to
> say. It would be reasonable to have it under /System (like /System/Files/)
> so that possible confusion as to its function can be avoided. I can think of
> no particular strong reason why it should remain where it is now. And moving
> it should be reasonable not only functionally but aesthetically as well.
Also no view. I have a slight dislike of shifting basically everything
to reside under /System, though. "/System/Files" is a little
misleading as well. Especially if you've moved everything from /S/L/L
into there as well.

All-in-all, I don't see there's enough advantage in any of these for
it to be worth changing - it's just a convention, and there has to be
one of some kind.
-Michael