pontiffkitchen0

That’s probably what I’ll do, atleast watch and study the first one before hand and see what I’m getting myself into. And I appreciate the call out, I’ll keep that in mind that I should be open to following what someone in the party says to do instead of blindly following possibly outdated strats from early videos. I really do appreciate this community, and the FF14 community as a whole. It’s not universal, but overall it’s the most welcoming and friendly gaming community I’ve ever experienced.

I could have missed something, but quickly scanning his job history shows he started as an intern at the beginning of AWS while getting his MBA, and then became a Product Manager. Didn’t really see any programming experience or knowledge, not sure he has the context and foundational understanding to be able to justify making claims like that.

Seems like most of the people who talk about AI eliminating programming jobs, haven’t ever had a job writing code or have a firm grasp of what those kind of roles actually do.

The cynic in me thinks all these articles from executives making such bold claims are to scare developers into thinking we don’t have as much leverage in the job market as we do, even after all the layoffs it’s still a workers market. The realist in me thinks they probably just like hearing themselves talk, and everyone’s guilty of talking about something they know nothing about. According to whoever’s razor it was, it’s probably the latter.

Thank you for taking the time and providing some recommendations, I’ll check them both out! First one sounds perfect for me wanting to go in kind of blind, but some good puns are really tempting lol.

I really appreciate the info and perspective you and the person above you provided! I kind of want to go in blind, but probably will chicken out lol. Do either of you have recommendations for videos or guides in case I end up studying first? I plan on using Red Mage or Dancer if that factors in.

What GPU are you using? What influenced you to add “Oibaf PPA” instead of using the default built in Mesa drivers that came with Mint? No judgement, just trying to figure out what led you here, so we can unravel it. Because as the other poster mentioned, Vulkan for Amd should have worked out of the box on a fresh install.

Edit, to clarify, did you add the repo because you thought that mint didn’t have drivers and that was the way to get them? Or was there a different reason you needed to add the repo?

This documentation is for bazzite, but they have a lot of the same stack under the hood. “Broadcom’s WL driver can be installed since it is needed by some hardware. Disabled by default. Enter “just use-broadcom-wl” to use it.”. You could try to see if aurura has the same “just” options, that’s where I would first research. If not, then yeah, “rpm-ostree” would be how you install the package, just like you said, just not sure of the commands for local files. Also there is a tool to “roll your own” distro built on top of any of the ublue work, it’s basically how bazzite and aurora exist. So you can layer the packages like the other option you said. https://github.com/ublue-os/image-template

It depends on what your metrics are for energy and resources. Are you talking about the end user hardware, or are you talking about developer time and effort. If it’s the former, you’re right, if it’s the latter you’re completely wrong. And while there’s merit to your point (if it is about end user storage, energy consumption, etc), that’s not really in short supply while open source developers free time is.

Kind of. CBT is (oversimplification incoming) just every time there’s a negative thought, you make a habit of thinking a positive thought, so then your brain starts associating the connection. Basically retraining your brain to naturally go from negative to positive path, and over time your brain gets rewired to do it without consciously doing it.

Exactly, ublue and in turn bazzite basically (oversimplification) add their own “layers” on top of fedora silverblue/kinotie, basically doing the same thing you do when using rpm-ostree.

I’m so happy to hear it! I’ll put off searching, for now :). If you do find the answers you should definitely post in this thread, I’m curious and others might find this thread when they encounter the same problems. No problem! I’ve had a lot of help from the community, so just paying it forward!

I really appreciate your positive attitude about having to change your workflow when using a new technology.

Just a tip to help when you search for how tos, tips, or guides: since bazzite is built on top of ublue, and ublue is built on top of fedora silver blue/ fedora kinotie, you can use those as search options as well. For example, you can use “how to install goverlay on fedora silverblue” instead of “how to install goverlay on bazzite”. Since more people use fedora silver blue or kinotie, it will increase the possible results, and they SHOULD be 100% compatible as you can rebase to either 3 (as long as they use the same DE, can’t go from gnome to KDE or vice versa).

I’ll try to find time to provide good links for those 3 remaining programs (I know how hard it is to find and use a replacement, or be missing features).

Here’s one for now: NordVPN for Linux** this link seems like a good resource: https://www.answeroverflow.com/m/1153350314028695562

• I currently use proton vpn, but I’ve had nord in the past and believed I used the”openvpn” option mentioned. Openvpn is a common standard with lots of support, and most vpn providers offer it as an option.

No worries! You’re doing exactly what’s recommended, so I’d say you’re on the right path! Main thing is that rpm-ostree is the built in package manager, so like rpm, dnf, apt, Pac-Man, etc. so if you’ve used any of them before, it’s going to be pretty straight forward. And yeah, just comment or message me and I’ll try to respond when I get a chance. I’m no expert, but I know a bit

So just to clarify, it’s recommended to limit they layers, but it’s not a hard rule or anything. The reason it’s recommended for a couple reasons.

One reason is that the layers are basically your “core” install, your “actual” os. One of the big benefits of atomic distros is the inherent stability, and by adding layers you are adding more risk and complexity, which doesn’t eliminate the stability but it does decrease the odds of it being as stable and reliable.

Another reason is that the more layers you have, the longer updates are going to take, and the more storage space used. Atomic distros usually keep multiple “versions” around (current and previous), so if you install 10 layers you’re really taking up twice that space. Atomic distros sacrifice disk space and update speed, to increase reliability stability and reproducibility. I think it’s a fair trade off, but a bunch of layers do shift the scales a bit more towards a net zero. Also besides have two versions (usually standard), you can also pin versions that you want to keep around, for example let’s stay you’re on plasma 5 and upgrading to 6, you can pin the version with 5 until you’re confident that 6 is working out for you. In the grand scheme that’s not a lot of storage, especially when cheap, but still worth factoring in.

There’s also concern about file conflicts, inheritance (a layer overwriting a config that’s used by the base or lower layers), etc. I wouldn’t worry about it too much, just in general it’s better to use distrobox or flatpak where possible, and only use rpm-ostree where it’s the only option.