Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote: These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. ext2 doesn't. Convert it to utilize directory hashing. The ability is there but iirc isn't used by default. What does the default Debian install do? Afaik the good, old, slow linear list. With that file open/stat is O(n) and ls also O(n) (cause you keep reading the dir instead of starting at the top each time). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
In article [EMAIL PROTECTED] you wrote: Ext2 direntry is 8bytes plus filename (or onlined symlinks, which you have a lot on /usr/lib). In my case 54bytes per entry. Me bad - the symlinks are inlined in the inodes of course. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Roger Leigh [EMAIL PROTECTED] writes: The only reason we don't have it is because of petty bickering and politics between the FHS folks (several years ago). That seems a good description of the FHS in general... -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Humberto Massa [EMAIL PROTECTED] writes: with the possible exception of FAT and Minix. Q: are they used by a default? A: Last time I installed Debian (15 days ago), it asked me if I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I am pretty sure finding a file in a directory in reiserfs is O(log n) in the worse case. (Actually, I think that except for HUGE directories [far larger than /usr/lib] it accesses two or three blocks of disk in every case, hence being O(1)). How many directory entries do you think fit in a block? Does that matter? Not if it's hashed. (But then why is it O(log n) in the worst case? That sounds like a search tree strategy, not a hash.) PS: I don't know if reiserfs is doing it this way, just wanted to show how it could be done. Right. I have no doubt it can be done. It's been done for decades in non-Unixoid systems. I'm asking about Debian, here and now, under default installation options, not under what can be done in the abstract. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote: These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. ext2 doesn't. Convert it to utilize directory hashing. The ability is there but iirc isn't used by default. What does the default Debian install do? Afaik the good, old, slow linear list. With that file open/stat is O(n) and ls also O(n) (cause you keep reading the dir instead of starting at the top each time). In which case, we do have that bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Humberto Massa [EMAIL PROTECTED] writes: with the possible exception of FAT and Minix. Q: are they used by a default? A: Last time I installed Debian (15 days ago), it asked me if I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I am pretty sure finding a file in a directory in reiserfs is O(log n) in the worse case. (Actually, I think that except for HUGE directories [far larger than /usr/lib] it accesses two or three blocks of disk in every case, hence being O(1)). How many directory entries do you think fit in a block? Does that matter? Not if it's hashed. (But then why is it O(log n) in the worst case? That sounds like a search tree strategy, not a hash.) If the hash is split up over multiple data blocks then you end up with a tree or list structure on top of it. The tree is O(log n), the later O(n). The base of the logarithm would be fairly big (the tree very wide) but that is just a constant and disapears in O(). PS: I don't know if reiserfs is doing it this way, just wanted to show how it could be done. Right. I have no doubt it can be done. It's been done for decades in non-Unixoid systems. I'm asking about Debian, here and now, under default installation options, not under what can be done in the abstract. It's doing something better than a plain list. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Wednesday 11 May 2005 05:47, Goswin von Brederlow [EMAIL PROTECTED] wrote: / on LVM allows for snapshot backups which are the most convenient method of backup. Except that the kernel freezes the device because the DM lock and device node updating deadlock. Might work with udev or devfs, haven't tried that. It works in Fedora and RHEL4, must be because of udev and tmpfs mounted on /dev. In that case we should make etch use tmpfs for /dev by default. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
hoi :) On Mon, May 09, 2005 at 03:45:32PM +1000, Russell Coker wrote: Should we change some of these to /usr/libexec? well, it would be against the FHS, I think. The BSDs use libexec but I don't really see a good reason why it exists. -- Martin Waitz signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? In principle, there could be files which can be used as both a shared library and an internal binary. Where would you put such files? Should we change some of these to /usr/libexec? I don't think so. Both FHS 2.1 (referenced by the current Policy) and FHS 2.3 (the latest FHS version) mandate /usr/lib (or a subdirectory) for internal binaries. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, and having the same directory names used across distributions provides real benefits The File Hierarchy Standard[0] uses /usr/lib for these kinds of things and LSB 2.1 explicitly referes to FHS for how the file hierarchy should be laied out. So unless Red HAt is pushing for the relevant standards to be changed I believe we should stick to the standards just so the same directory names may be used acress distributions. 0) http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Pekka Himanen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Waitz [EMAIL PROTECTED] writes: Should we change some of these to /usr/libexec? well, it would be against the FHS, I think. The BSDs use libexec but I don't really see a good reason why it exists. GNU project stuff also uses libexec (by default; I don't know if that location gets overridden in debian builds). E.g., if you build your own emacs, notice it installs various helper programs in /usr/local/libexec/emacs/... I don't know if there's an argument for it other than clarity and warm fuzzies. [I personally think that if a good idea is against the FHS, the right answer is to change the FHS.] -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
[Martin Waitz] The BSDs use libexec but I don't really see a good reason why it exists. Well, the reason */libexec exists is to avoid overloading the meaning of */lib to include things other than libraries. Just as /sbin was invented (way back in the day) to stop overloading /etc with things other than config files. I agree, though, that unless the FHS decides to adopt libexec, there's little point in Debian doing so. signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: Should we change some of these to /usr/libexec? Debian strives to follow the FHS (http://www.pathname.com/fhs), and this standard does not include /usr/libexec. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146023, which mentions the use of /usr/lib/package for storing support binaries out of the way. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Miles Bader [EMAIL PROTECTED] writes: I don't know if there's an argument for it other than clarity and warm fuzzies. Not that there is anything wrong with warm fuzzies. I prefer that to a file hierarchy layout that gives me the chills. [I personally think that if a good idea is against the FHS, the right answer is to change the FHS.] Since Debian's file system layout is based on FHS, that seems to be the correct way to change things. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy and FHS-2.3? (was: /usr/lib vs /usr/libexec)
* Peter Samuelson [EMAIL PROTECTED] [050509 03:07]: Well, the reason */libexec exists is to avoid overloading the meaning of */lib to include things other than libraries. Just as /sbin was invented (way back in the day) to stop overloading /etc with things other than config files. I think one of the problems is, that the current Debian Policy still mandates FHS version 2.1 which has already been superseeded by version 2.2 in May, 2001, which has - in turn - been superseeded by FHS version 2.3 released on January, 2004[2,3]. Among some other things, FHS version 2.3 provides a /srv hierarchy to pick up at least some of the non-library contents that is currently living below /usr/lib (e.g. CGI-Scripts)[4]. Personally, I'm in favor of ultimately adopting FHS version 2.3, rather than inventing new paths (such as /usr/libexec) which does not comply with any of the FHS versions so far. This issue has also been discussed at debian-lsb some time ago, but is is not quite clear to me if this has finally led to a decision by consensus[5]. Are there any plans/work in progress in view of FHS version 2.3 and its inclusion in the policy? I agree, though, that unless the FHS decides to adopt libexec, there's little point in Debian doing so. ACK. :-) Best regards - Juergen [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 [2] http://www.pathname.com/fhs/announce-2.2.html [3] http://www.pathname.com/fhs/announce-2.3.html [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM [5] http://lists.debian.org/debian-lsb/2003/11/msg9.html -- GPG A997BA7A | 87FC DA31 5F00 C885 0DC3 E28F BD0D 4B33 A997 BA7A pgpJYEV3ZxHcs.pgp Description: PGP signature
Re: /usr/lib vs /usr/libexec
Martin Waitz [EMAIL PROTECTED] writes: The BSDs use libexec but I don't really see a good reason why it exists. It reduces search times in libraries, which is important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Monday 09 May 2005 17:17, Martin Dickopp [EMAIL PROTECTED] wrote: In principle, there could be files which can be used as both a shared library and an internal binary. Where would you put such files? Anything that's a shared object has to be in a directory that ldconfig knows about. There's nothing preventing a shared object in /usr/lib from being directly executed, there's a shared object in /lib that's regularly executed directly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, and having the same directory names used across distributions provides real benefits (copying config files and binaries from other distributions when a bug stops a server working and it's REALLY important to get it fixed fast). Should we change some of these to /usr/libexec? That would be /usr/libexec/arch-os/postfix vs /usr/lib/arch-os/postfix then. If you consider any change then please include the multiarch changes at the same time. No point doing 2 transitions for etch. MfG Goswin PS: ln -s lib /usr/libexec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 08:39:10AM -0700, Thomas Bushnell BSG wrote: Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. 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. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. Is this an issue even with modern filesystems (like ext3 with the dir_index feature turned on) for which the kernel can find a directory entry faster than in O(n) time? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
hoi :) On Mon, May 09, 2005 at 08:38:02AM -0700, Thomas Bushnell BSG wrote: The BSDs use libexec but I don't really see a good reason why it exists. It reduces search times in libraries, which is important. well, /usr/lib is not _that_ crowded. Any sane filesystem should handle that many files/subdirs. And they are very likely in RAM already. so, do you have any numbers? -- Martin Waitz signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] 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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] 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. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:33:32PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] 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. You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. 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? That's a completely different question... which I don't think I need to answer. I was responding to your invalid criticism of the linker. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] writes: You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. How does ld determine that -latoheun will fail, other than by listing the directory O(n)? How does ld find -lfoo, without searching through, on average, half the entries? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
ma, 2005-05-09 kello 14:39 -0700, Thomas Bushnell BSG kirjoitti: Daniel Jacobowitz [EMAIL PROTECTED] writes: You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. How does ld determine that -latoheun will fail, other than by listing the directory O(n)? How does ld find -lfoo, without searching through, on average, half the entries? I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. I suspect this is what Daniel tried to say: that filename lookups aren't O(n) anymore. This means that the performance reason for keeping /usr/lib small is gone. This, of course, has no bearing on whether /usr/libexec should exist or not for other reasons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Lars Wirzenius [EMAIL PROTECTED] writes: I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. Right, and open is O(n) on just about every system. If that's not true on ext2, then that's good news, and I'm surprised. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. Actually, even systems as old as ITS used better than O(n) directories. It's Unix that has historically stunk. It's not a modern/old thing, it's a Just Do It thing. Which Linux filesystems have better than O(n) performance on open? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: 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? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. 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. That wasn't my argument. My argument is that I don't consider shared libraries and internal executables different kinds of things. They are both binaries loaded and executed by a program. If there is a _technical_ necessity to separate them (like directory search times), this would be similar to /bin vs /usr/bin, which are also separate for technical, but not semantic reasons. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas, please read http://www.nl.debian.org/doc/developers-reference/ch-resources.en.html#s-mailing-lists-rules about not sending Cc's unless people explicitly ask to be copied. (Mail-Followup-To is non-standard and badly supported, and also unnecessary. Any decent mail user agent can deal with the default case of not doing a Cc, without help from M-F-T. Ctrl-L in Evolution.) ma, 2005-05-09 kello 14:53 -0700, Thomas Bushnell BSG kirjoitti: Which Linux filesystems have better than O(n) performance on open? I haven't studied all of them so I won't speak authoritatively. mke2fs(8) documents one. The option was just mentioned by Martin Dickopp earlier in this thread in the message archived at http://lists.debian.org/debian-devel/2005/05/msg00443.html . (As far as I care, this topic is dealt with. We can move on to other misunderstandings now.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: 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? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. That wasn't my argument. My argument is that I don't consider shared libraries and internal executables different kinds of things. They are both binaries loaded and executed by a program. Sure, and documentation and libraries are both files opened by programs. The difference is that libraries are also generic things that are shared by many programs, and searched by the linker, whereas executables are not. In fact, a library is loaded and executed by only two programs (ld and ld.so) in the normal scheme of things. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Lars Wirzenius [EMAIL PROTECTED] writes: I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. Right, and open is O(n) on just about every system. If that's not true on ext2, then that's good news, and I'm surprised. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. Actually, even systems as old as ITS used better than O(n) directories. It's Unix that has historically stunk. It's not a modern/old thing, it's a Just Do It thing. Which Linux filesystems have better than O(n) performance on open? Thomas Which doesn't? Minix maybe. Even ext2/3 has hashes for dir if you format it that way. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: Which doesn't? Minix maybe. Even ext2/3 has hashes for dir if you format it that way. Is this the Debian default for installation? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: 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? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. That depends on how you get rid of it, i.e. if you get rid of /usr/bin in favor of /bin or vice versa. :) /usr can be shared between machines, which is IMHO a reason to have as many executables and libraries as possible under /usr. If /usr is shared, there is also a before /usr is mounted. The difference is that libraries are also generic things that are shared by many programs, and searched by the linker, whereas executables are not. I see your point, and I agree that this would be a good way to separate things. However, the separation should then indeed be based on whether a binary is used by many programs or not, and not on whether it is a library or an executable. For example, the mozilla-firefox package contains some libraries (*.so files) which are specific to firefox and which are not used by any other program. IMHO, these should _not_ be in (or under) /usr/lib in such a scheme. That said, I don't feel strongly enough about this to lobby for an FHS change. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: 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? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. Why, exactly? I know people think it's obvious, but the lack of stated reasons worries me. I know the *original* reasons why / needed to be small, but they don't apply anymore. So I'll buy the it's obvious if you can state the original reasons and explain why you think they still apply. If not, then what is the current reason? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. Why, exactly? I know people think it's obvious, but the lack of stated reasons worries me. I know the *original* reasons why / needed to be small, but they don't apply anymore. So I'll buy the it's obvious if you can state the original reasons and explain why you think they still apply. If not, then what is the current reason? Thomas - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing problems for /boot. - a larger FS has more chance of failing so you risk having a fully broken system more often - /usr can be easily network (shared accross the same arch) mounted while / (due to /etc) can't - / needs functioning device nodes on it while usr can be mounted nodev - a small / can be replicated across many disks to ensure the system always comes up and e.g. at least send an email to the admin. / can even be an initrd ... MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
In article [EMAIL PROTECTED] you wrote: - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing problems for /boot. Why is that? - a larger FS has more chance of failing so you risk having a fully broken system more often And two file systems have even more chance. One read only file system is pretty stable. - /usr can be easily network (shared accross the same arch) mounted while / (due to /etc) can't - / needs functioning device nodes on it while usr can be mounted nodev I agreee, those arguments and the netboot stuff is an argment for a smaller root partition. However our root filesystem is too big anyway. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/usr/lib vs /usr/libexec
It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, and having the same directory names used across distributions provides real benefits (copying config files and binaries from other distributions when a bug stops a server working and it's REALLY important to get it fixed fast). Should we change some of these to /usr/libexec? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
