You don’t need to learn about rebase, but if you want to: bazzite is built on top of ublue, which is built on top of fedora. Atomic uses layers and images, like docker containers, which means when they install stuff they add layers with what they want to add. Since they share foundations, you can switch between them with a single command. Basically it would be like if you installed Debian, but wanted to switch to Ubuntu. You could run a single command to “rebase” then when you reboot you would be switched over.

You’re correct, live USB or install media are the same thing in this context.

I’m on NixOS right now (wanted to learn it as a project), but was on bazzite before and it’s the first distro we’re I no longer felt the need to distro hop. I even installed it on my friends computer who doesn’t game, just because it’s the closest I’ve experienced to “it just works” out of the box and stays working. It’s what I’ve been recommending to all my ex-windows friends. Bazzite sounds perfect for you then.

So the OS can rollback (and if a boot fails it will automatically try a previous “image” to try and boot successfully). But your user “land” isn’t controlled by the OS, so it’s always a good idea. Especially because that’s where all your files and configs are. You never know if a hard drive will fail or fry, and having it backed up will save you from that panic. If you do setup a backup solution (whole other conversation) you only have to care about your /home directory, and some people might also backup /etc. for software, besides the one they recommended, “sync thing” is good for syncing files between devices and “borg backup” is good for doing more traditional backups.

TLDR: automatically, but you can manually set things.

Every time the OS upgrades. It keeps an image/version/generation or 2 automatically, but you can also “pin” a working generation if you want to to not eventually get blown away (it’s a rolling couple versions, so it will delete older ones and it updates and adds new ones to save you space). The updates are manual unless you set them to be automatic.

Flatpaks are “containerized”, but you don’t have to learn docker or anything. “Bazaar” is their app store for flatpaks. Basically when you want to install software, open it up, search for what you want. And click install. It handles everything else for you, including updates for the flatpaks. Basically you don’t even have to know their flatpaks. Just know to use the app store “Bazaar” instead of googling for Debs or using apk install.

Distrobox is a container “toolkit”. But honestly the GUI tools bazzite provides pre-installed abstract any knowledge you would need to learn away, you don’t have to learn or understand containers, all you need to know is “if I can’t find it in Bazaar, ill have to install it in distrobox”. Then you use the GUI tools (sorry, keep blanking on the new one they have is called, maybe “Pods”, old one was “BoxBuddy”), create ONE distrobox container (for you probably select Ubuntu or Debian from the drop down), leave the defaults. And then run any “apk install” commands in it instead of bazzite.

Lol no worries, that’s a great way to describe it.

TLDR: atomic are more “just works”, and harder to brick or get in a bad state, can “self heal”, but that comes at the expense of having less control over OS configuration (parts normal users wouldn’t touch) but still have complete control over parts you do want to change. Other compromise is relying more on flatpaks and containers than traditional package managers like apk.

Long:

So the big shift atomic distros did compared to vanilla or traditional distros, is the idea of having different parts of the filesystem read only and other parts read and write. It works similar to how phones work, where the “OS” part is read only and gets changed during updates, and the “user” part is full access.

The benefit of this is that if you brick your install changing something you shouldn’t, or the distro pushes out a bad update, your machine can boot into a previously good state.

The read only OS part is distributed through images or layers. When you update the distro it just download the new layers, and sets up a new boot entry with the upgraded layers, but keeps the old layers so that you can always fall or roll back to if something goes wrong.

The read write parts are all the stuff that users typically want to or would change.

