8 ms·

> systemd people are not willing to play nice with the rest of the world. Can we get a bit a of context on that?

by tym0 11y ago

runarb 11y ago
There is some controversy about Systemd and Lennart Poettering, one of the main developers. Wikipedia have more info: * https://en.wikipedia.org/wiki/Systemd#History_and_controversy https://en.wikipedia.org/wiki/Systemd#History_and_controvers... * https://en.wikipedia.org/wiki/Lennart_Poettering#Controversies https://en.wikipedia.org/wiki/Lennart_Poettering#Controversi...
- MichaelGG 11y ago
  What I don't get is, if systemd is so troublesome, why are so many distros picking it up? I know popularity isn't a perfect signal, but in this case of highly technical users that are distributing OSes it seems valid.
  - _cudgel 11y ago
    I'd also like an answer to this question, as well as an answer to the question of what, in exacting detail please, was so wrong with the previous system it needed to be torn out and replaced? I definitely tend toward the curmudgeonly, but to this grumpy old man, it seems like we're replacing things simply for the sake of change.
    - vezzy-fnord 11y ago
      Nah, the old system did need replacing [1], and plenty of them were in fact done. [2] Evidently they went understudied, though. [1] http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy... [2] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
      - _cudgel 11y ago
        Thanks -- this is exactly the sort of follow-up I was hoping for!
      - bigbugbag 11y ago
        it did, but systemd is not the silver bullet that will fix it. "It's often said that a half-truth is worse than a lie. In the case of systemd, a half-improvement is worse than a complete flop. People are focusing on the features they want to use and ignoring the ones that will come back to bite them later. No, my biggest problem with systemd is that it is repeating the mistakes of System V all over again. It's just given them a change of clothes to appeal to the 21st century." rest the rest at: http://www.steven-mcdonald.id.au/articles/systemd.shtml http://www.steven-mcdonald.id.au/articles/systemd.shtml for the debunking of the necessity of having journald see http://lpar.ath0.com/2014/05/18/why-i-dont-like-systemd/ http://lpar.ath0.com/2014/05/18/why-i-dont-like-systemd/
        vezzy-fnord 11y ago
        I wrote the first full scale technical critique of systemd, so you don't have to tell me all that. I've read the articles, btw.
        bigbugbag 11y ago
        Sorry if I have bothered you, I wasn't replying directly to you but was actually aiming at adding a complement to your answer.
      - digi_owl 11y ago
        At this point in time though i wonder if focusing on the init part is missing the forest for the trees. I think just as much of a stink comes with how you need to have systemd-the-init to use systemd-logind (replacing consolekit for session tracking) or any number of other possibly interesting, but tied to the hip of systemd, sub-projects.
  - sulami 11y ago
    I'm just guessing here, but systemd makes some things more convinient by being overall more monolithic, like Windows, and especially distros that are targeting a less technical crowd want to be able to compete with Windows in terms of features and usability. Non-technical people most likely don't see any of the beauty of a strictly modular system or proper clean code. And this is not about the init-daemon, it is about systemd as a whole integrated suite of daemons that connect easily and add fancy new features, while on the other side you might have to modify two completely independent software projects to add a new feature that uses both, and even then there most likely are alternatives to each one, and you feature will only work with this specific combination. So a more monolithic system, which systemd is despite Lennard denying this, makes development faster, but will bite you in the long run, especially when the code and documentation quality is as poor as systemd's.
    - mgbmtl 11y ago
      I'm more tempted to say that systemd does well what previously you needed a dozen half-broken tools to implement. For example, isolating the /tmp of an application, monitoring the process and restarting if necessary, more logging options (and imho cleaner/more efficient). Then again, all this has been debated over and over again. In practice, people are adopting it. Haters are noisy. It's like reading about debates on IPv6 migration strategies.
      - vezzy-fnord 11y ago
        Process supervisors with reliable logging are nearly two decades old at this point. Isolating /tmp is then a namespacing feature, which in a system where execution state is composed as an explicit external manifest via chain loading (as opposed to serializing from a unit file into a private ExecContext structure, as with systemd) should be completely orthogonal to any one service manager. Else it is inflexible if it needs complex internal scaffolding. (Actually I think supervision goes back to IBM's SRC in at least 1992, but I'm not exactly sure if the earliest versions had anything beyond process management.)
        XorNot 11y ago
  - rincebrain 11y ago
    Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.
    - MichaelGG 11y ago
      So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.
      - vezzy-fnord 11y ago
        Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community. As such, RH decisions with significant influence definitely would impact them. Ubuntu, in turn, is symbiotic with Debian, though still quite forked from it in most aspects beyond the packaging infrastructure (now with Snappy diverging even further). Nonetheless, Unity needs GNOME and Canonical are still a small player who are perfectly capable of foreseeing future trends. Adopting systemd is the path of least resistance and will help them track Debian's packages better. Most RPM-based distros (openSUSE included) tend to follow RH's direction, so that's not surprising. Besides, SUSE has always been enthusiastic about most desktop efforts. Arch Linux have at least two systemd developers on their team (Tom Gundersen and Dave Reisner). In fact, it was tomegun who wrote the Arch migration rationale: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530, based on the usual fallacious arguments (http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...). Also, distros have blindly went along with other bad ideas before. The most prominent examples were HALd and LSB-style initscripts. In fact, I'm not sure why you're at all surprised. Large groups of people in real life have collectively made far, far more catastrophic decisions. Why would a bunch of distribution maintainers adopting a piece of software be so shocking?
  - bigbugbag 11y ago
    Well that's a good question, I'd like to have an answer to that. debian adoption of systemd was a bumpy ride to say the least, it caused a few long time contributors to resign and others to fork debian to remove systemd in a new distro called devuan. Then again systemd gobbled other critical components such as udev, there's also gnome that made it a strict requirement, like a cancer it grows and takes over other components.
    - XorNot 11y ago
      Devuan is someone's extended tantrum and little more. Like every other rage-fork it'll die a slow death because who wants to develop on a platform founded on the premise of "why do we need to change anything? It's all working fine!"
      - vezzy-fnord 11y ago
        And yet: https://git.devuan.org/explore https://git.devuan.org/explore They began work on a logind compatibility layer over ConsoleKit2, they're writing a NetworkManager alternative, they directly influenced and are supporting a udev alternative called vdev (which also has libudev compatibility), and a host of other things. For a rage-fork, it's pretty impressive. They're changing a lot. It's easier to just astroturf in the corner, though, I suppose.
        simoncion 11y ago
        > ...they directly influenced and are supporting a udev alternative called vdev... Have you a notion as to why they're using vdev rather than eudev? What appears to be the vdev introductory blog post makes no mention of eudev.
        digi_owl 11y ago
        Possibly because vdev is a clean break, while eudev is still mostly about udev stripped from systemd. And that stripping will be more complicated moving forward, as i recall a recent systemd release moved various bits from udev to a new systemd lib. Leaving the udev interfaces as stubs to be removed at some undetermined future date.
  - meddlepal 11y ago
    It's actually a pretty good system and IMO way better than previous attempts at init systems throughout Linux history.
    - vezzy-fnord 11y ago
      Considering there's been ~15 of them, I doubt anyone has ever evaluated them comprehensively except post facto in light of the systemd integration.
      - digi_owl 11y ago
        Yeah the most documented such evaluation, the Debian process, seemed to only evaluate sysv, upstart and systemd (openrc was briefly mentioned but quickly dismissed). The rest seems to have been executive decisions (with or without a "deal with it" meme accompanying), often by people already involved with systemd development.
    - brazzledazzle 11y ago
      I haven't evaluated all of the previous attempts since that would consume more time than I have available. Can you provide a comparison or some insights into why they're worse?
      - meddlepal 11y ago
        I can't comment on all of them, but I've dealt with a bunch. I'm out enjoying Halloween right now but if I remember on the morning I'll follow up.
        brazzledazzle 11y ago
        If you get time that would be neat, I'm sure others would appreciate it too. I've heard good things about djb's daemontools from a few friends and colleagues but never had the chance to try it and if you have any insight on that one I'd really appreciate that.
