inetd

[John]

>>Note that if xinetd were the standard super daemon, packages would
>>a) depend on it
>>    
>>
>
>They do already, as xinetd provides .
>
>  
>
>>b) Plonk their config file into /etc/xinetd.d
>>    
>>
>
>Could be handled through a script that works with inetd/etc as well, so one 
>script is used to drive all *netd implementations.
>
>  
>
>>c) Not need scripts to run update-inetd or equivalent.
>>    
>>
>
>But then you're tied to one program, which is really what the problem with 
>*netd is currently.
>
>  
>
>>Seems to me a much nicer way to go for packagers, maintainers, sysadmins
>>and those who want to hack on the superserver's  configuration.
>>    
>>
>
>Actually, tying someone down to the ONE program isn't really that nice at all. 
>It's called lock-in. It's like telling every vi user that they must only use 
>emacs from now on.
>
>  
>

Anyone/anything that hacks on /etc/inetd.conf has the potential to break
if for everything. Each having its own config in /etc/xinetd.d means
that one that's broken breaks nothing else.

That's largely why nicer.

atm we're locked into the older one. How is that better?

The  update-inetd script should be part of the particular superserver.
It can do what it needs for _that_ userpserver, including nothing if
that's appropriate.

I think the file-per-app is a nicer starting-point for an update program
than the one-for-all approach of inetd. Creating a one-for-all config
file if needed shouldn't be too hard.

If you don't want to use _any_ existing ss's config file, invent an XML
format:-)