QR code generator is not a common feature of an init system, yet systemd includes one. Modern attempt at OS packaging (a.k.a. containerization) is not a weird thing in such a neighbourhood at all.
The separate journald log server available as part of the systemd project can generate qrcodes. journald can cryptographically sign logs so that future log tampering can be detected. This requires two keys, a sealing key and a verification key. The verification key must be stored off server. When the keys are generated systemd can display a qrcode to allow easy recording of the verification key.
Having a QR code parser as part of something that's tangentially related to the init system in concept but deeply embedded into systemd in practice is exactly what the post you were replying to is complainig about. It's unnecessarily complex.
>They are more mature
what does that even mean? that they are older? Similar to "modern XYZ" this phrase doesn't mean anything.
You seem to repeat what other people say like the "QR code" without even looking it up.
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).
You used the same argument ("They are more mature") again. 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).
I have noticed that systemd is "stable" and "well understood" because I have no problems with it. But would that convince someone else?
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.
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.
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.
Put another way, as a couple of anecdotes at $day_job, the boot time benefits (the one thing people always seem to bring up in defense of this ever-growing behemoth) were eaten up months ago in time troubleshooting, transitioning, and working around its corner cases.
More humorously, the words "fucking" and "goddamn" used to be followed by the name of some internal program known for being clunky. After getting up to Ubuntu 16 and Cent 7 in the whole environment, those words tend to be followed by "systemd".
Same for timers. Debugging not running cronjobs is a pain in comparison.
Writing sysv init scripts is so fucking shit, people started to dump everything in /etc/rc.local, especially for earlier RPi versions of Debian.
Do you know about Kafka, Spark, and Jenkins? They're all Java but they each have their batshit fucking insane quirks on starting up.
One of them runs in foreground. One of them runs in background.
Jenkins (actually as Hudson) had it's own fucking Unix daemon-isation inbuilt. For a Java program!
Nuts!
Thankfully pretty much popular Java server has a systemd unit file written for it which avoids any shell and Exec's Java directly.
For me it’s basically magic that I can now write a simple declarative file that describes how to run an application, and from there it works with all of the expected features.
I don't know if systemd is better (I've never managed a server fleet with it), but Upstart certainly wasn't good enough.
I hated systemd before it was cool to hate systemd. I never had a problem with sysvinit as the root casuse, but I had many problems with systemd as the root cause.
the real choice was between upstart and systemd, and upstart was clearly superior, especially for common use cases.