Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed i

Parallelism is but a small part of the complicated topic of boot time optimization. And yes, sequential strategies can still be really fast. Much of the speed increase in modern systems is not from parallelism, but forfeiting the overhead of the shell interpreter in favor of direct execution. Checkpointing can do far greater wonders for your boot times than parallelism can, anyhow. No. I have worked on embedded Linux systems where we have carefully charted boot time. We were able to get order-of-magnitude improvements by parallelizing service startups during boot. Parallelism is far from "a small part"-- it is the only important part. The overhead of the shell is negligible even on the slowest systems. Checkpointing is not an option for most things (I have mentioned this several times) because most of the startup processes initialize the hardware directly or indirectly, and hardware can't be checkpointed. The idea of device units is not well borne out, as I mentioned. You don't need to create an object type out of a udev handle to order after devices or trigger hotplug events (the device node manager itself does fine, of course in the case of systemd, udev is part of the project, so...) The important question is whether there is more or less complexity in systemd than a system with a separate device node manager. I am not convinced that systemd is more complex than the alternative. If the device node manager was separate, you would have to debug the interaction between the two processes. Having dealt with debugging d-bus interactions on Linux before, it doesn't sound fun. I'm not convinced that a static dependency graph is even feasible in a world where users can reconfigure and install new services, hotplug hardware, and join and leave wireless networks.