is it the future?

[Anders Wegge Keller]

On Fri, 12 Sep 2014 10:27:18 -0600
Kevin Fenzi <kevin at scrye.com> wrote:

> On Fri, 12 Sep 2014 10:06:59 +0200
> Anders Wegge Keller <wegge at wegge.dk> wrote:
> 
> > On Thu, 11 Sep 2014 17:37:13 -0600
> > Kevin Fenzi <kevin at scrye.com> wrote:
> > 
> > > Well, sorry you think so. I think systemd is far from perfect, but
> > > it's a good deal better than what we had before. 
> > 
> >  Do you know of a place where I can find the analysis behind this
> > assessment, or is it just your personal opinion? 
> 
> I was stating my opinion. Based on almost 10 years working on Fedora,
> 25 or so years working on computers. 

 Funny how two different career paths can bring us to two radically
different stances. May I ask what field you work in? My own background is
upper level machine controls where we generally end up requiring as stupid a
box as possible. 

> > For me, the limited
> > gains, are far exceeded by the additional risk and complexities that
> > comes as part of the bundle. I'd really like to see your analysis as
> > to why systemd is better for your use case. Then I'll tell you in
> > detail why it doesn't at all improve my situation.
> 
> I already posted something like this in the last long, mostly useless
> systemd thread in here. :) 
> 
> From that email: 
> 
> "A few that I really appreciate: 
> 
> If you did a 'service stop foobar' it would try and stop foobar, but if
> the pid file was stale, foobar started other stuff that wasn't tied to
> foobar as a parent, or any other of a number of situations I have run
> into, parts of foobar would still be running. With systemd, if you stop
> a unit, it's really stopped. All of it. 

 I've yet to see this as a real life issue. 
 
> If you started a sysvinit service foobar and wanted to look at it's
> output, you had to hope the needed info was also in a log file or kill
> the service and restart it in some non standard mode to watch it's
> output. With systemd/journald, ALL output is saved and easy to query. 

 At the cost of extra memory usage and/or disk I/O. Do you run into that
kind of problems often enough, that it warrant that? It's not gain for
me.

> If for some reason you had to modify a complex sysvinit script, you
> then would have to merge in all changes with package updates over time.
> With systemd you can use a .d directory to add/change things without
> overwriting the provided systemd unit file."

 Overrides are IMHO not an improvement. Having everything in one script
makes it easy to see what is trying to start. The sh scripting language is
expressive enough, that you can do all kinds of emergency hacks there, and
get the system running again, when the customer host system drops NFS, or
what else is the matter. Messing around with several layers of indirection
is not something that improves maintainability.

> I'll add in no particular order: 
> 
> * unit files are vastly simple to write. I created some unit files for
>   some irc bots I run in about 5minutes. This would have taken copy and
>   pasting bunches of stuff to make a sysvinit script that wouldn't have
>   worked as well. 

 Do you write init scripts often enough that it's an issue? See Randall
Monroes wonderful chart at http://xkcd.com/1205/

> * Setting some buggy service to restart on failure is trivial to do. 

 Again, I've never run into a service that could be allowed to fail. Either
it's critical, and must run, or it's been disabled. 

> * Log querying with journalctl is great. I can easily look at the
>   messages from the previous boot (no matter when it was) or the one
>   before that. I can look at just output from one service, etc etc. 

 At the cost of a ridiculously complicated binary format. I'm not aware that
the WoNTFIX issue with journal corruption still stands, but just giving that
answer in the first place... What's the worth of a whizbang feature, that's
unreliable?

> Anyhow, I could go on, but I think at least some of the folks on this
> list (Not sure if you are one of them) have made up their minds, and
> nothing I can say will convince them otherwise. In that case, we should
> probibly just agree to disagree and move on. 

 I would like to be convinced. But I'm not swayed by fluffy claims, that
haven't been thought through. There are a lot of theoretical nice to haves,
that are useful once in a decade, at least for me. But they come at such a
great price, in complexity and risk, that they are not worth it. 

> If not, I am happy to help folks track down and report bugs with
> systemd, or if you have questions on how to do something in particular
> or if there's some case that could be improved. 

 I hope it's just the most extreme cases of developer arrogance I've seen,
when people are referring to Lennart Pöttingers attitude. But what I've seen
does not make me want to report anything, anywhere. 

>>  As the only alternative is Slackware, one might as well stick
>> around. Since I'm stuck with RHEL at work, I relly haven't got much
>> choice in desktop distro.
 
> Fair enough, do as you like indeed. However, I don't see that it helps
> anyone to have a "systemd is horrible" thread every month that consists
> of bunches of people saying how much they hate it without any positive
> outcome. ;) 

 Insanity is doing the same thing over and over, expecting the result to be
different :) And in the meantime, we all get a bit of katarsis.

 But seriuously, IF someone can convince me that there has been an actual
analysis behind the descision, based on something else than gut feelings and
NIH, I'd very much like to see that. That might convince me the switch is
sane, even though it's a net loss in maintainability in my situation.


-- 
//Wegge