semi-extrinsic 11y ago
After they repurposed the "debug" kernel flag and made it literally unusable with systemd, Linus banned one of their core devs (Kay Sievers) from contributing to the Linux kernel, and I quote: "I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project." https://lkml.org/lkml/2014/4/2/420 https://lkml.org/lkml/2014/4/2/420
- magila 11y ago
  It's worth noting that this is a case of Linus flying off the handle based on incomplete information. It was latter revealed that the bug which caused this whole spat on LKML had already been fixed in systemd, Kay Sievers just failed to communicate that in the bug opened by Borislav Petkov.
  - felixgallo 11y ago
    that is not at all what happened. Here's Kay Sievers, defiantly posting after in his own words after the incident: https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB
    - magila 11y ago
      There were two different issues at play: 1. A system hang due an assertion in journald spamming kmsg. 2. The question of whether systemd should be logging to kmsg or doing anything based on the "debug" kernel command line argument. Linus got pissed because, based on Steven Rostedt's post to LKML and the referenced bug report, it looked like Kay was refusing to fix issue #1, but that bug had already been addressed and a fix committed to systemd. In the aftermath there was also a flamewar over issue #2, which is what Lennart is responding to in that G+ post.
      - digi_owl 11y ago
        Note that going by the Torvalds email, this is far from the first time him and Sievers has been at odds.
