For me the problem with SystemD is that it seems to be trying to make Linux run like Windows.
If you are running in a generic "This is my machine and I just did the normal install for a regular use case then everything works" it seems great. But the instant you try to do something a little out of the ordinary it becomes a absolute nightmare of opaque message passing interfaces and hours on Google.
A few examples:
1. In the old days you could network boot a machine with a kernel compiled with a couple of flags turned on and an NFS share. SystemD systems can be network booted, but you're going to spend a lot of time poring over obscure forums finding all of the tweaks you need to make, and it will be a lot slower and toss up error messages for things like UUIDs changing on different systems.
2. If you want to have the wireless card change MAC addresses before it connects for slightly improved anonymity at public hotspots, you had better be willing to upgrade to the bleeding edge. NetworkManager broke the existing solutions for doing this and implemented it's own model, but it required a version of wpa_supplicant that was never really released so you had to build it yourself from a snapshot and install it and tell your distro not to update it. The SystemD devs got tired of waiting for the wpa_supplicant devs to release the new version so they moved the functionality into their code. At the same time they pulled in the DNS resolver but broke it so it crashes on literally every other name lookup.
3. NetworkManager pulled in OpenVPN support as an option. It's awesome when it works, but when it dies it refuses to give you any sort of clue as to why the connection didn't work. You just get a generic "it failed" message like in Windows. Not "Authentication Failed", "Cannot connect to Server", or "Clocks unsynchronized", not even a cryptic error code. Every single error results in just a generic message and you have to either hope the logs have something useful or more often you have to fire up Wireshark and inspect the authentication exchange by hand to figure out what is up.
Lord help you if you find yourself with a machine that hangs at boot because some process didn't receive some message it was expecting and now you have to figure out who was supposed to send that message and why they didn't send it. This isn't the old days where you could trace shell scripts to figure out where the problem was, now you have to know the whole thing before you can fix anything.
And don't get me started about moving the syslog into some binary database thing that you can't grep without going through some export process.
If you are running in a generic "This is my machine and I just did the normal install for a regular use case then everything works" it seems great. But the instant you try to do something a little out of the ordinary it becomes a absolute nightmare of opaque message passing interfaces and hours on Google.
A few examples: 1. In the old days you could network boot a machine with a kernel compiled with a couple of flags turned on and an NFS share. SystemD systems can be network booted, but you're going to spend a lot of time poring over obscure forums finding all of the tweaks you need to make, and it will be a lot slower and toss up error messages for things like UUIDs changing on different systems.
2. If you want to have the wireless card change MAC addresses before it connects for slightly improved anonymity at public hotspots, you had better be willing to upgrade to the bleeding edge. NetworkManager broke the existing solutions for doing this and implemented it's own model, but it required a version of wpa_supplicant that was never really released so you had to build it yourself from a snapshot and install it and tell your distro not to update it. The SystemD devs got tired of waiting for the wpa_supplicant devs to release the new version so they moved the functionality into their code. At the same time they pulled in the DNS resolver but broke it so it crashes on literally every other name lookup.
3. NetworkManager pulled in OpenVPN support as an option. It's awesome when it works, but when it dies it refuses to give you any sort of clue as to why the connection didn't work. You just get a generic "it failed" message like in Windows. Not "Authentication Failed", "Cannot connect to Server", or "Clocks unsynchronized", not even a cryptic error code. Every single error results in just a generic message and you have to either hope the logs have something useful or more often you have to fire up Wireshark and inspect the authentication exchange by hand to figure out what is up.
Lord help you if you find yourself with a machine that hangs at boot because some process didn't receive some message it was expecting and now you have to figure out who was supposed to send that message and why they didn't send it. This isn't the old days where you could trace shell scripts to figure out where the problem was, now you have to know the whole thing before you can fix anything.
And don't get me started about moving the syslog into some binary database thing that you can't grep without going through some export process.