08:37 <__toor__> mm, util-linux was changed by redhat to ONLY support PAM. For some reason.

08:38 <__toor__> sorry login @ util-linux, just to be clear. not all tooling in util-linux requires PAM per se ;)

08:46 <larstiq> what alternative would there be to PAM?

08:47 <__toor__> well I don't need any complicated system more than just having a password file, PAM offers multiple way to authenticate via modules, including password

08:48 <__toor__> If I can avoid additional complexity, I opt out of everything that I don't need

08:48 <larstiq> not supporting PAM seems like additional complexity

08:48 <__toor__> well, if tooling I require, only support PAM, no opt out, then that is true

08:49 <__toor__> its all a compromise, like if something requires x11 or systemd, it might or might not be worth to import those just for the tooling in question

09:29 <crymeariver> Is it possible to re-order the outputs in river, so the focus-output {next|previous} can be in order left to right?

09:41 <tiosgz> crymeariver: unfortunately not; outputs are always in the order they were detected. it might be useful to order them by position or have a wrap-around variant for positional focus

09:42 <tiosgz> (but at this point it doesn't make sense to add that to river and there isn't any wm with/without this problem yet)

09:42 <crymeariver> Alright, thanks. I got around this in other wms by having workspaces for specific outputs. I could technically do that in river too, but I'm trying out the river way for now.

09:46 <tiosgz> hmm i feel like we should get used to saying "rwm" instead of just "wm" in order to avoid confusions with xorg wm or with other compositors...

09:48 <crymeariver> What would rwm mean?

09:49 <tiosgz> "river window manager". cos i suppose my above statement is false if wm isn't understood in the river-specific sense

09:50 <crymeariver> Oh, yeah I just call river river, and then wm to mean window managers in general.

09:50 <tiosgz> if you aren't aware, river is undergoing a redesign where the layout generator is getting replaced by something more powerful, basically like xorg window managers

09:50 <tiosgz> of course, river as the compositor is still just river to me

09:51 <crymeariver> I knew something was in the works, but I don't know what the end goal is.

14:22 <larstiq> tiosg: hmm, we _do_ hacve `focus-output up|right|down|left`

15:21 <gbrlsnchs> I'm not familiar with Wayland internals yet, so I was wondering, how would the communication between client (WM) and server (river) be established? Would you recommend me to read https://wayland-book.com/? Any other material for me to read about it? My goal is to write my own WM client when server is ready on that regard

15:24 <Nickli> afaik its all the compositor (wm and river)

15:54 <Nickli> *(wm and server)

16:35 <gbrlsnchs> Nickli: sorry, wdym with "it's all the compositor"?

20:17 <tiosgz> larstiq: yeah. my point was probably that next/previous wraps around, while positional focus (afaik) doesn't. doesn't matter at this point anyway

20:18 <tiosgz> gbrlsnchs: wayland book is a good resource on what's going on. if you only want to use wayland, i think looking at simple clients (including riverctl or rivertile) is another way to go