<html><body><div style="font-family: Arial; font-size: 12pt; color: #000000"><div aria-label="Compose body">Freedesktop.org has information on it. http://www.freedesktop.org/wiki/Software/systemd/</div><div><br></div><div>I have no strong feelings about systemd one way or the other. The SystemV init package was unmaintained. There were also projects, such as upstart, that were meant as replacements that also started services in parallel to speed bootup. At least one of the BSD's had also replaced BSD init to do the same thing.<br></div><div><br></div><div>SysV used scripts that were prefixed with S or K and a 3-digit number that controlled the order that the scripts ran in. It did not run another start script until the current one finished.</div><div><br></div><div>Upstart and systemd list dependencies that need to be run first, such as network before running samba. After scanning which services should be started and building a table of all the dependencies, init begins starting services, in parallel whenever possible, and in the proper order. They can also restart a service if it crashes, which SysV cannot do. Systemd uses something called cgroups to organize running services, but I don't know how this kernel feature works.<br></div><div><br></div><div>There are a number of reasons why some people don't like systemd. Lennart Pottering apparently is a tad difficult to deal with. He also developed pulseaudio, which some people haven't forgiven him for. Since he is a Red Hat employee, some people might not trust the project. Some people do not like the fact that the old bootscripts are gone, replaced by units. And the logs are binary, not text files.<br></div><div><br></div><div>Feature creep is another issue. Systemd has been extending into different areas, such as cron. Some people protest that this violates the Unix philosophy of doing one thing and doing it well. On the other hand, if you look at systemd as a master control program that fires off other programs and makes sure that they are restarted if they die, it might make sense for it to replace cron with a program that knows how to communicate with systemd's init program. Some older services return a pid that can be used to track a process's status, but not all services do that. Rewriting them makes it possible to have services that fit in seemlessly.<br></div><div><br></div><div>Arch Linux switched to systemd last year and I have not had any problems. That also means I haven't needed to dig into it, and I have not had the time to dig into it in my copious spare time.<br></div><div><br></div><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Sean LeBlanc" <seanleblanc@comcast.net><br><b>To: </b>"CLUE's mailing list" <clue@cluedenver.org><br><b>Sent: </b>Saturday, October 31, 2015 10:42:46 AM<br><b>Subject: </b>[clue] systemd - uh, wot's the deal?<br><div><br></div>So, having sort of been heads down on doing mostly bog-standard RHEL <br>stuff (when I do *nix at work, anyway: at home I'm using OSX on laptop, <br>and FreeNAS and Ubuntu server. There are also other *nixes at work, but <br>mostly they've been something I've set up and then tend to leave alone <br>as they don't need care and feeding) I've seen murmurings from the <br>bowels of the Internet (mostly on Diaspora) about systemd, and that's it <br>is controversial, etc.<br><div><br></div>But I don't fully understand all the concerns, counter-arguments in its <br>favor, etc.<br><div><br></div>Can anyone point me to some good reading on the topic? I'm also <br>interested in opinions from the old hands of CLUE, because I know some <br>people have been using Linux *as* sys- or net- admins for so long (being <br>mostly dev in my day job, I don't use it quite the same way).<br>_______________________________________________<br>clue mailing list: clue@cluedenver.org<br>For information, account preferences, or to unsubscribe see:<br>http://cluedenver.org/mailman/listinfo/clue<br></div><div><br></div></div></body></html>