GFK_of_xmaspast 11y ago
It's fashionable in some parts of the linux world to hate on systemd.
- xyproto 11y ago
  After Arch Linux, Debian, Fedora, Red Hat and CentOS switched over to systemd, it must be a very tiny part of the Linux world.
  - SquareWheel 11y ago
    I don't think so, as every time I see systemd mentioned in a headline - the comments are filled with arguments over its use.
  - bigbugbag 11y ago
    Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon. Debian got forked into devuan which is debian minus systemd. As systemd originated from redhat it is expected that the other faces of redhat namely fedora and centos would also feature systemd. Then there is slackware, gentoo, pclinuxos that either did not bit the systemd bullet or offer alternative option. Not sure about ubuntu.
    - digi_owl 11y ago
      Err, Distrowatch claim that Manjaro use systemd...
      - bigbugbag 11y ago
        please read archlinux systemd-free website[1]. [1]: http://systemd-free.org/ http://systemd-free.org/
    - steanne 11y ago
      "Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon." ...well, kinda: manjaro supports openrc, but the official, main installs are systemd. you can start with an official install and convert it, or you can use an openrc iso, but those are not officially supported.
bigbugbag 11y ago
there was extensive documentation on www.boycottsystemd.org but it seems to have been taken offline and there's no trace in the internet archive.
bsder 11y ago
People have been trying to fix the boot process in linux for years. Like most things, everybody screams when something changes, but nobody is willing to put in the work to make something better. RedHat had enough, and finally jammed systemd down on the Linux ecosystem. This had two effects: 1) Technical: it exposed a LOT of shortcomings in the architecture of Linux for operating on modern systems. The whole "This belongs in PID 1! No it doesn't!" stems from there not being good, correct, and obvious ways of accomplishing the tasks that need to be done. 2) Political: it pissed off everybody from Linus down who actually thought they had power and control by demonstrating forcibly that their opinions don't really matter. As for the technical issues, I'm not terribly sympathetic. Somebody needed to fix this, and it was painfully clear that nobody was ever going to get consensus on this. In addition, Linus blocks a LOT of stuff attempting to evolve the kernel in directions that are improvements, but that he does like or doesn't understand. For example, Linus didn't handle the ARM board issues very proactively. He basically ignored things until they got untenable and then finally blew up at the ARM guys and threatened to rip them out of the kernel. People had tried several times to get a modular configuration system put in place, but Linus never wanted to commit it as there "wasn't consensus". True, but once his pants caught on fire, he didn't give a shit about consensus anymore. As for political issues, I have even less sympathy, as RedHat simply did what Linus has been doing for years and imposed their will on the ecosystem by force. Enlightened dictatorship is a wonderful governmental mode, until you're no longer the dictator. Perhaps if Linus had figured out how to actually build consensus, I would find his words less hypocritical and more deserving of consideration. The BSD's are no strangers to controversy. The whole existence of OpenBSD and NetBSD is a tribute to that. Even with FreeBSD, the GEOM subsystem changeover caused great friction. The difference is that Poul-Henning Kamp did the work and got a signficant level of consensus from the BSD leadership--but by no means unanimous and it was sometimes acrimonious.
- simondedalus 11y ago
  I don't want to argue about systemd vs this or that, but re: (2) you are totally misrepresenting linus's objection to systemd (developers). the well-publicized incident to which you're referring had systemd introduce something that broke userland, then instead of fixing it in systemd code, proposed a kernel change for it. this is, obviously, bad practice. it would be one thing if the systemd code exposed a vulnerability or inefficiency in the linux kernel. but fixing your bad code by modifying the kernel is like trying to modify a popular compiler because some bad code you wrote isn't doing what you want it to.

