to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.

[steve@discuss.systems]

@ariadne @eschwartz @zyx @whitequark —omg-optimized

[whitequark@social.treehouse.systems]

@ariadne @eschwartz @zyx like it's not even about systemd, i'm using systemd right now, it's about people generally seeming to make more sensible decisions than my experience with debian as a maintainer which has left me very sour

[ariadne@social.treehouse.systems]

@eschwartz @zyx @whitequark I mean I don't really have an opinion on systemd. the reason I use and work on Alpine is because it is an integrated OS. systemd offers some of the same benefits for the GNU/Linux crowd and that seems like a positive for GNU/Linux...

[whitequark@social.treehouse.systems]

@ariadne @eschwartz @zyx i think a lot of the concepts are sound, but a significant part of how it was implemented historically shows a lack of care that i wouldn't really consider acceptable in my work but switching away from it would break KDE which i like enough that it's a nonstarter

[eschwartz@fosstodon.org]

@whitequark @ariadne @zyx

I'm not really sure what you mean by that... Switching away from systemd would break KDE? Shouldn't be -- KDE Plasma is packaged by alpine (no systemd option) and supported just fine on Gentoo's openrc profiles.

[whitequark@social.treehouse.systems]

@eschwartz @ariadne @zyx to be clear this isn't a deeply researched opinion, i just used to run systemd-less debian and at some point half of plasma (networkmanager, power management, etc) broke due to some consolekit related thing i eventually traced down to "i guess i need systemd now"

[ariadne@social.treehouse.systems]

@whitequark @zyx @eschwartz yes can confirm I use plasma as my daily driver on alpine.

[whitequark@social.treehouse.systems]

@ariadne @zyx @eschwartz does NM work?

[eschwartz@fosstodon.org]

@whitequark @ariadne @zyx

I have no particular idea what Debian might have done there, but generally the preferred alternative to systemd is using elogind anyways. Which should work fine. You could also try speaking to the upstream maintainers of $PACKAGE about using libseat where possible. Gentoo should support any configurations possible upstream, and possibly relevantly, Gentoo will *rebuild* if you change your configuration, not use libsystemd.so compiled binaries on openrc.

[eschwartz@fosstodon.org]

@whitequark @ariadne @zyx

The Gentoo gui installation ISO uses kde and openrc, and connecting to WiFi to begin installation means using the NM applet. It works quite well, except for the part where kde really wants to encrypt your wifi password with the account keyring, which as a live ISO doesn't exist. (So, routine "fail to store the password and then go back into settings and re-enter the password" on every ISO boot.) But that's not the fault of an init system.

[whitequark@social.treehouse.systems]

@eschwartz @ariadne @zyx thanks, this is very useful to me :3

[eschwartz@fosstodon.org]

@whitequark @ariadne @zyx

Basically, if you're gonna support a frankensystem where packages can either be compiled against one init system / seat manager / udev impl / lots more, or another one, it really helps to have the concept of USE flags, and I don't know what Debian does to try to support "packages depend on systemd, but we also support openrc instead" without USE flags. Maybe "foo-systemd" and "foo-openrc" packages? Sounds terrifying. "Openrc derivative with overridden repos"? Pain².

[whitequark@social.treehouse.systems]

@eschwartz @ariadne @zyx "pain" is a good summary

[noisytoot@berkeley.edu.pl]

@ariadne @whitequark @zyx @eschwartz do you run edge or stable? (I run edge on my laptop with KDE Plasma and occasionally stuff breaks)

[ariadne@social.treehouse.systems]

@noisytoot @eschwartz @whitequark @zyx edge, but i am patient