Based on some recent news, and an interaction I had.
-
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@pj@donotsta.re init and daemon supervision is not and never has been something an application developer should worry about
-
@pj@donotsta.re thats when something becomes "outdated" in software
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 -
@kopper@not-brain.d.on-t.work @julia@eepy.moe @nelson@wetdry.world oh yea thats good
-
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@pj@donotsta.re uh ok . could you be more specific in which features you are talking about ?
-
@pj@donotsta.re init and daemon supervision is not and never has been something an application developer should worry about
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 -
Based on some recent news, and an interaction I had.
@nelson@wetdry.world Nice draw
-
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@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 Nice draw
@nube thnkx

-
@pj@donotsta.re uh ok . could you be more specific in which features you are talking about ?
@fiore logind, tmpfiles, sysusers, user services (which are quite a recent thing still in openrc), socket activation, more... -
@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
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 logind, tmpfiles, sysusers, user services (which are quite a recent thing still in openrc), socket activation, more...
@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
-
@fiore logind, tmpfiles, sysusers, user services (which are quite a recent thing still in openrc), socket activation, more...@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 -
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 -
@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@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
-
-
@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
-
-
Based on some recent news, and an interaction I had.
@nelson this situation really sucks but your art goes hard as fuck as always keep up the good work