• 1 Post
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle
  • 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.






  • 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.




  • 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.


  • 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.