Re: Is missing SysV-init support a bug?
Nikolaus Rath <Nikolaus@rath.org> writes:
> On Aug 28 2016, Bart Schouten <list@xenhideout.nl> wrote:
>> But that's not the relevance. The idea that systemd is clearly superior
>> to sysvinit is just something you concoct up because you don't know how
>> to write a service file or script and you want to let systemd do the
>> hard work.
> How is that concoted? Yes, systemd is clearly superior to sysvinit
> because it doesn't require me to know how to write a service file or
> script but does the hard work for me.
Python is clearly superior to C in that I don't have to do tedious memory
management or worry about buffer overflows in allocated arrays. Yet, I
often prefer to implement things in C for a bunch of different reasons. A
couple of major ones are wanting more fine control and wanting a
standalone binary that doesn't depend on an installed Python ecosystem.
I disagree with both of you in that these aren't really "clearly superior"
sorts of things, I think. It feels like the wrong question entirely.
Personally, I think the systemd unit file syntax is a significant feature,
since I'm very tired of tedious, buggy shell boilerplate. Many people
have the same feeling about languages with automatic memory management and
garbage collection, or about exceptions versus return status codes. But
these aren't unambiguous design decisions. There are tradeoffs, and where
there are tradeoffs, there will be things one system or another isn't as
well-suited for.
Part of what systemd does explicitly is try to constrain the design space
by choosing not to support certain things in an attempt to make the
overall system much simpler. This is a very common approach with
programming languages as well; in a way, you could argue that every
programming language that isn't assembly limits the freedom of the
programmer in order to make the system simpler and more consistent. My
day job is in security, which gives one a real appreciation of the merits
of making dangerous things impossible to do and limiting the possibility
surface. But it's always a very controversial thing to do, since there
are always reasons for doing the thing that's normally quite dangerous, or
tedious, to do.
This is one of those arguments that you're never going to resolve either
way, since it's not a question of objective merit. It's a question of two
competing design principles that are inherently in tension. You can find
various different compromises between them that will be better at one
thing and worse at another thing, but you're never going to resolve the
conflict and be able to say that one approach is clearly better than the
other in all respects.
Debian historically tries to handle these situations by just providing
everything simultaneously. The debate over init systems is as heated as
it is because it's quite difficult to do a good job at supporting multiple
init systems.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: