Custom Linux Distribution just for Gaming

Martin@discuss.tchncs.de to Linux@lemmy.ml – 251 points –
Bazzite - The next generation of Linux gaming
bazzite.gg

Bazzite comes ready to rock with Steam and Lutris pre-installed, HDR support, BORE CPU scheduler for smooth and responsive gameplay, and numerous community-developed tools for your gaming needs.

107

You are viewing a single comment

Inconvenient package management, manual theme installation and anything that involves changes to the system.

Thank you for the reply!

Inconvenient package management

Fair.

manual theme installation

I assume this is based on an experience with Kinoite? Am I right?

anything that involves changes to the system

I'd argue "anything" is too harsh. But yes, there are definitely edge cases that are either very/too cumbersome or outright impossible to achieve on Fedora Atomic.

However, I'd argue that while the associated paradigm shift and learning curve do require some commitment to adjust to, it is a more sane way of running a system for most people.

This comment shows why I like Lemmy more than Reddit. Nuanced, acknowledging when the other person has a point without just yelling at each other.

Hehe. I agree that the community on Lemmy gives off more mature vibes. I suppose one should at least credit them for being idealistic enough to be on Lemmy rather than Reddit.

Thank you for spreading the positivity ๐Ÿ˜„!

Inconvenient package management

Fair.

If there's a flatpak, no problem.

Once you realize you do package management in distroboxes rather than the main OS (rpm-ostree etc), no problem, plus you have the AUR at your disposal.

So Ima go not fair, although there is something of an education gap atm.

I'm a big fan of Fedora Atomic. However, even I have to admit that knowing how to install packages through dnf is simply more convenient than knowing and understanding the nuances between rpm-ostree, Toolbx/Distrobox and flatpak. And I haven't even delved into ujust and brew that are found on uBlue images.

Furthermore, even if we would limit ourselves with what Fedora Atomic prescribes, we see the following inconveniences:

  • rpm-ostree ; I know --apply-live exists and I know systemctl soft-reboot exists. But still, if you have to resort to rpm-ostree, then both the speed of update/installation as well as the need to reboot (or live on the edge with --apply-live) are inconvenient compared to dnf.
  • flatpak ; It's inconvenient that I have to alias the installed package if I prefer sane naming conventions when accessing it through the terminal. Furthermore, stuff like the NativeMessaging portal not being available yet for sandboxed browsers and how that prevents any local password manager to interact with them (without hacking your way through; which, once again, is an inconvenience) is inconvenient.
  • Toolbx/Distrobox ; the fact that you'd have to setup quadlets (or simply rely on uBlue images to do it for you) to keep them up to date, up and running is an inconvenience. The fact that distrobox-export has to be resorted to for accessing these directly from your 'App Drawer' is an inconvenience.

The fact that there's no centralized place for upgrading all of the above (unless you rely on an uBlue image) is an inconvenience.

I could go on and on, but these should satisfy in revealing some of the more obnoxious inconveniences.

Fair cop on the inconveniences, although I've found it fine after an adaption phase, coming from fedora it was lesser than hopping to a new distro. Hard agree on knowing the nuances being problematic, clarity and accessible education is sorely missing, certainly the steepest part of the learning curve.

I just run 'distrobox upgrade -all' in my Daily.service, didn't need quadlets (although after adaption I quite like them for containers now).

Iโ€™ve found it fine after an adaption phase

Though credit where credit is due. At this point, so well-beyond the adaption phase, I simply don't see myself use anything else. This is my home. Though I have to admit my serious interest in QubesOS (and the upcoming Spectrum OS).

Hard agree on knowing the nuances being problematic, clarity and accessible education is sorely missing, certainly the steepest part of the learning curve.

Agree. I'm at least thankful that it's a lot better than it used to be. Like two years ago, when as a total noob to Linux, I decided to cold turkey quit Windows and installed Fedora Silverblue on my machine. Well..., those first two weeks were pretty traumatic ๐Ÿ˜‚. And, back then, there was not a lot out there. Luckily, I found this article that helped me to grasp the basics. And it has been smooth sailing ever since.