> systemd people are not willing to play nice with the rest of the world. Can we get a bit a of context on that?

by tym0 11y ago

> systemd people are not willing to play nice with the rest of the world. Can we get a bit a of context on that?

There is some controversy about Systemd and Lennart Poettering, one of the main developers. Wikipedia have more info: * https://en.wikipedia.org/wiki/Systemd#History_and_controversy https://en.wikipedia.org/wiki/Systemd#History_and_controvers... * https://en.wikipedia.org/wiki/Lennart_Poettering#Controversies https://en.wikipedia.org/wiki/Lennart_Poettering#Controversi...

MichaelGG 11y ago
What I don't get is, if systemd is so troublesome, why are so many distros picking it up? I know popularity isn't a perfect signal, but in this case of highly technical users that are distributing OSes it seems valid.
- _cudgel 11y ago
  I'd also like an answer to this question, as well as an answer to the question of what, in exacting detail please, was so wrong with the previous system it needed to be torn out and replaced? I definitely tend toward the curmudgeonly, but to this grumpy old man, it seems like we're replacing things simply for the sake of change.
  - vezzy-fnord 11y ago
    Nah, the old system did need replacing [1], and plenty of them were in fact done. [2] Evidently they went understudied, though. [1] http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/system-5-rc-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy... [2] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
    - _cudgel 11y ago
      Thanks -- this is exactly the sort of follow-up I was hoping for!
    - bigbugbag 11y ago
      it did, but systemd is not the silver bullet that will fix it. "It's often said that a half-truth is worse than a lie. In the case of systemd, a half-improvement is worse than a complete flop. People are focusing on the features they want to use and ignoring the ones that will come back to bite them later. No, my biggest problem with systemd is that it is repeating the mistakes of System V all over again. It's just given them a change of clothes to appeal to the 21st century." rest the rest at: http://www.steven-mcdonald.id.au/articles/systemd.shtml http://www.steven-mcdonald.id.au/articles/systemd.shtml for the debunking of the necessity of having journald see http://lpar.ath0.com/2014/05/18/why-i-dont-like-systemd/ http://lpar.ath0.com/2014/05/18/why-i-dont-like-systemd/
      - vezzy-fnord 11y ago
        I wrote the first full scale technical critique of systemd, so you don't have to tell me all that. I've read the articles, btw.
        bigbugbag 11y ago
        Sorry if I have bothered you, I wasn't replying directly to you but was actually aiming at adding a complement to your answer.
    - digi_owl 11y ago
      At this point in time though i wonder if focusing on the init part is missing the forest for the trees. I think just as much of a stink comes with how you need to have systemd-the-init to use systemd-logind (replacing consolekit for session tracking) or any number of other possibly interesting, but tied to the hip of systemd, sub-projects.
- sulami 11y ago
  I'm just guessing here, but systemd makes some things more convinient by being overall more monolithic, like Windows, and especially distros that are targeting a less technical crowd want to be able to compete with Windows in terms of features and usability. Non-technical people most likely don't see any of the beauty of a strictly modular system or proper clean code. And this is not about the init-daemon, it is about systemd as a whole integrated suite of daemons that connect easily and add fancy new features, while on the other side you might have to modify two completely independent software projects to add a new feature that uses both, and even then there most likely are alternatives to each one, and you feature will only work with this specific combination. So a more monolithic system, which systemd is despite Lennard denying this, makes development faster, but will bite you in the long run, especially when the code and documentation quality is as poor as systemd's.
  - mgbmtl 11y ago
    I'm more tempted to say that systemd does well what previously you needed a dozen half-broken tools to implement. For example, isolating the /tmp of an application, monitoring the process and restarting if necessary, more logging options (and imho cleaner/more efficient). Then again, all this has been debated over and over again. In practice, people are adopting it. Haters are noisy. It's like reading about debates on IPv6 migration strategies.
    - vezzy-fnord 11y ago
      Process supervisors with reliable logging are nearly two decades old at this point. Isolating /tmp is then a namespacing feature, which in a system where execution state is composed as an explicit external manifest via chain loading (as opposed to serializing from a unit file into a private ExecContext structure, as with systemd) should be completely orthogonal to any one service manager. Else it is inflexible if it needs complex internal scaffolding. (Actually I think supervision goes back to IBM's SRC in at least 1992, but I'm not exactly sure if the earliest versions had anything beyond process management.)
      - XorNot 11y ago
