So is systemd-the-initsystem and systemd-networkd. Both are independent tools, where systemd-networkd uses an API provided by systemd-the-initsystem. Distributions routinely replace systemd-networkd. They replace other parts of systemd as well. So I fail to see the difference. There are about 60 different binaries, each doing one thing. They all communicate using a standard and even scriptable method that is widely used in unix desktop environments.

The BSDs tend to develop kernels and tools together, too, precisely to have a better integrated userland and I am pretty sure those count as unix:-) So that is not (only) the windows way. The systemd project is about providing similar plumbing for Linux. The developers clearly say so for a long time now. With the stated goal of being the plumbing layer the project tackles a lot of problems that were ignored. That is a good thing(TM). And that more and more developers of applications start to depend on the plumbing is proof to me that they are doing a good job. Actually that is where the value of systemd is, not in the init system.

Process management the core task of any init system, so I am not sure how that ended up in your list. Not sure what notifications does there either, since I am not aware of systemd actually doing that, but maybe I am missing something. The kernel devs have tried to clean up the console code repeatedly and have expressed interest in moving that code to userland. A brave soul stepped up and started to implement that. Putting it into systemd is the logical step for him to take: That is what all the major distributions are using. That there is finally some common ground makes projects like this possible in the first place! Or do you seriously think he would have written the code and then have bothered to integrate it into a dozen different distributions? Nope, no chance. Yes, there are packagers that help with the packaging, but he would still have a shitload of integration work to do to handle the different setups, init systems and whatnot.

There are precedents to changing init systems on unixy systems: Mac has launchd, Solaris has SMF. Sysvinit itself was called an aberation when it was introduced, too, doing away with the much simpler BSD-style init.

I would consider systemd very unixy: It has lots of small tools, each designed to do something well. These work in concert to accomplish complex tasks. This whole "unix philosophy" thing is basically in the eye of the beholder.

Boot time is a side-effect.

Better hardening options for services is a value systemd brings to the table. Process management is another big one. Better logging, too. A more robust boot free of races is hard to argue with too (provided you have been bitten by such a race condition before:-). Finally socket activation greatly simplifies dependency management.

Systemd uses DBus, an established, well understood and well tested protocol to communicate in favor of rolling its own. That can be considered a huge plus: Or have you never seen custom protocol parsers explode before, especially those written in C?

I wonder where you got that from. Systemd is particularly well suited for server systems: It makes for a more reliably boot process, it provides easy ways to harden services run, it can monitor running services, it collects way more log entries and enriches them with a lot of information directly from the kernel.

Systemd is designed to make all the features of Linux available to admins. Those features are not available elsewhere, so of course systemd is neither. Blame that on the kernel developers, not on systemd.

Why does it your desktop environment depend on systemd? Because the developers of your desktop environment have decide that the services provided by systemd are valuable to them. Note that the desktop environment technically does not depend on systemd running as PID1, just on some of the daemons that are developed in the systemd repository. Those do in turn depend on systemd being PID1, but that is a different story:-)

If you do not know something, then maybe you should spend your time trying to understand the issue at hand before commenting in a public forum?

My experience with the systemd community was positive all the way. Any questions I had were answered in a friendly and helpful way. My patches were reviewed in a direct but friendly fashion and applied after all parties were happy with them. That is more that I can claim about many other projects I had contact with.

And I have seen several comments that have been well refuted but are brought up again and again. Well, I am happy with the answers to those comments, obviously the people making those comments are not.

There are rather a lot of opponents attacking proponents as well. That is no excuse for anybody to misbehave, but at this point *both* sides need to step back and take a deep of breath.

The outcry when the complex monster known as sysv init was introduced to replace the beautiful and simple BSD-style init was rather loud, too. Of course we were a much smaller group of people caring about Linux back then.

I have seen quite a few of the people arguing against systemd admit freely that they have never used it. That did give me the impression that much of the fuss ultimately results from a resistance to change, but I might be wrong.

Also I am convinced that there are actually only very few opponents that just manage to raise a lot of noise. E.g. the uselessd site consistently speaks about "we" and "our", but when you check the source code repository the whole thing was written by one person. I suspect other sites are doing the same. Maybe they are ultimately all run by one person with way too much time on their hands. Who knows?

