Re: Intent To Split: netbase
>>"Branden" == Branden Robinson <branden@debian.org> writes:
Branden> Could you remind me what these benefits are again? Pretend
Branden> for a moment that the FHS doesn't exist and it's entirely up
Branden> to us. What exactly DO we gain by having some binaries
Branden> segregated off into sbin?
You and I? Perhaps nothing. But then, we are not exactly
typical users either. A novice? Well, I remember how overwhelming
UNIX was back when I started. I had a minimal path, and then I
started exploring each command as I came across it. If I may quote
myself:
Manoj> The /bin vs /sbin distinction is purely about avoiding
Manoj> inconvenience and/or confusion for the normal user. The sole
Manoj> thing accomplished by putting some things in /sbin rather
Manoj> than /bin is that if you don't put /sbin in your path, you
Manoj> won't see those things. I myself, probably like most people
Manoj> on this list, rarely notice the distinction since I do have
Manoj> /sbin and /usr/sbin in my path. But the idea is that the
Manoj> average user won't have /sbin or /usr/sbin in their path, and
Manoj> so the programs in those directories can have simple names
Manoj> for the convenience of those who do use them, without an
Manoj> average user either accidentally running one because it has a
Manoj> simple name they confused with something else, or getting a
Manoj> lot of confusing possibilities in a command completion list.
Manoj> The things that we do put in /sbin, for the same reasons, we
Manoj> expect that the average user will not use them and might be
Manoj> confused by encountering them. For example, mkfs and fsck
Manoj> and so forth are in /sbin. Anyone can use these, on a file
Manoj> or on a device they have permissions for. It's not that we
Manoj> expect only root to use these, but that we expect anyone who
Manoj> wanted to use them to probably know enough about the system
Manoj> to be root (or at least enough more than the average user
Manoj> that they can handle putting /sbin in their path).
Branden> So why isn't netstat in sbin?
Well, it is an informational program, mostly; route is
informational only in oner of it's modes of operation. I would even
go out on the limb and say that the primary purpose of route is not
to behave like netstat -r. route add/del commands normally do require
special priviledges.
Branden> I think a set of rational and intuitive grounds for
Branden> determining what goes into sbin is good for everyone. ping
Branden> is in bin, traceroute is in sbin; netstat is in bin, route
Branden> is in sbin...
Hmm. I shan't defend traceroute, I do think it belongs in
/bin. route, though, is something else, as I have explained above.
The hueristic that I see glimmering under there seems to be that
anything that may affect other users on a multiuser machine out to
require sysadmin prviledges. *Sigh*. I wish I had not said that,
since now you shall proceed to shoot holes into it. But that is
indeed the principle I use in determining whether, in *my* opinion, a
program belonfgs in sbin or bin.
I admit this criteria is not bullet proof: I have been
convinced, by the presence of user mountable entries in /etc/fstab,
that mount does belong in /bin; previously I would have argued that
mounting and unmounting file systems is not a user task.
Another point is that chown/chmod are in /bin, but ifconfig is
not; chmod uses file permissions, and an unpriviledged user can't
modify files they do not own, and similarily they can't affect
interfaces they do not have permission to using ifconfig. The
difference, IMO, is that it one can (and people quite frequently do)
user chmod on files they own; ifconfig is far less likely to be sued
by the general user. (Offhad, I can;t see me useing chown, since one
needs permissions anyway for that).
No, I do not have hard rules. I do have a a fuzzy guidelines,
a well defined (but hard to categorize by) set of goals for the
separtion of the path components, traditional placement of commands,
and the FHS to go by.
And I do think that the goals have merit, even though to
experienced users, who frequently are sysadmins, the boundary has
become very blurred.
You have also, perhaps correctly, classified me as an old
fashioned curmudeon who is wildly conservative. Perhaps. I do tend to
resist change merely for the sake of change, or for benefits that I
believe are unpalpable compared to compatibility and tradition lost.
Convince me that the benefits of not having to modify ones
path is worth the potential confusion to newbies, and worth losing
the imprimatur of FHS compliance by yet another notch, and I'll
support doing away with sbin. But so far I ahve not been convinced.
Branden> Please identify the extrinsic factors that you think trump the
Branden> characteristics of the actual program.
If you are using part of the usage space of a program to
justify moving it to bin, I would say that the presence of an
alternate user space (as opposed to sysadmin space) program should be
enough to counter the argument.
Indeed, I am being delibrately careful to appeal to common
sense, rather than a set of rules that require more care to set up in
order to be loophole proof than I have time to spare ATM. Indeed, I
am not sure I want to come up with a ruleset until we examine a few
more programs on a case by case basis.
manoj
--
Why are many scientists using lawyers for medical experiments instead
of rats? There are more lawyers than rats. The scientist's don't
become as emotionally attached to them. There are some things that
even rats won't do for money.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: