I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity.
And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further than the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/m....
If you need extra customization capabilities, just run a shell script via the ExecStart= parameter and boom, you have all the power of systemd and the shell combined.
Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
> AFAIK it's not easy to replace various parts of systemd, it's very monolithic and it does too many things.
You can easily replace timesyncd with any NTP daemon. You can easily replace networkd with any other networking manager. You can easily replace timer units with cron. You can easily forward log messages to a syslog daemon. You can easily replace systemd-boot with grub or any other boot manager.
It should be pretty obvious how baseless the monolithic arguments against systemd are.
> I like the init part, i could do without everything else.
Then, do exactly that? None of the components you're complaining about are mandatory (except for journald, but you can easily forward log messages to a regular syslog daemon).
> The viewer journalctl is probably the worst log viewing app that exists
Completely disagree there. I've had quite a pleasant experience with journalctl. It has sane arguments and you can easily grep any relevant log messages from the journal. You can add custom fields to your log messages. You can even get the logs in JSON format to parse log message from any scripts. And you can even use the cursor feature of journalctl to keep reading the logs at regular intervals without having to keep a constantly running process and tail the logs.
I can understand people not liking systemd-journald on account of the binary logs, but I definitely don't understand calling journalctl the worst log viewing app.
Stop spreading FUD. ".zfs/snapshot" has been working on Linux for years now. I don't know when you last used ZFS on Linux, but just because you haven't used ZoL for a while doesn't mean that the developers stopeed working on it.
Also, me and hundreds of other people have been booting off of ZFS on Linux for years. Your issue is most likely in your distro's initramfs setup or you must have botched the initramfs config yourself. If you're just used to FreeBSD, just stick to commenting about FreeBSD without maligning other operating systems.