Service subsystems can be complicated and offer a lot of features. Even systemd services, which are relatively simple compared to the Windows Service subsystem, has a lot of features and service integration possibilities.

It is not the goal of qsu to be able to express every type of service, its goal is merely to facilitate the development of some hand-wavy "normal" service, where the developer should minimally need to worry about platform/subsystem specific integrations. In order to accomplish this it makes a few assumptions:

• Some features, like configuration reload events, are available on all platforms, but they will never be generated on some (for instance Windows service subsystem will never generate them).
• Linux has different subsystems to manage services. qsu only allows special integration against systemd, and is limited to the notify and notify-reload service types.
• There are two types of logs; "production logs" are for end-users. "developer logs" are for developers and troubleshooting only. qsu uses the log crate for "production logs" and tracing crate for "developer logs". It assumes ownership of these runtimes, in the sense that it will initialize them and assumes no one else does so.
• While developing service applications the developer may not want to have to install the program as a service, but run it as a regular foreground program. Doing this should require minimal diverging code.
• qsu claims ownership of certain signals on unixy platforms. On Windows it claims ownership of Ctrl+C and Ctrl+Break when running in foreground mode.

Agnostic to the developer, but idiomatic to the end-user

While it's a goal to provide a simple and unified developer experience when writing service applications (regardless of the service subsystem the application is run on top of), the same is not true from the end-user administrator's perspective. It can be very annoying when foreign idioms are brought into a system -- it's not unreasonable to assume that people want new programs to behave like all the other programs they are accustomed to on their platform.

As an example, Windows administrators will likely expect certain service configuration parameters to be stored in the registry, under the service's reguistry subkey. qsu caters to this, and this will inevitably bleed into the developer's domain -- but the goal to limit subsystem-specifics as much as possible for the developer, while enabling idiomatic behaviors for the system administrators.