I imagine I'd probably need to make a custom image since I doubt I can run the whole desktop in dist
I imagine I'd probably need to make a custom image since I doubt I can run the whole desktop in distrobox
AIt's possible for everything to not work after undocking
A
AFrom stealing your job to stealing your babe
VYeah pretty much
Ihmmm
ZDamn, I looked at journalctl at the same time, some interesting errors show up but nothing conclusive
Imight come down to whether it's easier to do as a ublue image or by using nix on stock steamos
Lhey 
Some of you play FF14 on Baazite ? If yes, do you have a solution for ACT ?
Some of you play FF14 on Baazite ? If yes, do you have a solution for ACT ?
Dis anyone aware of a copy/paste bug with dolphin and podman containers?
Dfor some reason, while a container is running, and i have a folder mounted to it, i copy files and they show up inside the container with ?????? permissions:
-?????????? ? ? ? ? ? image.png
-?????????? ? ? ? ? ? image.svg
-?????????? ? ? ? ? ? image.png
-?????????? ? ? ? ? ? image.svg
Dwas driving me crazy that the astro compiler was giving me weird errors, and realized it was the filesystem permissions, i tried copying the files over while the container was shutdown, i verified the permissions are correct on the host, but when i spin up the container again, only the files i copied with dolphin have messed up permissions
Dcopying with
cp works fine, wtfDit is dolphin
Di copied tako{.jpg, .png, .svg} just now with
cp using the host filesystem, the container does not have access to ~/Downloads, on the left hand side podman container is running, executing ls -la on the mounted directory, permissions are okay
Dhere it is copied image.webp with dolphin... im not crazy:
Danybody know where i could report this? KDE?
Arootless?
Anever use the rootless ver, its garbage
Pit's not really a bug
Athe fact that the rootless ver exists means that you always need to type sudo and remember which one is which
Awhereas with docker its always sudo
Pundesired behavior yes, but this is exactly what is meant to happen when podman (or anything else) interacts with another filesystem while not necessarily being enlightened about it
Mdam
Adoesnt have to do with the filesystem
Arootless messes with permissions
Aencodes them differently
Pand those permissions have to do with the FS, this applies beyond the scope of just podman
Ai tried using rootless for the project im working on
Prootless is not great
Ai found 0 benefit and it only caused issues
Aalias podman='sudo podman'
PLOL
Aits meant for obscure RHEL deployments that cant use sudo for one reason or other
Aalso podman launches a daemon which blocks you from unmounting devices
Abut other than that its daemonless
Aok
Pi would have to agree with that assessment
Aso i get 0 of the daemon benefits and all of the daemon disadvantages
Aat least with docker i have a service i can turn off
Pi guess if you're doing like. edge deployments. it's kinda a non-concern too.
Alike using podman instead of docker? yes
Pidk i guess i'd rather have the option to use rootless at all than no option
Ano, if you have root perms it should always be root
Ait should priviledge escalate
Aand hide rootless behind a feature flag
Pright so we both agree it should still be a thing
Dits not 100% rootless
Drunning as root inside the container
Adid you launch podman with root or not?
Pi'm not saying it's a sane default or useful for this env at all but having rootless is probably good for certain engineers
