Re: traceroute in /usr/bin, not /usr/sbin
(not really a reply to anything, but still on the thread)
OK, let's start talking sense here.
There are two camps in this discussion. One camp that thinks traceroute is
fine where it is right now (namely in /usr/sbin) and one camp that thinks
it belongs in /usr/bin. The latter camp argues that this would be more
FHS-compliant. The first camp argues that perhaps FHS says traceroute is
not an admin tool, but that the same goes for lots of other programs in
/sbin and /usr/sbin, that it would be unfair to say that only traceroute
should be moved, but that all those other programs can stay where they
are.
Personally, I don't think ifconfig and traceroute can be considered the
same type of tools. Agreed, traceroute is usually used to do network
administration, as is ifconfig. However, there's one (IMHO) big
difference: you don't use traceroute to change some setting on the local
machine; instead, usually you use traceroute to *find out* whether some
network setting on (most likely) *another* machine is wrong, while
ifconfig's main purpose is to *set* the network-configuration on the
*local* machine.
I feel that there's a huge difference between ifconfig on the one hand,
and traceroute on the other. You could say that ifconfig is an
administration tool intended for the local superuser (while it can also be
used by $lusers to find out some information on the network), whereas
traceroute is an administration tool intended for "some" superuser, which
is not usually the local superuser.
If he's got an account on that machine, he'll probably be a normal user.
I think that traceroute is a user tool. And that ifconfig is an
administration tool.
The easiest argument to this would be: "FHS does not define administration
tools this way, so if we do it that way, we're not FHS-compliant".
Correct. But while it's a good thing to follow standards, no single
standard should be looked at as the holy bible. In this particular case,
we'd be following the definition for a *software category* as defined by a
*filesystem standard*. A lousy definition, IMHO:
'Deciding what things go into "sbin" directories is simple: if a normal
(not a system adminstrator) user will ever run it directly, then it must
be placed in one of the "bin" directories. [...]'
Why do I find this a lousy definition? Let me give you another example:
'Deciding whether an eating utensil is a Chinese eating utensil is
simple: if a non Chinese person will ever use it, then it is not a Chinese
eating utensil'...
I doubt it's that simple. Chop-sticks are Chinese utensils; the fact that
I (sometimes) use them, does not change that. ifconfig is an
administration tool; the fact that users may use it from time to time,
does not change that.
Just my 2 cent...
--
wouter dot verhelst at advalvas in belgium
Try does not exist. Believe that you will do it, else you will fail.
-- Luke Skywalker,
in the trilogy "The Jedi Academy", Kevin J. Anderson
Reply to: