Re: Filesystem Hierarchy Standard (FHS) and NetBSD

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello!

Jeff Licquia <licquia%linuxfoundation.org@localhost> writes:

> (Sorry if this isn't the proper list for this discussion.  If
> not, please point me in the right direction.)
>
> The Linux Foundation's LSB workgroup has taken over maintenance
> of the Filesystem Hierarchy Standard, and is working on a number
> of updates needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to
> make sure that the FHS remains independent of any particular
> UNIX implementation, and continues to be useful to non-Linux
> UNIXes.
>
> My question to you is: do you consider the FHS to be relevant to
> current and future development of NetBSD?  If not, is this
> simply due to lack of maintenance; would your interest in the
> FHS be greater with more consistent updates?

Honestly, I don't understand what you might want to expect here.
You're coming into community with long-established file hierarchy
standard and propose to elaborate file hierarchy standard.
This alone sounds stupid. At best, you're going to hear replies like
"we've been doing it this way for decades before you came."

Next, not all people want such one-size-fits-all standards.

Users have diverse needs, and "one /bin for all" just doesn't work.
For instance, what do you propose for third-party optional software? "/opt"?
What if I need _two_ such constructions simultaneously? I do, really.
What if I want small root FS, potentially read-only, and space for experiments?
This means that I want this second "opt" live somewhere else.
But then, why am I to keep "/opt" on root file system at all?
I have parts of non-essential system tools in "/usr/bin" already,
why not "/usr/local" or "/usr/pkg" then? Note, that I want to keep
managed packages and unmanaged software separate. Hence no one single "/opt",
I need "/usr/local" _and_ "/usr/pkg," Both. Simultaneously.

Alternatively, why am I to bite nails inventing new names and renaming
programs and libraries so that they all fit single "bin-lib-share-man-etc"
frame? Why am I not to install each package into its separate subprefix?
What if I abandon dialogue interfaces of seventies in favour of modern
graphical environment? I'm not going to have search path at all, hence
having single "bin" doesn't matter to me. What does matter is the ability
to manage packages without handpicking files that are scattered along
directory tree just to satisfy egos of people on some committee.

In my opinion, FHS is nothing but anachronism. It could be useful in
eighties or early nineties, when, if only designed properly, it could
have saved some people from learning the hard way. Nowadays it isn't
useful at all. What is useful from available experience is convention on
names for common places: "bindir", "libdir", "mandir", "datadir", etc.
Perhaps this is the only place, where any related standard could be useful,
if we can get people to maintain consistency, to separate places for _sample_
configuration files and _real_ configuration files, perhaps some more neatness.
Otherwise FHS is nothing but anachronism.


-- 
HE CE3OH...