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.

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.