Manoj Srivastava [EMAIL PROTECTED] writes:
John Anyway, I think the current situation is largely fine, although
John I am still dismayed by the lack of statically-linked binaries
John in /sbin.
If I recall corectly, the argument went that we had a rescue
disk, so we did not
John == John Goerzen [EMAIL PROTECTED] writes:
John Actually, this is incorrect. On platforms predating
John FHS/FSSTND, /sbin was for statically-linked binaries --
John versions of vital system tools (fsck, sh, etc) linked
John statically for repair in an emergency. You may recall I have
I'll be happy to do whatever is required for sendmail, but we also need
the assistance of (at least - any others?):
LaMont Jones [EMAIL PROTECTED] postfix
If someone wants to tell me exactly what to change and how (I haven't
had to deal with alternatives before...), I'd be happy to make
On Thu, Aug 17, 2000 at 01:06:26PM -0700, tony mancill wrote:
I disagree. You *NEED* to have a copy of mke2fs in the root filesystem
in case /usr or any other mounted filesystem gets whacked. OTOH, you
probably won't be mastering any CD images while your system is crippled,
so having mkisofs
Branden == Branden Robinson [EMAIL PROTECTED] 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?
Manoj Srivastava [EMAIL PROTECTED] writes:
Manoj The /bin vs /sbin distinction is purely about avoiding
Manoj inconvenience and/or confusion for the normal user. The sole
Actually, this is incorrect. On platforms predating FHS/FSSTND, /sbin
was for statically-linked binaries -- versions
On Fri, Aug 18, 2000 at 12:44:37PM -0500, John Goerzen wrote:
Anyway, I think the current situation is largely fine, although I am
still dismayed by the lack of statically-linked binaries in /sbin.
I suppose that's OK too, as long as the binaries are only linked with libs in
/lib, which should
On Wed, Aug 16, 2000 at 02:05:58PM -0500, Bryan Andersen wrote:
When a user or administrator is using it it is because of unusual
conditions.
Why so? I use it in perfectly usual and common conditions.
--
Digital Electronic Being Intended for Assassination and Nullification
PM
Subject: Re: mkfs in /sbin, mkisofs in /usr/bin (was: Re: Intent To
Split: netbase
On Thu, 17 Aug 2000, Marcus Brinkmann wrote:
There is some inconsistency here.
ulysses:~# which mkisofs
/usr/bin/mkisofs
ulysses:~# which mke2fs
/sbin/mke2fs
tony mancill wrote:
I
On Wed, Aug 16, 2000 at 02:05:58PM -0500, Bryan Andersen wrote:
Traceroute is a diagnostic command. As such it isn't general use.
This distinction between sbin and bin is nowhere defined as having anything
to do with general use.
When a user or administrator is using it it is because of
On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote:
On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote:
Blindly following your fiat declarations about traceroute are getting us
into trouble now.
What trouble is that? I don't consider having to type
On Thu, Aug 17, 2000 at 09:34:51AM +1000, Herbert Xu wrote:
Hmm, I didn't know that traceroute sent ICMP packets by default. Are you
sure you are talking about /usr/sbin/traceroute?
Point taken. It had been a while since I read the manpage; it uses regular
IP packets and manipulates the TTL
Branden Robinson [EMAIL PROTECTED] wrote:
Anyway, from my personal experience,
ifconfig/route/ping/traceroute/snmpnetstat are often used together to
diagnose problems (or just waste time and bandwidth).
Tons of people use ping and traceroute without needing to invoke ifconfig,
route, or any
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote:
Branden Robinson [EMAIL PROTECTED] wrote:
Quoting the FHS:
Deciding what things go into sbin directories is simple: If a normal
(not a system administrator) user will ever run it directly, then it
should be placed in
On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote:
Any user who has a legitimate reason to run ifconfig is a system
administrator, and thus should have /sbin and /usr/sbin in his path.
Facilities like /etc/login.defs do discriminate to this fine degree.
They know two kinds of user,
On Thu, Aug 17, 2000 at 02:38:55AM -0500, Branden Robinson wrote:
On Thu, Aug 17, 2000 at 03:27:12AM -0400, Adam McKenna wrote:
Any user who has a legitimate reason to run ifconfig is a system
administrator, and thus should have /sbin and /usr/sbin in his path.
Facilities like
On Thu, 17 Aug 2000, Herbert Xu wrote:
snmpnetstat will show the routing table of routers that export it
through SNMP. My point is that route in this case is simply a
special case of snpmnetstat.
Most routers have a security arrangement so that the information is not
public.
Jason
On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote:
On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote:
What trouble is that? I don't consider having to type /sbin/traceroute
or add /sbin to my path trouble.
Obviously you haven't typed the actual path to
Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes:
Marcus We can put everything in /bin and make /sbin a link to /bin.
Marcus This way the utilities the FHS liste can be found in /sbin,
Marcus but there physical place is elsewhere. This does not violate
Marcus the standard.
I still
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 14.08.00 in [EMAIL PROTECTED]:
John == John Goerzen [EMAIL PROTECTED] writes:
No real reason? Only one package can listen in on port 25, and
John There is no real reason that all must listen on port 25.
Then you and I have very
[EMAIL PROTECTED] (Adrian Bridgett) wrote on 16.08.00 in [EMAIL PROTECTED]:
On Wed, Aug 16, 2000 at 12:31:47 -0500 (+), Branden Robinson wrote:
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote:
Well, the FHS is contradicting itself here. On one hand, it says that
ifconfig
[EMAIL PROTECTED] (Jacob Kuntz) wrote on 15.08.00 in [EMAIL PROTECTED]:
Clint Adams ([EMAIL PROTECTED]) wrote:
No real reason? Only one package can listen in on port 25, and
Only one package can listen on port 25 of one IP. It is possible to
have multiple packages listening on
Joey == Joey Hess [EMAIL PROTECTED] writes:
As to mount telling us what is mounted, so does df, and cat
/etc/mtab. again, not enough to move mount; unless one is being
contrary.
Joey I dont follow this. 'echo *' can tell me what files are in a directory;
Joey a system without ls in path
On Thu, Aug 17, 2000 at 10:42:57AM -0500, Steve Greenland wrote:
On 16-Aug-00, 23:43 (CDT), Branden Robinson [EMAIL PROTECTED] wrote:
On Wed, Aug 16, 2000 at 05:48:11PM -0500, Steve Greenland wrote:
What trouble is that? I don't consider having to type /sbin/traceroute
or add /sbin to
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden There is policy on this topic. We say we will comply with
Branden the FHS. (We should probably say we will be compatible
Branden instead, else our distribution is literally riddled with FHS
Branden violations.)
Should we
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden Well, keep in mind that Debian has committed itself to
Branden FHS-compatibility, not FHS-compliance. This means that we
Branden are free to have symlinks standing between a pathname and
Branden the inode.
We have? That's
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote:
d) they don't know about an alternative command which is already in
their path. [For example: netstat -er gives the same information
as route.]
Branden I don't
Anthony Towns wrote:
FHS discuss people: where should traceroute go? Tradition dictates
/usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate.
I think it should be in /usr/bin, certainly if it is setuid. So should ping,
and mount and umount. It is most annoying if you insert
Kai == Kai Henningsen [EMAIL PROTECTED] writes:
Kai AFAIK most MTAs can be convinced to use a different port. I
Kai wonder why that is?
You are missing the point. How often do these things have to
be done? How difficult is it to install two different MTA's as things
stand?
Kai I
Kai == Kai Henningsen [EMAIL PROTECTED] writes:
Kai Nothing, if the definition of user tools matches the FHS /bin - /sbin
Kai distinction, which says that if users ever run the thing, it belongs in
Kai /bin.
I think there is a modicum on common sense expetced to be
applied here.
On Thu, Aug 17, 2000 at 11:39:23AM -0500, Manoj Srivastava wrote:
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden Well, keep in mind that Debian has committed itself to
Branden FHS-compatibility, not FHS-compliance. This means that we
Branden are free to have symlinks
On Thu, Aug 17, 2000 at 11:35:31AM -0500, Manoj Srivastava wrote:
Should we not rather make an attempt to get rid of some of
those incompatibilities, rather than throwing our hands in disgust
and punting on it before we even start?
Have fun hacking apt.
--
G. Branden Robinson
On Thu, Aug 17, 2000 at 11:48:06AM -0500, Manoj Srivastava wrote:
(I am sure one can come up with some reason for moving every single
probgram out of sbin, and thus lose all the benefits of the split).
Could you remind me what these benefits are again? Pretend for a moment
that the FHS
On Tue, Aug 15, 2000 at 06:54:24AM -0700, Joey Hess wrote:
The question that seems to want to be raised is whether this
is true? Are people really confused more by having extra commands
available, or are they confused by _not_ havingcertain commands
present?
Sounds fine to me.
On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote:
The things that we do put in /sbin, for the same reasons, we
expect that the average user will not use them and might be confused
by encountering them. For example, mkfs and fsck and so forth are in
/sbin. Anyone
On Thu, 17 Aug 2000, Marcus Brinkmann wrote:
On Thu, Aug 17, 2000 at 11:26:17AM -0500, Manoj Srivastava wrote:
The things that we do put in /sbin, for the same reasons, we
expect that the average user will not use them and might be confused
by encountering them. For example, mkfs
On Thu, 17 Aug 2000, Marcus Brinkmann wrote:
There is some inconsistency here.
ulysses:~# which mkisofs
/usr/bin/mkisofs
ulysses:~# which mke2fs
/sbin/mke2fs
tony mancill wrote:
I disagree. You *NEED* to have a copy of mke2fs in the root filesystem
in case /usr or any other mounted
On Thu, Aug 17, 2000 at 04:15:17PM -0400, Peter S Galbraith wrote:
On Thu, 17 Aug 2000, Marcus Brinkmann wrote:
There is some inconsistency here.
ulysses:~# which mkisofs
/usr/bin/mkisofs
ulysses:~# which mke2fs
/sbin/mke2fs
tony mancill wrote:
I disagree. You *NEED* to have
Anthony == Anthony Towns aj@azure.humbug.org.au writes:
Anthony ifconfig is a required file for /sbin according the the FHS
Anthony section 3.10 as distributed in the debian-policy package.
I think that some people are espousing non-compliance with the
standards. Is that what we want
I proposed using symlinks for programs in */sbin to enable normal users
to see them in their default path, but now I think this is a bit messy.
(For instance, /sbin/ifconfig - /bin/ifconfig, lots of these would be ad hoc)
For simplicity's sake, I think it's just good enough to include /sbin,
On Tue, Aug 15, 2000 at 05:07:25PM -0400, Decklin Foster wrote:
Steve Bowman writes:
OK, how about moving everything into /bin except what FHS specifically
says should be in /sbin?
snip list from FHS 3.10
I very much like this idea. Does anyone have objections?
I don't object. I still
On Wed, Aug 16, 2000 at 07:32:32AM +1000, Herbert Xu wrote:
Branden Robinson [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
But I thought one of the main complaints was that /usr/sbin wasn't in the
PATH.
Generally, maintainer scripts, and
On Wed, Aug 16, 2000 at 12:39:15PM +1000, Anthony Towns wrote:
On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote:
I was confused by not having ifconfig in my user path. On this machine,
there's only a dial-up net connection, and it has some small connectivity
problems. I need to
[Followups to debian-policy, please]
On Tue, Aug 15, 2000 at 11:22:11PM -0500, Manoj Srivastava wrote:
I think that some people are espousing non-compliance with the
standards. Is that what we want to do?
The FHS exhaustively explains the difference between compatibility and
compliance.
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote:
For simplicity's sake, I think it's just good enough to include /sbin,
/usr/sbin and /usr/local/sbin in user's default path.
I think if someone has to do such a thing, then:
a) they forgot to su root; or
b) they don't know they
Branden Robinson [EMAIL PROTECTED] wrote:
Quoting the FHS:
Deciding what things go into sbin directories is simple: If a normal
(not a system administrator) user will ever run it directly, then it
should be placed in one of the bin directories. Ordinary users should
not have to
FHS discuss people: where should traceroute go? Tradition dictates
/usr/sbin, the FHS seems to indicate /usr/bin would be more appropriate.
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote:
Blindly following a contradictory standard is only going to get us into
trouble later on.
On 15-Aug-00, 17:12 (CDT), Eray Ozkural [EMAIL PROTECTED] wrote:
I was confused by not having ifconfig in my user path. On this
machine, there's only a dial-up net connection, and it has some small
connectivity problems. I need to check whether the line's really up. I
found myself going
On Wed, Aug 16, 2000 at 09:23:11AM +0300, Eray Ozkural wrote:
For simplicity's sake, I think it's just good enough to include /sbin,
/usr/sbin and /usr/local/sbin in user's default path.
On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote:
I think if someone has to do such a
On Tue, Aug 15, 2000 at 12:18:14PM -0700, Steve Bowman wrote:
OK, how about moving everything into /bin except what FHS specifically
says should be in /sbin? Section 3.10[0] identifies the following
specifically to be located in /sbin:
We can put everything in /bin and make /sbin a link to
On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote:
We can put everything in /bin and make /sbin a link to /bin.
This way the utilities the FHS liste can be found in /sbin, but there
physical place is elsewhere. This does not violate the standard.
This has nasty implications with
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote:
Well, the FHS is contradicting itself here. On one hand, it says that
ifconfig is required to be in /sbin, on the other, according to this
paragraph, since a user could ocassionally wish to run ifconfig to list
the interfaces, it has
On Wed, Aug 16, 2000 at 08:34:09PM +1000, Anthony Towns wrote:
This definition is really quite poor if you put too much emphasis on
the ever. swapon, for example, is clearly a tool for the admin,
but a user might decide one day to run it just see which version of the
program is installed on
On Wed, Aug 16, 2000 at 10:53:51AM -0400, Raul Miller wrote:
On Wed, Aug 16, 2000 at 02:42:37AM -0500, Branden Robinson wrote:
I think if someone has to do such a thing, then:
a) they forgot to su root; or
b) they don't know they need privleges to use the command in question; or
Marcus Brinkmann ([EMAIL PROTECTED]) wrote:
We can put everything in /bin and make /sbin a link to /bin.
This way the utilities the FHS liste can be found in /sbin, but there
physical place is elsewhere. This does not violate the standard.
(The Hurd has a symlink from /usr to /, this way
Perhaps not. But a traceroute in /usr/bin would satisfy more people than
a traceroute in /usr/sbin.
Traceroute is a diagnostic command. As such it isn't general use.
When a user or administrator is using it it is because of unusual
conditions. My opinion is to leave it in /usr/sbin. Let
On Wed, Aug 16, 2000 at 12:31:47 -0500 (+), Branden Robinson wrote:
On Wed, Aug 16, 2000 at 07:22:26PM +1000, Herbert Xu wrote:
Well, the FHS is contradicting itself here. On one hand, it says that
ifconfig is required to be in /sbin, on the other, according to this
paragraph, since a
On Wed, 16 Aug 2000, Anthony Towns wrote:
FHS discuss people: where should traceroute go? Tradition dictates
/usr/sbin, the FHS seems to indicate /usr/bin would be more
appropriate.
[analysis]
IMHO, the deciding factor should be whether traceroute is installed
setuid root.
If traceroute
On Wed, Aug 16, 2000 at 12:40:42PM -0500, Branden Robinson wrote:
In other words, I think the choice of directory should be controlled by
factors intrinsic, not extrinsic, to the program in question.
I think this is a reasonable viewpoint.
--
Raul
Branden Robinson wrote:
To be frank I'm not distressed by the thought of lots of programs moving
from sbin to bin, or even the elimination of sbin altogether.
Perhaps it would be neat to move back to what sbin was orginially used
for -- static binaries. Erik Andrerson has a whole slew of them
Manoj Srivastava wrote:
Hmm. Lets step back here, and take a deep breath. What we need
to consider is whether the underlying principle is desirable -- does
it make sense to have two separate path components? The rationale was
that for the common user, there are programs that are not
On 16-Aug-00, 12:31 (CDT), Branden Robinson [EMAIL PROTECTED] wrote:
Blindly following your fiat declarations about traceroute are getting us
into trouble now.
What trouble is that? I don't consider having to type /sbin/traceroute
or add /sbin to my path trouble.
The constitution clearly
Branden Robinson [EMAIL PROTECTED] wrote:
Incidentally, if one wants to argue by analogy, traceroute is more similar
to ping than it is to ifconfig or route, because both traceroute and ping
actually send ICMP packets out over the interface, and neither ifconfig nor
Hmm, I didn't know that
On Wed, Aug 16, 2000 at 01:18:39PM -0400, Raul Miller wrote:
On Wed, Aug 16, 2000 at 02:34:26PM +0200, Marcus Brinkmann wrote:
We can put everything in /bin and make /sbin a link to /bin.
This way the utilities the FHS liste can be found in /sbin, but there
physical place is elsewhere. This
Branden Robinson wrote:
Fine with me; either interpretation would get traceroute into (/usr)?/bin.
Same here, but ..
On the other hand, fsck seems to be a good example of a program that can't
do much for the unprivileged user.
advocate type=devil's
Anyone can own a block device.
/advocate
John Goerzen ([EMAIL PROTECTED]) wrote:
There is no real reason that all must listen on port 25.
while i can't imagine ever justifying having postfix AND exim installed on
the same machine, your argument holds true for other things. for instance,
it's not uncommon to see a machine that has
Clint Adams ([EMAIL PROTECTED]) wrote:
No real reason? Only one package can listen in on port 25, and
Only one package can listen on port 25 of one IP. It is possible to
have multiple packages listening on different ports or different IPs.
hadn't thought of that. but once again, is
On Tue, 15 Aug 2000, Jacob Kuntz wrote:
while i can't imagine ever justifying having postfix AND exim installed on
the same machine, your argument holds true for other things. for instance,
it's not uncommon to see a machine that has apache running on 80 for
I've done it - had to really..
Branden Robinson [EMAIL PROTECTED] wrote:
On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
Hear, hear! It would be a flag day for a few poorly written programs
out there, but a reorg is worth it.
Then they're VERY poorly written. The proper way (in posix sh) to invoke a
On Tue, Aug 15, 2000 at 02:54:01AM -0400, Jacob Kuntz wrote:
hadn't thought of that. but once again, is there any benefit to that at all?
will the efort required by the maintainers to get this working properly
(including reading bug reports) ever balance against the tiny number of
people
Jason == Jason Gunthorpe [EMAIL PROTECTED] writes:
Jason I've done it - had to really.. Two reasons
Jason1) Exim provides a different command line interface than say qmail,
Jason some software simply will not work. Thus we need a mail agent to
Jason move messages outbound
On Mon, Aug 14, 2000 at 09:54:40PM -0500, Branden Robinson wrote:
On the other hand, fsck seems to be a good example of a program that can't
do much for the unprivileged user.
That's not true. You can have disk image files you might want to check for
correctness.
In the Hurd, any user can boot
On 15 Aug 2000, Manoj Srivastava wrote:
Is it really your contention that all MTA's should provide for
this configurability, and cooperate with all other MTA packages out
of the box? I am afraid that all this handshaking is going to entail
a lot of effort, and the resultant gains
On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote:
hesitantly pointing out the bit about optimizing for the
overwhelmingly common case
There's a difference between *optimizing* for the common case, and
preventing the use of other cases without resorting to unofficial packages.
On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote:
On the other hand, fsck seems to be a good example of a program that can't
do much for the unprivileged user.
advocate type=devil's
Anyone can own a block device.
/advocate
To be frank I'm not distressed by the thought of lots of
On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
Branden Robinson [EMAIL PROTECTED] wrote:
On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
Hear, hear! It would be a flag day for a few poorly written programs
out there, but a reorg is worth it.
Then they're
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote:
hesitantly pointing out the bit about optimizing for the
overwhelmingly common case
Branden There's a difference between *optimizing* for the common
Branden
Hi,
If all we are interested in hacving a miny contentous debate,
please skip this message, because this pre-supposes a desire to
actually compromise and come to a rough consensus. Unfortunately,
common sense and a desire to actually co-operate seem to have been
sorely lacking of
On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote:
Branden Robinson wrote:
Fine with me; either interpretation would get traceroute into (/usr)?/bin.
Same here, but ..
On the other hand, fsck seems to be a good example of a program that can't
do much for the unprivileged user.
Why is it considered difficult for individual users adding /sbin and
/usr/sbin to their path if they wish to?
I'm sure that most users are competent enough to change their own path,
and if they are not, they will be soon after they find that they need to.
As a user with no formal computer
Steve Bowman writes:
OK, how about moving everything into /bin except what FHS specifically
says should be in /sbin?
snip list from FHS 3.10
I very much like this idea. Does anyone have objections?
--
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE
On 15-Aug-00, 14:35 (CDT), paul [EMAIL PROTECTED] wrote:
Why is it considered difficult for individual users adding /sbin and
/usr/sbin to their path if they wish to?
Because stating that it is difficult is seen as an valid argument by
those who wish sbin would go away. The fact that it is
Branden Robinson [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
But I thought one of the main complaints was that /usr/sbin wasn't in the
PATH.
Generally, maintainer scripts, and programs meant to be run by root, run as
root.
If a program expects to
Herbert Xu writes:
Branden Robinson [EMAIL PROTECTED] wrote:
Generally, maintainer scripts, and programs meant to be run by
root, run as root.
If a program expects to use some tool that only root would use, it
should expect to be running as root.
So you do agree with me that it is
On Tue, 15 Aug 2000 21:43:31 Manoj Srivastava wrote:
The question that seems to want to be raised is whether this
is true? Are people really confused more by having extra commands
available, or are they confused by _not_ havingcertain commands
present?
I was confused by not having
On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote:
I was confused by not having ifconfig in my user path. On this machine,
there's only a dial-up net connection, and it has some small connectivity
problems. I need to check whether the line's really up. I found
myself going
Andreas Fuchs [EMAIL PROTECTED] writes:
Good enough for you? Good enough for anyone? ajt? (-:
Bad idea.
Then you also want every X11-app to ask if it should install itself in
/usr/X386/bin or somewhere else and every game-like app if it should
instaal it self in /usr/bin or /usr/games?
Herbert Xu [EMAIL PROTECTED] writes:
Please also note that other daemons conflict with each other well, e.g.,
inn cnews, sendmail postfix.
I am aware of that, and it's a shame, there is no real reason that
they cannot coexist.
Andreas Fuchs writes:
Hm. So why not make it the admin's choice? How about'
snip
Setting up netbase (version) ...
In the standard configuration, some binaries of netbase are installed
in /usr/sbin, which is, by default, not included in the user's search
paths. Do you want to create a
Hi,
John == John Goerzen [EMAIL PROTECTED] writes:
John Herbert Xu [EMAIL PROTECTED] writes:
Please also note that other daemons conflict with each other well, e.g.,
inn cnews, sendmail postfix.
John I am aware of that, and it's a shame, there is no real reason that
John they cannot
On Monday, 14 August 2000 at 14:20, Manoj Srivastava wrote:
Hi,
John == John Goerzen [EMAIL PROTECTED] writes:
John Herbert Xu [EMAIL PROTECTED] writes:
Please also note that other daemons conflict with each other well, e.g.,
inn cnews, sendmail postfix.
John I am aware of
Manoj Srivastava [EMAIL PROTECTED] writes:
John Herbert Xu [EMAIL PROTECTED] writes:
Please also note that other daemons conflict with each other well, e.g.,
inn cnews, sendmail postfix.
John I am aware of that, and it's a shame, there is no real reason that
John they cannot
On Thu, Aug 10, 2000 at 03:22:43PM +1000, Anthony Towns wrote:
On Thu, Aug 10, 2000 at 12:47:34AM -0400, Decklin Foster wrote:
Anthony Towns writes:
Well, if you wanted half the people running unstable to just
blithely upgrade and have all their firewalling disappear, you could
remove
No real reason? Only one package can listen in on port 25, and
Only one package can listen on port 25 of one IP. It is possible to
have multiple packages listening on different ports or different IPs.
John == John Goerzen [EMAIL PROTECTED] writes:
No real reason? Only one package can listen in on port 25, and
John There is no real reason that all must listen on port 25.
Then you and I have very different opinions on what a working
MTA is. Indeed, the SMTP RFC's differ with your
On Mon, Aug 14, 2000 at 10:27:22AM -0500, Manoj Srivastava wrote:
Branden == Branden Robinson [EMAIL PROTECTED] writes:
Branden Of course. The obvious answer is that programs that have
Branden some utility to unprivileged users should go in /bin (or
Branden /usr/bin).
The
On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
On Mon, Aug 14, 2000 at 09:22:27AM -0400, Michael Stone wrote:
Perhaps not. But a traceroute in /usr/bin would satisfy more people than
a traceroute in /usr/sbin.
Hear, hear! It would be a flag day for a few poorly written
Branden Of course. The obvious answer is that programs that have
Branden some utility to unprivileged users should go in /bin (or
Branden /usr/bin).
The problem with that is that it is all so very subjective,
and it all depends on the ``unprivileged user''. Under this tacit
Then you also want every X11-app to ask if it should install itself in
/usr/X386/bin or somewhere else and every game-like app if it should
instaal it self in /usr/bin or /usr/games?
Worse: There's a package which asks the sysadmin where is dpkg in the
sustem..!
99 matches
Mail list logo
