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.
I don't know why you got downvoted, but I fear it may be because the people doing that don't consider it "immoral" at all, because they are doing God's work, so ejecting the heathens is by definition right.
I have no desire to be a package maintainer. But if it goes as far that systemd support in Debian gets threatened, I'd step up, as the alternative would be to switch distributions. I'm sure others would feel the same.
It'll not be effective.
If anything, I suspect the long term effect will be to make it harder for those who don't like systemd to get heard.
Comments
As a strategy for keeping systemd out of Debian, harassing the maintainers of systemd until they quit the project is extreme, immoral, and effective.
(This is not an endorsement of the tactic!)
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.
I don't know why you got downvoted, but I fear it may be because the people doing that don't consider it "immoral" at all, because they are doing God's work, so ejecting the heathens is by definition right.
Edit: Found this in the other thread: https://news.ycombinator.com/item?id=8616490
I have no desire to be a package maintainer. But if it goes as far that systemd support in Debian gets threatened, I'd step up, as the alternative would be to switch distributions. I'm sure others would feel the same.
It'll not be effective.
If anything, I suspect the long term effect will be to make it harder for those who don't like systemd to get heard.