[systemd-devel] Please proof-read: systemd’s dependencies and installation footprint

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jun 08, 2013 at 03:14:45PM +0200, Michael Stapelberg wrote:
> Hi,
> 
> I intend to publish a document about systemd’s dependencies and
> installation footprint (along with a blog article) to a wider scope soon
> and would like to make sure I don’t publish anything which is plain
> wrong.
> 
> Therefore, I’d be thankful if you could proofread
> http://t.zekjur.net/dependencies.html and let me know if you see
> anything wrong there.

"The binaries systemctl (299 KiB), journalctl (187 KiB) and loginctl
(91 KiB) are the main binary to use for respective part of system"
→ it's a bit unclear what "to use for" means in this context.

"pixel-perfect" → not true for a long time, since now we do coloring
and such, maybe "character-perfect" would be more adequate

"journal log" → journal

"since PID 1 is running permanently" →  also true for a few other
daemons.

"there is no cyclic dependency" → actually there's a *compile time*
cyclic dependency, so it might be good to add an adjective that makes
it clear that you mean startup order dependency

OK, you start talking about systemd, and than about libudev, and
serial ports, and it all becomes really muddy. Maybe it would be
better to first get systemd-udevd out of the way, especially that
udevd is used by everybody, so it is always loaded anyway, so the cost
of libudev.so.1 in PID 1 is nearly nil.

"To be honest, I don’t quite understand why this code is not inlined
into systemd. " → why should it be? It is rather worth explaining why
there's so much stuff in systemd. There's a reason why other code *is*
inlined into systemd, when it *could* be provided as a shared library.
The stuff that is part of static libsystemd-shared during compilation
is inlined and not shared between all the systemd components as a
shared library because it would have to be installed in /usr/lib and
other people could link against it. But we don't want to provide any
promises regarding the stability of the internal library API, so we
take the (small) cost of static linking over the hassles that come
with having a private library in a public place. There's no such
consideration for libsystemd-daemon, because it has a public API that
is stable.

"helper utilities" → why are there crosses and check marks, what's the
difference?

"systemd-shutdown PID 1 will be replaced with this binary" → when?

Maybe mention that systemd-shutdown is statically linked (I know it
can be inferred from the text, but being explicit might be better).

"Debugging, interactive tools, shell helpers ... systemd-readahead":
I would say that systemd-readahead doesn't really fall into any
of those categories.

"systemd-nspawn ... for debugging" → not really, since it has gained
the ability to socket activate containers, people use it also for
production (e.g. compilation chroots, web server environenments, etc).

"systemd-detect-virt ... Depending on your environment, you might not
want to start certain services — for example udev does not make sense
in an lxc container" → this is a bit misleading, because services
would be started or not using systemd's built-in ConditionVirtualization,
and this binary is for other uses.

"so that the only thing journald does is passing information to syslog"
→ it also stores stuff temporarily in tmpfs.

What I'm missing from all this, is the answer to the question set
forth in the title: what is the *total* footprint of running a normal
systemd installation (I'd be happy to see some good statistics and
analysis!). PID 1 is probably the heaviest, but journald also
contributes, and it would be nice to see the whole picture.

HTH,
Zbyszek