> if you knew the standard unix-ey tools you could get by
And if you know the standard systemd tools, you can get by with systemd. It's far from enigmatic, the docs are freely available. Yes, systemd does things differently from what you might be used to, but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.
> how do I see what services are available under systemd?
systemctl list-units --type=service
> How can I reliable see what file systems are supposed to be mounted at boot?
You can still use /etc/fstab, systemd will parse it at boot time. For mount units, you can use:
systemctl list-unit-files --type=mount
> The answer to both of those tends to be "systemd spreads it's files and configuration all around the filesystem to you need to learn some bespoke systemd command that you'll only ever use for systemd"
/etc/systemd or /usr/lib/systemd for global stuff
$HOME/.config/systemd for per-user stuff
> but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.
I responded to that in another post, but basically unix is a programming environment and when you start composing tools together you get a powerful solution for quickly throwing things together.
And if you know the standard systemd tools, you can get by with systemd. It's far from enigmatic, the docs are freely available. Yes, systemd does things differently from what you might be used to, but I don't see how that's an issue beyond having to surf the usual learning curve of a new tool.
> how do I see what services are available under systemd?
> How can I reliable see what file systems are supposed to be mounted at boot?You can still use /etc/fstab, systemd will parse it at boot time. For mount units, you can use:
> The answer to both of those tends to be "systemd spreads it's files and configuration all around the filesystem to you need to learn some bespoke systemd command that you'll only ever use for systemd" That's pretty much it for unit files.