[horusthecat]

It's not a holy war, but it does have a lot of politics, which engineers like to pretend don't exist.

Here is the only solid criticism of systemd I've read that focuses on design (as opposed to bugs that surface from the sprawling throw-it-over-the-wall approach to development): http://blog.darknedgy.net/technology/2015/10/11/0/

Notably, darknedgy hosted/hosts uselessd, which was a lightweight version of systemd. On the whole i think the idea underlying systemd, of graph-based management of services and system state makes more sense that wonky initscripts garbage.

Technical discussion aside, I rarely see mentioned is that, what in my opinion, systemd resembles a lot of "politics-driven-development" i've worked on before. It's sprawling and ambitious--which means bugs--and like a high-politics project there's a certain incentive i perceive to downplay bugs--which also means it's a great way for RHEL to centralize control over things they didn't have say in previously as well as standardize, etc.

I'll go ahead and beat up on it more by saying that if the project is going to be used cudgel-like, I wish it would more loudly start talking about stuff like formal analysis, fuzzing etc., because it would be a great opportunity to promote research-y stuff in the "email your patches" world of OSS development.

Which is fine, but running Arch workstations for nearly ten years now, there's been a lot of gore with systemd... more than i'd like to see in PID1.

Of course, I hate writing C code with a passion so I'm just a whiner really.

[rst]

To some of us, the "sprawling throw-it-over-the-wall approach to development" is the problem. Particularly when they decide to reimplement services instead of using battle-hardened code, and revive old bugs that haven't been seen in the wild in years. As has happened with their DNS resolver, which was initially shipped missing measures that everyone else had shipped years ago to deter cache poisoning, and had buffer overflow problems on top of that.

There are not fundamental design flaws. They don't have to be, to be a problem. And it's a problem exacerbated by the developers' typical response to problem reports -- to try to transfer blame, or treat them as personal attacks, rather than dealing with the issue. An example of that is CVE-2017-1000082 -- a rare example of a real problem that was assigned a CVE number by request of someone other than the developer, because the developers are still insisting, after a week of well-deserved mockery, that it's not a problem (or not their problem, or something)...

Refs:

Buffer overflow: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn...

Cache poisoning: http://seclists.org/oss-sec/2014/q4/592

[jwilk]

> CVE-2017-1000082

This was discussed here: http://www.openwall.com/lists/oss-security/2017/07/02/1

> a rare example of a real problem that was assigned a CVE number by request of someone other than the developer

It's fairly common that the security researcher requests CVE. CVE request by an affected distro (which is what happened here) isn't anything unusual either.

[JdeBP]

It was discussed a whole lot more in these places:

* https://github.com/systemd/systemd/pull/6300

* https://github.com/systemd/systemd/issues/6277 (https://news.ycombinator.com/item?id=14681377)

* https://lists.freedesktop.org/archives/systemd-devel/2017-Ju...

* https://news.ycombinator.com/item?id=14682210

[KirinDave]

"Battle-hardened" code is a myth. Please do not appeal to it. Either you're doing the hard work for security or you aren't.

You do not need to experience a breach in advance to have a hope of stopping a breach.

Besides, if people cared about security they'd use tools and languages and runtimes that help them test thst code works right. They don't, by and large.

[echaozh]

Hey, systemd has to be shipped when it's immature because you need users to try it out and help catch all the bugs and insecurities. Now you say battle hardened code is a myth.

Sure, people should audit their own tools, but there are also casual users. And there are indirect users. They are entitled to enjoy the better (if not perfect) security provided by battle hardened code.

[KirinDave]

I'm not sure why you're attributing that argument to me, but please don't fall into the habit of merging all the people who disagree with you in a thread into some kind of intellectual chimera.

I've even said above I agree with criticisms that systemd didn't plan and was deployed too early and too fast.

[dozzie]

> On the whole i think the idea underlying systemd, of graph-based management of services and system state makes more sense that wonky initscripts garbage.

It would make sense if systemd delivered on its promise of automatically detecting service dependencies (through socket activation mechanism). In practice, it's still distro maintainers and sysadmins who need to specify any and all dependencies manually, and as such, systemd is in no way better than what we had with upstart or Gentoo's old initscripts (those before OpenRC).

[ilovecookiestoo]

> It would make sense if systemd delivered on its promise of automatically detecting service dependencies (through socket activation mechanism).

New features require time to gain wider adoption. Some services already support this, but most don't (yet).

[dozzie]

This particular feature could be (quite easily!) implemented without much help from the daemons themselves, at the cost of duplicating the config option of listen address. To make the matter funnier, this is doable with mechanisms that were adopted in unices in '90s. This is why systemd underdelivers on its promise of automatic dependency detection.

[KirinDave]

I joke that I'll stop using systenmd if "you" stop writing C. Thoughtcrime for thoughtcrime. ;)