[opensuse] programs in /sbin -- why aren't they in /usr/sbin?
Some of the programs in /sbin don't seem to make sense and I was wondering why they had not been moved to /usr/sbin Specifically: (part of info package): /sbin/install-info (part of rpcbind package): /sbin/pmap_set2 /sbin/rpcbind /sbin/rpcinfo There may be others, but these stood out because they require libraries in /usr/lib64 -- and it seems a bit intuitive that if a programs's libraries are in /usr/lib64 that would expect the program to be in /usr/[s]bin. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-10-05 12:32 a.m., L A Walsh wrote:
Some of the programs in /sbin don't seem to make sense and I was wondering why they had not been moved to /usr/sbin
Why? Oh, sure, the _original_ reasoning was that what was in /bin and /sbin were what was needed early on in the boot/loading, before /usr/was mounted. That was then, this is now. There are all sorts of arguments (and I realise, Linda, your anti-systemd proclivity might mean you don't subscribe to some of them) for the unification of /usr on /. That now seems to be common practice, although, not I've mentioned it I'm sure people here will discuss it. I can see why you might need RPC networking early on, so if you can demonstrate, very specifically, that need ... But as it stands, my argument might be with /usr/bin & /usr/sbin overloading, but it is a weak one. It /might/ hold if you use a file system with directories that have to be searched linearly, like the old V7 UNIX, but most file systems have hashed directories these days. Well, OK, that has its downside as well. If you are treating files 000001.jpg, 00002.jpg ... 99999.jpg in order then the hash table might slow you down a bit. Some people solve this by using subdirectories covering various ranges. And Yes, this is relevant to things like news server. Of course you use XFS, don't you, Linda? It is mentioned here. https://lwn.net/Articles/400629/ OK, to get back on subject ..... Then, for other matters, the shell does pathname cashing for executables. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/5/2018 7:06 AM, Anton Aylward wrote:
Of course you use XFS, don't you, Linda?
Here's a more recent article (2018) regarding tuning xfs for parallel loads -- getting io-wait time down to .3% compared to 5% on ext3. Default w/o tunning for xfs was a 30% wait time. I.e. tuning gives a 100x speed up on parallel loads, whereas ext3 didn't appear to have the same type of knobs to turn. https://www.techforce.com.br/2018/01/lvm-raid-xfs-and-ext3-file-systems.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/04/2018 11:32 PM, L A Walsh wrote:
Some of the programs in /sbin don't seem to make sense and I was wondering why they had not been moved to /usr/sbin
Specifically:
(part of info package): /sbin/install-info
(part of rpcbind package): /sbin/pmap_set2 /sbin/rpcbind /sbin/rpcinfo
There may be others, but these stood out because they require libraries in /usr/lib64 -- and it seems a bit intuitive that if a programs's libraries are in /usr/lib64 that would expect the program to be in /usr/[s]bin.
I always looked at those sort of issues as "battleship issues". The reasoning behind why we continue to need battleships is "we have always had battleships". History and "that's where they have always been" probably plays a large part in it. I'll defer to Anton's depth of knowledge here, but to me, they are just "battleship issues." -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Anton Aylward -
David C. Rankin -
L A Walsh