Avoiding systemd isn't hard(vitavonni.de)
vitavonni.de
Avoiding systemd isn't hard
http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html
111 comments
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with.
This. It doesn't help this guy's case that he's basically calling anyone who doesn't want systemd a "troll". That's not the way to win people to your side of a disagreement.
This. It doesn't help this guy's case that he's basically calling anyone who doesn't want systemd a "troll". That's not the way to win people to your side of a disagreement.
> This.
This. Backed by nothing, calling the systemd team "notoriously hard to get along with". I'd be interested in seeing proof of "this".
This. Backed by nothing, calling the systemd team "notoriously hard to get along with". I'd be interested in seeing proof of "this".
A quote[1] by a systemd developer:
"The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future."
A major bug is reported, and their response is "it's too hard so we won't fix it" in a project that is soon to be at the core of every major GNU/Linux distro? No thanks.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=64116
"The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future."
A major bug is reported, and their response is "it's too hard so we won't fix it" in a project that is soon to be at the core of every major GNU/Linux distro? No thanks.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=64116
Does that really illustrate 'hard to get along with'?
I'd say telling a bug reporter that their report is useless because "we're too lazy and dumb to fix it" is being hard to get along with. Besides, that's far from the only example. A quick Google search brings up dozens of cases where systemd developers and evangelists deride even those who ask basic questions about it. It's a perfect example of "it's our playground, find your own" that is so juvenile and antisocial that it bothers the hell out of me. And that's not even the reason I don't want to use systemd; I simply prefer traditional init systems like sysvinit and Slackware's BSD-style init system.
have you actually used systemd before? it's quite good.
Yes, in Arch Linux. And as I've said elsewhere, it's a good idea, but terrible execution and a load of unnecessary controversy. I think GNU/Linux should have one major init system, with the option to use any other system one wants to. But in my own informed opinion, systemd is not the init system we need. I'll take 30 year old working technology over unproven, barely tested new technology with hostile developers, any day. If the day comes that systemd is stable and mature, drops the insane binary log system, stops being a dependency for entire DEs, stops being hostile to any other init system (if your distro of choice uses systemd as a default you risk breaking your system if you want something else), along with developers who aren't lazy and working in a bubble of their own creation, then I'll welcome it with open arms.
But that's a lot to overcome.
But that's a lot to overcome.
I guess not, but maybe it's even more damning that this core system component is so much more complex than the previous system, that it sometimes corrupts its data. I'm willing to believe that's not catastrophic, but can someone tell me why it's a good thing for an init system to have corruptible persistent state to begin with?
There are a couple of incidents mentioned on the LKML that go directly to their bug tracker - the ones I refer to is where Linus gives Kay Sievers an earful for hijacking the kernel flags (and subsequently writing off the perfectly reasonable complaint). I'd link you to them directly but I'm mobile now.
Here's the LWN story of this "incident": http://lwn.net/Articles/593676/ ; it has all the proper sources in links.
Core package bsdutils predepends on libsystemd0. Now it is impossible for any Debian jessie systems to be without systemd code.
https://packages.debian.org/sid/bsdutils
https://packages.debian.org/sid/bsdutils
That's moving the goalposts in a significant way. Debian has always been of the philosophy that binaries that have runtime-optional support for something link libsomething and have a dependency on it, but there cannot generally be a dependency from libsomething to the actual something package.
For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed.
Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed.
Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
This libsystemd points to a dangerous habit of the certain group of developers who prefer strong interdependency and monolithic architecture. In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. And gconf libraries which ship daemon executables and also launch daemons from library. Libsystemd is apparently not doing such right now, but given its windows.dll like nature, it's a reasonable concern to have.
> In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library.
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
Yep. You noticed that too. I found this out by trying to remove all traces of systemd from my Jessie/Sid installation, found out that I couldn't get rid of libsystemd0 because bsdutils depends on it. That's the same bsdutils that you can't really do without.
It's almost as if systemd was being forced upon you no matter what.
It's almost as if systemd was being forced upon you no matter what.
> Now? No, not really, just avoid GNOME.
You don't have to. Someone apparently implemented the logind interface(!) so that GNOME could function on non-systemd systems. Just use that.
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. [...]
Are you kidding? I've been following along the mailing list for at least two years and I've never seen any of the unreasonableness you claim. (I'm not in any way connected or invested in the systemd project, just as a little disclaimer.)
If you're going to pull this stunt please at least give us concrete references.
> Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
Ah, I see. You're just another troll recycling talking points. Oh, well.
Oh, and btw: Complain all you want -- in F/OSS the people doing the work get to decide. Deal.
You don't have to. Someone apparently implemented the logind interface(!) so that GNOME could function on non-systemd systems. Just use that.
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. [...]
Are you kidding? I've been following along the mailing list for at least two years and I've never seen any of the unreasonableness you claim. (I'm not in any way connected or invested in the systemd project, just as a little disclaimer.)
If you're going to pull this stunt please at least give us concrete references.
> Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
Ah, I see. You're just another troll recycling talking points. Oh, well.
Oh, and btw: Complain all you want -- in F/OSS the people doing the work get to decide. Deal.
No-one has yet come forward publicly with a working second implementation of logind for Linux. The only person known to be working on a second implementation of logind is targetting OpenBSD. To use logind-API-client desktop environments with the well-known systemd-shim actually involves using the logind that is part of the systemd package, running on top of a daemon that implements only part of an internal systemd API. See http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
As well as upower (though it still works with ConsoleKit as fallback, I think), udisks2, the Weston compositor and some other programs. Binary distros also have some pretty skewed dependency chains on systemd for packages where it's inessential.
It'll only grow, though. Most certainly.
It'll only grow, though. Most certainly.
> It'll only grow, though. Most certainly.
Only up to a point. Systemd is getting too bloated, and software engineering tells us that the effort to maintain this will grow exponentially.
So we have two options: if systemd improves and decides to follow UNIX principles, good. Otherwise it'll be replaced like consolekit et al. It's great that we have so many init systems to choose from. The only problem now is software that hard depends on systemd when a single line of code could avoid that.
Only up to a point. Systemd is getting too bloated, and software engineering tells us that the effort to maintain this will grow exponentially.
So we have two options: if systemd improves and decides to follow UNIX principles, good. Otherwise it'll be replaced like consolekit et al. It's great that we have so many init systems to choose from. The only problem now is software that hard depends on systemd when a single line of code could avoid that.
On gentoo, we have virtual/service-manager[0], that allows you to use openrc/systemd/runit/daemontools.
[0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/virt...
[0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/virt...
I think the author should refrain from using the word trolls so much it hampers his overall message.
So what happens with the pinning example with GNOME (I didn't know this useful command)? Because of the dependance on systemd it is not upgraded then?
So what happens with the pinning example with GNOME (I didn't know this useful command)? Because of the dependance on systemd it is not upgraded then?
Indeed, I've went off on some anti-systemd rants, simply based on its design philsophy, but all I ever wanted was init-system flexibility. I'm just glad to see that Debian has went in the right direction with this, rather than enforced a lock-in as has been previously suggested and may be the case on many other distributions.
Would you like your Debian with Unix or Windows flavoring? ;)
Seriously though, I am not really sure how I feel about this. While systemd obviously has benefits, I just can't shake the feeling that it goes against the Unix paradiam. But then again, I also prefer xterms and a window manager over a desktop environments like KDE, Xfce, and Gnome, so maybe that explains my mixed feelings.
Seriously though, I am not really sure how I feel about this. While systemd obviously has benefits, I just can't shake the feeling that it goes against the Unix paradiam. But then again, I also prefer xterms and a window manager over a desktop environments like KDE, Xfce, and Gnome, so maybe that explains my mixed feelings.
I've gone to FreeBSD for now on my personal dev box, I'm a real sucker for a dead simple /etc/rc.conf like Arch used to have and their system philosophy seems more in line with my own anyways.
Very glad to hear we have a major binary distro like Debian committing to init system flexibility this strongly. I just hope it's true. The people who are hesitant can experiment and stay where they are for now, moving only when it's actually desired rather than forced.
Very glad to hear we have a major binary distro like Debian committing to init system flexibility this strongly. I just hope it's true. The people who are hesitant can experiment and stay where they are for now, moving only when it's actually desired rather than forced.
We'll see how this develops, but this ain't Gentoo, I wouldn't count on Debian to keep supporting sysv. Quote from Debian forums:
it's very unlikely that SysVinit will continue to be supported, because writing init scripts for SysVinit is hard work, and if it isn't used as the default on Linux they'll rot.
it's very unlikely that SysVinit will continue to be supported, because writing init scripts for SysVinit is hard work, and if it isn't used as the default on Linux they'll rot.
Well, this post and http://lwn.net/Articles/616571/ does seem to indicate they're planning to keep some level of compatibility with other init systems at least.
I'm not in love with sysvinit, I just don't think systemd is the best option. It clashes, at least with my views on simplistic system design philosophy. OpenRC and FreeBSD's rc seem notably better than both systemd and sysvinit to me.
I'm not in love with sysvinit, I just don't think systemd is the best option. It clashes, at least with my views on simplistic system design philosophy. OpenRC and FreeBSD's rc seem notably better than both systemd and sysvinit to me.
I agree with everything you said, my point was that it's necessary to be prepared, in case systemd becomes a hard dependency for Debian, which is likely given that more software is depending on systemd, and the lead developer is trying to "merge" linux with systemd. And in that case, I think only Gento is willing to fork.
>I've gone to FreeBSD for now on my personal dev box,
I've been contemplating that, too. How do you like it?
Well, it took some RTFMing, but overall it seems quite good. The ports system is great and it has a lot of simple stuff I really like, like having a list of vulnerable packages emailed to root automatically every night by default.
There have been some real hate-filled messages on the mailing lists. If they had been directed at a women then they would have made HN all on their own. The article links to one of them, if you want to check it out.
Here is the message:
There has been no General Resolution amongst debian package maintainers. Red Hat has instituted a regulatory capture of the "bug squashing" committee within debian (the "Technical Committee") by having current or former (but stock holding) employees moonlight in debian and gradually gain membership in that comittie.
Once their numbers were sufficient they proceeded to file a bug report on the fact that systemd was not standard in debian.
This is illicit abuse of process and they need to be prosecuted.
Debian is an unincorporated association. It has bylaws, trade practices, and dealings by which it was governed. The RedHat associated members of the Technical Committee have illegally and in bad faith abused their positions in-order to realize financial and strategic gain for their employer.
Do you really believe this is hate speech? Hate speech attacks a person or group on the basis of attributes such as gender, ethnic origin, religion, race, disability, or sexual orientation.
There has been no General Resolution amongst debian package maintainers. Red Hat has instituted a regulatory capture of the "bug squashing" committee within debian (the "Technical Committee") by having current or former (but stock holding) employees moonlight in debian and gradually gain membership in that comittie.
Once their numbers were sufficient they proceeded to file a bug report on the fact that systemd was not standard in debian.
This is illicit abuse of process and they need to be prosecuted.
Debian is an unincorporated association. It has bylaws, trade practices, and dealings by which it was governed. The RedHat associated members of the Technical Committee have illegally and in bad faith abused their positions in-order to realize financial and strategic gain for their employer.
Do you really believe this is hate speech? Hate speech attacks a person or group on the basis of attributes such as gender, ethnic origin, religion, race, disability, or sexual orientation.
It may not be hate speech, but it is not very constructive and have a smell of conspiracy theory.
Mr. Snowden's revelations prove that "a smell of conspiracy theory" is not a strong enough argument. Obviously Red Hat is interested in widespread systemd adoption, and that message might offer an explanation as to why debian only considered 3 alternatives and unprecedentedly rushed the adoption process. So this angle is definitively constructive.
For the record, the guy on the mailing list linked in the article probably has serious mental health issues.
He also does those really creepy youtube videos: https://www.youtube.com/watch?v=2toVPMHRo8M
And I've heard he contacted other devs and I've heard a couple of stories that I'm not sure I can share publicly at this point.
Generalizing that all systemd opponents are trolls because there is one guy with serious mental health issues is not a valid argument.
He also does those really creepy youtube videos: https://www.youtube.com/watch?v=2toVPMHRo8M
And I've heard he contacted other devs and I've heard a couple of stories that I'm not sure I can share publicly at this point.
Generalizing that all systemd opponents are trolls because there is one guy with serious mental health issues is not a valid argument.
[deleted]
Oh great, now people whose opinions differ are "trolls". I think we all know who the troll is...
He's not casting all opponents of systemd as trolls; he's saying that trolls have spread a lot of misinformation about systemd, which is true.
Opponents of systemd have spread a LOT of FUD and misinformation about systemd. I know, because I was initially very skeptical of (or even opposed to) systemd based on what they had said. Fortunately, I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Even if we give them the benefit of the doubt and say that it wasn't an intentional attempt to spread misinformation, and that they were simply speaking very vocally about a topic that they themselves had not taken the time to read up on, it is not much of a stretch to call that behavior "trolling".
Opponents of systemd have spread a LOT of FUD and misinformation about systemd. I know, because I was initially very skeptical of (or even opposed to) systemd based on what they had said. Fortunately, I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Even if we give them the benefit of the doubt and say that it wasn't an intentional attempt to spread misinformation, and that they were simply speaking very vocally about a topic that they themselves had not taken the time to read up on, it is not much of a stretch to call that behavior "trolling".
While it may not be much of a stretch, it still hampers his point. If the goal is to convince an audience of people who are evaluating the technical aspects of systemd that there is a viable alternative to using it, the continued reference to the less-than-polite demeanor of many detractors isn't helping to further his point.
As well, many (most?) people associate "trolling" with "intentional griefing" and not "willful ignorance". I believe that many of the people arguing against systemd are either ill-informed or only considering their own use-cases, but I don't think it is appropriate to generalize them as trolls if their goal is something other than "to make people angry".
As well, many (most?) people associate "trolling" with "intentional griefing" and not "willful ignorance". I believe that many of the people arguing against systemd are either ill-informed or only considering their own use-cases, but I don't think it is appropriate to generalize them as trolls if their goal is something other than "to make people angry".
> Opponents of systemd have spread a LOT of FUD and misinformation about systemd
Well, obviously there's another, more charitable interpretation.
> I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Systemd is a continuously-varying project, and just because your distro smoothly switched, doesn't mean there were no problems for early adopters. Or that just because your configuration works, no difficulty with the multiple systemd components have, do or will arise.
Well, obviously there's another, more charitable interpretation.
> I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Systemd is a continuously-varying project, and just because your distro smoothly switched, doesn't mean there were no problems for early adopters. Or that just because your configuration works, no difficulty with the multiple systemd components have, do or will arise.
> systemd is a continuously-varying project, and just because your distro smoothly switched, doesn't mean there were no problems for early adopters, or that just because your configuration works, no difficulty with the multiple systemd components have, do or will arise.
Actually, I never claimed that my distro switched smoothly. Ironically, I literally commented just yesterday complaining that my distro (Arch) did not switch smoothly (and IMHO switched too early)[0]. I had a lot of issues when I first switched - I couldn't even boot my system, as a lot of stuff did not migrate cleanly.
Switching is always going to cause upheaval and breakage to at least some extent, and that's not what OP and I are referring to when talking about FUD.
What I'm talking about are people making factually incorrect (and worse, trivially verifiably incorrect) statements about systemd and what it does. Some of them are just blatantly wrong ("systemd forces you to use binary log files"[1], "systemd means you can't use init scripts"[2]), "systemd means you can't use crontab"[3], or my favorite "systemd gives QR code output"[4]). Others are technically true, but highly misleading ("I don't want everything to run in PID 1"[5], "systemd is the only way to run cgroups"[6])
There's a difference between disliking systemd on technical merit and disliking it based on false information that one hasn't even bothered to verify, and then vocally spreading that misinformation.
[0] https://news.ycombinator.com/item?id=8482950
[1] systemd by default does not use any log files (IIRC), and provides text logs as an alternative to the recommended binary default. You can keep using syslog just as always.
[2] systemd allows for init script compatibility. I won't claim that all init scripts will work without any modification, but it's not like you can't keep using init scripts instead of systemd configs if you don't want to
[3] systemd.timer is something you can use instead of crontab, but it will also run regular CRON jobs as well.
[4] systemd does have an option to display kernel dumps as QR codes. This feature is generally not compiled or available by default
[5] systemd includes some functionality that runs in PID 1, but most of what people actually are talking about does not run in PID 1
[6] systemd is the only way to run cgroups, because the Linux kernel requires that a single arbiter handle all cgroups, and systemd is (was?) the only program that has actually implemented the entire necessary ABI to do so. Anyone is free to write another program to handle cgroups instead of systemd.
Actually, I never claimed that my distro switched smoothly. Ironically, I literally commented just yesterday complaining that my distro (Arch) did not switch smoothly (and IMHO switched too early)[0]. I had a lot of issues when I first switched - I couldn't even boot my system, as a lot of stuff did not migrate cleanly.
Switching is always going to cause upheaval and breakage to at least some extent, and that's not what OP and I are referring to when talking about FUD.
What I'm talking about are people making factually incorrect (and worse, trivially verifiably incorrect) statements about systemd and what it does. Some of them are just blatantly wrong ("systemd forces you to use binary log files"[1], "systemd means you can't use init scripts"[2]), "systemd means you can't use crontab"[3], or my favorite "systemd gives QR code output"[4]). Others are technically true, but highly misleading ("I don't want everything to run in PID 1"[5], "systemd is the only way to run cgroups"[6])
There's a difference between disliking systemd on technical merit and disliking it based on false information that one hasn't even bothered to verify, and then vocally spreading that misinformation.
[0] https://news.ycombinator.com/item?id=8482950
[1] systemd by default does not use any log files (IIRC), and provides text logs as an alternative to the recommended binary default. You can keep using syslog just as always.
[2] systemd allows for init script compatibility. I won't claim that all init scripts will work without any modification, but it's not like you can't keep using init scripts instead of systemd configs if you don't want to
[3] systemd.timer is something you can use instead of crontab, but it will also run regular CRON jobs as well.
[4] systemd does have an option to display kernel dumps as QR codes. This feature is generally not compiled or available by default
[5] systemd includes some functionality that runs in PID 1, but most of what people actually are talking about does not run in PID 1
[6] systemd is the only way to run cgroups, because the Linux kernel requires that a single arbiter handle all cgroups, and systemd is (was?) the only program that has actually implemented the entire necessary ABI to do so. Anyone is free to write another program to handle cgroups instead of systemd.
Okay, I was saying, just because some people doesn't know, it doesn't have to be FUD, that'd be just an ad hominen attack. I've been a user of Arch back before systemd and I know your points are mostly right, but as you admit, in some cases you're true only technically, so don't attribute all errors to malice.
I think most people don't care how much of systemd is pid 1, there are components like udev that systemd is assimilating, we just want choice, I happen to like modern daemontools-like init systems a lot, but I use various init systems depending on what I want, and that's great IMO. However, read this:
Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.
The factually incorrect statements stem from such messages from lead developers, they've stated that in the future systemd will be sort of "merged" with linux, and that's no good. We know because we've been using great OSs and this is clearly a regression.
I think most people don't care how much of systemd is pid 1, there are components like udev that systemd is assimilating, we just want choice, I happen to like modern daemontools-like init systems a lot, but I use various init systems depending on what I want, and that's great IMO. However, read this:
Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.
The factually incorrect statements stem from such messages from lead developers, they've stated that in the future systemd will be sort of "merged" with linux, and that's no good. We know because we've been using great OSs and this is clearly a regression.
I really think he is thinking FUD (Fear Uncertainty and Doubt) equals trolls. Which is wrong.
"Don't listen to the FUD" # Fixes the first sentence
I can understand that feeling when ideas and chooses are not based on the same as your own. The whole Mono is evil was the definition of FUD to me and not based on the presented facts. To me the issue was mono and C# was a language that was already was a standard and that we had public confirmation that M$ would not do anything to anyone using mono. BUT I would be hard to call people who don't believe like me that SystemD is easier as a user or that Mono was a great choice of a language. I think society is based on what do we do to those who believe differently then ourselves.
"Don't listen to the FUD" # Fixes the first sentence
I can understand that feeling when ideas and chooses are not based on the same as your own. The whole Mono is evil was the definition of FUD to me and not based on the presented facts. To me the issue was mono and C# was a language that was already was a standard and that we had public confirmation that M$ would not do anything to anyone using mono. BUT I would be hard to call people who don't believe like me that SystemD is easier as a user or that Mono was a great choice of a language. I think society is based on what do we do to those who believe differently then ourselves.
'Troll' is basically now a useless word as it's been used to mean too many different things.
Yeah, this appears like a gross misuse of the world trolls
I thought the big concern is that it isn't hard yet.
it will only get "hard" if software projects bake in hard-dependencies to systemd, like the gnome project has (because they thought/think it provides a lot of benefits, and imho it does). Even so, there are plenty of shims being built that provide the small amount of api compatibility necessary to make things like gnome work on non-systemd systems (FreeBSD for example).
So, it is going to get hard, is what you are saying?
I mean, it could be that the shims are nice and easy, but it seems to be the expectation that this will not be the case, right? Especially since systemd seems to be on a very aggressive expansion of responsibilities campaign.
I mean, it could be that the shims are nice and easy, but it seems to be the expectation that this will not be the case, right? Especially since systemd seems to be on a very aggressive expansion of responsibilities campaign.
systemd is 69 individual components (and binaries) last time I checked. You can opt to build some, or all when you compile it. Yes they work together, but they have an open and now-more-or-less standardized api. So nothing prevents another developer from writing against the api, be it a shim to reduce/remove systemd but provide compatible calls into another system (init, logging, etc), or a complete replacement for a specific component of systemd.
I see it only getting easier actually. Folks in the BSD projects for example have their own init system but still want software like gnome, so shims are used to provide the api abstraction. This can be applied elsewhere in the Linux world as well. Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
I see it only getting easier actually. Folks in the BSD projects for example have their own init system but still want software like gnome, so shims are used to provide the api abstraction. This can be applied elsewhere in the Linux world as well. Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
> Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
I'd put good money on this getting harder and harder going forward though. At some point it will be everyone, or at least practically everyone, because every Linux distribution with any mindshare will have been using systemd for years, and hard-coding systemd will be not a lot different than hard-coding calls to the C standard library.
Also, shims? How god-awfully inelegant can we be? "You don't like systemd? Cool. You can run something else (as long as it looks, feels, and behaves exactly like systemd)."
Look, I'm not a religious zealot. Systemd is what they want me to run; systemd is what I'm running. I can live with ugly software. It's not the end of the world. But oh dear god is it ugly.
I'd put good money on this getting harder and harder going forward though. At some point it will be everyone, or at least practically everyone, because every Linux distribution with any mindshare will have been using systemd for years, and hard-coding systemd will be not a lot different than hard-coding calls to the C standard library.
Also, shims? How god-awfully inelegant can we be? "You don't like systemd? Cool. You can run something else (as long as it looks, feels, and behaves exactly like systemd)."
Look, I'm not a religious zealot. Systemd is what they want me to run; systemd is what I'm running. I can live with ugly software. It's not the end of the world. But oh dear god is it ugly.
I know the systemd developers are now planning on making udev depend on systemd in the near future, and that's pretty essential for desktop/server Linux.
Maybe not such a large hurdle though. udev was written by Kay mostly and he is on the systemd team. Before udev there was devfsd and hotplug[1], so it's feasible udev could be forked and/or an alternative introduced if it really becomes a burden for distros.
[1] http://en.wikipedia.org/wiki/Udev
[1] http://en.wikipedia.org/wiki/Udev
Udev is already forked, in the form of eudev. And Poettering is already having fun taunting them in systemd release notes, with lines like "This is your wakeup call".
Frankly i am reminded of the stuff we would see Jobs pull on stage. Like "Redmond, ready your copying machines"...
Frankly i am reminded of the stuff we would see Jobs pull on stage. Like "Redmond, ready your copying machines"...
> I thought the big concern is that it isn't hard yet.
And once it is a hard dependency then Red Hat will be in control of strategy for the dominant init system.
That's what concerns me, not the immediate technical challenges which can overcome. But those who are busy now patching the broken bits won't have influence over the direction of systemd in the future.
We'll all go where one billion-dollar enterprise-oriented vendor leads us.
And once it is a hard dependency then Red Hat will be in control of strategy for the dominant init system.
That's what concerns me, not the immediate technical challenges which can overcome. But those who are busy now patching the broken bits won't have influence over the direction of systemd in the future.
We'll all go where one billion-dollar enterprise-oriented vendor leads us.
This came to mind:
http://arstechnica.com/information-technology/2013/02/linus-...
The reason is that RH right now is deep in two camps, cloud and military/government contracts.
http://www.bizjournals.com/triangle/blog/techflash/2014/09/u...
and systemd has two parts as best i can tell.
One part is aimed at cloud via containers and sandboxes (soon to come to desktop as well via Gnome).
The other is aimed at securing "seats" via logind. This because the earlier consolekit had a limited reach because it didn't have a partner sitting as pid 1.
And the military is after all the origin of the concept "trusted computing".
I am not saying that there is a willed conspiracy. But with Red Hat being a for profit organization, anything that bring in the cash in the short run will be given priority...
http://arstechnica.com/information-technology/2013/02/linus-...
The reason is that RH right now is deep in two camps, cloud and military/government contracts.
http://www.bizjournals.com/triangle/blog/techflash/2014/09/u...
and systemd has two parts as best i can tell.
One part is aimed at cloud via containers and sandboxes (soon to come to desktop as well via Gnome).
The other is aimed at securing "seats" via logind. This because the earlier consolekit had a limited reach because it didn't have a partner sitting as pid 1.
And the military is after all the origin of the concept "trusted computing".
I am not saying that there is a willed conspiracy. But with Red Hat being a for profit organization, anything that bring in the cash in the short run will be given priority...
Thanks for the guide. Serious question, say I were to do a clean install of Jessie. I would use Xfce with either LightDM or no DM, or I might choose to set up a VPS that obviously won't even need Xorg. Is there a way during installation that I can skip installing systemd at all in that case, perhaps through a minimal install and then following up with adding the software I want? I don't like the idea of trying to purge systemd and its dependencies after a fresh install.
I am not sure about Jessie, but whenever Debian switches to Systemd as the default, I would guess even the minimal install would have it. Systemd is the init process, so you can't really just do without it (or some other init system at least). I think it will probably require somebody remixing the installer image to use a different init system.
Not sure though, I'm not super informed about what Debian is planning for the switch.
I think (no experience, but it makes sense) that Gentoo lets you pick the init system easily at install, you might want to look at that.
You might want to try it though. In my experience, the minimal config for systemd is quite lightweight and clean. I don't use KDE or Gnome, but I quite like systemd on my Arch workstation. Arch (and Fedora) have had it for quite a while now, even back when it was probably a bad idea to switch...
Not sure though, I'm not super informed about what Debian is planning for the switch.
I think (no experience, but it makes sense) that Gentoo lets you pick the init system easily at install, you might want to look at that.
You might want to try it though. In my experience, the minimal config for systemd is quite lightweight and clean. I don't use KDE or Gnome, but I quite like systemd on my Arch workstation. Arch (and Fedora) have had it for quite a while now, even back when it was probably a bad idea to switch...
The netinstall (not sure about the others) lets you choose exactly what packages you want during the installation, including init system, as far as I know.
Love to see a simple Linux dist that is base on xfce or some supper lightweight GUI as default but base on debian also.
Any good suggestion?
Any good suggestion?
Debian, then at the "task selection" stage choose nothing (definitely not desktop environment), later install xmonad and trayer and all that. Or you want xfce, OK install that. Oh and probably lightdm or xdm or some login manager, assuming you don't want to log in text and then startx or whatever other strategy.
Its not like Debian "requires" gnome or kde or whatever as part of the install. Just install what you want.
Its not like Debian "requires" gnome or kde or whatever as part of the install. Just install what you want.
i thought xfce required systemd-logind?
It just Recommends:libpam-systemd, its not a strict dependency. If I try to do an 'apt-get remove systemd systemd-shim' it doesn't show that it would remove XFCE.
I'm on KDE now though so I haven't checked how well xfce works without systemd.
KDE itself works quite well with systemd-shim.
apt-pinning (something that I have always thought is a bad practice) and using a shim. Honest question: isn't this just a giant hairy hack? Am I missing something?
Pinning? That's only a hack if you don't care to learn how apt works. And not actually necessary to avoid systemd unless you're running with `--assume-yes` or hammering 'y'.
systemd-shim? Well, yeah, but that's the entire point of it's existence.
systemd-shim? Well, yeah, but that's the entire point of it's existence.
apt pinning, like most systems administration software, is a bad thing if applied without forethought. while I withhold judgment on this particular application, apt pinning is a very useful feature when dealing with e.g. proprietary binary software with specific library version requirements, for instance.
[deleted]
They have fear of systemd becoming the mainstream init system. It's more easy for a project to become obsolete if we start to forget about it. Although sysvinit still has an chance to evolve.
not to mention all of the good things systemd actually provides.
I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc).
I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built).
Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.
I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc).
I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built).
Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.
As another article I read just today pointed out (in a completely different context), the point of Unix isn't the number or size of the tools. It's the composability of the tools.
systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence.
And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence.
And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
Serious question: in what ways would you want systemd commands to be composable? I'm struggling to think of a use case for being able to pipe a service name into systemctl (or "service" for that matter) and its output is reasonably grepable for running|failed etc (and more consistant the old SysV scripts)
I'm guessing you want more then that though right?
I'm guessing you want more then that though right?
Me personally? Not really. Like I said, I've been using it for a while and it's fine, but I also haven't tried to "stretch" it yet, so my experience doesn't really mean that much one way or the other. It's pretty simple to make something that works well most of the time. It's harder to do that in a way that still works well for the weird corner cases. Shell scripts sitting in a directory waiting to be kicked off by init are supremely flexible in that regard. I'm less confident in the future of systemd that this will still be the case. It's a lot harder to customize the way my Mac boots than it is to customize an old slackware install.
But mostly, like I said, it's just ugly. D-bus? Binary logs? Sure, you can build a working system like that, but just ugh.
But mostly, like I said, it's just ugly. D-bus? Binary logs? Sure, you can build a working system like that, but just ugh.
Conceptually composable. The logging in systemd sucks, sorry but true. Binary logs? LOL. Someday if rsyslog could speak raw systemd language as an input, that wouldn't be quite as awful. Then you could have systemd talking to a real logging platform. Just like "ls" can talk to "grep". Doesn't mean the talking can only be in the format of a pipe or whatever.
/etc/systemd/journald.conf
ForwardToSyslog=True
or
systemd.journald.forward_to_syslog=True on the kernel command line.
Is it just cool to not read documentation anymore?
ForwardToSyslog=True
or
systemd.journald.forward_to_syslog=True on the kernel command line.
Is it just cool to not read documentation anymore?
Journald is still there. So are libqrencode and libmicrohttpd and (possibly) the hook for the coredumps (that is now reverted in systemd 214 when - after almost 2 years from the first bug opened on the matter - they discovered that hard limiting a core dump to around 700MB using a #define and without respecting ulimit was not a good idea.[1]).
Systemd components are NOT interchangeable with something else, so let's stop pretending they are. Please.
[1] CentOS and RHEL 7 ship with an earlier version of systemd, and I'm not sure if the packages have been patched in some way or not to fix this. If not, good riddance if you are a sysadmin trying to pass core dumps along to developers.
Systemd components are NOT interchangeable with something else, so let's stop pretending they are. Please.
[1] CentOS and RHEL 7 ship with an earlier version of systemd, and I'm not sure if the packages have been patched in some way or not to fix this. If not, good riddance if you are a sysadmin trying to pass core dumps along to developers.
Thats not what I'm asking for.
Theoretically my configuration would look like rsyslog linking in a compatibility library and having something like this small config snippet from /etc/rsyslog/rsyslog.conf of the future:
# Connects rsyslog directly into the innards of systemd
$ModLoad systemd
I wouldn't even have journald installed on my system, at all. No config file named /etc/systemd/journald.conf, none of that. Just rsyslog.
That's like saying HN website is composable with emacs because I wrote this on emacs and then cut and pasted it into the browser. Really being composable would imply meta-x post-buffer-to-hacker-news direct API on emacs.
It doesn't really matter to me because systemd is going to force me to convert my systems to freebsd. But if I was staying on linux, I'd like systemd to at least minimally cooperate with the rest of the ecosystem instead of spreading like a cancer.
Theoretically my configuration would look like rsyslog linking in a compatibility library and having something like this small config snippet from /etc/rsyslog/rsyslog.conf of the future:
# Connects rsyslog directly into the innards of systemd
$ModLoad systemd
I wouldn't even have journald installed on my system, at all. No config file named /etc/systemd/journald.conf, none of that. Just rsyslog.
That's like saying HN website is composable with emacs because I wrote this on emacs and then cut and pasted it into the browser. Really being composable would imply meta-x post-buffer-to-hacker-news direct API on emacs.
It doesn't really matter to me because systemd is going to force me to convert my systems to freebsd. But if I was staying on linux, I'd like systemd to at least minimally cooperate with the rest of the ecosystem instead of spreading like a cancer.
To say that this is not fair would be an understatement. systemd-journald is only one component, there are more than 50!
[deleted]
In autofs (which has handled demand-based auto-mounting of network shares quite nicely for decades), you can write executable scripts to handle service discovery for different file-sharing protocols.
In ISC DHCP (I don't know if systemd is handling dhcp or not), you can add shell scripts as pre or post configuration hooks. I set up a cluster where the local hostname is set from DHCP/DNS, rather than vice versa.
In ISC DHCP (I don't know if systemd is handling dhcp or not), you can add shell scripts as pre or post configuration hooks. I set up a cluster where the local hostname is set from DHCP/DNS, rather than vice versa.
> "it's different and therefore I don't want it"
The argument is really that given that systemd as a project does a hell of a lot, it's actually really hard to replace bits of it - as people who are trying to are quickly finding out, there's a few dependency trees for various components which end up requiring that systemd manages most layers of the system. So you either use all of systemd, or as little of it as possible.
According to Lennart Poettering himself, udev is going to end up depending on systemd being the init system. udev! It'll be damn near impossible to replace systemd then. (And anybody who wants to use anything else, or even have the choice to use anything else, is a "systemd-hater".)
The argument is really that given that systemd as a project does a hell of a lot, it's actually really hard to replace bits of it - as people who are trying to are quickly finding out, there's a few dependency trees for various components which end up requiring that systemd manages most layers of the system. So you either use all of systemd, or as little of it as possible.
According to Lennart Poettering himself, udev is going to end up depending on systemd being the init system. udev! It'll be damn near impossible to replace systemd then. (And anybody who wants to use anything else, or even have the choice to use anything else, is a "systemd-hater".)
There are a lot of reasonable criticisms about the systemd family of utilities. I am very skeptical to the utility of binary logging for example. It makes an effort to guarantee integrity but does not make any guarantees and is useless in the face of an adversary.
I also have a suspicion there is a more friendly way do what PolicyKit provides, which is not at all very transparent to an administrator. You could easily trust software with privileges without realizing it. There are also concerns about the hard dependency on these utilities for GNOME, but I don't use it myself so I don't know if the concerns are valid or not.
I believe however most of the criticism centered on how udev was dropped as a separate utility, despite concerns from other developers, and the way people who tried to keep feature parity in a stand alone fork was treated. They was basically told they were regarded as downstream developers.
This is mostly water under the bridge now of course, but it makes cooperation a lot harder than it should be.
I also have a suspicion there is a more friendly way do what PolicyKit provides, which is not at all very transparent to an administrator. You could easily trust software with privileges without realizing it. There are also concerns about the hard dependency on these utilities for GNOME, but I don't use it myself so I don't know if the concerns are valid or not.
I believe however most of the criticism centered on how udev was dropped as a separate utility, despite concerns from other developers, and the way people who tried to keep feature parity in a stand alone fork was treated. They was basically told they were regarded as downstream developers.
This is mostly water under the bridge now of course, but it makes cooperation a lot harder than it should be.
journald's Forward Secure Sealing is an easy to use integrity mechanism that was previously unavailable in text-based syslog implementations... of course it cannot prevent your adversary from deleting all the logs, but at least that can be reliably detected.
http://lwn.net/Articles/512895/
And rsyslog can cryptographically sign logs too nowadays:
http://blog.gerhards.net/2013/05/rsyslogs-first-signature-pr...
http://lwn.net/Articles/512895/
And rsyslog can cryptographically sign logs too nowadays:
http://blog.gerhards.net/2013/05/rsyslogs-first-signature-pr...
> systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument).
That's not debunked. The small tools of the UNIX philosophy are supposed to compose well with others. If I want to replace systemd's init with that from daemontools (for instance) and keep the rest of systemd working, that should be possible.
Or let's suppose that I want to opt in to systemd's auto-remounting and socket activation (for instance), but for whatever reason I need to keep my syslogs as text on disc, so I can't use systemd's binary logs but need my legacy syslog system. Can I do that?
> I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it".
The arguments I've heard boil down to "it's badly designed and therefore I don't want it."
That's not debunked. The small tools of the UNIX philosophy are supposed to compose well with others. If I want to replace systemd's init with that from daemontools (for instance) and keep the rest of systemd working, that should be possible.
Or let's suppose that I want to opt in to systemd's auto-remounting and socket activation (for instance), but for whatever reason I need to keep my syslogs as text on disc, so I can't use systemd's binary logs but need my legacy syslog system. Can I do that?
> I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it".
The arguments I've heard boil down to "it's badly designed and therefore I don't want it."
yes you can
/etc/systemd/journald.conf ForwardToSyslog=True
/etc/systemd/journald.conf ForwardToSyslog=True
In a funny way, you've just proven my point. I'm talking about a whole class of problems caused by systemd's design, and you've provided a case-specific hack which happens to work in one instance I picked, leaving every other case where I might want to opt out of part of what systemd provides unsupported.
Have you ever noticed that it's really hard to replace the IP stack in Linux with the one from FreeBSD? Clearly that proves that Linux never followed the UNIX philosophy in the first place and we should never have switched away from MINIX.
systemd-journald is only one component, there are more than 50, and if you only want one piece of that, tough luck!
that seems unfair - on one hand, there are people complaining that systemd is too monolithic... on the other hand, we have people saying there are too many components !
Come on, this horse has been beaten to death already...
I'll just say, a GNU/Linux distro has many components, but they're not monolithic because they integrate well, you can do ls|grep etc, you know this. But if we want to change one component of systemd, we can't do it! You see? A lot of components, but they comprise a blob and can't be separated or used individually.
I'll just say, a GNU/Linux distro has many components, but they're not monolithic because they integrate well, you can do ls|grep etc, you know this. But if we want to change one component of systemd, we can't do it! You see? A lot of components, but they comprise a blob and can't be separated or used individually.
> I really don't get the systemd "hate" that is still floating around.
I found a message that might shed some light on it:
"[...] Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone without any noise?"
http://lists.freedesktop.org/archives/systemd-devel/2014-Oct... (read the whole message, it's quite interesting).
I found a message that might shed some light on it:
"[...] Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone without any noise?"
http://lists.freedesktop.org/archives/systemd-devel/2014-Oct... (read the whole message, it's quite interesting).
Systemd is great. I've used sockets for ssh, I use the timers instead of cron, everything goes smoothly and works really well.
I don't get the hate, I love it.
I don't get the hate, I love it.
> Although sysvinit still has an chance to evolve.
You'd probably have some of the same people complaining if you tried to "evolve" SysV.
I guess things are pretty good right now in the Linux world if this is the thing to argue over.
You'd probably have some of the same people complaining if you tried to "evolve" SysV.
I guess things are pretty good right now in the Linux world if this is the thing to argue over.
Depends on how it was to evolve.
Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already.
socket based service start, (hardware) event based, pass.
Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart).
The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc.
This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code.
you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually).
Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.
Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already.
socket based service start, (hardware) event based, pass.
Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart).
The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc.
This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code.
you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually).
Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.
Well... In fact it's alredy happening with the init wars
Not really, remember daemontools? There are almost a hundred init systems very superior technically compared to sysv and systemd, the truth is that sysv has NEVER been considered the best.
[deleted]
On a purely technical perspective (I don't care about people not getting along), what is reproached to systemd ?
another pro-systemd post. there's been two of them today, the other being the uselessd blog post. What's with this community rushing to defend themselves? doesn't this smell like astroturfing to anyone else?
[deleted](2)
In the future? Yeah, probably.
This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. Really, I think all of the reasons why systemd attracts hate can be boiled down to this. Nobody wants a standard init system that's overtly hostile to bug reports and reasonable changes.
Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...