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

[Sergey]

2011/7/17 Lennart Poettering wrote:

> sorry, but I am not interested. Unix is an inspiration but it is not
> dogma.

True. All those words "Unix philosophy", "flexibility", "portability"
really don't mean anything. Same as words "duplication" and "integration".
They're... just words. They either give a hint about the best solution for
problems, or they don't. Problems are the only real things that must be
adressed.

> Modularization for the only sake of modularization is however not what
> what we buy into.

Of course, and this applies to any development. Integration for the sake
of integration is no better. That's why I was trying to explain every idea
and every suggestion in detais, to show advantages and disadvantages of
each solution.

For example one of benefits of modular structure for systemd is that other
developers may work on it, i.e. write some runner plugins for systemd that
they need. You won't have to worry about them, you won't even have to know
about them. And more developers interested in the project is good, right?

> The more you modularize the bigger the overhead of communication becomes

Only if modules are in separate applications. If modules are just plugins
loaded with dlopen() there's not much difference in communication there.

> Also note that there's a reason why sockets, services, mount points and
> so on, are all handled in the same concept of units: they have complex
> interdependencies

There's no need for dependencies if everything is started in parallel. :)

Really, I was wondering about that. I can think of dependencies between two
services, for example [iptables] and [sysinetd] from the previous email
(reason - sockets must not be created before iptables applies all the rules).
But can you name any real case where dependency is needed between a service
and a mountpoint?

> In addition, you are very much overestimating the code size of the socket
> handling, and similar code. Splitting short code like tht into separate
> processes is wastage.

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. 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?

> That means I want to allow developers to rely that certain features in
> the OS are available, for example socket activation -- so that they
> actually use it. Hence making that optional would be diametrically against
> my goals.

I assume what you're calling "socket activation" here is the ability to
create a socket outside of the application to allow parallel startup -
the thing that were done by `sysunixd` and `sysinetd` in my example. Then,
yes, I agree, it's a good idea and implemented by mainstream developers
it would be better than patched by distribution maintainers.

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?

> 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?

> Well, it's neither more flexible nor simpler or easier to support. And
> portabality to other Unixes or being the "unix way" I don't consider
> much of an advantage.

A "unix way" was just an inspiration for the ideas I wrote about.

> Not using D-Bus wastes memory, since programs have to reinvent their IPC
> systems each and every time. 1 good IPC instead of 20 fucked up ones
> means using less resources, having more security, more simplicity, and
> more transparency.

DBus is good in certain cases of course, but it's not a panacea either.

> The idiocy of people who believe they could just remove the IPC from
> their system and everything would still be able to communicate as before
> but using fewer resources is amazing.

The matter is not in communication between each other without IPC, but
in the fact that there may be nothing to communicate. Whom can init-daemon
communicate with on ssh/ftp/http-server? (and servers market is where
Linux is the most widely spread)

> You are welcome to question the implementation of D-Bus, but if you
> question the existance and need for it then this says more about your
> nescience than about D-Bus.

I'm not questioning its existence in general, it would be stupid. I'm
questioning its existence in the main daemon, since it's mostly unused
on the desktop and totally unused on servers. Why not move it to the
separate service, that is autostarted by dbus-daemon only when it's
needed? Daemon will have fewer dependencies, fewer libraries to link,
that would make it eat fewer resources (no need for dbus tracking - fewer
CPU usage, longer battery life), make it more reliable (won't crash on
an accidentally broken dbus update), smaller and faster.

> I am not interested in that. If people want to keep using SysV scripts,
> it's their own burden.

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.

> 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? ;)

> Sorry if this reply is harsh,

No problems about that. :) Constructive criticism is always good in any form.

-- 
  Sergey