Why people hate :#systemd on IRC

So yeah, I’ve been forced into using SystemD for just about everything now that the entire community has taken the koolaid.

I recently had a question where if a ConditionFileIsExecutable fails in the [Unit] section, the logs say that the service was started - but in fact the service won’t attempt to be started. No errors, no warnings, but a message of success. This seemed strange, so I jumped onto #systemd on Freenode and ended up with the following conversation:

17:37 -!- Irssi: Join to #systemd was synced in 5 secs
17:38 <CRCinAU> ok - so if the start of a service fails because ConditionFileIsExecutable fails, is it expected to be a silent failure?
17:38 <CRCinAU> ie nothing in the journal or logged to state why a service failed? just a "Started" then nothing further?
17:39 <grawity> CRCinAU: yeah, it's supposed to be mostly silent
17:39 <grawity> unlike AssertFileIsExecutable=, by the way
17:39 <CRCinAU> logic behind that?
17:39 <grawity> its primary purpose is in filtering units which should or shouldn't auto-start
17:40 <grawity> logging failures at default level would result in too much logspam on most systems
17:40 <CRCinAU> o_O
17:40 <grawity> e.g. there's ssh-keygen.service with Condition= that at least one ssh_host_key is missing
17:41 <grawity> if you want things to be logged loudly, use Assert=
17:41 <CRCinAU> I don't see a problem with that?
17:41 <grawity> with what
17:41 <CRCinAU> a message that a file doesn't exist.....
17:41 <grawity> with users seeing "warning: ssh-keygen not started because EVERYTHING IS FINE" on every reboot?
17:42 <grawity> some programs install units with ConditionVirtualization=, which would either log warnings on every VM, or on every bare metal system
17:42 <grawity> if you want things to be logged loudly, use Assert=
17:42 <CRCinAU> wait........
17:42 <CRCinAU> what the hell is systemd doing thinking about virtualisation?
17:43 <grawity> there are daemons which are only needed in VMs, or aren't needed in VMs
17:43 <CRCinAU> urrrmmmm.......
17:43 <grawity> e.g. systemd's own udev has no business running in a container
17:43 <CRCinAU> holy crap... so what you're telling me is systemd is still hungry and needs to be fed more?
17:44 <michich> another example: vmtoolsd.service:ConditionVirtualization=vmware
17:44 <CRCinAU> I think I just died a little inside in that level of retardation.
17:45 <grawity> so by your own logic, a few minutes ago you were telling me systemd should be checking for your config files, instead of your own daemons doing that themselves?
17:46 <CRCinAU> no - the unit failed to start, and had no warning. if there was a problem and the unit failed, I'd expect to see something that says "blah.service failed because ConditionFileIsExecutable failed" or similar.
17:46 <CRCinAU> not just "Unit blah.service started"
17:46 <CRCinAU> when it fact it wasn't
17:46 <CRCinAU> it *attempted* to start
17:46 <CRCinAU> but failed.
17:49 <CRCinAU> on another note, now I'm hearing that systemd is becoming virtualisation aware because users are too stupid to do "systemctl enable vmtoolsd.service" when they do a virtualised install?
17:49 -!- mode/#systemd [+b $a:CRCinAU] by evilgrawity
17:49 <CRCinAU> well, not even that... as I guess you'd have to install the VMWare tools in that situation to even have the service file in the first place - so it could even be part of the package install.
17:50 -!- #systemd Cannot send to channel
17:50 -!- CRCinAU was kicked from #systemd by evilgrawity [CRCinAU]

I’m kinda speechless now.