I just run โ€˜distrobox upgrade -allโ€™ in my Daily.service

That's pretty cool (and straightforward). Why didn't I think of that ๐Ÿ˜‚? But yeah, quadlets FTW.

Everyone has an opinion on this. Won't argue with yours.

Fair.

Btw, was I correct on the following?

I assume this is based on an experience with Kinoite? Am I right?

Yeah, I had that at the beginning, then added to my fstab

# enable sddm and therefore good themes
/var/sddm /usr/share/sddm none rbind 0 0

and then it works, kludgy, but sddm is apparently working on allowing themes in /etc, sometime soon.

Thanks for pointing that out!

Bazzite also includes an entry in their documentation in which they explain how theming on Bazzite works exactly.

No. I know that installing a GTK theme requires putting the files in /usr/share/themes that is not in /home. That's why I said it. As an advanced user I love customization and freedom so immutable distros are a no go for me (and for many people imo). I didn't even bother trying.

FWIW, by creating your own images (through BlueBuild or tooling offered by uBlue) you could bake themes directly into those folders.

However, I totally understand why you'd not feel compelled to do as such ๐Ÿ˜…. Especially if your current distro/system works splendidly.

Sometimes, placing it to ~/.local/share/themes works as well*.

However, I totally understand why you'd not feel compelled to do as such ๐Ÿ˜…. Especially if your current distro/system works splendidly.

This.

Sometimes, placing it to ~/.local/share/themes works as well*.

Ehh I prefer system-wide installation. I think it's a habit from times when installing an Android app with root (so the OS treats it as a system app) increased its performance.

Ehh I prefer system-wide installation.

Fair.

I think itโ€™s a habit from times when installing an Android app with root (so the OS treats it as a system app) increased its performance.

Interesting. Didn't know this was a thing.

Thank you for sharing those links, I have been struggling with making rpm-ostree compose go from a yaml to an ISO, these look like they might reduce the level of effort!

You're welcome!

FWIW, last year, through what became BlueBuild eventually, I had my own image with all kinds of modifications within a weekend. And, perhaps most curiously, I was a total noob when it comes to containerfiles, github, git etcetera. So, if I somehow managed, then you should definitely be fine.

Wish ya good luck! Consider reporting back ๐Ÿ˜‰.

Sounds like you ramped up pretty quickly! Were you pretty familiar with the terminal beforehand or just jumping in?

I'm chronically unable to finish projects but with such a fantastic tool maybe this one is the one? I'll try follow up if get something going.

Were you pretty familiar with the terminal beforehand or just jumping in?

Yes, I did have some familiarity with the terminal.

Iโ€™m chronically unable to finish projects but with such a fantastic tool maybe this one is the one?

I hope it will work out for ya!

Iโ€™ll try follow up if get something going.

Thank you for your consideration ๐Ÿ˜Š!

Yeah, I had that at the beginning, then added to my fstab

#enable sddm and therefore good themes
/var/sddm /usr/share/sddm none rbind 0 0

and KDE themes with sddm components install fine now (most themes install fine into /home, does Gnome really not have per user themes?)

Essentially you can tactically make things mutable as needed, use sparingly, but maybe not even trying lessens your opinion, no?

Why would I use a system that isn't supposed to change if I want to change it? It's just not for me and I don't want to waste my time reinstalling everything. And my opinion isn't completely proven without trying but I have theoretical knowledge.

Why would I use a system that isnโ€™t supposed to change if I want to change it?

There's a bunch of benefits, atomic updates, intrinsic rollback, security of immutability, safe automatic updating and it goes on. Some things are not quite ready yet, e.g. things like sddm which should probably install themes to /etc (which they're working on), so as often happens in linux, workarounds ensue. Making one directory mutable does not destroy all the benefits.

Inconvenient package management

Can't you just use the Gnome App Store or whatever it's called?

GNOME Software but it only has Flatpaks which my machine can't quite run smoothly. It's weird that I use the GNOME ecosystem without Flatpaks though. Anyways I just use the AUR on my system that's based on Arch btw.

With an immutable system the flatpaks would be the way to go