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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
