> As discussed here: http://0pointer.de/blog/projects/systemd.html

Lennart Poetterring claims that you should use his software instead of someone else's software! I'm SHOCKED! Full story at 11.

Seriously now, did you honestly think that he would say to use xinetd over systemd? Do you honestly believe a developer will advocate the use of a competing piece of software over something (s)he produced?

> There absolutely is a ton of overlap between what systemd does with socket activation and what Xinetd has evolved to... but as with evenone else doing OS design, there comes a point where you leave Xinetd behind and let the full potential of that trick work in your favour.

Unless you don't feel like replacing small, simple, easy-to-use, well-tested xinetd with the 200K-line pile of C code that is systemd.

Besides, I've got your socket activation right here: Start the daemon, have the daemon open a port, and let the kernel swap it to disk. The kernel will swap it back in when it receives a connection for it.

Benefits:

* the daemon preserves state between "activations" for free

* the kernel gives you this feature for free

Security:

* the daemon doesn't have to trust another userspace program with anything

* the daemon can use mlock() to prevent sensitive pages from getting swapped

* if this isn't enough, you can encrypt the swap partition to resist offline attacks

Resources:

* If disk is too expensive, disk is read-only, you have no swap, you have no CAP_IPC_LOCK, the daemon would need to mlock() too much RAM, and you can't encrypt your swap, there's xinetd.

* Need to apply filters or QoS controls on connections before waking up the daemon? That's what the firewall is for.

Trivia:

* You can have xinetd trigger whatever event you want, since all it does is fire up a program and run it. This includes alerting other programs, like a service manager, that it got a connection, and maybe even sending along the message (or the file descriptor) if you want. There is no need for systemd to subsume this responsibility.

As you can see, "socket activation" is by and large a marketing gimmick.

> Me and the folks at Wikipedia:...

You think an article that compares data serialization protocols somehow proves your ludicrous claim that human readable text is less readable than marked-up text? Maybe daft was too nice a word...

> Ah, so it is much more modularized if it runs as an executable piece of code in process than a piece of executable code out of process. Got it. ;-)

Sir/madam, have you ever written an Internet-facing daemon? Obviously the bulk of the RPC logic lives in a shared library. You know, a logically distinct module that can be independently installed, loaded once, and independently maintained.

Besides, procedurally-generated RPC-handling code adds no technical debt to your project, anymore than the compiler's generated assembler output does.

You seem to want to replace the RPC shared library with a separate process. Not only will this make create a performance bottleneck, but also it makes it a single point of failure. If it crashes, all your daemons lose their connections. This is obviously highly undesirable, especially on servers.

> Well, that's the discussion you're having. I'm trying to talk about the design constraints and appropriate solutions for the problem domain...

I think I'm done with you. You deserve everything systemd will ever do for you.