- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Why pro-systemd and anti-systemd people will never get along
|
|
|
Comments (89)
The Zorro syndrome
61 earlier comments in the full thread.
@cybertao: you didn't get the message. Poettering and Sievers brought indeed a new init system to Linux. Which is a good thing. Now why do they have to spread their mess all over Linux in places where it doesn't belong? Hence my analogy. Add to that the fact that Lennart is a jerk, no more no less. Hearing this guy talk, I wouldn't trust him with mowing my lawn, let alone build an init system for the servers I depend on for my work. I know this is ad hominem, but I can't help it.
> "Ah, I see the lying jerk is back." (systemd fanboy troll)
> "Add to that the fact that Lennart is a jerk..." (systemd and PulseAudio developer)
A pattern emerges.
> "Add to that the fact that Lennart is a jerk..." (systemd and PulseAudio developer)
A pattern emerges.
jdixon wrote:If I'm going to be forced to use software I don't like, it might as well be Windows or OSX.Go on then, do it already. Cut your nose off to spite your face and see how many people notice or care.
Just a little reminder why staying with Slackware, Crux, Gentoo or Alpine Linux is a safe bet.
https://bugs.freedesktop.org/show_bug.cgi?id=76935
https://bugs.freedesktop.org/show_bug.cgi?id=76935
I've already told you: cybertao is Lennart. He's taking everything personally, so he is either payed to make a full of himself, or he is Lennart. Why would anybody pay this guy, I have no idea. Probably it works on windows forums... I still think he is Lennart!
You've failed the Turing test, Jazz. Who do you think pays out rope to me through the windows until I'm full?
> I've already told you: cybertao is Lennart.
I don't think so -- after all, wouldn't Lennart at least make some actual arguments, along the way? In any case, though he might have no use for them, Lennart Poettering at least would have some idea what the basic Unix design principles are.
Read back through cybertao's posts in this thread; it seems pretty clear that this guy is just a common troll. (Please stop feeding him.)
I don't think so -- after all, wouldn't Lennart at least make some actual arguments, along the way? In any case, though he might have no use for them, Lennart Poettering at least would have some idea what the basic Unix design principles are.
Read back through cybertao's posts in this thread; it seems pretty clear that this guy is just a common troll. (Please stop feeding him.)
> Go on then, do it already. Cut your nose off to spite your face and see how many people notice or care.
But didn't you just tell me not to use systemd if I didn't want too? Note: See lying jerk above.
For someone who doesn't notice or care, you seem to complain about my choices a lot.
In any case, Slackware isn't forcing me to use software I don't like. When it does, I'll worry about switching.
But didn't you just tell me not to use systemd if I didn't want too? Note: See lying jerk above.
For someone who doesn't notice or care, you seem to complain about my choices a lot.
In any case, Slackware isn't forcing me to use software I don't like. When it does, I'll worry about switching.
jdixon wrote:But didn't you just tell me not to use systemd if I didn't want too? Note: See lying jerk above.You can use Linux without systemd. However, you've been chucking your toys out of the cot and 'threatening' to just use Windows or OSX instead. Which you should just go and do instead of being such a diva.
BernardSwiss wrote:Lennart Poettering at least would have some idea what the basic Unix design principles are.Since jdixon won't personally provide three examples of principles important to him and specify how systemd contravenes them, perhaps you'd like to have a crack. Since you talk about the Unix design principles you must be able provide an authoritative list you base decisions for software you are willing to use or rebuke on.
Until then, “Yoonax phoolawsaphay”. Like the article says.
> You can use Linux without systemd.
And I do, and will. As long as I have the option to do so. When I don't, it's time to leave.
> However, you've been chucking your toys out of the cot and 'threatening' to just use Windows or OSX instead.
If I'm forced to use software I don't want to, yes. But you left that part out, didn't you? Note: See lying jerk above.
> Since jdixon won't personally provide three examples of principles important to him and specify how systemd contravenes them...
I'm not your personal secretary. If you want me to research things for you that you're obviously not capable of researching yourself, my fee would be $100/hour.
And I do, and will. As long as I have the option to do so. When I don't, it's time to leave.
> However, you've been chucking your toys out of the cot and 'threatening' to just use Windows or OSX instead.
If I'm forced to use software I don't want to, yes. But you left that part out, didn't you? Note: See lying jerk above.
> Since jdixon won't personally provide three examples of principles important to him and specify how systemd contravenes them...
I'm not your personal secretary. If you want me to research things for you that you're obviously not capable of researching yourself, my fee would be $100/hour.
@cybertao, I'll cite at least three principles since I needed to read them anyway.
http://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_an...
Rule Of Modularity: Systemd contravenes this principle through its use of binary logs enabled by default (well known interfaces).
Rule of Composition: Systemd fails to comply with this principle because of the way it hijacks the "debug" command-line parameter from the kernel.
Rule of Simplicity: Systemd has far too many interdependencies and external dependencies to be considered compliant to this principle.
Let's try to remember this, Systemd is salvageable and has some pretty interesting features included in it. The problem is Lennart Poettering and Kay Sievers and their "cavalier" attitude toward bug reports and (at first) constructive criticism regarding design choices such as binary logs and hard dependencies for gnome and various other downstream projects. Listen, the distros probably have their reasons for choosing Systemd over Upstart or OpenRC, but that doesn't mean they have to wholeheartedly condone all of the Systemd team's choices or demeanor toward the community.
Can I at least get you to admit that you never want to see a reply like Kay Sievers' when you report a bug (and that seriously is a BUG) for one of the most important pieces of software on your computer next to the kernel itself? I'll even admit that the rest of the Systemd opponents on that bug report hurt the discussion more than they helped.
http://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_an...
Rule Of Modularity: Systemd contravenes this principle through its use of binary logs enabled by default (well known interfaces).
Rule of Composition: Systemd fails to comply with this principle because of the way it hijacks the "debug" command-line parameter from the kernel.
Rule of Simplicity: Systemd has far too many interdependencies and external dependencies to be considered compliant to this principle.
Let's try to remember this, Systemd is salvageable and has some pretty interesting features included in it. The problem is Lennart Poettering and Kay Sievers and their "cavalier" attitude toward bug reports and (at first) constructive criticism regarding design choices such as binary logs and hard dependencies for gnome and various other downstream projects. Listen, the distros probably have their reasons for choosing Systemd over Upstart or OpenRC, but that doesn't mean they have to wholeheartedly condone all of the Systemd team's choices or demeanor toward the community.
Can I at least get you to admit that you never want to see a reply like Kay Sievers' when you report a bug (and that seriously is a BUG) for one of the most important pieces of software on your computer next to the kernel itself? I'll even admit that the rest of the Systemd opponents on that bug report hurt the discussion more than they helped.
@gru,
In simple terms I think that I understand what you are saying and can suggest a real world test that would tell if a piece of software followed the Unix philosopy.
Can it easily be swapped for a better alternative?
For example, less and more. The old unix command, more, let users page through large files. less provides the same functionality, and so much more (pun intended). Because both less and more were modular, simple and fully composed , they could easily be swapped. You could delete the more in /usr/bin and replace it with a link that points to /usr/bin/less, and everything would continue to work, but users would get all of the benefits of less!
Your criteria would imply that systemd is broken, unless or until, it can easily be swapped for an alternative init system. If it were designed with the unix philosophy, it would be a only a minor effort for system builders to replace init or upstart with systemd. (You would then probably have no complaints and never think about it.) It would not be a trivial replacement, but its modularity and simplicity would reduce dependencies and make it not too complex to do so.
Also, and this is the most important thing I think, when a better init system is developed in 10 years or so, it would be easy to reaplace systemd with the newer better init system. As it is, we are going to be stuck with systemd for a long time (even when vastly superior init systems are available).
Think of how long it took to replace X!
Sadly, as you point out, systemd is not built following these principles, and is therefore broken. It may work perfectly well and it may have a gajillion-zillion wonderful features and may make a mean cappucino as well, but until it is easily replaced, it is flawed.
Do I understand what you are trying to say?
In simple terms I think that I understand what you are saying and can suggest a real world test that would tell if a piece of software followed the Unix philosopy.
Can it easily be swapped for a better alternative?
For example, less and more. The old unix command, more, let users page through large files. less provides the same functionality, and so much more (pun intended). Because both less and more were modular, simple and fully composed , they could easily be swapped. You could delete the more in /usr/bin and replace it with a link that points to /usr/bin/less, and everything would continue to work, but users would get all of the benefits of less!
Your criteria would imply that systemd is broken, unless or until, it can easily be swapped for an alternative init system. If it were designed with the unix philosophy, it would be a only a minor effort for system builders to replace init or upstart with systemd. (You would then probably have no complaints and never think about it.) It would not be a trivial replacement, but its modularity and simplicity would reduce dependencies and make it not too complex to do so.
Also, and this is the most important thing I think, when a better init system is developed in 10 years or so, it would be easy to reaplace systemd with the newer better init system. As it is, we are going to be stuck with systemd for a long time (even when vastly superior init systems are available).
Think of how long it took to replace X!
Sadly, as you point out, systemd is not built following these principles, and is therefore broken. It may work perfectly well and it may have a gajillion-zillion wonderful features and may make a mean cappucino as well, but until it is easily replaced, it is flawed.
Do I understand what you are trying to say?
> I don't think so -- after all, wouldn't Lennart at least make some actual arguments, along the way?
Apparently he gets offended when you call him Lennart. It is the first time I see a systemd troll offended by this. They usually worship him. He must be Lennart.
Apparently he gets offended when you call him Lennart. It is the first time I see a systemd troll offended by this. They usually worship him. He must be Lennart.
@number6x
You got it. It might well be a very efficient and useful piece of software, but it's the implementation and peripheral considerations that make the prospect of fully committing to it dubious.
I guess my biggest complaint about it was that it was designed in such a way that it can only thrive at the expense of other init systems and the utilities they use, and it was pitched to downstream projects (Gnome) as an all-or-nothing choice without the notification of and consent from the larger community. To top it off, whenever the dev team was presented with some constructive suggestions and questions of design choices, they displayed a level of disregard that no serious FOSS developer should ever have for his/her own users, even if they disagree with the criticism.
No matter how important you think your project is, you never break previously existing functionality in the kernel-space and then just tell a downstream developer to accommodate your questionable design decisions in their project. It's just not good community stewardship, and it reflects a lack of maturity and character that you would hope to see in an init development team.
You got it. It might well be a very efficient and useful piece of software, but it's the implementation and peripheral considerations that make the prospect of fully committing to it dubious.
I guess my biggest complaint about it was that it was designed in such a way that it can only thrive at the expense of other init systems and the utilities they use, and it was pitched to downstream projects (Gnome) as an all-or-nothing choice without the notification of and consent from the larger community. To top it off, whenever the dev team was presented with some constructive suggestions and questions of design choices, they displayed a level of disregard that no serious FOSS developer should ever have for his/her own users, even if they disagree with the criticism.
No matter how important you think your project is, you never break previously existing functionality in the kernel-space and then just tell a downstream developer to accommodate your questionable design decisions in their project. It's just not good community stewardship, and it reflects a lack of maturity and character that you would hope to see in an init development team.
What about glibc then? There are alternatives, such as uClibc, but many applications depend on the functionality only glibc provides. Is glibc broken? Are all the apps requiring it broken?
Do people who applying that standard to systemd also apply it to glibc and those apps?
What about proprietary binary blobs running in kernelspace? They aren't easily replaceable, can abuse privileges, and crash the OS. Do you guys apply get all Stallman-esque by applying the same water-test and disabling WiFi?
Do people who applying that standard to systemd also apply it to glibc and those apps?
What about proprietary binary blobs running in kernelspace? They aren't easily replaceable, can abuse privileges, and crash the OS. Do you guys apply get all Stallman-esque by applying the same water-test and disabling WiFi?
I'm not a Stallman-ite(?). I just think that some of the Unix Philosophies are good practice and a best effort should be made. Obviously Linus doesn't practice this for the kernel, and the glibc and X teams do not either, but that doesn't mean we should apply those exceptions to all new software introduced as FOSS.
Let's take your argument and reverse it real quick. The Linux kernel, Systemd, glibc, and X are all monolithic binaries that are difficult (if not impossible) to interchange. If it's okay for them, then it's okay for all other applications to be built the same way. Do you see how this is also not a good thing?
We're not trying to go full Stallman, but we're also not trying to go full Poettering either. What I'm saying is that more consideration for the community should have been observed when the system was designed, and I don't have to condone or condemn the Linux kernel or glibc to ask this of the Systemd dev team.
Let's take your argument and reverse it real quick. The Linux kernel, Systemd, glibc, and X are all monolithic binaries that are difficult (if not impossible) to interchange. If it's okay for them, then it's okay for all other applications to be built the same way. Do you see how this is also not a good thing?
We're not trying to go full Stallman, but we're also not trying to go full Poettering either. What I'm saying is that more consideration for the community should have been observed when the system was designed, and I don't have to condone or condemn the Linux kernel or glibc to ask this of the Systemd dev team.
gru wrote:Let's take your argument and reverse it real quick. The Linux kernel, Systemd, glibc, and X are all monolithic binaries that are difficult (if not impossible) to interchange. If it's okay for them, then it's okay for all other applications to be built the same way. Do you see how this is also not a good thing?The thing is, systemd is not an application. It's a service layer, one that takes full advantage of the features available in Linux and glibc.
As kikinovak suggested earlier, anyone who feels strongly about the subject should consider using Alpine.
Alpine looks pretty good. Still seems a bit new, and for such as small distro, 338 active bugs is still a hard pill to swallow for some desktop users, let alone production servers.
If Systemd truly ends up being a nuisance, then there are still alternatives (for now). If it doesn't end up being a nuisance, then I guess people will either fork or find a new normal.
If Systemd truly ends up being a nuisance, then there are still alternatives (for now). If it doesn't end up being a nuisance, then I guess people will either fork or find a new normal.
Upstart vs Systemd from Debian Standpoint
Please, view :-
1. https://wiki.debian.org/Debate/initsystem/systemd
2. https://wiki.debian.org/Debate/initsystem/upstart
Section CONS ([2]) sounds like :-
Upstart is covered by a copyright license agreement, which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the Debian package; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL.
1. https://wiki.debian.org/Debate/initsystem/systemd
2. https://wiki.debian.org/Debate/initsystem/upstart
Section CONS ([2]) sounds like :-
Upstart is covered by a copyright license agreement, which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the Debian package; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL.
Imagine if Canonical had just given Upstart to the Debian and Ubuntu community at large with no copyright strings attached and promised ongoing support. Debian would surely have adopted Upstart, and the whole Systemd debate would have been radically altered, if not trivial altogether.
It always amazes me how Shuttleworth and Co. appear to be addicted to alienating themselves from the FOSS community by trying to act like a proprietary software solutions vendor. This insistence on vendor lock-in on his part was the deciding factor for steering Debian toward Systemd.
Case in point: "Upstart was a huge improvement over sysvinit, and Debian should have switched to it years ago. Now that systemd is available and well-tested, however, it cannot sustain the comparison. Upstart suffers from an improper design which replaces dependencies by purely event-driven actions, and its process tracking is implemented using the wrong tool (ptrace). It would be hard work to provide all the features systemd integrates on top of upstart, and its community, <b>limited in size by Canonical’s policy, seems neither willing nor able to develop them.<b>"
It always amazes me how Shuttleworth and Co. appear to be addicted to alienating themselves from the FOSS community by trying to act like a proprietary software solutions vendor. This insistence on vendor lock-in on his part was the deciding factor for steering Debian toward Systemd.
Case in point: "Upstart was a huge improvement over sysvinit, and Debian should have switched to it years ago. Now that systemd is available and well-tested, however, it cannot sustain the comparison. Upstart suffers from an improper design which replaces dependencies by purely event-driven actions, and its process tracking is implemented using the wrong tool (ptrace). It would be hard work to provide all the features systemd integrates on top of upstart, and its community, <b>limited in size by Canonical’s policy, seems neither willing nor able to develop them.<b>"
I wanna be clear though, many of the features on top of Upstart mentioned in the above quote don't NEED to be, and probably SHOULDN'T be included in an init system. Having said that, it is still a shame that a distro as amazing as Ubuntu used to be has been crippled and deformed by its creator.
It's like Ubuntu circa 2007 was Anakin Skywalker (young, brash, and full of hope), and Ubuntu circa 2015 is Darth Vader (just an asshole). "He's more machine now than man... twisted and evil." Except comparing Shuttleworth to Palpatine is honestly giving the man too much credit.
It's like Ubuntu circa 2007 was Anakin Skywalker (young, brash, and full of hope), and Ubuntu circa 2015 is Darth Vader (just an asshole). "He's more machine now than man... twisted and evil." Except comparing Shuttleworth to Palpatine is honestly giving the man too much credit.
> It's like Ubuntu circa 2007 was Anakin Skywalker (young, brash, and full of hope), and Ubuntu circa 2015 is Darth Vader (just an asshole). "He's more machine now than man... twisted and evil." Except comparing Shuttleworth to Palpatine is honestly giving the man too much credit.
I was just thinking along those lines yesterday. Remember the "Linux for Human Beings"?
Now, it's "Linux for Phones and Corporate Profits".
I was just thinking along those lines yesterday. Remember the "Linux for Human Beings"?
Now, it's "Linux for Phones and Corporate Profits".
This just kills me every time, particularly the bit about "Ubuntu CDs contain only free software applications; we encourage you to use free and open source software, improve it and pass it on."
http://web.archive.org/web/20070705222116/http://www.ubuntu....
And then a week or so ago, Shuttleworth mixed up a fresh batch of koolaid, asking developers to focus on contributing to HIS "convergence" (phone) priorities. And, he was actually surprised that nobody wanted his koolaid anymore.
To be fair, Ubuntu distributions still only contain free software applications out of the box. They can't legally distribute patent and licensed software in all jurisdictions. There is a clear trend to get people hooked on their services, as every other company in the world does, and development of their pet projects, but Ubuntu is still as free as it ever was. The only lock-in comes from people utilizing their services and personally liking the environment they develop.
Regarding Upstart, someone could have just forked it. Had it been forked, developed, and promoted it might very well have been a suitable candidate to replace sysvinit. Perhaps even filtering upstream to replace Upstart itself or put Upstart downstream of it. It wasn't though.
Regarding Upstart, someone could have just forked it. Had it been forked, developed, and promoted it might very well have been a suitable candidate to replace sysvinit. Perhaps even filtering upstream to replace Upstart itself or put Upstart downstream of it. It wasn't though.
Just looked at the Contributor license agreement, and they've changed it since the Debian init debate (probably as a result).
http://www.ubuntu.com/legal/contributors/licence-agreement-f...
I can understand that Canonical wants (needs) to monetize Ubuntu in order to be profitable (they never have been), but their decision to implement a contributor agreement that forced entire distro teams to assign copyright to them for their own code was preposterous.
Yes Debian members could have forked Upstart, or any other init system to their liking for that matter, but they didn't want the overhead so they opted for what they perceived at the time as the lesser of two evils. It's a shame that a perfectly adequate and more mature init system had to be killed because of the copyright ambitions of a profit motivated company.
Taken from the Upstart Cookbook (http://upstart.ubuntu.com/cookbook/):
"In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of "helper" daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons."
I can understand that Canonical wants (needs) to monetize Ubuntu in order to be profitable (they never have been), but their decision to implement a contributor agreement that forced entire distro teams to assign copyright to them for their own code was preposterous.
Yes Debian members could have forked Upstart, or any other init system to their liking for that matter, but they didn't want the overhead so they opted for what they perceived at the time as the lesser of two evils. It's a shame that a perfectly adequate and more mature init system had to be killed because of the copyright ambitions of a profit motivated company.
Taken from the Upstart Cookbook (http://upstart.ubuntu.com/cookbook/):
"In essence, Upstart is an event engine: it creates events, handles the consequences of those events being emitted and starts and stops processes as required. Like the best Unix software, it does this job very well. It is efficient, fast, flexible and reliable. It makes use of "helper" daemons (such as the upstart-udev-bridge and the upstart-socket-bridge) to inject new types of events into the system and react to these events. This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons."
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
> Don't want to use systemd? Then don't.
I won't. As I said, If I'm going to be forced to use software I don't like, it might as well be Windows or OSX.