The architecture he describes, that of an event broker, sounds a lot more like Upstart than it does like systemd, though. That said, the proposed idea doesn't

The architecture he describes, that of an event broker, sounds a lot more like Upstart than it does like systemd, though. That said, the proposed idea doesn't sound like something that is trivial at all, but rather pretty bug-prone. There already are de facto event engines for certain areas like device hotplugging (formerly HAL and now udev on Linux, devd on FreeBSD), whereas for a lot of other events in Linux software a typical way is to subscribe on an application's D-Bus interface and wait for signals. Indeed, OS X's notify API looks precisely like a message queue from my brief observations. But then there's certain events and classes of events (such as "network is up/network is down") that could have literally over a dozen meanings. I'm not sure how a practical centralized event broker could be anything more than a glorified message bus? Otherwise, encapsulating highly multi-faceted and non-deterministic system states into generic events sounds like bugs galore.