not surprised that @postmarketOS folks pulled the trigger on systemd
in alpine we have promised to build something better than openrc for years, but it still isn’t here.
meanwhile, the polyfills for various systemd apis to work on openrc do not actually work correctly in many cases, leading to unnecessary bugs on the desktop.
i think @alpinelinux should join pmOS in getting off openrc, the project is basically on life support anyway and the maintainers primarily focus on Gentoo usecases also.
@ariadne Have you seen @chimera_linux efforts to build a desktop grade ecosystem around dinit?
@Gottox @chimera_linux see next post about pet init systems
@ariadne I'm actually not talking about the init system here, but all the stuff around it. init systems are enough out there.
@ariadne chimera at least starts the stuff, that alpine failed to do. I don't know if it will succeed, as it is a small project, but I see steps in the right direction.
@Gottox what you're doing here is pointless because 1) @ariadne has already decided she's right from the point the first post was made, and therefore everyone who is not nodding in agreement is stupid 2) therefore our efforts are already obviously doomed to fail, and are nothing but somebody's pet project that wasn't even thought through
@chimera_linux @Gottox no, that is not my position, but after seeing half a decade spent on this with no results, i do ponder if it is the right move for alpine to continue. chimera may or may not succeed where alpine has thus far failed, but that doesn’t mean that alpine should make another gamble at this.
@ariadne @Gottox i don't really care what alpine ends up doing, as that's their choice and not ours; and it's not even like you're wrong wrt "systemd-free" projects ignoring what people want in practice (if anything that's one of *the* reasons this project was started and i've been saying that exact thing for years) but the way you say it sounds like a massive fuck you to anybody actually trying to make a real difference and i don't approve of that, it's toxic as hell
@chimera_linux @Gottox i only posted that because people were literally telling me about things i already know about and that weren’t adequate. maybe chimera will succeed where the others have not (indeed, it is the most hopeful yet), but after being told for hours about half-baked systemd-free projects, i think it is reasonable to post a generic “keep out” sign.
especially when the point was about alpine’s failure to do meaningful work in this area, and not about the half-baked alternatives.
@ariadne @Gottox fwiw the whole idea that creating a service manager is some kind of magical solution to service management problems is flawed, in reality it's only a part of it
sure, you need a solid base, but the integration work and tooling around it is another massive part, and makes up the majority of the actual UX
you can do it like systemd and provide all that stuff along with it (RH had it easy though since they have an in-house OS) which takes away power from the distribution, or...
@ariadne @Gottox the other way to do it is for a distribution to actually adopt it and collaborate with the service manager upstream (and have somebody working on the surrounding tooling a well)
that's what we're doing with dinit, and obviously it takes time, but there is no other way
what happens when you just take the service manager and shove it in a distro without a second thought or proper integration: you get an artix, and that seriously sucks
@chimera_linux @Gottox i think RH’s support of systemd is misunderstood. they only started backing it after it was a reasonably safe bet. RHEL7 only shipped with it because of demand from the community.
RH even went as far as to assure its partner network that they were fully committed to keeping LSB init scripts working forever.
instead the reason why systemd was successful was because it was legitimately a grassroots effort inside fedora. users were voluntarily changing their init to the unsupported systemd one well before (several fedora release cycles, about 2 years) RH decided to start embracing it.
@lanodan @Gottox @ariadne even if that was the case it's not right to blame gnome here; their lives would be much easier with just systemd as right now there are two process launch architectures simultaneously maintained (desktops consist of a lot of session-wide processes, and gnome can now either launch them with systemd which means being able to do so cleanly, on-demand, in a supervised manner and with dependencies, or in a crummy "just launch everything and hope it does not crash" way)
@lanodan @Gottox @ariadne the latter is the "traditional" way and it was bound to happen that as soon as there was something better somebody would jump on it
unfortunately we still have to live with the latter (gnome is nice enough that they still maintain vast majority of the old paths even though they have no obligation to) though in a few months we'll be ready to switch to a better architecture
@chimera_linux @lanodan @Gottox also it’s not surprising that the same people who work on both projects would leverage what they have built in a vertically integrated way. that doesn’t mean RH gave any of it their blessing, though.
@lanodan @Gottox @ariadne you would still need a way to securely request a file descriptor to the gpu device at least inside weston or whatever (the alternative is nasty suid wrappers, which has its own issues) and there was only libsystemd and consolekit for that (libseat did not come until years later and libseat on its own is still only a half of a solution)