>Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well.

And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true.

>In fact, udev merged with systemd a long time ago

systemd relies on udev and dbus, but udev doesn't pull in systemd as a hard dependency: another falsehood I've seen parroted by those in support of the eudev fork.

I'd be very interested to see a qualified crypto expert on the "sealing" that journald uses. This is one of two indicators of a troubling level of arrogance from the developers. The crypto method used by journald to verify messages haven't been tampered with is called Forward Secure Sealing [0]. It's based on an invention of the brother of Lennart - the lead developer, and for a long time after first release even the whitepaper describing it in detail was "coming soon" The code he finally produced is [1] - but rather light on documentation. I'm still unaware of any proper analysis of this, and using your brothers own crypto methods and ignoring all the questions this has raised does not come across well - and appears to seriously violate the "don't roll your own crypto system" rule.

The second indicator is the attitude to bugs, of which [2] is a good example - several of the developers appear to be extremely defensive towards any suggestion of defects in their software, and simply close bugs blaming the users, other software, anything else.

I'd be hopeful that RedHat manage to reign this behavior in, but that didn't seem to work for Ulrich Drepper when he was employed by RedHat to work on glibc, and I'm not sure if it's going to work here.

That said - I'm not in the "systemd is awful" camp - I do think there's a whole bunch of things it does really well, and that a lot of the hate is really quite reactionary - but the thing that frustrates me is that between the haters and the supporters, there are important questions that are getting lost in the noise.

[0]: http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

I just can't agree with your [2] as a problem. The actual problem (an assertion failure in systemd) was fixed, several alternative workarounds are provided in case the user can't or doesn't want to upgrade systemd immediately, and functionality changes about when and where and how to log were going on on the mailing list, as they should be, and the reporters were directed there politely, even after violent vitriolic attacks. After discussion concluded on the mailing list, systemd was changed to direct debug logs away from kmsg as soon as journald is available.

I can't find anything to complain about from the systemd team on that bug report. I'd just dismiss it as varying personal standards of politeness, but the complaints on that bug report are themselves far far worse, with vitriolic abuse and death threats, so there's got to be something else going on here.

There's also this: https://bugs.freedesktop.org/show_bug.cgi?id=73729

Their attitudes towards journal log corruption have been rather apathetic, as well, though I cannot find the particular bug report at the moment.

That discussion escalated quickly.. What i got from the thread is that systemd will only work with glibc, intentionally? If that's the case then it's kind of sad. Since systemd will become the standard glibc will be the only alternative.

Relevant work in the area is Log Hash Chaining as described in RFC 5848, which at least has been through some peer review.

I don't know why they chose to ignore that, let alone what their design is really supposed to guard against. Their design allows an attacker a window of 15 minutes where they can rewrite the log at will.

So the short of it is: Keep using remote logging. Authenticate that. Don't rely on journald.

(I too have had Drepper vibes about the whole situation for quite some time. But a new init standard was long overdue and if distros can finally rally around systemd it might be worth it.)

I like linus comment[0] about a workaround on the issue in your 3rd link.

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

From your [2]: Like for the kernel, there are options to fin-grain control systemd's logging behaviour; just do not use the generic term "debug" which is a convenience shortcut for the kernel AND the Base OS.

[2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

all I got from [2] is "if you would like to have productive discussion, move to the mailing list. if not, prepare to be banned."

Optional, but enabled by default. Most distros seem to ship with defaults and only customize flags related to library paths and FHS details (besides whatever patching they may apply). The fact that it's even there is distressing enough, really.

No one is saying udev pulls in systemd as a dependency. Where is that said?

>Optional, but enabled by default

Where is it enabled by default? In what distro does gatewayd get pulled in by default?

>No one is saying udev pulls in systemd as a dependency.

By the eudev hobbyists, whose justification for their fork was largely "we don't want to force people to use systemd" and "no, we didn't contact upstream with fixes before we forked" in their presentation.

Why do people use words like "violent" to describe the decision to change process launchers? Maybe if they'd toned down the rhetoric just a tiny bit that campaign might've worked better.