4 ms·

systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds n

systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead. But change has lots of difficulties. The biggest resistance though is coming from people who are simply accustomed to the old approaches and don't see a problem with them. But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. I'm personally more of a Mac user than Linux user. On the Mac, 10 years ago, launchd replaced many of the processes that systemd is now replacing in Linux. Particularly for things like cron and inetd (which were horrible to configure and work with) it was a huge improvement. However, the Mac never replaced as much all at once. It was a much gentler transition. In fact, discoveryd (which does a lot of what systemd's hostname daemon's are trying to do) was only introduced in the current Yosemite.

cpncrunch 12y ago
I haven't used systemd yet, but I'm concerned about having to learn a completely new way of doing things. I manage a number of servers, and it would be a huge inconvenience figuring out systemd. The old way works fine for me. Unfortunately most of the servers I work with are CentOS, and it seems Redhat has switched to systemd so I'm not entirely sure what I'll do in future. I guess now I have another option.
- GFK_of_xmaspast 12y ago
  "I'm concerned about having to learn a completely new way of doing things." That's just a fact of life in this industry tho.
  - cpncrunch 12y ago
    Yes, of course. I occasionally learn a new language (or develop one), and I'm regularly using new APIs. However this completely changes everything about managing servers, for no compelling reason. It will create a large amount of hassle for no significant benefit.
    - johnny22 12y ago
      No compelling reason? you should probably read the docs a bit more. If you don't have any philosophical concerns with systemd, then you will find a lot to love there.
      - cpncrunch 12y ago
        I just re-read some docs, and I still can't see any compelling reasons. I'm not concerned about booting a few seconds faster (I only reboot my servers once every year at most). Regarding memory footprint: that has never been an issue. Binary logfiles are a disadvantage to me.
        4ydx 12y ago
        Binary logs and the amount of new code which these developers are incorrectly assuming will be stable. It is a total disaster in my opinion. I fell in love with using Linux because everything is text files. Binary approaches will only make using linux more cryptic.
uselessdguy 12y ago
This is a disingenuous presentation, though I would not expect any different from a systemd proponent, or opponent, for that matter. I wrote about the follies of systemd debates here: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The speed benefits come at the trade-off of integration complexity potentially diminishing them: http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng. Change does not imply progress. This should go without saying. No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics. systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime. launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".
ahomescu1 12y ago
> systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. > But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. The problems start when those replacement system utilities become (more or less) tightly coupled, so if you want to change one of them (say, I want to use my own DHCP client) then you need to change all of them (and it's increasingly looking like you can't).
- digi_owl 12y ago
  More correctly, you can't just use networkd as your dhcp client unless you have systemd as init. You could however use dhcpcd on top of systemd (tho the latter would likely make a lot of noise about "missing functionality"). And that is the insidious nature of it all. the *d's panders developer laziness. What do you do when some production critical piece of code demands networkd, logind, or any of the systemd sub-daemons? Do you look to replace it, or do you roll over and replace whatever already functioning init you have with systemd?
gone35 12y ago
But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. Well, with roadmaps like this[1], one wonders if some of the criticism is really that hyperbolic or unjustified... [1] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
- digi_owl 12y ago
  Sadly it drags the whole debate into an argument over semantics. Yes, it is not monolithic in the sense of one binary running everything. But at the same time everything ties back to systemd running as init. This in effect makes everything under the systemd umbrella tightly coupled. Can i run journald on its own, or logind, or resolved, networkd? As long as the answer is no, they mays well be one big blob. And it is presented as such as well from a source point of view. http://www.freedesktop.org/software/systemd/ http://www.freedesktop.org/software/systemd/ There is no separate tarball for udev, journald, logind, or any of the other *d's that make up the systemd project.
  - the_why_of_y 12y ago
    > As long as the answer is no, they mays well be one big blob. So to you there is no difference between sendmail and postfix, they are both equally monolithic?
    - digi_owl 12y ago
      If i just need a small portion but has to download and run more, then yes.
digi_owl 12y ago
> Newer code that is easier to maintain. It also brings "new" bugs. http://seclists.org/oss-sec/2014/q4/592 http://seclists.org/oss-sec/2014/q4/592

cpncrunch 12y ago

I haven't used systemd yet, but I'm concerned about having to learn a completely new way of doing things. I manage a number of servers, and it would be a huge inconvenience figuring out systemd. The old way works fine for me. Unfortunately most of the servers I work with are CentOS, and it seems Redhat has switched to systemd so I'm not entirely sure what I'll do in future. I guess now I have another option.

