this post was submitted on 03 Jun 2024
30 points (91.7% liked)

Linux

48216 readers
902 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
30
Manjaro or Pop!_OS for (Nvidia) gaming on Steam? (lemmy.world)
submitted 5 months ago* (last edited 5 months ago) by lawrence@lemmy.world to c/linux@lemmy.ml
56 comments fedilink hide all child comments
 

cross-posted from: https://lemmy.world/post/16149785

Cross-posting here for more opinions.

Gentlemen, just for context, I usually use Linux. I have been a user of Debian, Ubuntu, and Fedora for a few years.

Recently, I acquired a decent graphics card (GeForce RTX 4070) and decided to uninstall my Windows and install Linux.

I saw that Pop!_OS already has an image with everything pre-configured for Nvidia. Is this pre-configuration worth it, are the games more stable on this distribution, or is it the same as manually installing Nvidia's proprietary drivers on Manjaro?

you are viewing a single comment's thread
view the rest of the comments
[–] yala@discuss.online 4 points 5 months ago* (last edited 5 months ago) (1 children)

But they rely on rpmfusion, an external repo packaging the proprietary NVIDIA stuff for Fedora. The repo is not supported by Fedora, and the drivers cannot be fixed by anyone.

Not sure what you're trying to say here. Would you mind elaborating? FWIW, Bazzite's model (by default) allows automatic fixes to be applied to a broken driver without requiring any manual intervention from its user.

[–] boredsquirrel 2 points 5 months ago* (last edited 5 months ago) (1 children)

allows automatic fixes to be applied to a broken driver without requiring any manual intervention from its user.

If you get an update, and after that update your system doesnt graphically boot anymore or something, you can use sudo ostree admin pin 1 and rpm-ostree rollback to switch back to the working version and make sure it never disappears.

Then you can wait for a next update (still no good update info mechanism afaik) to fix it, try it, unpin the saved version and go on.

But there is no automatic repair voodoo anywhere, on any distro. That driver is proprietary, only NVIDIA can fix it. rpmfusion packages it to work on Fedora, Fedora Atomic helps making this very unstable mechanism more failsafe.

But you are still relying on 3 entities (NVIDIA, rpmfusion, Fedora, (uBlue)), with NVIDIA not caring about Linux that much, instead of 1 (Fedora) like with AMD, where drivers are FOSS and can be adapted for Fedora specifically.

AMD does not opensource a lot, and ROCM or the entire amdgpu-pro driver is a similar situation. But at least the basics work.

[–] yala@discuss.online 3 points 5 months ago* (last edited 5 months ago) (1 children)

But there is no automatic repair voodoo anywhere, on any distro. That driver is proprietary, only NVIDIA can fix it.

Consider to revisit this, cuz this is basically (at least for me) most of uBlue's schtick:

"No more building drivers on your laptop, dealing with signing, akmods, third party repo conflicts, or any of that. We've fully automated it so that if there's an issue, we fix it in GitHub, for everyone."

And the way it's setup, is so that you don't get the broken update ever on your device in the first place.

So, contrary to what you might expect, this black magic (or just excellent engineering) somehow does exist.

[–] boredsquirrel 2 points 5 months ago* (last edited 5 months ago) (1 children)

uBlue does not repair anything, they dont automatically detect a broken driver on your system and block an update.

This would be possible, but slow down boot (running some GPU benchmark on every boot via a systemd service, if it fails run the commands that I mentioned).

rpm-ostree is awesome, and has the potential to do that.

you don't get the broken update ever on your device in the first place.

In theory yes, but this would mean uBlue is some kind of stable distro. I dont know, at least their base images just get updates.

Their big advantage is that they dont have the legal restrictions, so they can ship 1:1 the system you run. I dont know if they do, but having some automated benchmark tests on real hardware with these devices would be useful.

But that costs a lot of money. uBlues trick is that they can run their whole huge project for free on Github.

But for sure, the dependency issues will not occur. But this does not guarantees that there are no issues on bare metal.

Or a stable branch, Bazzite was longer on F39 for example. I use the :latest branch which automatically gets upgraded to the latest version, which they determine. So having an :testing branch that is up to date, and slowing down the releases of the latest branch, could help.

