Colin Booth:
I mean't more in the "one stop low-level system management" sense. Also in the design of the nosh unit files (which may be a case of parallel evolution, my knowledge of the history of nosh is limited at best). Pholosophicaly it's definitely coming from the daemontools world.
Yes, and they aren't really "nosh unit files". The native mechanism for nosh is the service bundle, comprising supervise/ subdirectory, service/ subdirectory, and various others. The systemd unit file is something that can easily be turned into a service bundle. It's not parallel evolution. It's simple recognition that the world is handing around systemd unit files with its softwares, and providing an easy migration path for that.
There's no reason, in principle, that someone couldn't come along and write a tool that parsed a launchd plist and made a native nosh service bundle. Translate <key>EnvironmentVariables</key> into setenv; <key>SoftResourceLimits</key> into softlimit; and so forth.
