[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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.

 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: