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

Re: systemd and server use



 Hi.

On Sun, 28 Sep 2014 12:15:43 +0200
Martin Steigerwald <Martin@lichtvoll.de> wrote:

> > 2 - daemontools, runit, many others.
> 
> Then go and support these. Test them and help them to be available and tested 
> in Debian. Help them so have sane defaults and so.

But I don't have to :) Both daemontools and runit have their
maintainers already. If those kind souls step down from their duty - I
may consider that.

 
> If you don´t like systemd as a default in Debian that are at least some other 
> options for acting on it.

I'm indifferent to s*stemd. What I care about is choice, and Debian
provided me one so far. And, with the little help of 'equivs' and
'dpkg-buildpackage' - does so in the current stable and testing.


> > 3 - usability of 'systemctl status' feature is actually questionable, if
> > you count in troubleshooting-over-phone usecase. In that case less is
> > better than more.
> 
> Oh, in that case I certainly prefer a this and this and this and prefer to 
> listen for the phone partner to read it all out… instead of "oh it failed, but 
> it doesn´t tell why".

No offense, but have you done support-over-phone before? Waiting for
the customer to find and read a single 'sentence' (i.e. relatively
short command output) is painful enough, even if they manage to do it
correctly on the first try. Forcing them to read a 'paragraph' (typical
output of 'systemctl status' is an excellent example of such) can be
considered a 'cruel and unusual punishment' in some countries.

If you can view it by yourself - sure, more is better.
If you depend on others to view it - less is better.

And, please note, that original statement was 'Compare systemctl
service status with /etc/init.d/service status. Its obvious that the
systemctl output is way more useful to administrators'. I merely
provided an example of the contrary.

Reco


Reply to: