[systemd-devel] The Linux Way or Some ideas to make systemd better

[Kay Sievers]

On Mon, Jul 18, 2011 at 15:38, Sergey <sergemdev at gmail.com> wrote:

> It's not, if one of these two processes actually never starts (we're talking
> about separate dbus service here, right?). Instead of providing two interfaces
> (unix sockets and dbus) systemd could provide just one. Dbus interface for
> systemd is mostly unused and splitting it to a separate application that
> does NOT start by default (dbus-daemon will start it if needed) we can get
> a lot of benefits. First we're getting the ability to not install dbus on
> servers where it has no use and free a little bit of resources.

That all systemd IPC is the D-Bus _protocol_ but no the D-Bus
_daemon_. The D-Bus daemon is not needed at all if you want to build a
system that works that way.

> Also systemd
> init daemon don't have to link against libdbus any more. Fewer libraries
> linked - faster startup and smaller boot time which was the initial goal.
> These are advantages, are there any disadvantages to that? What do I miss?

sytemctl uses libdbus to talk to systemd. Now what, invent your own protocol?

> But then implementing it in a separate daemon works in both directions. It
> not only makes this feature optional, but also makes it compatible with other
> init systems. Which means that more users would be able to install and use
> it. Which means that it will spread faster. Right?

Wrong. The main goal is to have almost no dependencies to bring up the
basic services by default. If you rely on a bunch of external service
again to manage the service startup, you have all of them back, with
all the problems we have solved. You can also not really mange these
services race-free with a unified interface anymore.

>> I see no value in the portability to other Unixes. I do see value however
>> in our platform becoming stronger by removing the big variable of the OS
>> we build on.
>
> Even if you don't need it (which is pretty usual unless you're using other
> unixes), portability is still a benefit. Such benefit may bring more users
> and more developers to the project. And this is definitely good. Is there
> anything bad?

Reality showed us that the balance of maintaining the code of other
OSs in the main repository is much more work than the work the few
lines of useful code the few people of the other OSs contribute. We
tried with many projects in the past, and decided against it. The
needed abstractions are just hard to manage and get into our way all
the time.

The only really thinkable solution for the niche OSs is to port the
needed Linux interfaces to their kernels. But I guess that will never
happen, and so systemd, udev, ... will probably never happen for them.

People can try to port systemd to other OSs, we can even work together
on defining and sharing the same interfaces, but they should use git
and rebase their patches, instead of merging the code into the Linux
git repository.

> Just curious, what's wrong with SysV scripts? And how is it possible to
> request status of arbitrary service without them? I mean, you can tell only
> whether it was started or not, but only SysV script knows i.e. is it alive
> or frozen.

They are _programs_, not _descriptions_ what a service should do. We
need machine-readable and user-interface-manageable service
descriptions, and not free-text, sometimes insane programs to bring up
services.

>> Upstream developers generally do not write init scripts, package
>> maintainers do, simple because you have tow write different ones for
>> different distros. Which coincidentally is something systemd fixes.
>
> LSB standard does the same thing. If people don't want to conform to standard
> it's not the problem of standard. But if they don't want to follow LSB
> standard what makes you sure they will follow yours? ;)

We are not even thinking about creation any new 'standard'. :)

Kay