Re: I'm not a huge fan of systemd
On Tue, 8 Jul 2014 12:39:02 +0100
Darac Marjal <firstname.lastname@example.org> 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
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 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.
> : 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
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance