Because systemd doesn't run on BSD, and probably never will.
This is a shame, because it makes for brittle software, even when targeting the same platform where APIs do shift and improve over time.
To quote:
> In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!
I find this to be extremely cringe-worthy; I can only hope that a Linux monoculture isn't the future of open source development.
The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.
False dichotomy; simply don't make abundant use of #ifdefs.
Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary.
The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
This is exactly what systemd's D-Bus API is for.
No. A proper approach to abstraction:
- Reduces complexity by reducing interdependency between subsystems.
- Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing.
- Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on.
> Might be fine for a lot of projects, but this is just something to boot up your system.
Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable).
Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
See, for example, Kernighan and Pike talking about portability in The Practice of Programming.
You could start by explaining "a bunch of stuff" -- and why it's necessary -- concretely.
PS - So-called "theoretical" use cases have probably been the number one source of bugs (especially security holes) in the history of software. "Oh, don't worry about checking array bounds, nobody would be stupid enough to write too much data!"