5 ms·

> The claimed advantages of systemd are mostly relevant, IMHO, for mobile devices that change configuration often. It brings no particular advantage to servers

> The claimed advantages of systemd are mostly relevant, IMHO, for mobile devices that change configuration often. It brings no particular advantage to servers or desktops, unless you tend to swap out lots of peripherals on your desktop. Systemd provides huge advantages for administering desktops and servers as well. I'd actually go so far as to say those are the main reasons that systemd won (it's the default init system for all of the top ten Linux distributions by marketshare).

gsaga 9y ago
>Systemd provides huge advantages for administering desktops and servers as well Can you list some of them?
- oblio 9y ago
  Creating unit files is trivial and you're sure that you're getting high quality service supervision, unlike with home grown scripts. Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. There's also other parts I'm probably forgetting right now, but in general having a standard interface for service interaction is really, really useful. Sometimes I get the impression that Linux folks underestimate the benefits of standardization. For example there's still no good, standard way to check the exact name and version of a distribution. If they can't agree about something as banal as that... (I think there is a convergence towards /etc/os-release, but when was the first distro launched? 1992? :) )
  - dozzie 9y ago
    > Creating unit files is trivial [...] Unless you expect anything but most trivial use cases, e.g. some user-owned directory under /var/run (/run). Then you need to wild-guess at what combination of options needs to be set. Good thing that those options are at least described in docs. > Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. syslog already was standard. We gained nothing really from journald.
    - oblio 9y ago
      Quick, how do I see the logs for the currently running services from the random OSS project foo and the random commercial project bar? What do I type in my terminal?
      - dozzie 9y ago
        So? How do you tell between commercial and OSS projects in journald? And about that "quick" part, I'd rather have a way to do that that's either easy to recall or easy to re-develop. journald's magical incantations that don't compose to any consistent language (unlike Vim or Emacs keybindings, for instance) nor are the same as in virtually any other software are not convenient by any stretch. I have my memory cluttered enough by half a dozen of different languages I use, their runtimes, runtimes of languages I don't write in but need for some software I run, twice that of DSLs and specialized languages, options and functions of dozens of services, wire formats of network protocols, management procedures of various Linux subsystems, and so on. I don't need an option to a command to tell me what you ask, I can work my way through grep/sed/awk faster than you read man page, thank you very much.
        lclarkmichalek 9y ago
        I feel like journalctl -u foo is easier to type than that rant.
        oblio 9y ago
        Those were just random examples to prove a point (daemons/services can have very varied origins). The real question is: > I have two service from totally different origins. What do I type in my terminal to see their logs, with syslog or other widely used init systems currently in use, except for systemd? So? :)
        fiddlerwoaroof 9y ago
        `less /var/log/<service>.log` or `ag <service> /var/log` or something similar usually works pretty well. I’m not sure why I need a command line utility to do something that the filesystem+standard Unix utilities does just fine. The whole point of Unix is to compose general purpose utilities to get the job done rather than to create a special tool for each task.
  - e12e 9y ago
    > For example there's still no good, standard way to check the exact name and version of a distribution. lsb_release -a? (lsb = Linux standard Base)
    - oblio 9y ago
      Yes, but unfortunately I think Debian is abandoning lsb. And most of its offspring will follow :(
- zhengyi13 9y ago
  Expressing inter-daemon/inter-service dependencies (restart this, want X, Y, and Z restarted subsequently) has repeatedly bitten our team under SysV init (in say, RHEL <= 6), but becomes a totally solvable issue under SystemD. (It should be noted that while our company runs an awful lot of 1st party stuff, what our team works with is exclusively 3rd party stuff over which we have precisely no control)
- stephenr 9y ago
  Declarative system service configuration (i.e. init scripts or unit files in systemd language) are definitely an advantage. I was initial skeptical about their benefit - after all, an init script is just shell, it can be debugged literally with `sh -x`. But that also means a) people write/ship fucking terrible init scripts, mostly because b) it's not necessarily simple to write an init script in pure shell. The problem with systemd is the politics and the project's approach to the community (including their self-defined role/goals).
  - dozzie 9y ago
    > I was initial skeptical about their benefit - after all, an init script is just shell, it can be debugged literally with `sh -x`. But note that unit files along with their PID 1 cannot be debugged now. Which is a big step backwards.
    - stephenr 9y ago
      > But note that unit files along with their PID 1 cannot be debugged now. Which is a big step backwards. Sure, I'll concede that. But, due to their nature, there's also less need for ops/packager level users to debug unit files.
      - JdeBP 9y ago
        * https://unix.stackexchange.com/questions/429474/ https://unix.stackexchange.com/questions/429474/ * https://unix.stackexchange.com/questions/428615/ https://unix.stackexchange.com/questions/428615/ * https://unix.stackexchange.com/questions/428689/ https://unix.stackexchange.com/questions/428689/ * https://unix.stackexchange.com/questions/428474/ https://unix.stackexchange.com/questions/428474/ * https://unix.stackexchange.com/questions/427836/ https://unix.stackexchange.com/questions/427836/ * https://unix.stackexchange.com/questions/427806/ https://unix.stackexchange.com/questions/427806/ * https://unix.stackexchange.com/questions/427712/ https://unix.stackexchange.com/questions/427712/ * https://unix.stackexchange.com/questions/427710/ https://unix.stackexchange.com/questions/427710/ That's just one WWW site, just the ones that I encountered (because I do not read them all), and just since the beginning of this month.

