Ancestors

Written by postmarketOS on 2025-01-10 at 16:39

Update: the #systemd merger is in progress. We recommend NOT updating your devices which are running #postmarketOS edge until this is complete.

We are currently working through some issues with the changes to https://build.postmarketos.org

A full explanation of the changes and our recommendations for migrating your devices to systemd will be published once things are ready!

In the mean time, refresh https://build.postmarketos.org at will

https://fosstodon.org/@postmarketOS/113798746780556806

=> More informations about this toot | More toots from postmarketOS@fosstodon.org

Written by djsumdog on 2025-01-10 at 17:20

NOOOOO!!!! PostmarketOS is adding system-shit-d?! God damn it. You were one of the good ones!

Edit: oh phew 😰 It's optional. Good!

=> View attached media

=> More informations about this toot | More toots from djsumdog@djsumdog.com

Written by tomato: 2025 edition on 2025-01-10 at 17:22

@djsumdog @postmarketOS I've seen similar sentiments from the alpine devs

=> More informations about this toot | More toots from mischievoustomato@0.5dollah.click

Written by Lily :pleadingcute: :heart_bi: on 2025-01-10 at 17:26

@mischievoustomato @djsumdog @postmarketOS the problem iirc is that openrc has been kinda unmaintained for a long time and distros aren't exactly happy with the state of the project. my gf is fixing that tho, she recently has become a maintainer and also did a bunch of things like user services. currently i think she's doing readiness notifications. the goal is to make it competitive with systemd, but without all the horrible decisions

=> More informations about this toot | More toots from lizzy@social.vlhl.dev

Written by caleb -> #FOSDEM on 2025-01-10 at 17:36

@lizzy @djsumdog@djsumdog.com @postmarketOS the proposed user services support seems quite interesting, it would be great to see openrc embracing more modern approaches - the biggest being moving away from shell scripts for service definitions.

Is there some plan for taking over openrc-settingsd? Or maybe following the Chimera (and now likely Alpine) approach of embracing the more widely standardised aspects of systemd (logind, udev and other freedesktop APIs)?

There's some folks hanging in the #postmarketos-openrc channel who maye be interested too (although not much has happened there in the 8 months since it was created)

=> More informations about this toot | More toots from cas@treehouse.systems

Toot

Written by Lily :pleadingcute: :heart_bi: on 2025-01-10 at 17:44

@cas @postmarketOS I don't see shell script services as a big problem. OpenRC services are declarative already, it's just that the declarativity works via shell variables and functions rather than, say, ini fields like systemd. It's not comparable to sysvinit or whatever, it's just that shell is the format they use, and that brings some conveniences while still having all the advantages of a declarative format.

And btw, the user services are no longer a proposal, they've been merged a few days ago :)

regarding the rest, ping @navi

=> More informations about this toot | More toots from lizzy@social.vlhl.dev

Descendants

Written by /etc/init.d/witch.navi on 2025-01-10 at 17:58

@lizzy @cas @postmarketOS

i think completely removing shell scripting would be a huge detriment to openrc, being able to define _pre or _post functions to do sanity checks inline instead of having to tie in secondary scripts/binaries is really nice, and defining custom commands like reload, check, save, restore, etc can be really nice for services that have such needs

what i do want to do is improve the declarative-ish variables, introducing easy to use namespaces under linux (networks, mount, etc), readiness notification (s6 newline style and systemd "READY=1" style), etc

there is a WIP pr for readiness notification already too

wrt to user services, the core merged (2 days ago!!), and i'm currently improving the implementation of the pam module for auto-start upon login, so openrc 0.60 (aka the next release) will have user services, and hopefully readiness notification

Is there some plan for taking over openrc-settingsd? Or maybe following the Chimera (and now likely Alpine) approach of embracing the more widely standardised aspects of systemd (logind, udev and other freedesktop APIs)?

i do want to either improve or take-over/fork/replace similar things, but i don't necessarily want to tie them to openrc unless extremely necessary. going for an open approach were people can use tools by themselves and integrate things in a modular way, tho i still didn't study openrc-settingsd yet to see how to handle that use case.

for logind, we already have half of it solved by seatd, the seat management part, and thus i want to look into the login management part, elogind is massive hack that barely works with each systemd update, turnstile... exists? so i need to study this part

there's also consolekit which freebsd still uses, and now a days consolekit also implements the logind c api and login1 (tho with another dbus endpoint as the name, so it's not a 1:1 replacement)

udev for now is on the really back burner because systemd-udev is easily buildable from the systemd tree without depending on systemd or even glibc at all. same goes for systemd-tmpfiles

=> More informations about this toot | More toots from navi@social.vlhl.dev

Written by caleb -> #FOSDEM on 2025-01-11 at 01:45

@navi @postmarketOS @lizzy ooh, ok sounds super interesting. ill be curious to see how this all shapes out, i'm happy to see alternatives to the hegemony and more interest being taken in actually meeting the needs that systemd fills.

=> More informations about this toot | More toots from cas@treehouse.systems