what is the cleanest way to install pulse audio instead of pipewire?
what is the cleanest way to install pulse audio instead of pipewire?
Kyou wouldn't be able to without making a custom image
and what if I install it alongside?
XD
Kpipewire-pulse is there, it'll conflict
CStep 1: provide a VERY good reason to even try, or try to assist with doing so..
I am genuinely curious about why you would
I am genuinely curious about why you would
Pulsemeeter
It's like voicemeeter
but for linux
I do not know how to make it work with pipewire
AWhy do you need i
AT?
Maybe not even pipewire is the problem
When I run it that happens
WI noticed that valve is recommending against cryoutilities as of 3.5. what's the recommendation on bazzite?
Kbuilding w/ this on
:testingAPls test first that blocks for 5s
KBazzite uses ZRAM same as Fedora and the next SteamOS release
ADon't use cryoutils, it doesn't really work on Bazzite
KNo swap file what so ever
K@Qwx576SDZf If you want, when this is done you can rebase to
:testing and see if your screen still unlocksKGNOME closed the issue stating what you experienced is not a bug
Kso we're gonna try and work around it
KI hate my internet 
that almost took an hour
that almost took an hour
DWhy is this?
KValve hasn't said anything about Cryo
Kbut they are dropping the concept of a swap file in the next SteamOS release entirely
Kso Cryo will do absolutely nothing
DAh ok
WI didn't fact check it, but what I read is today was supposedly a quote from valve saying they no longer recommend cryo on 3.5 because it supposedly addresses the same things cryo does
KValve has never recommended cryo
KIf they did, it would have been built into SteamOS
Kthe only time Valve even spoke on Cryo was to ask for reproducible benchmarks showing it made an improvement (none were provided)
KCryo is a collection of tweaks which have been spread around in the linux community for a long time, most of which are known to harm performance or not help it.
AI don't know about the other fixes, but a larger swap file definitely helped with system stability when I was doing PS3 emulation
ANever helped with performance though
JIs there a dbus-based screen lock vulnerability which could be replicated in KDE?
JYou'd probably have to use a different dbus address
KNot that I have seen, if there was it would have been triggered by the exact same thing
JI'm going to test this in KDE to see if I can replicate it
JIf KDE's login screen can be unlocked with
loginctl unlock-session, then I think it's more likely that a proper fix would be to harden the polkit rules to require some form of authentication for binaries/processes that aren't whitelistedJ(I'm no polkit expert, I just think it seems a teensy bit too trivial for someone to fire off a sleeping payload with a simple
sleep $SECONDS; loginctl unlock-session)KThe whole reason this is using that path too is it's the only way to request gnome not to fall asleep
KIt just happens to also unlock the screen from a locked state
KOr at least it was, maybe things have changed
KStill seems very suspect
Ayou cant, your user has the permission to unlock your session
Athat payload can do whatever somebody sitting on your keyboard can after it unlocks your session
Aso from a security standpoint, not being able to unlock your session is kinda mut
JUnlocking implies that there's a lock. When you have services like gnome-keyring storing your passwords, you don't automatically unlock them even though the files and the contents inside are owned by your user. You still need a security mechanism to ensure that not just anyone is accessing your resources. We already do this in several ways with the login screen before or after login, including A) what you know (password) B) what you have (smart card) C) what you are (biometrics such as fingerprint)
