I don't understand why people hate systemd so much. It is not monolithic, udev runs independent of systemd (but yes it is a component of it), it does not replace cron (officially it is even not recommended to use it as a cron replacement), and it does not steal these init scripts that some people seem to love so much for no obvious reason. It is much more portable to create a systemd unit than to create a portable init script. It is more reliable. It is faster. It integrates better with other services (like pam, udev, ...) which are shown here to be "eaten" by systemd. I replaced openrc by systemd on my system, and it boots and shuts down service much more reliable, it is much faster, unit files are much cleaner and easier to understand than init scripts, it parallelizes better and faster, it can start devices on demand which helps lower-spec systems... I suppose most hate comes from people having to learn something new after they managed to understand init scripts in all these years (and systemd is easier). Portability btw helps downstream distributions having less work with the init system. On the other hand: Having gnome-session hard-depend on systemd is a hole different story. Blame them for it. It's not systemd's fault - you cannot blame it for simply being there. It did not force gnome into depending on it. When udev was invented nobody blamed that for becoming an integral part of many components although it was similar intrusive. Face it: It is just another long-needed evolution of linux userspace - as many other components before. Without this work we would probably still be booting with an initrc script, slowly and serially running inefficient, unreliable, and hard to maintain boot scripts, and struggling with hotplugging and hardware detection.
And another one: You can still run syslogd and let journald log its stuff to non-persistent storage. Nobody is forced to replace syslog with journald. But even journald is an evolution with its capabilities. And it can produce syslog compatible text logs as output. So where's the problem?
+Jóhann B. Guðmundsson Probably because systemd is in many respects technical superior and there is simply nothing to discuss. The fact that e.g. gnome-session hard-depends on systemd is technically not a systemd problem. That your distribution replaced syslogd with journald exclusively is technically not a systemd problem. You can extent that to almost any aspect. And almost any aspect can be answered with "you can still use..." - so I just don't get it. Maybe people are just not able to read documentation (which is btw one of the best and most complete I've ever read).
Jóhann B. Guðmundsson - 2013-11-04T09:43:06+0000 - Updated: 2013-11-04T09:45:48+0000
+Kai Krakow in many case it seems that people have something personal against Lennart and at the same time fail to see it's not like he's doing all of this ( as well as pulseaudio and other things Lennart has hacked on ) alone but chose to blame him and him alone for that as well as anything else in the process ( bunch of stuff that Lennart has never touched ).
+Jóhann B. Guðmundsson Yes, +Lennart Poettering is probably just doing most of the PR. I think from development point of view the driving force behind systemd is +Kay Sievers . And yes, many good things come from his keyboard, like pulseaudio (which is an improvement for desktop sound whose impact most people probably even did not notice), udev (without which most people would struggle with hardware and had to start hardware initialization scripts by hand), and so on. Systemd is one of the very rare pieces of software which worked almost out-of-the-box without much struggle for me although it has a huge impact on the whole system and almost all of their components. So technically it is a master-piece of software with very high quality standards. And most blame can only be given to how downstreams adapt it into their systems and components. You cannot blame systemd for simply being there and it's infrastructure becoming used.
Kai Krakow - 2013-11-08T13:17:34+0000 - Updated: 2013-11-08T13:19:08+0000
Pressing Ctrl+C during execution of an init script is not a debug tool. Reboot into single mode and use journald to check why that specific service had problems. I don't see where this is more complex. If you press Ctrl+C in a parallelizing init system, behavior is completely undefined (where should the signal go?) - so it is totally valid that systemd does not allow it.
Did you look at http://fedoraproject.org/wiki/How_to_debug_Systemd_problems or tried systemd.confirm_spawn=1? You cannot just call it more complex and hard to debug just because it does not work the way a 30 year old init system works and you just did not read documentation, Sorry, no offense intended - maybe you searched for docs - I don't know. That just my idea. I find systemd pretty easy to debug - and yes: I had to read and find documentation before it was easy, without that it looked like hell. In fact, systemd units are actually less complex, cleaner and easier to understand.
BTW: What is your definition of "concept of unix" which makes you say that systemd does not follow that concept?
Martin Vegter - 2013-11-08T14:08:12+0000 - Updated: 2013-11-08T14:11:09+0000
The systemd issue is mainly a philosophical issue, the technical issue only comes second. Systemd symbolizes everything that is rotten in the linux community. What can this 20 year old kid know about UNIX philosophy? The principles of UNIX philosophy are what made UNIX/Linux successful. Systemd is a way where Microsoft is going - abandoning simplicity and transparency for monolithic monsters that no single person can understand. I am no developer, but I am able to understand init to that extent, that I can write my own scripts and boot from encrypted partitions. This would be unthinkable with systemd. Only selected few - the high priesthood - will be able to understand it. You can say good bye to freedom and independence.
+Bastian Ballmann Well, systemd is a small daemon which spawns many other small daemons. It does that one job well, so this is not really an argument pro or contra systemd. But probably you cannot chain or mix as you could with a simple script runner init process - sure. Because systemd makes many assumptions about sockets and dbus activation. But it does that job very well, much better than a scripted init system. But I cannot accept the argument about it being some big fat huge all-in-one bloatware. That's simply not true, that's not its architecture. In that respect it's probably more unix-like than some other projects.
+Martin Vegter If you want to talk about simplicity: A simple configuration file that spawns my process reliable is in all respects simpler than maintaining a non-portable script which has to do all the error handling itself. It's that simple. The single fact that you can no longer put in bash lines into that script does not mean simplicity. And by the way: You can still put in those lovely bash lines if you want to. Systemd service files just abstract everything away which had to be done by each init script individually before - and it even does this job better because it does it very sophisticated instead of sparing out a few of many error situations just for "simplicity". Systemd has a much better understanding of its child processes are running or not and are ready or not to accept connections - much better than a *simple* script could ever do. So where's the point about simplicity? Because you have to learn a new syntax? And with systemd you can still write your own scripts: Create a script, put it into the Exec line of a service file and enable it. Maybe a bit more work than adding a symlink to a run level. But with systemd in the background: What does your script have left to do? Probably nothing. So with around 4 lines of service file you can reliably spawn and kill a service process. That's not so bad to my mind. And systemd is as monolithic or modular as the linux kernel, or as KDE, or Gnome. It's not magically monolithic just because it delivers many tools in one package. Did you look at the list of binaries included in the distribution? It is made of many small binaries with well defined and clean responsibilities - and exactly that is unix philosophy. Did you look at system units starting traditional daemons like cron etc? Do you need the high priests bible to understand them? I looked at them 10 minutes and immediatly understood them and could add my own services - simply by looking at a few examples. And please forget about these old dependency definitions - it's not needed most of the times. Systemd resolves that automatically. Of course you may sometimes need to tell systemd a little more than old fashioned init scripts - tell it about sockets or dbus. But well: That's easier than learning the abstractions to master an old fashioned init system. And the best point is: The one who knows his service best can create this file: The programmer. Because systemd units are portable. Downstream maintainers have less work, do not need to maintain init scripts any longer. So in unix philosophy an important part of package maintaining has gone back to where it belongs: to the creator/maintainer/publisher of the source distribution.
Sometimes I think people are just talking against systemd because they expect something similar complex and hard to learn as their lovely old init system - and they just cannot find all those complicated documentation - and thus it must be bad and monolithic and not unix-like and all those stuff, and they hate that they managed to learn this old init system the hard way and now it's all so simple without all those 1000 knobs to turn and bla bla bla... *sigh
+Bastian Ballmann Just to compare numbers: It took me 1-2 hours to migrate my system from openrc to systemd with all important services running, and a few hours of the next day to tweak it for my needs adding services that had no unit files yet. And everything went more smooth since. Openrc pretty often had some hiccups with spawning or killing services, got the order wrong during parallel startup, or took about 3 minutes to boot with serial startup. Now, lightdm is starting after 15s with all important services reliably up, it takes maybe another 30 seconds for having my pretty loaded KDE session up and running, and when shutting down services no longer leave orphan processes behind which keep the system from cleanly unmounting the partition. At least for me, all is better. And on my way further learning systemd units, I found many bad examples of how you should not write your systemd units - and some of them come with Arch linux. Maybe not everything in your system units is done right (and simple) and that's where your problems and struggles come from?
+Martin Vegter Well, whoever you meant with 20 year old kid: At least my Unix and Linux experience started in the early 90's, touching SuSE, Debian, IRIX, SunOS, Solaris, Redhat, Fedora, SLES, OpenSuSE, Gentoo, and maybe a few others, including development of some near-kernel file system daemons (before we had FUSE). And from the beginning I liked the unix concept - so at least don't try to tell me that I don't know about the unix concept. So yeah, maybe I am a twenty year old kid, too, because I'm in contact with unix concepts for about 20 years. Let me rewind: This is exactly that sort of discussion that +Jóhann B. Guðmundsson originally mentioned.
From what I read here some people tend to understand the "unix concept" as glueing together simple CLI binaries to scripts which more or less do what they should if there are no disturbing factors. Well, let me tell you just one important fact: That IS NOT the unix concept. Without further knowledge about that it makes no sense to discuss this any further. Especially in the light of wordings like "20 year old kid".
Tomasz Torcz
And another one: You can still run syslogd and let journald log its stuff to non-persistent storage. Nobody is forced to replace syslog with journald. But even journald is an evolution with its capabilities. And it can produce syslog compatible text logs as output. So where's the problem?
Did you look at http://fedoraproject.org/wiki/How_to_debug_Systemd_problems or tried systemd.confirm_spawn=1? You cannot just call it more complex and hard to debug just because it does not work the way a 30 year old init system works and you just did not read documentation, Sorry, no offense intended - maybe you searched for docs - I don't know. That just my idea. I find systemd pretty easy to debug - and yes: I had to read and find documentation before it was easy, without that it looked like hell. In fact, systemd units are actually less complex, cleaner and easier to understand.
BTW: What is your definition of "concept of unix" which makes you say that systemd does not follow that concept?
The systemd issue is mainly a philosophical issue, the technical issue only comes second. Systemd symbolizes everything that is rotten in the linux community. What can this 20 year old kid know about UNIX philosophy? The principles of UNIX philosophy are what made UNIX/Linux successful. Systemd is a way where Microsoft is going - abandoning simplicity and transparency for monolithic monsters that no single person can understand. I am no developer, but I am able to understand init to that extent, that I can write my own scripts and boot from encrypted partitions. This would be unthinkable with systemd. Only selected few - the high priesthood - will be able to understand it. You can say good bye to freedom and independence.
+Martin Vegter If you want to talk about simplicity: A simple configuration file that spawns my process reliable is in all respects simpler than maintaining a non-portable script which has to do all the error handling itself. It's that simple. The single fact that you can no longer put in bash lines into that script does not mean simplicity. And by the way: You can still put in those lovely bash lines if you want to. Systemd service files just abstract everything away which had to be done by each init script individually before - and it even does this job better because it does it very sophisticated instead of sparing out a few of many error situations just for "simplicity". Systemd has a much better understanding of its child processes are running or not and are ready or not to accept connections - much better than a *simple* script could ever do. So where's the point about simplicity? Because you have to learn a new syntax? And with systemd you can still write your own scripts: Create a script, put it into the Exec line of a service file and enable it. Maybe a bit more work than adding a symlink to a run level. But with systemd in the background: What does your script have left to do? Probably nothing. So with around 4 lines of service file you can reliably spawn and kill a service process. That's not so bad to my mind. And systemd is as monolithic or modular as the linux kernel, or as KDE, or Gnome. It's not magically monolithic just because it delivers many tools in one package. Did you look at the list of binaries included in the distribution? It is made of many small binaries with well defined and clean responsibilities - and exactly that is unix philosophy. Did you look at system units starting traditional daemons like cron etc? Do you need the high priests bible to understand them? I looked at them 10 minutes and immediatly understood them and could add my own services - simply by looking at a few examples. And please forget about these old dependency definitions - it's not needed most of the times. Systemd resolves that automatically. Of course you may sometimes need to tell systemd a little more than old fashioned init scripts - tell it about sockets or dbus. But well: That's easier than learning the abstractions to master an old fashioned init system. And the best point is: The one who knows his service best can create this file: The programmer. Because systemd units are portable. Downstream maintainers have less work, do not need to maintain init scripts any longer. So in unix philosophy an important part of package maintaining has gone back to where it belongs: to the creator/maintainer/publisher of the source distribution.