[b112]

The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years.

To be fair, this could happen to any of us, especially early in career. But the real hubris is presuming that things are, as they are, without cause or reason. Along with never really knowing how things actually worked. Or why.

I envision a layperson (which is sort of understanding the author had of modern init systems, when starting on systemd). Said person walks up to a complex series of gears, and thinks a peg is just there for no reason, looks unused, and pulls it out. Only to have the whole mess go bananas. You can follow this logic with all of the half baked, partially implemented services like timekeeping, DNS, and others that barely work correctly, and go sideways if looked at funny.

I think if the author took their current knowledge, and this time wrote it from scratch, it could be far better.

However there still seems to be a chip on their shoulder, with an idea that "I'll fix Linux!" still, when in reality these fixes are just creating immense complication with very minimal upside. So any re-write would likely still be an over-complicated contraption.

[kloud]

When a complex system cannot be meaningfully reduced, another approach might be trying to reduce scope.

Current areas include managing services on a server, managing a single-user laptop, and enterprise features for fleet of devices/users.

There is some overlap at the core where sharing code is useful, but it feels way more complexity than needed gets shipped to my laptop. I wonder how much could be shaved off when focusing only on a single scenario.

[skydhash]

I like openrc for laptop or workstation. Writing service is as easy as writing a systemd files (with less options of course, but I never really wanted those).

[marcosdumay]

Yet another approach is exposing internal state.

That way you turn a very complex system into a set of much simpler artificial systems that you can control the interaction.

On your example, that would mean having different kinds of configuration options that go for each of those scenarios, but still all on the same software.

One can argue that systemd tries this (for example, there are many kinds of services). But in many cases, it does the complete opposite of this and reducing scope.

Still, I don't think init systems are a wicked problem (and so, it doesn't need advanced solutions to managing complexity). The wickedness is caused by the systemd's decision to do everything.

[jasonjayr]

> The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years.

Don't forget the best one: "We don't support that uncommon use case, we will not accept nor maintain patches to support it, and you shoulden't do it that way anyway, and we are going to make it impossible in the future" -- to something that's worked well for decades.

[kps]

“Those who do not understand Unix are condemned to reinvent it, poorly.” — Henry Spencer, 1987

[cyberax]

I disagree. As much as I dislike a lot of stuff in systemd, it was the _first_ init system that actually cares about reliability.

It evolved organically so it's a bit of a mess as a result, but it's the fate of most long-term projects (including Linux).

[b112]

Reliability!!

It's the least reliable init system I've ever used!

[cyberax]

Yes, reliability. Systemd was the first mainstream init system to deal with service confinement via cgroups, service readiness protocols, and true event-based service activation.

To give you some perspective, at that time, upstart was using ptrace() to detect the double-forking to allow services to be tracked.

[b112]

Tracking services doesn't provide for a reliable init system. From my perspective, the only job for init is to control startup and shutdown of services.

Not to keep them running. Not to restart them. Not to track them.

I have logs, and monitoring software for that. I have loads of applications to do that, if I wish. But regardless of what you believe an init system is for, the reliability of it is separate from "keeping apps that are so crappy they crash, running".