- rincebrain 11y ago
  Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.
  - MichaelGG 11y ago
    So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.
    - vezzy-fnord 11y ago
      Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community. As such, RH decisions with significant influence definitely would impact them. Ubuntu, in turn, is symbiotic with Debian, though still quite forked from it in most aspects beyond the packaging infrastructure (now with Snappy diverging even further). Nonetheless, Unity needs GNOME and Canonical are still a small player who are perfectly capable of foreseeing future trends. Adopting systemd is the path of least resistance and will help them track Debian's packages better. Most RPM-based distros (openSUSE included) tend to follow RH's direction, so that's not surprising. Besides, SUSE has always been enthusiastic about most desktop efforts. Arch Linux have at least two systemd developers on their team (Tom Gundersen and Dave Reisner). In fact, it was tomegun who wrote the Arch migration rationale: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530, based on the usual fallacious arguments (http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...). Also, distros have blindly went along with other bad ideas before. The most prominent examples were HALd and LSB-style initscripts. In fact, I'm not sure why you're at all surprised. Large groups of people in real life have collectively made far, far more catastrophic decisions. Why would a bunch of distribution maintainers adopting a piece of software be so shocking?
- bigbugbag 11y ago
  Well that's a good question, I'd like to have an answer to that. debian adoption of systemd was a bumpy ride to say the least, it caused a few long time contributors to resign and others to fork debian to remove systemd in a new distro called devuan. Then again systemd gobbled other critical components such as udev, there's also gnome that made it a strict requirement, like a cancer it grows and takes over other components.
  - XorNot 11y ago
    Devuan is someone's extended tantrum and little more. Like every other rage-fork it'll die a slow death because who wants to develop on a platform founded on the premise of "why do we need to change anything? It's all working fine!"
    - vezzy-fnord 11y ago
      And yet: https://git.devuan.org/explore https://git.devuan.org/explore They began work on a logind compatibility layer over ConsoleKit2, they're writing a NetworkManager alternative, they directly influenced and are supporting a udev alternative called vdev (which also has libudev compatibility), and a host of other things. For a rage-fork, it's pretty impressive. They're changing a lot. It's easier to just astroturf in the corner, though, I suppose.
      - simoncion 11y ago
        > ...they directly influenced and are supporting a udev alternative called vdev... Have you a notion as to why they're using vdev rather than eudev? What appears to be the vdev introductory blog post makes no mention of eudev.
        digi_owl 11y ago
        Possibly because vdev is a clean break, while eudev is still mostly about udev stripped from systemd. And that stripping will be more complicated moving forward, as i recall a recent systemd release moved various bits from udev to a new systemd lib. Leaving the udev interfaces as stubs to be removed at some undetermined future date.
- meddlepal 11y ago
  It's actually a pretty good system and IMO way better than previous attempts at init systems throughout Linux history.
  - vezzy-fnord 11y ago
    Considering there's been ~15 of them, I doubt anyone has ever evaluated them comprehensively except post facto in light of the systemd integration.
    - digi_owl 11y ago
      Yeah the most documented such evaluation, the Debian process, seemed to only evaluate sysv, upstart and systemd (openrc was briefly mentioned but quickly dismissed). The rest seems to have been executive decisions (with or without a "deal with it" meme accompanying), often by people already involved with systemd development.
  - brazzledazzle 11y ago
    I haven't evaluated all of the previous attempts since that would consume more time than I have available. Can you provide a comparison or some insights into why they're worse?
    - meddlepal 11y ago
      I can't comment on all of them, but I've dealt with a bunch. I'm out enjoying Halloween right now but if I remember on the morning I'll follow up.
      - brazzledazzle 11y ago
        If you get time that would be neat, I'm sure others would appreciate it too. I've heard good things about djb's daemontools from a few friends and colleagues but never had the chance to try it and if you have any insight on that one I'd really appreciate that.

semi-extrinsic 11y ago

After they repurposed the "debug" kernel flag and made it literally unusable with systemd, Linus banned one of their core devs (Kay Sievers) from contributing to the Linux kernel, and I quote: "I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project." https://lkml.org/lkml/2014/4/2/420 https://lkml.org/lkml/2014/4/2/420