gsaga 9y ago

>Systemd provides huge advantages for administering desktops and servers as well Can you list some of them?

oblio 9y ago
Creating unit files is trivial and you're sure that you're getting high quality service supervision, unlike with home grown scripts. Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. There's also other parts I'm probably forgetting right now, but in general having a standard interface for service interaction is really, really useful. Sometimes I get the impression that Linux folks underestimate the benefits of standardization. For example there's still no good, standard way to check the exact name and version of a distribution. If they can't agree about something as banal as that... (I think there is a convergence towards /etc/os-release, but when was the first distro launched? 1992? :) )
- dozzie 9y ago
  > Creating unit files is trivial [...] Unless you expect anything but most trivial use cases, e.g. some user-owned directory under /var/run (/run). Then you need to wild-guess at what combination of options needs to be set. Good thing that those options are at least described in docs. > Seeing the logs of every service is also trivial since it's standardized. No more spelunking through /var/log or some random location. syslog already was standard. We gained nothing really from journald.
  - oblio 9y ago
    Quick, how do I see the logs for the currently running services from the random OSS project foo and the random commercial project bar? What do I type in my terminal?
    - dozzie 9y ago
      So? How do you tell between commercial and OSS projects in journald? And about that "quick" part, I'd rather have a way to do that that's either easy to recall or easy to re-develop. journald's magical incantations that don't compose to any consistent language (unlike Vim or Emacs keybindings, for instance) nor are the same as in virtually any other software are not convenient by any stretch. I have my memory cluttered enough by half a dozen of different languages I use, their runtimes, runtimes of languages I don't write in but need for some software I run, twice that of DSLs and specialized languages, options and functions of dozens of services, wire formats of network protocols, management procedures of various Linux subsystems, and so on. I don't need an option to a command to tell me what you ask, I can work my way through grep/sed/awk faster than you read man page, thank you very much.
      - lclarkmichalek 9y ago
        I feel like journalctl -u foo is easier to type than that rant.
      - oblio 9y ago
        Those were just random examples to prove a point (daemons/services can have very varied origins). The real question is: > I have two service from totally different origins. What do I type in my terminal to see their logs, with syslog or other widely used init systems currently in use, except for systemd? So? :)
        fiddlerwoaroof 9y ago
        `less /var/log/<service>.log` or `ag <service> /var/log` or something similar usually works pretty well. I’m not sure why I need a command line utility to do something that the filesystem+standard Unix utilities does just fine. The whole point of Unix is to compose general purpose utilities to get the job done rather than to create a special tool for each task.
- e12e 9y ago
  > For example there's still no good, standard way to check the exact name and version of a distribution. lsb_release -a? (lsb = Linux standard Base)
  - oblio 9y ago
    Yes, but unfortunately I think Debian is abandoning lsb. And most of its offspring will follow :(
zhengyi13 9y ago
Expressing inter-daemon/inter-service dependencies (restart this, want X, Y, and Z restarted subsequently) has repeatedly bitten our team under SysV init (in say, RHEL <= 6), but becomes a totally solvable issue under SystemD. (It should be noted that while our company runs an awful lot of 1st party stuff, what our team works with is exclusively 3rd party stuff over which we have precisely no control)
stephenr 9y ago
Declarative system service configuration (i.e. init scripts or unit files in systemd language) are definitely an advantage. I was initial skeptical about their benefit - after all, an init script is just shell, it can be debugged literally with `sh -x`. But that also means a) people write/ship fucking terrible init scripts, mostly because b) it's not necessarily simple to write an init script in pure shell. The problem with systemd is the politics and the project's approach to the community (including their self-defined role/goals).
- dozzie 9y ago
  > I was initial skeptical about their benefit - after all, an init script is just shell, it can be debugged literally with `sh -x`. But note that unit files along with their PID 1 cannot be debugged now. Which is a big step backwards.
  - stephenr 9y ago
    > But note that unit files along with their PID 1 cannot be debugged now. Which is a big step backwards. Sure, I'll concede that. But, due to their nature, there's also less need for ops/packager level users to debug unit files.
    - JdeBP 9y ago
      * https://unix.stackexchange.com/questions/429474/ https://unix.stackexchange.com/questions/429474/ * https://unix.stackexchange.com/questions/428615/ https://unix.stackexchange.com/questions/428615/ * https://unix.stackexchange.com/questions/428689/ https://unix.stackexchange.com/questions/428689/ * https://unix.stackexchange.com/questions/428474/ https://unix.stackexchange.com/questions/428474/ * https://unix.stackexchange.com/questions/427836/ https://unix.stackexchange.com/questions/427836/ * https://unix.stackexchange.com/questions/427806/ https://unix.stackexchange.com/questions/427806/ * https://unix.stackexchange.com/questions/427712/ https://unix.stackexchange.com/questions/427712/ * https://unix.stackexchange.com/questions/427710/ https://unix.stackexchange.com/questions/427710/ That's just one WWW site, just the ones that I encountered (because I do not read them all), and just since the beginning of this month.