Nikolaus Rath <nikol...@rath.org> writes: > On Aug 28 2016, Bart Schouten <l...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
