On Tue, Jul 08, 2014 at 01:00:24PM +0200, berenger.morel@neutralite.org wrote: > > [cut] > > Indeed, since starting programs is the exact goal of the first PID process. > Plus, stuff from systemd is far easier to understand for a beginner (systemd > beginner and sysvinit beginner, I insists on this). > This dependency managing of dependencies is another advantage of systemd, > but I'm not sure it means that other softwares should have hard dependencies > on systemd, or that things like journaling, and others pieces of system > should be related to the first process. > > Journaling for example should be, imho, managed in the usual way: we use > stderr in programming, which is traditionally text. Since I'm not an expert > at all, I can only guess that PID1 have to define the various std* streams, > but if someone wants binary stuff, why not simply redirect those streams to > an different application? What would be the problem with that? I'm sure someone will correct me, but as I understand it, journald does work a bit like this. It captures the stdout and stderr of the process it starts (so that, in case of an error you can say "tell me what happened when to tried to start that daemon. SysVInit can't do that on its own, but programs like bootlogd help. Without bootlogd, you're left with re-running the initscript manually, which might not produce the same error). However, the storage format it uses "adorns" the output with extra information (I would imagine things like timing, possibly which stream the text belongs to and I believe there's also a checksum to avoid tampering/corruption). In my opinion a binary log format is probably more robust than a text format simply because it's well defined. Just as an example, there's no defined format for the timestamps in a syslog. But with a binary format, you can probably say that bytes M to N are a unix timestamp in some-endianness and any other format is junk data. > > Why should desktops and end-user applications have to depend on systemd's > parts? For mpd, for example. Ok, it's started as daemon by default, but > users can run instances of it for themselves if they want, and mpd is > portable. Why should it have a hard dep on libsystemd-daemon0 (it had no dep > like this previously, and I doubt mpd will stop their support for windows or > bsd... so it must be enabled by some sort of flag?). There's a nice explanation here[1] of what linking against libsystemd-daemon0 does for a program. > Indeed, it's not systemd's fault if those applications depends on it. But > it's a part of the noise around systemd. > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743941#10
Attachment:
signature.asc
Description: Digital signature