GFK_of_xmaspast 12y ago
"I'm concerned about having to learn a completely new way of doing things." That's just a fact of life in this industry tho.
- cpncrunch 12y ago
  Yes, of course. I occasionally learn a new language (or develop one), and I'm regularly using new APIs. However this completely changes everything about managing servers, for no compelling reason. It will create a large amount of hassle for no significant benefit.
  - johnny22 12y ago
    No compelling reason? you should probably read the docs a bit more. If you don't have any philosophical concerns with systemd, then you will find a lot to love there.
    - cpncrunch 12y ago
      I just re-read some docs, and I still can't see any compelling reasons. I'm not concerned about booting a few seconds faster (I only reboot my servers once every year at most). Regarding memory footprint: that has never been an issue. Binary logfiles are a disadvantage to me.
      - 4ydx 12y ago
        Binary logs and the amount of new code which these developers are incorrectly assuming will be stable. It is a total disaster in my opinion. I fell in love with using Linux because everything is text files. Binary approaches will only make using linux more cryptic.

uselessdguy 12y ago

This is a disingenuous presentation, though I would not expect any different from a systemd proponent, or opponent, for that matter. I wrote about the follies of systemd debates here: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ The speed benefits come at the trade-off of integration complexity potentially diminishing them: http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ Whether or not it is easier to maintain cannot really be objectively gauged. As for declarative configuration, I will grant that. systemd is not the first to do this on Linux, though. eINIT was, though it used XML as its configuration language (similar to launchd and SMF in fact, though not as verbose). eINIT also had the benefit of a modular plugin-based architecture, a property also shared by finit and initng. Change does not imply progress. This should go without saying. No, a lot of objectors simply come from having different opinions on process management and general software architectures. That said, there is a contingent who did approve of the old approaches, yes. I dislike sysvinit, but I can understand them. Serial execution with a concretely defined boot sequence that is easy to reason about can be a benefit to some. In contrast, the systemd approach eschews any definition of "boot process" or "boot sequence" that can be specifically intervened in by order, instead taking the philosophy that specifying a unit's dependencies and relative order to a target/synchronization point is enough, the rest being handled by internal transaction and job semantics. systemd most certainly is monolithic. It is also modular, but to a partial extent. System generators and various auxiliaries (journald, but also some of the more minor tooling) cannot be disabled at build time. Certain things like Plymouth communication are also explicitly done at runtime. launchd as a whole is still a much smaller system than systemd, at the end of the day. This is because launchd has a concretely defined purpose. systemd has little in the way of that other than vague descriptions that ultimately amount to being "as much as possible between the kernel and base libs+utils".

ahomescu1 12y ago

> systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. > But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. The problems start when those replacement system utilities become (more or less) tightly coupled, so if you want to change one of them (say, I want to use my own DHCP client) then you need to change all of them (and it's increasingly looking like you can't).

digi_owl 12y ago
More correctly, you can't just use networkd as your dhcp client unless you have systemd as init. You could however use dhcpcd on top of systemd (tho the latter would likely make a lot of noise about "missing functionality"). And that is the insidious nature of it all. the *d's panders developer laziness. What do you do when some production critical piece of code demands networkd, logind, or any of the systemd sub-daemons? Do you look to replace it, or do you roll over and replace whatever already functioning init you have with systemd?

gone35 12y ago

But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something (http://boycottsystemd.org http://boycottsystemd.org). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. Well, with roadmaps like this[1], one wonders if some of the criticism is really that hyperbolic or unjustified... [1] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf

digi_owl 12y ago
Sadly it drags the whole debate into an argument over semantics. Yes, it is not monolithic in the sense of one binary running everything. But at the same time everything ties back to systemd running as init. This in effect makes everything under the systemd umbrella tightly coupled. Can i run journald on its own, or logind, or resolved, networkd? As long as the answer is no, they mays well be one big blob. And it is presented as such as well from a source point of view. http://www.freedesktop.org/software/systemd/ http://www.freedesktop.org/software/systemd/ There is no separate tarball for udev, journald, logind, or any of the other *d's that make up the systemd project.
- the_why_of_y 12y ago
  > As long as the answer is no, they mays well be one big blob. So to you there is no difference between sendmail and postfix, they are both equally monolithic?
  - digi_owl 12y ago
    If i just need a small portion but has to download and run more, then yes.

digi_owl 12y ago

> Newer code that is easier to maintain. It also brings "new" bugs. http://seclists.org/oss-sec/2014/q4/592 http://seclists.org/oss-sec/2014/q4/592