Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz <dan@debian.org> writes:
> On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote:
>> Daniel Jacobowitz <dan@debian.org> writes:
>>
>> > The number of directory entries in /usr/lib should not make any
>> > difference to a modern GNU linker on a modern filesystem, unless
>> > you have thousands or millions of them.
>>
>> Why? Is there magic now?
>
> What magic do you need? Most filesystems can open a file without
> doing an O(n) lookup, especially from the dentry cache.
Huh? The dentry cache turns ls into O(n) instead of O(n^2), but that
doesn't mean that searching every item in the directory isn't still
necessary, unless the directory is hashed or stored in as a tree.
I suppose the real question is "why have a directory tree at all?" If
there is a reason to separate /usr from / (which so many people think
there is, though I don't understand why, since it has no semantic
significance at all), why separate /lib from /etc? Why not put every
file in one place, actually?
We could just have /, and /bin, put every package in / under its own
name, and be done with it.
Surely the reason who have these different directories is to make
logical distinctions, keeping different kinds of things in different
directories. If the argument for combining libexec and lib is that
"it does no harm", then I see why we should not put *everything* into
lib. It would make it simpler.
So the question is: why is it useful to make some distinctions
(including non-sensical ones like /usr vs. /) but not this one?
Thomas
Reply to: