Back

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

@ariadne @Gottox fwiw i haven't seen any such thing happening in alpine and s6, at least not enough for it to matter, and i suspect that's a part of the reason why it's never gone anywhere

but then i'm also not a big fan of the s6 style of creating something that's supposedly well designed in isolation, but then being unnecessarily difficult and annoying to integrate and use

@ariadne @Gottox that's not the point, the point is that it was an effort done *within fedora* so they were working on something specific and not just a service manager without any feedback from real world use cases

there is only so much you can think about and consider when you're only backed by theory

@chimera_linux @Gottox sure, but my point stands that it wasn’t a blessed by RH project for a long time. and alpine made the same level of access available to s6 and other projects.

@ariadne @Gottox perhaps not blessed by RH for RHEL, but still developed by RH people and driven by fedora

i don't think it's reasonable to expect the developer of the service management system to drive your distro integration; for one it's an entirely different job compared to actually developing the thing, for two it's way too much to do at once

first there needs to be a real initiative and goals, then some initial work, *then* (or during) you come to @ska or whoever for help

@chimera_linux @Gottox @ska i agree, and that is certainly a failure in alpine’s execution.

@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 what something else? there *wasn't* anything else they could have realistically used at the time (to a degree there still isn't)

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