Things like /boot, /usr are read only, the OS part. Things like /etc (lots of config files/, and /home (user directory) are full access.

Set updates to auto, and then ignore anything that mentions rpm-ostree as a way to install anything (at least until you’re more experienced with an atomic distro and learn when to and when not to).

Try to always go to flatpaks first for software (anything listed in their new Bazaar software store).

After your situated, spin up a “distrobox” container (they have a bunch of tools pre-installed to make it easy) of whatever distro you’re comfortable with, and install any software you can’t find a flatpaks for, in distrobox instead. I recommend sticking to just one, don’t try to spin up a couple for different use cases until later down the line. So if you are familiar with Debian, you can spin up a distrobox of Debian or Ubuntu, and then use “apt” to install stuff just like you’re use to.

The cli tool “ujust” has a custom script built in for basically any tinkering a user would want, and is way more reliable than following documentation and trying to do it from scratch. It’s lacking extremely niche cases, but anything gamer related is should have.

Their discourse (forum) is typically friendly and has knowledgable people willing to help as long as you provide enough info and are willing to follow instructions.

Just in case you didn’t circle back, the other commenter is correct. Just like Debian repositories, Arch repositories also haven’t been poisoned like this . AUR has recently, but that’s equivalent of like on Debian adding 3rd party repos, but AUR is just a meta collection of those unofficial user repos basically. Arch documentation even warns against blindly installing from AUR, and to read the pkg build first since it’s basically the same thing as copy and pasting a curl command from a GitHub repo’s readme.

No problem!

I completely know what you mean, it took a lot of research before I felt comfortable enough trusting a public instance enough to use.

So that solution would still decrease their ability to fingerprint you by a lot, but really the big problem would all the people/scripts randomly hammering your ip. They wouldn’t get past your password. But it being public and discoverable would meant you’d constantly be getting hit with a bunch of automation scanning your ports. And the security risk isn’t the concern, it’s more the heavy traffic slowing down your connect from them. It sounds like you’d be fine from a security stand point. But you’d have to put up something to block the traffic.

You could always self host, use that when you’re at home or connected to home through VPN and use it for more personal searches, and then use public instances when you’re connected to other vpns for more general or vague searches. Mixing and matching like that will at least add some noise and make you less identifiable. Kind of best of both worlds.

(Not an expert) hosting your own instance will make you more identifiable to big tech than if you used a public instance, but it would still increase your privacy compared to giving everything to them, and also prevent you from giving a public instance your data. I currently use “priv.au” but do plan on hosting my own in the near future. Some people who host their own instance even intentionally open it up to the public to crowd source more data points so that their traffic blends in better (not saying I recommend that though).

Tldr: it should still be worth it

In regards to connecting, you should still be able to hop from other vpns to your home network, just keep in mind they you will get higher latency jumping from their VPN network back to yours. I don’t recommend opening it up publicaly just to do that, unless you plan on going all in and having something in front of it like “fail2ban” and Anubis" another option is looking into “tailscale” and if you don’t trust their central server you can selfhost with “head scale” or use a different but adjacent product “pangolin”. These products basically let you creat your our VPN that spans multiple network.

OP, I had a similar issue, and I had to blow way the wine prefix.

Someone else will have to chime in, but I believe it’s the “compat data” folder, but be careful because some games like to keep saves in there.

After you do that, as someone else mentioned, try GE-Proton.

Also I’m not familiar with your card, if it is older, I believe there is a certain gen where they stopped adding older cards to the newer drivers. A lot of the distros you mentioned are new, maybe roll the dice and if you feel up for it try Debian. If games boot, the. You either have to grab the open source driver or use an older version.

Also for the future (after you’re up and running) you shouldn’t skip the shaders. Steam crowd sources them from similar configs and build, and vulkan can generate them before playing so that game play is smoother. Direct 12 trys to generate shaders during game play, which results in stuttering.

Oh and pangolin for a VPN tunneling replacement.

Proxmox communities are also good for some ideas, basically every sysadmin I know eventually spins up a cluster and builds their ideal tech stack that they wished they could use at work.

You should stick with more “corporate” or adjacent distros, that way they (or you) can purchase a support contract without having to reinstall or shift later down the line, so more like fedora or opensuse.

Postgress is more mainstream than SQL server in cloud native environments, no licensing. And plenty of managed option without too much of a lift and shift.

Next cloud might be an option to replace office 365, should look at open/only office (forget which one is active) along side libre office.

I think jitski can help replace zoom/teams, kind if.

Biggest hurdle will be excel and Active Directory Nothing else comes close to as feature (and hair pulling bug) filled as excel.

For AD there’s not even really an equivalent, but that can be a good thing. I would look into combining an Oauth service (keycloak is suppose to be good for “consumer” grade, Okta or whatever preferred cloud provide has for more professional) along with something like a casbin library (at least for servers/development).

I highly recommend following all the self hosted and open source communities here on Lemmy, I find new tech at least once a week from them that I consider taking to my bosses.

If possible it might help to have a couple demo PCs out so that they and try different desktop environments. Some might be more enthusiastic if they can not only play around with it when it’s up and running (and gives people something to do while your helping others) but also if the DE matches their “workflow better” it also gives you a chance to show them how to do common tasks. Maybe different demos have different “suites”, like here’s the gaming demo, here’s regular, productivity, etc

I agree with some of the other posts, I’d stick with 1 distro (whichever all the helpers are most comfortable with) so that you can speak confidently about it, and decrease the chances of something going wrong and you having to break out Google and the terminal. A DE is an easier choice to explain that different distros affecting and impacting things they can’t see. Especially if you might have to provide tech support during the beginning. Maybe just say a throw away line or 2 about there being different distros, just like there’s different kinds of cheese. Still same thing at its core, just different options.

I also recommend a couple spare external hard drives for them to back up their files.

I’d maybe do just a brief overview at the beginning. And go more in depth afterwards so they don’t get overloaded.