magila 11y ago
It's worth noting that this is a case of Linus flying off the handle based on incomplete information. It was latter revealed that the bug which caused this whole spat on LKML had already been fixed in systemd, Kay Sievers just failed to communicate that in the bug opened by Borislav Petkov.
- felixgallo 11y ago
  that is not at all what happened. Here's Kay Sievers, defiantly posting after in his own words after the incident: https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB
  - magila 11y ago
    There were two different issues at play: 1. A system hang due an assertion in journald spamming kmsg. 2. The question of whether systemd should be logging to kmsg or doing anything based on the "debug" kernel command line argument. Linus got pissed because, based on Steven Rostedt's post to LKML and the referenced bug report, it looked like Kay was refusing to fix issue #1, but that bug had already been addressed and a fix committed to systemd. In the aftermath there was also a flamewar over issue #2, which is what Lennart is responding to in that G+ post.
    - digi_owl 11y ago
      Note that going by the Torvalds email, this is far from the first time him and Sievers has been at odds.

GFK_of_xmaspast 11y ago

It's fashionable in some parts of the linux world to hate on systemd.

xyproto 11y ago
After Arch Linux, Debian, Fedora, Red Hat and CentOS switched over to systemd, it must be a very tiny part of the Linux world.
- SquareWheel 11y ago
  I don't think so, as every time I see systemd mentioned in a headline - the comments are filled with arguments over its use.
- bigbugbag 11y ago
  Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon. Debian got forked into devuan which is debian minus systemd. As systemd originated from redhat it is expected that the other faces of redhat namely fedora and centos would also feature systemd. Then there is slackware, gentoo, pclinuxos that either did not bit the systemd bullet or offer alternative option. Not sure about ubuntu.
  - digi_owl 11y ago
    Err, Distrowatch claim that Manjaro use systemd...
    - bigbugbag 11y ago
      please read archlinux systemd-free website[1]. [1]: http://systemd-free.org/ http://systemd-free.org/
  - steanne 11y ago
    "Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon." ...well, kinda: manjaro supports openrc, but the official, main installs are systemd. you can start with an official install and convert it, or you can use an openrc iso, but those are not officially supported.

bigbugbag 11y ago

there was extensive documentation on www.boycottsystemd.org but it seems to have been taken offline and there's no trace in the internet archive.

bsder 11y ago

People have been trying to fix the boot process in linux for years. Like most things, everybody screams when something changes, but nobody is willing to put in the work to make something better. RedHat had enough, and finally jammed systemd down on the Linux ecosystem. This had two effects: 1) Technical: it exposed a LOT of shortcomings in the architecture of Linux for operating on modern systems. The whole "This belongs in PID 1! No it doesn't!" stems from there not being good, correct, and obvious ways of accomplishing the tasks that need to be done. 2) Political: it pissed off everybody from Linus down who actually thought they had power and control by demonstrating forcibly that their opinions don't really matter. As for the technical issues, I'm not terribly sympathetic. Somebody needed to fix this, and it was painfully clear that nobody was ever going to get consensus on this. In addition, Linus blocks a LOT of stuff attempting to evolve the kernel in directions that are improvements, but that he does like or doesn't understand. For example, Linus didn't handle the ARM board issues very proactively. He basically ignored things until they got untenable and then finally blew up at the ARM guys and threatened to rip them out of the kernel. People had tried several times to get a modular configuration system put in place, but Linus never wanted to commit it as there "wasn't consensus". True, but once his pants caught on fire, he didn't give a shit about consensus anymore. As for political issues, I have even less sympathy, as RedHat simply did what Linus has been doing for years and imposed their will on the ecosystem by force. Enlightened dictatorship is a wonderful governmental mode, until you're no longer the dictator. Perhaps if Linus had figured out how to actually build consensus, I would find his words less hypocritical and more deserving of consideration. The BSD's are no strangers to controversy. The whole existence of OpenBSD and NetBSD is a tribute to that. Even with FreeBSD, the GEOM subsystem changeover caused great friction. The difference is that Poul-Henning Kamp did the work and got a signficant level of consensus from the BSD leadership--but by no means unanimous and it was sometimes acrimonious.

simondedalus 11y ago
I don't want to argue about systemd vs this or that, but re: (2) you are totally misrepresenting linus's objection to systemd (developers). the well-publicized incident to which you're referring had systemd introduce something that broke userland, then instead of fixing it in systemd code, proposed a kernel change for it. this is, obviously, bad practice. it would be one thing if the systemd code exposed a vulnerability or inefficiency in the linux kernel. but fixing your bad code by modifying the kernel is like trying to modify a popular compiler because some bad code you wrote isn't doing what you want it to.