I assume it’s a different system since it works on Wayland, but idk

Honestly, they just shouldn’t have added support. GNOMEs been causing problems for basically everyone else for a long time. If they want to do their own thing, that’s fine, but we shouldn’t but everyone else shouldn’t have to do extra work to accommodate them.

Eh, there’s a completely independent reimplementation of the server, so I’d be surprised if the same doesn’t happen for the apps if there’s a real issue that comes up

Yeah, I’ve been spoiled because most of the heavier workloads I do is all programming related and Linux tends to be better there.

I have had issues with Autodesk products, but I’m able to get 99% of what I need with freecad.

Fair, but in the context of gaming I doubt there are that many people gaming on their work machine.

deleted by creator

If you self host bitwarden/vaultwarden, each client stores an encrypted copy of the database, so even if your server was completely destroyed, you’d still have access to all the accounts you’re saving in it.

Yep, it does!

You’ve been hearing about it because there’s been a lot of pushback at all stages of them doing it. That doesn’t mean it won’t happen, they’ve kept pushing for it and there’s no indication they won’t go through with it.

SteamOS is based on arch, but it has major differences. The steam deck’s update mechanism is completely different from normal arch Linux.

Arch normally immediately updates to the latest version of every program. This is usually fine, but when a big bug is missed by the developers, it can cause problems.

The steam deck updates a base image that includes all the programs installed by default, and by the time it releases a lot of them aren’t the absolute newest version. When valve updates SteamOS they definitely run a lot of tests on the base image to make sure it’s stable and won’t cause any issues.

SteamOS is also an immutible distro, meaning the important parts are read only. This also means updates are done to everything at once, and if something goes wrong, it can fall back to a known good version.

Not to say arch Linux is unstable (its been better for me than Ubuntu), but SteamOS is at a completely different level. It’s effectively a completely different distro if we’re talking about stability. I think what they’re hoping is this support would allow arch to build out testing infrastructure to catch more issues and prevent them from making it to users.

Yeah, recently I’ve run into 1 game I’ve wanted to play that I just couldn’t (Valorant so probably a better outcome lol) and maybe 2 that had any sort of issue.

If you’re mainly into competitive games it’s still rough, but otherwise it’s honestly smoother than my friends on Windows often.

Yeah, imo the problems solved by using snaps for core system stuff are better solved with immutable distros, and I see very little reason to use snaps for anything else.

Yeah, sorry couldn’t resist.

snaps are very similar to flatpaks and, honestly, is technically better in a lot of ways.

Snap can be used for basically an entire system, while flatpak is limited to graphical apps. (Ubuntu core is built basically entirely off snaps.)

Snap is controlled by canonical, and the backend for the snap repo is entirely closed source. I’ve heard snaps are also easier for developers to work with, but I haven’t experienced that side of them.

Snaps automatically update by default where flatpaks don’t.

Snaps also get treated as loopback devices when they’re installed, which bloats a lot of utilities. (And they keep a few old versions around which makes it even worse). For example, you could run lsblk and if you’re using snaps like 90% of it will be snaps you’ve installed instead of actual devices.

Flatpaks are also noticeably faster to start up, which for desktop apps matters, but wouldn’t really matter for a server that’s aiming for a lot of uptime.

The loopback device issue is the main reason I don’t use snaps. I also like flatpak being completely open, but realistically that doesn’t matter for much. There used to be an open snap store, but that shut down because nobody used it.

The easiest way to think of it is flatpaks are AppImages with a repository and snaps are flatpaks but bad.

That has benefits and detriments. Appimages contain everything they need to run, flatpak’s mostly do, but can also use runtimes that are shared between flatpaks.

All flatpaks are sandboxed, which tends to make them more secure. AppImages can be sandboxed, but many aren’t.

Flatpaks tend to integrate with the host system better, you can (kinda) theme them, their updates are handled via the flatpak repo, and they register apps with the system.

AppImages are infinitely more portable. Everything’s in one file, so you can pretty much just copy that to any system and you have the app.

Yeah, but people installing GrapheneOS probably aren’t in the vast majority of users

deleted by creator

Oh, sorry, it’s called “Panels” app store says it has ads, but I just denied it network access and I’ve never seen one.

Aegis, its not on by default, but its recently customizeable, so play around with the settings

Edge Panels are a samsung only thing, but I use a similar app on my phone.

I use it less as a dock and more as a way to access stuff I want to quickly be able to go in and out of.

For example, the 2fa app I use auto closes when I copy something to the clipboard, so I just swipe into the app, copy it, and I’m back where I was.

Its also great for apps I don’t use frequently enough to want on my home screen, but when I do need them I don’t want to hunt around for them

I agree with pretty much everything they’ve said, though I’ve gotten more use out of the swappable parts. I have a desktop I use for things I need a powerful system for, but being able to swap in the GPU when traveling is great.

When I’m at home I have basically everything on USB C and the empty expansion bay.

When I travel I swap in the GPU and add an HDMI port and some USB a ports.

If you don’t have stuff set up like I do I agree it’s mostly just a reparability / upgradeability thing.