[inferiorhuman]

> They are not.

https://stackoverflow.com/questions/32924335/using-systemd-w...

> The journal is the only mandatory component of systemd outside PID1.

Seems pretty deeply embedded to me.

> what does that even mean? that they are older?

They are older, better understood, and there are fewer substantive bugs (e.g. malformed blob = run service as root).

> You seem to repeat what other people say like the "QR code" without even looking it up.

https://lists.fedoraproject.org/pipermail/devel/2012-October...

Not sure what else you're doing with a QR library, except maybe building tetris (which seems like a bad idea for something purported to be an init system).

[gsich]

>They are older, better understood, and there are fewer substantive bugs (e.g. malformed blob = run service as root).

You used the same argument ("They are more mature") again. It's still not saying anything.

[inferiorhuman]

> It's still not saying anything.

Sure it is. An init system should, first and foremost, be stable and well understood. By virtue of its size and youth, systemd is not (at least not by devs and end users).

[gsich]

But all those words are meaningless. "stable" and "well understood" could also be said of systemd. There is no metric to it. By that logic we could go back to using software from before 20 years, because they are "stable".

I have noticed that systemd is "stable" and "well understood" because I have no problems with it. But would that convince someone else?

[inferiorhuman]

> But all those words are meaningless. "stable" and "well understood" could also be said of systemd.

Bugs like this:

https://www.theregister.co.uk/2017/07/05/linux_systemd_grant...

https://github.com/systemd/systemd/issues/6077

https://github.com/systemd/systemd/issues/9449

https://github.com/systemd/systemd/issues/9079

Indicate that systemd interactions aren't particularly well thought out.

https://github.com/systemd/systemd/issues/8730

Non-deterministic behavior is exactly what I'd strive to avoid in an init system.

Stuff like this:

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...

Indicates both poor understanding of how an init system should work (including basics like privilege separation) and poor stability.

Stuff like this:

https://threatpost.com/linux-systemd-bug-could-have-led-to-c...

Well, I for one do not want my init system to be network accessible.

[mdekkers]

To be honest, @inferiorhuman keeps providing you with well supported reasoning for his position, whilst your only contribution appears to be "that doesn't meet my personal standards", which is devoid of any meaningful content for the rest of us. I am a committed systemd argument aficionado, and would really like to see a more supported set of arguments from your side. So far, @inferiorhuman is winning this debate.

[gsich]

It's typical in a systemd discussion that a link dump to broken stuff appears. Weather or not these are indeed broken - that is not explained. FWIW at least there are bug reports. The conclusion that because of those reports sysvinit is better, is false. It could just be that nobody cares about sysvinit anymore, so fewer bug reports happen.

[mdekkers]

It's typical in a systemd discussion that a link dump to broken stuff appears

Please help me understand this line of reasoning. Someone has a list of reasons as to why they believe systemd is not a good fit for them, and something else works better. They get told "prove it isn't a good fit for you". They prove this with some line of argumentation. They get told "that is your opinion only, and that doesn't count". They provide links to show many other users have the same issues, and they feel these issues have not been given due consideration. They get told "typical systemd haters, they always provide a link dump with broken stuff, it doesn't mean anything"

This has pretty much become the default template for the systemd pro/con arguments, and is unwinnable. FWIW, my problem with systemd is that it broke the concept of free choice in my environment. It was harshly shoved down everyone's throat, through politics rather then the usual meritocratic methods. I appreciate that this was a commercially advantageous position for the various distro maintainers, which lead me to cancel all my (thousands) of distro support agreements.

It is the political approach that was taken that gives rise to serious suspicions for me. If the system cannot stand on its' own feet from the meritocratic perspective, and needs to resort to all kinds of political games to gain a substantive foothold, my default position is not one of trust.

The "la la la i-can't-hear-you" systemd fanboy troupe response whenever someone attempts to make a well-supported argument against systemd only fuels my distrust of the whole systemd story.

As I mentioned, I vote with my feet and wallet. I use Alpine wherever possible.

[inferiorhuman]

> It could just be that nobody cares about sysvinit anymore, so fewer bug reports happen.

Waving your hands and suggesting everything is going to have bugs isn't much of an argument. It's unlikely that sysvinit would suffer from any of these bugs as there's simply a much smaller vector of attack than systemd by design. You could knock me over with a feather if arbitrary network traffic could compromise your system via sysvinit. The other class of bugs are ones where sysvinit is the defined behavior and systemd is simply deviating in unexpected, unintuitive, and undocumented ways.