Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven.

But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop".

Who then decided to reinvent everything along the way like log storage that still takes over hundred of file opens (and tens of seconds) to get "the last 5 log lines of a command" ( https://github.com/systemd/systemd/issues/2460 ), because why the fuck use say SQLite when you can have fun evening inventing your own shitty binary journal format.

I do find a lot of stuff behind systemd useful but the ever-present half-assness of its solutions is annoying. Half-assed logging here, half-assed dhcp client there, quarter-assed ntp client elsewhere, all while basic functionality is still riddled with edge cases.

Still a net positive over having to fix yet another fucked up init script...

This has not been my experience at all. The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be. The big controversy was when systemd-resolved implemented the spec to the letter and broke people’s assumption that listing DNS servers in order means they’ll be queried in that order.

> The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be.

Really, the issue here is that "how it used to work" is mostly unambiguous, but I have no clue what you mean by "the spec", and I suspect you're actually referring to a multitude of specs, several of which were only created in the process of writing the relevant systemd components.

> you can have fun evening inventing your own shitty binary journal format.

I thought the reasoning was to make logs harder (or impossible) to tamper with.

Something something about trading freedom for security.

> https://lwn.net/Articles/512895/

the binary logs handled by the systemd journal can be "sealed" at regular time intervals. That seal is a cryptographic operation on the log data such that any tampering prior to the seal can be detected.

This might be news to some people.

I think on the social level there's a lot of people that go "urgh systemd" because that's the popular opinion but overestimate their actual technical knowledge to comment on the matter.

I remember reading some advice about not doing rm -rf / on UEFI systems and looking that up, it looked like some MSI laptops would brick if certain UEFI variables were wiped.

I found an issue in systemd's issue tracker. And from what I could tell the ability to write to these variables was required to perform certain functions like rebooting into the UEFI system.

But it looked like that some forum or another had linked to the issue. And plenty of people were up in arms about it without anything substantial to say.

This is a hard point to refute because it's basically "some unknown number of people who don't like systemd are possibly technically illiterate" which is always going to be true but to an unknown extent.

If we're going on technical credentials, I have a few minor ones. I'm not writing dozens and dozens of lines of C every day, and I'm definitely not writing kernel components- but I've been doing low level technology stuff for 15 years now.

Everything from watching access patterns on drives and recombining data to writing/patching memory allocators and aggressively tuning system internals. I'm currently responsible for automating the deployment of the largest always online game my publisher has ever known. I'm relatively technical and highly regarded for my technical competence.

When it comes to systemd; you could argue that I'm "stuck in my ways"; but I've used systemd since fedora 21, I saw bugs you couldn't imagine, I read the code, I saw the hostility of the developers (maybe it's just defensiveness?) and I was a little worried, but ok, it's just fedora, it'll be better in RedHat when it releases... and while a lot of the lower hanging bugs went away for most use-cases; many remained in the edges. Instead of them being fixed though there's been a propensity to build a software eco-system and "system layer" to the OS.

My argument has never really been that "systemd totally sucks" it's that the conversation surrounding it is very hostile.. If you say that you don't like journald (because it's very easy to corrupt and has access drawbacks, encoding issues, tooling is sub-par etc) then people shout at you: "YOU CAN USE OTHERS", but you can never turn journald off.. it's wasted IOPs, IOPs are not free.

The biggest issues I had with systemd is the fact that (unlike Solaris' SMF, which is great btw) it will hide failure from you, and failure can happen relatively randomly because nothing is deterministic. This is not a holdover from being multi-threaded, there is actually a dependency graph that gets generated. But I've never been able to access that. (Maybe that's changed?)

My argument has always been, instead: "systemd's tight coupling of so many components means that we will never be able to have an alternative or successor to systemd". Because re-implementing single components is next to impossible and the sheer scope of the "system layer" is many times more lines of code than the kernel itself.

Anyway the conversation is steeped in some level of tribalism.. Which I truly hate.

You can't talk about systemd without being "pro" or "against" and then people take extreme stances, like "systemd saved my baby" and "sysvinit was trash" (and on my side: "unix philosophy!", and "systemd ate my utility!")

Well, my point is that (for instance) the specifics of its dependency model are still fairly obscure and undocumented knowledge. So I would say the statement is quite justified. And it also has a fascinating history that often gets reduced to culture war-related soundbites, which too deserved to be told.

I'd say software doesn't always win out on it's merits, there's almost definitely some social aspects regarding what does and does not get adopted. I do agree the commercial interests probably played the largest role, though. I think beyond the initial knee-jerk one might have towards this it's pretty comprehensive and there's interesting points here that are at least worth exploring.

Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. I lost track of the number of Upstart bugs we avoided by switching to systemd, and that had the backing of one of the most popular Linux distributions.

> Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive.

They had the people because they had the money. The debate about systemd is only partly technical; it's mostly a culture war about how Red Hat is hostilely taking over the free software ecosystem, and how that invokes memories of embrace/extend/extinguish.

I suppose so ya, can't sustain without a community or company unless you want to do all the work yourself.

Another factor I was thinking is that almost everything in systemd is there because someone saw a need, even if it’s a niche – things like mounts aren’t a big deal for many people but the people who had something which wasn’t well served before wanted something better in a new system. Trying to replace a core component will flush out a lot of those smaller communities.

> It is well understood and has been studied and critiqued by many, including me.

It seems a lot of people simply don’t want to understand systemd, and go out of their way to avoid learning anything about it.

Could that be considered a social factor?