bazzite VS relax-intel-rmrr

Oh neat! Thanks for the information.

> running Steam on Bazzite (https://bazzite.gg) inside Proxmox.

Does this mean you can pass the gyro controls onto Steam Link or GeForce Now or some such? I have no interest in retro games, but it would be awesome to use gyro aiming for shooters...

https://github.com/ublue-os/bazzite/blob/main/Containerfile#... has, in addition to fan and power controls, automatic updates on desktop, supergfxctl, system76-scheduler, and an fsync kernel:

  rpm-ostree install rocm-hip \

I went looking for KDE, but was disappointed. From the FAQ on https://projectbluefin.io/:

> What if I want something like KDE or another window manager?

> Bluefin is an opinionated GNOME experience. However Universal Blue provides a maintained set of base images for anyone to be able to make a custom image. We hope Bluefin acts as an inspiration for others to build their own communities around user experiences. For example check out Bazzite if you want a great KDE gaming experience, similar to SteamOS.

The Bazzite link 404s, but there is info at https://universal-blue.org/blog/2023/11/08/bazzite-20/ and https://github.com/ublue-os/bazzite. Seems mostly focused on SteamDeck.

It's a cool list of patches.

I love these projects that bundle a bunch of cool things together with a base thing. Bazzite is a SteamOS project that similarly bundles all kinds of crazy things, and was a very popular recent submission, for another example. https://news.ycombinator.com/item?id=38828040 https://github.com/ublue-os/bazzite

The maintenance style here looks difficult. They seem to somehow take chunks of new chromium releases and make commits with those dropped in changes, and fix random stuff for a while. Looks very arduous. It makes me appreciate a somewhat opposed style, the Debian's Quilt model, where you have take the upstream and keep reapplying a set of patches to upstream. Maintaining is then just re-hacking any patches that break, and authoring new patches, whenever reapplying breaks. Seems like it'd be much easier to maintain, long run.

I was also hoping for something like the Quilt model because it seemed like it would be a good way to learn some shit about Chromium! Having the patches on hand would point to some key parts of the code-base, I feel! Im not sure how I'd learn what went into this fork, other than meticulously going through history. The readme also doesn't link to where it sources it's many patches from (which is another thing Bazzite did an excellent job of!).

Kind of interesting seeing a spreading focus on using more/modern x86-64 extensions spreading. Ubuntu is dabbling with what they are calling x86-64-v3, Red Hat too. https://www.phoronix.com/news/RedHat-RHEL10-x86-64-v3-Explor...

https://opencontainers.org/

Here is Containerfile from the repo: https://github.com/ublue-os/bazzite/blob/main/Containerfile

Hadn't heard of Bazzite.

> Bazzite is an OCI image that serves as an alternative operating system for the Steam Deck, and a ready-to-game SteamOS-like for desktop computers, living room home theater PCs, and numerous other handheld PCs.

https://github.com/ublue-os/bazzite/

Worth visiting the readme even if not interested. There's a huge list of included stuff, and a lot of it seems really cool.and helpful (for gamers or streamers mostly).

check out bazzite, it's basically steamos but fedora based instead of arch based, has the same immutable root layout for stability and smooth upgrades and as long as youre not using nvidia graphics you can use gaming mode with the bazzite-deck image

I was in a similar situation as the author: for quite a while I had to build my own Redhat kernel for a very obscure case: by pass RMRR check to pass GPU to a windows VM. (similar to https://github.com/kiler129/relax-intel-rmrr ; not my repo)

The root issue can only be addressed by ROM updates from the manufacturer but I'm running an old DL360 that's no longer supported by HPE.

The patch itself is only one line change but updating the kernel is a pain since I have to :

Good news and bad news, there is a solution: https://github.com/kiler129/relax-intel-rmrr. But it's not always easy unless you understand building kernels. I have to do this on hpe platforms that I own.

One other method I used early in my research was to build a custom kernel that had a patch to ignore the RMRR. That worked really well and everything passed through as it should without issue, but every time you need a kernel upgrade, you have that hassle to deal with. Here is that patch if you'd like to give it a try: https://github.com/kiler129/relax-intel-rmrr

So after some searching I finally found a patch. https://github.com/kiler129/relax-intel-rmrr

So basically, some servers (HP proliant G6, G7 and some more but I don't know them all, i have a g6) have issues with RMRR. In order to fix this, you need to remove the RMRR check. When I used proxmox, I used https://github.com/kiler129/relax-intel-rmrr/blob/master/README.md#proxmox---premade-packages-easy this. Premade packages because I had no clue how to do it myself. That fixed my PCIe passthrough issues. But on manjaro, there is no premade packages for this patch. I have to manually add the patch, compile the kernel and install it and then PCIe passthrough will work hopefully.