LWN: Comments on "systemd 246 released"

systemd 246 released

NightMonkey — Tue, 04 Aug 2020 17:00:55 +0000

Perhaps OpenRC might be more appropriate for your use case? Several interesting projects use it. (e.g. Alpine Linux, Gentoo) My reasoning here is that if you want a startup and service management approach, but don't need the complexity of SystemD, you may need a mechanism that's a sort of half-way mark between bare SysV-init scripts and SystemD. You could think of OpenRC as SysV-init with "batteries included" - lots of helper functions to assist, but not dictate. https://en.wikipedia.org/wiki/OpenRC

Don't hate me for suggesting it - I don't know your actual use case. :) Cheers!

systemd 246 released

bmorel — Tue, 04 Aug 2020 03:55:42 +0000

If it is that hard to work with it, maybe there are alternatives?
I do not know your use-cases, of course, but I think nosh (https://jdebp.eu/Softwares/nosh/) might be worth trying, since you already work with unit files (it seems it have a tool o transform unit files to the scripts it uses) it might even just work nicely with your current tooling.

I must mention that I keep "using nosh" on my TODO list since ~4 years (runit works pretty well for most of my usages anyway).

systemd 246 released

geuder — Mon, 03 Aug 2020 18:10:42 +0000

Inform them about what? That it's complex and that our work estimated are continuously too optimistic if want to do a bit more than just writing a trivial unit file? No, I haven't and and I doubt that such feedback would change anything.

I do occasionally post on mailing lists, unfortunately far less than I would like to. There are a couple of limiting factors:

1. According to answers I read they want you reproduce reports on the newest release or even master. In real company life we never use the newest release or master, because we get it from some distro or recently in our case from Yocto. And even that distro we don't have the newest version in use at every point in time.

2. Systemd code is very complex in some parts. I have looked at some code for hours without understanding how it works. So it would require regular working with the code to get more familiar. We have tens of packages where I *should* engage more with upstream. Sometimes it is easy to send a patch without very deep background, but with systemd I haven't hit such case yet.

3. I don't think sending complaints or feature wishes is appreciated that much in any project (reproducible bug reports is a different story). One should rather send patches. But I'm afraid I don't know any realistic patches that would make systemd less complex.

systemd 246 released

ovitters — Sun, 02 Aug 2020 15:15:30 +0000

Did you reach out to upstream and inform them? Sometimes the communication is more direct than what people are used to (e.g. if you get a "don't think it is feasible", then that is not a no, they need better explanation or better arguments), but IMO they're quite open. If you're really relying on systemd then IMO it seems better to work with them. Expecting someone to develop like you want to or expect to without communication seems to have failed so far.

systemd 246 released

geuder — Sun, 02 Aug 2020 05:37:56 +0000

This is an unbelievable list of changes. We use systemd in a somewhat "embedded" system in various different ways than the standard distros. One or two features seem to do what we have hacked differently so far. It looks like several features are incompatible changes and will break things in more or less surprising ways.

I like systemd in a way for its approach to try to do things "the correct way". But I hate it for making all development schedules blow up with its complexity. If you think "that's a small change, I'll make it in 3 hours (including testing and bug fixing), it will take you anything between 3 days and 3 weeks. If you don't have to give up on the way because it gets too complicated and you need to do it "when there is more time". And this just gets worse.