Based on some recent news, and an interaction I had.
-
-
@julia @fiore @nelson julia hi this is an L I thibj.
flatpak itself is the abstraction you as the software dev target to make your software work on the weird distros without needing to care about them in specific. this is counter to pretty much half of the entire selling point of flatpak (the other half is the sandboxing)@kopper@not-brain.d.on-t.work @julia@eepy.moe @nelson@wetdry.world this is kinda like what if chromium decided to only work on windows . not rlly but . kinda
-
@pj@donotsta.re in any case , i am a happy systemd user on my servers . what im trying to say is that the push towards alternatives is there , and is something many people advocate for, and work actively towards . binding yourself to outdated technology is a bad idea imo..
Ok, so I'm like with you until "outdated technology" because where in the hell is systemd an "outdated technology" (as a project and its author that always has been striving to provide best Linux Desktop experience)?
@fiore -
Ok, so I'm like with you until "outdated technology" because where in the hell is systemd an "outdated technology" (as a project and its author that always has been striving to provide best Linux Desktop experience)?
@fiore@pj@donotsta.re outdated since alternatives have been consistently been able to provide better performance with simpler and more portable systems.
-
@pj@donotsta.re outdated since alternatives have been consistently been able to provide better performance with simpler and more portable systems.
@pj@donotsta.re thats when something becomes "outdated" in software
-
@pj@donotsta.re in any case , i am a happy systemd user on my servers . what im trying to say is that the push towards alternatives is there , and is something many people advocate for, and work actively towards . binding yourself to outdated technology is a bad idea imo..
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 @julia@eepy.moe @nelson@wetdry.world this is kinda like what if chromium decided to only work on windows . not rlly but . kinda
-
-
@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 -
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