[–] yala@discuss.online 3 points 5 months ago (1 children)

I think we're misunderstanding eachother. So perhaps consider to outline if you agree with the following:

  • uBlue has some systems in place that enable it to detect some breakages.
  • uBlue's pipeline is such to not ship you the detected breakages.
  • After a method has been found to fix a breakage (or other issues), uBlue's maintainers implement these fixes and then, the very next update, the users will receive an image that contains both the updated package and the fixes required for it to not cause problems. Heck, the user didn't know anything was up in the first place. They didn't notice a thing*.
  • uBlue's issue/problem detect systems are not absolute; things might slip through.
  • However, Nvidia drivers will not cause breakage that will make you shiver in fear.
  • uBlue does not fix it on your device. They fix the image and that fixed image will deliver you the fix built-in; so manual intervention are a thing of the past (except for edge cases).
  • Their pipeline does not require nor does it detect (through telemetry or whatsoever) the breakage on the device of the user. Heck, as implied earlier, most breakages are detected, prevented from shipping broken, fixed, ship the fixed one before any end user is disturbed by it.
  • uBlue is not a Stable system (i.e. it does not freeze packages (apart from security updates) until the next major release). So yes, you receive updates all the time.
  • Not being tied to legal restrictions is cool. However, a lot of derivatives do this. So this can't be its unique selling point.
  • uBlue is not entirely free. Its maintainers do pay money for providing some of their services (as has been mentioned by Jorge).
  • Some of their images do have testing branch; even Bazzite has.
[–] boredsquirrel 4 points 5 months ago (1 children)

Yes agreed.

I didnt know they have testing images, but makesbsense in their flagship variants.

I miss the old website with the full image list.

[–] yala@discuss.online 2 points 5 months ago* (last edited 5 months ago) (1 children)

Thank you for contributing so that people don't misunderstand!

I didnt know they have testing images, but makesbsense in their flagship variants.

You can verify it yourself from here.

Though, with all that's mentioned above; do you still think Pop!_OS is better than Bazzite for Nvidia?

[–] boredsquirrel 3 points 5 months ago (1 children)

I dont know.

"Traditional" / "package based" / "messy" distros suck a bit. The big issue is doing insane stuff like the kernel mod stuff on the user side, which leads to sooo much pain.

But as far as I know, NVIDIA just supports enterprise distros. The community distros build the packages, but the binaries are not compiled for newer distros. So using non-LTS Ubuntu etc may result in breakages. Especially when using newer kernels.

I dont know a lot of how drivers depend on userspace programs, it is likely only dependend on the Kernel.

I also look forward to CentOS-bootc, which is a bootable OCI container for CentOS-stream. Like the uBlue Containers or the OCI containers for Fedora built on Gitlab, used by uBlue.

I didnt know that, but uBlue uses random OCI container builds by Fedora for all their stuff, that Fedora doesnt even officially use themselves.

[–] yala@discuss.online 1 points 5 months ago (1 children)

But as far as I know, NVIDIA just supports enterprise distros.

I tried looking this up, but to no avail. Got any proof to back this up?

I didnt know that, but uBlue uses random OCI container builds by Fedora for all their stuff, that Fedora doesnt even officially use themselves.

I don't know how it is currently. However, initially, images were provided by maintainers affiliated to Fedora. Could you provide a link in which your current understanding is better described/explained?

[–] boredsquirrel 2 points 5 months ago

I tried looking this up, but to no avail. Got any proof to back this up?

Interesting, I only found a different site that offered the download specifically for developers to embed in their distros.

It was AMDGPUPro that only supports enterprise Linux.

Could you provide a link

I didnt find it. Search in the Atomic issue tracker, siosm wrote somewhere that the images are built on Gitlab and are the foundation of uBlue.

While Gitlab is not the official distribution method, and this was an issue about adapting these images for the main Fedora variants. So they arent even used, but built.

That upstream unused images are taken as the base for uBlue is pretty funny. But they have a future, and will likely become the main way of shipping Fedora Atomic.

Then it is also truly image-based, unlike the OSTree repo currently.