Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> [...] but the semantics of this seemingly "declarative" configuration was never properly specified.

What's missing from docs like [0] that makes you say that?

[0] https://www.freedesktop.org/software/systemd/man/systemd.uni...



I know so very little of systemd as it doesn't touch anything I do.

I can pattern match that https://blog.darknedgy.net/technology/2015/10/11/0/ - "Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise" from six years ago (Discussion at https://news.ycombinator.com/item?id=10370348 ) might be relevant.

Are those points reasonable? Dunno. If so, have they been addressed? No clue.


https://blog.darknedgy.net/technology/2020/05/02/0/ is a 2020 post from the same blog, pointing out that these issues basically remain unaddressed. But again, this is not just some "anti-systemd" talking point; the pro-systemd side also acknowledges this! They just think sysv-init was even worse.


I honestly would like to see a better service manager than systemd, but just my opinion from following development of these things: a huge reason why it can't happen comes from underlying deficiencies in the kernel, and with Unix. The real core issues can't be addressed without a large amount of changes there, which are outside the control of a service manager.


I'd love to see a later development of a proper system manager that learns from systemd's faults and allows for compatible interfaces for transition.

Much like Pipewire exposes PulseAudio interfaces but is implemented differently.


To me it's the other way around -- pipewire is the sound server equivalent of systemd. For better or for worse.


What would you prefer then? Jack?


I just use systemd and pipewire, it's not a problem for me personally. They're the worst options... except for all the others :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: