Why systemd?

Wow... we've come a long way baby! Now freely available software that you can modify as needed without interference is taking away your freedom! ;-)

> I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd.

Actually, the problem is that if you load IPv6 support after a socket was created, there's no efficient way to make that existing socket compatible with IPv6, which of course creates a nasty little integration problem. That wasn't a choice of the systemd folks, that was a choice of how the kernel folks organized their network subsystem & modules.

Systemd runs fine on my system with no IPv6 support.

> Sure, you're "free" to use something else, in the same way that you're "free" to patch and recompile every program that touches it to stop touching it. So "free" in the FOSS sense that nobody but developers care about.

For all the complaining about NIH syndrome and absorbing other projects for political purposes, systemd actually builds on top of a lot of very well established components (dbus, udev, etc.). To the extent that software gets tightly coupled with it, it wouldn't be hard to change it so that it used those standard components without systemd... unless systemd is actually providing some unique advantages for that software that you can't live without. In which case... go out and do a better job of it!

> I'm annoyed that this software is doing 5000 things where one would do.

I know, Unix is annoying that way. ;-)

~ # for file in `equery files openrc`; do [ -f $file ] && echo $file; done | xargs wc | tail -1 23729 196573 7432232 total

Oh, and that's with lzma compressed man pages.

I suspect he was referring to socket activation and how that simplifies these kinds of messes.

> Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others.

Right... so that's exactly what systemd did. It used Dbus, which provides that standard serialization format. Not my favourite format, but very well established and tested and focused on systemd's problem domain.

The point is, in order to have loose coupling between components, something like unix pipes is just a starting point.

> Does the pipe know what's best for every single application that will ever use it?

Ah, now I understand the problem with systemd. I never realized it was trying to take over every application's communications protocol! ; -)

Seriously, I think it is perfectly reasonable (and necessary) to define a standard protocol for system even notifications... I say this because it has already been done... by the standard compoents like udev & dbus that systemd is building on top of...

> Last I checked, you pass file descriptors via UNIX sockets, not pipes.

Correct. People have a tendency to mess up their semantics though. If the original poster wasn't referring to unix domain sockets, than it is an even sillier question.

> It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time.

Yes, but you do need something more sophisticated than a pipe to manage secure communications between your systems components.

> Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.

? D-Bus will drop you like a hot potato the moment you fire off invalid messages. You could send valid messages with fraudlent/misleading data payloads I guess, but at least a whole host of problems are addressed by tightening that up.

Systemd does more than just init, it has the features to replace everything from network manager to fstab. It is not just an init system it is an invasion of Linux userspace.

Don't take my word for it, just read the developers blog:

http://0pointer.net/blog/projects/fudcon-gnomeasia.html

   > The author of this piece makes the classic mistake 
   > of equating the init system as the process manager 
   > and process supervisor. 

In the interest of full disclosure I must admit I was on duty when AT&T and Sun were creating the unholy love child of System V and BSD, I'm sorry.

The architecture, as bespoke by AT&T system engineers, was that process 1 was a pseudo process which configured the necessary services and devices which were appropriate for an administrator defined level of operation. Aka a 'run level.' I think they would have liked the systemd proposal, but they would no doubt take it completely out of the process space. I am sure they would have wanted it to be some sort of named stream into the inner consciousness of the kernel which could configure the events system so that the desired running configuration was made manifest. They always hated the BSD notion that init was just the first 'shell process' which happened to kick off various processes that made for a multi-user experience.

Originally users were just like init, in that you logged in and everything you did was a subprocess of your original login shell. It was a very elegant system, root's primal shell spawned getty, and getty would spawn a shell for a user when they logged in, everything from that point on would be owned by the user just like everything that happened before was owned by root. The user's login shell logged out and everything they had done got taken down and resources reclaimed. When the root shell (init) logged out all resources got reclaimed and the system halted.

But Linux, like SunOS before it, serves two masters. The server which has some pretty well defined semantics and the "desktop user" which has been influenced a whole bunch by microcomputer operating systems like Windows.

I wasn't the owner of the init requirements document, I think Livsey was, the important thing was that it was written in the context of a bigger systems picture, and frankly systemd doesn't have that same context. I think that is what comes across as confusion.