Hacker News Reader

Comment by deong | Hacker News Reader

As another article I read just today pointed out (in a completely different context), the point of Unix isn't the number or size of the tools. It's the composability of the tools.

systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence.

And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".

View on HN

Serious question: in what ways would you want systemd commands to be composable? I'm struggling to think of a use case for being able to pipe a service name into systemctl (or "service" for that matter) and its output is reasonably grepable for running|failed etc (and more consistant the old SysV scripts)

I'm guessing you want more then that though right?

Conceptually composable. The logging in systemd sucks, sorry but true. Binary logs? LOL. Someday if rsyslog could speak raw systemd language as an input, that wouldn't be quite as awful. Then you could have systemd talking to a real logging platform. Just like "ls" can talk to "grep". Doesn't mean the talking can only be in the format of a pipe or whatever.

/etc/systemd/journald.conf

ForwardToSyslog=True

systemd.journald.forward_to_syslog=True on the kernel command line.

Is it just cool to not read documentation anymore?

To say that this is not fair would be an understatement. systemd-journald is only one component, there are more than 50!

Journald is still there. So are libqrencode and libmicrohttpd and (possibly) the hook for the coredumps (that is now reverted in systemd 214 when - after almost 2 years from the first bug opened on the matter - they discovered that hard limiting a core dump to around 700MB using a #define and without respecting ulimit was not a good idea.[1]).

Systemd components are NOT interchangeable with something else, so let's stop pretending they are. Please.

[1] CentOS and RHEL 7 ship with an earlier version of systemd, and I'm not sure if the packages have been patched in some way or not to fix this. If not, good riddance if you are a sysadmin trying to pass core dumps along to developers.

Thats not what I'm asking for.

Theoretically my configuration would look like rsyslog linking in a compatibility library and having something like this small config snippet from /etc/rsyslog/rsyslog.conf of the future:

# Connects rsyslog directly into the innards of systemd

$ModLoad systemd

I wouldn't even have journald installed on my system, at all. No config file named /etc/systemd/journald.conf, none of that. Just rsyslog.

That's like saying HN website is composable with emacs because I wrote this on emacs and then cut and pasted it into the browser. Really being composable would imply meta-x post-buffer-to-hacker-news direct API on emacs.

It doesn't really matter to me because systemd is going to force me to convert my systems to freebsd. But if I was staying on linux, I'd like systemd to at least minimally cooperate with the rest of the ecosystem instead of spreading like a cancer.

In autofs (which has handled demand-based auto-mounting of network shares quite nicely for decades), you can write executable scripts to handle service discovery for different file-sharing protocols.

In ISC DHCP (I don't know if systemd is handling dhcp or not), you can add shell scripts as pre or post configuration hooks. I set up a cluster where the local hostname is set from DHCP/DNS, rather than vice versa.

Me personally? Not really. Like I said, I've been using it for a while and it's fine, but I also haven't tried to "stretch" it yet, so my experience doesn't really mean that much one way or the other. It's pretty simple to make something that works well most of the time. It's harder to do that in a way that still works well for the weird corner cases. Shell scripts sitting in a directory waiting to be kicked off by init are supremely flexible in that regard. I'm less confident in the future of systemd that this will still be the case. It's a lot harder to customize the way my Mac boots than it is to customize an old slackware install.

But mostly, like I said, it's just ugly. D-bus? Binary logs? Sure, you can build a working system like that, but just ugh.

Reply on news.ycombinator.com