Bug#727708: Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use one that does.

If we're going to do block quotes... I refer you to http://0pointer.de/blog/projects/the-biggest-myths.html, in which it is clearly stated:

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

systemd is already "a collection of small programs, each tackling one specific, well-defined component of the larger task", so I don't see what the issue is.

Please take some time to actually research the facts instead of reiterating FUD that's already been debunked. This bug is long enough.

Regards, James Rhodes.

Redpoint Software

http://about.me/james.rhodes

On 2 February 2014 11:11, Thilos Rich <thilos.rich@aol.com> wrote:

Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use an init that does.

This man said it best:
wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd

"
Init has one other job, which is to keep the process tables clean. See, any process can create a copy of itself (called “forking” (don’t laugh) in Unix terminology); this is usually a precursor to loading some other program. Any process that runs to completion can deliver a status code to the process that created it; the creating (or parent) process is said to “wait” on the status code of the created (or child) process. But what happens if the parent process dies before the child does? What happens is that init is designated to be the adoptive parent of the “orphaned” process, and it waits for, and discards, any status code that may be returned by the orphan on exit. This is to prevent “zombie processes” – process table slots that are filled with status codes but have no running programs attached to them. They are undesirable because they take up process table space that could be used by actual, running programs.

So it is important that init run well and not crash.

Now, in Unix system design, it is a generally understood principle that a big task not be handled by a big program, but rather a collection of small programs, each tackling one specific, well-defined component of the larger task. You often hear the phrase “do one thing, and do it well” as a guiding principle for writing a Unix program. One major reason for this is that a small program has fewer places for bugs to hide than a big program does.
"