that's what I figured, but I wanted to be sure there wasn't a good reason to do seperate containers
that's what I figured, but I wanted to be sure there wasn't a good reason to do seperate containers for each app
_thanks!
Pschizoid-level paranoia? 
DIDK why bazzite is not known to a wider audience
_behold! my collection of containers that must absolutely not touch each other
Pnext step is separate physical machines for every application
Pthen when you're truly anonymous you start paying for hundreds of internet connections because you can't trust the vpn providers
J@_cryptagion if you were using a lot of untrusted code, then maybe it'd be a good idea to separate out those. A lot of it depends on whether you trust the app and its dependencies. Things would also be different were sandboxing a more "core" feature to apps on linux. I'd probably care less than I do currently if it were. I'm not really paranoid, but there sure is a lot of code developed by tons of people that could cause problems either on purpose on on accident. An accidental one woudl be an parameterized rm -rf that say evaluated to
rm -rf /home/user/ when it should have evaluated to rm -rf /home/user/path/to/app/fileintendedtoberemoved, but an untested combination of options led it to be that way.
Jthe container setup is more about logical seperation, not running untrusted code
Jif you really want that barrier then you'd use a vm
KIt's only like 6 months old from a user perspective
KStill lots of room to grow hopefully
KSpeaking of which we might actually hit 1K stars before new years
Jyour pulls
Joh that was wrong, sec
J
DI just wish these immutable distros don't grow to be PIA
Jpia?
DPain in ass
Jwhat bothers you about it?
DJust that I'm not used to them
DAnd I have no idea how to manage them
Kshould be less work since the vast majority of changes live in your home dir
Kno dependencies to deal with
Kyou may create and blow away a lot of distrobox containers, but once you get the hang of them it's just something you do
DYeaa
DContainers can use host system fs but, host isn't able to read the container's directory like /etc and /usr
DI installed ms-fonts on an Ubuntu container, but the host cannot read it
Pyou would want to install fonts to your home directory
P$HOME/.local/share/fontsKOr layer them
KDepends on your use case really
KYou can even copy them out of the container into home
KSince they share your home dir
WHowdy!
AThis is happening to my friends Deck too. Everything looks fuzzy at anything other than 60hz. Setting it to 50hz makes everything freak out pretty bad.
RRThere's a line here that is quite interesting
RNormally we follow Nvidia’s Production branch for driver releases, however we’ve added Nvidia’s 545.29.06 drivers from the New Feature branch for compatibility on waylandhttps://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90
We’ve also added the required explicit sync patches for xwayland in order for this to work:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/59
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300
As of now the full driver set has been tested and working on wayland in both KDE and GNOME on at least a 2060 super, gt 1030, and gtx 960m with no major problems.
GitLab
This is a new Linux explicit synchronization protocol based on DRM synchronization objects 1. ...
GitLab
Here is our proposal for adding explicit GPU synchronization to the DRI3 and Present extensions, along with an implementation for Xwayland. While we at NVIDIA may be particularly...
GitLab
Protocol specification to accompany xorg/xserver!967 providing...
GitLab
This implements the linux-drm-syncobj-v1 wayland protocol to handle the global migration to explicit sync. At a high level this hooks up the fds passed through the explicit sync...
RAFAIK Bazzite testing also uses these patches right?
WWhat Bluetooth codecs does bazzite support on oled currently?
DYes
RMakes sense
RUnfortunately it doesn't fix my issues but it's cool to know that we are getting the driver to a workable state by community efforts
RHopefully 550 it's not as problematic
RMinor bug I noticed -
Also, BoilR is available via Flathub now - https://flathub.org/apps/io.github.philipk.boilr
just command to install BoilR fails to properly download it (creates an empty file named BoilR), probably some error in jq syntax used there. Also, BoilR is available via Flathub now - https://flathub.org/apps/io.github.philipk.boilr
- so unless there are some downsides to it, I think it would be better for Bazzite Portal to just install flatpak version instead of dling it directly from github.
GI will say Bazzite is the first time I've felt like switching my main desktop over from Arch in over 8 years. It's really well done, and having an immutable desktop with distrobox is tempting me over
GDefinitely deserves more traction. It's excellent (same with the entire ublue project)
GProbably helps that flatpaks have matured to a point where I feel they can cover most desktop use cases
RSame story with Greenlight - current install via just/portal fails. There is Flatpak version available now - https://flathub.org/apps/io.github.unknownskl.greenlight
Flathub - Apps for Linux
Greenlight is an open-source client for xCloud and Xbox home streaming
