On Tue, 8 Jul 2014 12:39:02 +0100 Darac Marjal <mailingl...@darac.org.uk> wrote:
> 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). Timestamps are a must. > > 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. Or, you could simply define what a timestamp looks like in logs, even if it's seconds since epoch. Or reversely, you could allow any number of timestamp forms in a binary file. At least if it's text based, a human can look at it, determine what fields are what, and parse with sed, awk, grep, cut, etc. If it's binary, you're SOL without a spec or a viewer. > > > > > 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 I don't see anything compelling in that explanation. I might end up using djb Daemontools to instantiate and control a lot of my daemons. At least Daemontools is easily understood, configured, and changed. It basically just keeps track of, and reruns if necessary, a shellscript. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140708162251.5b839...@mydesq2.domain.cxm
