For me personally, I'd say "not much". I'm used to using the latter form, and it's fine. But I will say that now that I know about this, I see using it in scenarios where I'm running a lot of systemctl commands over and over again in close proximity and have the "muscle memory" of typing "systemctl" more in mind.
For example, when working with a new service that isn't quite working right yet, and doing many iterations of:
Especially if I'm testing on my laptop AND a remote deployment, I think it's easier from a cognitive viewpoint to always "think systemctl" instead of having to "think systemctl" sometimes and "think ssh systemctl" in others.
To be fair though, it's all a pretty minor point. But I do think it's cool that systemctl has that option. shrug
But that seems worse? If all your commands are systemctl, then you just have to ^p and edit/rerun, but there isn't a `systemctl $EDITOR /some/file`, so you'll have to ssh to run emacs (or use TRAMP, if using emacs), at which point you might as well just have a shell on the other end and do everything without having to tack --host onto your commands
I don't know. Maybe. It seems like something that could be handy, but I don't yet know how much I'll wind up using it. For what it's worth, I was working on a scenario exactly like this earlier tonight, and I wound up just ssh'ing into a shell on the remote box to do stuff. But that might just be inertia from being used to doing that, or maybe it was because I had a lot of other stuff to do on that box at the same time...
For me personally, I'd say "not much". I'm used to using the latter form, and it's fine. But I will say that now that I know about this, I see using it in scenarios where I'm running a lot of systemctl commands over and over again in close proximity and have the "muscle memory" of typing "systemctl" more in mind.
For example, when working with a new service that isn't quite working right yet, and doing many iterations of:
Especially if I'm testing on my laptop AND a remote deployment, I think it's easier from a cognitive viewpoint to always "think systemctl" instead of having to "think systemctl" sometimes and "think ssh systemctl" in others.To be fair though, it's all a pretty minor point. But I do think it's cool that systemctl has that option. shrug