|:: [devuan-dev] Meeting notes 2020-10-…|
|This message is part of the following thread:|
|the complete thread tree sorted by date|
### mason * wiki exploration * ikiwiki lacks real ACLs. * Foswiki seems to have hardcoded Apacheisms * Current focus: PMwiki * Was suggested in email poll, despite being PHP. * I've got this running internally, although I'm still working on setting it up. * It's got the cleanest, clearest configuration of all of them so far, and has presented the fewest hurdles out of the box. * It has an explicit separation of code and server-editable data, which we want. * I'm going to push forward with this one and commit to having usable content for next week's meeting, and accounts doled out to those interested before then so we can come into the meeting with some direct experience of the thing. * (from golinux) use pkginfo or bugs for style guidelines - simpler than web site * Unbound PID issue * I'm not sure they're going to go the right direction. They'll address the CVE-worthy security issue, but I suspect they'll continue with the self-owned PID. I don't have a feel for whether Debian would want to make this change or not, but we could wrap it in an init script that tells it not to manage its own PIDfile, and we can let start-stop-daemon manage a PIDfile for the service. This would mean forking it. * (Beer) They definitely seem obtuse about [the reported problem](https://github.com/NLnetLabs/unbound/issues/303). However forking & maintaining requires human resources…
### mason * How do people feel about elogind? * (mason) It's a big part of systemd and it seems like we should reject it as we reject the rest of systemd. It's a slippery slope. There are other tools that do its work that are not central components of systemd. This is distinct from elogind0, but I like the notion of ditching that as well. Libraries are supposed to supply defined resources related to each other. libelogind0 breaks this. As noted above, I hope to put my money where my mouth is once I've gotten the wiki into usable form - I'm looking to volunteer my own time primarily, but knowing that the project agrees or disagrees with these assessments will help me to properly understand how to prioritize this stuff. * (bgstack15) I care about lightdm, which requires elogind. And don't tell me that consolekit is suitable instead of elogind; isn't it by the same people, and unpopular in their eyes just like gtk2/3 is anathema to the Gnome people? * (mason) consolekit is preferable, but is this strictly needed at all for lightdm? Some quick reading suggests that you lose the ability to shut down from the login screen. And there are other display managers. Even on laptops, I find XDM to be entirely suitable for launching sessions of various sorts. Regardless, if we're just going to use huge chunks of systemd, I don't see the point. Just use Debian, if it really doesn't matter. I'm interested in having a diverse ecosystem, and a search/replace to rename pieces of systemd isn't a move in that direction. Tell me this: What's the point of Devuan if it's just going to use systemd? * (noname) I would love to see a maintained alternative to make devices available to it users securely and only while that particular user needs those devices. The seat management is only there to support that. Can you provide that? If yes, kill elogind with fire! If no: please keep elogind. * (LeePen) I think consolekit is unmaintained upstream and can't be considered a viable and secure option. The last commit was December 2017. It also delegates suspend/hibernate/resume to pm-utils which is also dead upstream. See [here](https://github.com/ConsoleKit2/ConsoleKit2/issues/114). * (LeePen) I think the stated objective of Devuan is to be able to avoid the use of systemd as PID1, not avoid any systemd derived code in all circumstances. We currently use eudev, elogind and libsystemd0 which are all derived from systemd codebase. * (plasma41) Technically eudev isn't so much derived from systemd as it is extracted after having been absorbed into systemd * (LeePen) If somebody wants to write and maintain a compatible logind implementation from scratch, great and let's try it. * (plasma41) Given that using elogind feels like just replacing systemd with the same systemd code, just sliced into smaller pieces, I am in favor of minimizing its use. Currently I'm running consolekit for the role that elogind serves, though I am running a single-user, single-seat setup, so I'd prefer to be able to do away with "seat-management/session-management" code on my system altogether. * (plasma41) If we want to minimize elogind dependence, I recommend we collaborate with the Hyperbola devs. See https://www.hyperbola.info/todo/consolekit-migration/ * (gl) pekman already hangs around here and he's active with hyperbola * (plasma41) And while we're ridding ourselves of systemd bits, I also would like to aim to get rid of the proto-systemd: d-bus. More Hyperbola colab opportunity here: https://www.hyperbola.info/todo/dbus-mitigation/
## New Actions * Find alternate eudev maintainer * greeter / display managers * language? * shutdown from login? * what else? * explore pm-utils viability * explore desktop environments that might not need consolekit/(*)logind * kde? mate? lumina? * https://lumina-desktop.org/ and https://github.com/lumina-desktop/lumina * wayland and rootless X11 both need logind nowadays (or insecure hacks)
-- Mason Loring Bliss mason@??? http://blisses.org/ For more enjoyment and greater efficiency, consumption is being standardized.