I realize I'm years late to the party arguing about this stuff , but I had a fine stable old debian laptop so none of it was relevant to me at the time.
I honestly came to systemd willing to give it a shot. Hell I can even forgive them for making technical decision designed to serve political ends. I sure wouldn't know how to get sufficient agreement for what they're trying to do myself. I always disliked sysvinit/inetd, and I like a lot things in systemd. I'm going to skip the usual arguments about systemd not because they're wrong or irrelevant but because they're commonly known. My apologies if these other issues are also well-known. Besides those usual arguments, the things that bother me about the above stack of software are: * the relative opaqueness of the big-blob-of-C approach. When it doesn't work its not obvious where it's failing, and when it does work it's hard to tell why. Yes network-manager logs a lot, but that approach can't hope to compete with a script that you can read and maybe set -ex and easily find out what's going on. C is simply the wrong language for most of this stuff. There's no efficiency requirement or need to use C-only APIs. * The relationship between the layers is incestuous. In theory gnome is layered on top of dbus, with network-manager optional, and all of the above independent of systemd, but in practice this is doomed to not be the case. The people who use this stack mostly use all of it, and other approaches are relatively untested. The upstream developers are not only well aware of this situation, but seem perfectly fine with it. They have a record of assimilating dependent projects. * One of debian's major promises involves it's ability to carry forward config files across upgrades. In practice this was always an ambitious promise and could run into trouble for extensively modified configurations over large upgrades, but the situation with systemd is much worse. systemd makes no secret of it's desire to replace various daemons. They talk about /etc-free systems. What happens to debian's promise to attempt to carry forward configuration under these circumstances? I sure hope debian can somehow continue to support alternative setups. It looks to me like it's going to be tough. E.g. I have no idea how debian even handles the udev issue for sysvinit systems, and at the moment I can't afford to break a bunch of stuff finding out. debian should not sell itself short and imagine that this new stack is better than all the infrastructure it built up over the years for doing mostly the same stuff. Britton