7 ms·

I'm sure systemd would be happy to take over responsibility for this functionality. (Sorry, couldn't resist!)

by j_s 9y ago

Rjevski 9y ago
If systemd does it right (just like it did with making service management) then I see no issues with this.
- TazeTSchnitzel 9y ago
  When has that ever happened?
  - Rjevski 9y ago
    Since systemd became mainstream? If only you've seen the time, money and sanity I saved when I switched to systemd instead of suffering with prehistoric initscripts.
    - atemerev 9y ago
      There were many other modern init replacements which did the job better than init scripts and better than systemd. I like my systems elegant, transparent and bloat-free. Systemd is none of that.
      - acdha 9y ago
        … and yet, oddly, most of the distribution maintainers who reviewed them picked systemd. That doesn't mean it's perfect but it does suggest this conversation would be far more productive if you reviewed the historical discussions to see the reasoning behind those decisions.
        atemerev 9y ago
        The reasoning was hammering it down to everybody's throats by Redhat. It is easier to adapt to proposed solution (even inferior) where there are some guarantees of support and traction, than to reinvent everything and be left as sole maintainers. It doesn't relate in any way to the quality of the solution.
        Etzos 9y ago
        I'm not sure this really makes sense. It sounds like RedHat didn't hammer it down throats, but instead created a solution that had some guarantees of support and traction which distro maintainers then decided was better than the current alternatives. No one was holding a gun to distro maintainer's heads tell them that they needed to move away from the existing solutions or else, or at least I haven't seen any evidence of that. So if they weren't forced into it and RedHat did indeed provide some guarantees, it does actually suggest what the parent says.
        _jal 9y ago
        There seems to be an effort to rewrite history to "well, everyone adopted it, so it must be good, right?" That is very much not the way it happened. Go read the discussions on the Debian lists, for instance - RHEL was indeed throwing its weight around. Add to that the games they're playing with interfaces, and at some point, it starts smelling like a miniature, farcical version of Microsoft in the 90s.
        aseipp 9y ago
        I don't even know what planet you're living on. In particular, Russ Allbery of the Debian technical committee gave some of the most detailed evaluation of systemd vs alternatives that I've seen from anyone from a user and maintainer POV. (He noticeably said, beforehand, he didn't think it would be a huge deal at first, but it turned out it was a big difference.) Many people did not like their decision, but suggesting that the Debian committee in particular didn't take the issue seriously and were strong-armed by Red Hat -- makes me think you have no idea what you're talking about, honestly. I'd like to read this part about RHEL throwing their weight around on the Debian lists. Given your implication is that Debian was clearly "forced" to adopting it, I imagine the relevant evidence shouldn't be hard to find. (Alternatively, you could actually ask other Debian maintainers yourself, like Josh, in this thread how it went. But you already did that and it didn't seem his narrative aligned with yours, so...)
      - edoceo 9y ago
        I <3 OpenRC Nothing broke, init scripts still plain simple.
    - _jal 9y ago
      You mean, when they started creating bizarre arbitrary username rules for handing out root(!), breaking DNS resolution, time sync, and so on? Perhaps it is best considered a time/money/sanity redistribution scheme, because I've certainly spent plenty on the above.
      - JoshTriplett 9y ago
        The bugs generate noise and make the news, the successes rarely do. (And what's wrong with time sync, exactly? It seems to work perfectly with zero configuration required, for a large number of people, myself included.)
        _jal 9y ago
        The question above was, "when has Systemd done it right?", followed by an assertion that they've been doing it right "since systemd became mainstream." I offered several examples, such as the '0day' username thing that was not only an example of a bug, but an example of very clearly Doing It Wrong on a design level. I'd suggest you search for timesyncd issues on Google, but you preemptively announced bugs don't matter to you and declared "works for me!", so I don't know why you'd ask. So perhaps just stop and consider for a moment why, exactly, it is that your init system is expanding to replicate existing, functional, standards-compliant userspace daemons with limited, buggy, noncompliant "replacements".
        JoshTriplett 9y ago
        > The question above was, "when has Systemd done it right?", followed by an assertion that they've been doing it right "since systemd became mainstream." Yes, they've been doing a great many things right. That doesn't make them bug-free by any means, nor does it mean that every single thing they've done is right; it does mean they built something incredibly useful and working for a large number of people. People don't seem to talk about those as often; outrage carries so much louder. > I offered several examples, such as the '0day' username thing that was not only an example of a bug, but an example of very clearly Doing It Wrong on a design level. Yes, and that was broken. And it has since been fixed, but that didn't get nearly as widely reported. systemd now checks for that issue and reports it rather than running the unit in question. (You could argue about its parsing of such fields, and that discussion is ongoing, but that's separate from the issue of running the unit as root.) > I'd suggest you search for timesyncd issues on Google, but you preemptively announced bugs don't matter to you and declared "works for me!" No, I asked the question of what you considered problematic about timesyncd, especially since you seemed to be talking about what you considered fundamental design issues. I keep a close eye on the large community of Debian folks running systemd, and read the bugs reported, and I had not seen anything notable related to timesyncd, especially not anything that would suggest a design issue. I never said bugs don't matter to me, nor was I attempting to generalize my own experiences to suggest that it must necessarily work for everyone. You seem to be actively seeking out and assuming hostility where none exists; I would not be surprised if you find it, but I'm not looking to supply any.
    - peterwwillis 9y ago
      If you had that much trouble with init scripts, the problem wasn't the scripts.
      - tdumitrescu 9y ago
        Who doesn't love cleaning out stale pidfiles? That's why we get those big SV $$$.
      - Rjevski 9y ago
        Yes sure, the problem is me for wanting to spend more time with my friends & family instead of pulling my hair out until 3am to make those damn initscripts work.
      - jjoonathan 9y ago
        Then why do all production init scripts for the simplest conceptual tasks always seem to be full of hacks (magic comments and files to declare dependencies, polling, cross-script communication, special cases, tons of comments referencing bugfixes to explain the crazy shit the script has to do, etc)?
        peterwwillis 9y ago
        Some of those are just things you find in any code (comments aren't bad), some of it refers to specific programs (there will always be 'special cases' if a program supports more modes of operation than "start" and "stop"), some of it is good (bugfixes are not bad), and sometimes init scripts are written by morons. Sometimes the code is bad. But the model isn't bad. People sometimes use "init script" to refer to the tools that run and maintain network services, and those are completely different. An init script boots your computer. A service runner is responsible for interfacing with an application and performing complex operations. They should not be confused, but often are, as Systemd conflates the two.
        bkor 9y ago
        The model of how the init scripts worked is terrible. There's no cross distribution bug fixing of those scripts. It's something added by the distribution. If there's an upstream script, it's often buggy. Or it didn't integrate with the 'speed init scripts up hacks' that various distributions were doing. Huge time sink for no particular gain.
    - tyfon 9y ago
      I have to agree with this, I never got the major systemd hate. And I started using linux in 1994-95ish and still use it and different bsds. The only thing it doesn't do properly out of the box is logging. I'm not the biggest fan of non text log files.
      - api 9y ago
        I haven't had a lot of stability problems with systemd, but I hate it. For me the hate comes from its extremely arcane interface and configuration layout. It's as bad as git in that you have to Google to learn how to do anything at all and the way to do simple things is obtuse and non-memorable, but unlike git I don't use it constantly so I never remember. Doing anything with systemd involves searching for how to do it since the command structure, layout, etc. is bizarre and counter-intuitive. There seem to be some Unix/Linux developers who have a mysterious affinity for obtuse arcane time-wasting cognitive-load-increasing design. It's like they see the ability to master crufty badly designed systems as a badge of honor or something, or maybe it comes from a drive for job security or consulting hours. Example: "systemctl list-units" What's wrong with "systemctl ls"? What would have been wrong with a shorter command that's easier to type like "sys ls"? It's a core aspect of the system so a name like "sys" would have been appropriate, easy to type, and easy to remember. Even worse the output of list-units has overly long lines and manages to be simultaneously hard for humans to read and hard for machines to parse. It uses white space as both a delimiter and within identifiers, making shell script parsing with "cut" etc. impossible. The entire design is like this: obtuse, verbose, clunky, hard to type, hard to remember. I absolutely loathe this stuff. Using it inspires fantasies of causing physical pain to its designers. A little bit of thought could have resulted in a clean, sparse, intuitive, and discoverable design with memorable commands and a straightforward configuration structure. Don't get me started on abominations like Debian packaging or Windows drivers, though those are somewhat forgivable as their ugliness can be explained by their age and the need for backward compatibility. Systemd was a green field design from the 21st century so it has no excuse.
        jjoonathan 9y ago
        "Clean, sparse, intuitive, and discoverable"? I have yet to meet a single non-broken production init script that merits a single one of those adjectives.
    - mixedCase 9y ago
      > prehistoric initscripts That's the only thing I've seen people praise systemd for, and I happen to agree. Nothing else systemd does do I think it does better. If systemd had remained an init system and nothing else, it would've been a clear improvement worth breaking what it does. What systemd is today should be called the Fedora userspace suite, not a Linux init system.
      - bkor 9y ago
        systemd is far more than an init system. I saw somewhere the description of the "basic building block of Linux". IMO a well working together basic building block is great. The huge amount of pointless differences needed to be reduced ages ago.
        koffiezet 9y ago
        > IMO a well working together basic building block is great. The huge amount of pointless differences needed to be reduced ages ago. Indeed, who needs competition, the bazaar philosophy got us nowhere right? /s
    - throw2016 9y ago
      This is repeated a lot but without specific examples lacks substance. Given scripts are used in nearly all linux software branding them them as 'prehistoric' comes off sounding misinformed.
      - brainfire 9y ago
        I think it is the specific scripts that are prehistoric, not the idea of scripting.
- work_account 9y ago
  The problem with systemd usurping basic Linux functionality is that it makes it really difficult for non-systemd distros to keep up. It's not like you can run 'systemd-udevd' standalone, for example. Instead there are massive "porting" efforts like eudev and elogind, just to extract the functionality BACK from systemd. And then you have obsolete-but-necessary components such as ConsoleKit and PolicyKit that are stuck on ancient pre-systemd versions with no current replacement. I started using systemd back before they even took over "udev". Back then systemd was a breath of fresh air. Now I'm using a different service manager and observing systemd gobbling up various critical parts of the Linux desktop like some damn Katamari is like watching a train accident in slow motion.
  - kuschku 9y ago
    Have you ever considered why it is so much effort to extract this functionality? systemd can iterate quicker, and work faster and better, because they can share more code between projects. Code that should have been in the stdlib, provided by the distro, but which no one does. So it ends up in systemd. You see the issue even in GNU yes, which implements its own version of a buffered output, or in cat, which does the same, but slightly different. All these things should be in the stdlib, and because they’re not, those projects that can use premade solutions iterate a lot quicker, and can get better, faster.
    - CyberDildonics 9y ago
      If what they are doing is so fundamental, why isn't it more modular?
JdeBP 9y ago
Actually, it has been given the responsibility. A quick review of the code reveals that dbus-broker-launch relies upon systemd entirely for bus-activation. To activate a dbus server on demand, it sends a message to systemd using a systemd-specific protocol. It has no way to demand-activate services on a non-systemd operating system. The dbus-daemon that this purports to be compatible with at least can be persuaded, via its launch helper, to demand-activate services in a generic fashion using whichever of initctl, systemctl, service, or system-control is appropriate. * http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html#ChangeDBusHelper http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.ht... * http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-start.html http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-s...

I'm sure systemd would be happy to take over responsibility for this functionality. (Sorry, couldn't resist!)

by j_s 9y ago

I'm sure systemd would be happy to take over responsibility for this functionality. (Sorry, couldn't resist!)

Rjevski 9y ago

If systemd does it right (just like it did with making service management) then I see no issues with this.

TazeTSchnitzel 9y ago
When has that ever happened?
- Rjevski 9y ago
  Since systemd became mainstream? If only you've seen the time, money and sanity I saved when I switched to systemd instead of suffering with prehistoric initscripts.
  - atemerev 9y ago
    There were many other modern init replacements which did the job better than init scripts and better than systemd. I like my systems elegant, transparent and bloat-free. Systemd is none of that.
    - acdha 9y ago
      … and yet, oddly, most of the distribution maintainers who reviewed them picked systemd. That doesn't mean it's perfect but it does suggest this conversation would be far more productive if you reviewed the historical discussions to see the reasoning behind those decisions.
      - atemerev 9y ago
        The reasoning was hammering it down to everybody's throats by Redhat. It is easier to adapt to proposed solution (even inferior) where there are some guarantees of support and traction, than to reinvent everything and be left as sole maintainers. It doesn't relate in any way to the quality of the solution.
        Etzos 9y ago
        I'm not sure this really makes sense. It sounds like RedHat didn't hammer it down throats, but instead created a solution that had some guarantees of support and traction which distro maintainers then decided was better than the current alternatives. No one was holding a gun to distro maintainer's heads tell them that they needed to move away from the existing solutions or else, or at least I haven't seen any evidence of that. So if they weren't forced into it and RedHat did indeed provide some guarantees, it does actually suggest what the parent says.
        _jal 9y ago
        There seems to be an effort to rewrite history to "well, everyone adopted it, so it must be good, right?" That is very much not the way it happened. Go read the discussions on the Debian lists, for instance - RHEL was indeed throwing its weight around. Add to that the games they're playing with interfaces, and at some point, it starts smelling like a miniature, farcical version of Microsoft in the 90s.
        aseipp 9y ago
        I don't even know what planet you're living on. In particular, Russ Allbery of the Debian technical committee gave some of the most detailed evaluation of systemd vs alternatives that I've seen from anyone from a user and maintainer POV. (He noticeably said, beforehand, he didn't think it would be a huge deal at first, but it turned out it was a big difference.) Many people did not like their decision, but suggesting that the Debian committee in particular didn't take the issue seriously and were strong-armed by Red Hat -- makes me think you have no idea what you're talking about, honestly. I'd like to read this part about RHEL throwing their weight around on the Debian lists. Given your implication is that Debian was clearly "forced" to adopting it, I imagine the relevant evidence shouldn't be hard to find. (Alternatively, you could actually ask other Debian maintainers yourself, like Josh, in this thread how it went. But you already did that and it didn't seem his narrative aligned with yours, so...)
    - edoceo 9y ago
      I <3 OpenRC Nothing broke, init scripts still plain simple.
  - _jal 9y ago
    You mean, when they started creating bizarre arbitrary username rules for handing out root(!), breaking DNS resolution, time sync, and so on? Perhaps it is best considered a time/money/sanity redistribution scheme, because I've certainly spent plenty on the above.
    - JoshTriplett 9y ago
      The bugs generate noise and make the news, the successes rarely do. (And what's wrong with time sync, exactly? It seems to work perfectly with zero configuration required, for a large number of people, myself included.)
      - _jal 9y ago
        The question above was, "when has Systemd done it right?", followed by an assertion that they've been doing it right "since systemd became mainstream." I offered several examples, such as the '0day' username thing that was not only an example of a bug, but an example of very clearly Doing It Wrong on a design level. I'd suggest you search for timesyncd issues on Google, but you preemptively announced bugs don't matter to you and declared "works for me!", so I don't know why you'd ask. So perhaps just stop and consider for a moment why, exactly, it is that your init system is expanding to replicate existing, functional, standards-compliant userspace daemons with limited, buggy, noncompliant "replacements".
        JoshTriplett 9y ago
        > The question above was, "when has Systemd done it right?", followed by an assertion that they've been doing it right "since systemd became mainstream." Yes, they've been doing a great many things right. That doesn't make them bug-free by any means, nor does it mean that every single thing they've done is right; it does mean they built something incredibly useful and working for a large number of people. People don't seem to talk about those as often; outrage carries so much louder. > I offered several examples, such as the '0day' username thing that was not only an example of a bug, but an example of very clearly Doing It Wrong on a design level. Yes, and that was broken. And it has since been fixed, but that didn't get nearly as widely reported. systemd now checks for that issue and reports it rather than running the unit in question. (You could argue about its parsing of such fields, and that discussion is ongoing, but that's separate from the issue of running the unit as root.) > I'd suggest you search for timesyncd issues on Google, but you preemptively announced bugs don't matter to you and declared "works for me!" No, I asked the question of what you considered problematic about timesyncd, especially since you seemed to be talking about what you considered fundamental design issues. I keep a close eye on the large community of Debian folks running systemd, and read the bugs reported, and I had not seen anything notable related to timesyncd, especially not anything that would suggest a design issue. I never said bugs don't matter to me, nor was I attempting to generalize my own experiences to suggest that it must necessarily work for everyone. You seem to be actively seeking out and assuming hostility where none exists; I would not be surprised if you find it, but I'm not looking to supply any.
  - peterwwillis 9y ago
    If you had that much trouble with init scripts, the problem wasn't the scripts.
    - tdumitrescu 9y ago
      Who doesn't love cleaning out stale pidfiles? That's why we get those big SV $$$.
    - Rjevski 9y ago
      Yes sure, the problem is me for wanting to spend more time with my friends & family instead of pulling my hair out until 3am to make those damn initscripts work.
    - jjoonathan 9y ago
      Then why do all production init scripts for the simplest conceptual tasks always seem to be full of hacks (magic comments and files to declare dependencies, polling, cross-script communication, special cases, tons of comments referencing bugfixes to explain the crazy shit the script has to do, etc)?
      - peterwwillis 9y ago
        Some of those are just things you find in any code (comments aren't bad), some of it refers to specific programs (there will always be 'special cases' if a program supports more modes of operation than "start" and "stop"), some of it is good (bugfixes are not bad), and sometimes init scripts are written by morons. Sometimes the code is bad. But the model isn't bad. People sometimes use "init script" to refer to the tools that run and maintain network services, and those are completely different. An init script boots your computer. A service runner is responsible for interfacing with an application and performing complex operations. They should not be confused, but often are, as Systemd conflates the two.
        bkor 9y ago
        The model of how the init scripts worked is terrible. There's no cross distribution bug fixing of those scripts. It's something added by the distribution. If there's an upstream script, it's often buggy. Or it didn't integrate with the 'speed init scripts up hacks' that various distributions were doing. Huge time sink for no particular gain.
  - tyfon 9y ago
    I have to agree with this, I never got the major systemd hate. And I started using linux in 1994-95ish and still use it and different bsds. The only thing it doesn't do properly out of the box is logging. I'm not the biggest fan of non text log files.
    - api 9y ago
      I haven't had a lot of stability problems with systemd, but I hate it. For me the hate comes from its extremely arcane interface and configuration layout. It's as bad as git in that you have to Google to learn how to do anything at all and the way to do simple things is obtuse and non-memorable, but unlike git I don't use it constantly so I never remember. Doing anything with systemd involves searching for how to do it since the command structure, layout, etc. is bizarre and counter-intuitive. There seem to be some Unix/Linux developers who have a mysterious affinity for obtuse arcane time-wasting cognitive-load-increasing design. It's like they see the ability to master crufty badly designed systems as a badge of honor or something, or maybe it comes from a drive for job security or consulting hours. Example: "systemctl list-units" What's wrong with "systemctl ls"? What would have been wrong with a shorter command that's easier to type like "sys ls"? It's a core aspect of the system so a name like "sys" would have been appropriate, easy to type, and easy to remember. Even worse the output of list-units has overly long lines and manages to be simultaneously hard for humans to read and hard for machines to parse. It uses white space as both a delimiter and within identifiers, making shell script parsing with "cut" etc. impossible. The entire design is like this: obtuse, verbose, clunky, hard to type, hard to remember. I absolutely loathe this stuff. Using it inspires fantasies of causing physical pain to its designers. A little bit of thought could have resulted in a clean, sparse, intuitive, and discoverable design with memorable commands and a straightforward configuration structure. Don't get me started on abominations like Debian packaging or Windows drivers, though those are somewhat forgivable as their ugliness can be explained by their age and the need for backward compatibility. Systemd was a green field design from the 21st century so it has no excuse.
      - jjoonathan 9y ago
        "Clean, sparse, intuitive, and discoverable"? I have yet to meet a single non-broken production init script that merits a single one of those adjectives.
  - mixedCase 9y ago
    > prehistoric initscripts That's the only thing I've seen people praise systemd for, and I happen to agree. Nothing else systemd does do I think it does better. If systemd had remained an init system and nothing else, it would've been a clear improvement worth breaking what it does. What systemd is today should be called the Fedora userspace suite, not a Linux init system.
    - bkor 9y ago
      systemd is far more than an init system. I saw somewhere the description of the "basic building block of Linux". IMO a well working together basic building block is great. The huge amount of pointless differences needed to be reduced ages ago.
      - koffiezet 9y ago
        > IMO a well working together basic building block is great. The huge amount of pointless differences needed to be reduced ages ago. Indeed, who needs competition, the bazaar philosophy got us nowhere right? /s
  - throw2016 9y ago
    This is repeated a lot but without specific examples lacks substance. Given scripts are used in nearly all linux software branding them them as 'prehistoric' comes off sounding misinformed.
    - brainfire 9y ago
      I think it is the specific scripts that are prehistoric, not the idea of scripting.
work_account 9y ago
The problem with systemd usurping basic Linux functionality is that it makes it really difficult for non-systemd distros to keep up. It's not like you can run 'systemd-udevd' standalone, for example. Instead there are massive "porting" efforts like eudev and elogind, just to extract the functionality BACK from systemd. And then you have obsolete-but-necessary components such as ConsoleKit and PolicyKit that are stuck on ancient pre-systemd versions with no current replacement. I started using systemd back before they even took over "udev". Back then systemd was a breath of fresh air. Now I'm using a different service manager and observing systemd gobbling up various critical parts of the Linux desktop like some damn Katamari is like watching a train accident in slow motion.
- kuschku 9y ago
  Have you ever considered why it is so much effort to extract this functionality? systemd can iterate quicker, and work faster and better, because they can share more code between projects. Code that should have been in the stdlib, provided by the distro, but which no one does. So it ends up in systemd. You see the issue even in GNU yes, which implements its own version of a buffered output, or in cat, which does the same, but slightly different. All these things should be in the stdlib, and because they’re not, those projects that can use premade solutions iterate a lot quicker, and can get better, faster.
  - CyberDildonics 9y ago
    If what they are doing is so fundamental, why isn't it more modular?

JdeBP 9y ago

Actually, it has been given the responsibility. A quick review of the code reveals that dbus-broker-launch relies upon systemd entirely for bus-activation. To activate a dbus server on demand, it sends a message to systemd using a systemd-specific protocol. It has no way to demand-activate services on a non-systemd operating system. The dbus-daemon that this purports to be compatible with at least can be persuaded, via its launch helper, to demand-activate services in a generic fashion using whichever of initctl, systemctl, service, or system-control is appropriate. * http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html#ChangeDBusHelper http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.ht... * http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-start.html http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-s...