Martin Man wrote:
> Roland Mainz wrote:
> > Martin Man wrote:
> >> David J. Orman wrote:
> >>>> Alan Coopersmith wrote:
> >>>>> Dennis Clarke wrote:
> >>>>>
> >>>>>> Was there a document at some point in history ( this is UNIX and it
> >>>>>> has tons of history ) called the FSSTD or was it FHS ?
> >>>>>>
> >>>>>> http://www.pathname.com/fhs/pub/fhs-2.3.html
> >>>>>> ( this may be a Linux animal however )
> >>>>> That's the Linux Standards Base filesystem layout, and should be
> >>>>> violently ignored by Solaris.
> >>>> Yes, I can only second that comment. The "Linux Standards Base
> >>>> filesystem layout" is totally braindead.
> >>>
> >>> Thirded. It's terrible.
> >> Anyone having some pointers to concrete evaluation/discussion why this
> >> document is terrible, brainder, flawed, etc?
> >>
> >> no religion please...
> >
> > My personal complaint is that they stuff everything into /usr/bin/. Unix
> > had some kind of "namespace" support via the elements in ${PATH} so
> > having package groups seperated into /usr/dt/bin/ (CDE), /usr/kde3/bin
> > (KDE3), /usr/xpg4/bin/ (XPG4 personality) and so on is a much cleaner
> > approach than stuffing everything into /usr/bin/.
>
> Good package management (that is not present ATM in Solaris) will take
> care of /usr/bin for you.
This is wrong. It can only handle the job if you are 1) "root" and 2) do
not care about stable paths and locations. A normal user in a large
multiuser system cannot simply run around and change the packages ad-hoc
without causing trouble for other users.
Unix (and therefore Linux) was designed to have some concept of
"namespaces" via the elements in ${PATH}. The shells depend on this
feature. Many other stuff in the Unix/Linux world depend on this
concept, too (for example ksh93 has builtin commands which get executed
when certain parts of ${PATH} are searched). The LSB way of stuffing
EVERYTHING into /usr/bin/ breaks that in a very BAD way.
By definition /usr/bin/ should only contain the minimum set of
executables for a system in networked multiuser mode (run level 3).
Graphical user interface is an add-on and therfore located elsewhere
(/usr/X11R6/bin/ or /usr/X11/bin/). Development stuff is an add-on and
therefore located elsewhere (/usr/ccs/bin/). Graphical desktop is an
add-on (on top of X11) and therefore located elsewhere (usually
/usr/dt/bin/ for CDE, /usr/kde3/bin/ for KDE3 and in theory
/usr/gnome/bin/ for Gnome (assuming the /usr/bin/ madness wouldn't have
infected the Gnome people, too)). Non-standard extensions to the basic
multiuser system live elsewhere until they become the standard (good
example are the PROC utilities who lived in /usr/proc/bin/ until they
became part of the OS core after the API became stable). Even system
adminstration tools are located elsewhere (e.g. /usr/sbin/) for similar
purposes.
The idea of stuffing all those add-ons into /usr/bin/ causes a giant
namespace clash. And just adding version numbers to the executable names
makes it even WORSE. MUCH WORSE.
> > Same applies to
> > ${MANPATH}&.co. There is no real way anymore to set/override/disable
> > things since it's now all in /usr/bin/.
>
> When you need to override the things, debian comes with alternatives
> mechanism that works pretty well in most cases...
See above. Basically the concept stuffing everything into /usr/bin/
makes such operating systems no longer a variant of Unix at all - they
really cannot even claim compatibility with them as this is one of the
very basic concepts where much stuff relies on.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
