Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?
I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.
I also think that maintainers would not have gone for systemd if they did not think it had benefits for their users. Contrary to what you think maintainers do care for having people use their distribution. The fact that systemd had convinced developers did also factor into the maintainers decisions. So did advantages for the packagers: Getting rid of init scripts was a big part of that. There were lots of factors considered at Debian, check the CTTE discussion you liked to earlier for more.
I do not think it matters whether software depends on an init system. Software depends on other software all the time and will adapt once some better option comes along.
Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it. Never seen that before on Linux.
Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.
How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.
Please read on what POSIX is first. It is what guarantees that your software will be portable, which is a foundation upon which UNIX is built.
Yes, POSIX is important. But as with any standard it defines the least common denominator. Couple that with the fact that POSIX was not updated in years and you have to address the least common denominator from more that 5 years ago (I think even longer...). That is an eternity in IT. A standard is fine, but it should not stop you from playing to your strength.
Systemd argues that an init system is closely related to the Kernel and should make all the fancy kernel features available to user space. There is enough precedence for this in commercial unix variants by the way: Many come with init systems tailored to their specific strength of their kernels. I do not see that as a bad thing. So far I am not aware of anybody in the BSD camp even wanting to port systemd. At least the FreeBSD developers said they wanted a modern init system, too, but they are going for something that plays to the strength of their own kernel. So why should systemd bother about being portable to OSes that want to come up with their own solution?
That BSDs require some compatibility layer is nothing new, either. There is support for Linux style/proc and IIRC even/sys in some of the BSDs! DBus, polkit and whatnot were ported over to the BSDs, too. So how is systemd any different than those projects? You will need to implement a couple of DBus interfaces and make sure those will do the right thing. Nothing new, nothing special.
There are projects on the BSDs as well, that are non-portable: LibreSSL and openSSH from openBSD spring to mind here. Those use interfaces from the BSD kernel. There a separate porting projects that bring those code bases over to Linux. They actually introduced a new kernel API due to libreSSL into the Linux kernel.
I see nothing bad in targetting specific platforms whatsoever. Yes, I do think POSIX is important: If you can do something with POSIX, then use that. If not, then use something else. And when in doubt target one platform and let people that care for other platforms port the stuff if they care.
There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.
That person is bitching that everybody and their dog start to depends on systemd. That is your evidence right there.
Of course you have to do the dating assumption that devs do whatever they like... It kind of crumples if you assume that there are systemd hitmen traveling the world, forcing developers to depend on systemd.
The absense of CVEs can mean the absense of people looking, and with the x11 being a quagmire of protocols, often contradicting each other as new stuff gets added over the decades, there are very few people that can even understand the code. One guy started to look last a while back and he is finding appalling bugs, check the recent CVEs and his presentation at last years chaos communication congress (30C3).
Making this swamp a bit dryer by not having it have root priviledgea is something that was work in progress ever since xfree started to run on Linux.
Now you come here and tell me that this sour spot for the last thirty years is better to keep around than having a much smaller, much cleaner codebase where almost all parts run in their own security context -- usually with privileges way lower than those you have as a user. Right.
Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.
If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am pretty sure developers will support their interfaces in favor of systemd. No developer wants needless ties.
Unfortunately it is much harder to provide generic solutions than it is to provide a specific one. So devuan is in a very challenging position to make things easier for developers.
Is they blow this, then they will have more and more software that depends on systemd-only interfaces and more and more work to remove those dependencies.
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.
- An uncompelling value proposition. I don't much care about boot time
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.
- Poor architecture.
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?
- Lack of concern for the server use case, and sysadmins in particular.
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.
- Tying perfectly-good cross platform programs to Linux. Why my window manager or graphics program has to depend on init, I don't know.
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?
- Most importantly, the community is extremely toxic.
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.
And the most troubling aspect of this toxic community are the attacks on opponents.
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.
[...] No, there was outcry all those other times (in the PulseAudio case, quite rightly), but this is by far the most severe I've seen. And do any of these proponents think to ask - why? No, they decide it must just be change aversion and claim they're all just trying to set up a guild to keep their practices secret.
The outcry when the complex monster known as sysv init was introduced to replace the beautiful and simple B
Systemd is monolithic - not built into a single binary blob, but split into several tightly-dependant binary blobs.
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.
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).
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.
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.
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.).
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.
Slashdot Mirror
Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?
I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.
I also think that maintainers would not have gone for systemd if they did not think it had benefits for their users. Contrary to what you think maintainers do care for having people use their distribution. The fact that systemd had convinced developers did also factor into the maintainers decisions. So did advantages for the packagers: Getting rid of init scripts was a big part of that. There were lots of factors considered at Debian, check the CTTE discussion you liked to earlier for more.
I do not think it matters whether software depends on an init system. Software depends on other software all the time and will adapt once some better option comes along.
Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it. Never seen that before on Linux.
Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.
How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.
Please read on what POSIX is first. It is what guarantees that your software will be portable, which is a foundation upon which UNIX is built.
Yes, POSIX is important. But as with any standard it defines the least common denominator. Couple that with the fact that POSIX was not updated in years and you have to address the least common denominator from more that 5 years ago (I think even longer...). That is an eternity in IT. A standard is fine, but it should not stop you from playing to your strength.
Systemd argues that an init system is closely related to the Kernel and should make all the fancy kernel features available to user space. There is enough precedence for this in commercial unix variants by the way: Many come with init systems tailored to their specific strength of their kernels. I do not see that as a bad thing. So far I am not aware of anybody in the BSD camp even wanting to port systemd. At least the FreeBSD developers said they wanted a modern init system, too, but they are going for something that plays to the strength of their own kernel. So why should systemd bother about being portable to OSes that want to come up with their own solution?
That BSDs require some compatibility layer is nothing new, either. There is support for Linux style /proc and IIRC even /sys in some of the BSDs! DBus, polkit and whatnot were ported over to the BSDs, too. So how is systemd any different than those projects? You will need to implement a couple of DBus interfaces and make sure those will do the right thing. Nothing new, nothing special.
There are projects on the BSDs as well, that are non-portable: LibreSSL and openSSH from openBSD spring to mind here. Those use interfaces from the BSD kernel. There a separate porting projects that bring those code bases over to Linux. They actually introduced a new kernel API due to libreSSL into the Linux kernel.
I see nothing bad in targetting specific platforms whatsoever. Yes, I do think POSIX is important: If you can do something with POSIX, then use that. If not, then use something else. And when in doubt target one platform and let people that care for other platforms port the stuff if they care.
It was not possible with consolekit, great that there was progress with consolekit2.
There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.
What got vdev/udev to do with running xorg as non-root? Yes, that does initial setup of device nodes, but all the rest is handled by systemd-logind.
You are brandishing the wing stick:-)
That person is bitching that everybody and their dog start to depends on systemd. That is your evidence right there.
Of course you have to do the dating assumption that devs do whatever they like... It kind of crumples if you assume that there are systemd hitmen traveling the world, forcing developers to depend on systemd.
That consultation mongering in that link is indeed laughable.
The absense of CVEs can mean the absense of people looking, and with the x11 being a quagmire of protocols, often contradicting each other as new stuff gets added over the decades, there are very few people that can even understand the code. One guy started to look last a while back and he is finding appalling bugs, check the recent CVEs and his presentation at last years chaos communication congress (30C3).
Making this swamp a bit dryer by not having it have root priviledgea is something that was work in progress ever since xfree started to run on Linux.
Now you come here and tell me that this sour spot for the last thirty years is better to keep around than having a much smaller, much cleaner codebase where almost all parts run in their own security context -- usually with privileges way lower than those you have as a user. Right.
Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.
If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am pretty sure developers will support their interfaces in favor of systemd. No developer wants needless ties.
Unfortunately it is much harder to provide generic solutions than it is to provide a specific one. So devuan is in a very challenging position to make things easier for developers.
Is they blow this, then they will have more and more software that depends on systemd-only interfaces and more and more work to remove those dependencies.
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.
- A complete disregard for precedent.
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.
- An uncompelling value proposition. I don't much care about boot time
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.
- Poor architecture.
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?
- Lack of concern for the server use case, and sysadmins in particular.
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.
- Tying perfectly-good cross platform programs to Linux. Why my window manager or graphics program has to depend on init, I don't know.
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?
- Most importantly, the community is extremely toxic.
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.
And the most troubling aspect of this toxic community are the attacks on opponents.
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.
[...] No, there was outcry all those other times (in the PulseAudio case, quite rightly), but this is by far the most severe I've seen. And do any of these proponents think to ask - why? No, they decide it must just be change aversion and claim they're all just trying to set up a guild to keep their practices secret.
The outcry when the complex monster known as sysv init was introduced to replace the beautiful and simple B
Systemd is monolithic - not built into a single binary blob, but split into several tightly-dependant binary blobs.
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*