Wichert Akkerman <[EMAIL PROTECTED]> 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
