Linked by jessesmith on Wed 5th Nov 2014 10:39 UTC
Linux Over the past year I've been reading a lot of opinions on the new init technology, systemd. Some people think systemd is wonderful, the bee's knees. Others claim that systemd is broken by design. Some see systemd as a unifying force, a way to unite the majority of the Linux distributions. Others see systemd as a growing blob that is slowly becoming an overly large portion of the operating system. One thing that has surprised me a little is just how much people care about systemd, whether their opinion of the technology is good or bad. People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do. Opponents claim systemd will divide the Linux community and drive many technical users to other operating systems. There is a lot of hype and surprisingly few people presenting facts.
Thread beginning with comment 598996
To view parent comment, click here.
To read all comments associated with this story, please click here.
ddjones
Member since:
2014-10-28

That's the point though: If you don't like software depending on systemd, it's up to you to fork the software, because clearly the people who actually write it aren't interested in sysvinit compatibility.

That's why we have eudev, uselessd, and consolekit.
They all have serious downsides, but at least the devs are putting their money where their mouths are, and writing alternatives.

tl;dr: Software becomes dependent on systemd. Choices:
a) Fork sotftware
b) Use systemd


c) Switch to another distro which doesn't use systemd

Yes, everyone understands that that is, in fact, largely the choice users face. You either use systemd, you switch to another of the vanishingly small distributions which don't require systemd, or you take on the onerous task of building a complete fork of your chosen distribution. While the last option is technically possible, it's far beyond the capabilities of most users and an enormous task even for those with the technical chops to pull it off. It's an option but not a reasonable option for most users. The question isn't what choice users face. The question is whether it's fair or reasonable for the distributions to put their users in the position of having to make that choice.

And of course the distro leadership CAN put their users in that position. It's certainly not illegal, and it's not immoral in any larger sense of the word. But because a leadership body CAN do something doesn't mean that they SHOULD, nor does it mean that the users of that distro can't express their opinions about the action taken by the leadership. Most distros are communities. They value the opinions of their users. They EXIST to provide a valuable and useful operating system for their users. When the body of users of a distro shrinks beyond a certain point, the distro usually dies. It might thrash about for a bit or remain a peripheral player for an extended time, but it generally stagnates and disappears. Leadership certainly can't please everyone, nor should they try. But they can and generally do consider the opinions of their users, and try to work out accommodations and compromises where feasible. It's in their best interest to maintain a large and diverse body of users. If a significant chunk of users break away and stop supporting Debian, everyone loses.

Your original post essentially said "STFU and go away - your opinion and preferences don't matter because they differ from mine." You're entitled to that opinion, of course, but I'm also entitled to mine. You can't make me STFU and you can't make me go away, no matter how much arrogance you exude.

Reply Parent Score: 4

hobgoblin Member since:
2005-07-06

How long can you guarantee that option C will be there?

With the mission creep of systemd, more and more user facing projects are likely to develop some kind of systemd dependency for some "reason" or other.

End result is that if you want to use program X, you now have to have systemd sub-system Y, and that again depends on systemd running as pid1 (init).

At no time in the past have user facing programs cared what kind of init the system is running.

Reply Parent Score: 7