Checking for a file in /usr/lib/systemd/system (which can be overridden in /etc/systemd/system is hardly comparable with windows startup. And I find reading a couple of lines with declarations like "Run this binary" and "Use this Environment" much easier to grok than several hundreds of lines of init scripts (that is including the helper code that the scripts drag in).

You seem to be more intelligent than me if you have no trouble with those scripts! And you also must be a better programmer than most of the authors of init scripts, which are often racy and even buggy.

I have seen way more name calling in systemd discussions than arguments, be they technical, philosophical or architectural. And that is from *both* sides.

Follow the Unix philosophy: Do one thing and do it well and work with other tools to implement complex tasks.

With your definition "ls -alF | grep "^drwxrwxrwx " is monolithic: The grep statement depends on ls formatting its output in a certain way. That makes them tightly-dependent binary blobs.

It is actually pretty simple: The systemd init system provides cgroups, which do solve a lot of problems that tools close to the kernel have. So those tools start to use systemd-the-init-system. These tools then in turn provide solutions to problems that application developers face. They do so in a better way than other tools addressing the same problem -- because they can leverage systemd-the-initsystem. So application software starts to depend on the tools lower down in the stack.

There is no one piece of software that depends on systemd-the-init-system directly: They all depend on things one level lower in the stack, all the way down to systemd-the-initsystem. That is actually considered to be good software design.

You are free to replace any level with another implementation (providing the same interface). Those interfaces are not all stable at this time, which is a bit of a stumbling block. But systemd actually promises stability for some interfaces while listing others as still under active development. That is more than many other projects do!

To me a faster boot-up time are just a nice side-effect of running systemd. I also do not see where well-established init system vestiges are abandoned. PID1 is pretty small -- yes, it is bigger as sysv-init, but then it does quite a few new and useful tricks.

Logs can be binary or you can forward them to whatever syslog implementation you care for (some of them then storing them in their own binary format;-). Why is that considered an issue at all? SuSE and RedHat apparently do that in their default configuration (I have not tried those though).

And no, adding more stuff to sysv-init is definitely not the right approach. It had out-grown its usefulness about a decade ago: That is when all the "real" unixes moved away from it, using service managers similar to what systemd tries to do now on Linux.

Abandoning sysv init is not happening to standardize on a new file format. It is happening because shell scripts are a horrible way to configure a system. A 10 line systemd file does a better job at starting a service than a 200 line sysv-init file. Systemd does apply a bunch of hardening features (e.g. make /home unavailable to a daemon, make /usr and /etc read-only to a daemon, restrict capabilities a daemon can get access to, even make it unable to ever apply more privileges than those it was started with), many of which I have never seen implemented in sysv-init scripts. Not that it is impossible to do in sysv-init, it is just so hard that nobody ever bothered!

About "Unix principle": I personally do not see why systemd is supposed to violate those. It is a lot of small binaries -- each doing some specific task -- working in concert.

So the proposal is an attempt to force volunteers to do something they do not care doing by themselves? That sounds like a solid plan and will surly result in well working support for non-systemd unit systems.

What could possibly go wrong with that plan?

Yeap, the indexing in the journald files does increase the file size. That does speed up searches though, so it does have its advantage.

But systemd also logs a lot more than syslog ever could. This includes a lot of meta data (e.g. systems unit that started a process, cryptographic hash) for each entry as well as more entries (e.g. stdout and stderr from all daemons).

What does systemd make worse?

I can e.g. restrict services far more effectively since I switched my machines to systemd. I really appreciate that. I also find the socket activation really convenient and am really happy to be rid of that horrible crontab syntax. Networkd works like a charm and debugging became so much easier since the log output is finally complete.

So far I have yet to find anything I miss from sysv unit.

That is indeed not posible: systems logs stuff that is not accessible to syslog (e.g. stdout and stderr of all processes run by systemd, output geerated before/after syslogd is up, etc.) and needs journald as some kind of internal interface to pass all that information on.

Why journald?

Because systemd logs stuff that is not accessible to syslog and thus needs an interface to buffer (e.g. before syslog is up) and forward that information to syslog.

That system grew up to handle most of the things syslog also does. So syslog was made optional, so that small systems have one less service that they need to run.

Send like a sensible decision to me.

The complexity of systemd is in stand-alone executables running inseverly restricted environments (no access to /home, private /tmp, read-only /, no network but through one file descriptor, etc.). That is a huge step forward.

This is especially true considering that the systems complexity is also running as separate, far less restricted services on non systemd systems (e.g. cron, xinetd, nwtpd, etc.).

That actually is a pretty good description of how systemd handles this.

Whichh sane ternatives to pulseaudio are you referring to?

How should that work? You need cgrouo support in the init system for that. Do you seriously think that is ever going to be added to sysv init?

Having some external process managing cgroups for init itself can not work, except by having init start the cgroup manager and then having that start everything else.

So the people that build the system do not care about it. *plonk*