I'm not sure it's all that effective. Yes, they've managed to harass this guy into leaving the systemd team for Debian. But I don't think that's enough to keep systemd out of Debian. And the way things are going, nothing will.
Debian is an operating system, but the amount of code that comes from people actually part of the Debian project is very, very small in comparison to the amount of code that comes from upstream projects. Some of those projects have people on them who are involved in Debian, many do not. In a growing number of cases, those upstreams are starting to rely on functionality that systemd provides, partly because it's becoming common to have systemd available on Linux systems, partly because it's providing functionality that nobody else is (like logind replacing the aged and unmaintained ConsoleKit[1]).
So if upstream packages are going to rely upon systemd, what is Debian to do? They have a limited set of options. They are:
1) Ship the packages the way the upstream built them -- dependent on logind, for instance. Ship any systemd compatability shims that exist for people who want to make a go of it without systemd.
2) Stop shipping packages that require systemd, or rewrite parts of thost packages until they don't anymore.
The problem is that a lot of volunteers who maintain packages for Debian are convinced that number one is the best -- it's the least effort for them, and provides the best user experience for anyone on systemd. People who want to keep systemd out of Debian are pushing for number two, and they're trying to do it politically -- in other words, force maintainers to behave how they want to. In a volunteer project, that's rather dicey.
But there's really no avoiding it -- if the TC had decided against systemd as the default init, GNOME would still depend on logind, and there's still be a fight over who had to do the work to get GNOME running without systemd.
(This is also why I'm really annoyed at people who keep screaming that Linux is about choice -- yes, but it's not about coerced choice. Your choice not to use systemd doesn't mean you get to force others to work on code to support your choice.)
[1] Yes, someone forked ConsoleKit into ConsoleKit2. That happened about a month ago, way past the point where all this debate started, and probably past the point where most packages are going to care.
Comments
I'm not sure it's all that effective. Yes, they've managed to harass this guy into leaving the systemd team for Debian. But I don't think that's enough to keep systemd out of Debian. And the way things are going, nothing will.
Debian is an operating system, but the amount of code that comes from people actually part of the Debian project is very, very small in comparison to the amount of code that comes from upstream projects. Some of those projects have people on them who are involved in Debian, many do not. In a growing number of cases, those upstreams are starting to rely on functionality that systemd provides, partly because it's becoming common to have systemd available on Linux systems, partly because it's providing functionality that nobody else is (like logind replacing the aged and unmaintained ConsoleKit[1]).
So if upstream packages are going to rely upon systemd, what is Debian to do? They have a limited set of options. They are:
1) Ship the packages the way the upstream built them -- dependent on logind, for instance. Ship any systemd compatability shims that exist for people who want to make a go of it without systemd. 2) Stop shipping packages that require systemd, or rewrite parts of thost packages until they don't anymore.
The problem is that a lot of volunteers who maintain packages for Debian are convinced that number one is the best -- it's the least effort for them, and provides the best user experience for anyone on systemd. People who want to keep systemd out of Debian are pushing for number two, and they're trying to do it politically -- in other words, force maintainers to behave how they want to. In a volunteer project, that's rather dicey.
But there's really no avoiding it -- if the TC had decided against systemd as the default init, GNOME would still depend on logind, and there's still be a fight over who had to do the work to get GNOME running without systemd.
(This is also why I'm really annoyed at people who keep screaming that Linux is about choice -- yes, but it's not about coerced choice. Your choice not to use systemd doesn't mean you get to force others to work on code to support your choice.)
[1] Yes, someone forked ConsoleKit into ConsoleKit2. That happened about a month ago, way past the point where all this debate started, and probably past the point where most packages are going to care.