Re: missing FHS archives
Wichert Akkerman <wichert@cistron.nl> writes:
> I really don't see the use.. if I follow your logic then /usr/lib should
> be just libraries. Okay, but now I have a program that uses a couple
> of bitmaps in its userinterface.. lets make /usr/libbitmap then!
Actually it's /usr/include/X11/bitmaps [1]
There's also /usr/include/X11/pixmaps
As well as /usr/share/icons
and /usr/share/pixmaps
(which seems to contain png's these days, strangely enough)
> Oh, wait, there are some audio effects. I guess we need to make
> /usr/libaudio as well then.
/usr/share/sounds actually.
> And while we're at it why not do /usr/libhelp as well?
Like /usr/share/man and /usr/share/info? Of course it can only have a location
outside of the application's data directory if it's in a common file format.
The only common help file formats are manual pages and info files, both of
which do have directories set aside for them.
That's sort of the point. If we take the easy way out and just toss everything
into application specific directories then things work smoothly but we never
get the useful benefits an integrated system has. Things like a documentation
browser that can view all the manuals for all of the system. (Like "man" in
the days of yore. One day we'll maybe recover our lost paradise with the likes
of debian's doc-base)
> But now we decide we need some static datafiles from which we
> extract information, so lets make /usr/libdata as well.
Well "static datafiles" is pretty generic, it includes all of these different
formats. If they're truly application-specific undocumented data then of
course it depends in a directory "owned" by the application. But applications
should strive use common documented data formats, with files that can be
shared across the entire system.
That's what makes an integrated system instead of a set of programs all trying
to reimplement the same wheels. That's how we avoid the "Office" malaise of a
suite of applications that don't play well with programs outside the suite,
and have to implement features that belong in the OS for all programs to use.
--
greg
PS:
> As you see this quickly becomes extremely silly. Also consider the
> difference between a library and a helper binary is really very minimal:
> they are both ELF objects that contain code that a program needs. The only
> difference is that one is linked into the binary and the other is run as a
> seperate process.
Well, they share a lot in common but they also are used in different ways. It
would be nice if binaries were in a separate tree for security audits -- being
able to look for any executable files outside of the correct place for
example. Or being able to mount everything except the appropriate directories
with the noexec flag.
For what it's worth, this is the flip side of my crusade against *sbin. It's
actually important to data organized along the lines of what kind of data it
contains. It allows for useful things like mounting different partitions with
different options or on different types of drives. It allows for being able to
effectively share partitions between machines safely, etc. sbin on the other
hand makes all these things more difficult because it's vague and poorly
defined and it's orthogonal to the normal rules for organizing data.
[1] I've argued weakly against "/usr/X11R6" before, the collection of things
under it have relatively little to do with the X11 project any more, no more
than putting everything in debian under /linux would today. But it's awfully
entrenched.
--
greg
Reply to: