Re: proposal: inetd improvements.

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> I can't help but think that this talkd fat finger example is quite
>>> an edge case but the ``solution'' is quite a problem.  If you
>>> exceed the connexions per minute, inetd will _stop_ the service for
>>> ten minutes.

> This kind of behaviour is basically never desirable.

I'm not convinced.  I run a number of machines where that is pretty
much exactly what I want: in the presence of that kind of respawning
behaviour, whether from a fat-fingered command line or from some other
cause, taking the service down until a human has looked at it is
*exactly* what I want.

You appear to be coming from a mindset wherein availability is
everything: where an overloaded service is better than none at all, for
example.  It's fine to accommodate such environments, but please don't
impose their idiosyncracies on the rest of us.

>> If you're going to complain about others imposing their
>> environments' appropriate solutions on you, it would behoove you to
>> avoid doing the same in the other direction.
> I am not complaining about others imposing their environments'
> appropriate solutions on me.

That's what it sounds like to me.

> I am pointing out that this particular behaviour doesn't make sense
> in any environment

That is...well, false.  It is exactly what I want, for example, for
most services on most of my machines: if something goes wrong (and the
syndrome in question here certainly counts) I want the service taken
down until a human can look at it.  I would rather have an otherwise
functional system with that service missing than a system trying to
limp along overloaded, or with its log partition blown out by the
resulting error messages, or any of the various other consequences of
not taking down the failing service.  Even if it's a deliberate DoS on
the service, for most services, I'd rather take the service down
pending human intervention.

These tradeoffs do not apply everywhere; I certainly do think it would
be good to avoid imposing them everywhere the way inetd currently does.
But I think it equally bad to do the converse: to impose some other
environment's tradeoffs here.

> but might be considered to be acceptable in a hobbyist/university
> setting.  This does not mean that it is desirable either, it just
> means that [its] failure cases are not as critical in those settings.

No, it doesn't mean that it's desirable.  But you appear to be making a
leap of illogic from that to meaning it's undesirable.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B