4 ms·

Red Hat isn't responsible for systemd, Poettering started it and was later hired by Red Hat, which at some point adopted systemd. Red Hat doesn't have the power

by DasIch 10y ago

Red Hat isn't responsible for systemd, Poettering started it and was later hired by Red Hat, which at some point adopted systemd. Red Hat doesn't have the power to force distributions to use systemd or to make other projects depend on it.

kbenson 10y ago
> Poettering started it and was later hired by Red Hat, which at some point adopted systemd. Almost right. He worked at Red Hat already, but Red Hat wasn't interested in his ideas for a new init system (they were moving to Upstart, which is used in RHEL 6), so he decided to work on it on his own time, and Red Hat eventually decided there were problems that needed to be fixed with init, and adopted it[1]. I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...) > Red Hat doesn't have the power to force distributions to use systemd or to make other projects depend on it. Exactly. Systemd was adopted by many distros because they thought it was the best choice. There's no way for Red Hat to to force it on other distros, and of things that might be susceptible to market forces in Linux, I wouldn't count the init system as one. Almost all software will only interface with it through a startup mechanism, if even that, and that's generally minuscule compared to the rest of the software development. It's likely smaller than the distro specific packaging config in the vast majority of cases too. I'm not sure where this myth started, but I don't think I've heard it put forth from anyone that has a clue about how the distributions operate. It's interesting that it's so pervasive. 1: https://www.linuxvoice.com/interview-lennart-poettering/ https://www.linuxvoice.com/interview-lennart-poettering/
- DasIch 10y ago
  > I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...) People complain about Poettering because he's Poettering and about his projects because they are his projects. It's very rare that I see anyone providing any valid criticism, that is not some Red Hat conspiracy bullshit, the Unix philosophy "This is the way it's always been and that's by definition perfect" argument or the portability (read: I don't want obscure-OS-that-nobody-cares-about-or-invests-any-resources-in left behind so please don't take advantage of innovation in the kernel) argument. What should be controversial is how incredibly shitty and unfairly Poettering is treated by the community.
  - kbenson 10y ago
    Indeed. The way everyone was ready to assume the worst interpretation of his words in the evivarfs fiasco[1][2] was telling. 1: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 2: https://news.ycombinator.com/item?id=11152880 https://news.ycombinator.com/item?id=11152880
- badsock 10y ago
  There's pressure for distros to adopt the Red Hat's init system, regardless of its quality, for compatibility purposes. For example when Gnome 3, which has significant ties to Red Hat, started depending on systemd, other distros had to a) switch to systemd, b) use a shim, or c) follow a forked version of Gnome. B and c are a lot of slogging work that they'd rather not do, so it's a pretty strong argument to fall in line with what Red Hat wants; especially when it's likely that the projects that did what Gnome did will continue to increase in number, and that systemd is difficult to maintain compatibility with, and becoming more so.
  - kbenson 10y ago
    That pressure is not from Red Hat. That pressure is from projects that see a benefit to using systemd, and so then do so. Gnome wanted better power management and session tracking. So did KDE. Systemd offered that, so instead of having to maintain their own code paths to do that, which may or may not work as well, they can offload that task to systemd. Really, what the GUIs care about appears to be mostly handled in logind, and there are various projects in the works (available?) to provide that bit of functionality.
    - digi_owl 10y ago
      Err, things like upower existed as independent projects before systemd. But now upower is just a wrapper around systemd-logind (of all things).
      - kbenson 10y ago
        Okay, I just looked into this. upower used pm-utils upstream. According to upower devs, pm-utils was a dead project, so they switched to what was working, systemd[1]. I'm not sure specifically why pm-utils was discontinued, but given that the page says it's stuff for HAL, and other things I found in my search note that HAL was being discontinued, I think that's likely a reason. Note: pm-utils looks to have not been actively developed since at least late 2012. That's as far as I went back in the mailing list archives to find something indicative of that[2]. The last release was in July 2010. I can see why projects that relied on it wanted to migrate to something better, or at least maintained. Also note that pm-utils was a collections of shell scripts that ran different commands, such as mount, etc, and echo'd values into the proc filesystem. That may have also influenced decisions one way or another. 1: https://lists.freedesktop.org/archives/devkit-devel/2015-December/001748.html https://lists.freedesktop.org/archives/devkit-devel/2015-Dec... (upower was previously called DeviceKit, according to their site, which is why it's the devkit-devel mailing list). 2: https://lists.freedesktop.org/archives/pm-utils/2012-March/002249.html https://lists.freedesktop.org/archives/pm-utils/2012-March/0...

