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

[nelson@wetdry.world]

@julia @fiore what could actually cause some real issues when it comes to "supporting entire different multiple different OS stacks" could probably be drivers or some weird kernel level stuff, but for the most part, most of the userland essentially disappears for an application that's built for flatpak as a platform

[kirby@freerobuxextremist.com]

@julia @fiore @nelson >supporting entire different multiple different OS stacks is contrary to that goal

if that's the case, then why doesn't flatpak exclusively support immutable distros? bad card

[pj@donotsta.re]

> systemd is not in its golden days anymore and hasnt been for a while

since when and how

@fiore @julia @nelson

[fiore@brain.worm.pink]

@pj@donotsta.re @julia@eepy.moe @nelson@wetdry.world @claude review

[nelson@wetdry.world]

@pj @fiore @julia since they've began using AI to write code and file bug reports

[pj@donotsta.re]

Yeah I don't consider that anyhow related because it does not affect dev process

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

@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)

[nelson@wetdry.world]

@pj @fiore wym, ofc it does, there's AI code in systemd right now, and that's because redhat itself has been introducing it as a development tool for a while

don't cite me on it though, but it can be seen spreading across everything redhat-owned

[fiore@brain.worm.pink]

@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..

[pj@donotsta.re]

> don't cite me on it though

ok so you're talking out of your ass then?

@nelson @fiore

[fiore@brain.worm.pink]

@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]

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

[fiore@brain.worm.pink]

@pj@donotsta.re outdated since alternatives have been consistently been able to provide better performance with simpler and more portable systems.

[fiore@brain.worm.pink]

@pj@donotsta.re thats when something becomes "outdated" in software

[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