qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<IdleBot_5e50c57d> Hm, vhost-user might become a good solution. Qemu works on the implementation; it actually makes a lot of sense for Firecracker, too — hopefully CrosVM also gets something
MichaelRaskin has joined #spectrum
tilpner has quit [Remote host closed the connection]
tilpner has joined #spectrum
<MichaelRaskin> Oh fun, apparently, unlike Xorg, wayland composers are actually annoying to get running without systemd
<MichaelRaskin> OK, weston can be started but unclear how to stop (well, pkill works)
<MichaelRaskin> Hm, at the second attempt it reacts to normal ctrl-alt- stuff
MichaelRaskin has quit [Quit: MichaelRaskin]
<qyliss> As long as you have elogind you should be fine
<qyliss> I think
<multi> which bits of (e)logind does wayland require?
<samueldr> a non-systemd distro that has wayland stuff working is postmarketOS, if it helps
* multi nods
<multi> okay
<multi> i'm totally illiterate when it comes to wayland; i'm a stubborn debian user running i3wm on xorg :)
<qyliss> multi: I believe it's "seats"
<qyliss> You can also run it as root, just like X
<qyliss> But that's a bad idea
<multi> ah, like how some distributions have a setuid X wrapper to permit the server to open the framebuffer?
<qyliss> Yeah exactly
<qyliss> (e)logind handles that with seats
<qyliss> I don't really know the details
<multi> hmm
<multi> i do wonder if it's possible to shim around that
<multi> any links to some code which i can confuse myself with?
<qyliss> not really
<qyliss> I do know that sway will detect if it's running as root and decline to run
<multi> i messed around with sway a while back, and it certainly seems opinionated on things like that
<multi> (inb4 running it with elevated capabilities but not full root...)
<Shell> There is support in wlroots for direct access to the devices without going through logind. I don’t know whether that’s exposed in sway.
<multi> interesting
pie__ has joined #spectrum
<qyliss> why would you not just run elogind
<multi> irrational aversion to extra moving parts
pie_ has quit [Ping timeout: 276 seconds]
<qyliss> Wouldn't your custom shim that does who knows what be a moving part?
<multi> see the "irrational" in my above statement. i don't have any particularly well-founded argument against just running elogind.
<Shell> multi: if you build sway+wlroots without systemd/elogind support, you can setuid sway and it'll work. it'll drop permissions shortly after startup.
<multi> neat
<Shell> this is how sway works on FreeBSD.
<multi> makes sense
<qyliss> woooo, got the chroot working
<Shell> \o/
<qyliss> having to use the prebuilt one though -- couldn't get it to build from source
<qyliss> and still required a one-line ptach
<qyliss> oh hello
<qyliss> lol he just wrote a meson file
<Shell> :D
<IdleBot_5e50c57d> Well, elogind will do some things wrong exactly in the same way as logind…
<IdleBot_5e50c57d> I already have permissions-to-vts code in my system, and I want to spawn wayland sessions on the fly in sequentially allocated vts (like I now sometimes do with Xorg), etc.
<IdleBot_5e50c57d> BTW, elogind means D-Bus, and non-contained D-Bus is also bad
<qyliss> that is true
<qyliss> D-Bus is sadly almost impossible to avoid afaik
<IdleBot_5e50c57d> Well, with Weston it is not necessary
<IdleBot_5e50c57d> I am OK with contained D-Bus — isolation avoids all those «crazy interaction» issues
<Shell> d-bus winds up being used for all sorts of stuff. for example, it's used for desktop notifications iirc.
<qyliss> And portals, right?
<Shell> yup!
<IdleBot_5e50c57d> Portals?
<Shell> with portals there's a dbus server per app, and a shim which proxies calls from that to the desktop dbus.
* multi blinks
<multi> what's the proxy for?
<Shell> so that the app doesn't have access to the desktop dbus server.
<multi> fair enough
<Shell> IdleBot_5e50c57d: portals are a system being developed by the desktop linux folks for sandboxed apps to be able to request additional access ("open file", "take screenshot", etc) from the user.
<Shell> it's being pushed by the flatpak people, supported by the GNOME/KDE lot, and it's the only standard way to do things like remote control and screencasting with Wayland.