Hacker News Reader

Comment by mindslight | Hacker News Reader

Talking about "hardcore opposition" is a bit of a straw man. Put me in the continual "softcore opposition" camp. I don't care about it enough to move away from Debian or figure out how to switch to another init, and I was never in love with SysV init, but every time I have to debug systemd it's a pain in my ass.

Systemd suffers from being an underspecified declarative system. They look great when things work, but when they go wrong you're left with an opaque mess. For example, creating a dependency loop results in arbitrary units simply being dropped at boot time. On a desktop machine, you might only realize this when trying to figure out why some service didn't start and digging through the logs!

Of course there is nothing else systemd could possibly do instead, given a loop in a dependency DAG (besides refuse to boot completely). The problem is the design decision of using a simplistic data model that fails in that spectacular and unintuitive way.

View on HN

One thing I've found helpful when Debian systems are causing problems is (1) ignore the config churn and (2) just attach GDB to edit raw memory, to make a process stop doing whatever it is that it's doing. It shouldn't be necessary but sadly in a world where engineering practices "evolve" this rapidly that's usually easier.

> The problem is the design decision of using a simplistic data model that fails in that spectacular and unintuitive way.

I don't see how it could be made intuitive. How would you design it?

Ideally ordering would be assured by construction, as if units were listed out in one file. But that would not compose easily.

I'd start by adding an optional priority number to each unit, which if supplied would form an ordering that units were always executed in. A unit having the priority number should also be less likely to be chosen for dropping, as they'd likely to be distribution-supplied units that were better debugged. This would make it much easier to narrow down the source of a logical conflict, and drop sensible units.

That only addresses the one gripe I brought up as an example though, and not the general pattern. For instance another issue I've run into is this automagical hacks that parse fstab crypttab etc and make units at boot time, while not actually supporting all the customary options of those files.

In general it feels like if systemd were written in a modern language, traditional distribution responsibilities (eg initrd/cryptoroot) could have been comprehensively replaced. But instead they bit off more than they could chew in C, so completeness and elegance were cast aside, and we're left with a hodgepodge of the old and new systems.

> That only addresses the one gripe I brought up as an example though, and not the general pattern. For instance another issue I've run into is this automagical hacks that parse fstab crypttab etc and make units at boot time, while not actually supporting all the customary options of those files.

Maybe the long term plan is to have these files dropped and replaced with something more systemd like?

> we're left with a hodgepodge of the old and new systems.

Same argument: if the long term goal is to completely overhawl the system, then at any point before that goal is reached there has to be old devices still in place.

That being said, I don't know much about systemd, not about the long term goals of systemd authors. I think that Poettering language of choice is C, so this explains that, but there's always room for other solutions in the FOSS world.

Reply on news.ycombinator.com