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".

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

or

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.

> "it's different and therefore I don't want it"

The argument is really that given that systemd as a project does a hell of a lot, it's actually really hard to replace bits of it - as people who are trying to are quickly finding out, there's a few dependency trees for various components which end up requiring that systemd manages most layers of the system. So you either use all of systemd, or as little of it as possible.

According to Lennart Poettering himself, udev is going to end up depending on systemd being the init system. udev! It'll be damn near impossible to replace systemd then. (And anybody who wants to use anything else, or even have the choice to use anything else, is a "systemd-hater".)

There are a lot of reasonable criticisms about the systemd family of utilities. I am very skeptical to the utility of binary logging for example. It makes an effort to guarantee integrity but does not make any guarantees and is useless in the face of an adversary.

I also have a suspicion there is a more friendly way do what PolicyKit provides, which is not at all very transparent to an administrator. You could easily trust software with privileges without realizing it. There are also concerns about the hard dependency on these utilities for GNOME, but I don't use it myself so I don't know if the concerns are valid or not.

I believe however most of the criticism centered on how udev was dropped as a separate utility, despite concerns from other developers, and the way people who tried to keep feature parity in a stand alone fork was treated. They was basically told they were regarded as downstream developers.

This is mostly water under the bridge now of course, but it makes cooperation a lot harder than it should be.

journald's Forward Secure Sealing is an easy to use integrity mechanism that was previously unavailable in text-based syslog implementations... of course it cannot prevent your adversary from deleting all the logs, but at least that can be reliably detected.

http://lwn.net/Articles/512895/

And rsyslog can cryptographically sign logs too nowadays:

http://blog.gerhards.net/2013/05/rsyslogs-first-signature-pr...

> systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument).

That's not debunked. The small tools of the UNIX philosophy are supposed to compose well with others. If I want to replace systemd's init with that from daemontools (for instance) and keep the rest of systemd working, that should be possible.

Or let's suppose that I want to opt in to systemd's auto-remounting and socket activation (for instance), but for whatever reason I need to keep my syslogs as text on disc, so I can't use systemd's binary logs but need my legacy syslog system. Can I do that?

> I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it".

The arguments I've heard boil down to "it's badly designed and therefore I don't want it."

yes you can

/etc/systemd/journald.conf ForwardToSyslog=True

systemd-journald is only one component, there are more than 50, and if you only want one piece of that, tough luck!

that seems unfair - on one hand, there are people complaining that systemd is too monolithic... on the other hand, we have people saying there are too many components !

Come on, this horse has been beaten to death already...

I'll just say, a GNU/Linux distro has many components, but they're not monolithic because they integrate well, you can do ls|grep etc, you know this. But if we want to change one component of systemd, we can't do it! You see? A lot of components, but they comprise a blob and can't be separated or used individually.

In a funny way, you've just proven my point. I'm talking about a whole class of problems caused by systemd's design, and you've provided a case-specific hack which happens to work in one instance I picked, leaving every other case where I might want to opt out of part of what systemd provides unsupported.

Have you ever noticed that it's really hard to replace the IP stack in Linux with the one from FreeBSD? Clearly that proves that Linux never followed the UNIX philosophy in the first place and we should never have switched away from MINIX.

> I really don't get the systemd "hate" that is still floating around.

I found a message that might shed some light on it:

"[...] Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone without any noise?"

http://lists.freedesktop.org/archives/systemd-devel/2014-Oct... (read the whole message, it's quite interesting).

Systemd is great. I've used sockets for ssh, I use the timers instead of cron, everything goes smoothly and works really well.

I don't get the hate, I love it.