8 ms·

I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain Linux servers. systemd is a great addition to the Linux server ecosystem. It's infi

by maheart 10y ago

I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain Linux servers. systemd is a great addition to the Linux server ecosystem. It's infinitely easier to write a systemd init script that is functionally correct, than it is to write the equivalent init script in shell. > It wasn't broken, so it did not need fixing / rewriting. Writing a robust init script in shell is a HUGE pain. Every distro seemed to have their own tools and methods for writing init scripts (e.g. Red Hat had /etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them sucked. systemd makes it easy (and for the most part, portable across systemd distros).

snaky 10y ago
> Writing a robust init script in shell is a HUGE pain In trivial case, it's simple in any modern distro [1] In non-trivial case, it's complicated. And the complexity is not going away, all you can do is move the complexity to one corner or another. When you add the complexity to the shell script, it's right there, plain and clear. When you move the complexity to systemd, it's not magically goes away - it just moves to thousands of lines of C code (of not the best quality on this planet, to say the least). [1] https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts#Writing_initscripts https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...
- scrollaway 10y ago
  > When you move the complexity to systemd, it's not magically goes away You're ignoring that complexity was added to every single init script. Every init script had its own potential bugs, issues, race conditions, dependency logic, etc etc. Now you're moving it to one single master system. No, it's not "magically going away". The repetition is going away. The code duplication of an extremely complex system is going away.
  - snaky 10y ago
    The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that. depend() { need localmount after bootmisc } reload() { ebegin "Reloading configuration" start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/} eend $? }
    - scrollaway 10y ago
      systemd the init system is by no means a monster (may I remind you and everyone else again that -resolved is merely a project under the systemd umbrella). I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this. It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.
      - snaky 10y ago
        The modularity of systemd-the-monster is greatly overrated. The "basic software engineering principles" you are talking about are not about tightly-coupled interdependent in and out ball of mud with no documented protocols and APIs. Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.
    - vidarh 10y ago
      You do, however, need e.g. an init that knows what to do about orphaned processes, or the above is not reliable. It also does not provide any ability to guarantee that process remains running without something other than the typical init, nor to ensure logging is done properly, or enforce resource limits. To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.
  - digi_owl 10y ago
    An artifact of sysv, not of scripts. . filename or source filename allow one script to effectively import another. This means that the various logic can live in one place and be reused.
roblabla 10y ago
I also love the systemd init system and unit system. What most people complain about isn't that. It's all the rest. Systemd is a huge, huge thing that tries to do everything. Here, people are complaining that systemd replaces the name resolution system. People also complains it handles tmpfiles, the random devices, the journal, etc... People complains that it replaced perfectly working, battle-tested components with new, unaudited code. I don't personally care one way or another, btw. I'm a happy systemd user. But I understand the concern.
fridsun 10y ago
You probably didn't realize that pain until systemd. Otherwise if you searched for alternatives, daemontools family is pretty easy to find. Or you would be using BSD instead, with better security. But, well, since I saw a 5-year-ago Stackoverflow question recommending double fork to daemonize which goes against process management best practices dating back to 1990s IBM AIX, I realize the Internet is not smart enough to get such delicate things straight. Maybe djb stuff was not easy to find. Whatever. *"Portable across systemd" is not portable at all.

by maheart 10y ago

snaky 10y ago

> Writing a robust init script in shell is a HUGE pain In trivial case, it's simple in any modern distro [1] In non-trivial case, it's complicated. And the complexity is not going away, all you can do is move the complexity to one corner or another. When you add the complexity to the shell script, it's right there, plain and clear. When you move the complexity to systemd, it's not magically goes away - it just moves to thousands of lines of C code (of not the best quality on this planet, to say the least). [1] https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts#Writing_initscripts https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...

scrollaway 10y ago
> When you move the complexity to systemd, it's not magically goes away You're ignoring that complexity was added to every single init script. Every init script had its own potential bugs, issues, race conditions, dependency logic, etc etc. Now you're moving it to one single master system. No, it's not "magically going away". The repetition is going away. The code duplication of an extremely complex system is going away.
- snaky 10y ago
  The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that. depend() { need localmount after bootmisc } reload() { ebegin "Reloading configuration" start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/} eend $? }
  - scrollaway 10y ago
    systemd the init system is by no means a monster (may I remind you and everyone else again that -resolved is merely a project under the systemd umbrella). I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this. It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.
    - snaky 10y ago
      The modularity of systemd-the-monster is greatly overrated. The "basic software engineering principles" you are talking about are not about tightly-coupled interdependent in and out ball of mud with no documented protocols and APIs. Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.
  - vidarh 10y ago
    You do, however, need e.g. an init that knows what to do about orphaned processes, or the above is not reliable. It also does not provide any ability to guarantee that process remains running without something other than the typical init, nor to ensure logging is done properly, or enforce resource limits. To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.
- digi_owl 10y ago
  An artifact of sysv, not of scripts. . filename or source filename allow one script to effectively import another. This means that the various logic can live in one place and be reused.

roblabla 10y ago

I also love the systemd init system and unit system. What most people complain about isn't that. It's all the rest. Systemd is a huge, huge thing that tries to do everything. Here, people are complaining that systemd replaces the name resolution system. People also complains it handles tmpfiles, the random devices, the journal, etc... People complains that it replaced perfectly working, battle-tested components with new, unaudited code. I don't personally care one way or another, btw. I'm a happy systemd user. But I understand the concern.

fridsun 10y ago

You probably didn't realize that pain until systemd. Otherwise if you searched for alternatives, daemontools family is pretty easy to find. Or you would be using BSD instead, with better security. But, well, since I saw a 5-year-ago Stackoverflow question recommending double fork to daemonize which goes against process management best practices dating back to 1990s IBM AIX, I realize the Internet is not smart enough to get such delicate things straight. Maybe djb stuff was not easy to find. Whatever. *"Portable across systemd" is not portable at all.