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

[Lennart Poettering]

On Sun, 17.07.11 06:32, Sergey (sergemdev at gmail.com) wrote:

Heya,

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

Integration avoids duplication, integration hence avoids bloat. Note
that systemd is not monolothic anyway. For example, you can just remove
the bus mechanisms, and the early-boot components and everything will
still work fine. Modularization for the only sake of modularization is
however not what what we buy into. The more you modularize the bigger
the overhead of communication becomes, and that again ... is bloat.

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, and managing those if the managers supervising them
are separate would mean complex synchronozation logic.

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.

Finally, I am also not interested to encourage too much mix and
matching, have too many variables in the installation. I want to help
streamline and standardize our platform. 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 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.

> "Why is this better?"
> =====================
> Because it's flexible, portable, simple, easy to support and it's
> unix-way.

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. (Also, I think you misunderstand Unix a bit.)

> It does not have any extra dependencies. So if someone needs to build a compact
> system for netbook with 128MB RAM he can install just `systemd` and save a few
> MB of RAM without dbus (Xorg+IceWM don't need dbus) and other systemd services.
> There's also no need in dbus on ssh/dns/http-servers.

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.

I am not sure what the folks who claim dbus was bloat are smoking, but
it certainly interferes with their ability to think logically.

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. 

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.
 
> For example, this structure forces developers (or maintainers) of every service
> to write two startup scripts - one for systemd-based script and one sysv-init
> script for non-systemd-based systems. Why not use a single script for that?
> For example instead of writing second startup script we just add the line:
>   # TCPListen: 22
> to the LSB Header of /etc/init.d/sshd. That will make transition easy and
> remains fully backward compatible. Services that don't have this line will
> be treated as usual sysv services.

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

> That also makes developers' work easier - they won't have to write two
> startup scripts and worry about compatibility.

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.
 
Sorry if this reply is harsh,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.