[systemd-devel] What I think is really wrong with systemd

[Lennart Poettering]

On Wed, 16.09.15 09:47, dottomi at gmail.com (dottomi at gmail.com) wrote:

> Now, as was written in that post, the project consists of over 69
> binaries, where most of them are entirely optional.

It's 119 executables now, btw.

> The problem with this project is not how it is written.
> It is how it is *packaged and distributed* to end-users.

systemd is not a product for "end-users". It's a set of basic building
blocks distributions can build an OS from. It's not an app you
install. Also, even if it was an "end user" product, we don't actually
provide packages, not even dist tarballs. We provide people with
sources, with a git tree, and it's up to them how they decide to
package that.

> Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server?
> A system logger? Something that uses QR codes? Can I replace it with
> another package?
> 
> The answer is: no one but the developers know.

I am pretty sure the packagers know pretty well how they decide to
package systemd.

> The package doesn't even have an understandable version numbering. It
> is one increasing number. How is a package maintainer supposed to know
> if version change from 340 to 341 introduces major changes? I don't
> even know *what* changed unless I read a ChangeLog.

Well, it's supposed to be a steady stream of smaller additions instead
of major feature additions in long intervals.

Also, as we are not an end-user product, we don't market things to
anyone. Major/minor version numbers are a marketing tool, that's all,
and as that's not a priority for us, hence we don't do it. If you so
will, the only folks who should care about our updates are those who
are technically versed enough to not need version numbers, but who can
read our NEWS files. 

> What this project needs is division of this one big have-it-all
> package into individual packages, each containing components for a
> specific purpose. 

Like the linux kernel we keep all components of our system together in
one repo, under a single release schedule and without stable, internal
APIs.

Splitting things up into multiple projects means more code duplication
(since you cannot share code as freely), means commiting to stable,
internal APIs, encourages bitrotting, and increases complexity, at no
gain.

Also, it's pretty irrelevant how we distribute things, downstream
packagers should decide how they package things, and if they do that
in one, or split out. By having everything in one tree, we simplify
everything drastically, while still giving downstreams the chance to
split things up, if they wish.

> There is nothing wrong with them depending on each
> other, but they should be in different packages, each having a
> separate build system and version, for the following reasons:

Nope, no way. We need to keep things maintainable. And you don't make
things maintainable by exploding the number of packages, by forcing us
to stabilize internal APIs and by creating a network of versioned
dependencies (dependency hell!) between these packages.

> 1) You as developers are more aware of what changes in the project,
>    beause commits are associated with individual componenets.

I am pretty sure watching one repo is much easier than watching many.

> 2) If a component was a failure, you can just drop
>    the package and work on another - nothing else needs work.
>    Most importantly, the main component is not touched.

We can drop things from our git tree from time to time, that requires
no splitting up of repos.

> 3) The people that are not involved with the developement are more aware
>    what the suite of packages called systemd is actually composed of.
>    Package maintainers can now block one component if there is
>    something wrong with it, but not all the others.

Talk to your distro maintainer.

> 4) The user can then install the init system from systemd, and keep
>    their system logger. Example: systemd-logind should not pass the
>    messages to another logger. The other projects should be encouraged
>    to use systemd APIs/ABIs on Linux to get them.
>    This makes systemd-logind more lightweight.

Hmm? by not using systemd's APIs directly, but by abstracting things
away and not being able to rely on the availability of a single
backend you certainly make things way heavier -- certainly the
absolute opposite of "lightweight".

Not having to care about stability of internal interfaces, sharing
code, and being able to rely on the same set of backends in the right
version makes things lightweight and robust, since you don't have to
deal with multiple codepaths, with abstracting, with versioning, and
dependency hell.

> 5) Most importantly: by such a split you future-proof the project
>    as a whole. Someone might come up with a better solution for
>    a component than you in the future. That someone should not fight
>    with your system in order to use other components. It should be made
>    easy and simple to replace any binary systemd uses now
>    with another - with another PACKAGE.

The sources are open. Anyone can fork systemd and rearrange it the way
they like. There's no point in us doing that for them. People can do
that on their own.

> If systemd keeps going the way it does, it will eventually get forked,
> because it will become an unmaintainable mess when you notice
> something major in the system could be done better, and that better
> approach breaks everything else in the system. systemd works fine.
> NOW. I also would want it to work after 20 years, because I see good
> ideas here.

Well, let's see. 

Also, what's so bad about a fork, anyways?

You know, you can make all your points against the linux kernel too,
which contains so much stuff in one repo: different subsystems, file
systems, drivers, and even userspace tools. It even includes it's own
implementation of a build system! It's humungous! systemd and the
components it has are a fraction of that, and hence I think we are
good!

To put things in perspective: all of systemd 226 has 363K lines of
codes now --- the exact same amount wpa_supplicant has as of today!

As long as all of our code together is still not larger than that
little daemon that encrypts your wifi traffic I think we are good. If
you think that systemd is too large, then wait until you see the SLOC
count of the kernel, of glibc or even X11!

Or to turn this around, please work with the wpa_supplicant people,
the glibc people, th kernel people, and so on, and ask them to split
up their packages! Thank you!

> Actually, I think this project's future is a "Linux-based Init and
> Service Management System Standard", where the systemd suite
> of packages is the reference implementation.

Yeah, but no. I doubt writing standards like that makes any sense at
all... Sorry,

Lennart

-- 
Lennart Poettering, Red Hat