Based on some recent news, and an interaction I had.

[pj@donotsta.re]

Also to be clear, I'm all for having diversity in software stack and be as compatible and interoperable as possible, but I'm also just a dev that cannot support everything always forever and having less scope and more predictable platforms is extremely better for me

(I'm also an Alpine/pmOS/Chimera user that has been on musl and non-sd init/rc for years)

@fiore

[kopper@not-brain.d.on-t.work]

@fiore @julia @nelson eh, more like wine only deciding to support wsl

[nelson@wetdry.world]

@pj @fiore I take the L for this tbh lol

[yukijoou@fedi.kemonomimi.gay]

@pj@donotsta.re @fiore@brain.worm.pink @julia@eepy.moe @nelson@wetdry.world as a user, i do feel like the project has ballooned a bit too much, taking on features that feel like they don't need to be tied to an init system and/or service manager (such as systemd-ukify)-- this means these features depend on libsystemd when they could work independently of systemd, which makes me feel a bit too "locked in" to the project (bus factor and all that)
that, while still having long standing issues (extremely vague log messages such as "A stop job is running …", like, could you tell me at least what is holding up shutdown..?) has made me loose some faith in the project

[fiore@brain.worm.pink]

@pj@donotsta.re init and daemon supervision is not and never has been something an application developer should worry about

[pj@donotsta.re]

But all those alternatives are worse in terms of providing functional features (as in they lack them). Like I've been there, done that (openrc/dinit) and there's only one project that can somewhat compete with current status quo.

@fiore

[fiore@brain.worm.pink]

@kopper@not-brain.d.on-t.work @julia@eepy.moe @nelson@wetdry.world oh yea thats good

[fiore@brain.worm.pink]

@pj@donotsta.re uh ok . could you be more specific in which features you are talking about ?

[pj@donotsta.re]

No, I'm talking as a developer relating to other developer when e.g. Flatpak devs say they want to use X that is used by majority of users because it makes their job easier and more rigid.

@fiore

[nube@verse.averagedood.xyz]

@nelson@wetdry.world Nice draw ​​

[fiore@brain.worm.pink]

@pj@donotsta.re as i said , i have not looked into the specifics of how flatpak would even need this. so i cannot say anything about it

[nelson@wetdry.world]

@nube thnkx

[pj@donotsta.re]

@fiore logind, tmpfiles, sysusers, user services (which are quite a recent thing still in openrc), socket activation, more...

[pj@donotsta.re]

And because of that I hate this whole discourse because people don't really look into the specifics and just pile on because of buzzwords like "systemd"

@fiore

[fiore@brain.worm.pink]

@pj@donotsta.re > logind, user services

there are alternative implementations that despite not being complete yet, are already in use by lots of people and have already proven that a standalone tool is better for this job (turnstile, for example)

> sysusers

what even is that

> tmpfiles

why is this even in systemd

[navi@social.vlhl.dev]

@pj @fiore

> sysusers

https://git.pinkro.se/Rose/gardenhouse/sysuserd.git/

> tmpfiles

https://git.pinkro.se/Rose/gardenhouse/seedfiles.git/

> socket activation

super-servers have existed for a while, and i'm honestly dubious of the performance claims systemd gives to apply it for every single possible socket -- it feels like a "trick" to shave miliseconds out of boot time more than anything else

eventually i'll be doing performance tests, and if it turns out to actually matter, then something similar will be implemented in openrc

[nelson@wetdry.world]

@pj @fiore i still don't quite understand why would flatpak, NOW, depend on systemd even though they worked this hard to have no hard dependencies on pretty much anything except a couple of userland static utilities

[fiore@brain.worm.pink]

@navi@social.vlhl.dev @pj@donotsta.re like why would anything even depend on whether socket activation is available this is making me lose my mind

[pj@donotsta.re]

Have you seen the talk that was referenced by the original post that spun this whole shitfest?

@nelson @fiore

[pj@donotsta.re]

You don't have to really but it's up to you to not use it and not the project that wants to use it

@fiore @navi