by DasIch 10y ago

kbenson 10y ago

> Poettering started it and was later hired by Red Hat, which at some point adopted systemd. Almost right. He worked at Red Hat already, but Red Hat wasn't interested in his ideas for a new init system (they were moving to Upstart, which is used in RHEL 6), so he decided to work on it on his own time, and Red Hat eventually decided there were problems that needed to be fixed with init, and adopted it[1]. I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...) > Red Hat doesn't have the power to force distributions to use systemd or to make other projects depend on it. Exactly. Systemd was adopted by many distros because they thought it was the best choice. There's no way for Red Hat to to force it on other distros, and of things that might be susceptible to market forces in Linux, I wouldn't count the init system as one. Almost all software will only interface with it through a startup mechanism, if even that, and that's generally minuscule compared to the rest of the software development. It's likely smaller than the distro specific packaging config in the vast majority of cases too. I'm not sure where this myth started, but I don't think I've heard it put forth from anyone that has a clue about how the distributions operate. It's interesting that it's so pervasive. 1: https://www.linuxvoice.com/interview-lennart-poettering/ https://www.linuxvoice.com/interview-lennart-poettering/

DasIch 10y ago
> I can't find a hire date for Poettering, but it's possible what you are thinking of is PulseAudio which was started in 2004, and was also controversial in the beginning (there's a trend here with Poettering...) People complain about Poettering because he's Poettering and about his projects because they are his projects. It's very rare that I see anyone providing any valid criticism, that is not some Red Hat conspiracy bullshit, the Unix philosophy "This is the way it's always been and that's by definition perfect" argument or the portability (read: I don't want obscure-OS-that-nobody-cares-about-or-invests-any-resources-in left behind so please don't take advantage of innovation in the kernel) argument. What should be controversial is how incredibly shitty and unfairly Poettering is treated by the community.
- kbenson 10y ago
  Indeed. The way everyone was ready to assume the worst interpretation of his words in the evivarfs fiasco[1][2] was telling. 1: https://news.ycombinator.com/item?id=10999335 https://news.ycombinator.com/item?id=10999335 2: https://news.ycombinator.com/item?id=11152880 https://news.ycombinator.com/item?id=11152880
badsock 10y ago
There's pressure for distros to adopt the Red Hat's init system, regardless of its quality, for compatibility purposes. For example when Gnome 3, which has significant ties to Red Hat, started depending on systemd, other distros had to a) switch to systemd, b) use a shim, or c) follow a forked version of Gnome. B and c are a lot of slogging work that they'd rather not do, so it's a pretty strong argument to fall in line with what Red Hat wants; especially when it's likely that the projects that did what Gnome did will continue to increase in number, and that systemd is difficult to maintain compatibility with, and becoming more so.
- kbenson 10y ago
  That pressure is not from Red Hat. That pressure is from projects that see a benefit to using systemd, and so then do so. Gnome wanted better power management and session tracking. So did KDE. Systemd offered that, so instead of having to maintain their own code paths to do that, which may or may not work as well, they can offload that task to systemd. Really, what the GUIs care about appears to be mostly handled in logind, and there are various projects in the works (available?) to provide that bit of functionality.
  - digi_owl 10y ago
    Err, things like upower existed as independent projects before systemd. But now upower is just a wrapper around systemd-logind (of all things).
    - kbenson 10y ago
      Okay, I just looked into this. upower used pm-utils upstream. According to upower devs, pm-utils was a dead project, so they switched to what was working, systemd[1]. I'm not sure specifically why pm-utils was discontinued, but given that the page says it's stuff for HAL, and other things I found in my search note that HAL was being discontinued, I think that's likely a reason. Note: pm-utils looks to have not been actively developed since at least late 2012. That's as far as I went back in the mailing list archives to find something indicative of that[2]. The last release was in July 2010. I can see why projects that relied on it wanted to migrate to something better, or at least maintained. Also note that pm-utils was a collections of shell scripts that ran different commands, such as mount, etc, and echo'd values into the proc filesystem. That may have also influenced decisions one way or another. 1: https://lists.freedesktop.org/archives/devkit-devel/2015-December/001748.html https://lists.freedesktop.org/archives/devkit-devel/2015-Dec... (upower was previously called DeviceKit, according to their site, which is why it's the devkit-devel mailing list). 2: https://lists.freedesktop.org/archives/pm-utils/2012-March/002249.html https://lists.freedesktop.org/archives/pm-utils/2012-March/0...