thoughts on systemd, network-manager, dbus, packagekit, gnome etc.
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
Reply to: